AI Hedge Fund：13人の投資家AIがLangGraphで議論して1つの判断を出す教育目的のマルチエージェント設計
AI Hedge Fund は、著名投資家を模した複数のAIエージェントがLangGraph上で議論し、1つの判断へ統合する設計。本稿はその仕組みを中立的に解説する（教育・研究目的のシミュレータ）。
はじめに：本記事は投資助言ではありません
本記事は投資・売買を一切すすめるものではなく、損益や有利・不利にも触れません。扱うのは「AI Hedge FundというOSSが、複数のAIエージェントをLangGraphでどう組み合わせて1つの判断に統合しているか」という技術的な設計だけです。AI Hedge Fund自身も公式READMEで 「educational purposes only（教育目的のみ）／real tradingを意図しない」 と明記しています。マルチエージェント設計の学習を目的とした中立的な解説であり、実際の投資判断・是非は各自の責任と各国の法規制に従ってください。

「複数のAIに、それぞれ別の専門家の視点で同じ問題を考えさせ、最後に1つの結論へまとめる」——これは、いまマルチエージェント設計でもっとも面白いテーマの一つです。AI Hedge Fund は、その発想を「著名投資家の思考スタイルを模したAIたちに銘柄を分析させる」という分かりやすい題材で実装した、Python製のオープンソース（MITライセンス、⭐61,000超）です。作者の virattt 氏はこれを 「a proof of concept（概念実証）」 と呼び、README冒頭で「educational purposes only（教育目的のみ）」と念を押しています。

本サイトは AI関連OSSの設計解説 に特化しているため、本稿では「儲かるか」「どう投資するか」といった話は一切扱いません。取り上げるのは、13体の投資家ペルソナAI＋分析・リスク・統合のエージェントを、LangGraphの有向グラフでどう配線しているか という技術的な設計だけです。取引という題材を抜きにしても、「役割特化のエージェントを並列に走らせ、その意見を1つの意思決定へ統合する」というパターンは、レビュー・審査・分類など多くの実務に応用できます。この記事は 2026年7月12日（JST）時点 の公式リポジトリ（README / VISION / ROADMAP / ソースコード）をもとに整理しています。

この記事のポイント
  • ・本記事はマルチエージェント設計の技術解説。投資助言・損益・推奨の話は一切しない。
  • ・AI Hedge Fund（MIT・Python）は13体の投資家ペルソナAI＋分析/リスク/統合エージェントで構成。
  • ・各エージェントは「強気/弱気/中立＋確信度＋理由」という構造化信号を返し、LangGraphで配線される。
  • ・設計思想は「LLMは意見、コードが判断」——数量計算・リスク上限・発注は決定的コードが担う。
  • ・投資家ペルソナは本人でも推奨でもなく、公開された哲学を近似したプロンプトにすぎない。

AI Hedge Fundとは：13人の投資家AIが議論する「教育目的のシミュレータ」

AI Hedge Fund は、ひとことで言えば 「複数のAIエージェントに投資家の役を演じさせ、その意見を1つの判断へ統合する仕組み」 を実装したOSSです。名前に「Hedge Fund（ヘッジファンド）」とありますが、公式READMEには 「Note: the system does not actually make any trades（このシステムは実際には取引を行いません）」 とはっきり書かれています。つまり実体は、お金を動かさずにマルチエージェントの意思決定パイプラインを観察・実験できる教育用シミュレータ です。

システムに登場する「AI」は、大きく3種類に分けられます。

・投資家ペルソナ・エージェント（13体）：バフェット、マンガー、ベン・グレアム、ビル・アックマン、キャシー・ウッド、マイケル・バーリ、ピーター・リンチ、フィル・フィッシャー、スタンレー・ドラッケンミラー、ナシーム・タレブなど、実在の著名投資家の「公開された投資哲学」を模したエージェント
・分析エージェント（4体）：Valuation（本質的価値の計算）、Sentiment（市場センチメント）、Fundamentals（財務指標）、Technicals（テクニカル指標）という、投資家名ではなく機能で分かれたエージェント
・統合・制御エージェント（2体）：Risk Manager（ポジション上限などのリスク指標を計算）と Portfolio Manager（全信号を統合して最終アクションを出す）

README の一覧では合計19体のエージェントが挙げられており、そのうち投資家の名を冠したペルソナが13体です。重要なのは、これらのエージェントが「同じ入出力の形」を共有している こと——各エージェントは銘柄（ティッカー）を受け取り、決まった構造の「信号（Signal）」を返します。この統一されたインターフェースがあるからこそ、エージェントを足したり外したり、LLMを差し替えたりが自由にできます。

AI Hedge Fundの公式アーキテクチャ図：Startから投資家エージェント群へ、Risk Manager・Portfolio Managerを経てbuy/sell/hold等のアクションへ
公式READMEのアーキテクチャ図。Start→各エージェント→Risk Manager→Portfolio Manager→アクション（buy/cover/sell/short/hold）という一方向の流れ。（出典：公式リポジトリ）

プロジェクトは現在、初代の実装（src/ 配下）に加えて、「常時稼働する永続的なファンド」への作り替え（v2/ 配下）が進んでいます。VISIONによれば、アナリストを差し替え可能な「アルファモデル」として再定義し、バックテスト・ペーパートレード・（オプトインの）ライブ運用を同じパイプラインで回す構想です。ただしVISIONには 「Much of this is aspirational（多くは構想段階）」 と正直に書かれており、本稿では「今あるもの」を中心に、構想は構想として区別して扱います。

アーキテクチャ全体像：LangGraphで組む「分析→リスク→統合」パイプライン

AI Hedge Fund の心臓部は、エージェントたちの 配線（オーケストレーション） です。ここに使われているのが LangGraph——LangChain チームが開発する、状態を持つ有向グラフ（stateful graph）でLLMアプリの制御フローを書く ためのライブラリです。ノードが「処理（エージェント）」、エッジが「次に誰が動くか」を表し、分岐・並列・ループを明示的に記述できます。

実際のコードでは、StateGraph に各エージェントをノードとして登録し、エッジで順番を定義しています。要点を抜き出すと、次のような素直な構造です。

from langgraph.graph import END, StateGraph

workflow = StateGraph(AgentState)
workflow.add_node("start_node", start)

# 選ばれた投資家/分析エージェントを並列にぶら下げる
for node_name, node_func in analyst_nodes:
    workflow.add_node(node_name, node_func)
    workflow.add_edge("start_node", node_name)        # Start から各エージェントへ
    workflow.add_edge(node_name, "risk_management_agent")  # 各エージェント → Risk

workflow.add_node("risk_management_agent", risk_management_agent)
workflow.add_node("portfolio_manager", portfolio_management_agent)
workflow.add_edge("risk_management_agent", "portfolio_manager")  # Risk → Portfolio
workflow.add_edge("portfolio_manager", END)                       # Portfolio → 終了
agent = workflow.compile()

ポイントは、投資家エージェントたちが「Start から並列にぶら下がる」 ところです。各エージェントは互いに直接会話するのではなく、それぞれ独立に同じ銘柄を分析し、自分の信号だけを出す。その全部が Risk Manager に集まり、さらに Portfolio Manager に集約されて1つの判断になります。これは「エージェント同士が延々とチャットで議論する」タイプの設計とは対照的で、責任の分界点がはっきりしていて、再現性・デバッグ性が高い のが特徴です。

グラフを流れる「状態（AgentState）」も明快で、messages（会話メッセージ）・data（分析データ）・metadata（設定）の3つを持つ TypedDict です。各エージェントは data に自分の分析結果を書き込み、後段がそれを読む——という共有メモリ型の受け渡しになっています。1回の実行（VISIONでは「1 cycle」と呼ぶ）は、データ取得 → 各エージェントが信号を生成 → リスクで上限を計算 → ポートフォリオで統合 → 記録 という一巡です。図にすると次の通りです。

flowchart LR A["市場データ
価格・財務・ニュース"] --> B{"13体の投資家AI
＋分析エージェント
（並列に分析）"} B --> C["各自の Signal
強気/弱気/中立
＋確信度＋理由"] C --> D["Risk Manager
ポジション上限を計算"] D --> E["Portfolio Manager
全シグナルを統合"] E --> F["最終アクション
buy / sell / short / cover / hold"]

VISIONで強調される設計原則の一つに 「Point-in-time honesty（その時点で実際に公開されていたデータしか使わない）」 があります。過去日付でシミュレーションするとき、未来の情報を覗き見しない（no lookahead）という規律で、バックテストを意味のあるものにするための工夫です。技術的には地味ですが、「検証が自己欺瞞にならないための制約を、設計の第一級市民として置く」 という姿勢は、AIシステム一般にも通じる考え方です。

作り替え中の v2 では、この一巡（run_cycle）を 「1つのエンジン・3つのモード」 で回す構想が示されています。すなわち、同じパイプラインを BACKTEST（過去の時計＋擬似ブローカー）／PAPER（現在の時計＋擬似ブローカー・仮想資金）／LIVE（現在の時計＋実ブローカー） の3モードで動かし、変わるのは「時計」と「ブローカー」だけ、という設計です。ここで注目すべきは安全側の既定値で、VISIONには 「Paper before real, always. Live trading is opt-in and off by default（ペーパーが先、ライブはオプトインで既定オフ）」 と明記されています。つまり 「実運用は、明示的に有効化しない限り決して走らない」 ことが設計として担保されている——AIに意思決定を任せるシステムほど、こうした「危険な側を既定で無効化する」フェイルセーフが効いてきます。なお、これらの多くはROADMAP上「構想・実装途上」であり、本稿は現時点の到達点として区別して紹介しています。

投資家ペルソナAIの設計：バフェットやマンガーはどう”近似”されるのか

このプロジェクトでもっとも誤解されやすいのが、「投資家ペルソナ」の正体 です。結論から言うと、各ペルソナは その投資家本人でも、その人の推奨でもなく、「公開された投資哲学」をプロンプトとして近似したもの にすぎません。VISIONにも 「stylized approximations of these investors’ public philosophies — not the actual individuals, and not endorsements（公開された哲学の様式化された近似であり、本人でも推奨でもない）」 と明記されています。

投資家ペルソナの正体：本人や推奨・未来予測ではなく、公開された哲学を近似したプロンプトで、出力は強気/弱気/中立＋確信度＋理由という一票にすぎない
ペルソナは本人でも推奨でもない。公開された投資哲学を近似したプロンプトで、出力は「一票」にすぎない、という線引き。

エージェントの中身を見ると、「決定的なコードによる数値分析」と「LLMによる言語的な判断」を組み合わせている ことが分かります。たとえばバフェット・エージェントは、まず Python の関数で財務指標を計算します——ROE（自己資本利益率）の一貫性、営業利益率の安定性、といった「モート（競争優位）」の指標をスコア化する。そのうえで、計算済みの事実だけをLLMに渡し、最終的な信号を作らせます。LLMに与えられるシステムプロンプトは、驚くほど規律的です。

You are Warren Buffett. Decide bullish, bearish, or neutral using only the provided facts.

Checklist for decision:
- Circle of competence   （自分の能力の輪の内か）
- Competitive moat        （堀＝競争優位はあるか）
- Management quality       （経営の質）
- Financial strength       （財務の頑健さ）
- Valuation vs intrinsic value （本質的価値に対する割安/割高）
- Long-term prospects      （長期の見通し）
...
Keep reasoning under 120 characters. Do not invent data. Return JSON only.

注目したいのは末尾の 「Do not invent data.（データを捏造するな）」「Return JSON only.（JSONだけ返せ）」 という指示です。LLMに自由作文をさせず、与えた事実の範囲内で、決まった形式の答えだけを出させる ——これは、LLMをソフトウェアの部品として安全に使うための定石です。そして各エージェントが返す信号は、Pydantic のモデルで型が固定されています。

from pydantic import BaseModel, Field
from typing_extensions import Literal

class WarrenBuffettSignal(BaseModel):
    signal: Literal["bullish", "bearish", "neutral"]  # 強気/弱気/中立
    confidence: int = Field(description="Confidence 0-100")  # 確信度
    reasoning: str = Field(description="Reasoning for the decision")  # 理由

この「Literal で選択肢を固定＋確信度は0-100の整数＋理由は文字列」という三点セットが、全ペルソナで共通のインターフェースです。バフェットもマンガーもキャシー・ウッドも、内部のプロンプトと分析ロジックは違っても、出口の形はまったく同じ。だからこそ後段は、どのエージェントの意見も同じように扱って集計できます。ペルソナごとの「個性」は、参照する財務指標の重みづけや、システムプロンプトに書かれた投資哲学（グレアムは「安全域のある割安株だけ」、キャシー・ウッドは「破壊的イノベーション」など）で表現されます。

ペルソナごとの違いは、コードを読むとより具体的に見えてきます。たとえばバフェット・エージェントは analyze_moat（モート分析）という関数で、ROE（自己資本利益率）の一貫性や営業利益率の安定性を数値化し、「価格決定力のある堀があるか」をスコア化します。同じ財務データを受け取っても、グレアム寄りのエージェントは「安全域（margin of safety）」を重く見て割安さを問い、成長株志向のエージェントは売上やイノベーションの勢いを重く見る——同じ入力に対して、どの指標をどう重みづけするかがペルソナの個性 になっているわけです。プロンプトの投資哲学（言葉）と、分析関数の重みづけ（数値）の両輪で「その投資家らしさ」を近似している、と理解すると腑に落ちます。

念のため繰り返すと、これは 「バフェットならこう考えそうだ、という様式化された近似」 であって、本人の見解でも投資推奨でもありません。confidence（確信度）も、モデルが自己申告する数値であって、当たる確率ではない——この区別は、AIの出力を扱ううえで常に意識すべき点です。実在の人物を模したエージェントを作るときは、「本人ではない・推奨ではない」という線引きを設計にもドキュメントにも明記する のが誠実なやり方で、AI Hedge Fund はそれをVISIONで丁寧に行っています。

Portfolio ManagerとRisk Manager：LLMは「意見」、コードが「判断」

各エージェントが「一票」を投じたあと、それを1つの行動へまとめるのが Risk Manager と Portfolio Manager です。ここに、このプロジェクトの背骨とも言える設計思想が表れています。VISIONの言葉を借りれば 「The LLM never touches the trade（LLMは取引そのものには決して触れない）」。すなわち——

・LLMが担うのは「意見（views）」と「説明（narration）」だけ。ペルソナは信号と理由を生成する
・数量の計算・発注・リスク上限の適用は、決定的なコードが担う。ここにLLMの気まぐれを入れない
・リスク上限は、エージェントが超えられない「硬いゲート（hard gates）」。conviction requests, risk disposes（確信は要求するが、可否はリスクが決める）

Portfolio Manager が最終的に出す判断も、やはり型が固定されています。

class PortfolioDecision(BaseModel):
    action: Literal["buy", "sell", "short", "cover", "hold"]  # 取り得る行動を限定
    quantity: int = Field(description="Number of shares to trade")   # 数量
    confidence: int = Field(description="Confidence 0-100")
    reasoning: str = Field(description="Reasoning for the decision")

class PortfolioManagerOutput(BaseModel):
    decisions: dict[str, PortfolioDecision]  # ティッカーごとの決定

action が Literal["buy","sell","short","cover","hold"] に限定されている点が重要です。LLMが「なんとなく強気っぽい文章」を返しても、それがそのまま行動になるわけではない。取り得る選択肢はあらかじめコード側で有限に決められていて、さらに Risk Manager が計算したポジション上限によってクランプ（上限で頭打ち）や拒否がかかります。LLMは「こう思う」と主張できるだけで、「いくら動かすか」「そもそも動かしてよいか」は決定的なロジックが握っているわけです。この関係を図にすると次のようになります。

flowchart TB subgraph LLM["LLMが担当：意見と説明"] A1["投資家ペルソナ
Signalと理由を生成"] end subgraph CODE["決定コードが担当：数量と可否"] B2["Risk Manager
硬い上限でクランプ/拒否"] B1["Portfolio Manager
数量を計算し行動を確定"] end A1 -->|"一票として渡す"| B2 B2 --> B1 B1 --> C["記録：判断・理由・（v2ではNAV）"]

この「判断の生成（柔らかいLLM）と、判断の執行（硬いコード）を分離する」という考え方は、取引に限らず応用が利きます。たとえば、LLMに与信の所見を書かせつつ、実際の融資可否や上限はルールエンジンが持つ。LLMにコンテンツの危険度を評価させつつ、公開/非公開の最終判定は決定的なポリシーが下す。AIに意見を言わせても、後戻りできない行動の引き金はコードに握らせておく ——AIエージェントを実務に入れるときの、堅実な設計原則です。

LangGraph / CrewAI / AutoGen / MetaGPT：マルチエージェント基盤を技術で比較

AI Hedge Fund は「マルチエージェントの一実装例」です。では、他のマルチエージェント基盤と何が違うのでしょうか。ここでは代表的な4つ——LangGraph・CrewAI・AutoGen・MetaGPT——を、設計の抽象化レベル という技術軸で並べてみます（優劣ではなく、向き不向きの整理です）。

マルチエージェント基盤の立ち位置：ai-hedge-fundはLangGraph上の実装例、LangGraphはグラフ基盤、CrewAI/AutoGenは役割・会話フレーム、MetaGPTはSOP駆動
マルチエージェント基盤の技術的な立ち位置。AI Hedge FundはLangGraphを土台にした「題材特化のサンプル」に当たる。
基盤 抽象化の単位 制御の粒度 位置づけ（技術面）
AI Hedge Fund 役割特化エージェント＋統合層 LangGraphのグラフを直接記述 特定題材（投資判断）に特化した実装例
LangGraph 状態＋有向グラフのノード 分岐・並列・ループを明示制御 AI Hedge Fundが採用する低レベルの土台
CrewAI 役割を持つエージェントの「クルー」 タスク委譲・協調を高レベルに抽象化 役割分担を素早く組みたいとき
AutoGen 会話するエージェント群 メッセージのやり取りが主体 対話ループ・人間介在を含む探索的タスク
MetaGPT SOP（標準作業手順） 成果物駆動のワークフロー 疑似”会社”のように工程を回す

ざっくり言うと、CrewAI や AutoGen は「役割と会話」を高レベルに抽象化 しており、「エージェントAとBに話し合わせる」ことを数行で書けます。MetaGPT は「標準手順（SOP）」を軸に、成果物を作らせる工程管理 に寄っています。それに対して LangGraph は、より低レベルで「状態機械としての制御フロー」を自分で書く ライブラリです。

AI Hedge Fund があえて LangGraph を選んでいるのは、「誰が・どの順で・並列に動き、どこで集約するか」を厳密にコントロールしたい からだと読み取れます。投資判断のように「複数の独立した意見を集めて、決定的なリスク制御をかけて、1つの行動に落とす」処理は、会話ベースの緩い協調よりも、明示的な有向グラフのほうが素直に書けて、再現性も高い。マルチエージェントと聞くと「エージェントが自由に議論する」姿を想像しがちですが、実務では AI Hedge Fund のように”議論”を構造化して固定する ほうが、扱いやすいことが多いのです。

もう一つ、選定の判断材料になるのが 「エコシステムとの地続きさ」 です。AI Hedge Fund は LangChain 経由で多数のLLMプロバイダ（OpenAI・Anthropic・Groq・DeepSeek・Google・xAI・ローカルのOllama）を差し替えられますが、これは LangGraph が LangChain と同じ土台の上にあるからこそ自然に効いてきます。CrewAI・AutoGen・MetaGPT はいずれも「役割協調をどう簡潔に書くか」に強みがある一方、AI Hedge Fund が必要としたのは 「決定的な集約とリスク制御を、グラフの構造そのもので表現する」 ことでした。どのフレームワークが優れているかではなく、作りたい制御フローの形に合わせて土台を選ぶ ——この観点は、自分でマルチエージェントを設計するときにもそのまま使えます。会話の自由度が欲しいのか、工程の再現性が欲しいのかで、選ぶべき抽象化のレベルは変わってきます。

Web UI・CLI・バックテスト：AI Hedge Fundの動かし方（技術面）

最後に、このシミュレータを「どう動かせる形になっているか」を技術的に見ておきます。実際の投資に使うためのガイドではなく、エンジニアとして構成を理解するための整理 です。動かし方は大きく3つあります。

① コマンドライン（CLI）。Poetry で依存を入れ、ティッカーを指定して実行します。少なくとも1つのLLM APIキーと、財務データ用の FINANCIAL_DATASETS_API_KEY を .env に設定する構成です。

# 依存関係のインストール（Poetry）
poetry install

# 銘柄（ティッカー）を指定して1回分の分析を走らせる
poetry run python src/main.py --ticker AAPL,MSFT,NVDA

# --ollama を付ければローカルLLMで動かせる
poetry run python src/main.py --ticker AAPL,MSFT,NVDA --ollama
AI Hedge FundのCLI実行画面：各エージェントの分析ステータスが順に表示される
CLI実行の様子。各エージェントの分析ステータスが順に流れる。（出典：公式README）

② バックテスト。backtester.py を使うと、過去の期間についてシミュレーションを回せます。ここで効いてくるのが前述の「point-in-time honesty」——その日時点で実際に公開されていたデータしか使わない という制約です。--start-date --end-date で期間を、--ollama でローカルLLMを指定できます。

# 過去期間でのシミュレーション（教育・検証目的）
poetry run python src/backtester.py --ticker AAPL,MSFT,NVDA \
  --start-date 2024-01-01 --end-date 2024-03-01
AI Hedge Fundのバックテスト出力例：銘柄ごとのシグナルやアクションが表形式で並ぶ
バックテスターの出力例。銘柄ごとの分析結果が表形式で確認できる（数値は例示であり、成績を示すものではない）。（出典：公式README）

③ Web アプリ。新しい動かし方として、ノードを線でつないでエージェントの流れを組み立てる Web UI が用意されています。画面では、Portfolio Manager をスタートノードにして、Warren Buffett（”The Oracle of Omaha”）や Charlie Munger（”The Rational Thinker”）といったエージェントノードを配置し、出力（JSON Output）へつなぐ——というビジュアルなグラフ編集ができます。各ノードには「In Progress」「Generating Warren Buffett analysis」のように進捗が表示され、まさに前半で見た LangGraph の有向グラフを、目で見て触れる形にしたものです。

AI Hedge FundのWebアプリ画面：Portfolio Managerを起点にWarren Buffett・Charlie MungerノードをつないでJSON Outputへ流すビジュアルなフロー編集
Webアプリのフロー編集画面。エージェントをノードとして配置し、線でつないで実行できる。（出典：公式README）

3つの動かし方に共通するのは、「同じパイプラインを、粒度を変えて観察できる」 ことです。CLIは自動化・スクリプト向き、バックテスターは過去データでの検証向き、Web UIは構成を視覚的に理解する学習向き。エンジニアの視点では、LLMプロバイダを差し替え可能にし、エージェントをプラガブルにし、同じ制御フローを複数のフロントエンドから叩けるようにする という、拡張性を意識した作りが参考になります。ここで示したコマンドは構成理解のための例であり、実運用を勧めるものではありません。

まとめ：AI Hedge Fundから学べる設計と、投資助言ではないという線引き

AI Hedge Fund は、「著名投資家を模したAIに銘柄を分析させる」という親しみやすい題材を借りて、マルチエージェント設計の要点を一望できる、よくできた教材 です。技術的な持ち帰りを3つに絞るとこうなります。

・役割特化のエージェントを並列に走らせ、統一インターフェース（強気/弱気/中立＋確信度＋理由）で意見を集約する。個性はプロンプトと分析ロジックで表現し、出口の形は揃える
・「LLMは意見、コードが判断」。数量・可否・リスク上限といった後戻りできない部分は決定的コードに握らせ、LLMの出力は一票として相対化する
・検証の誠実さ（point-in-time honesty）を設計の第一級市民に置く。未来を覗かない制約が、シミュレーションを意味あるものにする

これらは投資という題材を超えて、レビュー・審査・分類・異常検知 など「複数の視点で評価して1つの判断へ統合する」あらゆる場面に応用できる設計パターンです。

重要な注意：これは教育・研究目的のシミュレータです
本記事で扱った AI Hedge Fund は、公式に 「proof of concept／educational purposes only」 と位置づけられた実験的プロジェクトであり、実際には取引を行いません（does not actually make any trades）。作者もREADMEで 「real tradingを意図しない・投資助言ではない・損失の責任は負わない・過去の成績は将来を保証しない」 と明記しています。本記事も同様に、投資の推奨・助言・成績の示唆を一切行いません。AIによる相場予測が当たる保証はどこにもなく、確信度（confidence）は的中率ではありません。実際の投資判断や本番運用の可否は、リスクを十分理解したうえでの各自の責任と、各国の法規制に従ってください。
結論
AI Hedge Fund の価値は「儲かるかどうか」ではなく、「複数のAIの意見を、決定的なリスク制御を挟んで、1つの行動へ統合する」設計をまるごと読める点にある。役割特化エージェント＋統一インターフェース、LLMとコードの責任分離、検証の誠実さ——この3つは、取引という題材を外しても通用するマルチエージェントの型だ。AIに意見を言わせつつ、後戻りできない引き金はコードに握らせる。この線引きこそ、本プロジェクトから持ち帰るべき最大の教訓である。（再掲：本記事は投資助言ではなく、いかなる取引も推奨しない）

参照ソース

・virattt/ai-hedge-fund（公式GitHubリポジトリ）
・AI Hedge Fund — VISION.md（設計思想）
・AI Hedge Fund — ROADMAP.md（実装状況）
・LangGraph（公式ドキュメント）
・AIエージェントとは？仕組み・種類・代表的OSSフレームワーク【2026年版】（本サイト・ピラー）