# Graph EngineeringはLoop Engineeringの次に何を設計するのか > Prompt、Context、Harness、Loopへと広がったAI Agent Engineeringをたどり、Graph Engineeringで増える設計対象と実務上の境界を整理します。 Canonical URL: https://labs.eastbraver.com/blog/graph-engineering-after-loops Published: 2026-07-21T11:40:00+09:00 Updated: 2026-07-24T15:33:05+09:00 Category: ai-development Tags: ai-agent, software-engineering, agentic-infra Peter Steinberger氏をフォローしているので、2026年7月18日午前9時34分（日本時間）に投稿された短い問いが、いつものようにタイムラインに流れてきました。 「また新しい話してる...！笑　ループの外側の話がまた始まってるのか...！？」 そんな感じで気になって、調べてみました。 [Peter Steinberger氏のGraph Engineeringに関する投稿](https://x.com/steipete/status/2078277297791189132) Prompt EngineeringからLoop Engineeringまでは、これまで自分なりに整理し、それぞれ[Guide](/guides)にもまとめてきました。 今回気になったのは、その外側に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まで積み上がってきた それぞれの設計対象を並べると、こうなります。 | Engineering | 主な設計対象 | 問い | | -------------------------------------------------- | -------------------------------------------------- | --------------------------------------------- | | [Prompt Engineering](/guides/prompt-engineering) | Instruction・例・制約・出力条件 | 何をどう指示するか | | [Context Engineering](/guides/context-engineering) | 推論時に渡す履歴・Tool・外部データ・Memory | 今の判断に何を見せるか | | [Harness Engineering](/guides/harness-engineering) | Tool・権限・Sandbox・Test・Artifact・Observability | Agentが作業・検証・回復できる環境をどう作るか | | [Loop Engineering](/guides/loop-engineering) | 反復・進捗・検証・Budget・停止・人間への移譲 | いつ続けて、どこで止めるか | | Graph Engineering | Node・Edge・State・依存関係・並列処理・権限 | 複数の処理を誰が、どの順番と条件で担うか | [AnthropicがContext EngineeringをPrompt Engineeringの自然な発展として整理した](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)ことで、設計対象はPromptの文言から、推論時に利用できるToken全体に広がりました。 [OpenAIのHarness Engineering](https://openai.com/index/harness-engineering/)が扱うのは、Repository・Tool・Test・Architectureの制約・Observability・Feedback loopまでを含む、Agentが働く環境全体です。 そのHarness上で、仕事の発見・実行・検証・停止を反復可能にしたものがLoopです。[Addy Osmani氏が整理したLoop Engineering](https://addyosmani.com/blog/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](https://docs.langchain.com/oss/python/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です。 ### Graph型Agent workflow Requestを分解した後、Specification researchとImplementationを並行させてMerge stateへ集約します。TestまたはReviewの結果に応じて実装へ戻すかHuman approvalへ進み、OKまたは承認時だけDoneになります。 - RequestをPlanへ分解し、Specification researchとImplementationを進めます。 - 両方の結果をMerge stateへ集約してTestまたはReviewを実行します。 - 回復可能なNGはImplementationへ戻し、承認が必要ならHumanへ渡します。 - ReviewがOKになるかHumanが承認した時点でDoneへ進みます。 *並行作業、検証、承認、復旧を明示したGraph* `Test / review`から`Implementation`へ戻るEdgeは、そのままLoopです。私が冒頭で気になった「Loopの外側」はここでした。各Nodeの内側にAgent Loopがあり、Graph側が依存関係・Stateの受け渡し・実行条件を管理します。 > [!IMPORTANT] LoopはGraphの中に残る > Graphが担うのは、Loopを含む複数の処理単位をどう接続し、制御するかです。 ## Workflow GraphとKnowledge Graphは分けておく ここは、今回かなり混線しているところでした。 追加で確認した[Sprytix氏の長文ポスト](https://x.com/Sprytixl/status/2078778799064584535?s=20)は、Microsoft GraphRAG、Stanford DSPy・STORM、Anthropicの顧客事例をまとめてGraph Engineeringと呼んでいます。 それを案内する[もう一つのポスト](https://x.com/Sprytixl/status/2078969602189746340?s=20)で前面に出ているのは、GraphをAgentの長期Memoryとして使う話です。 この長文の中心はKnowledge Graphです。[Microsoft GraphRAG](https://github.com/microsoft/graphrag)は、非構造化Textから構造化データを抽出し、Knowledge GraphのMemory構造でLLMの出力を補強します。 Anthropicのリンク先も、AnthropicがGraph Engineeringを提唱した資料ではありません。[LaunchNotesの製品「Graph」にClaudeを使った顧客事例](https://www.anthropic.com/customers/graph)でした。 一方、この記事で扱っているのは、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](https://www.anthropic.com/engineering/building-effective-agents)で、Prompt Chaining・Routing・Parallelization・Orchestrator-Workers・Evaluator-OptimizerといったWorkflow Patternを整理していました。 [Microsoft AutoGenのGraphFlow](https://microsoft.github.io/autogen/dev/user-guide/agentchat-user-guide/graph-flow.html)にも、直列・並列・Loop・Graphによる実行制御があります。 2026年5月19日にGAとなった[Google ADK 2.0](https://github.com/google/adk-python/releases/tag/v2.0.0)も、非線形・条件分岐・循環を扱うExecution Graph、並列Worker、動的Scheduling、Agent間Routingを公式に掲げています。 研究側では、2026年7月2日に公開された[Atomic Task Graph](https://arxiv.org/abs/2607.01942)が、依存関係をDAGとして明示し、独立したBranchの並列実行と、失敗箇所だけの局所修復を提案しています。7B〜8BのModelを使い、3つのInteractive Benchmarkで強いBaselineをSuccess Rateと実行効率の両面で上回ったと報告しています。 結果の数字以上に私が気になったのは、検証済みの領域を残したまま、失敗した箇所だけを直す設計です。Graphにする価値は、こういう「全部やり直さない」運用に出るのだと思います。 構造そのものは、前からあります。Graph Engineeringという呼び名が付き、接続部分も設計対象として意識しやすくなった。私はそんな捉え方をしています。 一つのAgentを長く自律実行させるところから、役割を分け、並列に動かし、検証結果で経路を変え、人間に戻すところまで。その関係も設計対象になってきました。 既存の構造でも、何を設計するのかが伝わる名前には意味があると思います。 ## 手元の運用もすでにGraph相当だった ここまで整理してみると、私が運用しているn8nとCodexのAI DigestパイプラインもGraph相当でした。決定論的なNodeとAgentのNodeをつなぎ、生成後は品質ゲートを通し、最後はdraft-firstで人間の承認を待ちます。 一番助かっているのは、私がほぼ手を動かさなくても、生成後の成果物がTestを含む検証まで進むことです。検証Nodeまで接続したことで、任せられる仕事の単位が大きくなりました。 一方、cmuxで複数のAgentを並列化したときは見事に失敗しました。`git worktree`を分けず、全Agentが一箇所で作業し、オーケストレーターも競合作業を考慮していない状態。各PaneのAgentが互いの修正をさらに修正し始め、作業ツリーがぐちゃぐちゃになりました。 これは困りました...。 そこで、Agentごとに`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について、複雑性は必要な場合だけ追加し、まず単純な構成を選ぶよう勧めています](https://www.anthropic.com/engineering/building-effective-agents)。一つの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をどう接続するのか。まずは自分の運用で事故を減らし、どこまで作業を任せられるのかを見ていきたいと思います。