この記事の対象：AIエージェントを「単発のプロンプト」や「1本のループ」ではなく、明示的な実行グラフ（Execution Graph） として設計したい人。
前提知識：LLM／プロンプトエンジニアリングの基礎。LangGraph などのコードが少し読めると理解が深まります。
重要な注意：本稿の Graph Engineering は Knowledge Graph Engineering / GraphRAG とは別物 です。後述の「用語の境界」で厳密に区別します。

0. TL;DR（3行まとめ）

Graph Engineering とは、Agent・決定的関数・Evaluator・人間承認を Node として配置し、型付きの状態（State）を運ぶ 検査可能な Edge で接続して、実行順序・分岐・並列・合流・権限・予算・回復を「契約」として設計する方法論。
進化の系譜は Prompt → Context → Loop → Graph。「1体の賢いAI」ではなく「AIたちの組織と業務フロー」を設計する層に主戦場が移った、という位置づけです。
グラフは万能ではありません。「複雑タスク × 高い並列性」 のときに真価を発揮し、単純な処理には従来のループで十分。Decision Matrix で選び分けます。

1. Graph Engineering とは何か

1-1. ひとことで言うと「仕事の設計図」

AIに「あるテーマを調査 → 記事を書く → レビューする」という仕事をさせるとします。これを 点（Node） と 線（Edge） で表すと次のようになります。

**Node（ノード）**＝「調査」「記事作成」「レビュー」といった 処理の単位
**Edge（エッジ）**＝「終わったら次はどこへ進むか」という 接続関係・遷移条件

ここまでは普通のワークフローと同じです。Graph が面白くなるのは、分岐（レビューで問題があれば戻す） や 並列（市場調査・競合調査・顧客調査を同時に走らせ、揃ったら合流） を明示的に書ける点です¹²。

つまり Graph Engineering は、「誰が何をして、終わったらどこへ進み、どんな条件で分岐し、どこで合流し、失敗したらどこへ戻り、どこで人間を挟むか」 という“仕事の構造そのもの”を設計・実装・改善する考え方です¹。

1-2. なぜ今、注目されているのか

きっかけは 2026年7月18日、開発者 Peter Steinberger（@steipete） の一言でした。

"Are we still talking loops or did we shift to graphs yet?"（まだループの話をしてる？それとももうグラフに移った？）

この投稿は数時間で数十万〜数百万ビューに達し、「Loop Engineering の時代の次は Graph Engineering」という議論が一気に広がりました³⁴。

背景には「1体の優秀なAIに全部任せる」だけでは、長時間タスクの管理・再開・監査が難しくなる、という実務上の課題があります。判断・状態・副作用が1つのループに集中すると、破綻しやすいのです²。

2. 進化の系譜：Prompt → Context → Loop → Graph

時期	パラダイム	制御対象	主要プリミティブ	十分な場面
2023	Prompt Engineering	1回のモデル応答	指示テキスト	静的・一発勝負のタスク
2025半ば	Context Engineering	コンテキストウィンドウの中身	RAG・system prompt・few-shot	入力の質が結果を決める場面
2026/6	Loop Engineering	1体のエージェントの行動サイクル	Plan → Act → Observe → Retry	単一ドメインの自律タスク
2026/7	Graph Engineering	複数エージェントの“組織”	Node（agent）＋ Edge（依存関係）	横断的・並列・進化するワーク

出典：⁴³

重要な誤解を1つ潰しておきます。 これは「Prompt の次が Loop、その次が Graph」という単純な置き換えではありません。それぞれ別レイヤーの設計技術で、組み合わせて使うものです¹。

「記事を書く」という Node の中身には優れた Prompt Engineering が必要。
「作成 → レビュー → 修正 → 再レビュー」の部分では Loop Engineering が使われる。
それらを含む「調査 → 戦略 → 作成 → レビュー → 承認 → 公開」の全体を設計するのが Graph Engineering¹。

3. 用語の境界：Graph Engineering ≠ GraphRAG

ここが最重要ポイントです。混同されやすい4語を厳密に分けます²⁴。

用語	意味	主目的
Graph Engineering	Agent・決定的関数・Evaluator・人間承認を Node として構成し、型付き状態と検査可能な遷移で接続する実行オーケストレーションの設計活動	実行順序・制御
Execution Graph	1回の仕事について「何が実行可能で・何に依存し・どの状態を受け渡すか」を表す制御構造	制御フローの表現
Knowledge Graph	実世界のエンティティと関係を表す知識構造	知識表現（実行制御が目的ではない）
GraphRAG	知識グラフやグラフ由来の構造を検索・生成に利用する手法	検索拡張生成
Graph Database	グラフ構造の保存・問い合わせを担うデータ基盤（Neo4j 等）	永続化・クエリ

要点：GraphRAG は「知識の探索」、Graph Engineering は「仕事の実行フローの設計」。両者は役割が異なります。ただし Graph Engineering の1ノードとして GraphRAG（検索）を組み込むことはできます⁴。

4. 3つのコア構成要素

4-1. Node（ノード）＝処理単位

従来のワークフローの Node は「API呼び出し」「DB保存」「条件判定」など決められた処理が中心でした。Graph Engineering の Node は、その中身が Agent／LLM／Tool／人間の承認 に置き換わり得るのが本質的な違いです¹。単一責務（1ノード＝1つの仕事）で設計するのが原則です²。

4-2. Typed Edge（型付きエッジ）＝遷移の契約

Edge は単なる矢印ではありません。入力・出力スキーマ、遷移条件、許可される副作用、失敗時の扱いを含む「境界契約」として扱います²。

知識グラフ側でも、エッジに「型」を与えることが多段推論の精度を大きく左右します。untyped edge（"A は B に関連"） は1ビットの情報しか持ちませんが、typed edge は「関係の意味」までエージェントに伝えます⁴。

実務で効く 6つの Edge 型⁴

Edge 型	意味	例	ユースケース
`SUPERSEDES`	これがあれを置き換える	ADR-007 supersedes ADR-003	どの決定が最新かを判断
`DEPENDS_ON`	これはあれを必要とする	auth depends_on JWT	何が壊れるかを追跡
`DECIDED_BY`	これはこの理由で選ばれた	API設計 decided_by RFC-004	設計判断の根拠をたどる
`CAUSED`	これがあれを生んだ	PR#142 caused Bug#42	因果連鎖をデバッグ
`IMPLEMENTS`	これがあれを実現する	Service B implements Interface A	契約を満たす実装を特定
`REFERENCES`	これがあれに言及する	Docs refs ADR-001	決定が現れる文脈を発見

テストでは、typed relationship を加えるだけで複雑なコードレビュータスクの多段推論精度が +18% 改善したという報告があります⁴。

4-3. State（状態）＝チェックポイント可能な共有メモリ

グラフを流れるデータの形を typed state schema（TypedDict / Pydantic） で定義します。各キーには reducer（例：Annotated[list, operator.add] で追記） を付けられ、複数ノードからの書き込みのマージ方法を宣言的に決められます⁵。

State を checkpointer（SQLite / PostgreSQL / in-memory） に永続化することで、途中で一時停止 → クラッシュから再開 → 人間の承認待ちで止める といった長時間・耐障害の実行が可能になります⁶⁷。

5. 代表的な Graph トポロジ（設計パターン）

Andrew Ng が整理した4つの設計パターン（Reflection・Tool Use・Planning・Multi-Agent Collaboration）は、グラフにマッピングして考えると実装に落としやすくなります⁸。以下は実運用でよく使う代表トポロジです。

5-1. Sequential（逐次）

決定論的な順序で1つずつ処理。最もシンプル⁹.

5-2. Concurrent / Parallel Review（並列レビュー）

3つのレビューを同時に走らせ、Synthesizer で集約。ループが「順番待ち」なのに対し、グラフは壁時計時間を圧縮します（後述のコード参照）⁴.

5-3. Orchestrator-Worker（オーケストレーター＋ワーカー）

中央のオーケストレーターがタスクを分解し、ワーカーへ委任。Anthropic が composable pattern として整理したものの1つ²¹⁰.

5-4. Hierarchical（階層）／ Handoff（委譲）／ Group Chat ／ Magentic

Microsoft Agent Framework は、次の組み込みマルチエージェント・オーケストレーションを提供します¹¹。

パターン	説明
Sequential	定義した順にエージェントを実行
Concurrent	エージェントを並列実行
Handoff	文脈に応じて制御を相互に受け渡し
Group Chat	共有会話の中で協調
Magentic	マネージャーが専門エージェントを動的に統括

AutoGen の GraphFlow は、有向グラフ（DAG）で「順次・並列・条件・ループ」を厳密に制御でき、Anthropic の orchestrator-worker を忠実に再現できます¹²。

5-5. Blackboard / Event-Driven（ブラックボード／イベント駆動）

共有知識ベースへ非同期に書き込み合う協調や、pub/sub でエージェントを反応的コンシューマとして動かす方式もあります（EDOW / EDHA / EDB / EDMB など）¹⁰.

6. Loop vs Graph をコードで見る

6-1. 旧来のループ（逐次）

# Sequential: 各レビューが前のレビューの完了を待つ
def agent_loop(task):
    plan = planner(task)
    while not done:
        code = worker(plan)
        sec = security_reviewer(code)   # 待つ…
        log = logic_reviewer(code)      # さらに待つ…
        sty = style_reviewer(code)      # さらに待つ…
        synthesis = synthesize([sec, log, sty])
        if synthesis["pass"]:
            return synthesis["output"]
        plan = replan(plan, synthesis["feedback"])

6-2. 新しいグラフ（並列）

import asyncio

# Parallel: 3つのレビューを同時に実行
async def agent_graph(task):
    plan = await planner(task)
    while True:
        code = await worker(plan)
        # 3レビューを PARALLEL 実行 → 壁時計時間が約1/3
        sec, log, sty = await asyncio.gather(
            security_reviewer(code),
            logic_reviewer(code),
            style_reviewer(code),
        )
        synthesis = synthesize([sec, log, sty])
        if synthesis["pass"]:
            return synthesis["output"]
        plan = await replan(plan, synthesis["feedback"])

asyncio.gather() が3つのレビューを一斉に発火するため、同じコードレビュータスクで並列ワークフローは逐次リトライループより約3倍速く完了したという実測が報告されています⁴。

6-3. LangGraph での最小形

from typing import Annotated
from typing_extensions import TypedDict
import operator
from langgraph.graph import StateGraph, START, END

class State(TypedDict):
    messages: Annotated[list, operator.add]  # reducer で追記マージ

def worker(state: State) -> State:
    ...  # LLM / Tool 呼び出し
    return {"messages": [result]}

builder = StateGraph(State)
builder.add_node("worker", worker)
builder.add_edge(START, "worker")
builder.add_conditional_edges("worker", route_fn, {"retry": "worker", "done": END})
graph = builder.compile(checkpointer=checkpointer)  # 永続化で再開/HITL可能

LangGraph は Google の Pregel や Apache Beam に着想を得た StateGraph → compile()（Pregel ランタイム） という構造で、ノード＝計算ステップ、エッジ＝制御フロー、を明示します。2026年4月時点で GitHub 12.6万スター超と、本番エージェントで最も広く使われている OSS の1つです⁵⁷¹³.

7. 実践：5ステージ導入メソドロジ

チーム導入向けの反復可能な手順です。どのステージも飛ばさないのがコツ⁴。

Stage	名前	やること	アウトプット
1	AUDIT	現状の全ループを棚卸し（平均ステップ数・リトライ箇所・壁時計時間・トークンコスト）	ボトルネック注釈付きループ台帳
2	IDENTIFY	互いに独立で並列化できるステップを特定	インパクト順の並列化候補リスト
3	DESIGN	3〜5ノードで最小トポロジを紙に描く（Planner→Worker→2並列Reviewer→Synthesizer→Pass/Fail）	グラフ・トポロジ図
4	IMPLEMENT	実装して計測（壁時計時間・成功1件あたりコスト）	ベースライン計測付きの動くグラフ
5	TYPE	typed edge（supersedes/depends_on/…）を追加	多段推論可能な typed knowledge graph

Stage 5 は最も飛ばされがちですが、最大の精度改善が眠っている場所です⁴。

8. いつグラフを使うか：Decision Matrix

すべてのタスクにグラフが要るわけではありません。2×2で判断します⁴。

	低並列	高並列
単純タスク	単一ループ（過剰設計しない）例：「リストをソートする関数」	並列ループ例：「独立した10件のPRをレビュー」
複雑タスク	ステージドループ（チェックポイント付き逐次）例：「マイルストーンごとにレビューして機能を作る」	Graph Engineering 例：「auth・DBスキーマ・API契約に触れる重要PRのレビュー」

経験則：独立した検証ステップが3つ以上かつ複雑な分岐ルーティングがあるならグラフ。そうでなければループで十分。

Microsoft も「必要最小の複雑さから始めよ」と明言しています。Direct model call → Single agent with tools → Multi-agent orchestration の順に、信頼して要件を満たせる最も単純な段を選ぶべき、という指針です⁹。

9. コスト vs 性能：誰も語らないトレードオフ

グラフは速いが、必ずしも安くはありません⁴。

	逐次ループ	並列グラフ
壁時計時間	高（3サイクル逐次）	低（1並列サイクル）
トークンコスト	中（単一コンテキスト、1呼び出しずつ）	高（複数エージェント同時稼働）
得意	単純タスク・低通過率（安いリトライ）	複雑タスク・コードレビュー・多段推論
失敗モード	無限リトライ・コンテキスト肥大	全レビュー失敗時のコスト爆発

損益分岐点：1サイクルあたりの通過率（pass rate）が 約50%超でグラフがコスト面でも有利になりやすい。通過率30%だと、グラフは各サイクルが3倍のトークンを消費するため不利になり得ます。

だから見るべき指標は壁時計時間だけでなく 「成功1件あたりのコスト（cost per successful completion）」 です⁴。

10. 検索の観点：Vector Search vs Graph Traversal

GraphRAG-Bench（arXiv 2506.05690）の独立評価が示す傾向⁴：

グラフが勝つ：多段推論（53.4% vs ベクトルのみ 42.9%）、時系列推論、コーパス横断の統合
グラフが負ける：単純なファクト検索、大量検索（インデックスコスト）、エンティティ解決が低精度なとき（85%/hop なら 5hop で信頼度44%）

実務ルール：単純検索はベクトル、複雑な多段推論はグラフ探索。「ベクトル検索は“質問に似たもの”を見つけ、グラフは“答えにつながっているもの”を見つける」という言い回しが的確です⁴。

11. よくある落とし穴（Pitfalls）

グラフの過剰設計：まず3〜5ノードから。20ノード・50エッジは線形ループよりデバッグが難しい⁴。
エンティティ解決の軽視：hop精度が低いと多段探索の信頼度が急落する⁴。
untyped edge の使用：「related to」は推論に使えない。型が知識そのもの⁴。
フィードバックのコストを忘れる：並列レビューで全員失敗→再ディスパッチはトークンを食う⁴。
時間軸の無視：事実は失効する。エッジの作成時刻・最終検証時刻を持たせる（Zep Graphiti の bi-temporal「facts expire, not die」）⁴。
中央オーケストレーターのボトルネック化／会話履歴の中だけに業務状態を隠すこと。状態は検査・回復可能な形で外に出す¹⁰。

運用のベストプラクティス（要約）¹⁴¹⁰

State はコンパクトに構造化し、成果物は URI 参照＋来歴（provenance）で保持。
Node は冪等（idempotent）＆副作用安全に。dedupe キーとリトライメタデータを State に。
グラフとスキーマにバージョンを付け、後方互換のチェックポイント移行を用意。
明示的な終了条件とループガード（最大ステップ数）を必ず設定。
ノード単位の KPI（レイテンシ・トークン・成功/フォールバック）を計測し、予算を強制。

12. FAQ

Q. Graph Engineering は GraphRAG と同じ？
A. いいえ。GraphRAG は検索拡張の一部。Graph Engineering はエージェントメモリグラフ（Graphiti）やマルチエージェント・オーケストレーション（LangGraph、AutoGen GraphFlow など）まで含む、実行フローの設計です⁴。

Q. 必ず複数エージェントが必要？
A. 不要です。単一 Agent＋決定的関数＋Evaluator＋人間の組み合わせでも立派なグラフ。重要なのはAIの“人数”ではなく仕事の構造です²¹。

Q. Graph という考え方は新しい？
A. 概念自体は古くからある（ワークフロー・状態遷移・DAG・依存関係・イベント駆動）。新しいのは Node の中身が Agent/LLM に変わった点です¹²。

Q. どのフレームワークを使えばいい？
A. 低レベルで細かく制御したいなら LangGraph、Microsoft/Azure エコシステムなら Agent Framework / AutoGen（GraphFlow）、役割ベースなら CrewAI 等。ワークフロー複雑性への“適合”で選ぶのが正解で、単純な用途に無理にグラフを使わないこと⁶¹¹。

13. まとめ

Graph Engineering は「AIが働く組織・業務フローそのものを設計する技術」。Prompt/Loop を置き換えるのではなく、内包して束ねる上位レイヤー。
核は Node（単一責務）＋ Typed Edge（境界契約）＋ Checkpointed State。
導入は AUDIT → IDENTIFY → DESIGN → IMPLEMENT → TYPE の5段階で。
選定は Decision Matrix、評価は 成功1件あたりコスト。複雑 × 高並列のときにグラフが輝く。

「どのモデルが一番賢いか？」以上に、「それらをどう組み合わせ、どう仕事を流すか？」が問われる時代。その設計思想が Graph Engineering です¹。

参考文献・出典

藤井晃司「Graph Engineeringとは？ AIエージェントの「仕事の設計図」を初心者向けに簡単解説」note, 2026-08-18. https://note.com/fujikou/n/n6fb81b827e24 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
suwash「Graph Engineering入門：AIエージェントのループを明示グラフへ変える」Zenn, 2026-07-27. https://zenn.dev/suwash/articles/graph-engineering_20260727 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Yash Thakker "Graph Engineering: After Loops, This Is How You Wire Multi-Agent Orgs (2026)" explainx.ai, 2026-07-18. https://www.explainx.ai/blog/graph-engineering-ai-agents-multi-agent-organizations-2026 ↩ ↩²
"From Loops to Graphs: The Next Paradigm in AI Agent Engineering" Flowtivity, 2026-07-25. https://flowtivity.ai/blog/graph-engineering-2026-guide-openclaw-codex/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²²
"LangGraph: Build Stateful AI Agents with Graph-Based Orchestration" PyShine, 2026-05-05. https://pyshine.com/LangGraph-Stateful-AI-Agent-Orchestration-Framework/ ↩ ↩²
Pearson et al. "Graph-Based Agentic AI with LangGraph: Workflow Pathways for Long-Running Stateful Business Processes" arXiv, 2026-07-21. https://arxiv.org/html/2607.19297v1 ↩ ↩²
"LangGraph Tutorial 2026: Build Stateful AI Agents with Graphs" RockB, 2026-04-19. https://baeseokjae.github.io/posts/langgraph-tutorial-2026/ ↩ ↩²
Shirley "Andrew Ng's Agentic Design Patterns, Mapped to Graphs" AI Builder Club, 2026-07-29. https://www.aibuilderclub.com/blog/andrew-ng-loop-to-graph-engineering ↩
"AI agent orchestration patterns" Microsoft Azure Architecture Center, 2026-02-12. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns ↩ ↩²
"Workflow Orchestration" Agentic Design. https://agentic-design.ai/patterns/workflow-orchestration ↩ ↩² ↩³ ↩⁴
"Workflow orchestrations in Agent Framework" Microsoft Learn, 2026-03-30. https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/ ↩ ↩²
社内資料「202507_MultiAgentHandsOn」（AutoGen GraphFlow / Magentic-One / Handoff などのパターン整理） ↩
"LangGraph: Agent Orchestration Framework for Reliable AI Agents" LangChain. https://www.langchain.com/langgraph ↩
"Stateful Graph Workflows" Agentic Design. https://agentic-design.ai/patterns/workflow-orchestration/stateful-graph-workflows ↩