取引を決定してから実際に執行するまでの「ギャップ」が、正しく作られたボットが静かに損失を出している本当の理由
Polymarket取引ボットの構築に関するほとんどの記事は、プライシングモデルにばかり焦点を当てている。エッジをどう計算するか、どんなシグナルを使うか、確率の推定をどれだけ正確にするか。
しかし、その決定が下された後の数ミリ秒に何が起きているかを書いた記事は、ほぼ存在しない。
薄い流動性の市場では、そのギャップこそが、技術的に正しいボットが静かに損失を出し続ける原因になっている。
Polymarket取引ボットがエッジを計算する仕組み
ほぼすべてのPolymarket取引ボットは、こんなループから始まる。
オーダーブックを取得する。そこから暗示確率を計算する。自分のモデルの推定値と比較する。エッジが閾値を超えていれば、そのエッジに合わせたサイズで注文を出す。
深い流動性のある市場ではこれで問題ない。しかし、トップオブブックの流動性が浅い市場では静かに失敗する。Polymarketのフラッグシップ市場以外の多くのリストがそれに該当する。
問題は数学ではない。タイミングだ。
ボットがオーダーブックを取得した瞬間から、注文が取引所に届くまでの間に、ブックは変わっている可能性がある。薄い市場では、中程度のサイズの注文一つで、その間に見えていた流動性のほとんどが消える。
自分が計算したエッジは、もう存在しないブックの状態に基づいていた。
結果として、モデルが一度も評価していない価格で約定することになる。数学は正しかった。タイミングが違った。しかし、特別に確認していなければ、ログからは区別がつかない。
なぜこれが予測市場では特に深刻なのか
従来の取引インフラは数十年前から実行レイテンシの問題に取り組んできた。ただし、そのほとんどは深い流動性の市場を前提にしており、影響はわずかだ。
Polymarketのような予測市場は構造的に違う。
高ボリュームな少数の市場を除けば、オーダーブックはデフォルトで薄い。そして、5分・15分のBTC Up/Downマーケットのような短期間のコントラクトは、取引のライフサイクル全体を非常に短い時間に圧縮する。数秒のドリフトが、ポジションの保有時間全体に対して無視できない割合を占めることになる。
深い流動性の取引所では問題なく機能したPolymarket取引ボットが、ここでは一貫して損失を出すことがある。プライシングモデルの問題ではなく、「価格を計算したブックが、実際に取引するブックと同じ」という前提が崩れるためだ。
修正方法：実行直前に検証する
解決策はより良いモデルではない。安価な実行ガードだ。
注文を出す直前に、ライブのオーダーブックを再取得する。エッジを計算したスナップショットとの差分を確認する。ドリフトが設定した許容値を超えていれば、盲目的に実行するのではなく、その取引をスキップする。
def validate_before_execution(priced_book, market_id, drift_tolerance=0.02):
"""
注文を出す直前にライブのオーダーブックを再確認する。
価格計算時からドリフトが許容値を超えていればFalseを返す。
"""
live_book = fetch_orderbook(market_id)
drift = calculate_book_drift(priced_book, live_book)
if drift > drift_tolerance:
log_skip(market_id, reason="ブックが許容値を超えてドリフト", drift=drift)
return False
return True
def trading_loop(market_id):
book = fetch_orderbook(market_id)
implied_prob = calculate_implied_probability(book)
my_prob = model.predict(market_id)
edge = my_prob - implied_prob
if edge > EDGE_THRESHOLD:
size = position_size(edge)
if validate_before_execution(book, market_id):
place_order(market_id, size=size)
追加コストはAPIコール一回だけ。それだけで、ボットは古い価格に対して実行し続けることをやめる。実際のところ、これは流動性の薄いPolymarket市場においてはモデルの改善よりもはるかに重要だ。
本番環境で使えるひとつの目安
トップオブブックの深さが自分の想定ポジションサイズの約3倍を下回る場合、モデルの精度よりも「ステールネス」を最大のリスクとして扱うべきだ。
その比率を下回ると、どれだけプライシングシグナルが優れていても、注文が届くまでの時間で市場は意味のある変動をする可能性がある。比率が上回れば、実行レイテンシはまだ重要だが、損失の支配的な要因ではなくなる。
同じ原則はPolymarket以外でも現れる。私がもう一つ構築しているカジノプラットフォームのプロバブリーフェアRNGシステムでも、同じ失敗パターンが出てくる。結果を生成した状態と、コミットした状態が一致していなければ、タイミングベースの不正を許すことになる。プロダクトは違っても、根本的な問題は同じだ。自分が取得したスナップショットを、世界が変わった後も信頼し続けてはいけない。
より大きなボットアーキテクチャの中での位置づけ
実行検証は、Polymarket取引ボットのフルスタックのうちの一層に過ぎない。データ取得、シグナル検出、確率モデリング、実行、リスク管理、これらすべてが連携して機能する必要がある。
しかしこの層は、ほとんどのチュートリアルが完全にスキップしている部分だ。だからこそ、プライシングモデルだけでボットを収益性に持っていけると仮定するのではなく、意識的に構築する価値がある。
Polymarketや、薄いオーダーブックを持つ取引所で自動実行を構築しているなら、モデルのチューニングよりも先にこの検証レイヤーを優先することを勧める。精度の高いモデルにステールネス対策がなければ、流動性の薄い約定でエッジを失い続ける。適度なモデルでも、実行コントロールが厳しければ、実際に重要な市場でそれを上回る結果を出す傾向がある。
私はPolymarket取引ボットの実行・リスク・アービトラージインフラと、カジノプラットフォームのプロバブリーフェアシステムを構築している。実行タイミングの問題に取り組んでいる方は気軽に連絡してほしい。
関連記事:
Polymarketトレーディングボット開発：実際に機能する手法とは: Dev.to link