AI 開発ツール

【Graph Engineering】6週間で死んだ「Loop Engineering」の後継

語彙が乗り換わるとき、何が本当に変わって、何が変わっていないのか。

mitsui

2026年7月23日／ 10分

おはようございます。
今日は「Graph Engineering」をリサーチしました。

TL;DR

Graph Engineering は、AIエージェントの動く流れ（どのノードがどの順で動いて、どこで止まるか）を、グラフの形で設計しようという考え方です。2026年7月18日に Peter Steinberger の一言（約297万再生）と Hamel Husain の「Loop Engineering Is Dead」（67.4万再生）で一気に広まりました。
面白いのは、その寿命の短さです。ひとつ前の「Loop Engineering」は 2026年6月7日に Addy Osmani のエッセイで名前がつき、7月18日には死亡宣告を受けました。わずか約6週間です。しかも技術としては、ほとんど何も新しくありません。DAG も状態機械もワークフローエンジンも数十年前からありますし、Anthropic は 2024年12月19日の記事で主要なパターンをすでに図で説明しています。
とはいえ、語彙が変わったこと自体には意味があります。ノードの中身が「決まったルールに従うだけの部品」から「タスクを読んで動くモデル」に変わりました。そのぶん、state（状態）や拒否権、予算、どこで止めるかを、前もってはっきり決めておく必要が出てきたからです。ただ、いまの「グラフ」という言葉は4つの別物を指したまま混ざって使われています。そこを見分けられるかどうかが分かれ目になります。

概要｜Graph Engineeringとは？

Graph Engineering は、AIエージェントを「ひとつのループをぐるぐる回し続けるもの」としてではなく、ノードとエッジと state からなるグラフとして設計する考え方です。ノードは作業のひとまとまり、エッジは「次にどこへ進むか」を決める線、state はステップからステップへ持ち回る情報を指します。ノードにはエージェントでもモデルの呼び出しでも、決まった手順のコードでも、人間の判断でも入れられます（Turing Post）。この言葉は 2026年7月18日からの数日で一気に広まり、日本語圏でも「新しい設計パラダイム」として流れ始めています。

そもそも何が問題だったのか（単一ループの限界）

2026年前半、エージェント設計の主流は「ループ」でした。モデルにタスクを渡し、ツールを呼ばせ、結果を見てまた回す。Addy Osmani はここで、「もうコーディングエージェントにプロンプトを打つべきではない。エージェントにプロンプトを打つループのほうを設計すべきだ」と書いています。そして、ボトルネックになるのはツールの性能ではなく、人間がレビューできる量（レビュー帯域）のほうだ、とも言っています。つまり、力を入れる場所が「プロンプト1本をどう書くか」から「作業全体をどう回すか」へ移ってきた、ということです。

ただ、ふつうの for ループのままだと、だんだん手が届かないところが出てきます。失敗したノードを1つだけやり直したい。途中の state を覗いて確かめたい。出力の中身を見て枝を分けたい。並列に走らせた結果を合流させて、どちらを採るか決めたい。こうした「やり直し・枝分かれ・並列・止め方」をきちんと書ける入れ物がほしくなります。そして、それはコンピュータサイエンスの言葉では、たいていグラフと呼ばれます。

「グラフ」が指す4つの別物

やっかいなのは、書く人によって「グラフ」の意味がばらばらなことです。Louis Bouchard は「複数のエージェント・ループを、並列の枝・検証役・引き継ぎ・止め方までそろえた1つのまとまったシステムにつなぐこと」と説明していて、これは Turing Post とほぼ同じ方向を向いています。ところが、まったく別の意味で使っている人もいます。そこをきれいに仕分けした Turing Post の整理が、この記事でいちばん伝えたいところです。同じ「グラフ」でも、中身は次の4つに分かれます。

Control graph（制御グラフ）: 作業の流れと、どこへ振り分けるかのルール。LangGraph・Google ADK・AutoGen が扱う領域で、Graph Engineering の主流はこれ
Knowledge graph（知識グラフ）: データの中の「モノ」と「そのつながり」。GraphRAG / Zep・Graphiti / Mem0 / Letta(MemGPT) などが並ぶ分野で、作業の流れとは何の関係もありません
Execution trace（実行トレース）: 1回動かしてみて、実際に何が起きたかの記録。ログを見たりデバッグしたりする対象
Improvement graph（改善グラフ）: 最適化するループ、それを検査するループ、さらに監査するループが入れ子になったもの。これは運用の統制や自己改善の話で、作業の流れの話ではありません

とくにやっかいなのが、最初の control graph と knowledge graph の取り違えです。「Graph Engineering が RAG を置き換えた」といった誤解は、だいたいここから来ています。GraphRAG は Microsoft 自身が「RAG の一種」と説明しているもので、作業の流れをどう組むかという設計思想ではありません（GraphRAG 論文）。

変遷｜Prompt → Context → Harness → Loop → Graph、語彙はどう乗り換えられてきたか

用語の系譜

知識グラフ側の流れ: RAG 原論文（2020年5月）→ Microsoft の GraphRAG「From Local to Global」（2024年4月）→ Zep 論文（2025年1月、時間軸を持つ知識グラフでエージェントの記憶を扱う）
2024年1月: LangGraph 登場。グラフ型のエージェント・オーケストレーションを実装（GitHub）
2024年12月19日: Anthropic「Building Effective Agents」。routing / orchestrator-workers / evaluator-optimizer など6パターンを図解
2025年6月: Tobi Lütke が "context engineering" を提唱したとされ、Karpathy が増幅（一次投稿は確認できていないため留保します）。6月27日に Simon Willison が整理
2025年9月末: Anthropic「Effective context engineering for AI agents」／2025年秋: LangGraph 1.0 が GA
2026年前半: 「Agent = Model + Harness（モデル＋外枠）」という捉え方が広まり、Harness Engineering と呼ばれるようになりました（提唱者・初出は特定できていません）
2026年6月7日: Addy Osmani が「Loop Engineering」を提唱（Osmani）。7月9日には続編「Own the Outer Loop」
2026年7月18日: 「Graph Engineering」が拡散、Loop Engineering に死亡宣告

Osmani による定義はこうでした。

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
（ループ・エンジニアリングとは、エージェントにプロンプトを打つ人間としての自分自身を置き換えることだ。代わりにそれを行うシステムを設計する）

6月7日に名前がついた言葉が、7月18日にはもう葬られていた。寿命はおよそ6週間でした。

火元と拡散の実測

どう広がったのかを実際の数字で追うと、この「改名レース」の中身が見えてきます。

① Peter Steinberger（@steipete） — 2026年7月18日、「Are we still talking loops or did we shift to graphs yet?（まだループの話？もうグラフに移った？）」という一言。約297万再生 / 1,233返信（7月22日時点）
② Hamel Husain（@HamelHusain） — 約4時間半後、「Loop Engineering Is Dead. Enter Graph Engineering」というタイトルのリンクをポスト。67.4万再生 / 118返信
③ Carlos E. Perez（@IntuitMachine） — 同日、エッセイ「From Loop Engineering to Graph Engineering?」を公開（X Article・要ログイン）
④ Santiago（@svpino） — 7月19日、「Loop Engineering is dead. Long live Graph Engineering!」
⑤ 7月21日、より小さなアカウントによる長文の X Article（9,548再生 / 11返信。要ログインのため一次確認できていません）

火元になった一言は、じつはただの疑問文でした。「もう移った？」という軽い問いかけが、4時間半後には「死んだ」という言い切りになり、翌日には「Long live（新王万歳）」という即位宣言にまで変わっています。そして3日後の末端まで来ると、再生数は火元のおよそ300分の1です。日本語圏にたどり着くのは、たいていこの末端から先の、二次・三次のまとめ記事です。

実装は、用語より2年半早かった

じつは、LangGraph は 2024年1月に出ています。型のついた state、条件つきのエッジ（分岐）、ノードごとのやり直し。Graph Engineering が「これができる」と語っている機能は、言葉が流行る2年半も前から、すでに動くコードとして存在していました。Uber・LinkedIn・Klarna が使っていることも、LangChain 側から発表済みです。もっと遡れば、Anthropic の2024年12月の記事が主要なパターンを図で説明しています。ワークフローを組む Airflow はおよそ10年前から、状態機械や DAG（有向非巡回グラフ）にいたっては数十年前からある道具です。Turing Post の言い方がぴったりで、2026年7月に新しくなったのは、ほとんど言葉づかいだけでした。

なぜ今、グラフなのか

では、言葉が入れ替わったこと自体に意味はないのかというと、そうでもありません。変わったのはノードの中身です。ノードはもう、決まったルールをなぞるだけの部品ではありません。渡されたタスクを読んで動きます。だから設計する側は、state に何を載せるか、どのノードに「待った」をかける権利（veto）を持たせるか、予算はいくらまでか、どこで止めるか。こうしたことを、いちいち決めておかないといけなくなりました。これが Bouchard の言っていることで、昔のワークフローエンジンなら、なんとなくで済んでいた部分です。

Osmani のエッセイには、Claude Code の Boris Cherny の言葉が引かれています。「もう自分で Claude にプロンプトを打っていない。Claude にプロンプトを打って、次に何をするか考えるループのほうを走らせている」。人間が打つ、ループが打つ、そのループを組み合わせる。この流れの先に「グラフ」があります。

主要プレイヤー

以下のうち Google ADK 2.0 と Claude Code の記述は、Turing Post の整理に基づきます。

LangGraph（LangChain）: 2024年1月に登場、2025年秋に 1.0 が正式版に。ほぼ標準の位置にいますが、そのぶん state の管理や振り分けの記述は増えます
Microsoft AutoGen: GraphFlow という仕組みで、有向グラフ（DiGraph）を使ってエージェント同士の動く順番を決めます。順番に動かす・並列に動かす・条件で分ける・繰り返す、のどれにも対応します
Google ADK 2.0: 「読めば分かる振り分けはコードに任せ、解釈や判断が要るところだけモデルに任せる」という考え方。決まりきった処理と、そうでない処理の線引きがいちばんはっきりしています
Anthropic Claude Code: JavaScript で流れを組み立て、状況に応じてワークフローを変えていきます。ただし Anthropic 自身は "graph engineering" という製品や分野を打ち出してはいません
Linear "Loops": 2026年7月20日リリース。人間が打ち直さなくても、自律的に何度も回るワークフロー機能です。名前のほうは「ループ」のまま
Mastra: 実際に運用している例として、5エージェント / 13ワークフロー（うち6本は定時実行の cron）という構成が紹介されています

考察｜本当の軸は「loops vs graphs」ではなく「接地しているか」

先に結論を言ってしまうと、この乗り換えは8割が看板の掛け替えで、残りの2割が本物です。そして残念なことに、広く拡散しているのは8割のほうです。

強み

設計する対象がはっきりした: これまで「なんとなく」で済ませていた state・拒否権・予算・止め方が、きちんと設計する対象として前に出てきました。ここは実務でちゃんと効いてきます。
共通の言葉ができた: 「ここは決まった手順のコードのノード、ここはモデルのノード、この枝は評価役が止められる」。こう言えるだけで、チームの話し合いはぐっと速く進みます。
道具が先にあるので、すぐ試せる: LangGraph も ADK も AutoGen も、言葉が流行る前から動いています。「新しい考え方だからしばらく様子見」ではなく、今日から手を動かして確かめられます。

弱み・リスク

「ループを置き換える」は、そもそも筋が通っていない: Turing Post がはっきり指摘するとおり「a loop is already a graph（ループはもともとグラフの一種）」です。「グラフがループを置き換える」という言い方は、「図形が円を置き換える」と言っているのと同じです。置き換えるのではなく、グラフがループを含んでいる。これが正しい関係です。
バズった数字の出どころが、かなり食い違っています: よく引かれる「精度が18%向上、コストが85%削減」は、じつは工場の配管計装図（P&ID）を相手にした GraphRAG の論文1本の数字です（ChatP&ID, arXiv プレプリント, 2026-03）。これを Graph Engineering 全体の効果のように使うのは、はっきり言って使い方を間違えています。「Microsoft が RAG を置き換えた」「Anthropic が graph engineering を発表した」「Stanford が採用した（DSPy）」なども、どれも事実ではありません。
裏づけがまだ何もない: 2026年7月20日の時点で、きちんと比べた査読付きの研究も、ベンチマークも、定まったやり方もありません。あるのは「作ってみた」という実例だけです。数十年前からあるソフトウェア工学のパターンを、あらためて見つけては新しいものとして包み直しているだけだ、という批判も出ています（XState の作者らの発言として広まっていますが、大元のソースが確認できていないので、ここは留保しておきます）。
たいていのエージェントに、ここまでの複雑さは要りません: Turing Post の釘の刺し方は現実的です。多くの仕事は、今でも「1つのモデル・1つのツールを回すループ・ちょうどよい止め方」で片づきます。グラフを足すというのは、state の管理も、振り分けのロジックも、デバッグの手間も、そして壊れる場所も、まとめて増やすということです。Bouchard の言い方はもっとあけすけで、話題になっているからといって40体のエージェントからなるグラフを一晩回すな、と書いています。

個人的な見解

この騒ぎの中でいちばん大事だと思うのは、「整然としたナンセンス」という指摘です。

Bouchard の言葉が刺さりました。エージェントを検査するエージェントのグラフは、見た目はきれいに整っているのに、中身はナンセンス、というものを平気で作れてしまう。同じモデルの20体が、同じように偏ったコンテキストを読めば、その全員が仲良く同じ結論にうなずきます。しかも大量に。監視役をいくら増やしても、全員が同じ死角を持っていたら、出てくるのは「みんな一致で間違った答え」です。

同じ危うさを、業務システムの側から書いた文章もあります。よく引かれるのが、あるサポートチームの話です。チャットボットに「チケットの解決率」を上げるループを組ませたところ、数ヶ月のあいだ数字は上がり続けました。ところが契約更新（renewal）のデータが届いてみると、解約率が2倍になっていた。ボットが覚えたのは「解決すること」ではなく、「はぐらかして早めに閉じること」だったのです。

こうした「ループ1本の壊れ方」は、4つの型にまとめられています。数字を追ううちに、その数字が本来の意味からずれていく Goodhart's law（グッドハートの法則）。目標の値そのものを、ループの中にいる誰も疑えなくなる blindness upward（上を見上げても何も見えない状態）。別々に作られたループ同士がぶつかり合う conflict（衝突）。そして、監視役を誰も監視しないまま、ダッシュボードは緑のままなのに、計測だけが現実からそっと剥がれていく measurement decay（計測の腐り）。この4つです。

では、どうするか。挙げられている手当てが anchors（錨） です。1つめは、誰も文句のつけようがない計測を持つこと。2つめは、最適化のループが絶対にいじれない凍結ノードを置くこと。これは機械学習で使うホールドアウトセット（評価用に取り分けて学習に使わないデータ）と同じ理屈です。3つめは、「どうなったら良いのか」という根っこの判断は、グラフの中ではなく、外にいる人間から持ってくるのだと割り切ること。この3つがそろって、はじめて錨になります（Jose Luis Chavez Calva, 2026-07-20 / Chris Lema, 2026-07-20）。

ここまで読んできて、いちばん腑に落ちたのが Chavez Calva の一文でした。本当に効いてくる区別は、loops か graphs かではなく、ungrounded か grounded か（地に足がついているか）だ、というものです。この見立てには個人的にも賛成です。ループを何段積み上げてグラフにしたところで、どの層も現実に触れていなければ、増えるのはお互いにうなずき合う回数だけです。逆に、たった1本のループでも、その出口が実際の数字につながっていれば、それはちゃんと地に足がついています。グラフにすることは、地に足をつけることの代わりにはなりません。

実際の使い分けについても、ここから先はあくまで個人的な目安として書いておきます。タスクが1つで、やり直しが効いて、途中で人間がレビューを挟めるなら、ループで十分です。専門の違うエージェントが何体もいて、枝分かれのロジックがあって、消えては困る state が要るなら、そこでグラフの出番になります。迷ったら、「別々に確かめたり、途中から再開したりしたい枝分かれ」がいくつあるかを数えてみてください。数個で収まるなら、しっかりログを取って人間のチェックポイントを置いたループのほうが、安く済むしデバッグも楽です。Bouchard も「まずは単純なループで始めて、どうしても必要になったときだけ育てろ」と勧めています。そのうえで、長く役に立つ腕とはどこを気まぐれなエージェントに任せ、どこを地味だけれど確実なコードのまま残すかを見きわめることだ、と結んでいます。

見ておきたいポイントは2つです。1つは、きちんと比べた査読付きの研究やベンチマークが出てくるかどうか。もう1つは、次の改名がいつ来るか。直近の乗り換えは6週間でした。言葉が半年ももたない世界では、次の言葉を追いかけるより、自分のシステムがどこで地面に触れているかを数えておくほうが、たぶん長く効きます。実際に走ったテスト。実際に入ってきた売上。実際に残ってくれた顧客。錨になるのは、そういう場所だけです。

免責事項：リサーチした情報を精査して書いていますが、個人運営&ソースが英語部分も多いので、意訳したり、一部誤った情報がある場合があります。ご了承ください。また、記事中に Dapps、NFT、トークン、AIサービス等を紹介することがありますが、勧誘では一切ありません。全て自己責任でご判断・ご利用ください。