9月14日、Towards Data Scienceが「Graph Engineering for AI Agents: From Prompts and Loops to Workflows」と題した記事を公開した。この記事では、AIエージェント構築における「ループ」から「グラフ」へのパラダイムシフト——グラフエンジニアリングの概念と実践的な設計手法について詳しく紹介されている。
「ループエンジニアリングは死んだ」——X上の論争から始まった議論
2026年半ば、PSPDFKit（現Nutrient）の創業者Peter Steinbergerが「ループの話をしているのか、それともグラフに移行したのか？」とXに投稿した。それに対してAIエンジニアのHamel Husainが「Loop Engineering Is Dead. Enter Graph Engineering.（ループエンジニアリングは死んだ。グラフエンジニアリングへようこそ）」と題したX記事を公開し、AIエンジニア界隈で大きな議論を巻き起こした。
この記事はその議論を整理し、グラフエンジニアリングが実際に何を変えるのかを具体的に解説するものだ。
ループとグラフ、何が違うのか
記事はまず、AIを使う際の各アプローチを以下のように整理する。
- プロンプトエンジニアリング: モデルへの入力（指示文）を最適化する
- コンテキストエンジニアリング: モデルが参照できる情報を最適化する
- （上記2つはいずれも「1ターン内」の話）
- ループエンジニアリング: ツール・メモリ・反復実行をモデルに与え、複数ターンで処理させる。ただし次のステップを決めるのはモデル自身
- グラフエンジニアリング: ノード・ルーティング・チェックポイントをあらかじめ設計者が定義する。次のステップを決めるのはグラフ（構造）
一言でまとめると、「モデルにプロセス全体を委ねる」から「構造にプロセスを委ねる——モデルは判断が必要な箇所にだけ使う」への転換だ。
シングルエージェントループの何が問題か
記事が挙げる具体例が分かりやすい。「Shopifyマーチャント向けのAI帳簿ツールを作るべきか？」というスタートアップのアイデア検証を1つのモデルに丸投げするケースだ。
モデルは市場調査し、競合を調べ、GTM戦略を立て、レポートを返してくる。一見よさそうに見えるが、「何を調査するか」「証拠をどう解釈するか」「推奨の確信度をどう判断するか」をすべて同一モデルが同一ランの中でこなしている。途中で誰も確認しない。推論が途中でズレても止める仕組みがない。
「答えはより良いプロンプトではない。より小さな仕事だ」
これがグラフエンジニアリングの核心にある考え方だ。ビジネスルールや確定した知識はコードに直接書く。モデルは「曖昧なものを解釈する」「複数の選択肢を比較する」といった判断が必要な部分にのみ使う。
グラフの構成要素：ノード・エッジ・ステート
グラフの実体はシンプルで、3つの要素に集約される。
- ノード: 1つの独立した作業単位。LLM呼び出しでも、人間の承認ステップでも、単純な計算でも構わない。請求書が承認閾値を超えているかチェックするだけなら、LLMは不要だ
- エッジ: 次のステップへのルーティングを定義する。固定・条件分岐・並列処理・ループ・エラー処理・人間承認待ち・イベントトリガーの7種類がある
- ステート: グラフ全体を流れる共有データ構造。チャット履歴1本に全情報を詰め込む代わりに、各ステップが必要な情報だけ読み書きする
Shopifyの例に当てはめると、Plannerノードが問いを「顧客の課題」「競合」「流通」の3軸に分解し、3つのResearcherノードが並列で調査、Skepticノードが根拠の弱いクレームを除外、Mergeノードが生き残った証拠から推薦を生成、最後に人間が判断する——という流れになる。
本番環境で重要になる2つの概念
- Reducer（リデューサー）: 並列ブランチが合流する際の競合を解決する。3つのResearcherが同時に同じステートフィールドを書き込もうとしたとき、後から書いたものが前を上書きしないよう、マージルールを定義する
- Checkpoint（チェックポイント）: ステートのスナップショット。40分のワークフローが39分で落ちたとき、最初からやり直さなくて済む。LangGraphではCheckpointとInterruptが連携しており、人間の承認待ちで一時停止→再開というパターンが実用的に機能する。同様のグラフベースのワークフロー管理を提供するフレームワークとしては、LlamaIndex WorkflowsやCrewAIなども選択肢として存在する
なお、リトライや再開処理の周辺で副作用を持つ処理（メール送信・課金など）には注意が必要だ。再開のたびに同じ処理が複数回実行されないよう、冪等性を担保する設計が求められる。
「グラフ」という言葉の使われ方が2通りある
記事は混乱しやすい点として、「グラフ」に2種類の意味があることを明示している。
- ナレッジグラフ: 情報間の関係を表現する（Microsoft GraphRAGなどが例）。RAGが苦手な「複数ドキュメントにまたがる関係性の推論」を補う
- エージェントグラフ: 作業の流れを定義する（本記事の主題）
「ナレッジグラフは情報をつなぐ。エージェントグラフは作業を調整する。」
両者は排他的ではなく、ナレッジグラフで情報の関係を把握しながら、エージェントグラフでその情報をどう扱うかを制御する、という組み合わせも可能だ。
5つの設計パターン
記事後半では、多くの本番ワークフローが次の5パターンのいずれかに収束すると説明している。
プロンプトチェーニング: 前のノードの出力を次のノードの入力にする。各ノードは必要な情報だけ受け取り、上流のノイズを引き継がない。先述のShopify検証ワークフローがこの典型で、Planner→Researcher→Skeptic→Mergeという直列の流れがこれに当たる
ルーティング: 入力を一度評価して適切なパスに振り分ける（病院のトリアージに相当）。例えばサポートチャットボットであれば、入力を「請求に関する質問」「技術的な問題」「一般的な問い合わせ」に分類し、それぞれ専門化されたノードへ送る、というパターンだ
並列化: 複数のノードを同時実行し、ファンアウト→ファンインで結果を集約する。Shopifyの例でいえば「顧客の課題」「競合」「流通」を3つのResearcherが同時に調査するフェーズがこれに当たる。Reducerの設計とセットで考える必要がある
オーケストレーター/サブエージェント: 計画を立てるノードが実行ノードを動的に呼び出す。タスクの全容があらかじめ確定しない場合——例えばコード生成後にテストを走らせ、失敗したら修正ノードを追加で呼ぶ——に適している
評価・フィードバックループ: 出力を評価ノードが採点し、基準を下回れば理由を添えてやり直す。品質基準を「モデルの判断」ではなく「グラフの構造」として明示化できる点が、ループエンジニアリングとの根本的な違いだ
「今週、紙に書いて試せる」
記事の最後は実践的だ。自分がすでにAIで繰り返しやっている作業を1つ選び、紙の上でグラフとして描いてみる——その練習が、構造化によって本当に改善されるかどうかを判断する最初のステップだと述べている。コードを書く前に、「どのステップに判断が必要か」「どのステップはコードで書けるか」を分離する思考習慣そのものが、グラフエンジニアリングの本質だ。
詳細はGraph Engineering for AI Agents: From Prompts and Loops to Workflowsを参照していただきたい。
