Graph Engineering（グラフエンジニアリング）完全ガイド

Graph Engineering とは？

Graph Engineering（グラフエンジニアリング）とは、マルチエージェントシステムを明示的なグラフとして設計する実践です。ノード（単一の責務を持つエージェントまたは決定的なステップ）、エッジ（ノード間のルーティング——逐次・条件分岐・並列）、そして共有状態（エッジに沿って流れ、各ノードが読み書きするオブジェクト）から構成されます。

Loop Engineering が単一エージェントの振る舞い——ゴール、チェックコマンド、終了条件、リトライ——をプログラマブルにするものだとすれば、Graph Engineering はエージェントの組織をプログラマブルにするものです。ループが答えるのは「このエージェントはどうやって完了まで働き続けるか？」。グラフが答えるのは「どのエージェントが存在し、誰が誰に引き継ぎ、ブランチが失敗したらどうなるか？」です。

有用な退化ケースとして、ノードが 1 つだけのグラフは単なるループです。だからこの 2 つの分野は競合ではなく積み重なる関係にあります——まともなグラフはすべて ループのグラフなのです。

なぜ今、この言葉なのか

この言葉は 2026 年 7 月 18 日頃に X 上で定着しました。Loop Engineering を広めたのと同じ人物である Peter Steinberger が "Are we still talking loops or did we shift to graphs yet?"（まだループの話をしているのか、それとももうグラフに移行したのか？）と問いかけたのがきっかけです。一日のうちに、ビルダーたちはエージェントを「while ループを卒業して組織図へ進学する」と表現し始めました。

注目すべきは、その週に新しい機能は何もリリースされていないことです。転換は概念的なものでした。2026 年半ばには、よく調整された単一ループが十分に信頼できるようになり、チームは複数を同時に走らせ始めました——リサーチループがビルダーループへ、さらにレビュアーループへと出力を渡す形です。すると難所は配線に移りました：ルーティング、引き継ぎの契約、障害の隔離、エージェント間の状態整合性。Graph Engineering とは、その配線を本番環境で偶然発見するのではなく、意図的に設計することに付けられた名前です。

スタック：プロンプトからグラフまで

これらのレイヤーはオンラインで常に混同されています。内側から外側へ：

• Prompt Engineering（プロンプトエンジニアリング） ——モデルへの単一の指示を 1 ターンずつ最適化する。
• Context Engineering（コンテキストエンジニアリング） ——エージェントが応答する前に見る情報（ファイル、メモリ、検索されたドキュメント）を決める。
• Harness Engineering（ハーネスエンジニアリング） ——1 つのエージェントが動くシステムを設計する：ツール、ガードレール、権限、可観測性。エージェント = モデル + ハーネス。
• Loop Engineering（ループエンジニアリング） ——ハーネス工学を「リトライと検証」のサイクルに適用したもの：ゴール、チェックコマンド、終了条件、最大反復回数。完全ガイド →
• Graph Engineering（グラフエンジニアリング） ——複数のループを 1 つの組織に配線する：ノード、エッジ、共有状態、そしてそれらの間のルーティングロジック。本記事はこのレイヤーについてです。

グラフの解剖学

よくできたエージェントグラフはすべて 4 つの問いに答えます——配線する前に書き出しておきましょう：

• ノード（Nodes） ——作業単位は何か？各ノードは単一の責務と独自の「完了」の定義を持っているか？独立して失敗できないノードはノードではなく、隠れた依存関係です。
• エッジ（Edges） ——各ノードについて、次のノードを起動するのは何か？逐次（常に実行）、条件付き（チェックが通ったら）、並列（多数へ fan-out し、合流点で fan-in）？
• 共有状態（Shared State） ——エッジに沿って移動するオブジェクトは何か？下流ノードが必要とするフィールドはすべて上流ノードが書き込む必要があります——グラフは、ワークフローのうちまだモデル化していない部分がどれだけあるかを認めさせます。
• 失敗時のルーティング（Failure Routing） ——ノードのループがリトライを使い果たしたら、制御はどこへ行くのか？1 ステップ戻るのか、フォールバックノードへ行くのか、人間にエスカレーションするのか？失敗エッジのないグラフは図解であって、システムではありません。

組織グラフとワークグラフ

元のスレッドで定着したフレーミング：成熟したシステムは実際には2 つのグラフを同時に動かしています。

• **組織グラフ（Org Graph）**は安定して長寿命——ドメインを所有する専門エージェント（レビュアー、リサーチャー、デプロイエージェント）が永続的なコンテキストを保ち、多くのタスクをまたいで存在します。組織図のイメージです。
• **ワークグラフ（Work Graph）**は動的で短命——1 つの仕事のために生成されるタスク DAG で、実際の作業が要求するものに応じてノードが現れ、展開し、合流し、消えます。プロジェクト計画のイメージです。

初期に最もよくある間違いはこの 2 つの混同です：今日のタスク分解（ワークグラフ）を常設のエージェント編成（組織グラフ）にハードコードしてしまい、なぜ新しいタスクのたびに構造と戦うことになるのか不思議に思うのです。

名前のついたグラフパターン

繰り返し現れる形がいくつかあります：

• パイプライン（逐次引き継ぎ） ——リサーチャー → ライター → レビュアー。最も単純なグラフで、各ノードの出力が次のノードの入力になります。
• Fan-out / Fan-in ——1 つのノードが多数の並列ワーカー（ファイルごと、テスト失敗ごと、データソースごと）を生成し、合流ノードが結果をマージします。並列化可能な作業の主力パターンです。
• Orchestrator–Workers（オーケストレーター・ワーカー） ——より強いモデルのプランナーノードがタスクを分解し、サブタスクを安価なワーカーノードにルーティングして、最後に統合します。「ゆっくり考え、速く動く」のマルチエージェント版です。
• カウンシル / 審査員パネル（Council / Judge Panel） ——複数のノードが同じタスクを独立に試行または評価し、審査ノード（または多数決）が勝者を選びます。冗長性で信頼性を買うパターンです。
• ノード内ループ（Loops-within-Nodes） ——どのノードも内部に完全な「リトライと検証」ループを持てます——Ralph 式ループや test-until-green ループなど——グラフの他の部分からは見えません。この合成規則こそがスタック全体を成立させています。

本当にグラフが必要か？

正直で冷静な答え：多くの場合、まだ必要ありません。単一ループで十分なサイン——良いコンテキストを持つ 1 つのエージェントがタスク全体を抱えられる、失敗してもゼロからのリトライが安い、活かせる真の並列性がない。単一ループを卒業したサイン——フェーズ間の引き継ぎが 1 本の長いコンテキストの中で失われ続ける、フェーズごとに異なるモデルや権限が必要になる、1 つの遅いサブタスクがすべてを直列化する、ステップ 7 の失敗でステップ 1 からやり直しになる。

現実的な道は漸進的です：まず 1 つのループを信頼できるものにし、次に明示的な引き継ぎで 2 つ目のループを接続し、配線そのものがバグの発生源になったときに初めてフレームワークに手を伸ばします。

フレームワーク

グラフオーケストレーションはこの言葉より先に存在していました。LangGraph は最も直接的な実装です——StateGraph を定義し、ノードを追加し、エッジを追加すれば、ランタイムが状態の永続化、条件付きルーティング、ロールバックを管理します。Microsoft AutoGen の GraphFlow、Google の Agent Development Kit（ADK）、CrewAI も異なるトレードオフで同じ領域をカバーしています。エージェントネイティブなランタイムも同じ形に収束しつつあります：Claude Code 組み込みのループプリミティブは、まさにこうしたパイプラインや fan-out に合成できます。どれかを使ったことがあるなら、あなたはすでに別の名前で Graph Engineering をやっていたのです。

はじめの一歩

グラフは動くループから作られるので、レバレッジの大きいところから始めましょう：まず 1 つのループを信頼できるものにし、そこから配線していきます。

• MCP.so の Loops ディレクトリから実証済みの単一エージェントループを選びます——例えば Test Until Green や Ship PR Until Green——退屈になるまで回してください。
• 引き継ぎを 1 つ追加します：2 つ目のループが、明示的な状態ファイルまたは PR を通じて 1 つ目のループの出力を消費し、独自のチェックコマンドを持つようにします。
• その後で初めて形式化します：配線を LangGraph やお使いのランタイムのネイティブなワークフローサポートに移し、各ノードのループ契約（ゴール、チェック、終了、リトライ）はそのまま保ちます。

ループは筋肉、グラフは骨格です。すぐに使えるループの全コレクションは MCP.so Loops にあります——それぞれ、グラフのノードに必要なキックオフプロンプト、チェックコマンド、終了条件が付属しています。