AI制御の進化：プロンプトからグラフへの多層構造
MarkTechPostが2026年7月29日に公開した記事「Prompt Engineering vs Loop Engineering vs Graph Engineering: What Changes at Each Layer」では、AIエンジニアリングにおける「Prompt Engineering」「Loop Engineering」「Graph Engineering」という3つの用語が、異なる制御レベルを持つ階層構造であると明確に示されています。これらは競合する技術ではなく、積み重なる「制御単位」であり、下位の層は上位の層に組み込まれる形で存在し続けると説明されています。これは、AIシステムの複雑化に伴い、制御の抽象度が高まっている現状を非常によく表していると感じます。
Prompt Engineeringは単一のモデル応答を制御し、Loop Engineeringは単一エージェントの振る舞いサイクルを制御し、Graph Engineeringは複数のエージェントの編成を制御する。
それぞれの層は、以下のように進化してきました。
- Prompt Engineering: 単一の呼び出しに対する指示の作成と構造化をカバーします。Anthropicのガイドラインでは、システムプロンプトを背景情報、指示、ツールガイダンス、出力記述などのセクションにXMLタグやMarkdownヘッダーで区切ることを推奨しています。
- Context Engineering: プロンプトエンジニアリングの自然な進化として、適切な単語を見つけるだけでなく、コンテキストウィンドウに含めるトークンの構成を最適化する問題へと焦点が移ります。コンテキストは有限なリソースであり、その利用効率を最大化することが課題となります。
- Harness Engineering: 単一のエージェントが動作する環境（ファイル、ツール、メモリ、フィードバック）を構築する技術です。
- Loop Engineering: ハーネスの上に位置し、システムが繰り返し「観測、行動、検証、回復」を行う方法を定義します。2026年6月のarXiv論文「Buildrix」は、この4段階の進展を明示しています。
- Graph Engineering: 最も新しい概念で、複数のエージェントの協調動作やタスクのワークフローをグラフ構造でオーケストレーションします。用語の起源は未確定ですが、マルチエージェントシステム研究におけるグラフベースのオーケストレーションという実践に起源を持つとされています。
各層の役割と制御対象の比較
| 層の名称 | 制御対象 | 設計されるもの | 目的 |
|---|---|---|---|
| Prompt Engineering | 単一のモデル応答 | 指示、コンテキスト、出力形式 | 期待される単一応答の生成 |
| Loop Engineering | 単一エージェントの行動サイクル | 観測、行動、検証、回復のプロセス | エージェントの自律的なタスク遂行とエラー回復 |
| Graph Engineering | 複数エージェントの連携とタスク編成 | エージェント間の依存関係、タスクフロー、通信プロトコル | 複雑な目標達成、大規模なAIシステムの協調動作 |
なぜ上位層が必要とされているのか
Prompt Engineeringは、人間が各イテレーションに介入し、モデルの応答を評価し、プロンプトを修正するという前提で機能します。しかし、AIの活用が進むにつれて、この前提が崩れてきています。
- 高頻度での利用: 大量のプロンプト生成と応答処理。
- 多段階タスク: 複数のステップが必要な複雑なタスク。
- 人間による評価の不在: 出力を人間が評価できない、あるいは不要なケース。
- 自動化された次ステップへの入力: モデルの出力が自動的に次のステップの入力となる場合。
このような状況では、プロンプト単独ではもはや十分ではなくなります。プロンプト自体の質が低下したわけではなく、周辺環境と要件が変化したため、より上位の制御層が必要とされているわけです。
例えば、私が Claude Code でゴリゴリとコードを書く際も、単一のプロンプトで完結することは少なく、対話の中でコンテキストを調整したり、試行錯誤のループを回したりしています。これはまさに Prompt Engineering から Context Engineering、そしてLoop Engineeringへの移行を体感していると言えるでしょう。
エンジニアが取り組むべき次なる課題
Graph Engineeringは、複数のAIエージェントが協調して動作するシステムを構築する上で不可欠な技術となるでしょう。これは、企業における複雑なビジネスプロセスをAIで自動化する際に、各エージェントが担当する役割と、それらがどのように連携して目標を達成するかを設計することに他なりません。GCPのCloud RunやBigQueryを組み合わせたデータパイプラインを構築する際に、各サービス間の連携やデータの流れを設計する感覚に似ていると感じます。
Graph Engineeringは、単一エージェントの能力だけでは解決できない、より複雑な問題に取り組むための鍵となるでしょう。
これは、AIが単なるツールから、自律的に連携するシステムへと進化している証拠ではないでしょうか。個人プロダクトでローカルLLMを動かす際にも、複数のモデルやツールを組み合わせてより高度なタスクをこなさせたいというニーズは確実に存在します。例えば、Stable Diffusionで画像を生成し、その画像を元にLLMでストーリーを作成するようなワークフローを自動化する際に、Graph Engineeringの考え方が役立つはずです。
まとめ：進化するAI制御スタック
AIエンジニアリングは、単一のプロンプト最適化から、エージェントの行動サイクル、そして複数エージェントの協調システム全体のオーケストレーションへと、その制御対象の範囲と複雑性を拡大し続けています。Prompt Engineeringは基礎であり続けながらも、Loop EngineeringやGraph Engineeringといった上位の抽象化レイヤーが、より高度で自律的なAIシステムの実現に不可欠となるでしょう。この進化は、開発者にとって新たな設計スキルとアプローチを要求しますが、その分、AIが解決できる問題の範囲も大きく広がることを意味します。
