8月27日、AWSが「Closing the AI agent trust gap with graduated autonomy」と題した記事を公開した。AIエージェントが実業務に深く関与するようになった今、「エージェントにどこまで信頼を与えるか」という問いに対して、AWSは静的な二択ではなく実績に基づく動的な権限設計「段階的自律性（Graduated Autonomy）」を提案している。
「全権限か読み取り専用か」という二択の限界
AIエージェントが顧客データの読み取り、チケットの起票、返金処理、アカウント削除といった実業務に関わるようになった今、権限設計は避けられない問題だ。しかし多くのチームは依然として「フルアクセス」か「読み取り専用」の二択で済ませている。
LLMエージェントが抱える本質的な問題は、同一エージェントでもプロンプト変更やモデル更新によって振る舞いが変わりうる点だ。元記事ではこの変動性を「Monday to Tuesday problem」として提示している——ある時点で正確に動作していたエージェントが、プロンプト変更やモデル更新の後に幻覚や誤動作を起こす可能性を指す。従来のIAMモデルが前提とする「プリンシパルは一貫して振る舞う」という仮定が、LLMエージェントには成立しない。フルアクセスは予測不能な失敗があるため危険で、読み取り専用ではエージェントの価値の大半が使われないまま終わる。AWSはこの乖離を「エージェントのトラストギャップ（trust gap）」と呼ぶ。
このギャップを埋めるために必要なのは、APIログだけでは得られない3つの能力だ：
- 可視性：何が起きたかだけでなく、その行動が安全だったかの判断
- 決定の来歴（decision provenance）：どのシグナルがトリガーになり、何が考慮され、どの程度の確信度で行動したか
- 可逆性：行動前の状態を記録し、誤った操作からリカバリーできること
6層アーキテクチャ「段階的自律性」の構造
AWSが提案する段階的自律性パターンは、以下の6つの層で構成されるクローズドループだ。
| 層 | 役割 |
|---|---|
| スコアリングエンジン | 設定可能な複数次元でトラストスコアを算出 |
| ティアシステム | スコアに基づき自律性レベルを決定 |
| 事前実行層 | 危険なツール呼び出しを実行前にブロック |
| 強制適用層 | Cedarポリシーでインフラレベルから制限を適用 |
| 事後実行層 | 結果を評価し来歴を記録、スコアへフィードバック |
| デリバリーゲート | 評価を通過しないエージェントバージョンを本番から遮断 |
各層は設定として差し替え可能で、スコアリングモデルやティア閾値、事前実行シグナル、評価基準はコードではなくコンフィギュレーションだ。
設計の核心：スコアとティアの仕組み
スコアリングエンジン
過去50アクションのローリングウィンドウで、0〜100のスコアを5次元で算出する：
| 次元 | 重み | 内容 |
|---|---|---|
| 正確性（Accuracy） | 25% | 期待されるアウトカムとの一致 |
| 安全性（Safety） | 20% | 境界の遵守、敵対的コンテンツ検出 |
| 一貫性（Consistency） | 20% | ツール使用パターンのドリフトの逆数 |
| コンプライアンス | 20% | 行動前の推論品質、ガードレール遵守 |
| 効率性（Efficiency） | 15% | 不要なリトライや資源浪費の回避 |
重要なのが安全性は独立したフロアとして機能する点だ。他の指標が高くても、安全性スコアが下限を割ると即座に降格が発動する。他の指標の強さで希釈されない設計になっている。
ティアシステムとその遷移ルール
すべてのエージェントはテスト環境での実績に関わらずT1からスタートする。
| ティア | スコア範囲 | 権限 |
|---|---|---|
| T1：試用（Probation） | 0〜40 | 読み取り・リストのみ。ツール2本 |
| T2：監視下（Supervised） | 41〜70 | 書き込み追加。高リスク操作は人間が承認 |
| T3：信頼（Trusted） | 71〜90 | 実行・変更可。異常はレビュー対象 |
| T4：自律（Autonomous） | 91〜100 | フルアクセス。事後監査のみ |
遷移には3つのルールがある。昇格はローリングウィンドウ全体を通じて閾値を維持した場合のみ許可される。一方、降格は即座だ。安全性フロアを割るか、インジェクションを検出した瞬間にティアが下がる。またヒステリシスを設けており、あるティアへの昇格にはそのティアの下限より5点高いスコアが必要だが、降格はレンジの下限で発動する。境界付近でティアが行き来するフラッピングを防ぐ設計だ。
トラスト状態はAmazon DynamoDBに現在状態レコードと時系列履歴として保持され、エージェント呼び出しのたびに読み取られる。DynamoDBが提供する一桁ミリ秒のレイテンシが前提になっている。
強制適用はエージェントの外側で行う
設計上のポイントとして強調されているのが、強制はエージェントプロセスの外側で行うという原則だ。
事前実行層はエージェントプロセス内のアプリケーションコードだが、強制適用層はインフラレベルで動く。Amazon Bedrock AgentCoreのAgentCore Gatewayがエージェントとツールの間に位置し、すべてのMCP（Model Context Protocol）ツール呼び出しをCedarポリシー言語で評価する。MCPはAIエージェントが外部ツールやデータソースと標準化された方法でやり取りするためのプロトコルで、CedarはAWSが開発したポリシー記述言語だ。
Cedarはforbid-wins（禁止優先）セマンティクスを採用しており、1つのforbidが満たされれば何件のpermitがあっても上書きされる。また、Gatewayはポリシーが許可できるツールだけをリスト表示するため、エージェントは見たことのないツールを呼び出しにくい設計になっている。
緊急停止も即座に対応できる。単一の「deny-all」Cedarポリシーをプッシュすることで、再デプロイなしに数秒以内でGatewayがすべてのツール呼び出しを拒否する。
マルチエージェント構成では、委任チェーン上の最小ティアが有効ティアとなる。委任を通じた権限昇格の経路を塞ぐ設計だ。
デリバリーゲートと本番監視
プロンプト、設定、ツール定義の変更はすべてAWS CodePipelineのrunをトリガーする。ステージング環境でAmazon Bedrock AgentCore Evaluationsによりグラウンドトゥルースのフィクスチャに対してテストされ、プロンプトインジェクションやデータ漏洩リクエストといった敵対的ケースを含む。敵対的テストで1件でも不正なツール呼び出しがあればリリースがブロックされる。
本番監視では、トラフィックの一部に既知の期待動作を持つ「ハニーポット」ケースを合成注入する。自然言語出力ではなくツール呼び出しの軌跡（期待ツール、期待順序、禁止ツールの不使用）を検証するため、非決定的な出力の揺れに左右されない。
まとめ
段階的自律性パターンの要点は「エージェントには実績が支える範囲の自律性だけを与える」という設計思想だ。AWSは2つのテーブル（次元の重みとティア境界）をテンプレートとして公開しており、1つのエージェントを対象にT1からスタートして試せる構成になっている。
既存のIAM設計との関係という観点でも、このパターンは既存のIAMロールやポリシーを廃するものではなく、その上にエージェント特有の動的な信頼評価を重ねる構成だ。CedarポリシーがIAMと独立したレイヤーで動作するため、既存のインフラを大きく変えずに導入できる点は実践上の利点となる。また、LLMの振る舞いの変動性という問題はAWS固有ではなくLLMアーキテクチャ全般に共通する課題であり、同様のアプローチは他のクラウドプロバイダーや独自インフラ上のエージェント設計にも応用できる考え方だ。※編集部の考察
詳細はClosing the AI agent trust gap with graduated autonomyを参照していただきたい。
