5秒で結論： スキャルピングの板・約定データから未知の勝ち筋を逆探索するような、計算も推論も重い部分はGPT-6 Astraに集中させる。一方、データ基盤、実験環境、バグ修正、回帰テスト、バックテスト、反証、ジョブ管理はClaude Opus 5.5に任せる。つまり「一番賢いAIを全部に使う」のではなく、Astraを高価な研究者、Opus 5.5を止まらない現場監督として使う二段構えだ。
1. まず驚いたのは「賢さ」より、止まらず次へ行くことだった
ある長いソフトウェア保守セッションでは、最初の失敗を一つ直して終了、ではなかった。
ランタイム差によるテスト失敗を依存注入で切り分け、廃止済み仕様を検査していた古いテストを書き換え、共有バリデータへの移行に追随していなかった監査ロジックを修正し、最後に本番ビルドを止めていたfixture不足まで掘り当てた。個別テストを直した後には全テストを再実行し、さらに実ビルドまで通した。
人間から見ると、これは「一発の天才回答」より価値が大きい。
エージェント作業のボトルネックはしばしば、
- 問題を発見する
- 一つ直す
- 別の失敗を見つける
- 「次はこれを確認してください」で止まる
- 人間が「いや、そのまま続けて」と再起動する
という人間割り込み税だからだ。
AnthropicはOpus 5.5を、長時間のコーディング、大規模コードベース、複数ツールをまたぐエージェント作業を少ない監督で前に進めるモデルとして位置づけている。Opus 5より典型的なトークン課金ワークロードで約40%低コストとも説明している。
ここで重要なのは、AIの価値を「難問を一問解くIQ」だけで測らないことだ。現場では、原因特定、修正、検証、再修正、完了確認までつながるかどうかが効く。
2. ではAstraは要らないのか？ むしろ「探索だけ」に使うと贅沢さが生きる
GPT-6 AstraはOpenAIが最難関のend-to-end作業向けとして出している最上位モデルで、API価格は100万トークンあたり入力10ドル、出力50ドル。Opus 5.5の4ドル、20ドルより重い。
しかもOpenAIのAstra紹介では、Jane Streetの評価として、GPT-5.6 Solに比べて「trading intuition」の評価で明確な改善があったと紹介されている。OpenAIの金融サービス向け製品でも、Astraは情報検索、金融推論、成果物生成の三領域で強いと位置づけられている。
だからAstraを、CSV整形、依存関係修正、テストfixture作成、ファイル名変更のような仕事で燃やすのはもったいない。
Astraには、
- 何が効いているか分からない
- 特徴量の候補が広い
- 条件の組み合わせが多い
- 正解の形がまだ定義できない
- 失敗仮説を大量に捨てる必要がある
という「研究」の部分だけを渡す。
道路工事までF1マシンでやる必要はない。F1はコースができてから呼べばいい。
3. 板スキャルピングの逆探索は「指標を考える」より、未来の値動きから過去へ戻る
ありがちな戦略設計は、「RSIが低いなら買う」「板の買いが厚いなら上がるかも」と人間が先に条件を作る。
逆探索は逆だ。
まず、500ミリ秒後、1秒後、3秒後、5秒後などに、手数料とスプレッドを超えて価格が動いた局面を機械的に抽出する。その直前の板と約定列へ戻り、何が共通していたかを探す。
例えば候補は、
- best bid / ask周辺の厚み
- 複数段のdepth imbalance
- market orderの方向と強度
- order-flow imbalance
- cancel / addの比率
- 板の補充速度
- spreadの拡大・縮小
- 約定後の板復元
- micropriceとmid-priceの乖離
- ボラティリティ regime
- 時間帯
- 数百ミリ秒単位のイベント順序
などになる。
Cont、Kukanov、Stoikovは、短い時間幅の価格変化について、単純な出来高よりもbest bid / ask周辺のorder-flow imbalanceとの関係が強く、影響度は市場のdepthにも左右されることを示した。
つまり板は「買い板が厚いから上」程度の静止画ではない。注文追加、取消、成行、補充が時間方向に流れるイベント列である。
ここをAstraに探索させる価値がある。
4. ただし「100個試して一番儲かった」は、聖杯ではなく過学習ガチャかもしれない
AI探索の最大の罠は、賢くなるほど大量の戦略を試せることだ。
Baileyらの研究は、バックテスト候補を大量に試し、その中の最高成績を選ぶほど、in-sampleで偶然よかっただけの戦略を選びやすくなる問題を扱っている。
つまりAstraが1万個の条件を発見して「これが最強です」と言った瞬間、むしろ警戒レベルを上げる必要がある。
逆探索では最低でも、
- 探索期間と最終評価期間を分離する
- 時系列を壊すランダムsplitに頼り切らない
- 同じ期間へ何度も戻って条件調整しない
- 試した仮説数を記録する
- 複数regimeで崩れないか見る
- 手数料とspread込みで評価する
- 将来情報の混入を検査する
必要がある。
ここでOpus 5.5を「Astraが見つけた戦略を殺しに来る査読者」にする。
Astraには発見させる。Opusには疑わせる。
研究組織としては、仲が悪いくらいでちょうどいい。
5. 板バックテストで最も怖いのは「その価格、そもそも約定できたの？」問題
特にスキャルピングでは、チャート上の価格が見えたことと、その価格で自分の注文が通ることは別物だ。
limit orderならqueue positionがある。自分より前に何枚並んでいるか、相手注文がどれだけ来たか、途中で前の注文がcancelされたかで約定率が変わる。
2025年のManagement Science掲載研究は、ほぼ同時に送られたlimit orderでもランダムなlatencyでqueue順が変わり得ることを扱っている。 また暗号資産市場を使った近年の実証研究でも、観測した板と注文がmatching engineへ届くまでの時間差によって、見えていた流動性を実際には取れないfailure-to-fillが起き、HFTバックテストへ影響すると報告されている。
したがってバックテスター側で最低でも、
- fee
- spread
- slippage
- latency
- queue position
- partial fill
- cancel latency
- order rejection / failure-to-fill
- adverse selection
を扱えないなら、Astraの探索能力が上がるほど「美しい架空利益」を高速生産する危険も上がる。
AIが賢くなったのに、約定シミュレータが雑。これはフェラーリに段ボールのタイヤを付ける構成である。
6. 役割分担は「Opusが工場、Astraが研究室」
実運用では、次の分割が分かりやすい。
| 作業 | 主担当 |
|---|---|
| 板・約定データ取得 | Opus 5.5 |
| データ欠損・時刻同期・正規化 | Opus 5.5 |
| Parquet / DB / feature store整備 | Opus 5.5 |
| バックテスター・約定モデル実装 | Opus 5.5 |
| テスト・回帰防止・ログ整備 | Opus 5.5 |
| 目的変数と探索空間の準備 | Opus 5.5 + 人間 |
| 未知特徴量・条件の逆探索 | Astra |
| 仮説生成・クラスタ探索 | Astra |
| look-ahead / leakage検査 | Opus 5.5 |
| 過学習・regime依存の反証 | Opus 5.5 |
| 候補の再実装・大量再検証 | Opus 5.5 |
| 次の探索課題の切り出し | Opus 5.5 → Astra |
AnthropicはOpus 5.5を、コーディング、agent、computer use、複数アプリをまたぐ仕事のdaily driverとして明示している。
一方Astraは、OpenAI自身が複雑推論、コーディング、computer use、research向けの最上位モデルとしている。
能力が重なるからこそ、「できる方に全部やらせる」ではなく「高価な能力が必要な瞬間だけ呼ぶ」設計が効く。
7. OpusにChromeを触らせてAstraを操作する案は、試作ならアリ。本番化するならAPIがきれい
ブラウザ操作権限を持つOpus 5.5に、Astraのチャット画面を開かせ、
- Astraへ探索課題を送る
- 完了を確認する
- 結果を回収する
- 自分で反証する
- 足りなければ次の探索を送る
という「AIがAIを使う」構成は、試作品としてかなり分かりやすい。
Opus 5.5は公式にもcomputer useを主要用途として挙げられているため、適切なブラウザ/コンピュータ操作ハーネスがあれば、こうした多段作業の司令塔にできる。
ただし反復運用が固まったら、UI越しよりAPIの方が通常は扱いやすい。
ブラウザ経由には、
- ログイン切れ
- UI変更
- ボタン状態
- 生成中か停止中かの判定
- 出力取りこぼし
- 会話コンテキスト肥大
- ブラウザ自体の故障
が入る。
APIならexperiment ID、入力データのhash、prompt version、出力、評価結果を構造化して保存できる。
だから順番としては、
まずChromeで人間の作業をそのまま自動化して価値検証 → 探索ループが固まったらAPI化
が自然だ。
最初から宇宙船を作る必要はない。まず自転車にロケットを縛り付けて、本当に進みたい方向を確認すればいい。
8. 最終形は「Astraに考えさせる」のではなく「Astraが考える価値のある問題だけ渡す」
一番もったいない構成は、Astraへ巨大な生データと壊れたコードを丸投げし、
「なんか儲かる戦略探して」
である。
強い構成は逆。
Opus 5.5側で、
- データ品質を保証する
- 再現可能な実験環境を作る
- 探索APIを用意する
- 成功条件を定義する
- コストモデルを入れる
- leakage検査を自動化する
- 結果を保存する
- Astraが返した候補を独立反証する
ところまで済ませる。
その上でAstraには、「まだ人間が特徴量を思いついていない場所」を掘らせる。
すると計算資源の流れは、
Opus 5.5が土台を作る → Astraが未知を掘る → Opus 5.5が壊す → 生き残ったものだけ次へ進む
になる。
一人の天才AIへ全部任せるのではない。
研究者には研究をさせ、現場監督には現場を回させる。
AIエージェント時代になっても、結局いちばん効くのは組織設計だった。
