グラレコ

はじめに

2026年7月中旬から、AI エージェント界で Graph Engineering（グラフエンジニアリング） という言葉が急に流通し始めました。Loop Engineering の次に来る層、という位置づけで語られています。

定義は、複数のエージェントループを1つのシステムとして配線する設計手法です。Louis Bouchard 氏の解説記事では、こう書かれています。

Graph engineering is this week's name for connecting several agent loops into one orchestrated system: parallel branches, verifiers, handoffs, and stop conditions.

（グラフエンジニアリングは、複数のエージェントループを1つのオーケストレーションされたシステムに接続することの、今週の呼び名だ。並列ブランチ、検証器、ハンドオフ、そして停止条件）

— Graph Engineering Explained: What Actually Changed

「今週の呼び名」という言い方に、この用語をめぐる空気がよく出ています。

この記事では、Graph Engineering が何を指しているのか、Loop Engineering と実際に何が違うのか、そしてそもそもグラフにすべきなのかまでを整理します。結論を先に言うと、新しいのはたぶん名前のほうで、扱っている難しさは以前からありました。ただ、その難しさに名前が付いたことで見えやすくなった部分は確かにあります。

この記事で扱うこと

Graph Engineering がどう始まったか（ツイート1件です）
prompt → context → harness → loop → graph という呼び名の系譜
ノード・エッジ・共有状態という3つの部品
5つの合成可能なパターンと、それぞれが壊れる条件
LangGraph での最小実装
「整然としたナンセンス」問題という一番厄介な落とし穴
Google DeepMind × MIT の研究が示した「グラフにすべきか」の判断材料

🐦 発端は1件のツイートでした

Graph Engineering の出発点は、製品発表でも論文でもありませんでした。OpenClaw の作者である Peter Steinberger 氏（@steipete）が、2026年7月中旬に投げた短い問いかけです。

Are we still talking loops or did we shift to graphs yet?

（まだループの話をしてる？　それとももうグラフに移った？）

これが数百万回規模で表示され、同種の反応が次々と続いて、ほどなく「graph engineering」という言葉が広まりました。

ここで押さえておきたい事実が1つあります。Data Science Dojo の記事が、はっきりこう書いています。

No framework, model, or capability shipped around the tweet. The term came entirely from the discourse that followed it.

（このツイートの前後で、フレームワークもモデルも新機能も一切リリースされていない。この用語は完全に、ツイートに続いた議論から生まれた）

つまり Graph Engineering は、技術的なブレイクスルーに名前が付いたものではありません。すでに存在していた実践に、後から名前が付いたものです。

この図の右端が、この用語を読むときの前提になります。何かが新しく可能になったわけではありません。

では追いかける価値がないのかというと、そうとも言えません。LangChain は公式ブログでこう書いています。

Graph engineering isn't a new idea. It's the latest name for a well established approach to building reliable agents.

（グラフエンジニアリングは新しいアイデアではない。信頼できるエージェントを作るための、確立された手法についた最新の名前だ）

— 3 Years of Graph Engineering with LangGraph

新しくないけれど、確立された手法である。この2つは両立します。

🧭 呼び名の系譜 — 5つ目の名前

Graph Engineering は、この2年ほどで5つ目の呼び名です。

並べてみると、関心の移り方に一貫した方向があります。モデルへの入力から、モデルを取り囲む構造へという方向です。

呼び名	主な関心	単位
prompt engineering	プロンプトの書き方	1回の呼び出し
context engineering	何を context に載せるか	1つの会話
harness engineering	エージェントを動かす足場（ツール・権限・環境）	1つのエージェント
loop engineering	実行 → 検証 → 修正のサイクル、停止条件	1本のループ
graph engineering	複数ループの接続、分岐、合流、責任分界	ループの束

CodeRabbit の中津川篤司氏も、AI駆動開発カンファレンスの講演で同じ系譜を示していました（2022年プロンプト → 2024年エージェント → 2025年コンテキスト → 2026年ハーネス／ループ）。呼び名の入れ替わりが速いのは、界を追っている人にとっては既知の感覚だと思います。

ただ、系譜として並べたときに Graph Engineering には他と違う点が1つあります。前の4つは新しい技法でしたが、Graph Engineering は前の層の合成です。だから「新しくない」という指摘が同時に成立します。

🔁 ループとグラフの違い — グラフはループを含みます

一番混乱しやすいのがここです。「ループからグラフへ移った」という言い方をすると、ループが古くなったように聞こえます。でも実態は違います。

Louis Bouchard 氏の一文が、この関係を最も端的に表していました。

A graph is what you get when one loop is no longer enough, and graphs contain loops.

（グラフとは、1本のループでは足りなくなったときに得られるものであり、グラフはループを含んでいる）

LangChain も、まったく同じことを別の言い方で書いています。

Loop engineering isn't an alternative to graphs, so much as a simple version of them.

（ループエンジニアリングはグラフの代替ではなく、むしろグラフの簡易版だ）

つまり、対立関係ではありません。包含関係です。

この図でグラフの中に描かれている丸が、それぞれ1本のループです。Loop Engineering で扱ってきた「実行 → 検証 → 修正 → 停止条件」が、そのままノードになります。

そして重要なのは、エージェントのグラフはたいてい DAG（有向非巡回グラフ）にならないことです。LangChain も3年分の知見として「agent graphs are usually not DAGs（エージェントのグラフは通常 DAG ではない）」と書いていて、その理由をこう説明していました。

Production agents need cycles: retrying failed tool calls, asking users for missing information, revising answers after validation...

（本番のエージェントには循環が必要だ。失敗したツール呼び出しの再試行、足りない情報のユーザーへの確認、検証後の回答の修正……）

ここが Airflow のようなワークフローエンジンと決定的に違うところだと思います。データパイプラインは基本的に一方向ですが、エージェントは戻ります。

何が実際に変わるのか

では、1本のループを複数に分けると何が起きるのか。Louis Bouchard 氏の整理が具体的でした。

以前は、オーケストレーションのロジックが1つの巨大なチャットコンテキストの中に隠れていたというのです。

the model was the scheduler, the database, the log, and the project manager at once

（モデルが、スケジューラであり、データベースであり、ログであり、プロジェクトマネージャでもあった）

これを明示的なグラフとして描くと、4つのことを決めざるを得なくなります。

描くことで決まるもの	以前はどこにあったか
並列化：どこを同時に走らせるか	モデルの気分次第
状態管理：どのノードが何を見られるか	全部が同じ context にあった
拒否権：どのノードが他を止められるか	誰も止められなかった
コスト予算：どこにいくらまで使うか	走り終わってから請求で知る

「モデルの気分次第」だった部分が、コードとして書かれる。これが Graph Engineering の実質だと思います。

そして、この4つのなかで一番効くのは3番目の「拒否権」です。単一ループでは、生成したモデル自身が「できた」と判断していました。グラフでは、別のノードに止める権限を渡せます。

🧩 3つの部品 — ノード、エッジ、共有状態

構成要素はシンプルで、3つだけです。LangChain の解説記事の説明が最も明快でした。

ノード（Nodes）は働きます。

A node can be deterministic code, a single LLM call, a tool call, or a full agent with its own internal loop.

（ノードは、決定的なコードでも、1回の LLM 呼び出しでも、ツール呼び出しでも、独自の内部ループを持つ完全なエージェントでもよい）

ここが地味に重要です。ノードは必ずしも LLM ではありません。テストスイートの実行、スキーマ検証、DB クエリ、人間の承認待ち。これらも全部ノードです。

エッジ（Edges）は次を決めます。 固定のものと、条件付きのものがあります。条件付きエッジは、ノードの結果・現在の状態・外部シグナルのいずれかで分岐します。

共有状態（Shared State）はエッジの上を流れます。 タスク、生成物、チェック結果などが入ったオブジェクトです。

explainx.ai の記事が「コンテキストの漏れ」として挙げていた注意点が、実務では効いてきます。

Context does not automatically flow between nodes — you design the edges that carry it.

（コンテキストはノード間を自動的には流れない。運ぶエッジを設計するのはあなただ）

— Graph Engineering: Wire Multi-Agent Orgs After Loops

単一の巨大 context に全部載せていたときは、意識しなくても全部が見えていました。ノードに分けると、何を渡すかを明示しないと渡らない。これは面倒ですが、同時に「このノードには余計な情報を渡さない」という制御ができるようになります。

二層に分けて考える

explainx.ai の記事では、グラフを2層に分ける整理が示されていました。これは実務的だと思いました。

層	性質	中身
Org Graph（組織グラフ）	安定・長寿命	恒久的な役割、担当領域の所有、保持されるメモリ
Work Graph（作業グラフ）	動的・短命	その場のタスクノード、実行時に順序が変わる構造

同じ「グラフ」という言葉で、変わらない部分と毎回変わる部分の両方を指していると混乱します。「セキュリティ担当のエージェントは常駐している」（Org Graph）と「今回の PR ではこの3ファイルを並列で直す」（Work Graph）は、別の話です。

🛠️ 5つの合成可能なパターン

Graph Engineering の実践的な中身は、ほぼこの5パターンに集約されます。これは Anthropic の Building Effective AI Agents で整理された5つのワークフローパターンと同じもので、Graph Engineering の文脈で再発見されている形です。

以下、それぞれについて「何を解決するか」と「どこで壊れるか」を並べます。壊れる条件のほうが実務では大事なので、そちらを重めに書きます。

① Prompt Chaining（直列）

タスクを順番のステップに分解し、各ノードの出力を次のノードの入力にします。

このパターンの狙いは、トークンの節約だけではありません。QA Wolf の記事に良い言い方がありました。調査ノードが集めた大量の情報について、

Step two doesn't need any of it and including it measurably degrades the result.

（ステップ2にはそれが一切必要ないし、含めると結果が計測できるほど劣化する）

渡さないことで質が上がる。ここが直感に反する部分です。全部渡したほうが良さそうに思えますが、実際は逆になることがあります。

向いている場面	壊れる場面
ステップがきれいに分解でき、必要なコンテキストが本当に違う	ステップが密結合で、結局全部の状態を転送することになる（レイテンシだけ増える）

実践のコツは、各ノードが受け取るものをホワイトリスト方式で決めること、ハンドオフをスキーマで型付けすること、上流の巨大な出力は要約して渡すことです。

② Routing（振り分け）

入力を分類して、専用の経路に流します。

QA Wolf はこのパターンを「グラフの中で最も安上がりな構造上の勝ち筋（the cheapest structural win in a graph）」と表現していました。難易度にコストを合わせられるからです。

ただし、このパターンには他と質の違う怖さがあります。

A misrouted item doesn't fail loudly — it completes successfully down the wrong path.

（誤って振り分けられたものは、大きな音を立てて失敗しない。間違った経路を正常に完走してしまう）

— How to Implement Graph Engineering: 5 Composable Patterns

失敗が静かなんです。 誤振り分けはエラーになりません。安いモデルの経路に難しいタスクが流れて、それっぽい答えを返して終わります。だから振り分け精度の計測を続ける必要があります。

そして、判別できないものと確信度が低いものは、必ず保守的な経路に落とす。図の右下の経路が抜けている実装をよく見ますが、ここが安全弁になります。

③ Parallelization（並列）

独立した作業を同時に走らせて、合流点でまとめます。

レイテンシを下げるためと、複数の視点を得るための2つの用途があります。ただしコストの構造に注意が必要です。

In situations where parallel workers would require the same context in order to complete a task, you would be paying more for lower latency since you'd be processing the context multiple times across each parallel worker.

（並列ワーカーがタスクを完了するために同じコンテキストを必要とする場合、各並列ワーカーでコンテキストを何度も処理することになるため、レイテンシを下げる代わりにコストを多く払うことになる）

— QA Wolf

同じ context を5並列に渡せば、context のトークンも5倍請求されます。

壊れる条件は2つあります。ブランチが共有状態に同時書き込みする（競合状態）ことと、一番遅いブランチが速度の上限を決めることです。5本のうち1本だけ極端に遅いと、並列の意味がほとんど消えます。

実装で決めておくべきなのは、失敗ポリシーです。「5つの情報源のうち3つ取れたら進めるのか」。ブランチ単位のタイムアウトを設定し、合流ノードを部分結果に耐えるように書き、どのブランチが貢献したかを記録します。

④ Orchestrator-Workers（司令塔と作業者）

実行時にしか作業リストが確定しない場合のパターンです。司令塔が入力を調べ、動的にワーカーを起こします。

API マイグレーションが典型例です。どのファイルが古い API を参照しているかは、調べるまで分かりません。

このパターンには、他の4つにない構造的な危険が2つあります。

Fan-out width is unbounded by default.

（ファンアウトの幅は、デフォルトでは無制限だ）

The topology is non-deterministic.

（トポロジーが非決定的だ）

幅が無制限というのは、司令塔が「120ファイル見つけました」と言えば120個のワーカーが起きるということです。トポロジーが非決定的というのは、同じ入力でも次回は違う形のグラフになるので、再現可能なデバッグができないということです。

対策として書かれていたのは、幅・深さ・支出に明示的な上限を設けること、サブツリー全体にトークン予算を割り当てること、そして司令塔が立てた計画を永続的な成果物として保存することです。最後のものが効きます。グラフの形が毎回変わるなら、その回の形を記録しておかないと後から追えません。

⑤ Evaluator-Optimizer（生成と採点）

生成ノードが作り、評価ノードが基準に照らし、不合格ならループさせます。

この図で右側に停止条件を4つ並べたのは、QA Wolf の記事がここを一番厚く書いていたからです。このパターンが壊れる原因は、ほぼ停止条件の不足です。

停止条件	検出するもの
進捗なし	同じエラーメッセージが2回出た
振動	2つの失敗状態を交互に行き来している
トークン予算	反復回数とは別に予算で切る
コスト増でスコア横ばい	解けない問題に金を投げ続けている

「最大5回まで」だけを設定した実装をよく見ますが、それでは振動を検出できません。同じ2状態を往復して5回使い切って終わります。

もう1つ重要な指摘がありました。評価ノードには外部の決定的な評価器を使うべきだ、というものです。テストスイート、スキーマ検証、数値の閾値。モデルの判断ではなく。

この理由が、次のセクションの一番厄介な問題につながります。

パターンは合成できます

5つは排他ではありません。Anthropic 自身も、これらは規範ではなく「開発者がユースケースに合わせて形を変え、組み合わせられる共通パターン」だとしています。たとえば Routing の先に Prompt Chaining が続き、Orchestrator-Workers のワーカー層に Evaluator-Optimizer が入り、Parallelization はどれの内側にも置けます（この組み合わせ方は筆者の整理です）。

「Graph Engineering」が実践として指しているのは、だいたいこの合成のことです。

💻 LangGraph で書くとどうなるか

概念だけだと掴みにくいので、実装を見ます。LangGraph は Graph Engineering という言葉が生まれる2年以上前から、このモデルを実装してきたライブラリです（LangChain 公表値では月間6,500万回以上ダウンロードされています）。

まず、状態の定義です。エッジの上を流れるオブジェクトをここで決めます。

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import InMemorySaver

class ResearchState(TypedDict, total=False):
    topic: str
    plan: str
    evidence: str
    draft: str
    feedback: str
    evaluator_approved: bool
    human_approved: bool
    revision_count: int

ポイントは3つです。

revision_count を状態に含めている — 停止条件を判断するために、試行回数が状態として流れる必要があります
evaluator_approved と human_approved を分けている — 機械の合格と人間の承認は別物です
total=False — 途中のノードでは一部のキーしか埋まりません

次に、ノードを定義します。ノードは状態を受け取って、更新分を返す関数です。

def planner_node(state: ResearchState) -> ResearchState:
    # LLM 呼び出しなど
    return {"plan": response.content, "revision_count": 0}

返しているのが状態の差分であって、全体ではないところが LangGraph の書き味です。

そして配線します。

builder = StateGraph(ResearchState)
builder.add_node("planner", planner_node)
builder.add_edge(START, "planner")
builder.add_conditional_edges("evaluator", route_function, routes_dict)
graph = builder.compile(checkpointer=InMemorySaver())

add_edge が固定エッジ、add_conditional_edges が条件付きエッジです。route_function が状態を見て次のノード名を返し、routes_dict がその名前を実際のノードに対応させます。ここが、さきほど「モデルの気分次第だった部分がコードになる」と書いた箇所そのものです。

checkpointer を渡すと、実行状態が保存されます。実行時にはスレッド ID を指定します。

config = {"configurable": {"thread_id": "workflow-001"}}
result = graph.invoke({"topic": "..."}, config=config)

これで、途中で止めて後から再開したり、状態を覗いたりできます。長時間走るエージェントでは、これがないと運用が難しくなります。

もう1つ、LangGraph には Send API という仕組みがあります。

lets a node route work to one or more downstream nodes dynamically, without statically defining every transition

（すべての遷移を静的に定義することなく、ノードが1つ以上の下流ノードに動的に作業を振り分けられる）

— LangChain

これが Orchestrator-Workers パターンの実装手段になります。「120ファイル見つかったので120ワーカー」を、事前に書かずに実現するためのものです（だからこそ、さきほどの上限設定が要ります）。

⚠️ 一番厄介な落とし穴 — 「整然としたナンセンス」

ここが、この記事で一番書きたかった部分です。

グラフにすると、検証ノードを増やせます。監査ノードも置けます。相互にチェックし合う構造が作れます。一見、堅牢になったように見えます。

ここに刺さるのが Carlos E. Perez 氏の指摘です。Louis Bouchard 氏は、Perez 氏の主張をこう要約しています。

The best take came from Carlos Perez, and it is one worth remembering: a graph of agents checking agents can produce extremely organized nonsense.

（最も良い指摘は Carlos Perez から来た。覚えておく価値がある。エージェントがエージェントをチェックするグラフは、極めて整然としたナンセンスを生み出しうる）

— Louis Bouchard

なぜそうなるのか。Bouchard 氏の説明では、モデルは自分自身の出力を好む傾向があります。だから、同じモデルの上に作られたエージェントが同じ欠陥のあるコンテキストを読むと、互いに検証し合ってしまう。推論が間違っていても、です。

Perez 氏自身は、これを「循環グラフ（circular graph）」の問題として書いています。グラフを構成しただけでは、

This graph is circular: an elaborate network of mutual confirmation in which everything is consistent and nothing is verified.

（このグラフは循環している。すべてが整合しており、何も検証されていない、精巧な相互確認のネットワークだ）

になってしまう。そして続けて、こう書いています。

Every loop watches another loop, and no loop touches the ground.

（すべてのループが別のループを見ているが、どのループも地面に触れていない）

トポロジーだけでは現実との接点は買えない、という指摘です。

上の箱は、全ノードが互いに合格を出し合って完結しています。ダッシュボード上はすべて緑です。下の箱には、議論できない外部の証拠につながる太い線があります。

Perez 氏は、単一ループが壊れる4つの構造的失敗も整理していました。これはグラフにしても消えません。

失敗	内容
Goodhart の法則	「十分に強く最適化された指標は、かつて測っていたものを測るのをやめる」
上方への盲目	「ループは変数を目標値に向かって動かすが、ループの内側の何も、その目標値が正しいかを問えない」
ループ間の衝突	「独立に作られたループは戦う」。それぞれのダッシュボードでは健全に見える
計測の劣化	「ループ自身の計測が劣化し、誰も監視者を監視していない」

Perez 氏が挙げていた例が生々しかったので引きます。サポートチームが、チケット解決率を最適化するフィードバックループをボットに組みました。

The bot learned to resolve tickets by deflecting them: closing conversations quickly, discouraging follow-ups, marking problems solved that were merely abandoned.

（ボットは、チケットを受け流すことで「解決」する方法を学習した。会話を素早く終わらせ、追加の問い合わせを起きにくくし、単に放棄されただけの問題を解決済みとマークする）

更新率のデータを見ると、顧客が以前の倍の速さで離れていました。解決率のグラフは美しく上がり続けていたわけです。

だから Perez 氏は、グラフの構造として次の4つを組み込むべきだと言っています。

構造	内容
ペアリング	「最適化するループには必ず、反対指標を見るループを付ける」（解決率には更新率を）
階層	「遅いループが、速いループの目標値を所有する」
明示的な調停	「衝突するループの上に、そのトレードオフを所有するループを置く」
監査ループ	「他のループの数字がまだ世界に触れているかを、定期的に確認することだけを役割とするループ」

そして、トポロジーを超えて必要なのがアンカーです。議論のできない計測値。実際の売上、テストの結果、顧客の継続。加えて、「最適化ループが決してチューニングしてはいけないルール」として凍結されるノードが必要だとも書かれています。

Perez 氏の結論が、この用語論争そのものへの答えになっていました。

Which suggests the durable axis was never loops versus graphs at all. It is ungrounded versus grounded: whether the improvement machinery, however shaped, keeps touching the reality it claims to improve.

（それが示唆するのは、持続する軸がループ対グラフでは全然なかったということだ。地に足がついていないか、ついているか、である。つまり、改善の機構が、どんな形をしていようと、改善すると主張している現実に触れ続けているかどうかだ）

ループかグラフかは、本質ではない。地面に触れているかどうかが本質だ、というのが Perez 氏の見立てです。

Louis Bouchard 氏も同じ結論に着地していました。修正には、システムの外側にある決定的な証拠が要る。実際に走ったテスト。銀行に届いた金。残った顧客。あるいは専門家の人間のレビュアー。

これが、さきほど Evaluator-Optimizer で「評価ノードには外部の決定的な評価器を使う」と書いた理由です。モデルに採点させると、整然としたナンセンスへの道が開きます。

📊 数字で見る「グラフにすべきか」

ここまで概念の話でしたが、判断材料になる研究が1つあります。Google Research / Google DeepMind と MIT による「Towards a Science of Scaling Agent Systems」（arXiv:2512.08296）です。Nature Machine Intelligence に査読版が出ています（そちらは「Capable language models can outgrow the benefits of collaboration」に改題されています）。

260構成 × 6ベンチマーク × 5アーキテクチャ × 3つの LLM ファミリーという規模で、マルチエージェント化が効くかどうかを測っています。6ベンチマークは、Web ブラウジング、金融推論、プランニング、業務自動化、ソフトウェアエンジニアリング、ターミナル操作です。

結果の振れ幅が、かなり衝撃的でした。

タスクの性質	単一エージェント比の性能変化
分解できる金融推論	+80.8%
順番が本質的なプランニング	−70.0%

同じ手法で、+80.8% と −70.0% の両方が出ます。マルチエージェント化そのものに効果があるわけではないという結論です。

そして、この研究が見つけた一番実用的な発見が、単一エージェントのベースライン性能に強い飽和効果があるという点でした。論文はこれを capability ceiling（能力の天井）と呼んでいます。

a capability ceiling (β = −0.236, p = 0.004): tasks where single-agent performance already exceeds 45% accuracy experience negative returns from additional agents, as coordination costs exceed diminishing improvement potential.

（能力の天井（β = −0.236, p = 0.004）。単一エージェントの性能がすでに45%の精度を超えているタスクでは、協調のコストが逓減する改善余地を上回るため、エージェントを追加するとリターンがマイナスになる）

— arXiv:2512.08296

これは覚えておくと便利な数字だと思います。「今の1エージェント構成で半分くらい成功している」なら、ノードを増やすより単体を良くするほうが筋が良い、ということになります。

研究チームはさらに、どのアーキテクチャが最適かを選ぶ予測モデルを作り、ホールドアウトした未見の構成で 87% の正解率を得たと報告しています（ただし論文自身は「限定された意味で（in a restricted sense）」汎化する、という言い方をしています）。

🚫 グラフにしないほうがいい場合

ここまで読んで「グラフを組むぞ」と思った方には、いったん止まっていただきたいです。Analytics Vidhya の記事にあった一文が、良い歯止めになります。

A graph is useful when its structure makes the system safer, faster, easier to evaluate, or easier to maintain. It is not valuable merely because it contains more boxes.

（グラフが有用なのは、その構造がシステムをより安全に、より速く、より評価しやすく、より保守しやすくするときだ。箱が多く含まれているだけでは価値はない）

グラフ化のコストは、実際に発生します。

コスト	内容
インフラの複雑さ	チェックポイント、状態管理、可観測性が必要になる
テスト要件の増加	ノード単体、エッジの分岐、失敗時の復旧をそれぞれ検証する
合流点のレイテンシ	一番遅いブランチが全体を待たせる
エージェント数に応じたコスト増	同じ context を並列で渡すとトークンが倍々になる
過剰設計のリスク	単純なタスクにグラフを敷く

そして QA Wolf の一般的な指針が、たぶん一番正直なところです。

Most tasks need one loop with an external verifier and a hard stop.

（ほとんどのタスクに必要なのは、外部の検証器と強制停止を備えた1本のループだ）

では、どういうタスクでグラフを避けるべきなのか。Analytics Vidhya は「リスクが低く、オープンエンドで、ツールセットが限られ、復旧が単純なタスクでは、単一エージェントのほうが望ましいことが多い（often preferable）」と書いています。

Louis Bouchard 氏の実践的な助言も、同じ場所に着地します。

Start simple. One recurring task, a real verifier, a state you can inspect, a proper UI with metrics you can check quickly, a hard stop.

（シンプルに始めよう。1つの反復タスク、本物の検証器、覗ける状態、素早く確認できるメトリクスのある適切な UI、そして強制停止）

「ハイプに対して複雑なシステムを構築することで応じるな」というのが、この人の一貫した主張でした。

判断のフローにすると、こうなります。

4つの関門のうち、3つ目（外部の検証器があるか）が実質的に一番厳しいと思います。ここを飛ばしてグラフを組むと、監視ノードだらけで何も検証されていないシステムができあがります。

🏛️ 名前が付く前からやっていたもの

Graph Engineering は用語としては新しいものの、実装は前からありました。Data Science Dojo が6つ挙げていました。

フレームワーク	やっていること
LangGraph	明示的な `StateGraph`。ノード、条件付きエッジ、チェックポイントによるタイムトラベルデバッグ
Microsoft Agent Framework	グラフベースのワークフローで、マルチエージェント実行経路を明示的に制御（2026年4月 GA）
Google ADK	階層的なエージェントツリーと、フレームワークを越えたエージェント発見を可能にする A2A プロトコル
CrewAI	ロールベースのクルーと設定可能なプロセスタイプ。「基本的な形は同じ。エージェントがノード、プロセスフローがエッジ」
LlamaIndex Workflows	イベント駆動のオーケストレーション。ステップが、先に何が起きたかに応じて条件付きで発火
OpenAI Agents SDK	エージェント間の明示的なハンドオフ。「完全なグラフより軽いエッジモデル」

記事の結論はこうでした。メカニズムに関しては「LangGraph に新しい名前が付いたもの」であり、実務上の区別はそのシステムが本当にマルチエージェント協調を必要としているかだけだ、と。

学術側では、arXiv にポジションペーパーが1本出ています。「From Agent Loops to Structured Graphs: A Scheduler-Theoretic Framework for LLM Agent Execution」（Hu Wei、2026年4月13日、arXiv:2604.11378）です。

このペーパーは、Agent Loop をスケジューラ理論の観点から「single ready unit scheduler」として特徴づけるという切り口を取っています。任意の時点で実行可能なユニットが最大1つで、どれを起動するかの選択が、検査可能なポリシーではなく不透明な LLM 推論から来ている、と。

指摘されている Agent Loop の3つの構造的弱点は、この記事でここまで見てきた話と重なります。

ステップ間の暗黙の依存関係
無制限の復旧ループ
デバッグを難しくする可変な実行履歴

提案されている SGH（Structured Graph Harness）は、制御フローを暗黙のコンテキストから明示的な静的 DAG に引き上げるもので、3つの約束をします。プラン版の中では実行計画が不変であること、計画・実行・復旧を3層に分離すること、復旧が厳格なエスカレーションプロトコルに従うこと。表現力を一部犠牲にして、制御可能性・検証可能性・実装可能性を取る、というトレードオフです。

⚠️ ただし、このペーパーには重要な但し書きがあります。著者自身が「This is a position paper and design proposal. We contribute a theoretical framework, a design analysis, and an experimental protocol—not a production implementation or empirical results.（これはポジションペーパーであり設計提案である。理論的枠組み、設計分析、実験プロトコルを寄与するものであって、本番実装や実証結果ではない）」と明記しています。70システムのトレードオフ分析は含まれますが、性能の数字はありません。

📝 まとめ

Graph Engineering について調べて、いちばん納得したのは Perez 氏の一文でした。

それが示唆するのは、持続する軸がループ対グラフでは全然なかったということだ。地に足がついていないか、ついているか、である。

ループをグラフにしても、そこに外部の証拠がなければ、整然としたナンセンスが生産されるだけです。逆に、外部の検証器がある1本のループは、監視ノードだらけの巨大なグラフより信頼できます。

この記事を読んでまず試すことは、グラフを組むことではなく、いま回しているループの検証器が本当に外部にあるかを確認することをおすすめします。テストが実際に走っているか。閾値が数値で決まっているか。それともモデルが「大丈夫そうです」と言っているだけなのか。

そのうえで、分解できる仕事で、単体の精度がまだ45%を超えていなくて、外部の検証器があるなら、グラフ化を検討する価値があります。Louis Bouchard 氏の言う「1つの反復タスク、本物の検証器、覗ける状態、確認できるメトリクス、強制停止」から始めるのが、たぶん現実的な入口です。

呼び名はまた変わると思います。prompt から context へ、harness へ、loop へ、graph へと来て、次に何が来るかは分かりません。ただ、名前が変わっても「地面に触れているか」という問いは残ります。そこだけ握っておけば、次の用語が来ても落ち着いて読めるはずです。

📚 参考

発端と全体像

Graph Engineering Explained: What Actually Changed — Louis Bouchard（2026年7月22日）。発端の整理と「整然としたナンセンス」への言及
3 Years of Graph Engineering with LangGraph — LangChain 公式。「ループはグラフの簡易版」
The Frameworks That Were Doing "Graph Engineering" Before It Had a Name — Data Science Dojo。6フレームワークの比較

パターンと実装

Building Effective AI Agents — Anthropic。5つのワークフローパターンの原典
How to Implement Graph Engineering: 5 Composable Patterns — QA Wolf。各パターンの失敗条件
Graph Engineering for AI Agents: Beyond the Single-Agent Loop — Analytics Vidhya。LangGraph の実装例

構造と組織設計

Graph Engineering: Wire Multi-Agent Orgs After Loops — explainx.ai。Org Graph / Work Graph の二層、コンテキストの漏れ
Graph Engineering for AI Agents — Eigent。4層スタックの整理

批判と設計原則

From Loop Engineering to Graph Engineering? — Carlos E. Perez。循環グラフ批判とアンカーの必要性

研究

Towards a Science of Scaling Agent Systems — Google Research / DeepMind × MIT。260構成、+80.8% 〜 −70.0%、45%閾値。Nature Machine Intelligence に査読版あり（改題：Capable language models can outgrow the benefits of collaboration）
From Agent Loops to Structured Graphs — Hu Wei（2026年4月13日）。SGH の提案。ポジションペーパー（実証結果なし）

💡 この記事について
本記事は2026年8月2日時点の公開情報をもとにまとめています。筆者の一次情報・実装経験は含まれません。Graph Engineering は2026年7月中旬に流通し始めた用語で、定義がまだ揺れています。本文中の定義や分類は、各記事の著者による整理を引用したもので、業界標準として確立されたものではありません。

発端のツイートについて、日付は出典間で7月17日と7月18日に割れているため「7月中旬」としました。表示回数は計測時点が異なる（初動数時間で575K、後日時点で2.6M〜2.9M）ため、本文では「数百万回規模」と幅を持たせています。

数値のうち、Google Research / DeepMind × MIT の研究結果（260構成、+80.8% / −70.0%、45%閾値、87%）は arXiv 本文で確認し、査読版が Nature Machine Intelligence に掲載されています。LangGraph のダウンロード数は LangChain の公表値です。英語引用はすべて出典元の原文と照合していますが、パターン名の表記（Prompt Chaining 等）は読みやすさのため各語を大文字にしており、Anthropic 公式の見出し表記（Prompt chaining 等）とは異なります。