「ループエンジニアリング」「グラフエンジニアリング」という言葉を目にする機会が増えてきた。これまでのプロンプト・コンテキスト・ハーネスエンジニアリングがAIが使う「材料や環境」を扱うのに対し、この2つはAIそのものの「動かし方」「つなぎ方」を設計する技術である点が異なる。登場の経緯、構造、事例、そして人間の役割の変化を要点を絞って解説する。
ループエンジニアリングとは、AIエージェントにタスクの実行・評価・修正というサイクルを自律的に反復（ループ）させるシステム設計技術である。人間が毎回手動で次の指示を与えるのではなく、「何を繰り返すか」「何を基準に評価するか」「いつ終了するか」を設計する。一言でいえば「AIの仕事をどう回すか」のエンジニアリングである。
グラフエンジニアリングとは、複数のAIエージェント、ツール、検証プロセスなどを有向グラフ*で定義し、順序制御・条件分岐・並列処理・エージェント間の情報の引き継ぎ（handoff）を構造的に設計する技術である。一言でいえば「AIの仕事をどうつなぐか」のエンジニアリングである。 ＊有効グラフとはノード（頂点）とエッジ（向きが付いた線）で構成されるグラフ
ループは単一エージェントの自律的な反復実行を設計するものであるのに対し、グラフは複数のエージェントやツールの構造的な連携を設計するものであり、ループはグラフを構成する１つのノードにあたる。ループエンジニアリングが１人の作業員に道具と自律修正の手順書を渡すことだとすれば、グラフエンジニアリングは適切な役割の作業員を配置し、業務フロー全体を設計するようなものである。
図1：ループは同じ流れの反復、グラフは複数の経路・分岐をもつ構造
ループエンジニアリングの発端は、2026年6月、AIエージェント「OpenClaw」の作者として知られるPeter Steinberger氏のX（旧Twitter）への投稿である。彼の「コーディングエージェントに対して逐一プロンプトを書くのではなく、エージェントにプロンプトを与える『ループ』を設計すべきだ」という趣旨の発言が、この言葉が広まるきっかけとなった。
続いてGoogleのAddy Osmani氏がブログ記事「Loop Engineering」でこの概念を整理し、ループを構成する要素を提示した。
さらに、Anthropicで「Claude Code」を率いるBoris Cherny氏の発言――もはやClaudeに直接プロンプトを書かず、Claudeに指示を出し判断させる「ループを書くこと」が自分の仕事だ、という趣旨のもの――が象徴的な言葉としてよく引用されるようになった。
その後、Josh C. Simmons氏が、ノード・エッジ・ステートによって複数エージェントを結合する「グラフ型」の構造設計への移行を提唱した。そして、Steinberger氏が再び「まだループの話をしているのか、それともグラフへ移行したのか」という趣旨の投稿を行ったことで、グラフエンジニアリングという呼び方も一気に広まった。
一方、AIエージェントのフレームワークである「LangGraph」を提供するLangChain社は、グラフエンジニアリングは技術的なブレイクスルーというより、既に存在していた実践に後から名前が付いたものだという見解を示している。実際、Anthropicが2024年に公開した記事「Building Effective Agents」には、既にグラフの代表的パターンが描かれていた。
ループエンジニアリングやグラフエンジニアリングが登場した背景には、AI、特にLLMの能力向上に伴う「AIの課題の変化がある。AIの推論力やツール利用能力の向上により「AIに長時間の作業をいかに自律的に完遂させるか」が新たな課題となり、また問題の複雑化に伴い単一エージェントでは扱いきれない領域が増え、複数の専門エージェントを構造的に連携させる必要が生じてきたのである。
ここで、これまでに登場した５つのエンジニアリングを整理しておこう。
| エンジニアリング | 主な設計対象 |
|---|---|
| プロンプトエンジニアリング | モデルへの指示文そのもの |
| コンテキストエンジニアリング | AIに与える情報・ツールなどの「材料」 |
| ハーネスエンジニアリング | AIが動作する実行環境・接続の仕組み |
| ループエンジニアリング | 単一エージェントの反復動作（動かし方） |
| グラフエンジニアリング | 複数エージェント・ツールの構造的連携（つなぎ方） |
プロンプトからハーネスまでは、「AIが動くための環境条件」が設計対象であり、モデルの内部入力からシステム全体の制御構造へと外側に向けての拡張してきたとらえることができる。ループとグラフは環境というより、「AIの動かし方」へと設計対象が大きく転換している。
↑ 目次に戻る次に、各エンジニアリングの構成要素を見てみよう。
AIエージェントの最小ループは、Reason／Think（思考）→Act（行動）→Observe（観察）からなる「ReAct」と呼ばれる構成である。ループエンジニアリングでは、Goal（目標設定）・Evaluate（評価）・Revise（修正）・Stop Condition（終了条件）なども必要になる。
図2：最小構成の「ReActループ」に、目標設定・評価・修正・終了条件を加えたのが本稿でいうループの構造
Addy Osmani氏はループの構造を「オートメーション（自動化）」「ワークツリー（作業領域の分離）」「スキル（知識・ベストプラクティスの定義）」「プラグイン／コネクタ（外部接続）」「サブエージェント（役割分担）」の５つの要素と、セッションをまたいで文脈を保持する「外部記憶（Memory／State）」の「５＋１」に整理している。
また、Andrew Ng氏はプロダクト開発におけるループを、数分単位で回る「エージェント型コーディングループ」、数時間単位で開発者が確認する「開発者フィードバックループ」、数日〜数週間単位でユーザや市場の反応を取り込む「外部フィードバックループ」の３層に整理している。内側のループほどAIが高速に回し、外側ほど人間や市場が関与する構造である。
Josh C. Simmons氏は、グラフエンジニアリングの構成要素を「ノード（仕事をする単位）」「タイプ付きエッジ（条件分岐やhandoffを含む接続）」「チェックポイント付きステート（引き継ぐ情報と再開のための保存）」だとしている。
図3：グラフエンジニアリングの構成要素（ノード・エッジ・状態・チェックポイント）
Anthropicが2024年に公開した「Building Effective Agents」では、代表的なグラフ構造として、処理を順番につなぐ「Prompt Chaining」、入力に応じて処理先を変える「Routing」、複数処理を並行して集約する「Parallelization」、中央のLLMが仕事を分解し複数workerへ割り振る「Orchestrator-Workers」、生成と評価の役割を分けて繰り返す「Evaluator-Optimizer」の５パターンが示されている。
複数エージェントの協調パターンについては、Anthropicが2026年4月の公式ブログで、成果物を生成する側と検証する側を分ける「Generator-Verifier」、中央が仕事を割り振る「Orchestrator-Subagent」、対等な複数エージェントが連携する「Agent Teams」、メッセージを介してやり取りする「Message Bus」、共有状態を介して連携する「Shared State」の５パターンを紹介している。
↑ 目次に戻るループエンジニアリングとグラフエンジニアリングの具体的な事例を見ておこう。
Claude Code（ループの例） ループの代表事例はやはり「Claude Code」の事例である。ターミナル上で「不具合を修正せよ」といった大まかな目標を与えると、自律的にファイルを検索して文脈を収集し、コードを編集し、テストを実行する。失敗すればエラーログを読み取って再修正・再テストを繰り返す。特に、タスクを実行する主エージェントとは独立した軽量な評価モデルを毎ターンの終わりに起動し、完了条件を機械的に満たすまで主エージェントに次のターンを続けさせる「評価の分離」が特徴である。
Anthropic Researchの事例（グラフの例） Anthropic Researchのマルチエージェント調査システムは、タスクが投入されると、「Lead Agent」が全体計画を立案してサブタスクに分解し、複数の「Search subagent」へ並行して割り振る。各subagentの内部では検索→評価→追加検索というループが回り、全subagentの完了後にLead Agentが成果を集約・検証してレポートを作成する。
Lyft社の事例（グラフの例） Lyft社の顧客対応基盤は、「LangGraph」を用いて構築されており、ルーターノードが問い合わせ内容の意図を分類し、料金・ドライバー・アカウント・安全など専門のサブエージェントへ処理を引き継ぐ。各工程で決定論的なAPI呼び出しやポリシー適合チェックを経由する構造により、誤回答による不正返金などのリスクを排除している。同社は本番品質の向上にはプロンプトエンジニアリングや評価・監視も同様に重要だったと報告している。
Build社の事例（グラフの例） Build社は、データセンター開発などの商業不動産業務を自動化するため、25以上の専門サブエージェントからなるネットワークを「LangGraph」で構築している。
↑ 目次に戻るループエンジニアリングやグラフエンジニアリングにおいては、AIシステムにおける人間の役割が、個々の処理に直接参加する従来の「HITL（Human-in-the-Loop）」から、システム全体を監督し必要時に介入する「HOTL（Human-on-the-Loop）」へとシフトする。人間は「作業者兼デバッグ担当」から「指揮官・品質管理者」となり、目標と終了判定基準の設定、制約条件や評価基準の設定、そしてモデルが自分で取得できない文脈（コンテキスト・アドバンテージ）の注入が主な役割となる。最も重要なのは、どこまでをAIのループに任せ、どこで人間の承認を入れるかという「介入の設計」である。
また、プロンプト・コンテキスト・ハーネス・ループ・グラフの５つのエンジニアリングは代替関係ではなく積み上げの関係にある。プロンプトやコンテキストの設計が甘ければ各ノードの出力精度が下がり、優れたグラフを構築しても全体として機能しない。AIが自ら起動パラメータを組み立てる時代になっても、最外郭における人間の「意図」の定義と「品質責任」は残り続ける。
ループエンジニアリングやグラフエンジニアリングにも限界や課題はある。以下のような課題が指摘されている。
ループの課題
①ゴール・ドリフト（目標からの徐々のズレ） ②無限ループ（同じ失敗の反復） ③コストの増大（トークン・API呼び出しの膨張）
グラフの課題
①コストの増大 ②複雑な事前設計 ③ブラックボックス化（handoffが増えるほど失敗の追跡が困難に）
Anthropicもマルチエージェント研究システムについて、エージェント数が増えるほど調整が急速に複雑化し、小さなエラーが後続処理へ波及すると報告している。すべてのノードが「問題なし」と判定してしまい誤りが検出されない、いわゆる「整然としたナンセンス（organized nonsense）」を課題として指摘する声もある。グラフエンジニアリングは複雑なAIシステムを管理するために導入するにもかかわらず、グラフ自体を複雑にしすぎると管理不能に陥るという逆説をはらんでいる。
↑ 目次に戻るAI技術の潮流は、人間が静的なループやグラフを設計する段階から、AI自身が自らの構造や能力を動的に改変・拡張していく「Self-Improving／Self-Evolving Agents」へと移り始めている。今後は、AIが自らループやグラフを進化させるための「ガードレール」と「正当な評価基準」を与えることが、人間に残された仕事となるのかもしれない。