「GPT-4に相場を見せて、Buy/Sellの指示を出させる」
そんな夢のような自動トレードシステムを想像して、プロンプトを書き始めた人がいるかもしれない。結論から言おう。それは極めて危険な、ただのギャンブルだ。
LLM（大規模言語モデル）は驚異的な推論能力を持っているが、金融トレーディング、特にボラティリティの激しいBTC市場において「意思決定の全権」を握らせるには、致命的な弱点が多すぎる。
本記事では、LLMに判断を丸投げするのではなく、あえて役割を分離した「AIハイブリッド型（Hybrid）」の設計思想について整理していく。
何を作るか：LLMを「トレーダー」ではなく「アナリスト」として再定義する
今回構築を目指しているのは、LLMが直接注文を出すシステムではない。
従来の「LLM単体による判断型」から、「LLMによる仮説生成 ＋ ルールベースによる執行」という、役割分担されたハイブリッド・アーキテクチャへの転換だ。
- 旧： 市場データ → LLM → 売買指示（Buy/Sell）
- 新： 市場データ ＋ 文脈情報 → LLM（仮説生成） → 戦略エンジン（検証・フィルタリング） → リスク管理モジュール → 注文執行
LLMには「相場の文脈を読み解く」という、人間（アナリスト）に近い役割を与え、実際の「ボタンを押す」作業は、決定論的なプログラムに任せる。これが設計の核となる。
構成・実装ポイント：分離された3つのレイヤー
このシステムは、大きく分けて以下の3つのレイヤーで構成する。
1. Context Layer (LLM / Analyst)
ここがLLMの主戦場だ。価格データ（OHLCV）だけでなく、ニュース、SNSのセンチメント、オンチェーンデータの変化といった「非構造化データ」を処理させる。
- 役割: 「現在の市場は、ETF流入に伴う強気相場である」といった仮説（Hypothesis）を生成する。
- 出力形式: 自由な文章ではなく、後続のエンジンがパース可能なJSON形式で出力させる。
2. Decision Engine (Rule-based / Strategy)
LLMが生成した「仮説」を、数学的な裏付けがあるテクニカル指標やルールで検証するレイヤーだ。
- 役割: LLMの「強気」という判断に対し、「RSIは買われすぎを示していないか？」「ボリンジャーバンドの境界にいないか？」といった定量的チェックを行う。
- 目的: LLMの「勘（推論）」を、決定論的な「ロジック」でフィルタリングする。
3. Risk Management Layer (The Guardrail)
ここにはLLMの介入を一切許さない。
- 役割: ポジションサイジング、ストップロス（逆指値）の設定、最大ドローダウン制限の強制執行。
- 重要性: LLMがどれほど強気なシナリオを描こうとも、資金管理ルールに反する注文はプログラムレベルで遮断する。
ハマりどころ：LLM特有の「不確実性」への対処
設計を進める上で、避けて通れない壁がいくつかある。
- 非決定論性の罠: 同じ入力に対しても、LLMは毎回異なる回答を返す可能性がある。これを許容すると、バックテストと実運用で全く挙動が異なる事態を招く。「温度感（Temperature）」の設定や、出力フォーマットの厳格なバリデーションが必須だ。
- ハルシネーション（幻覚）による数値ミス: LLMは「価格が〇〇ドルになったら」といった具体的な数値を扱うのが苦手だ。LLMに計算をさせず、あくまで「傾向」や「イベントの有無」を判断させることに徹させる必要がある。
- レイテンシ（遅延）問題: APIのレスポンス待ちをしている間に、相場は数パーセント動いている。短期のスキャルピングには不向きであり、スイング〜デイ・トレード向けの設計に限定すべきだ。
次にやること
まずは、LLMが出力する「仮説」を構造化するためのスキーマ定義に着手する。
具体的には、`{“sentiment”: “bullish”, “reasoning”: “…”, “target_volatility”: “high”}` といった、後続のルールエンジンが解釈しやすいJSONフォーマットのプロンプトエンジニアリングだ。
その後、このJSONをトリガーにして、既存のテクニカル指標（MACDやボリンジャーバンド）と照合するロジックの実装へと進む。
注意点
LLMは「もっともらしい嘘」をつく天才である。
システム構築においては、「AIが何を言ったか」よりも「AIの判断を、いかにして数学的な制約の中に閉じ込めるか」という、ガードレールの設計にこそリソースを割くべきだ。
※この記事は投資助言ではなく、システム構築・検証ログです。
