TauricResearch/TradingAgents

先に断っておくと、これは研究用の枠組みであり、投資助言ではない。作者自身が README でそう明記している。注文が飛ぶ先も模擬の取引所だ。

株の判断を LLM に1回聞いて終わりにすると、その答えがなぜそうなったかを検証できない。TradingAgents はそこを、実在するトレーディング会社の組織図をまねるという形で解いている。役割ごとに別々のエージェントを立て、順番に受け渡していく。まず分析班が4人。財務諸表を見る人、ニュースや景気指標を見る人、掲示板やSNSの空気を集める人、MACD や RSI といった指標を見る人。次に研究班で、強気の担当と弱気の担当がわざと対立させられ、分析班の材料をめぐって決められた回数だけ議論する。討論の回数は設定で変えられる。

そのうえでトレーダー役が売買案（時期と量）を書き、リスク管理班が値動きの荒さや流動性を見て評価をつけ、最後にポートフォリオ責任者が承認するか却下するかを決める。承認された注文は模擬取引所に送られて約定する。土台は LangGraph で、この受け渡しの並びが図として組まれている。一連の流れは Python から TradingAgentsGraph を作って .propagate("銘柄", "日付") を呼ぶだけでも走るし、対話式のコマンドライン画面から銘柄・日付・使うモデル・調査の深さを選ぶこともできる。

このプロジェクトの読みどころは、実は組織図よりも、過去の情報を覗いてしまう問題への手当てのほうにある。過去日付で試すとき、その日にはまだ存在しなかった情報が混ざれば、成績はいくらでもよく見える。更新履歴を見ると、景気指標・SNSの空気・判断の記録それぞれについて、この覗き見を潰す修正が繰り返し入っている。加えて、銘柄記号から会社を特定する処理はエージェントが動く前に確定的に済ませ、価格や指標の記述は検証済みのデータに紐づける、という作りに変えられている。「走らせるたびに別の会社の話になる」「ありもしない株価が出てくる」という報告への対処だと、README に経緯ごと書かれている。実行ごとの記録は判断ログに残り、次に同じ銘柄を分析するときは、実際の値動き（SPY との比較を含む）を取ってきて振り返りを1段落作り、それを責任者役への指示文に差し込む。

複数のエージェントに議論させる設計を、動く実例で見たいとき

役割を分ける、わざと反対の立場を作る、承認の関門を置く、結果を次に持ち越す。多エージェントの設計でよく話題になる要素がひととおり実装されていて、LangGraph で組まれた流れとして読める。題材が投資であることより、組み方のほうに学ぶところがある。

過去日付での検証を、自分で組もうとしているとき

情報の混入をどこで塞ぐかが、更新履歴に具体的な項目として並んでいる。どこから漏れるのかの一覧として読める。

投資助言ではない、と作者自身が明記している。 研究目的の枠組みであり、成績は使うモデル・温度・期間・データの質などで変わる、と README とリンク先の免責に書かれている。この記事も同じ立場で紹介している。

同じ入力でも結果は揺れる。 作者はこれを不具合ではないと説明したうえで、原因を分けている。モデルの出力自体が毎回同じにならないこと、そしてニュースやSNSは「いま」を返すので、過去の日付を指定しても社会の側の材料は変わってしまうこと。掲載されている成績が再現される保証はない、と明言されている。

費用が読みにくい。 分析4人、討論を複数回、審査と承認。1回の判断で LLM が何度も呼ばれる構成なので、銘柄数や討論回数を増やすと費用が伸びる。深く考えるモデルと素早く答えるモデルを分けて指定できるので、そこで調整することになる。

データ提供元の鍵を求められる場合がある。 README では、LLM 各社の鍵と並べて Alpha Vantage の鍵が案内されている（必須とは書かれていない）。市場の対応範囲は Yahoo Finance が扱う範囲と説明されていて、どこまで鍵なしで動くかは、使う機能によるので確かめたほうがいい。市場は、東証（7203.T）や香港（0700.HK）など、記号に取引所の接尾辞を付けて指定できる。

ライセンスは Apache-2.0。論文（arXiv:2412.20138）が併記されている。