トレーディング企業がいかにして新しいAIモデルを即日リリースできるのか - ノヤン・トクゴゾウル（オプティバー）

하이라이트

• オプティバーは1日に1,000万件以上の取引を行い、変更がP&Lへ与える影響を数時間以内に確認する。

• 規制の厳しい業界かつ知的財産を重視するため、すべての活動をオンプレミス環境で実行し外部通信を抑制している。

• 新しいフロンティアモデルを価値があると判断したその日のうちに本番フローで活用できる仕組みを構築している。

• 初期セッションでコンテキストサイズが20万トークンに達した課題に対し、ツール検索機能の導入やナレッジベースの最適化を実施した。

• チームごとにアラートや上限を設定できる可視性と裁量権を与えた結果、コストを適切に抑制することに成功した。

타임라인

1. 00:00 - 03:00

   トレーディング事業における特有の制約とAI活用の文脈

   一般的なテック企業が数週間から数四半期かけてエンゲージメントや収益を測定するのに対し、トレーディング企業では日々の取引結果から迅速に影響が表面化する。機会損失の天井が極めて高いため、バイアス・フォー・アクション（行動指向）を持ちながら効果的かつ効率的に意思決定を下す必要がある。

   • オプティバーは自己資金で取引を行うマーケットメイカーであり、顧客を持たない。
   • 1日に1,000万件以上の取引と100万以上の銘柄価格算出を行い、ペタバイト単位のデータを処理する。
   • システムの変更によるP&Lへの影響を数時間以内に確認できる即時的なフィードバックループを持つ。
2. 03:00 - 07:05

   独自のAIプラットフォームの構築原則とアーキテクチャ

   プラットフォームはセルフサービス形式でありながら優れたデフォルトを提供し、混沌を防ぐ設計になっている。サードパーティ製モデルの利用時はゼロデータ保持契約を締結する。最下層のモデル群から推論ゲートウェイ、エージェントプラットフォーム、ウェブポータルに至るまで全レイヤーに責任を持つ構造をとっている。

   • 毎日生まれる新しいモデルやパラダイムに対応するため、モジュール式で測定可能なプラットフォームを構築している。
   • トレーダーの隣にエンジニアを配置するフォワード・デプロイを行い、現場の課題をプラットフォームに還元する。
   • 規制や知的財産の保護を重視し、原則としてオンプレミスのGPUやインフラで運用している。
3. 07:05 - 09:50

   新モデルの迅速なオンボーディングとメタハーネス層の運用

   社内の主要顧客であるトレーディングチームからベンチマークを収集し、外部の一般的なベンチマークとは異なる自社データ分布での性能を即座に把握する。24時間体制のサポート体制を敷き、モデルやクラウドプロバイダーの可用性に依存しない柔軟なルーティングを実現している。

   • 新しいフロンティアモデルは、ゴールデンセットによるベンチマークテストを経てその日のうちに本番フローへ組み込まれる。
   • すべてのモデル間のやり取りはログに記録され、自動的に評価システムへと移行される。
   • メタハーネス層を設けることで、チームが独自のハーネス設定を定義し、異なるハーネス間でポータビリティを確保している。
4. 09:50 - 15:55

   トークンコストの急増に対する最適化とコスト管理

   初期状態で20万トークンに達していたコンテキストに対し、専用CLIやナレッジベースの活用を進めた。オープンソースモデルの活用やプロンプトの動的ルーティングも試行している。また、特注セットアップの乱立を防ぐため、共同ドキュメント編集やマルチプレイヤー的な環境を備えた統合Webポータルを提供し、生産性を底上げしている。

   • Claude Codeや主要フロンティアモデルのリリースに伴い支出が急増したが、最適化によってコストを抑え込んだ。
   • MCPのツール検索機能の導入やコンテキストサイズの最適化により、単一セッション内のトークン消費量を削減した。
   • チームごとにコストの可視性を高め、自ら上限やアラートを設定できる裁量権を与えたことが支出削減に寄与した。
5. 15:55 - 23:13

   Q&A：メモリ戦略、既存ツールとの違い、評価の課題

   ナレッジベースやメモリ管理については既存の解決策に満足しておらず、グラフデータベースなどのハイブリッドアプローチの探索に時間を割いている。複数機能を1つのエージェントに詰め込むと複雑さが爆発するため、バージョン管理とマルチエージェントオーケストレーションによって測定可能な状態を維持している。

   • 既存の商用ツールは独自のインフラやカスタムマネージドエージェントの要件を満たさないため、自社構築を選択した。
   • エージェントの評価においてツール呼び出し時の世界の状態を再現するため、OTELロギングとスナップショットの仕組みを取り入れている。
   • 多機能な肥大化エージェントを避け、エージェント・ゲートウェイを介して役割ごとにスコープを絞る設計を推奨している。