要点 / 簡易回答
TradingAgentsを使用する最も実用的な方法は、Pythonパッケージとして実行し、それを小さなFastAPIサービスでラップし、Apidogでそのサービスをテストすることです。これにより、分析のトリガー、結果のポーリング、リクエスト契約の文書化、チームとのセットアップ共有のための繰り返し可能なワークフローが得られます。
はじめに
TradingAgentsは、外部から見ると魅力的なものです。GitHubリポジトリには、マルチエージェント取引ワークフロー、洗練されたCLI、複数のモデルプロバイダーのサポート、およびフレームワーク設計を説明する研究論文が示されています。しかし、実際のエンジニアリングワークフローでそれを使用しようとすると、より困難な部分が始まります。
ほとんどのチームは、一人の開発者しかローカルで実行できないリポジトリを望んでいません。彼らが求めているのは、分析をトリガーし、ティッカーと日付を渡し、ジョブIDを返し、後で結果を検査し、すべての問題をPythonのデバッグセッションに変えることなく、そのワークフローをフロントエンド、QA、またはプラットフォームのチームメイトに引き渡すことができる、繰り返し可能な方法です。そして、あらゆる取引研究システムはいずれ実資金の意思決定に利用されるため、誰かのノートパソコン上の使い捨てスクリプトとして残すのではなく、TradingAgentsを管理され文書化されたAPIでラップすることがさらに重要になります。
ボタン
TradingAgentsとは何か、そしてそうでないもの
コーディングを開始する前に、ツールを正確に定義することが役立ちます。

TradingAgentsはオープンソースのマルチエージェント取引フレームワークです。このリポジトリは、取引会社の構造を反映した専門的な役割のセットを説明しています。
- ファンダメンタルズ、センチメント、ニュース、テクニカルシグナルを分析するアナリスト
- 議論のための強気および弱気研究者
- トレーダーエージェント
- リスク管理担当
- 最終決定を下すポートフォリオマネージャー

また、このリポジトリは、フレームワークがLangGraphで構築されており、OpenAI、Google、Anthropic、xAI、OpenRouter、Ollamaを含む複数のモデルプロバイダーをサポートしていると述べています。公開されているデフォルト設定では、プロジェクトは現在次のような値を使用しています。
llm_provider = "openai"deep_think_llm = "gpt-5.2"quick_think_llm = "gpt-5-mini"backend_url = "https://api.openai.com/v1"max_debate_rounds = 1
これは、あなたが実際に何を使っているのかを教えてくれるため重要です。それは設定可能な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 uvicornTradingAgentsリポジトリには、プロバイダー変数を記述した.env.exampleも含まれています。
OPENAI_API_KEY=
GOOGLE_API_KEY=
ANTHROPIC_API_KEY=
XAI_API_KEY=
OPENROUTER_API_KEY=モデルとデータの選択によっては、Alpha Vantageのような他のベンダーの認証情報も必要になる場合があります。
ここで重要な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で公開する価値のあるパラメータが何であるかを教えてくれます。
ticker(ティッカー)analysis_date(分析日付)llm_provider(LLMプロバイダー)deep_think_llm(詳細思考LLM)quick_think_llm(迅速思考LLM)- research depth (調査深度) または debate rounds (議論回数)
このローカルPythonフェーズをスキップして直接HTTPに移行すると、デバッグが不必要に難しくなります。
ステップ3:TradingAgentsの利用方法を決定する
この時点で、フレームワークを使用する3つの一般的な方法があります。
オプション1:CLIのみ
このリポジトリには、ティッカー、日付、プロバイダー、調査深度を選択できる対話型CLIが含まれています。これはプロジェクトを素早く探索するのに良い方法です。
これを使うのは次の場合です。
- ツールを学習している場合
- 単独で実験を行っている場合
- 他のアプリに安定した契約が必要ない場合
次のステップがフロントエンド、管理ツール、共有サービス、またはQAワークフローである場合は、ここで止まらないでください。
オプション2:Pythonのみ
カスタムオーケストレーションやローカルスクリプトが必要な場合、Pythonから直接TradingAgentsGraphを呼び出す方がCLIよりも優れています。
これを使うのは次の場合です。
- ノートブックやローカルでの自動化が必要な場合
- プログラムによる制御が必要な場合
- 一人の開発者がワークフロー全体を所有している場合
複数のチームがワークフローを利用する必要がある場合、これはまだ不十分です。
オプション3:APIラッパーとApidog
これは最も有用なチーム設定です。TradingAgentsを実行エンジンとして保持し、小さなFastAPIサービスを通じて公開し、Apidogを使用して契約をテストし文書化します。
これを使うのは次の場合です。
- フロントエンドが分析をトリガーする必要がある場合
- QAが繰り返し可能なリクエストフローを必要とする場合
- 環境、アサーション、ドキュメントを一つの場所にまとめたい場合
- ワークフローの実行時間が長くなり、同期リクエスト1回よりもポーリングの方が理にかなっている場合
ほとんどのチームにとって、これは「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 /analyses | TradingAgentsの実行をトリガーする |
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は以下を公開します。
http://localhost:8000/docshttp://localhost:8000/openapi.json
その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このステップは小さいように見えますが、多くの摩擦を防ぎます。
- ローカル、ステージング、プロダクション間をより速く切り替えられる
- リクエストが再利用可能になる
- チームメイトが毎回URLやヘッダーを書き換える必要がない
これが、ApidogがTradingAgentsにとって強力なパートナーである最も単純な理由の1つです。フレームワーク自体が分析ロジックを処理し、Apidogはそれを取り巻く共有ワークフローを処理します。
ステップ8:Apidogで完全なワークフローをテストする
これで、実際のクライアントがそうするように、Apidogを使用してTradingAgentsをテストできます。
リクエスト1:分析を作成する
設定:
- メソッド:
POST - URL:
{{base_url}}/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
}ステータスを検証し、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:分析をポーリングする
設定:
- メソッド:
GET - URL:
{{base_url}}/analyses/{{analysis_id}}
次のようなアサーションを追加します。
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クライアント以上のものになります。次のようなシナリオを構築します。
POST /analysesを送信するanalysis_idを保存する- 数秒待つ
GET /analyses/{{analysis_id}}を実行する
これにより、QAおよびエンジニアリングチームは、単に1つのエンドポイントが200を返すかどうかを確認するのではなく、ライフサイクルを検証するための再現可能な方法を得ることができます。
ステップ9:チーム向け内部ドキュメントを公開する
リクエストが機能するようになったら、テストで止まらないでください。
Apidogを使用して、以下を説明する内部ドキュメントを公開します。
- どのプロバイダーが許可されているか
- デプロイメントにおける
research_depthの意味 - クライアントが期待すべきステータス値
- 通常、実行にどのくらいの時間がかかるか
- どのエラーが再試行可能か
- 研究目的のみの免責事項がどこに適用されるか
これは、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 /analysesとGET /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は実際の金融意思決定に適していますか?
公開されているプロジェクト資料では、これは研究フレームワークであると説明されており、金融アドバイスや投資アドバイスではないとはっきりと述べられています。独自の制御、検証、ガバナンスを追加しない限り、研究および実験システムとして扱ってください。
