AIエンジニアリングの職務記述書では、現在3つの用語が同じ行を競っている。確立された「プロンプトエンジニアリング」、2025年末にAI用語として登場し2026年6月まで開発者討論を席巻した「ループエンジニアリング」、そしてその約6週間後に続いた「グラフエンジニアリング」である。これらは互換的に使われるが、それは適切だろうか？
実際には、これら3つは競合する技術ではない。それらは異なる3つの制御ユニットであり、積み重なっている。プロンプトは1つのモデル応答を制御する。ループは1つのエージェントの行動サイクルを制御する。グラフは多数のエージェントの組織を制御する。各レイヤーはその下のレイヤーを保持する。プロンプトは、その周りにループが構築されても消えることはない。ただし、手動で入力されるものではなくなる。
本稿ではこれら3つを分離する。各レイヤーで何が設計されるか、公開された主張が上位レイヤーがいつコストを回収するかを述べていること、そして懐疑論が正当化される箇所についてである。
スタックの順序
各段階の進化は、ベンダーの文書に現れる前に実際に名前が付けられていた。
第1層：プロンプトエンジニアリング
定義的な前提は、あらゆる反復に人間が関与することである。プロンプトが書かれ、モデルが応答し、出力が評価され、プロンプトが修正される。この前提が崩れるのは、高ボリューム、多段階タスク、出力を評価する人間が不在、結果が自動的に次のステップにフィードされる場合である。これらのいずれかがあれば、プロンプトだけでは不十分になる。プロンプト自体が悪くなったわけではない。周囲の条件が変わったのだ。
プロンプトエンジニアリングは上位レイヤー内でも消滅しない。Anthropicのマルチエージェント研究の報告によれば、プロンプトエンジニアリングは協調障害の修正における主要なレバーであった。初期バージョンでは単純なクエリに対して50ものサブエージェントが生成されたが、その修正はトポロジーではなくプロンプトであった。
第2層：ループエンジニアリング
このフレーミングは、コーディングエージェントが解を見つけるための総当たりツールであるというものだ。技術は目標、ツール、ループを設計することであり、プロンプトだけではない。この用語は2026年6月に主流の開発者討論に到達した。広く共有された投稿が、エンジニアはコーディングエージェントにプロンプトを与えるのをやめ、それらにプロンプトを与えるループを設計すべきだと論じた後である。AnthropicのClaude Codeチームもその週にステージで同じシフトを説明した。
最も詳細な公開分解は5つのプリミティブを特定し、さらにそれらをまとめる第6の要素を含む。自動化、ワークツリー、スキル、プラグインとコネクタ、サブエージェント、そして状態（会話の外部にあるマークダウンファイルまたはボード。モデルは実行間で忘れるため）である。2つのセッション内機能が非常に重要である：/loopは周期で再実行し、/goalは書かれた条件が実際に真になるまで実行し、各ターン後に別の小さなモデルがチェックする——つまりコードを書いたエージェントがそれを評価するのではない。Claude CodeとCodexアプリの両方が同等の機能を搭載している。
サイクルは難しい部分ではない。停止条件が難しいのだ。機械的に「完了」と「行き詰まり」を区別できないループは、大きな失敗をしない。トークンを消費し続けるだけである。
第3層：グラフエンジニアリング
2026年7月、議論はループからグラフへと移った。ループはエージェントの振る舞いをプログラム可能にした。グラフはエージェントの組織をプログラム可能にする。見逃されがちな構造的ポイントは、本番マルチエージェントシステムが2つのグラフを同時に実行することである。
組織グラフ（Org Graph）は安定している。長寿命のエージェントは名前付きの役割を保持し、ゾーンを所有し、時間とともにコンテキストを蓄積する。再デプロイ時に変更される。
ワークグラフ（Work Graph）は一時的である。タスクノードは作業が存続する間のみ存在する。エッジは並列パスのために分割され、収束時にマージされ、証拠がブランチを不要にしたときに消える。
組織グラフは「誰が」に答える。ワークグラフは「今、何を」に答える。
このラベルに対する懐疑論は正当である。定義された目的を持つサブエージェントはすでにグラフを形成しており、技術は用語に先行していた。LangGraphはこの用語が存在するずっと前にグラフAPIを出荷していた。Anthropicの2024年12月の5つのワークフローパターン——プロンプトチェーン、ルーティング、並列化、オーケストレーター・ワーカー、評価者・最適化——は散文で記述されたグラフトポロジーである。新しいのは、これらのフレームワークが常に強制した決定（ノードとは何か、エッジとは何か、状態とは何か）に共有の名前が与えられたことである。
具体的な成果物を知る価値はある。LangGraphでは、StateGraphが状態スキーマ上で宣言される。ノードはadd_nodeで登録される。エッジはadd_edgeとadd_conditional_edgesで配線される。STARTとENDがマークされ、グラフがコンパイルされる。ノードは状態を受け取り部分更新を返すプレーンな関数である。コンテキストは、エッジが運ばない限りノード境界を越えない。この最後の部分が全障害モードを説明している。
レイヤーの選び方
順番に質問に取り組む。最初の「いいえ」が通常は答えである。
- 何かが行動に移す前に、人が毎回出力を読むか？はいの場合、プロンプトレイヤーで十分。ループは監視なし実行を購入するが、自律性は購入しない。
- 「完了」を人間以外の何か（テスト、スキーマ、ルーブリック、第2のモデル）でチェックできるか？いいえの場合、停止条件はなく、予算のみ。
- タスクは1つのエージェントのコンテキストと1つのドメインに収まるか？はいの場合、ループを構築する。単一の推論トレースは仮定を一貫させ続ける最も安価な方法。
- 独立したブランチを同時に実行する必要があるか？はいの場合、これはグラフの問題：ノード、エッジ、共有状態、障害経路を宣言する。いいえの場合、エージェントを追加する前にループのツールを拡張する。
最終的な注意はアーキテクチャではなく運営者に関するものである。2人のエンジニアが同一のループを構築して正反対の結果を得ることができる。一方は深く理解している作業でより速く動く。他方は作業をまったく理解しないことを避ける。システムはその違いを区別できない。これが、上位レイヤーをプロンプトよりも設計を難しくする理由であり、簡単にする理由ではない。