TradingAgents-astock: A股の制度制約を組み込んだマルチエージェント投研フレームワーク
A股多Agent投研框架 — 适配A股数据源(龙虎榜/游资/解禁等)，7位分析师基于A股规则的辩论决策，基于TradingAgents深度改造，适配大A。A-share multi-agent investment research framework — 7 AI analysts, bull/bear debate, risk assessment。
ひと目でわかる
- これは何？
- TauricResearch/TradingAgents をA股向けに作り直した fork。データ源、アナリスト役割、売買ルールの3層を差し替えており、研究・教育用途に限定した位置づけが README で明示されている。
- 誰に向いている？
- A股の制度要因（政策・龍虎榜・解禁）を LLM パイプラインに載せて研究したい個人や少人数チームに向く。リアルタイムの売買シグナル生成や本番運用を期待する用途には向かない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 11 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
上流 TradingAgents がA股で使えなかった理由
上流の TradingAgents はデータを Yahoo Finance と Alpha Vantage から取り、アナリストは4役（市場・センチメント・ニュース・ファンダメンタルズ）、売買ルールは T+0 で値幅制限なしという前提に立つ。A股ではこの3点がすべて成立しない。値幅制限があり、T+1 決済で、最小売買単位が決まっている。さらに政策の変化がセクター・ローテーションを直接動かし、龍虎榜に現れる游資が短期価格形成の中心になる。上流のフレームワークはこうした入力を取得する経路を持たないため、討論の土台そのものがA股とずれる。この fork は翻訳ではなく、データ層・エージェント役割・売買規則の3層を差し替えると README で説明している。対象読者は、A股の制度要因を LLM パイプラインに組み込んで検証したい研究者と、その構造を教材として使いたい読者である。
7アナリストからポートフォリオマネージャーまでの流れ
パイプラインは段階で構成される。まず7つのアナリストがそれぞれツール呼び出しループを回してレポートを生成する。市場、センチメント、ニュース、ファンダメンタルズの4役は上流由来で、A股向けに調整されている。加えて政策、游資追跡、解禁監視の3役が追加されている。7本のレポートは次段の Bull と Bear の討論に流れ込み、Research Manager がそれを統合して投資計画を出す。続いて Trader が T+1、値幅制限、売買単位といったA股制約を反映した取引案を作り、Aggressive、Conservative、Neutral の三方リスク討論を経て、Portfolio Manager が最終判断を下す。ここで重要なのは、討論とリスク評価の内部言語が英語のまま維持されている点だ。出力レポートだけが中国語になる。README はその理由を推論品質の維持と説明しており、多言語モデルで議論の精度が落ちるという判断が働いている。
quick_think_llm と deep_think_llm の役割分担
LLM は2系統に分かれる。quick_think_llm がアナリスト、Researcher、Trader、リスク討論者を担当し、deep_think_llm が Research Manager と Portfolio Manager を担当する。前者はツールを呼びながら局所的な分析を量産する役で、後者は全体を突き合わせて1つの判断に畳む役である。呼び出し回数が構造的に多いのは前者であり、コストの大半もそこに寄る。README は1回の分析に30〜50回の LLM 呼び出しが必要だと明記している。この数字は設計から直接出てくる。7アナリストがそれぞれツールループを回し、その後に討論とリスク評価のラウンドが続くため、エージェント数と討論ラウンド数を増やせば線形に近い形で伸びる。安価なモデルを quick 側に、推論の強いモデルを deep 側に置く構成が前提になっていると読める。
データ源の選別と東財リクエストの直列化
データ源はすべて無料で API キーを要さない。mootdx が TCP 7709 で OHLCV と財務スナップショットを、テンセント財経が HTTP で PE、PB、時価総額、回転率を、東方財富が龍虎榜、解禁、板塊、個別銘柄情報を、新浪財経が K線履歴と財務三表を、同花順が EPS コンセンサスを、財聯社がマクロ速報を、百度股市通が概念板塊と資金流向を提供する。Tushare、Alpha Vantage、Yahoo Finance には依存しない。ここで実務上いちばん効くのが東方財富の扱いだ。README は、行情、K線、時価総額、財務は mootdx かテンセントで取れるならそちらを優先し、東方財富は龍虎榜、解禁、資金流、板塊、個別ニュースなど固有のデータに限って使うと述べている。理由はアクセス制限で、東方財富側の風控は毎秒5回超、同時10以上、1分200回以上で一時ブロックを発動すると README が説明している。そのため全リクエストは内部の節流入口 _em_get() を通り、既定で1秒以上の間隔に0.1〜0.5秒のランダムゆらぎを加えて直列化し、Keep-Alive セッションを再利用する。バッチ処理では環境変数 EM_MIN_INTERVAL を1.5〜2に上げる選択肢がある。制限がかかるのは東方財富だけで、mootdx、テンセント、新浪、同花順、財聯社、百度には及ばない。
導入コマンドと .env の設定項目
Python 3.10 以上が前提で、pip install -e . で入る。Docker は任意であり、ローカル開発には不要だと README は書いている。インストール後は streamlit run web/app.py で Web UI、tradingagents で CLI が起動する。LLM はプロジェクト直下の .env に設定する。既定は API キー課金で、選択肢として MiniMax の MINIMAX_API_KEY、DeepSeek の DEEPSEEK_API_KEY、智谱 GLM の ZHIPU_API_KEY、通義千問の DASHSCOPE_API_KEY、OpenAI が並ぶ。MiniMax は国内直結で費用対効果が高いとして README が第一候補に挙げている。Gemini を使う場合は extra が用意されておらず、pip install --no-deps "langchain-google-genai>=4.0.0" に続けて google-genai と httpx を明示的に入れる必要がある。v0.4.0 以降は pip install -e ".[agentsdk]" により、一部または全部のノードを Claude Agent SDK 経由で個人の Claude Pro/Max 購読枠に流せる。API 課金を避けたい場合の経路として用意されている。v0.5.15 では role_llms がロール単位で api_key を指定できるようになり、v0.5.16 では一部の config が KeyError を出さなくなった。
向かない場面と上流との使い分け
この fork は研究と教学を目的として明示されており、投資助言でも投資サービスでもないと README の冒頭で断っている。したがって本番のシグナル生成や執行前チェックに直結させる使い方は想定されていない。もう1つの制約はデータ経路の脆さだ。東方財富の HTTP エンドポイントに依存する龍虎榜、解禁、資金流、板塊は、相手側の仕様変更や風控強化の影響を直接受ける。加えて7アナリスト構成は、A股の制度要因を明示的に扱いたい場合に効く一方、米国株や香港株の分析には役割が過剰で、討論の論点も噛み合わない。米国株が対象なら上流の TradingAgents をそのまま使うほうが構成が素直である。逆に、政策・游資・解禁を分析対象から外してテクニカルとファンダメンタルズだけで検証したい場合も、この fork の追加3役はノイズになる。
Apache-2.0 と更新の追従コスト
ライセンスは Apache-2.0 で、上流と同じである。派生物の配布時には帰属表示と変更点の明示が求められる。上流との差分は CHANGES_FROM_UPSTREAM.md に記録されており、fork 側の変更を追う手がかりになる。更新頻度は高く、v0.5.15、v0.5.16、v0.5.17 が2026年8月から9月にかけて立て続けに出ている。内容は role_llms のロール別 api_key 対応、config の KeyError 修正、Web UI の LLM 設定保持といった運用寄りの修正が中心だ。これは裏返すと設定まわりの挙動がまだ動いているということで、バージョンを固定せずに追従すると .env や config の前提が変わりうる。上流の TradingAgents にも同じ変更が入るわけではないため、fork を選んだ時点で上流の改善を自動的に受け取る経路は切れる。追従コストは fork 側のコミットを追う作業として残る。
採用前に確かめる3つの数字
最初に潰すべきはコストの見積もりだ。1回の分析で30〜50回の LLM 呼び出しが発生する。quick 側と deep 側でモデルを分ける前提なので、実際の請求額はどのモデルをどちらに割り当てるかで決まる。次に東方財富の制限下で自分の分析本数が回るかを確認する。既定は1秒以上の間隔なので、多数銘柄を一括処理するなら EM_MIN_INTERVAL を1.5〜2に上げた状態で所要時間を測る必要がある。3点目はライセンスで、Apache-2.0 の帰属表示を自分の配布形態にどう入れるかは、導入前に決めておくべき論点である。これらは法務判断ではなく、設定と運用の前提を先に固めるという話だ。
編集部の結論
A股の制度要因（政策・龍虎榜・解禁）を LLM パイプラインに載せて研究したい個人や少人数チームに向く。リアルタイムの売買シグナル生成や本番運用を期待する用途には向かない。導入前に確認すべきは、1回の分析あたり30〜50回という LLM 呼び出しのコスト、東財リクエストの直列化設定（EM_MIN_INTERVAL）、そして Apache-2.0 の帰属表示義務が自社の再配布形態と噛み合うかどうかの3点である。
コミュニティノート