グラフエンジニアリング

一行での定義

AIエージェントに「何を・どの順番で動かし・どこで確認し・どこで止めるか」を、 明示的な有向グラフとして設計する考え方。

提唱の経緯

Josh C. Simmons が 2026年7月4日に「node / typed edge / checkpointed state の3要素」で 明示的に定義したものが、確認できている初期の一次資料。

その後 2026年7月18日に X 上で投げられた問いをきっかけに一気に広がった。 提唱から1か月余りしか経っておらず、定義はまだ統一されていない。

このページは注意して読むこと。 提唱から日が浅く、後述のとおり 「そもそも新しくない」という批判も存在する。

ループエンジニアリングとの関係 — ここが最重要

日本語圏では「ループの次はグラフ」という世代交代の物語で語られがちだが、 一次資料の記述はそうなっていない。

グラフエンジニアリングはループを「置換」するのではなく、ループを node 内部へ保存する。 複数のループと決定的処理の外側に協調層を置く設計。

つまり loop ⊂ graph（ループはグラフのノードの中に入る）。二者択一ではない。

これは ハーネスエンジニアリング と全く同じ構図。 あちらも提唱者本人は「ハーネス構築は文脈工学の特定形式」と包含関係で述べているのに、 流通している整理は世代交代になっている。

一次資料が包含関係を述べ、二次資料が世代交代に読み替える — このパターンが 2件続けて確認できている。「A の次は B」という説明を見たら、一次資料を疑うべき。

なぜループでは足りないとされるのか

記事が挙げる、単一ループで困難になること:

• 複数の独立した作業を並列化できない
• 長時間の停止・再開の状態を追跡できない
• 金銭・削除など権限の異なる副作用を分離できない
• 中間成果物の監査と再評価ができない

設計の3要素

要点は「LLM に任せる部分」と「決定的に処理する部分」の境界を明示的に引くこと。

移行の順序

既存のループから直接グラフを設計しない、という指針が示されている。

境界抽出 → typed state → deterministic node → conditional edge → fan-out / fan-in

複雑性を一度に足さず、段階的に追加する。

実装

LangGraph を使った最小実装が示されている。使う機能は StateGraph / Send / reducer / conditional edge / checkpointer / interrupt。

外部 API 不要で制御フローだけを検証する例として:

• 3件の work item を並列処理（fan-out）
• 失敗した item を再作業する修復ループ
• 評価スコアで終端を判定（gate / revise / stop）

Microsoft Agent Framework、Google ADK 2.0、Temporal も比較対象として言及されているが、 「標準実装」ではなく「設計要素の写像先」という位置づけ。

批判（併記）

iii.dev による批判: 既存の workflow・state machine・分散システムの再命名にすぎない。

これに対し記事の著者は、新規性は「非決定的な LLM node と既存技法の統合」にあると 対置している。どちらが妥当かを判断する材料は現時点で持っていない。

この批判は妥当性が高いように見えるため、status: contested としている。

系譜

• 前に来る概念: ループエンジニアリング（ただし置換ではなく包含）
• 関連: ハーネスエンジニアリング（同じ包含／世代交代の読み替えが起きている）

このページの記録

このリポジトリの新語検出（npm run discover）はこの語を検出できなかった。

原因は2つ。

1. n-gram のトークナイザが [a-z0-9+#.-] 以外を捨てるため、日本語のタイトルからは 語が1つも生成されない。日本語の情報源を集めていても検出に寄与していなかった
2. この語は X と日本語圏（Zenn / YouTube）を中心に広がっており、 HN 中心のコーパスでは母数が足りなかった

ユーザーから YouTube のリンクを示されて初めて存在を知った。レーダーの設計上の限界として記録する。