予測市場のバックテストでは、ティッカーも価格履歴も正しそうに見えるのに、契約だけが違うことがあります。この誤りは見落としやすいものです。市場名は短く、イベントページは更新されることがあり、YESシェアはいつでも0から1の価格に見えるからです。
「クリーン交通法案は可決されるか？」という仮想市場を考えてみましょう。ある戦略がニュースシグナルを受けて、0.42でYESを買います。バックテストではその後、ポジションを1.00で評価します。この勝ちを信頼する前に、契約が具体的に何を約束していたのかを確かめたいところです。どの法案か、「可決」が何を意味するのか、期限はいつか、どの情報源が結果を確定したのか。
タイトル：「クリーン交通法案は可決されるか？」
タイトルは表示用の文字列であって、安定した金融商品識別子ではありません。よく似た文言の市場でも、対象が異なる議会会期、修正法案、あるいは期限であることがあります。また、取引所が市場の基本条件を変えずに、内容を明確にするためタイトルを変更する場合もあります。
そのため、バックテストでは取引所の変更されない市場IDまたは契約IDをポジションのキーとして使い、ルール全文とそのバージョンも保存する必要があります。過去データにタイトルとティッカーしかなければ、その価格系列が戦略の取引対象だった契約のものだとは確認できません。
| 識別項目 | 特定できる内容 | 省略した場合の問題 |
|---|---|---|
| 取引所と市場ID | 個別に上場された市場 | 似たタイトルの市場が混同される |
| ルールのバージョン | 参加者が合意した条件 | 後日の編集内容が過去の取引に適用される |
| 結果トークンID | 取引対象のYESまたはNOの権利 | YESとNOの価格が入れ替わる、または混同される |
| 判定情報源 | 結果の判定に使われる根拠 | バックテストが別の判定主体を想定する |
ルール：「可決」とは何か？
たとえばルールに、法案は6月30日までに下院と上院を通過し、その後大統領の署名を得なければならない、とあるとします。いずれか一方の議院を通過すれば成功とみなすバックテストは、賭けの内容を変えてしまっています。次の会期に同じ名前の法案が成立した場合まで数えるのも同じです。
実際の結果判定基準を、実行可能な条件として読み解きましょう。期限とタイムゾーン、該当するイベント、例外、指定された判定情報源を記録します。曖昧さも重要です。取引所のルールで妥当なシナリオが未確定のままなら、過去の結果に合う解釈をひそかに選んではいけません。
この作業には、実に地味ながら大切な工程があります。何か動きが起きる前にルールページを保存することです。結果確定後に初めて保存したページには最終版の文言が載っていても、戦略が注文を出した時点では、より前のバージョンが適用されていたかもしれません。
タイムライン：戦略はいつ情報を得られたか？
では、ルールに問題がなく、ニュースシグナルが14:05 UTCに出たとしましょう。過去データには、14:05に0.42で取引が成立したとあります。このタイムスタンプだけでは、情報が取引前に得られたのか、その後に記録価格で約定できたのか、あるいはバーが気配値、取引価格、期間集計のどれを表しているのかは分かりません。
シグナルが利用可能になった時刻と、市場イベントの時刻は分けて管理しましょう。そのうえで、戦略が計算して注文を出せる時刻以降に注文を置きます。流動性の薄い市場では、次の取引記録まで数分かかることがあります。それは、あなたの注文がその価格で約定した証拠にはなりません。
価格：気配値は約定価格ではない
YESの0.42は1シェアあたり42セントを意味しますが、直近取引の系列ではスプレッドや利用可能な数量が分かりません。最良売気配が0.45で20シェアなら、100シェアの買い注文すべてを0.42で約定させることはできません。板を食い上がるか、待つか、未約定のままになる可能性があります。
予測市場の価格では、会計上の近道にも注意が必要です。0.42を42%の確率として扱い、同時にそれがエントリー時の現金支出でもあることを忘れがちです。YESを100シェア保有するには、手数料を除いて$42かかります。1ドルで決済されれば、手取り前の受取額は$100です。0ドルで決済されれば、受取額はゼロです。手数料、部分約定、取引所固有の決済方法も台帳に反映させましょう。
決済：何をもって取引終了とするか？
バックテストでは、最後の市場価格でポジションを終了させることがよくあります。しかし、判定まで保有する契約はルールに基づいて支払われます。最後に記録された気配値が古かったり、スプレッドが広かったり、最終的な支払額とかけ離れていたりすることもあります。結果、決済時刻、現金の移動は契約記録から取得し、判定を独立したイベントとしてモデル化しましょう。
取引所のルールで無効または係争中の結果が定義されている場合は、それも考慮します。賭け金が返還されたり、別の金額が支払われたり、決済が遅れたりする可能性があります。2値の支払いを前提にすると、すべての判定経路を表現できません。
バックテストの判定
この例では、変更されない市場ID、エントリー時点で有効だったルールのバージョン、YESトークン、シグナルの利用可能時刻、実際に約定可能な売気配と数量、手数料、記録された決済を照合して初めて、報告された勝ちを認めます。価格アーカイブでこれらを確認できないなら、誠実な報告はシナリオの範囲か、未検証という結果です。
小さな取引1件の話としては厳しく聞こえるかもしれません。同じ結合ミスが何千もの市場で繰り返されれば、バックテストは、戦略が一度も取引していない契約を丁寧に測定する結果になりかねません。
← 記事一覧
