【ITニュース解説】I tried to reproduce four Collective2 Calmar ratios. None of them matched.

ITシステム開発において、データの信頼性とその再現性は極めて重要な要素だ。今回注目するニュース記事は、まさにこの「データの再現性」がどれほど重要かを示している。ある投資戦略を紹介するウェブサイトに掲載されている「カルマー比率」や「プロフィットファクター」といった評価指標が、そのウェブサイトが公開している基本データから再計算できるか、つまり「再現性があるか」を検証した事例である。

検証の舞台となったのは、様々な投資戦略が紹介されているCollective2というプラットフォームだ。このプラットフォームでは、投資家が戦略を選び、そのパフォーマンスを判断するために多くの統計データが提示されている。記事の著者は、その中でも特に主要な二つの指標に焦点を当て、公開されている基本データを用いてそれらを独自に計算し直した。

まず、一つ目の指標である「カルマー比率」とは、投資戦略のリターンとリスクのバランスを示すものだ。具体的には、「年間リターン」を「最大ドローダウン」（資産が最も大きく減少したときの割合）で割って算出される。この比率が高いほど、得られるリターンに対してリスクが小さい、つまり効率の良い戦略であると評価できる。システムエンジニアの視点で見れば、これはシステムの「性能」と「安定性」を比較するような指標と言えるだろう。高い性能を持っていても、システム障害で頻繁に停止するようでは、その総合的な評価は下がってしまう。カルマー比率も、単に利益が高いだけでなく、その利益を得るまでの下落リスクも考慮に入れた総合的な評価を意図しているのだ。

二つ目の指標は「プロフィットファクター」だ。これは、その戦略で得られた総利益が、総損失の何倍になったかを示す指標である。計算式は「（勝率 × 平均利益） ÷ ((1 - 勝率) × 平均損失)」となる。プロフィットファクターが1より大きければ、利益が損失を上回っていることを意味し、数値が大きいほど効率的に利益を上げている戦略と見なされる。これは、システムが処理するタスクの「成功率」と「成功時の利益」「失敗時の損失」を考慮して、総合的な「稼働効率」を測るようなものと捉えることができる。

著者は、Collective2の四つの投資戦略ページに表示されている「年間リターン」「最大ドローダウン」「勝率」「平均利益」「平均損失」という五つの基本データに着目した。そして、これらの数値を使って先に述べたカルマー比率とプロフィットファクターを自分で計算し、ウェブページに掲載されている値と比較したのだ。これは、システムが出力するレポートの数値が、そのレポートの元となるデータから正しく導き出されているかを確認する作業と全く同じである。

検証の結果は興味深いものだった。カルマー比率については、調査した四つの戦略すべてで、ウェブページに表示されている値と自分で再計算した値が一致しなかった。ウェブページの表示値は、再計算値よりも1.21倍から1.53倍も高い値を示していたのである。しかも、この「ずれ」の割合は戦略によって異なっていた。これは、もしプラットフォーム側で特定の異なる計算方法を使っているのだとしても、その方法がすべての戦略に対して一貫しているわけではない可能性を示唆している。例えば、「年間リターン」の年率換算の方法が異なるのか、あるいは「最大ドローダウン」の定義が異なるのかといった疑問が浮かび上がるが、その違いが固定的なものではないため、問題はさらに複雑だ。

一方でプロフィットファクターは、四つの戦略のうち三つで、ウェブページの表示値と再計算値が数パーセント以内の誤差で一致した。これは、丸め誤差や表示の桁数の違いの範囲内と見なせるレベルであり、これらの戦略に関するプロフィットファクターの数値は信頼性が高いと言えるだろう。しかし、残りの一つの戦略（ID: 132169961）では、プロフィットファクターがウェブページの表示値と再計算値で14.8%もの大きなずれを見せた。この戦略では、同じページに表示されている他の基本データ（勝率や平均利益・損失）から計算した結果と、プロフィットファクターの数値が大きく食い違っていたのだ。

この検証結果から得られる教訓は多い。まず、プロフィットファクターのほとんどが一致したことから、Webページに掲載されている他のデータは概ね正確である可能性が高い。だからこそ、カルマー比率のずれは単なる入力ミスやいい加減な表示ではなく、プラットフォーム側が採用している「計算定義の違い」に起因する可能性が高いと考えられる。しかし、その定義が公開されていない、あるいは戦略によって異なるために、一貫性が失われている状況だ。

最も深刻な問題は「比較可能性」の欠如にある。もし二つの投資戦略が「カルマー比率2.0」と表示されていたとしても、その計算方法が異なれば、それらを公平に比較することはできない。ウェブサイト上では同じ基準で評価されているように見えても、実際には異なるものさしで測られた結果である可能性があるのだ。これは、システムエンジニアが異なるサービスの性能指標を比較する際にも同じことが言える。例えば、あるAPIの「レスポンスタイム500ミリ秒」と、別のAPIの「レスポンスタイム500ミリ秒」が、計測方法や基準（例えば、平均値か中央値か、成功したリクエストのみかエラーも含むかなど）が異なれば、そのまま比較することはできないだろう。

このニュースは、特定のサービスが「嘘をついている」と断定するものではない。むしろ、システムが提供するデータの裏側にある「定義」や「計算ロジック」がどれほど重要かを示している。公開されている数値だけを見て判断するのではなく、その数値がどのような前提条件のもと、どのような計算を経て導き出されたのかを理解しようとすることが、システムエンジニアを目指す上で非常に重要だ。

私たちがITシステムを開発する際も、ユーザーに提供する数値やレポートが、どのような入力データから、どのようなアルゴリズムによって計算されたのかを明確にし、必要であればその再現性を保証することが、システムの信頼性を高める上で不可欠である。特に、外部のシステムと連携したり、異なるシステム間でデータを比較したりする場面では、各データの定義が本当に一致しているかを確認する「データの互換性」と「計算ロジックの透明性」が、システムの品質を大きく左右する。

この検証結果は、表面的な数字だけを鵜呑みにせず、その背後にあるロジックを常に探求し、自ら検証するエンジニアとしての姿勢がいかに重要かを教えてくれる。ユーザーが安心してシステムを利用できるようにするためには、提供するすべての情報に対して、その計算方法が明確であり、誰もがその結果を再現できるような透明性を持たせることが、現代のシステム開発には求められているのだ。