TradingAgentsをリアルな取引APIワークフローに変える方法

Ashley Innocent

Ashley Innocent

26 3月 2026

TradingAgentsをリアルな取引APIワークフローに変える方法

要点 / 簡易回答

TradingAgentsを使用する最も実用的な方法は、Pythonパッケージとして実行し、それを小さなFastAPIサービスでラップし、Apidogでそのサービスをテストすることです。これにより、分析のトリガー、結果のポーリング、リクエスト契約の文書化、チームとのセットアップ共有のための繰り返し可能なワークフローが得られます。

はじめに

TradingAgentsは、外部から見ると魅力的なものです。GitHubリポジトリには、マルチエージェント取引ワークフロー、洗練されたCLI、複数のモデルプロバイダーのサポート、およびフレームワーク設計を説明する研究論文が示されています。しかし、実際のエンジニアリングワークフローでそれを使用しようとすると、より困難な部分が始まります。

ほとんどのチームは、一人の開発者しかローカルで実行できないリポジトリを望んでいません。彼らが求めているのは、分析をトリガーし、ティッカーと日付を渡し、ジョブIDを返し、後で結果を検査し、すべての問題をPythonのデバッグセッションに変えることなく、そのワークフローをフロントエンド、QA、またはプラットフォームのチームメイトに引き渡すことができる、繰り返し可能な方法です。そして、あらゆる取引研究システムはいずれ実資金の意思決定に利用されるため、誰かのノートパソコン上の使い捨てスクリプトとして残すのではなく、TradingAgentsを管理され文書化されたAPIでラップすることがさらに重要になります。

💡
Apidogはこのワークフローに自然に適合します。FastAPIからOpenAPIスキーマをインポートし、ローカルおよびリモートデプロイメントの環境を保存し、応答から変数を抽出し、ポーリングリクエストをシナリオに連結し、残りのチームのためにドキュメントを公開できます。Apidogを無料でダウンロードして、一緒に試してみましょう。

ボタン

TradingAgentsとは何か、そしてそうでないもの

コーディングを開始する前に、ツールを正確に定義することが役立ちます。

TradingAgentsはオープンソースのマルチエージェント取引フレームワークです。このリポジトリは、取引会社の構造を反映した専門的な役割のセットを説明しています。

また、このリポジトリは、フレームワークがLangGraphで構築されており、OpenAI、Google、Anthropic、xAI、OpenRouter、Ollamaを含む複数のモデルプロバイダーをサポートしていると述べています。公開されているデフォルト設定では、プロジェクトは現在次のような値を使用しています。

これは、あなたが実際に何を使っているのかを教えてくれるため重要です。それは設定可能なPythonフレームワークであり、そのまま使えるSaaS APIではありません。

このリポジトリは、範囲についても慎重です。TradingAgentsは研究フレームワークとして提示されており、金融アドバイスではありません。社内で使用したり、それを中心にソフトウェアを構築したりする場合は、その位置づけをドキュメントとユーザーエクスペリエンスで明確に示してください。

ステップ1:TradingAgentsをインストールする

リポジトリ自身のセットアップから始めます。

git clone https://github.com/TauricResearch/TradingAgents.git
cd TradingAgents
conda create -n tradingagents python=3.13
conda activate tradingagents
pip install .

このチュートリアルからAPIラッパーも構築したい場合は、FastAPIとUvicornを追加します。

pip install fastapi uvicorn

TradingAgentsリポジトリには、プロバイダー変数を記述した.env.exampleも含まれています。

OPENAI_API_KEY=
GOOGLE_API_KEY=
ANTHROPIC_API_KEY=
XAI_API_KEY=
OPENROUTER_API_KEY=

モデルとデータの選択によっては、Alpha Vantageのような他のベンダーの認証情報も必要になる場合があります。

ここで重要な2つの実用的なルールがあります。

  1. 認証情報を環境変数またはシークレットマネージャーに保持する。
  2. 後でプロバイダーのシークレットをパブリックAPIリクエストボディを介して渡さない。

この分離により、Apidogの環境がよりクリーンになり、セキュリティモデルがはるかに安全になります。

ステップ2:最初にPythonでTradingAgentsを実行する

APIラッパーを構築する前に、コアフレームワークがあなたの環境で動作することを確認してください。

READMEには、最小限のPython使用パターンが示されています。

from tradingagents.graph.trading_graph import TradingAgentsGraph
from tradingagents.default_config import DEFAULT_CONFIG

ta = TradingAgentsGraph(debug=True, config=DEFAULT_CONFIG.copy())
_, decision = ta.propagate("NVDA", "2026-01-15")
print(decision)

これは正しい最初のチェックポイントです。なぜなら、早い段階で唯一重要な質問に答えるからです。あなたのマシン、モデルのセットアップ、および依存関係は、実際にTradingAgentsの実行を実行できますか?

それが機能すれば、制御された設定に進むことができます。リポジトリは、デフォルト設定を上書きできることも示しています。

from tradingagents.graph.trading_graph import TradingAgentsGraph
from tradingagents.default_config import DEFAULT_CONFIG

config = DEFAULT_CONFIG.copy()
config["llm_provider"] = "openai"
config["deep_think_llm"] = "gpt-5.2"
config["quick_think_llm"] = "gpt-5-mini"
config["max_debate_rounds"] = 2

ta = TradingAgentsGraph(debug=True, config=config)
_, decision = ta.propagate("NVDA", "2026-01-15")
print(decision)

この2番目の例は、見た目以上に重要です。後でAPIで公開する価値のあるパラメータが何であるかを教えてくれます。

このローカルPythonフェーズをスキップして直接HTTPに移行すると、デバッグが不必要に難しくなります。

ステップ3:TradingAgentsの利用方法を決定する

この時点で、フレームワークを使用する3つの一般的な方法があります。

オプション1:CLIのみ

このリポジトリには、ティッカー、日付、プロバイダー、調査深度を選択できる対話型CLIが含まれています。これはプロジェクトを素早く探索するのに良い方法です。

これを使うのは次の場合です。

次のステップがフロントエンド、管理ツール、共有サービス、またはQAワークフローである場合は、ここで止まらないでください。

オプション2:Pythonのみ

カスタムオーケストレーションやローカルスクリプトが必要な場合、Pythonから直接TradingAgentsGraphを呼び出す方がCLIよりも優れています。

これを使うのは次の場合です。

複数のチームがワークフローを利用する必要がある場合、これはまだ不十分です。

オプション3:APIラッパーとApidog

これは最も有用なチーム設定です。TradingAgentsを実行エンジンとして保持し、小さなFastAPIサービスを通じて公開し、Apidogを使用して契約をテストし文書化します。

これを使うのは次の場合です。

ほとんどのチームにとって、これは「TradingAgentsの利用方法」が単なるローカルデモではなく、実際の実現可能な回答となるポイントです。

ステップ4:TradingAgentsをFastAPIサービスでラップする

最初のラッパーにとって最もクリーンなパターンは、ジョブベースのAPIです。

なぜジョブベースなのか?マルチエージェント分析は、1つのリクエストを開きっぱなしにするのがクライアントにとって不便なほど長時間かかる可能性があるからです。より良いパターンは次のとおりです。

POST /analyses -> returns analysis_id
GET /analyses/{id} -> returns queued, running, completed, or failed

その構造は、ブラウザにとってより簡単で、QAにとってより簡単で、Apidogで文書化するのもより簡単です。

API契約を作成する

最小限の契約は次のようになります。

エンドポイント目的
GET /health基本的なヘルスチェック
POST /analysesTradingAgentsの実行をトリガーする
GET /analyses/{analysis_id}ジョブステータスと最終結果を取得する

ラッパーを構築する

以下に簡潔なFastAPIの例を示します。

from concurrent.futures import ThreadPoolExecutor
from datetime import date, datetime
from uuid import uuid4

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field

from tradingagents.default_config import DEFAULT_CONFIG
from tradingagents.graph.trading_graph import TradingAgentsGraph

app = FastAPI(title="TradingAgents API", version="0.1.0")
executor = ThreadPoolExecutor(max_workers=2)
jobs: dict[str, dict] = {}

class AnalysisRequest(BaseModel):
 ticker: str = Field(..., min_length=1, examples=["NVDA"])
 analysis_date: date
 llm_provider: str = Field(default="openai")
 deep_think_llm: str = Field(default="gpt-5.2")
 quick_think_llm: str = Field(default="gpt-5-mini")
 research_depth: int = Field(default=1, ge=1, le=5)

def run_analysis(job_id: str, payload: AnalysisRequest) -> None:
 jobs[job_id]["status"] = "running"
 jobs[job_id]["started_at"] = datetime.utcnow().isoformat()

 config = DEFAULT_CONFIG.copy()
 config["llm_provider"] = payload.llm_provider
 config["deep_think_llm"] = payload.deep_think_llm
 config["quick_think_llm"] = payload.quick_think_llm
 config["max_debate_rounds"] = payload.research_depth
 config["max_risk_discuss_rounds"] = payload.research_depth

 try:
 graph = TradingAgentsGraph(debug=False, config=config)
 _, decision = graph.propagate(
 payload.ticker,
 payload.analysis_date.isoformat(),
 )
 jobs[job_id].update(
 {
 "status": "completed",
 "finished_at": datetime.utcnow().isoformat(),
 "result": decision,
 }
 )
 except Exception as exc:
 jobs[job_id].update(
 {
 "status": "failed",
 "finished_at": datetime.utcnow().isoformat(),
 "error": str(exc),
 }
 )

@app.get("/health")
def health() -> dict:
 return {"status": "ok"}

@app.post("/analyses", status_code=202)
def create_analysis(payload: AnalysisRequest) -> dict:
 analysis_id = str(uuid4())
 jobs[analysis_id] = {
 "status": "queued",
 "ticker": payload.ticker,
 "analysis_date": payload.analysis_date.isoformat(),
 "created_at": datetime.utcnow().isoformat(),
 }
 executor.submit(run_analysis, analysis_id, payload)
 return {"analysis_id": analysis_id, "status": "queued"}

@app.get("/analyses/{analysis_id}")
def get_analysis(analysis_id: str) -> dict:
 job = jobs.get(analysis_id)
 if not job:
 raise HTTPException(status_code=404, detail="Analysis not found")
 return job

サービスを開始します。

uvicorn app:app --reload

サーバーが起動すると、FastAPIは以下を公開します。

その2番目のURLは、Apidogが直接インポートできるため特に便利です。

ステップ5:APIを通じてTradingAgentsを使用する

これで、安定して繰り返し可能な方法でTradingAgentsを使用する準備が整いました。

分析をトリガーする

次のようなボディでPOST /analysesリクエストを送信します。

{
 "ticker": "NVDA",
 "analysis_date": "2026-03-26",
 "llm_provider": "openai",
 "deep_think_llm": "gpt-5.2",
 "quick_think_llm": "gpt-5-mini",
 "research_depth": 2
}

応答は迅速かつ簡潔であるべきです。

{
 "analysis_id": "88f9f0f5-7315-4c73-8ed5-d0a71f613d31",
 "status": "queued"
}

それこそがあなたが求めているものです。クライアントは最終レポートをすぐに必要としません。実行のための安定したハンドルが必要です。

結果をポーリングする

GET /analyses/{analysis_id}を使用して進捗状況を確認します。

{
 "status": "running",
 "ticker": "NVDA",
 "analysis_date": "2026-03-26",
 "created_at": "2026-03-26T06:00:00.000000",
 "started_at": "2026-03-26T06:00:01.000000"
}

ワークフローが完了すると、応答には最終決定が含まれることがあります。

{
 "status": "completed",
 "ticker": "NVDA",
 "analysis_date": "2026-03-26",
 "result": {
 "decision": "hold"
 }
}

何か問題が発生した場合は、クライアントを推測させるのではなく、明確なfailedステータスとエラーメッセージを返してください。

ステップ6:APIをApidogにインポートする

ここでワークフローの保守がはるかに簡単になります。

Apidogで、OpenAPIスキーマを以下からインポートします。

http://localhost:8000/openapi.json

インポート後、エンドポイントはリクエストおよびレスポンス構造が既に配置された状態で表示されます。

これにより、いくつかの即座の利点が得られます。

アドホックなcURLテストから移行する場合、これは重要なアップグレードです。リクエスト専用ツールから移行する場合、Apidogは設計、テスト、環境、ドキュメントを一箇所に保持できるため、ここでより重要になります。

ステップ7:Apidog環境を作成する

APIがインポートされたら、ローカルサービス用の環境を作成します。

変数の例:

base_url = http://localhost:8000
analysis_id =

APIが認証を使用する場合は、それも含まれます。

internal_api_key = your-local-dev-key

このステップは小さいように見えますが、多くの摩擦を防ぎます。

これが、ApidogがTradingAgentsにとって強力なパートナーである最も単純な理由の1つです。フレームワーク自体が分析ロジックを処理し、Apidogはそれを取り巻く共有ワークフローを処理します。

ステップ8:Apidogで完全なワークフローをテストする

これで、実際のクライアントがそうするように、Apidogを使用してTradingAgentsをテストできます。

リクエスト1:分析を作成する

設定:

{
 "ticker": "NVDA",
 "analysis_date": "2026-03-26",
 "llm_provider": "openai",
 "deep_think_llm": "gpt-5.2",
 "quick_think_llm": "gpt-5-mini",
 "research_depth": 2
}

ステータスを検証し、IDを保存するテストスクリプトを追加します。

pm.test("Status is 202", function () {
 pm.response.to.have.status(202);
});

const data = pm.response.json();
pm.expect(data.analysis_id).to.exist;
pm.environment.set("analysis_id", data.analysis_id);

リクエスト2:分析をポーリングする

設定:

次のようなアサーションを追加します。

pm.test("Analysis has a valid status", function () {
 const data = pm.response.json();
 pm.expect(["queued", "running", "completed", "failed"]).to.include(data.status);
});

成功パスのチェックも行いたい場合:

pm.test("Completed jobs include a result", function () {
 const data = pm.response.json();
 if (data.status === "completed") {
 pm.expect(data.result).to.exist;
 }
});

両方のリクエストをシナリオに連結する

ここでApidogは単なるAPIクライアント以上のものになります。次のようなシナリオを構築します。

  1. POST /analysesを送信する
  2. analysis_idを保存する
  3. 数秒待つ
  4. GET /analyses/{{analysis_id}}を実行する

これにより、QAおよびエンジニアリングチームは、単に1つのエンドポイントが200を返すかどうかを確認するのではなく、ライフサイクルを検証するための再現可能な方法を得ることができます。

ステップ9:チーム向け内部ドキュメントを公開する

リクエストが機能するようになったら、テストで止まらないでください。

Apidogを使用して、以下を説明する内部ドキュメントを公開します。

これは、TradingAgentsをうまく利用するための最も重要な部分の1つです。コアフレームワークは巧妙ですが、契約が1人の開発者の頭の中にしかない場合、巧妙なフレームワークはチームのボトルネックとなります。

Apidogを無料でダウンロードして、TradingAgentsを環境、アサーション、および再利用可能なチーム向けのシナリオを備えた文書化されたAPIワークフローに変えましょう。

ボタン

この方法でTradingAgentsを使用する際のよくある間違い

フレームワークをホストされたAPIのように扱う

TradingAgentsは既製のパブリックサービスではありません。これはPythonフレームワークです。リポジトリが提供してくれると期待するのではなく、チームが使用したい契約を構築してください。

リクエストボディを通じてシークレットを渡す

プロバイダーのキーは環境管理に保持してください。それらを例、フロントエンド呼び出し、または共有スクリーンショットに漏らさないでください。

長い同期応答を1つ返す

多段階のエージェントワークフローの場合、ジョブベースのAPIは、長いブロッキングリクエストよりも通常管理が容易です。

構成オプションを過度に公開する

リポジトリには有用な設定オプションがありますが、APIが初日からすべての内部設定を公開する必要はありません。小さく、安定した契約から始めましょう。

結果をメモリのみに保持する

チュートリアルコードは理解しやすいためインメモリ辞書を使用しています。本番環境では、サービスが再起動してもアクティブな分析が消去されないように、ジョブの状態と結果をRedis、Postgres、または別の永続バックエンドに保存してください。

研究免責事項を隠す

あなたのサービスがTradingAgentsをラップする場合、プロジェクトが使用しているのと同じ警告を維持してください。このフレームワークは研究と実験のためのものであり、金融アドバイスではありません。

結論

TradingAgentsを最大限に活用する方法は、あなたが何をしようとしているかによって異なります。フレームワークを単独で探索している場合は、CLIとPythonパッケージで十分です。安定した、繰り返し可能なチームワークフローを望む場合は、TradingAgentsを小さなAPIでラップし、Apidogを使用してテストおよび文書化してください。

GitHubリポジトリからすぐに使えるチームワークフローに移行したい場合は、TradingAgentsをインストールし、TradingAgentsGraphがローカルで動作することを確認し、POST /analysesGET /analyses/{id}を追加した後、そのスキーマをApidogにインポートして、エンドツーエンドのシナリオを構築してください。このパスは、ターミナルコマンドのコレクションや口頭伝承よりもはるかに維持しやすいです。

ボタン

よくある質問

TradingAgentsを初めて使用するにはどうすればよいですか?

まず、リポジトリをインストールし、モデルプロバイダーの環境変数を設定し、TradingAgentsGraphでPythonの例を実行します。それが機能したら、CLIのみが必要なのか、APIでラップすべきかを判断してください。

TradingAgentsには公式のREST APIが付属していますか?

2026年3月26日時点で確認された公開リポジトリの資料にはありません。このプロジェクトはCLIとPythonパッケージとして提示されており、そのため多くのチームは薄いFastAPI層を追加したいと考えるでしょう。

フロントエンドアプリでTradingAgentsを使用する最も簡単な方法は何ですか?

Pythonフレームワークをフロントエンドから直接呼び出さないでください。analysis_idを返すバックエンドAPIを介して公開し、フロントエンドに結果をポーリングさせてください。

TradingAgentsでApidogを使用する理由は何ですか?

Apidogを使用すると、OpenAPIスキーマをインポートし、環境値を保存し、リクエスト例を保存し、アサーションを追加し、Pythonコードをリバースエンジニアリングする必要のないチームメイトとワークフローを共有するためのクリーンな場所を提供します。

APIで公開する価値のあるTradingAgentsの設定は何ですか?

最も安全な開始設定は、ティッカー、分析日付、プロバイダー、モデル選択、および調査深度です。ユースケースが現実的であれば、後でいつでも拡張できます。

例のジョブ状態をメモリに保持できますか?

学習またはプロトタイピング目的のみです。本番環境では、サービスが再起動してもアクティブな分析が消去されないように、ジョブの状態と結果をRedis、Postgres、または別の永続バックエンドに保存してください。

TradingAgentsは実際の金融意思決定に適していますか?

公開されているプロジェクト資料では、これは研究フレームワークであると説明されており、金融アドバイスや投資アドバイスではないとはっきりと述べられています。独自の制御、検証、ガバナンスを追加しない限り、研究および実験システムとして扱ってください。

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる