TL;DR
- AIエージェント運用は プロンプト → ループ → スワーム → グラフ の順に進化する。「グラフエンジニアリング」とは、複数エージェントの協調構造（誰が並列で、誰が待ち、どこで再試行・エスカレーションするか）を一度だけ宣言的に設計する実践のこと。
- スクリプトが壊れる 3 つの壁（① あるエージェントが別のエージェントを待つ、② サイクルをまたいで状態を保つ、③ 複数ループを並列に回す）を、グラフは構造として吸収する。
- 具体例として、ヘッジファンドが使う多因子アルファモデルを「7 つの並列な因子ノード＋4 つの逐次な調整ノード」の 11 ノード・グラフとして組む設計を読み解く。検証は必ず作り手とは別のノードにやらせる（maker-checker）。
- 元記事は特定ツール（Slate）の宣伝色が強いが、持ち帰るべきは「協調構造を宣言的に設計する」という考え方であって、ツールそのものではない。ここはフレームワークに依らず移植できる。
きっかけ：プロンプトの次に来る「4 段階」
X で流れてきた長文記事 How to Use Graph Engineering to Build a Multi-Factor Alpha Model（著者 Roan、X: @RohOnChain）が出発点だ。定量投資（クオンツ）の文脈だが、AIエージェントの運用レベルを 4 段階で整理するフレームが AI 開発全般に効くので、そこを軸に紹介する。
記事いわく、AI を使うクオンツは全員この進化のどこかにいる。今どこにいるかを名指しすると、次に何をすべきかが見える。
- プロンプト（Stage 1） — あなたがプロンプトを打ち、出力を読み、次を打つ。あなた自身がループであり、ラップトップを閉じれば何も残らない。
- ループ（Stage 2） — プロンプトをスクリプトで包み、スケジュールで発火させる。ループが状態を持ち、閉じても走り続ける。「1 エージェント・1 ジョブ」を永続化した段階。
- スワーム（Stage 3） — ループを役割ごとに多数のエージェントへ扇状に展開する。信号生成・検証・執行をそれぞれ別エージェントが担う。ただし調整は手書きの Python グルーコードでつなぐ。
- グラフ（Stage 4） — 協調構造を一度だけ記述する。ノードがエージェント、エッジがデータの受け渡し。いつ並列に、いつ待ち、いつ再試行し、いつエスカレーションするかをグラフが知っている。グルーコードにはもう触らない。
このブログでも「ループエンジニアリング」は繰り返し扱ってきたが、その先にある「スワームを一枚のグラフにまとめる」段階が今回のテーマだ。
なぜスクリプトは壊れ、グラフエンジニアリングが効くのか
グラフとスクリプトの違いは、思っている以上に本質的だ。スクリプトは次の 3 つの瞬間に壊れる。
- あるエージェントが別のエージェントの完了を待つ必要が出たとき
- 状態をサイクル（実行の周回）をまたいで保持しなければならなくなったとき
- 異なるモデルで複数のループを並列に回したくなったとき
マルチエージェントを手で組んだ人はほぼ全員がこの壁に当たる。元記事の著者も「収益性エージェントが 500 社分のバランスシートを解析中にレートリミットで詰まり、パイプライン全体が死んだ。翌朝は停止したプロセスと、原因不明の無出力だけが残っていた」と振り返る。デバッグは、スタックトレースを読んで「どのエージェントが上流か」を推測する作業になる。研究より調整に時間を溶かす——これがマルチエージェント・クオンツの典型的な失敗状態だ。
グラフはこの失敗モードを構造的に持たない。
- 並列がネイティブ — 扇状の同時実行が前提。
- 状態が永続的 — 周回をまたいで持ち越す。
- 失敗がノードに限定される — 1 ノードが壊れても残りのグラフは走り続け、壊れたノードだけを自然文で直す。
題材：多因子アルファモデルを 11 ノードで組む
グラフエンジニアリングを体感する題材として、記事はヘッジファンドの多因子（マルチファクター）投資を選んでいる。AQR や Two Sigma のような運用会社は単一のアイデアでは張らず、複数の**ファクター（＝因子。リターンの系統的な源泉）**を積み上げる。以降、学術モデル名は「ファクター」、グラフのノードとして数えるときは「因子」と表記する。
理論的な土台は Fama-French の 3 ファクターモデル（1993）だ。株式リターンを「市場・サイズ・バリュー」に分解し、モデルが説明できない残差 α（アルファ）こそが狙う対象になる。その後 Carhart がモメンタムを加え（1997、4 ファクター）、Fama-French が収益性（RMW）と投資（CMA）を追加した（2015、5 ファクター）。
注意: 記事は低ボラティリティを加えた「7 ファクター」を挙げるが、「7 ファクターモデル」は正式な学術モデル名ではない。低ボラティリティ・アノマリー自体は実在するが、ここは各運用会社が実務的に拡張した構成、と理解するのが正確だ。
この 7 因子を、それぞれ 1 つのノードにする。全体像は次のとおり。
並列に走る 7 つの因子構築ノード
高速なモデル（記事では sonnet エイリアス）で回す、独立した計算だ。
| ノード | 因子 | 計算内容 |
|---|---|---|
| ① | 市場ベータ | 超過リターンを市場に対して 60 ヶ月ローリング回帰 |
| ② | サイズ (SMB) | 時価総額でソートし小型−大型のスプレッド |
| ③ | バリュー (HML) | 簿価/時価でソートし高−低のスプレッド |
| ④ | モメンタム | 12−1 ヶ月リターンのデシルスプレッド |
| ⑤ | 収益性 (RMW) | 粗利益性から構築 |
| ⑥ | 投資 (CMA) | 年間資産成長率から構築 |
| ⑦ | 低ボラティリティ | 直近 60 日の実現ボラティリティのデシルスプレッド |
逐次に走る 4 つの調整ノード
こちらは強い推論モデル（記事では opus エイリアス）で、順番に流す。
- ⑧ バリデータ — Newey-West 調整の t 統計（自己相関・不均一分散に頑健な標準誤差）とブートストラップ 1 万回で検定。イン/アウトサンプルの劣化が 30% を超える因子を棄却する。ここが maker-checker の要で、因子を作ったノードとは別のモデルに検証させる。
- ⑨ レジーム監査 — Hidden Markov Model で 20 年の歴史を 3 つのレジームに分割し、単一レジームでしか効かない因子を棄却する。「1 つの相場でしか効かないものは α ではなく、そのレジームへのβを α に見せかけているだけ」という発想だ。
- ⑩ ポートフォリオ構築 — 生き残った因子をリスクパリティで合成し、セクター・ベータ・ダラーニュートラルを強制する。
- ⑪ リスク分解 — ポートフォリオを 7 因子＋スタイル＋マクロで回帰し、残差 α の t 値が 2.5 を超えたものだけを「本物の新しい α」と判定する。
このグラフ全体が 1 つのプログラムとして 24 時間おきに発火し、毎朝「取引できる信号があるか／今日はノイズだった証拠」のどちらかが Slack に届く。どちらの結果も有用で、どちらもキーボードの前にいる必要がない——これが自走するグラフの姿だ。
この設計から持ち帰れること
元記事は特定ツール（後述の Slate）の導入記事の色が濃い。だがツールに依存しない設計原則として抜き出せるものが多い。
- 協調構造を「宣言的に一度だけ」書く — グルーコードを毎回書き直すのではなく、ノード（役割）とエッジ（受け渡し）を定義する。あとの並列・待ち・再試行はランタイムに任せる。
- 並列と逐次を意識して分ける — 独立に計算できるもの（7 因子）は並列、依存関係があるもの（検証→構築→分解）は逐次。同期ポイントで合流させる。
- 役割ごとにモデルを使い分ける — 数の出る単純作業は高速モデル、判断が要る検証・分解は強い推論モデル。コストと品質のバランスを構造で決める。
- 作り手に自分を検証させない（maker-checker） — これは金融の「four-eyes principle（四つの目の原則）」に由来し、AIエージェントでは Anthropic の Evaluator-Optimizer や Andrew Ng の Reflection パターンに対応する実在の設計原則だ。同一モデル・同一コンテキストの自己検証は「検証」ではなく「二度実行」にすぎない、という点も過去記事「AIエージェントにリファクタさせるときの完了の定義の引き方」で触れたとおり。
- 失敗をノードに閉じ込め、状態を永続化する — 1 ノードの失敗で全体を止めない。状態をタイムスタンプ付きで残し、周回をまたいで再開できるようにする。
多因子モデルという題材はクオンツ固有だが、この 5 つはコード監査・リサーチ・データパイプラインなど、およそ「複数エージェントを協調させる」あらゆる場面にそのまま効く。
ランタイムについての注記（Slate）
グラフは設計図であり、それ自体では動かない。動かすにはランタイムが要る。元記事はランタイムとして Slate（Random Labs 製、Y Combinator 出資）を挙げている。ターミナルで動く「スワームネイティブ」なエージェントだ。npm i -g @randomlabs/slate で導入でき、既存のモデルサブスクリプション（Codex や Copilot など）に処理を扇状に振り分けられる。ここまでは公式ドキュメントでも確認できる事実だ。
一方で、記事が挙げる同梱 Program の具体名（/goal や /deepresearch）や slate run といったコマンドは、公式ドキュメントでは裏付けが取れなかった。ユーザー向けの機能名は “Skills” と呼ばれている可能性がある。導入を検討する場合は、記事のコマンド例をそのまま信じず公式ドキュメントで確認してほしい。
モデル ID についても一点。記事には claude-opus-4.5 などの表記が出るが、これは執筆時点の値で、現行の最上位は Claude Opus 4.8、Sonnet も Sonnet 5 が登場済みだ。記事のコード例自体は model: 'opus' / model: 'sonnet' のようなエイリアスを使っており、具体的なバージョン番号に依存しない書き方をしておくのが安全だ。
なお元記事には「最初の 20 人を個別サポートする」といった誘導や紹介リンクが含まれる。ツール選定は、こうした販促と技術的な中身を切り分けて判断したい。ここで価値があるのは繰り返すが**「グラフとして協調構造を設計する」考え方**であって、どの製品を使うかは二の次だ。
まとめ
- AIエージェントの運用は プロンプト → ループ → スワーム → グラフ と進化する。グラフエンジニアリングは、その最終段——協調構造を宣言的に設計する実践だ。
- スクリプトが壊れる 3 つの壁（待ち・状態・並列）を、グラフは構造で吸収する。並列がネイティブ、状態が永続、失敗がノードに限定される。
- 多因子アルファモデルは「7 並列の因子ノード＋4 逐次の調整ノード」の 11 ノードで表現でき、検証は必ず作り手とは別ノード（maker-checker）に任せる。
- ツールやモデルは入れ替え可能。「協調構造を一度だけ宣言的に設計する」という考え方そのものが、マルチエージェント時代の再現性を支える。