プロンプトエンジニアリング vs ループエンジニアリング vs グラフエンジニアリング：各層で何が変わるか
AIエンジニアリングの職務記述書で、3つの用語が同じ行を争っています。プロンプトエンジニアリング、ループエンジニアリング、グラフエンジニアリングは、それぞれ単一応答、エージェント動作サイクル、マルチエージェント組織を制御する積み重ねられた層です。本記事では各層の内容、使用すべき場面、適切なレベルの選び方を説明します。
現在、AIエンジニアリングの職務記述書では、3つの用語が同じ行を争っています。プロンプトエンジニアリング（Prompt Engineering）は確立されたものです。ループエンジニアリング（Loop Engineering）は2025年末にAI語彙に登場し、2026年6月まで開発者議論を支配しました。グラフエンジニアリング（Graph Engineering）は約6週間後に続きました。
これらは互換的に使われています。しかし、そうすべきでしょうか？
これら3つは競合技術ではありません。それらは3つの異なる制御単位であり、積み重なっています。プロンプトは1つのモデル応答を制御します。ループは1つのエージェントの行動サイクルを制御します。グラフは多数のエージェントの組織を制御します。各層はその下の層を保持します。プロンプトは、その周りにループが構築されても消えません——手で入力されるものではなくなるだけです。
本記事では、これら3つの層を区別します：各層で何が設計されるか、高層がいつコストを回収するかに関する発表された主張、そして懐疑が正当化される箇所です。
1つのタスク、3つの層
これらの3つの用語は競合技術ではありません。それらは3つの異なる制御単位です。以下は、各層で同じジョブが段階的に処理される様子です。オレンジ色の点は人間の介入が必要な瞬間を示します。
タスク： authモジュールの失敗したテストを修正し、プルリクエストを開く。
- 層1：プロンプトエンジニアリング——1つのモデル応答を制御します。あなたがループです。あなたのターン：0、モデル呼び出し：0
- 層2：ループエンジニアリング——1つのエージェントのサイクルを制御します。ループがプロンプトを行います。あなたのターン：0、モデル呼び出し：0
- 層3：グラフエンジニアリング——多数のエージェントの編成を制御します。あなたのターン：0、ノード：0、並列：0
実際の違い
| 側面 | プロンプトエンジニアリング | ループエンジニアリング | グラフエンジニアリング | |------|------------------------|----------------------|----------------------| | 制御単位 | 単一のモデル応答 | 1つのエージェントの行動サイクル | エージェントの組織 | | 記述するもの | 指示、例、出力形式 | トリガー、ツール、停止条件、リトライ予算 | ノード、エッジ、共有状態、障害ルート | | 誰が「もう一度」と言うか | 人間（毎ターン） | 検証器（ループが自身を呼ぶ） | 事前に書かれたルーティングルール | | 破綻する場所 | 曖昧または過剰な指示 | 完了とスタックを区別できない | 描き忘れたエッジをコンテキストが越えない | | 十分な条件 | 1回限り、人間が結果を読む | 反復的、機械的にチェック可能、単一ドメイン | 並列ブランチを伴うクロスドメイン作業 |
スタックの順序
各ステップは、ベンダー文書に登場する前に実際に命名されました。
プロンプトエンジニアリングは、単一呼び出しのための指示の作成と構造化をカバーします。Anthropicのガイダンスは、システムプロンプトをラベル付きセクション（背景情報、指示、ツールガイダンス、出力記述）に分け、XMLタグまたはMarkdownヘッダーで区切ることです。最小限の情報セットを提供することが推奨されますが、最小限は短いことを意味しません。
コンテキストエンジニアリングが次に登場しました。Anthropicはこれをプロンプトエンジニアリングの自然な進化として説明しています。問題は適切な単語を見つけることから、ウィンドウ内にどのトークン構成が属するかを決定することに移ります。コンテキストは有限リソースであり、エンジニアリング問題はモデル制約に対してそれらのトークンの効用を最適化することです。
ハーネスエンジニアリングは、単一のエージェントが実行する環境（ファイル、ツール、メモリ、フィードバック）をカバーします。
ループエンジニアリングはハーネスの1つ上の層に位置します。2026年6月の建築工学におけるエージェントAIに関するarXiv論文（Buildrix）は、同じ4段階の進行を明示的に提示しています：プロンプト、コンテキスト、ハーネス、ループ。最終層は、システムがどのように繰り返し観察、行動、検証、回復するかを定義します。
グラフエンジニアリングは最新のラベルであり、最も未確定です。あるエンタープライズレポートは、この用語の起源が未解決であり、古い知識グラフの用法と衝突することを指摘しています。根底にある実践、つまりグラフベースのオーケストレーションは、マルチエージェントシステム研究において文書化された系譜を持っています。
層1：プロンプトエンジニアリング
決定的な仮定は、人間があらゆる反復に存在することです。プロンプトが書かれ、モデルが応答し、出力が判断され、プロンプトが修正されます。
その仮定が破綻するのは、高ボリューム、マルチステップタスク、出力を評価する人間がいない、結果が自動的に次のステップに供給される、といった場合です。これらのいずれかが発生すると、プロンプトだけでは不十分になります。
プロンプト自体は悪化していません。周囲の状況が変わったのです。
プロンプトエンジニアリングは高層内でも消えません。Anthropicのマルチエージェント研究レポートによると、プロンプトエンジニアリングは協調障害を修正するための主要な手段でした。初期バージョンでは単純なクエリに対して50のサブエージェントが生成されましたが、修正はトポロジーではなくプロンプトでした。
層2：ループエンジニアリング
枠組みは、コーディングエージェントが解決策を見つけるための力任せのツールであるということです。技術は、ゴール、ツール、ループを設計することであり、プロンプトだけではありません。
この用語は、2026年6月に広く共有された投稿（エンジニアはコーディングエージェントにプロンプトを与えるのをやめ、それらをプロンプトするループを設計すべき）の後、主流の開発者議論に浸透しました。AnthropicのClaude Codeチームは同じ週に同じシフトをステージで説明しました。
最も詳細な公開分解は5つのプリミティブを特定し、さらにそれらを結びつける第6の要素を示しています：
- オートメーション：監視なしで発見とトリアージを実行するスケジュールまたはイベント
- ワークツリー：並列エージェントが同じファイルを編集できないようにする分離
- スキル：セッションごとに再説明するのではなく、SKILL.mdに一度書き留められるプロジェクト知識
- プラグインとコネクタ：問題トラッカー、データベース、ステージングAPIへのMCPベースのアクセス
- サブエージェント：メーカー/チェッカーの分離（コードを書いたモデルは採点が甘すぎるため）
- 状態：会話の外部にあるMarkdownファイルまたはボード（モデルは実行間で忘れるため）
2つのセッション内機能が非常に重要です：/loopは一定の周期で再実行します。/goalは記述された条件が実際に真になるまで実行し、毎ターン後に別の小さなモデルがチェックします——つまり、コードを書いたエージェントが採点するわけではありません。Claude CodeとCodexアプリの両方が同等の機能を提供しています。
ループ自体は難しい部分ではありません。停止条件が難しいのです。機械的に完了とスタックを区別できないループは、大きく失敗するのではなく、トークンを消費し続けます。
層3：グラフエンジニアリング
2026年7月、議論はループからグラフへ移りました。ループはエージェントの行動をプログラム可能にしました。グラフはエージェントの組織をプログラム可能にします。
最も見落とされがちな構造的ポイントは、本番マルチエージェントシステムが2つのグラフを同時に実行することです。
組織グラフは安定しています。長期存続するエージェントは名前付きロールを持ち、ゾーンを所有し、時間とともにコンテキストを蓄積します。再デプロイ時に変更されます。
作業グラフは一時的です。タスクノードは作業が存在する間だけ存在します。エッジは並列パスのために分割され、収束時にマージされ、証拠がブランチを不要にすると消えます。
組織グラフは「誰が」に答えます。作業グラフは「今、何を」に答えます。
このラベルに対する懐疑はもっともです。明確な目的を持つサブエージェントはすでにグラフを形成しており、技術は語彙より先に存在していました。LangGraphは用語が存在するずっと前にグラフAPIをリリースしました。Anthropicの2024年12月の5つのワークフローパターン（プロンプトチェーン、ルーティング、並列化、オーケストレーターワーカー、評価者最適化）は、散文で記述されたグラフトポロジーです。新しいのは、これらのフレームワークが常に強制してきた決定（ノードとは何か、エッジとは何か、状態には何があるか）に対する共有名です。
具体的な成果物を知っておく価値があります。LangGraphでは、StateGraphが状態スキーマ上で宣言されます。ノードはadd_nodeで登録されます。エッジはadd_edgeとadd_conditional_edgesで配線されます。STARTとENDがマークされ、その後グラフがコンパイルされます。ノードは状態を受け取り部分更新を返すプレーンな関数です。コンテキストは、エッジが運ばない限りノード境界を越えません。最後の部分が全体の失敗モードを説明しています。
層の選び方
質問を順に検討してください。最初の「いいえ」が通常は答えです。
- すべての出力が実行前に人間によって読まれますか？はいの場合、プロンプト層で十分です。ループは監視なし実行を購入するものであり、自律性ではありません。
- 「完了」を人間以外でチェックできますか？テスト、スキーマ、ルーブリック、別のモデル。できない場合、停止条件はなく、予算だけです。
- タスクは1つのエージェントのコンテキストと1つのドメインに収まりますか？はいの場合、ループを構築してください。単一の推論トレースは、仮定を一貫させる最も安価な方法です。
- 独立したブランチを同時に実行する必要がありますか？はいの場合、これはグラフ問題です：ノード、エッジ、共有状態、障害ルートを宣言します。いいえの場合、エージェントを追加する前にループのツールを拡張してください。
2026年7月のコーディングエージェントループに関するarXiv論文は、関係を正しく述べています。ループはグラフのサブケースです。すべての作業が同じコンテキストを共有し並列性が必要ない場合、グラフはループに縮退します。ループがなく人間が手動で反復する場合、ループはプロンプトに縮退します。層は入れ子になっており、相互排他的ではありません。