最終更新: 2026年06月
2026年、FX取引システムの設計は新しい段階に入った。
従来の自動売買(EA)は「if-then ロジック」——特定の条件が満たされたらエントリーする、という事前にプログラムされた規則で動く。これに対してAIエージェント型システムは、状況を「推論」して行動を選ぶ。テクニカルシグナルの解釈、ニュースの文脈理解、リスク評価の統合——これらを連鎖させてトレード判断を生成する。
ただし、先に言っておく必要がある。Goldman Sachsや JPMorganが本番で動かしているシステムと、個人が試みるシステムの間には、インフラ・データ品質・レイテンシ管理において大きな差がある。本稿は「個人・小規模開発者が現実的に構築できるAIエージェントFXシステム」を対象にする。
AIエージェントとは何か:従来のEAとの違い
まず定義を整理する。
従来のEA(ルールベース):
if EMA20 > EMA50 and RSI < 70:
enter_long()
条件が数値で定義されており、実行は決定的(同じ入力 = 同じ出力)。
AIエージェント:
データ → LLMによる状況推論 → アクションの選択 → 実行
入力を「解釈」し、文脈に応じてアクションを変える。同じ市場データでも異なる推論が生じうる(非決定的)。
この非決定性が最大の違いだ。AIエージェントは「柔軟で文脈を理解する」一方、「バックテストの信頼性が低い」「再現性が保証されない」という根本的な課題を持つ。
免責: AIエージェントを使ったFX取引は元本損失リスクを伴います。本記事はシステム設計の技術情報提供が目的であり、投資収益を保証するものではありません。
マルチエージェントアーキテクチャ:TradingAgentsの設計思想
2026年に注目されたUCLA+MITのTradingAgentsフレームワークは、7つの専門エージェントが役割分担する設計だ。
| エージェント | 役割 | |---|---| | ファンダメンタルズアナリスト | 経済指標・政策の解釈 | | センチメントアナリスト | ニュース・SNS感情分析 | | テクニカルアナリスト | チャートパターン・指標の解釈 | | バルアナリスト | 強気シナリオの構築 | | ベアアナリスト | 弱気シナリオの構築 | | リスクマネージャー | ポジションサイジング・損切設定 | | ファンドマネージャー | 最終的な取引決定(統合・承認) |
このフレームワークのバックテスト(2024年6〜11月、AAPL株)では26.62%のリターンを記録したと報告された(バイアンドホールドは-5.23%)。ただし以下の点に注意が必要だ:
- バックテスト期間が約6ヶ月と短い
- 取引1回あたり11回以上のLLM呼び出しが発生(コスト高)
- 実際のライブ取引での検証は未実施
- 株式市場での結果であり、FX市場への転用は別途検証が必要
この設計思想——「議論し合う複数エージェントが合意してから動く」——は、個人が実装する場合でもスケールダウンして取り入れられる。
個人が構築できる最小構成:3エージェント設計
フルのTradingAgentsは個人には過剰だ。筆者が現実的と考える最小構成を提案する。
[Agent 1: 市場環境分類エージェント]
入力: テクニカルデータ(EMA/RSI/ADX等)+ 直近の主要ファンダメンタルズ
出力: 相場環境の分類(トレンド/レンジ/警戒)+ スコア
↓ 環境が"トレンド"の場合のみ次へ進む
[Agent 2: シグナル評価エージェント]
入力: 環境スコア + 具体的な売買シグナル(テクニカル条件の充足状況)
出力: エントリーの妥当性評価(0〜100点) + 否定的な根拠
↓ 評価スコアが閾値(例: 70点)以上の場合のみ次へ進む
[Agent 3: リスク管理エージェント]
入力: 評価スコア + 口座残高 + 既存ポジション
出力: 推奨ロットサイズ + ストップロス位置
↓ 承認された場合のみ実行層へ
[実行層(EA): MT5]
入力: Agent 3の出力(ロット・SL・TP)
出力: 実際の注文
「判断はエージェント、実行はEA」 という分離が安全設計の核心だ。AIが直接取引を実行するのではなく、AIが判断したパラメータをEAに渡してEAが実行する。エラー時のフォールバックも実装しやすい。
Pythonによる実装:LangGraph + Claude API
LangGraphはLangChainベースのエージェントワークフロー管理フレームワークで、状態管理と条件分岐が扱いやすい。
import anthropic
from typing import TypedDict, Literal
from langgraph.graph import StateGraph, END
client = anthropic.Anthropic()
# 共有状態の定義
class TradingState(TypedDict):
market_data: dict
environment: str
environment_score: float
signal_score: float
lot_size: float
stop_loss: float
decision: Literal["execute", "skip", "error"]
# Agent 1: 市場環境分類
def classify_market_environment(state: TradingState) -> TradingState:
data = state["market_data"]
prompt = f"""<market_data>
EMA20: {data['ema20']}, EMA50: {data['ema50']}
RSI14: {data['rsi']}, ADX14: {data['adx']}
直近指標: {data.get('news', 'なし')}
</market_data>
JSON形式のみで回答:
{{"environment": "trend/range/caution", "score": 0-100の整数, "reason": "30字以内"}}"""
message = client.messages.create(
model="claude-opus-4-8",
max_tokens=128,
messages=[{"role": "user", "content": prompt}]
)
import json
result = json.loads(message.content[0].text)
state["environment"] = result["environment"]
state["environment_score"] = result["score"]
return state
# 条件分岐:環境が適切かチェック
def should_continue_after_environment(state: TradingState) -> str:
if state["environment"] == "trend" and state["environment_score"] >= 60:
return "evaluate_signal"
return "skip_trade"
# スキップ処理
def skip_trade(state: TradingState) -> TradingState:
state["decision"] = "skip"
return state
# ワークフロー構築
workflow = StateGraph(TradingState)
workflow.add_node("classify_environment", classify_market_environment)
workflow.add_node("skip_trade", skip_trade)
# ... (シグナル評価・リスク管理エージェントを同様に追加)
workflow.set_entry_point("classify_environment")
workflow.add_conditional_edges(
"classify_environment",
should_continue_after_environment,
{"evaluate_signal": "evaluate_signal", "skip_trade": "skip_trade"}
)
設計上の重要な注意点
注意点1:コストと呼び出し頻度のバランス
Claude Opus 4.8は入力$5/100万トークン。3エージェント構成で1回の判断に約2,000〜4,000トークン使用するとして、15分に1回判断する場合の月間コストは数十〜百ドル程度。コスト管理のため:
- 環境評価(Agent 1)は15分〜1時間足レベルでの判断に留める
- 明らかに環境が適切でない場合(レンジ相場など)はAgent 2・3を呼ばない条件分岐を入れる
- 軽量な初期フィルターをアルゴリズムで実装し、Claudeへの呼び出しを最小化する
注意点2:エラーハンドリングの徹底
LLMの応答は常に期待通りのフォーマットで返るとは限らない。
def safe_parse_json(response_text: str, fallback: dict) -> dict:
"""LLM応答のJSONパース失敗時にフォールバック値を返す"""
try:
import json
return json.loads(response_text)
except json.JSONDecodeError:
# ログに記録してフォールバック
print(f"JSON parse failed: {response_text[:100]}")
return fallback
# 使用例: パース失敗時は"skip"判断にフォールバック
result = safe_parse_json(
message.content[0].text,
{"environment": "caution", "score": 0, "reason": "parse_error"}
)
注意点3:非決定性への対処
同じ入力でも毎回異なる出力が返ることがある。重要な判断には同じプロンプトを複数回送って多数決を取る「コンセンサスパターン」が有効だが、コストが増加する。本番運用前にこのトレードオフを設計で解決しておく。
Claudeと会話しながらインジケータが作れるhedgrow-fxはこちら。
フォワードテスト:AIエージェントシステムの評価方法
AIエージェントシステムのバックテストは限定的な信頼性しかない(LLMの非決定性のため)。評価の主軸はフォワードテストにする必要がある。
推奨フォワードテスト期間: 6ヶ月以上(複数の市場局面を含む)
記録すべき項目:
- 各判断のエージェント出力ログ(何を理由に判断したか)
- 判断から実行までの時間(レイテンシ)
- APIエラー・パース失敗の発生頻度
- スキップした取引の事後評価(スキップして正解だったか)
「取引の損益」だけでなく「エージェントの判断プロセスの品質」を評価することが、改善につながる。
よくある質問(FAQ)
Q: LangGraphとCrewAIのどちらを使うべきですか?
A: LangGraphは状態管理と条件分岐の制御が細かくできるため、取引システムのように「条件を満たさない場合はスキップ」という設計に向いている。CrewAIはエージェント間の対話を重視した設計で、TradingAgentsのような議論型システムに向く。小規模から始めるならLangGraphが学習コストが低い。
Q: デモ口座でのフォワードテストはどれくらいの期間が必要ですか?
A: AIエージェントシステムは従来のEAより変動要因が多い(LLM応答の非決定性、APIコスト変動等)。最低6ヶ月、できれば12ヶ月のデモ口座テストを推奨する。
Q: 取引判断をClaudeに「決定させる」のは危険ですか?
A: 危険というより、「最終決定前に複数の安全ネット」を設けるべきだ。本記事のアーキテクチャでは、LLMは「判断のインプット」を提供し、最終的な実行は閾値チェックとリスク管理層を通過した後にEAが行う設計にしている。
Q: ヘッジロウFXとのような仕組みでAIエージェントと連携できますか?
A: Claudeベースのシステムとの連携は技術的に可能。ただし実装の安全性確認と責任の所在は開発者自身が担う。
Claudeと会話しながらインジケータが作れるhedgrow-fxはこちら。
免責事項: 本記事はAIエージェント技術の設計情報提供を目的としています。記載のアーキテクチャ・コードはいかなる投資収益も保証しません。TradingAgentsのバックテスト結果は過去の特定期間の実績であり、将来のパフォーマンスを保証しません。FX取引は元本損失リスクを伴い、損益はすべて投資家自身の責任に帰します。
