8月15日、Damon Garnが「Prompts vs. loops: Why prompt engineering won't build your AI workforce」と題した記事を公開した。「よい回答を生成するAI」から「仕事を完遂するAI」へ——この転換を象徴するのが、GPSナビの比喩だ。GPSは一度だけ道を教えるのではなく、進行状況を監視しながら目的地まで継続的にルートを修正し続ける。Garnはこの性質こそが、プロンプトと実行ループ（Execution Loop）の本質的な差だと論じる。LangGraph・AutoGen・OpenAI Agents SDKなど、エージェントAIのフレームワークが急速に普及する今、「プロンプトを磨く」先にある設計思想を整理した記事として注目に値する。
プロンプトは「回答を生成する」、ループは「仕事を完遂する」
エンタープライズAIの第一波は、コパイロット・チャットボット・プロンプトエンジニアリングが中心だった。しかし企業が本当に求めているのは「よく書かれた回答」ではなく、「完了した仕事」だ。この評価軸の転換が、AIシステムの基本単位をプロンプトから実行ループ（Execution Loop）——AIが計画・実行・検証・修正を自律的に繰り返す処理サイクル——へと押し上げている。
プロンプトの動作は単純だ。回答を生成し、成功を前提とし、1回のやり取りで終了する。一方、実行ループは以下のサイクルを回す。
- 作業を計画する
- アクションを実行する
- 結果を観測する
- 成果を検証する
- 失敗をリトライする
- 例外をエスカレーション（人間や別システムへの問題引き継ぎ）する
- 目標が完了するまで停止しない
GarnはこれをGPSナビに例えている。GPSは一度だけ方向を教えるのではなく、進行状況を継続的に確認しながら目的地に到着するまでルートを修正し続ける。実行ループも同様に、完了まで処理を継続する点が根本的に異なる。
具体例として挙げられているのがITデプロイのシナリオだ。プロンプトベースのアシスタントは「デプロイ手順を書いた文書」を生成する。対してエージェントループは、権限の確認・インフラの作成・デプロイの検証・失敗ステップのリトライ・チケットの起票・監査レコードの生成まで一気通貫で処理する。差を生むのはモデルの賢さではなく、このループ構造の有無だ。
「アシスタント」と「オペレーショナルエージェント」の違い
記事はAIの役割を「アシスタント」と「オペレーショナルエージェント」に明確に分けて整理している。アシスタントが「新しい開発環境のプロビジョニング方法を説明する」のに対し、オペレーショナルエージェントは「承認申請・リソース作成・デプロイ検証・問題のエスカレーションを実際に実行する」。この差を生むのはモデルの性能ではなく、実行ループの有無だ。
この観点は、LangGraphが提唱するステートフルなエージェントグラフや、AutoGenのマルチエージェント会話フレームワークが解こうとしている課題と本質的に重なる。各フレームワークが「ループをどう設計するか」に腐心しているのは、まさにこの理由からだ。
実行ループはスケールに応じて3段階に分けられる。タスクループはパスワードリセットや経費承認など単一タスクの完結を担い、ワークフローループは複数アプリケーション・チームにまたがる複数タスクを調整し、システムループは複数エージェントを監督しながらポリシー適用・共有リソース管理・運用健全性の維持を担う。組織のAI成熟度に応じて、どの段階から着手するかを判断することが実装の出発点になる。
開発者の役割も変わる
実行ループの普及は開発者を不要にするのではなく、エンジニアリングの焦点を移す。「最高のプロンプトを書く」から「システムがどのように仕事をこなし、完了を判断するか」を設計することへ。具体的には、ビジネス目標の定義・エンタープライズシステムとの接続・検証ロジックの構築・オブザーバビリティ（システムの内部状態を外部から観測・追跡できる性質）の実装が中心的な仕事になる。プロンプトチューニングのスキルが不要になるわけではないが、それだけでは設計者として十分でなくなる、というのがGarnの主張だ。
ガバナンスとオブザーバビリティが不可欠になる
実行ループはエンタープライズシステムにアクセスし、繰り返し意思決定を行い、リソースを消費する。自律的に動くほど、「何をしているのかわからない」リスクは高まる。だからこそ、オブザーバビリティとガバナンスの枠組みが必須になる。記事では、以下の問いに常時答えられる状態を目標として示している。
- エージェントはどのアクションを実行したか？
- なぜその判断をしたか？
- 何か失敗したとき何が起きたか？
- 監査のためにプロセス全体を再現できるか？
ガバナンスの要素としては、高リスクアクションへの人間承認・IDと権限管理・監査証跡・コスト管理が挙げられている。人間の監視役割は「全アクションのレビュー」から「例外と高影響の意思決定への介入」へと移行する。これは責任の軽減ではなく、介入ポイントの再設計だ。
セキュリティの文脈では、プロンプトベースのアシスタントが「不審なログイン活動を要約する」のに対し、ループベースのエージェントはアラートの相関分析・追加情報収集・調査チケットの起票・閾値到達後のアナリストへのエスカレーションまでを自動で処理する例が紹介されている。この差は、インシデント対応のスピードと一貫性に直結する。
ITリーダーへの実践的な次のステップ
記事はITリーダーに向けて、まず成功を明確に測定できる、繰り返し可能で定義済みのオペレーションワークフローから着手することを推奨している。ベンダー評価の際は、モデルのベンチマークスコアではなく、以下を問うべきだとしている。
- システムはどのように成功を検証するか？
- システムはどのように失敗から回復するか？
- 人間はどこで関与するか？
- 監査とオブザーバビリティの機能はどう実装されているか？
実行ループが増やすのはケイパビリティだけでなく責任でもある。統合コスト・ガバナンス要件・運用複雑性というトレードオフを正しく理解した上で導入を進めることが求められる。プロンプトエンジニアリングの時代が終わるのではなく、それが「ループ設計の一部」に収まる時代が来つつある——Garnの論点はそう読むのが正確だろう。
詳細はPrompts vs. loops: Why prompt engineering won't build your AI workforceを参照していただきたい。
