TradingAgents: オープンソースLLM取引フレームワーク

ほとんどのマルチエージェントLLMフレームワークは、期待ほど実装が具体的ではありません。その中で、TradingAgents は例外的に、役割分担・議論・意思決定・監査ログまでを実装した参照例です。Tauric Research によって arXiv論文 と共にオープンソース化され、v0.2.4では、実際の調査デスクに近いワークフローをLLMエージェントで構成しています。

今すぐApidogを試す

この記事では、TradingAgentsの構成、v0.2.4の変更点、LangGraph/CrewAIとの違い、そして Apidog を使ってマーケットデータAPIとLLMプロバイダー層をどうテストするかを実装寄りに整理します。エージェント契約の設計を深掘りする場合は、APIチーム向け agents.mdガイド も参考になります。

TL;DR

• TradingAgentsは、Tauric Research製のマルチエージェントLLMトレーディングフレームワークです。
• arXiv 2412.20138 として公開され、現在の対象バージョンはv0.2.4です。
• ファンダメンタルズ、センチメント、ニュース、テクニカル、ブル/ベアリサーチ、トレーダー、リスク管理委員会に役割を分割します。
• v0.2.4では、構造化出力、LangGraphチェックポイント再開、SQLiteの意思決定ログ、DeepSeek/Qwen/GLM/Azure OpenAI対応が追加されています。
• OpenAI互換エンドポイントを使えるため、ホスト型・ローカル・自己ホスト型モデルを切り替えられます。
• Apidog を使うと、マーケットデータAPIのモック、LLMリクエストの記録、レスポンス差分、JSONアサーションをCIに組み込めます。
• 実資金で使う前に、Apidogをダウンロード してAPI層を検証してください。

TradingAgentsとは何か

TradingAgentsは、トレーディング判断の流れを専門エージェントに分解するPythonパッケージ兼CLIです。

各エージェントは以下を持ちます。

• 明確な役割
• 専用プロンプト
• 使用可能なツールセット
• LangGraph上の実行ノード
• 下流エージェントに渡すレポート

基本的な流れは次の通りです。

1. マーケットデータを収集する
2. 複数アナリストが独立して分析する
3. ブル/ベアのリサーチ担当者が議論する
4. リサーチマネージャーが統合する
5. トレーダーが取引計画を作る
6. リスク管理委員会が検証する
7. 最終決定をログに保存する

READMEにも明記されている通り、これは投資助言ではなく研究コードです。目的は「LLMエージェントの協調が意思決定にどう影響するか」を調べることであり、そのまま本番トレーディングボットとして使うことではありません。

アーキテクチャ上のポイント

TradingAgentsで参考になるのは、役割分離がかなり明確な点です。

役割	主な責務
ファンダメンタルズアナリスト	企業財務を評価
センチメントアナリスト	ソーシャルメディアや市場感情を評価
ニュースアナリスト	ニュースやマクロ情報を確認
テクニカルアナリスト	MACD、RSIなどを計算
ブルリサーチ担当	強気シナリオを提示
ベアリサーチ担当	弱気シナリオを提示
リサーチマネージャー	議論を統合
トレーダー	取引計画を作成
リスク管理委員会	制約やリスクを検証
ポートフォリオマネージャー	承認または差し戻し

これはトレーディング以外のエージェント設計にも使えるパターンです。

• 専門エージェント
• 議論フェーズ
• 統合フェーズ
• 構造化された意思決定
• 永続ログ
• 検証ステップ

複雑なエージェントワークフローを設計するなら、TradingAgentsは読みやすい参照実装です。

v0.2.4で追加されたもの

v0.2.4は、本番に近い検証をしたい開発者にとって重要なリリースです。

構造化出力エージェント

リサーチマネージャー、トレーダー、ポートフォリオマネージャーが、OpenAI Responses APIまたはAnthropicのツール利用チャネルを通じて構造化出力を返せるようになりました。

以前のように自由形式テキストをパースするのではなく、型付きJSONとして扱えるため、下流処理が安定します。

例として、テストでは次のような項目をアサートできます。

{
  "decision": "BUY",
  "confidence": 0.72,
  "rationale": "...",
  "risk_notes": ["..."]
}

LangGraphチェックポイントからの再開

長時間実行されるエージェント処理を、保存済みチェックポイントから再開できます。

これは以下のような失敗に有効です。

• マーケットデータAPIのレート制限
• LLMプロバイダーの429エラー
• ネットワークタイムアウト
• 長い議論フェーズ中の中断

最初から再実行せずに済むため、コストと時間を削減できます。

永続的な意思決定ログ

トレーダーの各決定は、理由・入力・タイムスタンプと共にSQLiteに記録されます。

このログは次の用途に使えます。

• 後続レビュー
• プロバイダー比較
• モデル変更時の回帰確認
• バックテスト用の分析
• 監査証跡

マルチプロバイダー対応

v0.2.4では、既存のOpenAI、Anthropic、Gemini、Grokに加えて、DeepSeek、Qwen、GLM、Azure OpenAIが追加されています。

推論コストを下げたい場合は、OpenAI互換エンドポイントを介してDeepSeek V4 に切り替えられます。長いコンテキストやビジョンが必要な場合は、Geminiを検討できます。

DockerサポートとWindows UTF-8修正

Dockerfileが追加され、v0.2.3のWindowsパスエンコーディング問題も修正されています。

地味ですが、CIやチーム開発では重要です。

TradingAgentsの実行フロー

1回の完全な実行は、概ね次のように進みます。

1. CLIがティッカーと日付範囲を受け取る
2. 4人のアナリストが個別にデータを取得する
3. 各アナリストがレポートを作成する
4. ブルリサーチ担当が強気シナリオを書く
5. ベアリサーチ担当が弱気シナリオを書く
6. 両者が議論する
7. リサーチマネージャーが推奨事項を統合する
8. トレーダーが取引計画を作る
9. リスク管理エージェントが計画を検証する
10. ポートフォリオマネージャーが承認または差し戻す
11. 最終決定がSQLiteログに保存される

LLMコストが特に重いのは、以下の2箇所です。

• ブル/ベアのリサーチ議論
• リスク管理委員会の議論

小規模な7Bモデルでは、議論が反復的になったり、結論に収束しないことがあります。DeepSeek V4思考モード、GPT-5.5、Claude 4.5のような推論品質の高いモデルでは、より構造化されたやり取りになりやすいです。

なぜAPIツールでLLM層をテストするのか

TradingAgentsを実行すると、主に2つのAPI層が失敗します。

1. マーケットデータAPI
2. LLMプロバイダーAPI

対象となるマーケットデータAPIには、Yahoo Finance、FinnHub、Polygon、OpenBBなどがあります。

マーケットデータAPIでは、次のような問題が起こります。

• 無料ティアのレート制限が安定しない
• フィールド名が変わる
• ドキュメントにないフィールドが増える
• ベンダーごとに取引日の境界が異なる
• 一部レスポンスだけ欠損する

例として、regularMarketTime が regular_market_time に変わるだけで、アナリストエージェントの入力が壊れる可能性があります。

LLMプロバイダー側にも別の問題があります。

• DeepSeek V4の思考モードでコストが増える
• OpenAI Responses APIのレスポンス形式に癖がある
• Anthropicのツール利用がコンテンツブロックを返す
• プロバイダーごとにJSON整形の安定性が違う
• トークン使用量が役割ごとに大きく変わる

必要なのは、保存・リプレイ・アサーション可能なリクエストコレクションです。これは Apidog が得意とする領域です。同じテストパターンは、MCPサーバーテストプレイブック でも扱っています。

ApidogでマーケットデータAPIをモックする

TradingAgentsのテストを安定させるには、まずマーケットデータAPIをモック化します。

ステップ1：アップストリームエンドポイントを定義する

Apidogプロジェクトで、TradingAgentsが呼び出すベンダーAPIを登録します。

対象例：

• Yahoo Finance
• FinnHub
• Polygon
• OpenBB

各エンドポイントについて、以下を保存します。

• HTTPメソッド
• パス
• クエリパラメータ
• 認証ヘッダー
• 実レスポンスから取得したサンプルJSON

例：

GET /quote
Host: example-market-data.local
Authorization: Bearer {{MARKET_DATA_API_KEY}}

レスポンス例：

{
  "symbol": "AAPL",
  "regularMarketPrice": 173.5,
  "regularMarketTime": 1777507200,
  "currency": "USD"
}

ステップ2：モックサーバーを有効化する

Apidogのモックサーバーを有効にし、TradingAgentsのツール設定をモックURLに向けます。

これにより、テスト実行は以下の影響を受けません。

• Yahoo Financeの一時的な失敗
• FinnHubのレート制限
• Polygonのレスポンス遅延
• 週末や時間外のデータ差分

ステップ3：ベンダー変更を検出する

週に一度、ライブエンドポイントを実行し、保存済みフィクスチャと比較します。

確認する差分：

• 追加されたフィールド
• 削除されたフィールド
• 名前変更されたフィールド
• 型が変わったフィールド
• null許容になったフィールド

このパターンは、契約優先API開発 と同じです。

LLMプロバイダー層をテストする

TradingAgentsを複数ティッカーで実行する前に、LLMプロバイダー層では最低3つを確認します。

1. 役割ごとのコスト

1つのティッカーを、4人のアナリストと議論フェーズまで通します。

Apidog のリクエストログで、エージェントごとのトークン数を記録します。

見るべき項目：

• prompt tokens
• completion tokens
• reasoning tokens
• latency
• retry count
• total cost

ブル/ベア議論は、通常アナリスト単体より高コストになります。もし極端に安い場合、モデルが議論を十分に行わずショートサーキットしている可能性があります。

2. 出力JSONの妥当性

v0.2.4の構造化出力エージェントは、常に整形式JSONを返すべきです。

ApidogでJSONPathアサーションを追加します。

例：

$.decision exists
$.confidence is number
$.rationale exists
$.risk_notes is array

JSONが壊れると、下流のトレーダーやポートフォリオマネージャーが失敗します。ここはCIで検出すべきです。

3. プロバイダー間の同等性

OpenAIからDeepSeek V4へ切り替える場合、単発の決定は変わっても、多数の実行では傾向が近いか確認します。

実装例：

1. 同じ50ティッカーをOpenAIで実行
2. 同じ50ティッカーをDeepSeek V4で実行
3. SQLiteの意思決定ログを抽出
4. BUY/SELL/HOLDの分布を比較
5. 信頼度スコアの平均との差分を見る

DeepSeek側のリクエスト形式は DeepSeek V4 APIガイド、OpenAI側は GPT-5.5 APIガイド が参考になります。

Apidogのレスポンス差分を使うと、プロバイダーごとの差を視覚的に比較できます。

最小構成でTradingAgentsを実行する

READMEのクイックスタートは、おおよそ次のような流れです。

git clone https://github.com/TauricResearch/TradingAgents
cd TradingAgents
pip install -r requirements.txt

export OPENAI_API_KEY="sk-..."
export FINNHUB_API_KEY="..."

python -m tradingagents.cli \
  --ticker AAPL \
  --date 2026-04-30 \
  --models gpt-5.5 \
  --rounds 2

--rounds 2 は、ブル/ベア議論を試す最小構成として扱いやすい設定です。

出力は、JSONとMarkdown形式の意思決定サマリーとして次のディレクトリに保存されます。

tradingagents/results/

DeepSeek V4に切り替える例

推論負荷の高い役割にDeepSeek V4 Proを使う場合は、プロバイダー設定とモデル指定を切り替えます。

export DEEPSEEK_API_KEY="sk-..."

python -m tradingagents.cli \
  --ticker AAPL \
  --date 2026-04-30 \
  --models deepseek-v4-pro \
  --provider deepseek \
  --rounds 2

同じ考え方は、Qwen 3.6、GLM 5、Ollama、vLLM、LM StudioなどのOpenAI互換エンドポイントにも適用できます。

ローカルLLMの選定については、2026年版ベストローカルLLMの記事 を参照してください。

CIに組み込むテスト例

TradingAgentsを安全に変更するには、以下のようなテストをCIで実行します。

name: tradingagents-api-tests

on:
  pull_request:
  schedule:
    - cron: "0 2 * * 1"

jobs:
  api-contract-test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: |
          pip install -r requirements.txt

      - name: Run TradingAgents against mocked APIs
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          FINNHUB_API_KEY: test
          MARKET_DATA_BASE_URL: ${{ secrets.APIDOG_MOCK_URL }}
        run: |
          python -m tradingagents.cli \
            --ticker AAPL \
            --date 2026-04-30 \
            --models gpt-5.5 \
            --rounds 1

      - name: Validate outputs
        run: |
          test -d tradingagents/results

実運用では、Apidog側で次をアサートします。

• マーケットデータAPIのレスポンススキーマ
• LLMレスポンスのJSON形式
• 必須フィールドの存在
• HTTPステータス
• レイテンシ
• トークン使用量の上限

よくある落とし穴

小規模モデルで実行する

7Bクラスのローカルモデルでは、ブル/ベア議論がループしたり、結論が弱くなることがあります。

現実的な最低ラインとしては、以下のようなモデルが候補になります。

• DeepSeek V4 Flash
• Qwen 3.6 32B
• GPT-5.5
• Claude 4.5

マーケットデータキャッシュを使わない

各アナリストはデータ層を個別に呼び出します。キャッシュなしでは、1回の実行で4〜8件以上のベンダーリクエストが発生します。

レート制限を避けるため、キャッシュは有効化してください。

トレーディングボットとして扱う

TradingAgentsは研究コードです。

出力は次のように扱うべきです。

• 売買指示ではなく仮説
• 戦略ではなく分析サンプル
• 実資金投入前の検証対象

トークン消費量を記録しない

1ティッカーの実行コストは、モデルとラウンド数によって大きく変わります。

Apidog のリプレイ履歴で、実行ごとのコストを記録してください。

議論フェーズが暴走すると、数分でコストが増えます。

1つのプロバイダーに固定する

v0.2.0以降のマルチプロバイダー対応は、比較検証のために使うべきです。

本番に近い検証では、少なくとも次を比較します。

• OpenAI
• DeepSeek
• Anthropic
• ローカルOpenAI互換モデル

開発ループにおけるApidogの使いどころ

TradingAgentsで Apidog が役立つ場面は大きく3つあります。

1. 設計フェーズ

実ベンダーに接続する前に、各マーケットデータエンドポイントをApidogで定義します。

この時点で確認すること：

• 本当に必要なフィールドは何か
• どのエージェントがどのAPIを呼ぶか
• レスポンススキーマは安定しているか
• ベンダー依存が強すぎないか

2. ローカルCI

Apidogのモックサーバーを使えば、ユニットテストを外部APIに依存させずに実行できます。

メリット：

• テストが速い
• レート制限を受けない
• 週末や市場時間に依存しない
• 同じ入力で再現できる

このパターンは、PostmanなしのAPIテスト でも解説されています。

3. リグレッション差分比較

週次でライブエンドポイントを呼び、保存済みフィクスチャと比較します。

Apidogで見るべき差分：

• フィールド名変更
• 型変更
• nullの混入
• 配列構造の変更
• エラーレスポンス形式の変更

これは「データ層が壊れて、エージェントが幻覚を始める」前に検知するための安価なアラームです。

トレーディング以外で応用できるパターン

TradingAgentsのパターンは、トレーディング以外にも使えます。

• 顧客サポートのトリアージ

  • チケット種別ごとの分析エージェント
  • 優先度判定
  • 最終対応方針

• コードレビュー

  • セキュリティエージェント
  • パフォーマンスエージェント
  • スタイルエージェント
  • PRコメント生成エージェント

• コンプライアンスレビュー

  • データ分析エージェント
  • リスクレビュー担当
  • 決定委員会

• 研究要約

  • 複数分野の専門リーダー
  • 議論
  • 統合サマリー

重要なのは、すべてを1つの巨大プロンプトに詰め込まないことです。

代わりに、次の形に分解します。

入力
  ↓
専門エージェント
  ↓
議論
  ↓
統合
  ↓
構造化出力
  ↓
検証
  ↓
ログ保存

この構造は、Apidog と組み合わせることでテストしやすくなります。

実世界のユースケース

クオンツ研究でのモデル比較

あるクオンツ研究の学生は、同じ30銘柄のバスケットでDeepSeek V4、GPT-5.5、Claude 4.5を比較しています。

Apidogで全リクエストとレスポンスをキャプチャすることで、比較を再現可能にしています。

社内コードレビュー

あるフィンテックエンジニアは、TradingAgentsのマルチエージェントパターンをコードレビューに応用しています。

構成例：

• セキュリティ担当エージェント
• パフォーマンス担当エージェント
• 命名規則担当エージェント
• シンセサイザー

PRごとのレビューコストは約0.04ドルです。

夜間ウォッチリスト分析

あるソロ開発者は、10銘柄のウォッチリストに対してTradingAgentsを毎晩実行し、すべての決定をPostgresに保存しています。

週末のテストでは、Apidogのモックサーバーがライブマーケットデータベンダーの代わりをします。

結論

TradingAgentsは、チャットではなく「構造化された意思決定」を生成するマルチエージェントLLMシステムの実装例です。

v0.2.4では、構造化出力、チェックポイント再開、監査ログ、マルチプロバイダー対応が追加され、検証しやすくなりました。

ただし、LLM層とマーケットデータ層をテストできなければ、エージェントの出力は信頼できません。そこで Apidog を使い、APIのモック、リプレイ、差分比較、JSONアサーションを組み込みます。

要点は5つです。

• TradingAgentsは、明確な役割と議論フェーズを持つ専門エージェントにトレーディングを分解する
• v0.2.4では、構造化出力、LangGraphチェックポイント、DeepSeek/Qwen/GLM/Azureプロバイダー対応が追加された
• マーケットデータベンダーは Apidog でモックし、テストを決定論的にする
• 本番でモデルを交換する前に、LLMプロバイダー間の同等性をテストする
• 「専門家、議論、決定、ログ」のパターンは、トレーディング以外のエージェントワークフローにも適用できる

次のステップはシンプルです。

1. TradingAgentsリポジトリをクローンする
2. 好みのLLMで1ティッカーを実行する
3. マーケットデータAPIをApidogモックサーバーに向ける
4. LLMレスポンスのJSONアサーションを追加する
5. 意思決定ログを比較する

1時間ほどで、このフレームワークが自分のワークフローに合うか判断できます。

FAQ

TradingAgentsは実際の資金で使っても安全ですか？

リポジトリには、これは研究コードであり金融アドバイスではないと明記されています。出力は仮説として扱ってください。ライブ証券口座に接続する場合、そのリスクは利用者が負います。

どのLLMプロバイダーが費用対効果に優れていますか？

2026年初頭の多くのワークロードでは、思考モードを持つDeepSeek V4 Flashが、コスト面でGPT-5.5より有利で、ブル/ベア議論の品質も同等とされています。リクエスト形式は DeepSeek V4 APIガイド を参照してください。

ローカルモデルでTradingAgentsを実行できますか？

はい。v0.2.0でマルチプロバイダー対応が追加されました。Ollama、vLLM、LM Studioは、TradingAgentsが利用できるOpenAI互換エンドポイントを提供できます。モデル選定は 2026年版ベストローカルLLMの記事 を参照してください。

マーケットデータAPIをどうモックしますか？

Apidog で各ベンダーエンドポイントを定義し、モックサーバーを有効化します。その後、TradingAgentsのツール設定をモックURLに向けます。同じ考え方は QAエンジニア向けのAPIテストツール にもまとめられています。

最小ハードウェア要件は？

ホスト型LLM、たとえばOpenAI、Anthropic、DeepSeekを呼び出す場合は、Python 3.10以降が動くラップトップで実行できます。

ローカルモデルを使う場合は、モデルに応じてGPU要件が変わります。24GB GPUではDeepSeek V4 FlashやQwen 3.6 32B、8GB GPUではLlama 5.1 8Bのような小規模モデルが対象になります。ただし、小規模モデルでは議論品質が低下する可能性があります。

時間外や週末のシミュレーションはできますか？

マーケットデータベンダーが過去データを返すため、任意の日付で実行できます。ただし、ライブトレーディングはTradingAgentsが明示的に解決する問題ではありません。

他のマルチエージェントフレームワークと比べてどうですか？

TradingAgentsはトレーディング領域に特化しています。一方、CrewAI、AutoGen、LangGraphは汎用的です。

• トレーディング特化の実装パターンを読みたい場合：TradingAgents
• 汎用エージェント基盤を作りたい場合：LangGraph
• ロールベースの抽象化を素早く試したい場合：CrewAI

TradingAgentsは、マルチエージェント設計の実装パターンを学ぶ教材として特に有用です。