ループエンジニアリングとグラフエンジニアリングを比較　AIエージェントを『一人で回す』から『チームで動かす』へ

はじめに

AITCセンター長の深谷です。

以前、以下のような記事を作成しました。

この記事では、生成AIを企業で活用するための三つの設計領域を整理しました。

1. プロンプトエンジニアリングは、AIへの「頼み方」を設計する
2. コンテキストエンジニアリングは、AIに必要な情報を適切に渡す「見せ方」を設計する
3. ハーネスエンジニアリングは、ツール、権限、実行環境、検証、監視、人へのエスカレーションなどを含め、AIが安全に成果を出せる「働かせ方の仕組み」を設計する

その後、AIエージェントの活用がさらに進む中で、「ループエンジニアリング（Loop Engineering）」と「グラフエンジニアリング（Graph Engineering）」という言葉が話題になっています。

2026年6月、GoogleのAddy Osmani氏は、以下の記事を公開しました。

人がAIエージェントへ一つずつ指示するのではなく、AIエージェントに仕事を与え、結果を確認し、次の仕事を決める仕組みそのものを設計する考え方です。

続いて2026年7月ごろから、「グラフエンジニアリング」という表現も広がり始めました。こちらは、一つのAIエージェントを繰り返し動かすだけではなく、複数の専門エージェントや処理、検証、承認をノードとして配置し、それらの接続関係を設計する考え方です。

本稿では、用語の新しさに振り回されず、ループエンジニアリングとグラフエンジニアリングが何を設計対象とし、企業のAI活用でどう使い分けるべきかを整理します。

ループは「仕事の反復」、グラフは「仕事の接続」を設計する

最初に、二つの違いを簡潔に整理します。

ループエンジニアリングは、一つの目標に対してAIエージェントが「行動する、結果を観察する、評価する、修正する」というサイクルを、完了条件を満たすまで回せるようにする設計です。

グラフエンジニアリングは、複数のAIエージェント、決定論的なプログラム、ツール、人の承認などをノードとして配置し、どの順序や条件で仕事を渡すかをエッジとして設計するものです。

したがって、グラフエンジニアリングがループエンジニアリングを置き換えるわけではありません。一つのノードの中でAIエージェントがループを回し、そのような複数のノードをグラフとして接続することもできます。

生成AIを「非常に優秀な新人」に例えるなら、次のように表現できます。

• プロンプトエンジニアリングは、新人への指示の出し方
• コンテキストエンジニアリングは、新人に渡す資料と背景情報の整理
• ハーネスエンジニアリングは、新人が安全に働ける職場環境の整備
• ループエンジニアリングは、新人が自分で進捗を確認しながら仕事を完了まで回す業務サイクルの設計
• グラフエンジニアリングは、複数の担当者、専門家、レビュワー、承認者をつなぐ業務体制の設計

ループは「一人の担当者が仕事を完了させる仕組み」、グラフは「チームとして成果を出す仕組み」と考えると、違いを理解しやすくなります。

ループエンジニアリングは「人が回していた試行錯誤」を仕組みに移す

これまでの生成AI活用では、人が実質的なループを担っていました。

AIへ指示を出し、回答を読み、問題点を見つけ、追加の指示を出す。結果が良くなるまで、このやり取りを人が繰り返していました。言い換えれば、人がAIの外側で「forループ」を回していたわけです。

ループエンジニアリングでは、この反復をシステム側へ移します。AIエージェントは、与えられた目標に対して行動し、ツールの実行結果やテスト結果を観察し、次の行動を自ら決めます。そして、完了条件を満たすまで処理を継続します。

以下のIBMの記事では、典型的なエージェントループを「Goal、Action、Observation、Adjustment」という段階で整理しています。実務で信頼できるループにするには、次の要素を明確にする必要があります。

• 何をきっかけに開始するのか達成すべき目標は何か
• 何をもって完了と判定するのか
• どのデータとツールを利用できるのか
• 途中の状態や成果物をどこに保存するのか
• 失敗したときに何回まで再試行するのか
• 時間、トークン、費用の上限をどうするのか
• どの条件で人へエスカレーションするのか

重要なのは、単に「成功するまで繰り返す」と指示することではありません。評価基準と停止条件を含めて設計することです。停止条件が曖昧なループは、同じ誤りを繰り返し、時間とコストを消費し続ける危険があります。

製造設備の異常原因調査をループエンジニアリングで考える

たとえば、製造設備で異常アラームが発生し、AIエージェントに原因候補と初動対応案を作らせる業務を考えてみます。

ループ型では、一つの調査エージェントが次の処理を繰り返します。

1. アラーム、センサーログ、設備マニュアル、過去の障害履歴を確認する
2. 原因仮説を作る
3. 追加で必要なデータを取得する
4. 仮説と根拠の整合性を検証する
5. 根拠が不足していれば仮説を修正する
6. 完了条件を満たせば、原因候補と初動対応案を出力する

完了条件としては、たとえば「原因候補ごとに根拠となるログと手順書の該当箇所が示されている」「安全上禁止された操作を提案していない」「信頼度が基準値を満たす」などを設定できます。

また、最大反復回数を5回とし、それでも基準を満たさなければ保全担当者へ引き継ぐ、といった停止条件も必要です。

この形は、目的が一つにまとまり、同じ担当者が調査から提案まで行える仕事に向いています。AIエージェントには進め方の自由を与えつつ、検証基準と停止条件によって暴走を防げます。

ループだけでは難しくなる場面

一つのループは強力ですが、業務が複雑になると限界も見えてきます。

たとえば、設備異常の調査に、設備保全、品質管理、生産計画、設計変更、法令・安全基準など、異なる専門性が必要になったとします。一つのAIエージェントにすべてを任せると、扱うコンテキストが肥大化し、役割や判断基準が混ざりやすくなります。

また、調査結果を作ったAIエージェント自身に最終評価まで任せると、自分の結論を甘く採点する可能性があります。複数の観点を並列に調査したい場合や、作成者と検証者を分離したい場合にも、一つのループへすべてを詰め込むのは適切ではありません。

そこで必要になるのが、複数の役割と処理の接続を明示するグラフエンジニアリングです。

グラフエンジニアリングは「AIエージェントの業務配線図」を設計する

グラフエンジニアリングでは、AIエージェントシステムを主に次の三要素で表します。

1. ノード：実際に仕事をする単位
2. エッジ：次にどのノードへ進むかを決める接続
3. 状態：ノード間で共有、更新、引き継ぎされる情報

ノードは、AIエージェントだけとは限りません。LLMへの1回の問い合わせ、通常のプログラム、検索やデータ更新を行うツール、人による確認・承認もノードになり得ます。

エッジには、必ず同じノードへ進む固定経路だけでなく、状態や評価結果によって分岐する条件付き経路、複数ノードを同時に動かすファンアウト、それらの結果を集約するファンイン、前の処理へ戻るループなどがあります。

つまり、グラフエンジニアリングの本質は、単に複数のAIを並べることではありません。「どこはAIに任せ、どこはシステムで経路を固定し、どこで人が承認するか」を明示することにあります。

Segun Akinyemi氏は、以下の記事で、「AIエージェントを“一人でうまく働かせる”段階から、“チームとして安全かつ確実に働かせる”段階へ進むための設計論がGraph Engineeringである」と言及されています。

グラフエンジニアリングはナレッジグラフやGraphRAGとは異なる

ここで、混同しやすい点を整理しておきます。

本稿でいうグラフエンジニアリングは、ナレッジグラフを作る技術やGraphRAGを指すものではありません。

ナレッジグラフは、人、製品、部品、設備、規程などの実体と、その関係を表現する「知識の構造」です。

一方、本稿のグラフエンジニアリングは、調査、分析、レビュー、承認、実行などの処理をノードとして表現する「実行の構造」です。

両者を組み合わせることはできます。たとえば、実行グラフ上の原因分析エージェントが、設備と部品の関係を表すナレッジグラフを参照することはあります。しかし、設計対象は別物です。

製造設備の異常原因調査をグラフで考える

先ほどの異常原因調査をグラフ型にすると、たとえば次のように役割を分けられます。

1. 受付・分類ノードが、アラーム内容と影響範囲を判定する
2. 設備ログ分析ノード、保全履歴分析ノード、設計変更分析ノード、安全基準確認ノードを並列に動かす
3. 統合ノードが、それぞれの調査結果と根拠をまとめる
4. 独立した検証ノードが、根拠の不足、矛盾、禁止操作の有無を確認する
5. 基準を満たさない場合は、必要な分析ノードだけへ差し戻す
6. 基準を満たした場合は、保全責任者の承認ノードへ進む
7. 承認後に、作業指示の登録や関係者への通知を行う

この構成では、異なる専門領域を分離でき、複数の調査を並列化できます。また、提案を作る役割と評価する役割を分け、外部システムへ変更を加える前に人の承認を挟めます。

さらに、どのノードが、どの根拠をもとに、どの経路を選んだのかを記録しやすくなります。説明責任や監査が重要な企業業務では、この追跡可能性が大きな価値を持ちます。

グラフを細かく描きすぎると、従来型ワークフローへ逆戻りする

一方で、経路を細かく定義すればするほどよいわけではありません。

グラフの全経路を人が細かく固定すると、AIエージェントの強みである柔軟な判断を失い、従来型のワークフローエンジンにAIを埋め込んだだけになりかねません。逆に、すべての経路選択をAIへ任せると、グラフとして統制する意味が薄れます。

実務では、次のような分担が有効です。

• グラフの外側では、担当範囲、引き継ぎ先、承認、禁止経路、並列実行、停止条件を明示する
• 各ノードの内側では、AIエージェントに目標、能力、制約、評価基準を与え、具体的な進め方は一定範囲で自律させる
• 条件付きエッジでは、AIの自由な感想ではなく、状態データや検証結果を使って経路を決める

これは、経路を中心にすべてを固定する設計ではありません。業務上必要な統制点だけをグラフで明示し、その内側ではAIエージェントの自律性を生かす、決定論と非決定論の組み合わせです。

ループエンジニアリングとグラフエンジニアリングの比較

二つの考え方を表で整理します。

プロンプト、コンテキスト、ハーネス、ループ、グラフの関係

ここまでの五つのエンジニアリングを、設計上の問いとして整理すると次のようになります。

この五つは、古いものから新しいものへ置き換わる関係ではありません。また、厳密に分離された階層でもなく、実装上は重なり合います。

各グラフノードの中では、プロンプトとコンテキストが必要です。AIエージェントがループを安全に回すには、ツール、権限、監視などのハーネスが必要です。グラフ全体にも、状態管理、監査、再開、障害回復といったハーネスが必要になります。

重要なのは流行語を選ぶことではなく、それぞれの観点を理解し、対象とする業務課題にどの観点を取り入れていくかをしっかり設計していくことです。

まず小さなループから始める

ループエンジアリングやグラフエンジニアリングという言葉が新しく見えても、最初から多数のAIエージェントを接続する必要はありません。まずは一つの業務目標を決め、その達成に必要な情報とツールを、一つのAIエージェントに渡すところから始めるのが現実的です。

このとき重要なのは、単に回答を生成させることではありません。必要な情報を取得し、その結果を踏まえて次に調べることを判断し、回答を組み立てる。この小さな反復を、実際の業務データに接続した形で動かすことです。

その実践の入り口となるのが、Know Narrator AgentSourcingの「コネクターエージェント」や「マルチ業務ナレッジエージェント」です。

外部のデータや機能をAIから利用するための接続方式であるMCPを通じて、複数の接続先をエージェントに設定し、接続先が提供するツールを利用しながら対話できます。

利用者の依頼に対して、AIが必要なツールを選び、取得した結果を踏まえて追加の情報取得や回答生成を進める。この動きには、ループエンジニアリングの基本となる「行動し、結果を観察し、次の行動を決める」という要素があります。

一方、エージェントにどの接続先を持たせ、どの業務の情報や処理を利用させるかは、人が設計します。これは、AIと外部の処理をつなぐという意味で、グラフエンジニアリングにも通じる接続設計です。ただし、複数のコネクターをつなぐことと、専門エージェントや検証者、承認者からなる業務体制を組むことは同じではありません。コネクターエージェントは、まず一つのAIエージェントを業務につなぎ、そこから必要な役割分担を見極めるための出発点と捉えられます。

たとえば、設備情報や保全履歴を参照するツールをMCPで提供できる環境なら、それらを接続し、設備異常の調査を支援する構成が考えられます。設備情報を確認した結果から、関連する保全履歴を追加で調べ、原因候補を整理する。人が情報取得のたびに指示を出すのではなく、AIが結果を踏まえて調査を進める使い方です。

また、コネクターエージェントでは、実行したツールと、その入力・出力を画面で確認できます。回答だけでなく、その回答に至る情報取得の過程を確認することは、接続先や指示を見直し、業務に合った動作へ改善する手掛かりになります。

実務では、次の順序で進めるとよいでしょう。

1. 一つの業務目標と、検証可能な完了条件を決める
2. 必要最小限の接続先とツールで、小さなループを動かす
3. 実行結果を確認し、情報の不足や判断の誤りを評価する
4. 一つのエージェントでは分離しにくい専門性や責任を見つける
5. 必要に応じて、独立した検証、人の承認、並列処理を組み込む

なお、接続できることと、安全に任せられることは別です。接続先の権限、実行回数や費用の管理、完了条件の検証、外部への送信やデータ更新に対する承認は、製品・接続先の機能と業務運用を組み合わせて設計する必要があります。ここもKnow Narratorを利用した設計を行うことで、実現可能となります。

まずは一つのAIエージェントに、業務で使える道具と接続先を持たせる。そして、実行過程を確かめながら、必要な部分だけをチームとしての構成へ広げる。 コネクターエージェントは、ループによる自律的な情報活用と、グラフにつながる接続設計を、小さな業務から実践するための入り口になります。

まとめ

ループエンジニアリングは、AIエージェントが一つの目標に向けて、行動、観察、評価、修正を繰り返し、完了まで仕事を進める仕組みを設計する考え方です。

グラフエンジニアリングは、複数のAIエージェントや処理、ツール、人をノードとして配置し、仕事の分担、引き継ぎ、並列化、検証、承認を設計する考え方です。

ループが「一人のAIエージェントをどう働かせるか」だとすれば、グラフは「AIエージェントを含むチームをどう組織するか」です。

ただし、グラフはループの上位互換ではありません。一つの明確な仕事なら、よく設計された一つのループの方が、安く、速く、理解しやすく、保守もしやすいでしょう。異なる専門性、権限、検証、承認、並列処理が本当に必要になったとき、初めてグラフが価値を持ちます。

これからのAI活用では、人の役割も変わります。人が毎回プロンプトを書いてAIを動かすのではなく、仕事の目標、評価基準、停止条件を定義し、さらに複数のAIエージェントの役割と責任を設計するようになります。

つまり、プロンプトを書く人から、AIの仕事を設計する人へ。さらに、AIエージェントのチームと組織を設計する人へと、求められる能力が広がっていくのです。

電通総研AITCでは、企業固有の業務ナレッジとAIエージェントを組み合わせた業務適用を支援しています。AIエージェントを単体で作るだけでなく、権限、データ、評価、監視、人との役割分担まで含めて設計することが、企業で継続的な成果を生み出す鍵になります。

---

筆者
AITC センター長
深谷 勇次