最終更新: 2026年06月
MetaTrader 5のEAにLLMを組み込もうと調べ始めると、情報の断片が多くて全体像がつかみにくい。MQL5フォーラム、GitHub、各種ブログ記事——それぞれが部分的な実装例を出しているが、「どのアーキテクチャを選ぶべきか」「Claude APIとMT5の間の通信をどう設計するか」を体系的に解説したものは2026年現在でも少ない。
筆者は過去1年ほど、Claude APIをMT5と組み合わせた実験を繰り返してきた。その過程で見えてきたのは、「3つのアーキテクチャに収束する」という事実だ。本稿ではそれぞれの設計思想・実装手順・限界を整理する。
Claude APIとMT5を連携させる意義と注意点
まず前提を整理しておく。
LLMは「テキストとして与えられた情報を推論する」能力が高い。逆に言えば、「高頻度の数値計算」や「ミリ秒単位の判断」は本質的に不得意だ。API呼び出しのレイテンシーは1〜3秒が現実的な水準であり、スキャルピング系EAに組み込むのは構造的に無理がある。
筆者が有効だと考えるのは、LLMをフィルター・アドバイザーとして使う設計だ。具体的には以下の役割に限定する：
- ニュース・ファンダメンタルズの定性的解釈
- 相場レジームの分類（トレンド・レンジ・ボラティリティ拡張期）
- 既存テクニカルシグナルの「方向性バイアスの確認」
最終的な執行判断・損切幅・ロットサイズは従来のアルゴリズム層で制御する。LLMに執行権限を渡さないことが、リスク管理上の鉄則だ。
免責: 本稿はシステム設計の技術的解説であり、投資収益を保証するものではありません。FX取引には元本損失リスクがあります。実装・運用は自己責任で行ってください。
アーキテクチャ1：MQL5 WebRequest + Claude API直接呼び出し
最もシンプルな構成。MQL5のWebRequest関数からAnthropicのエンドポイント（https://api.anthropic.com/v1/messages）へ直接HTTPリクエストを送る。
設定手順
MetaTraderの設定:
- ツール → オプション → エキスパートアドバイザー
- 「WebRequestを許可するURLのリスト」に
https://api.anthropic.comを追加
MQL5側の実装骨格:
string claudeRequest(string prompt, string apiKey)
{
string headers = "Content-Type: application/json\r\n"
+ "x-api-key: " + apiKey + "\r\n"
+ "anthropic-version: 2023-06-01\r\n";
string body = "{\"model\":\"claude-opus-4-8\","
+ "\"max_tokens\":256,"
+ "\"messages\":[{\"role\":\"user\","
+ "\"content\":\"" + prompt + "\"}]}";
char post[], result[];
string resultHeaders;
StringToCharArray(body, post, 0, StringLen(body));
int res = WebRequest(
"POST",
"https://api.anthropic.com/v1/messages",
headers,
5000,
post,
result,
resultHeaders
);
if(res == 200)
return CharArrayToString(result);
return "";
}
送るプロンプトの設計が鍵になる。筆者の経験では、生の価格データをそのまま渡しても推論精度は上がらない。前処理として以下の特徴量に変換してから送信する：
現在のADX値: 32.4（強トレンド）
EMAクロス状態: 短期EMAが長期EMAを上回っている（強気バイアス）
直近の主要レジスタンス: 1.0850（現値から+42pips）
直近の米雇用統計: 予想を上回る強い結果（2日前）
質問: 現在のUSDJPYロング・エントリーに対するリスク評価を3段階（低・中・高）で回答してください。
この方式の限界
APIキーがMQL5コード内またはEAパラメータとして露出する。商用配布や複数環境での運用には向かない。また、Claudeはトレードシグナルの直接的な生成指示に対してアライメント上の制約から拒否応答を返すケースがある。「リスク評価」「相場環境の分類」といった問い方に変えると通過率が上がる。
アーキテクチャ2：ミドルウェア（Python/Flask）経由の分離設計
セキュリティと柔軟性を重視するなら、MT5とClaude APIの間にPythonサーバーを挟む設計が優れている。MQL5フォーラムのRatio X MLAI 2.0やPrime Quantum AIが採用している構造に近い。
全体の通信フロー
MT5 EA (MQL5)
↓ WebRequest (JSON) → ローカルPythonサーバー (Flask/FastAPI)
↓ Anthropic SDK
Claude API
↓ JSON応答
↑ シグナル・バイアス値 ← Pythonサーバー
Pythonサーバー側の実装（抜粋）
import anthropic
from flask import Flask, request, jsonify
app = Flask(__name__)
client = anthropic.Anthropic() # ANTHROPIC_API_KEY は環境変数から自動読み込み
@app.route("/analyze", methods=["POST"])
def analyze():
data = request.json
prompt = build_prompt(data) # 市場データをプロンプトに変換
message = client.messages.create(
model="claude-opus-4-8",
max_tokens=512,
thinking={"type": "adaptive"},
messages=[{"role": "user", "content": prompt}]
)
# 応答からバイアス方向とスコアを抽出
response_text = message.content[-1].text
return jsonify(parse_signal(response_text))
thinking={"type": "adaptive"} を有効にすると、Claude自身が推論ステップを内部的に実行してから回答を返す。相場環境の複合的な判断には有効だが、レイテンシーが増加するため用途に応じて切り替えを検討する。
ミドルウェア設計のメリット
- APIキーがMQL5コードに露出しない
- プロンプトの改善をPython側だけで完結できる（EAの再コンパイル不要）
- 複数のEAから同一サーバーを利用できる
VPS上でPythonサーバーを常時稼働させる運用が現実的。MT5もVPS上で動かしている場合はlocalhostで通信でき、外部ネットワーク通信のリスクを排除できる。
免責: ミドルウェアを外部サービスに公開する場合は認証機構が必須です。APIキーの漏洩は意図しない課金・取引リスクに直結します。
アーキテクチャ3：MCPサーバーを使ったエージェント統合
2025〜2026年にかけて実用段階に入ったのが、MCP（Model Context Protocol）経由でClaudeエージェントにMT5を直接操作させる構成だ。
Anthropicが策定したMCPは、LLMに外部ツールを「ツール定義」として提供するオープンスタンダード。MQL5フォーラムの記事（"How to connect AI agents to MetaTrader 5 via MCP"）では、FastMCPフレームワークを使って以下の14ツールをClaudeに公開する実装例が紹介されている：
get_account_info— 口座情報取得get_positions— 保有ポジション一覧place_order— 成行・指値注文の発注close_position— ポジション決済get_symbol_info— 通貨ペア情報- ほか9ツール
Pythonでのファストセットアップ
from mcp.server.fastmcp import FastMCP
import MetaTrader5 as mt5
mcp = FastMCP("MT5 Trading Server")
@mcp.tool()
def get_positions() -> list:
"""現在の保有ポジション一覧を取得する"""
mt5.initialize()
positions = mt5.positions_get()
return [p._asdict() for p in positions] if positions else []
@mcp.tool(annotations={"destructiveHint": True})
def close_position(ticket: int) -> dict:
"""指定チケットのポジションをクローズする（破壊的操作）"""
# 実装省略
pass
destructiveHint アノテーションを付けた破壊的ツール（注文・決済）に対しては、Claude側でも事前確認を促すシステムプロンプトを設定しておくことを強く推奨する。
MCPアーキテクチャの重要な注意点
MT5 Python APIはWindowsのみ対応しており、MT5ターミナルと同一マシン上での実行が必要。シングルスレッドの制約もあるため、並列ツール呼び出しが発生すると問題になりやすい。本番運用前にデモ口座で徹底検証することが必須だ。
筆者はこのアーキテクチャを現時点では「研究・プロトタイプ段階」と位置づけている。Claudeに発注権限を持たせることのリスクは、技術的問題よりもプロンプト・エンジニアリングの品質に依存する部分が大きく、十分なフェイルセーフ機構なしの本番運用は勧めない。
Claudeと会話しながらインジケータが作れるhedgrow-fxはこちら。
3つのアーキテクチャの比較まとめ
| 項目 | 直接呼び出し | ミドルウェア | MCPエージェント | |---|---|---|---| | 実装難易度 | 低 | 中 | 高 | | APIキー安全性 | 低 | 高 | 高 | | レイテンシー | 中（1〜3秒） | 中（1〜4秒） | 高（3〜10秒+） | | 用途 | 個人・検証用 | 安定運用 | 研究・実験 | | LLMの役割 | アドバイザー | フィルター | 意思決定エージェント |
実装時の共通注意事項
1. LLMに執行権限を渡さない
どのアーキテクチャを選んでも、ロット計算・損切幅・最大ポジション数はアルゴリズム層で固く制御する。LLMは「方向性バイアス」の参考情報を提供するに留める。
2. 高時間軸フィルターとして使う
1時間足・日足レベルのレジーム判断に限定すれば、API呼び出しコストとレイテンシーの問題は実用範囲に収まる。
3. バックテストでの検証は慎重に
APIコール履歴を記録し、過去のシグナルと実際の市場結果を照合する「疑似バックテスト」は可能だが、APIの応答がリアルタイムでどう変わるかは事前に特定できない。統計的評価の信頼性は従来のアルゴリズムバックテストより低い。
よくある質問（FAQ）
Q: Claude APIとGPT-4、どちらをMT5連携に使うべきですか？
A: 筆者の検証では、コード生成サポートはClaudeが優れているケースが多い。ただし売買シグナルの直接生成指示に対するアライメント制約はClaudeの方が強い傾向があるため、「相場環境の分類」や「リスク評価」という問い方に変えると応答が安定する。用途に応じてモデルを選択することを勧める。
Q: APIコストはどれくらいかかりますか？
A: Claude Opus 4.8は入力$5/100万トークン・出力$25/100万トークン。1回の呼び出しで1,000〜2,000トークン程度を使用するとして、15分に1回呼び出した場合の月額コストは数ドル〜数十ドル程度。ただしmax_tokensの設定と呼び出し頻度の最適化が重要。
Q: デモ口座でのテストで十分ですか？
A: LLMのAPIレスポンスは非決定的であり、同じプロンプトでも毎回異なる応答が返る。デモ口座でのテストは必須だが、それだけで本番相当の品質保証にはならない。少なくとも3ヶ月以上のフォワードテスト期間を設けることを推奨する。
Q: MQL5のWebRequestで直接呼び出す際、AIが応答を拒否することがあります。どう対処すればいいですか？
A: 「〜のシグナルを出せ」という命令形を避け、「〜の環境を低・中・高リスクで分類してください」という評価形式に変えると拒否率が下がる。また、プロンプト冒頭に「FXシステム開発者向けの市場環境分析ツールです」という文脈を明示することも有効。
Claudeと会話しながらインジケータが作れるhedgrow-fxはこちら。
免責事項: 本記事はFXシステム開発の技術的情報提供を目的としています。記事内の実装例・パフォーマンス評価はいかなる投資成果も保証するものではありません。FX取引は元本損失リスクを伴い、すべての損益は投資家自身の責任に帰します。
