Graph EngineeringはLoop Engineeringの次に何を設計するのか

Peter Steinberger氏をフォローしているので、2026年7月18日午前9時34分（日本時間）に投稿された短い問いが、いつものようにタイムラインに流れてきました。

「また新しい話してる...！笑　ループの外側の話がまた始まってるのか...！？」

そんな感じで気になって、調べてみました。

Prompt EngineeringからLoop Engineeringまでは、これまで自分なりに整理し、それぞれGuideにもまとめてきました。

今回気になったのは、その外側にGraph Engineeringが加わり始めていることです。

Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering

では、Graph EngineeringはLoop Engineeringを置き換えるのか？

私の今の理解では、Loopは一つの部品として残ります。

そのうえで、複数のAgent・決定論的な処理・検証・人間の承認をどう接続するかまで設計する。設計する範囲が、さらに外側に広がったという話です。

なお、Graph Engineeringは2026年7月21日時点で標準化された方法論ではありません。起点になった投稿にも、定義や設計原則までは書かれていません。 本稿では、既存のAgent Frameworkと一次資料から確認できる範囲に留めます。

設計対象はPromptからGraphまで積み上がってきた

それぞれの設計対象を並べると、こうなります。

この積み上がりを、Graphの内側にLoopが残る形で描くと次のようになります。

図の読み方

1. Promptは指示と制約を設計し、その外側のContextは判断に必要な履歴や外部データを選びます。
2. HarnessはTool・権限・Testを含む作業環境を整え、Loopは反復・検証・停止を制御します。
3. GraphのNodeには、そのLoopだけでなく決定論的な処理、検証、人間の承認も置けます。
4. Graphは共有StateとEdgeを使い、複数の処理単位の依存関係・遷移条件・権限を外側から制御します。

AnthropicがContext EngineeringをPrompt Engineeringの自然な発展として整理したことで、設計対象はPromptの文言から、推論時に利用できるToken全体に広がりました。

OpenAIのHarness Engineeringが扱うのは、Repository・Tool・Test・Architectureの制約・Observability・Feedback loopまでを含む、Agentが働く環境全体です。

そのHarness上で、仕事の発見・実行・検証・停止を反復可能にしたものがLoopです。Addy Osmani氏が整理したLoop Engineeringも、Harnessの一つ上の階層にLoopを置いています。

私には、Graphがここまで積み上げた部品同士の接続に名前を付けたものに見えます。

GraphはLoopを内側に残す

Graphという名前だけを見ると、複数Agentの組織図を作る話に見えます。でも、NodeはAgentに限りません。

• Agent Loop
• 決定論的なFunctionやTool
• Routerと条件分岐
• TestやEvaluator
• Human Approval
• Queueや外部Workflow

LangGraphのGraph APIには、次の一文があります。

“Nodes and Edges are nothing more than functions—they can contain an LLM or just good ol’ code.”

— LangGraph Graph API

ここまで割り切って書かれているので、Graph Engineeringを「Agentをたくさん並べる技術」と理解するとズレる、というのが正直な感想です。

Stateを受け取って仕事をするのがNode、次にどこに進むかを決めるのがEdge。そのNodeはLLMを含むAgentでも、普通のCodeでも構いません。

Code変更を役割ごとに分けるなら、たとえばこんなGraphです。

テスト・レビューから実装へ戻るEdgeは、そのままLoopです。私が冒頭で気になった「Loopの外側」はここでした。各Nodeの内側にAIエージェントのLoopがあり、Graph側が依存関係・状態の受け渡し・実行条件を管理します。

Workflow GraphとKnowledge Graphは分けておく

ここは、今回かなり混線しているところでした。

追加で確認したSprytix氏の長文ポストは、Microsoft GraphRAG、Stanford DSPy・STORM、Anthropicの顧客事例をまとめてGraph Engineeringと呼んでいます。

それを案内するもう一つのポストで前面に出ているのは、GraphをAgentの長期Memoryとして使う話です。

この長文の中心はKnowledge Graphです。Microsoft GraphRAGは、非構造化Textから構造化データを抽出し、Knowledge GraphのMemory構造でLLMの出力を補強します。

Anthropicのリンク先も、AnthropicがGraph Engineeringを提唱した資料ではありません。LaunchNotesの製品「Graph」にClaudeを使った顧客事例でした。

一方、この記事で扱っているのは、Agent・Tool・Test・Human ApprovalをNodeとしてつなぐWorkflow / Execution Graphです。

Knowledge Graphが持つのは「何を知っているか」の関係。Workflow Graphが持つのは「誰が、どの順番と条件で動くか」の関係です。両方を組み合わせることはできますが、私は分けて考えています。

要約ポストには「Stanford–Anthropic Framework」という論文風の画像も添付されています。ただし、Anthropic・Stanford・arXivの一次資料としては確認できませんでした。

ポスト本文にある$3.1M・42%も、本稿の根拠には使いません。

同じGraphという言葉で、別の設計対象が語られている。Graph Engineeringはまだ、そのくらい言葉の境界が曖昧です。

新しいのは構造より設計の重心

NodeとEdgeで処理をつなぐ構造は、前からあります。Anthropicは2024年のBuilding Effective AI Agentsで、Prompt Chaining・Routing・Parallelization・Orchestrator-Workers・Evaluator-OptimizerといったWorkflow Patternを整理していました。

Microsoft AutoGenのGraphFlowにも、直列・並列・Loop・Graphによる実行制御があります。

2026年5月19日にGAとなったGoogle ADK 2.0も、非線形・条件分岐・循環を扱うExecution Graph、並列Worker、動的Scheduling、Agent間Routingを公式に掲げています。

研究側では、2026年7月2日に公開されたAtomic Task Graphが、依存関係をDAGとして明示し、独立したBranchの並列実行と、失敗箇所だけの局所修復を提案しています。7B〜8BのModelを使い、3つのInteractive Benchmarkで強力なBaselineをSuccess Rateと実行効率の両面で上回ったと報告しています。

結果の数字以上に私が気になったのは、検証済みの領域を残したまま、失敗した箇所だけを直す設計です。Graphにする価値は、こういう「全部やり直さない」運用に出るのだと思います。

構造そのものは、前からあります。Graph Engineeringという呼び名が付き、接続部分も設計対象として意識しやすくなった。私はそんな捉え方をしています。

一つのAgentを長く自律実行させるところから、役割を分け、並列に動かし、検証結果で経路を変え、人間に戻すところまで。その関係も設計対象になってきました。

既存の構造でも、何を設計するのかが伝わる名前には意味があると思います。

手元の運用もすでにGraph相当だった

ここまで整理してみると、私が運用しているn8nとCodexのAI DigestパイプラインもGraph相当でした。同じ入力から同じ結果を出すNodeとAIエージェントのNodeをつなぎ、生成後は品質検査を通し、最後は下書きの状態で人間の承認を待ちます。

一番助かっているのは、私がほぼ手を動かさなくても、生成後の成果物がテストを含む検証まで進むことです。検証用のNodeまで接続したことで、任せられる仕事の単位が大きくなりました。

一方、cmuxで複数のAIエージェントを並列化したときは見事に失敗しました。git worktreeを分けず、全エージェントが一箇所で作業し、オーケストレーターも競合作業を考慮していない状態。各ペインのエージェントが互いの修正をさらに修正し始め、作業ツリーがぐちゃぐちゃになりました。

これは困りました...。

そこで、AIエージェントごとにgit worktreeを切り、オーケストレーターのタスク割り振りにも競合・衝突の想定を入れました。並列Nodeを増やすだけでは足りず、作業場所と責任範囲まで分けてようやく運用できる。私にとってGraph Engineeringが必要だと感じるのは、こういう事故を経験したときです。

Graphで先に決めたいのはStateと権限

Nodeが増えると、実行経路と失敗箇所も増えます。並列実行した結果が競合する、同じToolを重複実行する、古いStateから再開する、循環してBudgetを使い切る。こういう事故が、NodeとNodeの間で起きます。

私なら、Agentを増やす前に次を決めます。

Stateの更新者を決める。

成果物・進捗・検証結果・Budget・承認状態を一つの会話履歴に全部押し込むと、どのNodeが何を確定したのか追いにくくなります。

State Schemaを定義し、Nodeごとの読み取りと更新範囲を分けます。中断と再開を扱うなら、Checkpointの保存単位とSchema変更時のルールも先に決めておきます。

Edgeの遷移をAgent任せにしない。

Agentが「完了しました」と言ったので次へ進む。

これだけでは、判定がAgentの自己申告に残ります。

Test結果・Evaluatorの判定・Budget・Deadline・権限不足・Human Approvalなど、遷移条件を外側から確認できる形にしておきます。Retry・Reflection・Replanも失敗原因に応じて経路を分けておくと、後から自分やチームが復旧するときにだいぶ楽です。

権限はNodeごとに絞る。

調査Nodeは読み取り専用で十分です。実装Nodeは対象Repositoryだけ更新可能、外部への書き込みやDeployは承認を通す。Nodeごとに権限を絞っておけば、一つの誤判断がGraph全体の事故に広がる範囲を抑えられます。

事故から戻れるTraceを残す。

どのNode・Prompt・Model・Tool・Stateを通ったのか。最終結果だけを残しても、事故が起きた後に追えません。

Graph ID・Run ID・Node IDをTraceに残し、Tool実行と外部状態の変更までつなげます。そうしておけば、失敗した部分だけを安全に再実行できます。事故から戻るための、実行経路とArtifactです。

最初からGraphにしない

NodeとEdgeを増やせば、保守・Test・Observabilityの負担も一緒に増えます。

AnthropicもAgent Systemについて、複雑性は必要な場合だけ追加し、まず単純な構成を選ぶよう勧めています。一つのAgent Loopで完了する仕事は、そのままの方がStateも失敗箇所も少なく済みます。

私がGraphに広げるなら、判断材料はこのあたりです。

• 役割ごとにTool・Model・権限を分けたい
• 独立した作業を並列に進めたい
• 生成と検証を別のNodeへ分けたい
• 人間の承認を途中へ組み込みたい
• 全体をやり直さず、失敗した部分だけ再実行したい
• 複数のLoopでStateとBudgetを共有したい

Node名だけが違い、同じContext・Tool・権限で順番に処理する構成なら、一つのLoopや決定論的なWorkflowで十分かもしれません。

Graph Engineeringでやることは、増えた処理単位の責任と接続を制御する設計です。Agentを増やすのは手段の一つです。

Loopの外側まで設計する

今回の問いをこの並びに置くと、最後にGraphが加わります。

Prompt → Context → Harness → Loop → Graph

Steinberger氏の問いに、今の私ならこう答えます。LoopをやめてGraphに移るのではなく、Loopの外側にある接続と制御の話が始まっている。

Graph Engineeringはまだ呼び名が先行し、Workflow GraphとKnowledge Graphまで同じ言葉で語られている段階です。

言葉そのものを追うより、State・権限・停止条件・検証・Traceをどう接続するのか。まずは自分の運用で事故を減らし、どこまで作業を任せられるのかを見ていきたいと思います。