Loop EngineeringはGraph Engineeringの中にある

「まだループの話してるの、それとももうグラフにシフトした？」

Graph Engineeringという言葉は、ここ数日でX(旧Twitter)を横断して広がっています。

震源はPeter Steinbergerさんが2026年7月18日に投げた、たった12ワードのこの問いでした。

「え、ループもう古いの？」と一瞬固まった人は少なくないと思います。

1か月半前にBoris ChernyさんとAddy OsmaniさんがLoop Engineeringを体系化したばかりで、ようやく実装に手を付け始めた矢先です。

ただ、投稿後に広がった議論と各実装フレームワークの動きを読むと、この話の結論は逆でした。

Loop EngineeringはGraph Engineeringの中に消えたのではなく、Graph Engineeringの内側で相変わらず心臓部を担っています。

Graph Engineeringという言葉が広がった日

Steinbergerさんのこの短い問いかけは、2026年7月21日時点で276万ビューを超え、7,500件を超えるいいねを集めています。

Xを開くたびに「自分のループ運用、まだこのままでいいんだっけ」とどこかで引っかかっていた人が、それだけ多かったということです。

ループが古いのではなく、ループの上の階が急に見えるようになった、という感覚です。

ここを捉え直すとはっきりします。

Graph Engineeringとは何か Loop Engineeringとの違い

この投稿をきっかけに広がった議論の中で、次のような整理が定着していきました。

「a loop is a single node in a graph. You don't graduate from loops to graphs.」つまり、ループはグラフの中の1ノードにすぎず、ループを卒業してグラフに進むわけではない、という捉え方です。

Loop Engineeringは1体のエージェントを自走させる技術で、Graph Engineeringはそれを組織として配線する技術です。

個体の設計と、個体を束ねる設計の話で、片方が古くなって片方が新しくなった関係ではありません。

構造の違いを並べてみます。

「グラフに進む」は正確ではありません。

「ループを内包した組織を設計する」が近い言い方です。

ここで「結局グラフの方が上位互換では」と思うかもしれませんが、腕のいい作業員が1人いても配置がなければ組織は回らず、配置図だけ立派でも腕が悪ければ現場は止まります。

両方が同時に必要です。

なぜ今Graph Engineeringが必要になったのか ループの限界

1体のエージェントを自走させる仕組みが整うと、次に必ずぶつかる壁が3つあります。

この3つがLoop Engineeringの構造的な限界で、Graph Engineeringが生まれた実務的な理由です。

1つ目は測定指標のズレです。

ループが長時間動くほど「メトリクスは通っているが本当に価値を生んでいるか」の乖離が広がります。

テストが全部緑なのに誰も嬉しくない、という状態になっても、ループの内側で自己評価しているだけでは、この乖離に気づけません。

2つ目は検証の循環論法です。

作った本人に検証させると自己評価バイアスで甘くなる問題は、既にSub-agentsの分離で対処しています。

ただしSub-agents同士が同じモデル・同じスキルセットを持つと、結局同じ盲点を共有します。

レビュー役の太鼓判をすり抜けたバグが後から出てくるのは、たいていこのパターンです。

「別の視点」を構造として保証するには、そもそも役割が違うノードを別に立てる必要があります。

3つ目は複雑性の増加です。

1つのループに機能を足していくと、担うタスクが数種類混在します。

CI待ちとレビュー対応が同じループに乗った瞬間、どれか1つが失敗しただけで、関係のない作業まで巻き添えでループ全体が止まります。

単一責任の原則は、ループの設計にもそのまま効いてきます。

3つとも「ループを頑張る」で解ける問題ではありません。

グラフの語彙が要る、というのが今回の話の核心です。

Graph Engineeringに進むべき5つのサイン

「じゃあ自分のエージェント運用はグラフ化すべきか」の判断を助けるシグナルを、一次情報をもとに5つに整理します。

自分の運用と1つずつ照らし合わせながら見てください。

当てはまるものが2つ以上あればグラフ化の圧力がかかっているサイン、1つ以下ならまだループのままで十分です。

補足として、こういう指針も共有されています。

「Default to a loop. Assume one node until a signal forces a second.」——迷ったらループ、2ノード目を要求してくる何かが現れるまでは1ノードで押し切る、という考え方です。

Graph Engineeringの2種類 Org GraphとWork Graph

グラフと一口に言っても、実務では性格の違う2種類が混在します。

Org GraphとWork Graphです。

自分の運用がどちらに近いか押さえておくと、後段のフレームワーク選定も楽になります。

Org Graphとは 安定した組織のグラフ

Org Graphは、役割が固定された長期的な組織構造です。

「PMエージェント」「実装エージェント」「レビューエージェント」「デプロイエージェント」のように、ノードごとに担う職務が明確で、プロジェクト期間を通じて変わりません。

比喩として近いのはスポーツのゾーンディフェンスです。

誰がどのゾーンを守るかが試合前から決まっていて、その配置が試合中に大きく変わることはありません。

エージェントごとに知識・ツール・記憶を長期蓄積させる設計に向きます。

Work Graphとは 動的なタスクのグラフ

Work Graphは、タスク単位で組み替わるエフェメラルなグラフです。

「このPRの調査だけ」「この障害対応の間だけ」に立ち上がり、完了したら消えます。

fan-outで並列調査を撒いてfan-inで結果を統合する、という使い捨てのフローが典型です。

Org Graphが「組織図」なら、Work Graphは「プロジェクト表」です。

組織図の中で人手が足りない時にプロジェクト表を臨時に立ち上げる、という組み合わせが実務では自然になります。

Graph Engineeringを支えるLangGraphとAutoGenとADK

Graph Engineeringを実装で支えているフレームワークは、2026年7月時点で主要な選択肢が3つあります。

LangChainのLangGraph、MicrosoftのAutoGen、GoogleのAgent Development Kit(ADK)です。

自分に近いケースを探しながら読んでみてください。

LangGraphのStateGraph

LangGraph overview - Docs by LangChain

Gain control with LangGraph to design agents that reliably handle complex tasks

docs.langchain.com

LangGraphの中核はStateGraphです。

add_nodeでノードを登録し、add_edgeまたはadd_conditional_edgesでエッジを引くという素直なAPI設計になっています。

ノード間で持ち回る状態をTypedDictで明示的に定義するため、「今この時点で共有されている情報」がコードから追える設計です。

LangChainを既に使っているならほぼ追加学習ゼロで入れます。

Microsoft AutoGenのGraphFlow

AutoGenのGraphFlowは、実行パターンをsequential・parallel・conditional・loopingの4プリミティブで宣言する形をとります。

順に実行・並列に実行・条件分岐・ループを組み合わせて配線するイメージで、Org Graph寄りの安定したフローを組むときに書きやすい設計です。

複数の役割エージェントがチャット形式で議論する構造とも相性が良いのが特徴です。

Google ADKのA2Aプロトコル

Agent Development Kit (ADK)

Build powerful multi-agent systems with Agent Development Kit (ADK)

google.github.io

ADKの特色はA2A(Agent-to-Agent)プロトコルです。

エージェント間のメッセージ交換を標準化されたプロトコルで扱い、別ベンダー・別モデルで作られたエージェント同士でもインターフェイスを揃えて通信できます。

Org Graphの一部ノードだけ別サービス製のエージェントに委譲する構成で価値が出ます。

マルチベンダー前提の組織で強い選択肢です。

Graph Engineeringは何から始めるか

一足飛びに全部グラフ化する必要はありません。

1か月半前に紹介したLoop Engineeringの5要素(Skills、Automations、Worktrees、Sub-agents、Plugins & Connectors)を思い出してもらうと、順番が見えてきます。

私の経験だと、Skills→Automations→Worktrees→Sub-agentsまでを一通り運用したあと、Sub-agentsの構成が複雑になってきたと感じた瞬間がグラフ化の圧力を感じるタイミングです。

作成役1つと検証役1つの2ノード構成では回らなくなり、「別ドメインの調査役を足したい」「並列で回して合流させたい」という要求が具体的に出てきた時、初めてグラフの語彙が要ります。

最初の一歩は、LangGraphの最小サンプル(2ノード+1エッジのStateGraph)を1本、自分の実プロジェクトで動かしてみるのが安全です。

既存のSub-agentsをそのまま2ノードとして置き、間に共有状態のTypedDictを1つ挟むだけで、グラフの手触りは掴めます。

フレームワーク選定を先に悩むより、まず最小サンプルを触ってから決めた方が判断精度が上がります。

まとめ Graph Engineeringはループを消さない

Loop EngineeringはGraph Engineeringの中に消えたわけではなく、Graph Engineeringの1ノードとして生き続けます。

ループを卒業するのではなく、ループを内包した組織を設計する話。

これが今回の核心です。

ただし、グラフが常に正解ではありません。

前述の5つのシグナルが1つも当てはまらないなら、まだループのままで十分です。

Sub-agentsが2ノードで回っているうちにグラフ化しても、複雑性のコストだけが増えて価値が出ないケースの方が多いくらいです。

タイミングの見極めが本題です。

Loop Engineeringを最後まで詰め、限界が見え始めてからGraph Engineeringに進む。

この順番さえ崩さなければ、次にXで「まだそれ使ってるの？」という新しい問いが飛んできても、慌てて乗り換える必要はありません。