ループは死んでいない。複数のAIエージェントをつなぐ「グラフエンジニアリング」

2026年7月6日、僕はこのブログで、AIの目標、状態、証拠、評価、停止条件をつなぎ、結果に応じて次の行動を変える「ループエンジニアリング」について書きました。人間が何度もプロンプトを送り続ける代わりに、AIが実行結果を評価し、修正、続行、停止を決められるようにする設計です。

その記事の公開からまだ2週間も経っていない7月18日、OpenClawを手がけたPeter SteinbergerがXへ短い問いを投稿しました。

Are we still talking loops or did we shift to graphs yet?

まだループの話をしている？ それとも、もうグラフに移った？

その数時間後、Hamel Husainは「Loop Engineering Is Dead. Enter Graph Engineering」という記事を公開しました。AI界隈の用語の寿命は、モデルのリリースサイクルより短いのかもしれません。

もちろん、ループという技術が役に立たなくなったわけではありません。どちらの投稿も、次々と新しい名前を付けたがるAI業界を半分は茶化したものです。それでも、冗談として片づけられない部分があります。

一つのAIエージェントを動かしている間は、実行、評価、修正を繰り返すループを設計すれば足ります。しかし、調査役、執筆役、検証役のように、複数のエージェントや処理を連携させた瞬間、別の問題が発生します。

誰が先に動くのか。
何を同時に動かせるのか。
どの結果を、誰へ渡すのか。
誰が誰を確認するのか。
失敗した処理だけを、どうやってやり直すのか。

この調整そのものを設計対象として捉えるのが、グラフエンジニアリングです。複数のAIエージェントや処理について、依存関係、状態、分岐、権限、検証、停止条件を設計します。

2026年7月時点では、確立された標準や正式な方法論というより、既存の設計問題に付けられた新しい呼び名と考えたほうがよいでしょう。

AIエンジニアリングシリーズ

まず結論。ループは「反復」、グラフは「連携」

ループとグラフの違いは単純です。ループは、一つの仕事を完成へ近づけるための反復です。

実行
  ↓
証拠を確認
  ↓
評価
  ├─ 完了 → 停止
  └─ 未完了 → 修正・再計画
                    ↓
                  再実行

コードを書き、テストを実行し、失敗した原因を調べ、修正してもう一度テストする。前回の結果を見て、次の行動を変えるのがループです。

グラフは、複数の仕事の関係を決めます。

                 ┌→ 公式情報を調査 ─┐
依頼 → 作業を分割 ├→ 海外事例を調査 ─┼→ 結果を統合 → 執筆 → 検証
                 └→ 反対意見を調査 ─┘

どの仕事が独立しているかを見極め、同時に実行できるものは並列化し、必要な結果がそろった場所で統合します。もっと簡単に言えば、こうです。

ループは、一人の作業者がどう仕事を完成させるか。
グラフは、複数の作業者がどう分担し、連携するか。

グラフは、ループの反対ではありません。グラフの中には複数のループを置けます。調査エージェントが検索を繰り返すループ、執筆エージェントが原稿を修正するループ、レビュアーが証拠を確認するループを、それぞれ接続できます。

つまり、グラフはループを置き換えるのではなく、複数のループをつなぎ、統制します。

この記事が対象としている業務

ひとつでも心当たりがあれば、このあと紹介する判断表とテンプレートを試してみてください。

• 調査、執筆、検証のように、複数のAIエージェントや処理を連携させたい
• 実行する順番や、同時に動かせる処理を、毎回勘で決めている
• 一部の処理が失敗しただけで、全体を最初からやり直している
• エージェント間で受け渡す情報が、どこで壊れたのか特定できない
• 分岐の判断をモデルに任せた結果、同じ入力でも経路が再現できない
• エージェントを増やしたのに、速度も品質も上がっていない

この記事を読み終えると、ループのままでよい仕事と、グラフへ分ける価値がある仕事を切り分けられるようになります。

グラフを構成する3つの要素

グラフの基本要素は、ノード、エッジ、状態の3つです。

ノードは、必ずしもAIエージェントではない

ノードと聞くと、複数のAIエージェントを並べる場面を想像しがちです。実際には、一つの作業単位であれば、AIエージェントである必要はありません。

次の処理も、すべてノードにできます。

• データベースから情報を取得する関数
• テストを実行するコマンド
• JSONを検証する処理
• 人間が内容を承認する画面
• メールを送信するツール
• 最終原稿を書くAIエージェント

判断が必要な場所ではモデルを使い、決められた処理はコードで実行します。

すべての箱をAIエージェントにすると、高度なシステムになるわけではありません。単純な加工までモデルに任せると、遅く、高く、不安定になります。

エッジは、「次に実行する」だけではない

エッジが主に表すのは、実行順序よりも依存関係です。

たとえば、次の二つの仕事があるとします。

PDFを要約する
天気を調べる

天気を調べる処理は、PDFの要約結果を使いません。そのため、「PDFを要約して、そのあと天気を調べる」と書いてあっても、処理上の依存関係はなく、二つは同時に実行できます。

一方、次の処理には依存関係があります。

PDFを読む
  ↓
PDFの内容を要約する

後者は、前者が取得した内容を入力として使います。判断するときは、「次のノードは、直前のノードが出力したデータを使うか」と考えます。使わないなら、その待ち時間は不要かもしれません。

状態は、グラフ全体の共有メモではない

状態には、各ノードが必要とする情報を保存します。

state = {
    "research_results": [],
    "draft": "",
    "review_status": "pending",
    "errors": [],
    "approved": False
}

ただし、すべてのノードが自由にすべての項目を書き換えてよいわけではありません。調査ノードは調査結果を書き、執筆ノードは原稿を書き、レビュー担当は評価結果を書きます。誰がどの情報を変更できるのかまで含めて設計する必要があります。

状態は、巨大な共有メモではなく、型と所有者を持った引き継ぎ書として扱ったほうが安全です。

単一のループは、1ノードのグラフと考えられる

調査、執筆、レビューを行う簡単なグラフを、擬似コードで表すと次のようになります。

graph.add_node("research", research_agent)
graph.add_node("write", writer_agent)
graph.add_node("review", reviewer_agent)
graph.add_edge("research", "write")
graph.add_edge("write", "review")
graph.add_conditional_edge(
    "review",
    lambda state: "done" if state.approved else "write"
)

処理の流れは、こうです。

リサーチ
   ↓
執筆
   ↓
レビュー
  ├─ 合格 → 終了
  └─ 不合格 → 執筆へ戻る

ノードは、リサーチ、執筆、レビューの3つ。エッジは、リサーチから執筆、執筆からレビュー、レビューから終了、レビューから執筆への差し戻しの4つです。最後の差し戻し部分がループになっています。

この見方を一つのエージェントへ縮めると、次の形になります。

          ┌─────────┐
          ↓         │
      エージェント → 評価
          │         │
          └─ 未完了 ┘

一つのノードが実行と評価を繰り返し、自分自身へ戻っています。単一エージェントのループは、自分自身へ戻るエッジを持った1ノードのグラフとも考えられます。

だから、「ループからグラフへ」は世代交代ではありません。一つの反復だけを見ていたところから、複数の反復の関係まで見るようになった、という視点の拡張です。

プロンプトからグラフまで、設計対象が外側へ広がってきた

このブログでは、これまでAIエージェントを動かす設計を、プロンプト、コンテキスト、ハーネス、ループに分けてきました。

グラフを加えると、次のように整理できます。

前回の記事では、ループを「目標、状態、証拠、評価、停止条件をつなぎ、次の行動を決める設計」と整理しました。グラフは、そのループが複数存在するときの調整レイヤーになります。

これは初級から上級へ進む序列ではありません。グラフを作っても、各ノードへ適切な情報が渡らなければ失敗します。ツールの権限管理や検証が不十分なら、間違った結果を高速で共有します。停止条件のないループを複数つなげれば、複数箇所で同時にトークンを燃やします。

グラフという上位構造を加えても、下位の設計は必要です。

むしろ、弱いループをグラフへ並べると、失敗が組織化されます。

新しいのは名前であって、構造ではない

グラフを使ったエージェント設計は、2026年7月に突然現れたものではありません。

LangChainは2024年1月に、エージェントをグラフとして構築するLangGraphを公開していました。現在のLangGraphも、長時間動作する状態付きエージェントを、ノード、分岐、チェックポイントなどから構築する低レベルのオーケストレーション基盤として説明されています。

Microsoft AutoGenのGraphFlowも、エージェントを有向グラフとして接続し、順番、並列実行、条件分岐、安全な終了条件を持つループを構築できます。AutoGen自身も、会話ベースの簡単なチームで足りる場合はそこから始め、厳密な順番や条件分岐が必要になった段階でGraphFlowへ移るよう案内しています。

GoogleのADK 2.0でも、判断が必要な部分だけをモデルへ任せ、取得、分岐、実行などを決定論的なコードノードとして接続するワークフローグラフが採用されています。

2026年7月に変わったのは、構造よりも注目の集まり方です。モデル単体の能力に加え、複数のAIとコードをどう連携させるかが、主要な設計問題として意識され始めました。

AI編集部をグラフにすると、何が変わるのか

記事制作を一つのエージェントへ任せる場合、処理は次のようになります。

企画
 ↓
調査
 ↓
構成
 ↓
執筆
 ↓
自己レビュー
 ↓
修正

小さな記事なら、これで十分です。しかし対象が広くなり、公式情報、海外事例、反対意見、製品仕様まで確認するとなると、一つのコンテキストへ情報が集中します。

調査時の仮説を、執筆時にも引きずる。自分で選んだ情報を、自分で正しいと評価する。後半になるほど、初期の条件が薄くなる。

そこで、仕事をグラフとして分けます。

                         ┌→ 公式文書を調査 ───┐
人間がテーマと範囲を決定 ├→ 海外事例を調査 ───┼→ 重複除去
                         ├→ 反対意見を調査 ───┤
                         └→ 数値・出典を確認 ──┘
                                                    ↓
                                                  構成
                                                    ↓
                                                  執筆
                                                    ↓
                                      新しいコンテキストで検証
                                                    ↓
                                              人間が公開判断

ここで大事なのは、エージェントの数ではありません。公式文書、海外事例、反対意見は独立して調べられるため、並列化する意味があります。一方、結果の平坦化、URLの重複除去、項目数の集計はコードで処理できます。

執筆は一つの場所へ集約します。

複数のライターが同じ原稿へ同時に書き込むと、論旨や語調が崩れ、誰の判断で変更されたか追いにくくなるからです。

調査と意見出しは横へ広げ、最終的な書き込みは絞る。これが、グラフを増やしすぎずに使う基本形です。

難題1：そのノードは、本当に分ける必要があるのか

グラフ設計で最も起きやすい失敗は、仕事を細かく分けすぎることです。

「このPDFを要約してください」という依頼を、次のようなグラフにする必要はありません。

PDFを取得するAI
  ↓
文章を分割するAI
  ↓
要約するAI
  ↓
要約をレビューするAI
  ↓
形式を整えるAI

PDFの取得、文章の分割、形式の調整は、通常のコードで実行できます。要約と軽い修正も、一つのエージェント内で完了できるかもしれません。

ノードを分ける意味があるのは、分離によって何かが改善するときです。

二つのノードを一つにまとめても、速度、品質、安全性のどれも悪化しないのであれば、最初から分ける必要はありません。

ノード数は、システムの賢さではありません。増やすたびに、入力、出力、状態、失敗処理、ログ、コストの管理対象も増えます。

僕なら、コードを書く前に紙へ箱と矢印を描きます。その図が一枚の紙へ収まらないなら、実装に入る前に箱を減らします。

難題2：共有状態が、静かに腐っていく

ループでは、会話が長くなるほど不要な情報や古い判断が蓄積する「context rot」が問題になります。

グラフでは、同じ問題が共有状態へ移ります。

調査ノードが不正確な情報を書く
              ↓
共有状態へ保存される
              ↓
執筆ノードが確定情報として使う
              ↓
レビューが文章だけを確認する
              ↓
最終原稿で初めて間違いが発覚する

グラフの後半で誤りを見つけたときには、すでに複数のノードがその誤りを前提に処理を終えています。

対策は派手ではありません。状態に型を持たせ、所有者を決め、変更履歴を残します。

調査ノードが検証済みフラグまで書き換えたり、執筆ノードが都合の悪い出典を共有状態から削除したりできる設計にはしません。

さらに、ノード間でチェックポイントを保存します。どの時点で、誰が、どの値を書いたのかが分かれば、問題が起きた場所から再実行できます。

ただし、再実行には注意が必要です。チェックポイントより後の処理をもう一度動かしたとき、メール送信、課金、レコード作成、公開処理が二重に行われる可能性があります。

外部へ影響を与えるノードは、同じ処理が2回実行されても事故にならない冪等性を持たせるか、実行済みIDを確認してから動かします。

難題3：誰に経路を決めさせるのか

グラフのエッジは、意思決定です。たとえば、レビューに合格したら公開へ進み、失敗したら執筆へ戻します。高リスクなら詳しい監査を実行し、低リスクなら簡易レビューで終えます。

問題は、その判断をコードとモデルのどちらに任せるかです。

基本原則は次のとおりです。

コードで判定するもの

• テストが成功したか
• 必須項目が存在するか
• 件数がゼロか
• スコアが閾値を超えたか
• 予算を超えたか
• 最大試行回数へ達したか
• 承認フラグが付いているか

モデルへ判定させるもの

• 問い合わせの意図は何か
• この変更は高リスクか
• 主張同士が矛盾しているか
• 原稿に論理的な不足があるか
• 追加調査が必要か

モデルへ意味的な分類をさせても、実際にどのエッジへ進むかはコードで固定できます。

risk = classify_with_model(diff)
if risk == "high":
    run_full_audit()
else:
    run_quick_review()

同じ分類結果なら、毎回同じ経路へ進みます。GoogleもADK 2.0で、決定論的に処理できる部分をコードノードへ置き、解釈が必要な部分にだけモデルを使う構成を示しています。

ノードではモデルの判断力を使い、エッジではコードの予測可能性を使う。この分担が、グラフをデバッグ可能な状態に保ちます。

難題4：エージェント同士の合意を信用できるか

マルチエージェントという言葉からは、複数の専門家が議論し、正しい結論へ近づく姿を想像します。しかし、20体のエージェントが同意しても、正しいとは限りません。

同じ基盤モデルを使い、同じ会話履歴を読み、同じ不正確な前提から判断すれば、同じ方向に間違えます。

LLMを評価者として使う研究では、モデルが自分自身の生成した文章を、同等品質の他モデルや人間の文章より高く評価する自己選好バイアスも確認されています。

そのため、次の構造は見た目ほど独立していません。

生成エージェント
  ↓
同じモデル・同じ履歴のレビューエージェント
  ↓
同じモデル・同じ履歴の承認エージェント

信頼できる検証ノードを作るには、少なくとも次の点を押さえます。

• 生成者とは別のコンテキストで評価する
• 可能なら異なるモデルを使う
• 評価基準を先に固定する
• 反証する役割を与える
• テスト、ログ、実行結果、一次資料など外部証拠を使う
• 評価役には書き込み権限を与えない
• 影響の大きな判断は人間へ戻す

別モデルを使えば必ず正しくなるわけではありません。精度を支えるのは、失敗原因を共有しにくい構造です。

コードであれば、実際にテストを実行する。
データ処理であれば、入力件数と出力件数を照合する。
記事であれば、引用元に主張が本当に書かれているか確認する。

「よさそうです」という別エージェントの感想より、外部から得られる証拠を優先します。Anthropicも、エージェント評価では決定論的な検査、実環境での結果、LLM評価、人間による校正を組み合わせる考え方を示しています。

グラフは、コストを下げる技術ではない

グラフにすると処理を並列化できるため、実行時間は短くなる可能性があります。しかし、総トークン数が減るとは限りません。

Anthropicのマルチエージェント調査システムでは、通常のチャットと比べ、単一エージェントが約4倍、マルチエージェントシステムが約15倍のトークンを使用したと報告されています。

同じ調査では、Claude Opus 4を中心にSonnet 4のサブエージェントを使ったマルチエージェント構成が、内部の調査評価で単一のOpus 4を90.2％上回りました。

ただし、効果が出たのは、複数の検索方向へ自然に分解できる調査タスクです。全員が同じ情報を共有する必要がある仕事や、依存関係が多い仕事には向かないとも説明されています。

グラフでは、追加のトークンと調整コストを払い、調査範囲、処理速度、障害分離、検証能力を買います。魔法のコスト削減策ではありません。

価値の低い小さな作業へ15倍のトークンを使っても、経済的には成立しません。

一方で、見落としによる損失が大きいセキュリティ監査や、単一コンテキストでは扱えない大規模調査であれば、追加コストに意味があります。

ループのままでよい仕事、グラフを使う仕事

すべてをグラフ化する必要はありません。

グラフを検討する目安は、次のような場合です。

• 複数の情報源や市場を並列に調査できる
• 大量のファイルを独立して確認できる
• 読み取りと書き込みの権限を分離したい
• 工程ごとに異なるモデルやツールを使いたい
• 一部の失敗で全体を止めたくない
• 条件分岐や承認経路を監査可能にしたい
• 人間による承認を処理途中へ入れたい

反対に、一つのエージェントが数回のツール呼び出しで終えられるなら、ループのままで十分です。仕事を複数に分けられることと、分ける価値があることは別です。

グラフを使うのは、分離による速度、品質、安全性の改善が調整コストを上回る場合だけです。この基準で考えると、過剰なマルチエージェント化をかなり減らせます。

最初からAIの組織図を作らない

グラフを始める前に、まず一つのループを安定させます。

最低限、次が必要です。

• 達成したい状態
• 現在の状態
• 実行結果を確認する証拠
• 合格と不合格の基準
• 不合格時の次の行動
• 最大試行回数
• 最大費用と実行時間
• 人間へ戻す条件

一つのループで、正しく止まれない。証拠を残せない。前回の失敗から行動を変えられない。その状態でノードを増やしても、失敗する場所が増えるだけです。

ループが安定したら、コードを書く前に次のテンプレートを紙に書き出します。

Goal:
  最後に成立していればよい状態は何か
Nodes:
  本当に独立した責任を持つ仕事は何か
Edges:
  どのデータが、どのノードからどこへ渡るか
State:
  保存する情報と、その書き込み担当は誰か
Evidence:
  各ノードの成功を何で確認するか
Routing:
  コードで決める分岐と、モデルへ任せる判断は何か
Budget:
  ノード数、並列数、トークン、時間の上限
Stop:
  完了、無進展、安全停止の条件
Human:
  どこで人間が確認し、何を承認するか

僕なら、最初のグラフは最大3種類の役割で作ります。

作る役
  ↓
確かめる役
  ↓
人間が採用を決める

そこで、入力と出力、状態、停止条件、費用が追えることを確認します。そのうえで、本当に並列化できる調査やファイル処理だけを横へ広げます。最初から10体のエージェントを並べる必要はありません。

よくある質問

グラフエンジニアリングとLangGraphは同じですか

同じではありません。グラフエンジニアリングは、複数の処理の依存関係、状態、分岐、権限、検証を設計する考え方です。

LangGraphは、その構造を実装するためのフレームワークの一つです。AutoGen GraphFlow、Google ADK、通常のPythonやJavaScript、ワークフロー自動化ツールでも同じ考え方を実装できます。

並列実行すれば、グラフエンジニアリングになりますか

並列実行はグラフの一部ですが、それだけでは足りません。結果をどこで集めるのか、一部が失敗した場合にどうするのか、どの状態を後続へ渡すのか、誰が検証するのかまで決める必要があります。

グラフにすれば精度は上がりますか

自動的には上がりません。異なる専門性を分離できる場合や、独立した証拠による検証を追加できる場合には、精度向上が期待できます。同じモデルへ同じ情報を渡し、似た回答を多数決するだけなら、同じ誤りを増幅する可能性があります。

エンジニアでなくてもグラフを設計できますか

設計自体はできます。最初に、仕事の流れを箱と矢印で描いてみてください。誰が何を受け取り、何を出力し、何を条件に次へ進み、どこで人間が承認するのかを言葉にできれば、グラフの骨格は作れます。

実装には開発ツールが必要な場合もありますが、業務フローを知っている人が設計へ参加しなければ、正しいグラフにはなりません。

グラフエンジニアリングという名前が消えても、問題は残る

ループエンジニアリングは死んでいません。グラフの中でも、各エージェントはループを使います。調査を続け、結果を評価し、修正しながら、停止条件を満たすまで処理を続けます。

変わったのは、見る範囲です。

一つのエージェントだけを見ている間は、プロンプト、コンテキスト、ツール、反復を整えれば十分でした。複数のエージェントや処理を動かし始めると、依存関係、状態、権限、検証、費用、失敗時の責任まで設計しなければなりません。

一つのループでは足りなくなった瞬間、調整そのものがエンジニアリングの対象になります。

グラフエンジニアリングという呼び名が半年後にも残っているかは分かりません。それでも、次の問いは残ります。

• この仕事は、本当に別ノードへ分ける必要があるか
• この矢印を、どのデータが通るのか
• この状態を、誰が書き換えられるのか
• この判断は、コードとモデルのどちらが行うのか
• この結果を、何の証拠で信用するのか
• 失敗したとき、誰が止めるのか

グラフは、仕事の責任と受け渡しを偶然に任せないために描きます。AIエージェントをたくさん動かすこと自体が目的ではありません。

僕なら最初に、紙へ三つだけ箱を描きます。

矢印を通して渡すデータの名前を書けないなら、その矢印を消す。独立した責任がないなら、二つの箱を一つへ戻す。そして最後に、誰が結果を確認し、どの条件で止めるのかを書く。

そこまで決まれば、役に立つグラフの半分は、もうできています。

それではまた！

情報元

• HF.M「プロンプトを打ち続けるのはもうやめよう。AIの仕事を評価し、次へ進める『ループエンジニアリング』」。
• LangChain「OpenGPTs」およびLangGraph公式リポジトリ。
• Microsoft AutoGen「GraphFlow（Workflows）」。
• Google Developers Blog「Why we built ADK 2.0」。
• Anthropic「How we built our multi-agent research system」。
• Panicksseryほか「LLM Evaluators Recognize and Favor Their Own Generations」。
• Anthropic「Demystifying evals for AI agents」。