グラフエンジニアリング

2026年9月5日

🐧 要するにどういう話か

LLMが現れて、プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリングの流れでループエンジニアリングとか言い出したと思ったら、「いや、やっぱグラフじゃね？」とか言い出して、「ループエンジニアリングは死んだ！グラフエンジニアリングだ！」と騒ぎになったようだが、いやいやLangGraphじゃんそれ、なんならステートマシンじゃん、みたいなツッコミを受けたりしたといった話。発展的にワークフロー型に回帰したという感じか。コンテキスト境界を適切に設定できるかどうかがキモのような気がする。

1. グラフエンジニアリングとは何か

グラフエンジニアリングとは、エージェントがその中を動くグラフを設計することである。具体的には、以下のようなことを決める。

  • どのような専門的なノードが存在するか
  • ノードの間で仕事をルーティングするエッジ（辺）はどれか。分岐、ファンアウト/ファンイン、ループを含む
  • どの共有ステートがそのエッジに沿って流れるか

ループエンジニアリングは、1つのエージェントが繰り返すサイクルを設計する。一方、グラフエンジニアリングは、そうした複数のループをどうつなぐかを決める。1つのループは最も小さいグラフ（自身へ戻るエッジを持つ1つのノード）なので、グラフエンジニアリングはループエンジニアリングの置き換えではなく、その上位概念である。

2つの違いを端的にいうと、経路を決めるのはエージェントか、それともあなたか、である。

  • ループでは、目標と基準を設定し、エージェントが自分でそれを達成する経路を選ぶ。
  • グラフでは、有効な経路とその上のチェックを宣言する。一部のエッジは実行時に決まるので、エージェントの自由は全作業にわたるのではなく、各ノードの内側に置かれる。

グラフエンジニアリングではない要素を3つ挙げる。

  • ナレッジグラフやGraphRAGではない。それらは検索のためにデータをエンティティと関係としてモデル化する。グラフエンジニアリングは実行をモデル化する。次にどのエージェントが実行され、どのステートを受け取るかである。同じ「グラフ」だが、両者は関係ない。
  • 新しいものではない。2025年に作れなかったものが2026年7月にリリースされたというわけではない。
  • デフォルトではない。多くのタスクは1つの仕事と1つのバリデータであり、それはグラフというよりループである。

2. 用語が登場した経緯

この言葉は2026年7月18〜19日頃にX上で結晶化した。種になったのはある質問である。OpenClawの作者であるPeter Steinberger氏が「まだループの話か、もうグラフに変わったか」と問うた。1日もたたないうちにタイムラインが反応し、皮肉な弔辞（「Loop Engineering is dead. Long live Graph Engineering!」）や、定着したフレーミング（エージェントが「whileループから組織図へと卒業する」）が並んだ。これはプロンプト、コンテキスト、ハーネス、ループエンジニアリングに続く、最新の用語である。

なぜこれほど多くの用語が次々と現れるのか。それはLLMに仕事をさせるのが難しいからである。LLMは堅牢ではなく、決定論的でもない、それは新しいタイプのソフトウェアであり、作り手はそれを動かすために新しい戦略を絶えず試している。そして新しい戦略のたびに新しい名前が生まれる。

この用語を位置づけるには5層のスタックで考えるとよい。各層はモデルから1つ外側を設計する。

  1. プロンプト — 単一の依頼
  2. コンテキスト — モデルが見るもの
  3. ハーネス — それを取り巻くツール、メモリ、足場
  4. ループ — 1つのエージェントが繰り返すサイクル
  5. グラフ — 多数のエージェントやステップの間の協調
flowchart TB subgraph graph["グラフエンジニアリング (2026)"] subgraph loop["ループエンジニアリング (2026)"] subgraph harness["ハーネスエンジニアリング (2026)"] subgraph context["コンテキストエンジニアリング (2025)"] prompt["プロンプトエンジニアリング (2022–2024)"] end end end end

これらのスタックは累積であり、上へ登って離脱するための階段ではない。グラフはノードでできている。良いノードは設計されたループである。良いループには実体のハーネスが必要である。グラフは最も外側の層であり、だからこそ最後に触るべきものである。

実は、言葉よりも基盤となるツールのほうが先にあった。グラフによるオーケストレーションは、実際のフレームワークとして既に実装されていた。

  • LangGraph（LangChain）: StateGraphとしてエージェントを構築し、ノードを追加して、共有ステートの上でエッジを接続する。
  • Microsoft AutoGen（GraphFlow）: グラフベースのマルチエージェント・オーケストレーション。AutoGenは現在メンテナンスモードで、後継はMicrosoft Agent Frameworkとされている。
  • Google ADK: グラフベースのアーキテクチャ。逐次、並列、ループのワークフローエージェントと、ファンアウト/ファンインやループ用のエージェントルーティングを備える。
  • A2A（Agent2Agent）: エージェントがシステム間で互いに仕事を委譲するためのオープンプロトコル。

この用語は同時に懐疑論も呼び、それらは正当なものである。

  • 「おめでとう、LangGraphを再発明した」。LangGraphを作ったHarrison Chase氏自身は、この言葉が本当に何か新しいものを名乗っているかどうかはまだ確信が持てず、「結局ほぼLangGraphでは？」と答えている。
  • ステートマシンの専門家の警告。XStateの作者David Khourshid氏は、ステートと遷移の有向グラフは数十年も前のコンピュータサイエンスである、と指摘している。
  • 先行事例の指摘。もう1人は、マルチエージェントの委譲の考え（A2Aとその仲間）は、この用語が流行する前に既に企業内で実績があった、と指摘している。

妥当な整理は、言葉と変化を分けることである。仕組みは古く、この用語に乗った内容の多くはノイズである。しかしその下での動き、すなわち「ループの中の1つのエージェント」から「共有ステートで協調する複数の専門的なエージェント」への段階の上昇は、チームが実際に踏む設計ステップである。この段階の上昇自体は本物である。ただし、必要になる前に触らないこと。

3. 基礎

3.1 エージェントグラフの3要素

ジャーゴンを剥ぎ取ると、エージェントグラフはちょうど3つからなる。

  • ノード — 仕事をする単位。ノードは通常、専門的なエージェント（調査担当、作成担当、レビュアー）か、素の決定論的なステップ（関数、ツール呼び出し、データ取得）である。各ノードは1つの仕事を持つ。
  • エッジ — ノード間のルーティング。エッジは「このノードのあとに、あのノードへ行く」と言う。エッジは直線的（AのあとB）、条件付き（レビューが通れば出荷、通らなければ戻す）、ファンアウト（1つのノードが複数同時に起動）、ファンイン（複数の結果が1つに再統合）があり得る。
  • 共有ステート — エッジに沿って流れるオブジェクト。全ノードが読み書きするもの、すなわちタスク、現時点までの草稿、ノート、判定である。ステートがエージェントの束をシステムにする。

この概念を支えている比喩は組織図である。会社は通常、1人に調査、執筆、レビューを一気通貫にはやらせない。異なる役割（ロール）の人で分担し、仕事の行き来をルーティングし、結果を上へ戻す。エージェントグラフも同じ考えである。専門的なロール、定義された引き継ぎ、共有される記録からなる。

3.2 基本のグラフ

最小の標準的なグラフは、3つのノードと条件付きのループバックを持つ。

  • 調査担当はソースを集めてノートを書き、ステート {タスク, ノート} を作成担当に渡す。
  • 作成担当はノートを草稿に変え、ステート {タスク, ノート, 草稿} をレビュアーに渡す。
  • レビュアーは草稿を基準に対して採点する。通れば仕事を出荷し、通らなければ草稿を作成担当へ戻す。

ステートは流れるにつれて成長する。ノートは作成担当まで、草稿はレビュアーまで運び、レビュアーの判定が次のエッジを決める。

graph LR R[調査担当] -->|ノート| W[作成担当] W -->|草稿| V[レビュアー] V -->|合格| S[出荷] V -.->|不合格: 戻す| W

3.3 エージェントをグラフとしてモデル化する

グラフは、エージェントが動くワークフローを具体的に定義する方法を与える。

  • ノードが仕事をする。ノードは決定論コード、単一のLLM呼び出し、ツール呼び出し、あるいは自身の内部ループを持つ完全なエージェントになり得る。
  • エッジが次に何をするかを定義する。一部のエッジは決定論的であり、他のエッジはノードの結果、現在のステート、あるいは外部シグナルに基づく条件付きである。
  • これはステートマシンと捉えてよい。グラフがワークフローを定義し、ステートがそれを流れていき、ステップ間の遷移がある。

各ノードは、決定論的から自律的の間のものさし上の異なる点に位置する。具体例は、チャットの依頼をプルリクエストに変えるドキュメントエージェントである。

  • 固定ステップ: チャットツールとタスク管理の操作は、決められたコードとAPI呼び出しで動く。
  • モデルステップ: 分類と統合は、ツールなしの単一LLM呼び出しを使う。
  • エージェントステップ: 参照ドキュメントエージェントと概念ドキュメントエージェントは、それぞれのコードベースでより開かれた仕事をする。

決定論と自律性のこの混合こそが、こうしたエージェントを予測可能で、強力かつ効率的にする。

3.4 グラフを使うべき場面

現実のエージェントのワークフローには予測可能な構造があることが多い。サポートエージェントは回答やエスカレートの前に課題を分類する。コーディングエージェントは変更を提案する前にリポジトリを検査する。コンプライアンスワークフローは外部動作の前に承認を求める。

グラフはその構造を直接エンコードさせる。有効な経路、モデルが選べる場所、そしてモデルが毎回正しく判断するのを望む代わりにシステムが決定論的に強制すべき場所をである。システムをグラフとして表現することは、そのシステムがどう動くべきかという自分自身の世界知識をエンコードすることである。プロンプトがドメイン知識を持つように、こうした「認知アーキテクチャ」にもそれを持たせられる。

例: ナレッジベースエージェントは、検索のために3つのサブエージェントを使う。コード、課題、プルリクエスト用のGitHubエージェント、内部ドキュメントやWiki用のNotionエージェント、関連スレッド用のSlackエージェントである。ワークフローは3つの固定ステージを持つ。分類、検索、統合である。結果は、コードとモデルの推論が協働することになる。モデルは価値を生む場所で推論し、コードは残りを持ち、エージェントはより安く、速く、予測可能になる。

3.5 グラフを使うべきでない場面

いくつかのタスクは本質的に自律的（エージェント的）であり、それを決定論的な経路に強制するのは誤った手である。こうした場合は、グラフではなくエージェントハーネスを望むべきである。

  • 良い例が汎用的なディープリサーチである。リサーチエージェントは、事前に固定するのが難しい形で、計画し、委譲し、検索し、読み取り、統合する必要がある。

過剰設計のケースはそれと鏡写しである。「このPDFを要約して」。取得担当、分割担当、要約担当、レビュアー、整形担当の5ノードグラフに、条件付きエッジと共有ステートオブジェクトを付けて作る。それは確かに動く。だが、本来あるべきもの、すなわちファイルを読んで要約を書くループの中の1つのエージェントよりも、作るのに時間がかかり、デバッグしにくく、実行コストは高い。

3.6 グラフを作り続けて分かったこと

エージェントがグラフとして何年も作られ続けた結果、3つの教訓が得られている。

  • エージェントグラフは通常DAG（有向非巡回グラフ）ではない。本番のエージェントはサイクルを必要とする。失敗したツール呼び出しのリトライ、不足情報のユーザーへの質問、検証後の回答の修正、十分なコンテキストが揃うまでのツールの反復呼び出し、人間の入力待ちの一時停止と再開である。ループはエージェントシステムのコアな部分なので、おそらくDAGではない。
  • ループは単純なグラフである。ループエンジニアリングはグラフの代替ではなく、その単純版である。ループは単に、有向のサイクルを持つグラフである。シンプルなエージェントループに基づくLangChainフレームワークは、LangGraphの上に構築されている。
  • 動的トランジションが重要である。全エッジを事前に定義したくないことが多い。ノードが実行時にどれだけの仕事を生成するかを決めることもある。古典的な例がマップリデュース（map-reduce）である。入力を分割し、各ピースをワーカーへ送り、結果を結合する。ワーカーの数は入力に依存し、事前に分からない。LangGraphはSend APIでこれに対応し、ノードが静的に全遷移を定義せずに、1つ以上の下流ノードへ動的に仕事をルーティングできるようにする。

教訓は、有用なエージェントシステムは既知の構造と実行時の可変性を混ぜる、ということである。検索がファンアウトして統合することは分かっても、ソースがいくつあるかは分からない。スーパーバイザーがワーカーに委譲することは分かっていても、どのワーカーに移譲するかはタスクが始まるまで分からない。

3.7 本当に新しいのは何か

エージェントシステムをグラフとして表現することは新しものではない。変わったのは、ノードの中に入れるものの範囲である。初期は、ノードは決定論的コードか単一LLM呼び出しだった。今ではエージェント自身が本物の仕事を託せるほど信頼できるようになり、ノードは完全なエージェント実行になり得る。つまり、LLM呼び出しではなく、エージェントをオーケストレーションするのだ。

コーディングエージェントが良い例である。これらは現在本番で最も効果的なエージェントの部類に入り、1つを大きなグラフのノードとして埋め込むのは、新しく実用的になったパターンである。

3.8 フレームワーク

ランタイムを自作してはならない。LangGraph、Google ADK、Microsoft Agent Framework（AutoGenの後継）は、ノード、エッジ、共有ステート、ファンアウト/ファンイン、ループをすでに提供している。

3.9 開始チェックリスト

ループをグラフに変える前に、アイデアを以下のリストでチェックする。

  1. まずループで済ませようとする。良いバリデータを持ち、スコープが明確な1つのエージェントで足りるなら、そこで止める。
  2. ノードは本当に専門的な場合にだけ命名する。各ノードは、1つのループが本当に持てない仕事を持つべきである。別のモデル、別のツールセット、あるいは読み取り専用のレビュアーロールである。
  3. コードの前にエッジを描く。何が逐次的で、何がファンアウトし、何がファンインし、条件付きのエッジかループバックのエッジがどこにあるかをスケッチする。裏紙に描けないなら複雑すぎる。
  4. 共有ステートオブジェクトを明示的に設計する。エッジに沿って何が流れ、誰が書き込めるかを決める。ステートドリフト（共有ステートが設計からずれていくこと）はグラフが劣化する最大の要因である。
  5. レビュアーノードに牙を与える。最も価値の高いノードは、通常、仕事の生み手とは別の、読み取り専用のバリデータである。
  6. 失敗を隔離する。1つのノードの失敗とリトライが、共有ステートを壊したり、下流ノードを汚染したりしないようにする。
  7. 自作するよりフレームワークを選ぶ。
  8. 支出の上限（金額・トークン）と、実行の上限（回数・ステップ・時間）を設定する。グラフは多くのループであり、弱いバリデータは並列でトークンを消費する。

勝利条件は「ノードが最も多いこと」ではない。「全ノードがループではできない仕事をしていて、なおかつ全体を一息で説明できること」である。

4. グラフエンジニアリング対ループエンジニアリング

誇大広告を剥ぎ取ると、2つはきれいに定義できる。

  • ループエンジニアリングは、1つのエージェントが回るサイクルを設計する。発見、計画、実行、検証、停止条件まで繰り返す。プロンプトを手書きするのをやめ、サイクルとその終了テストを設計する。
  • グラフエンジニアリングは、1つのループでは足りない時にやること。複数の専門的なエージェントやステップをグラフに接続する。

2つの比較は次の通り。

  • 単位: 1つのエージェントのサイクル／複数のノード、エッジ、共有ステート。
  • 形: サイクル（発見、計画、実行、検証、繰り返し）／ルーティングエッジで結ばれたノードの有向グラフ。
  • ステート: 1つのエージェントのコンテキストの内に生きる／エッジに沿って流れ、ノード間で共有される。
  • 設計するもの: サイクルとその停止条件／トポロジーとルーティング。
  • 失敗する時: バリデータが弱い時／トポロジーが誤っている時、あるいはノード間でステートが漏れる時。

関係は単純である。ループはグラフの特殊ケースであり、自身へ戻るエッジを持つ1つのノードである。グラフを作るためにループを捨てない。グラフの中の各ノードはループである。

4.1 本当に変わったこと

1つのタスクの例を取り上げ、2通りの作り方で見てみよう。毎日の調査ブリーフである。毎朝、あるテーマのいくつかのソースを読み、1ページの要約を起草し、受信トレイに入る前に要約が正確かをチェックする。

  • 1つに詰め込んだループで: 1つのエージェントが1つのコンテキストですべてを行う。ソースを検索し、生の結果を投げ込み、ブリーフを起草し、自分の草稿をレビューする。レビューの頃には、コンテキストは生の検索結果と自身の以前の推論の沼になっている。草稿を書いたのと同じコンテキストの中で草稿をレビューするので、自分の仕事を形式的に承認するだけになる。また、ループは形状としては逐次的なので、ソースを1つずつしか読めない。
  • 小さなグラフで: 同じタスクは、ステートが流れる3つのノードになる。
    • 調査担当ノードはソースを並列にファンアウトし、構造化ノートを返す。文章は書かない。
    • 作成担当ノードは生の検索結果ではなく整理されたノートだけを見て、ブリーフを作る。
    • レビュアーノードは新しいコンテキストで走り、ブリーフと精度の基準だけを見て、失敗なら作成担当へ戻す。

グラフの本当に新しい能力は以下の3つである。

  1. 並列の専門的なノード。「検索、次に執筆、次にレビュー」を、それぞれ自身のプロンプト、ツール、整理されたコンテキストを持つ別々のノードに分割する。
  2. 明示的・監査可能な制御フロー。自由に回るループでは「なぜそう動いたか」は1つのトランスクリプトの中に埋もれる。グラフではエッジを事前に定義する。このノードが走り、レビューが失敗すれば戻し、そうでなければ進む。経路は読める図になる。
  3. ファンアウト / ファンイン。1つのタスクをN本の並列枝に分割し、同時に走らせ、結果を結合する。これはグラフ特有のものであり、単一ループが本質的にできない動きである。

4.2 コスト

グラフを用いることで、余分なコストがかかる。

  • 維持するプロンプトが増える（1つから3つ）。
  • ノード間のステートスキーマ: 調査担当は作成担当に何を渡すのか。
  • 新しい失敗モード: ソースを黙って落とすマージ、永遠にループするルーティングバグ、ノードを越えて漏れるステート。

毎日走らせるブリーフなら、これらのコストは元が取れる。ブリーフの品質が上がり、それが毎日効いてくる。一度実行するだけのタスクなら、これらのコストは純粋に無駄である。グラフを作るかどうかは、このトレードオフで決まる。

4.3 直感チェック

「ループからグラフに移った」と結論付ける前に、以下の問に答えて「はい」の数を数える。

  1. 1つのコンテキストを、専門的な複数のコンテキストに分割したか。1つのトランスクリプトの中で帽子を変える1つのエージェントではなく、ノードごとに異なるプロンプトとツールになっているか。
  2. 本物のファンアウト/ファンインがあるか。単に箱として描いた逐次処理ではなく、何かを並列に走らせて結合するものがあるか。
  3. 制御フローを図として読めるか。ルーティングは事前に定義され、確認可能なものであり、1つのエージェントの判断から自発的に生じるものではないか。
  4. 目標と成功の基準が変わったか。「完了かつ正しい」の定義が以前と全く同じなら、変わったのは絵だけで、実際の進め方は変わっていない。
  • はいが0〜1つ: グラフの絵をまとったループである。ループのままにし、失敗モードから身を守る。
  • はいが2〜3つ: ループをグラフに合成している本物であり、新しい能力はコストに見合っている。
  • はいが4つ: パラダイムを変えた。それを求めたのは流行ではなく仕事である。

1行のテスト: 専門的なロールを名指しでき、その間に矢印が引ければ、それはグラフである。ただ正しくなるまで繰り返す1つの仕事なら、それはループであり、ループのままにすべきである。

4.4 移行手順

直感チェックで仕事が本当にグラフを要求すると言うことになった場合、動きは意外と小さい。なぜならループはグラフの1つのノードだからである。実際に機能する手順は次の通り。

  1. ループを残す。ノード1にする。既存のエージェント、プロンプトとツールをそのままに、最初のノードにする。これはループエンジニアリングからの移行ではない。既に持つループを包むのである。
  2. 失敗しているステップを引き剥がす。実際にはほぼ必ずレビュアーである。レビューを新しいコンテキストと明示的な基準を持つ自身のノードに引き出すのが、最も価値の高い最初のエッジである。1つのノードが2つになった。それがグラフである。
  3. ノード1がノード2に何を渡すかを記述する。これが実際の仕事である。調査担当は作成担当に何を渡すのか。生のテキスト、構造化ノート、ソース付きの主張リストか。そのステートスキーマこそがグラフが難しくなり、黙って壊れる場所である。エッジを越えるものを名付けられないなら、まだ描く準備ができていない。
  4. ファンアウトは、1つずつ繰り返していたところにだけ追加する。本当に新しい能力は、N本の枝を同時に走らせて結合することなので、本当のNがある場所に使う。1つのアイテムへのファンアウトは図であって、グラフではない。
  5. 次のノードがそれに見合う価値をもたらさなくなったところで止める。加えるノードごとに、維持するプロンプトが1つ増え、ステートスキーマのエッジが1つ増え、ステートが漏れる場所が1つ増える。2、3個の適切に分離されたノードで、多くの人がグラフを作る理由のほとんどをカバーできる。

この手順は、ループからの書き直しではないし、フレームワークの決定でもなく、ループでのやり方を捨てる理由にもならない。描く各ノードは依然としてループであり、その中のバリデータが依然としてボトルネックである。

5. まとめ

グラフエンジニアリングは本物であり、かつ誇大広告でもある。

  • 本当に新しいのは、ファンアウト/ファンインを持つ並列の専門的なノードと、明示的・監査可能な制御フローである。毎日のブリーフのグラフは、1つに詰め込んだループでは得られなかった、実体のレビューと整理されたコンテキストを得た。
  • 既存の用語が再ブランド化されたものである。ステートマシンもグラフオーケストレーションも、誰かがそれを「グラフエンジニアリング」と呼ぶ前に、LangGraph、AutoGen、ADKに実装されていた。
  • グラフエンジニアリングは、信頼できるエージェントを作る確立されたアプローチの最新の名称である。ループエンジニアリングやハーネスエンジニアリングと同じ考え、すなわち各ステップで、モデルの推論を正しい場所に、正しいコンテキストで置くことである。

騒ぎが去っても残る枠組みは単純である: ループはグラフの1つのノードである。ループからグラフへ卒業するのではない。1つのループでは足りなくなる時に、そしてその時にだけ、ループをグラフに合成し、プロンプト、ステートスキーマ、新しい失敗モードの代価を払う。

まずループを磨く。仕事が求める時に、グラフを結ぶ。

📚 参考文献