1人の開発者がPolymarket取引ロボットの構築方法を共有し、BTCの15分間市場の価格変動を捉えることで、数日で1000ドルを1869ドルに増やし、リターン率86％を達成した。記事では、ロボットの構築ロジック、バックテスト方法、その制約について詳述している。
（前提：予測市場のリーダーPolymarketが独自のL2を構築すると発表、Polygonの切り札はなくなる？）
（補足：Polymarketの裁定取引で年率40％の利益を実現する方法は？）

目次

• ロボットの構築ロジック
• バックテスト
• バックテストの制約
• インフラ

数週間前、私は自分専用のPolymarketロボットを構築することを決意した。完全版の作成には数週間を要した。

このエネルギーを投入した理由は、Polymarketには確かに効率の悪さの脆弱性が存在し、市場にはこれらの非効率を利用した利益獲得を狙うロボットもあるが、まだ十分ではなく、この市場のチャンスはロボットの数よりもはるかに多いからだ。

ロボットの構築ロジック

このロジックは、私が過去に手動で実行していた戦略に基づいており、効率化のために自動化したものだ。ロボットは「BTC 15分間のUP/DOWN」市場で動作する。

ロボットはリアルタイム監視プログラムを運用し、現在のBTC 15分間のラウンドに自動的に切り替え、WebSocketストリームを通じて最良買値/売値（best bid/ask）を伝送し、固定の端末UIを表示、文字コマンドによる全面制御も可能にしている。

手動モードでは、直接注文を出せる。

buy up / buy down ：特定のドル金額で買い。

buyshares up / buyshares down ：正確な株数を購入。ユーザーフレンドリーなLIMIT（指値）+ GTC（キャンセルまで有効）注文を使用し、現在の最良売値（best ask）で約定。

自動モードは、二段階（two-leg）の繰り返しループを運用。

最初の段階では、各ラウンド開始後の windowMin 分以内に価格変動を観察。どちらかが急落（約3秒以内にmovePct以上の下落）した場合、「第一段（Leg 1）」をトリガーし、急落した側を買い。

Leg 1完了後、同じ側を再び購入することはなく、「第二段（Leg 2、ヘッジ）」を待つ。条件は：leg1EntryPrice + oppositeAsk <= sumTarget。

この条件を満たすと、反対側を購入。Leg 2完了後、そのサイクルは終了し、ロボットは次の暴落シグナルを待つ状態に戻る。

サイクル中にラウンドが変わった場合、そのサイクルは放棄され、次回同じ設定で再開。

自動モードのパラメータ設定は以下の通り：auto on [sum=0.95] [move=0.15] [windowMin=2]

• shares：二段階取引のポジションサイズ
• sum：ヘッジ閾値
• move (movePct)：暴落閾値（例：0.15＝15％）
• windowMin：各ラウンド開始からLeg 1を実行できる時間（分）

バックテスト

ロジックは非常にシンプル：暴力的な売り圧力を待ち、下落した側を買い、その後価格が安定したら反対側を買ってヘッジ。条件は：priceUP + priceDOWN < 1。

しかし、このロジックはテストが必要だ。長期的に本当に有効なのか？さらに重要なのは、多くのパラメータ（株数、合計、移動閾値、ウィンドウ時間など）が存在し、最適な組み合わせは何か、最大の利益をもたらすのはどれか。

最初のアイデアは、ロボットを実運用し、一週間観察することだった。しかし、これには時間がかかりすぎ、パラメータは一つしか試せない。

次のアイデアは、PolymarketのCLOB APIから取得できる過去の履歴データを使ったバックテストだ。しかし、BTC 15分間のUP/DOWN市場の履歴データエンドポイントは空のデータセットを返し続けている。過去の価格変動（ticks）がなく、暴落（約3秒以内）を検出できず、Leg 1をトリガーできない。パラメータに関係なく、サイクルは0回、ROIは0％となる。

調査を進めると、他のユーザーも特定の市場の履歴データ取得に問題を抱えていることが判明。いくつかの市場で実際に履歴データを返すものを試した結果、この特定の市場では履歴データが保持されていないことがわかった。

この制約のため、戦略のバックテスト唯一の信頼できる方法は、ロボットの動作中にリアルタイムの最良売値を記録し、自分で履歴データを作成することだ。

記録ツールはスナップショットをディスクに書き込み、内容は以下の通り：

• タイムスタンプ
• ラウンド識別子（round slug）
• 残り秒数
• UP/DOWNトークンID
• UP/DOWNの最良売値

その後、「記録バックテスト（recorded backtest）」はこれらのスナップショットをリプレイし、同じ自動ロジックを確定的に適用。これにより、暴落とヘッジ条件の検出に必要な高頻度データを確保できる。

合計4日間で6GBのデータを収集。もっと記録できたが、異なるパラメータセットを試すには十分と判断。

このパラメータセットをテスト開始：

• 初期残高：$1,000
• 1回あたり20株
• sumTarget = 0.95
• 暴落閾値 = 15%
• windowMin = 2分

また、0.5％の固定手数料と2％のスプレッドも適用し、保守的なシナリオを想定。

バックテスト結果はROI86％、数日で$1,000が$1,869に増加。

次に、より攻撃的なパラメータも試した：

• 初期残高：$1,000
• 1回あたり20株
• sumTarget = 0.6
• 暴落閾値 = 1%
• windowMin = 15分

結果は：2日後のROIは-50％。

これにより、パラメータ選択の重要性が明確に示された。適切な設定次第で大きく稼げるし、大きな損失も招く。

バックテストの制約

費用やスプレッドを考慮しても、バックテストには制約がある。

• まず、数日分のデータしか使っておらず、市場全体の視野を得るには不十分。
• 記録した最良売値のスナップショットに依存しているため、実際には注文が部分的に約定したり、異なる価格で成立したりする可能性を考慮していない。注文簿の深さや利用可能な取引量もモデル化されていない。
• 秒以下の微細な動き（データは1秒ごとにサンプリング）を捉えられず、1秒のタイムスタンプはあるが、その間に多くの動きが起き得る。
• スリッページは一定とみなされ、遅延（200〜1500ミリ秒）やネットワークのピーク時の遅延は模擬されていない。
• 各取引は「即時」執行とみなされ、注文の待ち行列や指値注文は考慮されていない。
• 費用は一律だが、実際には市場やトークン、注文者と売り手の条件、手数料レベルにより変動する。

慎重を期すために、次のルールを適用：もしLeg 2が市場閉鎖前に執行されなかった場合、Leg 1は全損とみなす。

これは保守的な仮定だが、実際には：

• Leg 1は早期に終了できることもある
• 最終的にITM（イン・ザ・マネー）となり勝つこともある
• 損失が部分的で済む場合もある

損失は過大評価される可能性があるが、最悪のシナリオを想定した実用的なモデルとも言える。

最も重要なのは、バックテストは大口注文が注文簿に与える影響や、他のトレーダーの追撃行動を模擬できないことだ。実際には、あなたの注文は：

• 注文簿を攪乱し、
• 他のトレーダーを引き付けたり排除したりし、
• 非線形のスリッページを引き起こす。

バックテストは、あなたが純粋な流動性供給者（price taker）であると仮定している。

最後に、レートリミット、APIエラー、注文拒否、一時停止、タイムアウト、再接続、ロボットの忙しさによるシグナル見逃しなどは考慮されていない。

バックテストは良好なパラメータ範囲を見つけるのに非常に有効だが、現実の効果の一部はモデル化できないため、100％保証ではない。

インフラ

このロボットは、私のメインPCのリソースを消費せず、24時間365日稼働させるためにRaspberry Pi上で動かす予定だ。

しかし、改善の余地は大きい：

• Rustに切り替えることで、JavaScriptよりも遥かに高性能かつ高速に動作
• 専用のPolygon RPCノードを運用し、遅延をさらに低減
• Polymarketのサーバーに近いVPSに展開し、遅延を大きく削減

他にも最適化手法はあるかもしれない。現在はRustを学習中で、Web3開発において不可欠な言語になりつつある。