IBKR 移行分析 — Client Portal API + IBeam + AWS 完結アーキテクチャ¶

作成日: 2026-04-12 対象: LT_RC (Saxo LIVE 実資金トレード) のスリッページ検証と移行可否判断関連: スリッページ検証戦略 / MM 気配の仕組み

1. 背景 — なぜ IBKR を検討するのか¶

LT_RC は 2026-03 末以降、Saxo multileg API で credit spread の combo bid が頻繁に 0 を返し、mid fallback 経路で 46 件試行 / submit 0 / fill 0 の dead-letter 状態に陥った。live_quote_collector で 5,393 件の snapshot を収集した結果:

Polygon mid vs Saxo combo bid の CR 乖離平均 = 0.269
Saxo Ticket #16633 は COB routing の質問 (Q3) に未回答のまま Japan 窓口経由で再エスカレーション中 (2026-04-10)

ここで問題を 2 つに切り分ける必要がある:

仮説	検証に必要なデータ
A: Saxo 独自 pricing が NBBO から乖離している (broker 固有問題)	別 broker の combo quote との比較
B: Credit spread の combo bid は市場全体として薄い (市場構造問題)	NBBO 基準の独立ソース

どちらであっても、IBKR を参照実装として横に置く ことで決着がつく。

2. IBKR Client Portal Web API の実態¶

2.1 "TWS 不要" は本当、"Java 不要" は嘘¶

コンポーネント	必要	説明
TWS (GUI アプリ)	❌	Trader Workstation のデスクトップ取引画面は不要
Client Portal Gateway (JAR)	✅	REST エンドポイント `localhost:5000/v1/api/` を公開する軽量 Java プロセス
Java Runtime	✅	Gateway JAR が要求
API クライアント側	❌	Rust / Python / Node 任意

つまり TWS/IB Gateway デスクトップアプリが要らない というだけで、Java ランタイム依存は残る。Java を完全に外す唯一の手段は OAuth 1.0a / 2.0 だが、retail 向けには原則降りてこない (third-party vendor approval が必要)。

2.2 IBeam で Java 依存を 1 コンテナに閉じ込める¶

Voyz/ibeam は CP Gateway JAR + Chrome headless + Selenium auto-login を 1 Docker image に包んだ OSS。

起動時に IBKR ログインページへ credentials を自動注入
Session が切れたら自動で再ログイン
常駐プロセスとして port 5000 を公開

AEGIS 側の Rust ランタイムは IBeam コンテナに対して REST で叩くだけで済み、Java を意識する必要がゼロになる。

3. AWS 完結アーキテクチャ提案¶

┌─────────────────────────────────────────────────────┐
│  AWS us-east-1 VPC                                  │
│                                                     │
│  ┌──────────────────────┐   Service Discovery       │
│  │ aegis-ibkr-gateway   │   ibkr-gw.aegis.local     │
│  │ (Fargate Service)    │──────┐                    │
│  │                      │      │                    │
│  │ IBeam image          │      │                    │
│  │  ├─ CP Gateway JAR   │      ▼                    │
│  │  ├─ Chrome headless  │   ┌──────────────────┐    │
│  │  └─ Auto re-auth     │   │ aegis-lt-runtime │    │
│  │                      │   │ (Fargate Task)   │    │
│  │ :5000                │◄──│                  │    │
│  │                      │   │ Rust LT runtime  │    │
│  │ always-on (0.25vCPU  │   │ EventBridge 起動 │    │
│  │  / 0.5GB, ~$6.5/mo)  │   └──────────────────┘    │
│  └──────────────────────┘                           │
│           │                                         │
│           ▼                                         │
│  ┌──────────────────────┐                           │
│  │ Secrets Manager      │                           │
│  │  ├─ IBKR_USERNAME    │                           │
│  │  ├─ IBKR_PASSWORD    │                           │
│  │  └─ IBKR_TOTP_SECRET │                           │
│  └──────────────────────┘                           │
└─────────────────────────────────────────────────────┘

aegis-ibkr-gateway: Fargate Service, desired=1, always-on on-demand (Spot 禁止)
aegis-lt-runtime: EventBridge で市場時間のみ起動される ephemeral task
Service Discovery: AWS Cloud Map で ibkr-gw.aegis.local を内部 DNS に
Secrets: KMS 暗号化 + IAM 最小権限。IBKR Pro 口座で TOTP 2FA 必須

4. 現実的な落とし穴 4 つ¶

設計前に認識すべき制約

2FA 方式は TOTP 必須 IBKey モバイルプッシュ通知だと毎回スマホ承認が要り、AWS 上の無人運用は破綻する。IBKR 口座設定で TOTP (Google Authenticator 互換) を明示的に有効化しておく必要がある。
Session expiry は避けられない CP Gateway は /tickle で延命しても ~24 時間で強制再認証が入る。IBeam が自動で再ログインするが、その瞬間 API は数秒〜数十秒落ちる。Rust 側の ordering layer は retry / idempotent 前提で設計する必要がある。
Fargate platform upgrade / task 入れ替え Spot interruption で session ゼロから復旧する窓が生まれる。On-demand Fargate を採用し Service desired=1 にしておけば自動再起動される。月額 $6.5 の追加コストを払う価値はある。
Credentials を平文で Secrets Manager に格納する IBeam の設計上、username / password / TOTP secret をすべて保存する必要がある。KMS + IAM で最小権限化した上で、監査ログを有効化する。IBKR Pro アカウント以外では headless 自動ログインは TOS 上グレー。

5. 資金ゼロで実データを取る 3 つの手段¶

現時点で IBKR 口座に投入可能な資金は限定的なので、「実口座・実 API を使った virtual trading」で slippage 観測データを積む必要がある。

手段	capital 要求	得られるデータ	実装負荷
whatIf = true	ゼロ	margin impact + expected fill price (注文を投げずに preview)	小
Paper Trading 口座	ゼロ	実市場データ + 仮想フィル、$1M 仮想資金	中
Market data snapshot	ゼロ	bid/ask/last/mid のみ (注文概念なし)	極小

推奨: whatIf + Paper 併用

quote / combo pricing 比較だけなら whatIf + snapshot で十分
"実際にフィルされた価格" の分布統計 が欲しいなら Paper 口座を並行稼働
Paper 口座は live 口座保有者に無料発行され、market data subscription も共有される

6. なぜ IBKR の方がスリッページ観測に有利か¶

観点	Saxo (現)	IBKR
Quote 基準	独自 IB pricing (market maker 経由)	NBBO 直参照 (consolidated feed)
Combo pricing	multileg API、combo bid 0 頻発	BAG order + `conidex`、Smart routing で leg-wise best-ex
Order preview	❌ 実注文しないと価格不明	✅ whatIf で margin + fill 推定を事前取得
公開 execution 統計	❌ 非公開	✅ SEC Rule 605/606 月次レポートで execution quality を開示
深さ	L1 相当	L2 (depth book) 取得可能
Atomic multileg fill	✅ 保証される	⚠️ Smart routing では leg 分離の可能性。direct routing (CBOE COB 等) で atomic 可能だが fill rate は落ちる

IBKR の Smart router は leg ごとに別 exchange (BOX, CBOE, MIAX...) へ振って best-ex を狙う。credit spread の fill 価格は IBKR の方が良いはず — ただし atomic fill と引き換え。LT_RC の銘柄群 (SPY / QQQ / IWM / large cap) なら Smart routing で流動性上の問題はない。

7. 3-Track Shadow 実験設計¶

        Polygon provider (reference NBBO mid)
                     │
         ┌───────────┼───────────┐
         ▼           ▼           ▼
    ┌─────────┐ ┌─────────┐ ┌─────────┐
    │  Saxo   │ │  IBKR   │ │  IBKR   │
    │  LIVE   │ │ whatIf  │ │  Paper  │
    │ (現行)  │ │ (新規)  │ │ (新規)  │
    │         │ │         │ │         │
    │ 実約定  │ │ preview │ │ 仮想    │
    └─────────┘ └─────────┘ └─────────┘
         │           │           │
         ▼           ▼           ▼
    quote_samples/live_spread_quotes.jsonl (拡張)
         │
         ▼
    diff 分析:
      Polygon_mid vs Saxo_combo_bid vs IBKR_combo_bid vs IBKR_paper_fill

5 営業日 parity 観測で 3 つのシナリオを判別可能:

パターン	解釈	アクション
IBKR ≈ Polygon、Saxo 乖離 30%	Saxo 独自 pricing が原因	IBKR 本格移行を正当化、Ticket 16633 に決定打データ添付
IBKR ≈ Saxo ≈ Polygon から 30% 乖離	市場全体の構造問題	broker 変えても無駄、execution model calibration で解決
IBKR ≈ Polygon、Paper fill 乖離	Smart routing は quote 良いが fill 悪い	direct routing (CBOE COB) を試す、broker 選定は慎重に

8. 意思決定マトリクス¶

項目	Saxo (現行維持)	IBKR + IBeam (移行)	ハイブリッド併走
Gateway 場所	Synology (Token Keeper)	AWS Fargate	AWS + Synology
月額運用コスト	既存インフラ内	~$10-15	~$15-20
Credit spread 実装	multileg API (現行悩み中)	BAG order + conidex (未検証)	両方
Slippage 観測精度	Polygon 経由の推定のみ	NBBO 直参照 + whatIf	最高 (比較可能)
切替コスト	ゼロ	broker adapter + IBeam + TOTP 設定	同左
Ticket 16633 への影響	回答待ち継続	データ付きで再エスカレ	データ付きで再エスカレ
LIVE 口座切替	不要	IBKR 本格運用 (資金移動)	当面不要

推奨: ハイブリッド併走 を 4-6 週間走らせた上で決定する。Saxo LIVE を止めずに IBKR shadow を追加するだけなので、実損ゼロでデータが溜まる。

9. 次のアクション¶

IBKR 口座で TOTP 2FA 有効化
IBKR Paper Trading 口座申請 (live 口座保有者は無料、5 分)
IBeam ローカル Docker 動作確認 (Mac で dry run、Fargate 移行前の sanity check)
aegis-ibkr-gateway ECS Task Definition + Fargate Service を IaC 化
Rust 側に broker::ibkr::adapter を実装 (BrokerProtocol trait 準拠、Saxo と同型)
quote_collector を IBKR whatIf + snapshot 対応に拡張
5 営業日 parity 観測 → Saxo Ticket #16633 再エスカレ材料として活用
parity 結果次第で Saxo 継続 / IBKR 本格移行 / 併走継続を判断