hdknr blog

グラフエンジニアリング

AIエージェント運用の第4段階。仕事をノード（判断）とエッジ（データの受け渡し）のグラフとして設計し、並列・待ち・再試行・検証を構造として宣言する実践

概要

グラフエンジニアリングとは、複数エージェントの協調構造を宣言的に一度だけ設計する実践。ノードがエージェント（判断）、エッジがデータの受け渡しにあたり、「いつ並列に走り、いつ待ち、いつ再試行し、いつエスカレーションするか」をグラフ自体が知っている状態を目指す。

出発点は「AIエージェント運用は プロンプト → ループ → スワーム → グラフ の順に進化する」という 4 段階モデル。ただしこのモデルの正しい使い方は今どこにいるかを名指しすることであって、段階を「導入すべきツール名」として消費すると、すでに持っているものを別の名前で買い直すことになる。

なお 4 段階モデルは「段階が進むと前の段階が不要になる」とは言っていない。LangChain 自身が「ループは単純なグラフにすぎず、ループエンジニアリングはグラフの代替ではなくその簡略版である」と述べており、グラフの各ノードは依然としてループである。この積み重なりの構造は AIエージェント設計レイヤー で整理している。

4 段階モデル

段階内容限界
1. プロンプト人がプロンプトを打ち、出力を読み、次を打つ。人間自身がループラップトップを閉じれば何も残らない
2. ループスクリプトで包みスケジュールで発火。状態を持ち自走する「1 エージェント・1 ジョブ」に留まる
3. スワーム役割ごとに多数のエージェントへ扇状展開。信号生成・検証・執行を分業調整が手書きのグルーコード
4. グラフ協調構造を宣言的に一度だけ記述。ランタイムが並列・待ち・再試行を知る適用範囲は「幅」に限られる（後述）

Stage 3 → 4 の境目は「宣言的な協調記述があるか」だけ。手書きグルーコードで束ねているのは欠陥ではなく Stage 3 の定義そのものである。

「名詞」ではなく「性質」で自己診断する

段階は次のような性質に分解して、実装が満たすかどうかで判定する。

実在の自律トレーディングシステムをこの表で診断した例では、宣言的記述以外はすべて満たしており「すでに教科書どおりのスワームだった」という結論になった。測定可能なエッジが無いなら Stage 4 への移行は非推奨、という判断もあり得る。

ノードとエッジの規律

エッジは「データが渡るとき」だけ存在する

最も多い間違いは、「その後で」をエッジとして扱うこと。

「このファイルを要約して、それから天気を教えて」——この 2 つの間にエッジは 1 本もない。天気予報は要約を消費しない。

データを運んでいないエッジ＝偽エッジを消すだけで待ち時間の多くが消える。しかもコストはゼロで、新しいツールも要らない。直列に書かれたスクリプトは既に「分岐のないグラフ（退化した形）」であり、最初の実技は矢印ごとに「次のステップは前の出力を読んでいるか」を問うことになる。

ノードには契約を与える

推論できないノードは、並列化できないノードである。 限定された入力・定義された形の出力・単一の仕事を与える。入力は共有コンテキスト経由で暗黙に前提せず、明示的に渡す。出力に形がないなら、それはノードではなく会話である。

エッジはタダ。配管にエージェントを使わない

fan out と統合の間にある reduce ステップ（平坦化、重複排除、フィルタ）は、素のコードで書けばよい。「結果を統合する」ためにエージェントを起動したくなるが、平坦化と重複排除の意味なら flatMap と Set で済む——決定的、即時、0 トークン。

エージェントは判断のためにあり、配管のためにはない。すべてのエッジがエージェントであるグラフは、自分の配線に家賃を払っている。

正典形：ダイヤモンド（fan out → reduce → 統合）

1 ノードが依頼を分割し、多数のノードが並列に働き、1 ノードが融合する。市場スキャン・依存関係監査・コードレビュー・リサーチレポートはすべてこの骨格を共有する。直列チェーンの所要時間が B + C + D の合計になるのに対し、ダイヤモンドでは max(B, C, D) と統合の和に縮む。

設計の問いも変わる。「どうやってもっとステップを踏ませるか」ではなく 「切れ目はどこで、融合はどこか」 になる。

バリアは正当化された例外に

全結果を一度に必要とする段（集合に対する重複排除、合計に応じた早期終了、「他の発見」と比較するプロンプト）だけがバリアを正当化する。単にリストを平坦化するだけならそれはエッジで、インラインでやるべき。「分離していること」は「同期していること」と同じではない。

反対ルール — グラフが買えるのは「幅」だけ

このテーマで最も重要な警告。

グラフが買えるのは幅である。より良い判断は買えない。仕事の各ステップが前ステップの全体像を必要とするなら、エージェント間に分配してもより良い答えは得られない。同じ答えが、より高くより遅く得られるだけだ。

エージェントを 1 体足す前に問うべきは 「私の仕事はどこで分かれるのか？」 の一点。分かれないなら、エージェント 1 体のままでよい。

信頼を作る構造

失敗の封じ込めと収束

コスト：0 トークンなのはエッジであってノードではない

調整レイヤ自体はコードなのでモデルのトークンを消費しない。だが実行全体のトークンは、同じ作業を会話で進めるより増える。「配管が無料」と「実行が安い」は別の話である。

対策は 2 つ。ノード間でモデルを段階化する（反復的な抽出・分類は安いモデル、統合や裁定は高いモデル）ことと、トポロジーを選ぶこと。バリアによる待ち時間は実在し、計測でき、そして無駄なので、要素ごとに全段を独立に流す形をデフォルトにする。

実装例：多因子アルファモデル（11 ノード）

グラフの具体例として、ヘッジファンドの多因子投資を 11 ノードで組む設計がある。

全体が 24 時間おきに発火し、「取引できる信号があるか／今日はノイズだった証拠」のどちらかが届く。どちらの結果も有用で、どちらも人がキーボードの前にいる必要がない。

注: Fama-French 3 ファクター（1993）→ Carhart 4 ファクター（1997）→ Fama-French 5 ファクター（2015）は学術モデルだが、低ボラティリティを加えた「7 ファクターモデル」は正式な学術モデル名ではなく、実務的な拡張構成である。

関連ページ

ソース記事