8月27日、Techstrong AIが「AI Agents Need an Escalation Architecture, Not Just Better Prompts」と題した記事を公開した。AIエージェントを企業システムで安全・確実に運用するには、プロンプト改善ではなく「エスカレーションアーキテクチャ」を設計の中核に置く必要がある——これが本記事の中心的な主張だ。
AIエージェントが単なるデモツールから実業務の担い手へと移行しつつある今、「エージェントが誤った判断を下したとき、誰が止め、誰が責任を取るのか」という問いが業界全体で急浮上している。OpenAIやAnthropicが自律型エージェントのAPIを整備し、企業導入が加速する一方、EUのAI法（EU AI Act）など規制面でも「自律システムの説明責任」を明示的に求める動きが強まっている。こうした背景のもと、プロンプト品質に依存するだけでは企業リスクを制御できないという認識が、実装現場で広がりつつある。
プロンプトでは解決できない問題
AIエージェントが実運用に入ると、必ず直面する問いがある。「このエージェントは、誰の許可を得て動いているのか？」「重大な判断の責任は誰にあるのか？」これらはプロンプトをいくら磨いても答えが出ない。認可・証跡・回復・説明責任はアーキテクチャの問題であり、UI上に「承認」ボタンを追加する程度では解決しない——というのが本記事の中心的な主張だ。
エージェントが「メールを書く」「ドキュメントを要約する」デモ段階は終わった。今、問われているのは長期稼働するワークフローの中でエージェントが実際の業務を動かせるか、そしてその過程で組織に対してシステム的なリスクをもたらさないかどうかだ。
承認ボタンが機能しない理由
「リスクのある操作に汎用的な『承認』ボタンを追加する」というアプローチは直感的に思えるが、スケールしない。レビュアーが受け取るのが文脈のない通知であれば、承認のために元の調査作業を自分でやり直さなければならなくなる。これでは自動化の意味がない。
有効なエスカレーションは汎用通知ではなく、構造化されたアクションオブジェクトでなければならない。具体的には以下を含む：
- スコープと意図：何を、なぜ実行するか
- インプット：判断の根拠となった具体的なコンテキスト
- 結果と回復パス：期待される結果と、ロールバックの手順
- 選択肢の限定：「この更新を承認する」「このアクセス変更を却下する」など、明確で実行可能な選択肢
レビュアーがエージェントの作業をやり直さずに安全に承認できること——これが設計のゴールだ。
「自律性の3レーン」という考え方
自律性は「完全手動」か「完全自動」かの二択ではない。本記事では、実運用システムに必要な3つの動作レーンを定義している。
| レーン | 対象 | 例 |
|---|---|---|
| Complete（完了） | ルーティン・低リスク・可逆的な作業 | チケット分類、レポート生成、初稿作成 |
| Propose（提案） | 判断を要する高価値作業 | 証拠を収集して提案し、本番環境への変更前に承認を待つ |
| Escalate（エスカレーション） | 財務・セキュリティ・法務・顧客に影響する作業、またはデータが欠損・矛盾している場合 | 元記事に具体例の記載なし |
この構造のポイントは「Completeレーンを時間をかけて拡大できること」にある。抽象的なリスクスコアに頼るのではなく、実測の失敗率と承認ログに基づいて自律性の閾値を引き上げるという、データドリブンなアプローチが可能になる。
ガバナンスは実行レイヤーで機能させる
AIガバナンスがポリシー文書だけに存在し、エージェントがソフトウェアツール上で無制約に動いていれば意味がない。ポリシーは実行時点で強制されなければならない。
推奨されるアプローチは、エージェントの境界を「インフラのコード化」と同様に扱うことだ：
- エージェントごとにスコープされた権限とツールアクセスを制限する
- 特定のアクション実行前に証拠チェックを義務付ける
- チャットコンテキストの外部に永続する改ざん不能な監査ログを保持する
- エスカレーションルールを本番コードと同様にバージョン管理・テスト・観測する
監査ログの設計については、OpenTelemetryのトレーシング仕様や、NIST AI RMF（AIリスク管理フレームワーク）が参考になる。また、AIエージェントのガバナンス設計に関しては、Anthropicが公開しているモデル仕様（Model Spec）も合わせて参照されたい。
測るべきはトークン数ではなく完了した仕事
トークン消費量はビジネス価値の指標として誤解を招く。重要なのは以下のような業務指標だ：
- タスク完了あたりのコスト
- 解決までの時間
- 手戻り率・失敗率
- タスクカテゴリ別のエスカレーション率
- 承認の折り返し時間
重複メッセージを大量送信する安価なAPIコールは高くつく。複雑な問題を完全な監査証跡付きで解決する高コストの多段階ワークフローは実際には安い——という視点の転換が求められる。
実装上のロードマップ（5ステップ）
- 境界が明確なワークフローを選ぶ：明確なアウトカムと単一のオーナーを持つプロセスに絞る。スコープが曖昧なまま自動化を拡大すると、エスカレーション設計自体が破綻する。
- 境界を明示的に定義する：各アクションをComplete／Propose／Escalateに分類する。この分類はドキュメントではなく、実行時に評価されるコードとして表現されるべきだ。
- 実行状態を保持する：リトライや人間へのハンドオフの後も完全なコンテキストを維持する。状態が失われれば、レビュアーは最初からやり直すことになり、エスカレーションの構造的な利点が消える。
- 統合レビュー画面を作る：コンテキスト、提案アクション、限定された選択肢をレビュアーに提供する。通知ではなく「判断に必要な情報が揃った画面」を設計することが、承認プロセスの実効性を左右する。
- 実データで反復する：仮定ではなく、実測の失敗率と承認ログで自律性閾値を調整する。Completeレーンの拡大は、組織が積み上げた実績データに基づいて段階的に行う。
「プロンプトはエージェントを饒舌にする。エスカレーションアーキテクチャはエージェントを安全で信頼性が高く、運用上有用にする」——本記事の締めはこの一文だ。AIエージェントの実装に携わるエンジニアにとって、設計の優先順位を整理するうえで参考になる視点だ。
詳細はAI Agents Need an Escalation Architecture, Not Just Better Promptsを参照していただきたい。
