AIエージェントの承認プロンプトは認可ではない

OpenAIのAgents SDKでは、人間による承認が実行時の状態として扱われるようになりました。機密性の高いツール呼び出しの前に実行を一時停止し、中断を表示し、その判断をRunStateに保存できます。承認または拒否のあと、同じ実行から再開することもできます。¹

この製品設計は、重要な点を正しく捉えています。承認はチャット履歴の中だけでなく、実行環境の中に置かれるべきです。

次に難しい問いが出てきます。人間は、実際に何を認可したのでしょうか。

「シェルコマンドを許可しますか？」や「ツール呼び出しを承認しますか？」という承認プロンプトは、その瞬間を信頼するようユーザーに求めます。一方、本当の認可記録は、行動の範囲を定め、リスクを明示し、証拠を残し、有効期限を持ち、あとから確認できる履歴を作ります。AIエージェントに必要なのは後者です。エージェントは複数の手順をまたいで計画し、入れ子になったツールを呼び出し、拒否されたあとに再試行し、流暢な説明を添えて判断を迫るためです。そこで人間は「はい」を押す圧力を感じることがあります。

要約

AIエージェントの承認プロンプトは、認可ではありません。プロンプトは作業を一時停止できますが、認可には、誰が権限を与えるのか、どのエージェントが受け取るのか、どのツールを実行できるのか、どのリソースに触れられるのか、どのリスク区分に該当するのか、その付与がどのくらい続くのか、判断を支えた証拠は何か、運用者がどう取り消せるのかを定義する必要があります。チームは承認をチャットの割り込みではなく、範囲を絞った権限オブジェクトとして設計すべきです。問うべきなのは「誰かが承認をクリックしたか」ではありません。「責任ある人が、どの制約のもとで、どの具体的な行動を認可したのか」です。

重要ポイント

プロダクトチームへ: - 承認は型付きの判断オブジェクトとして表示しましょう。行動、リソース、リスク、証拠、有効期限、ロールバックを含めます。 - 低リスクの確認と、高リスクの認可は分けて扱います。

セキュリティチームへ: - 繰り返し表示される承認プロンプトは、単なるUX問題ではなく攻撃対象として扱いましょう。 - 許可、拒否、自動許可、自動拒否、期限切れ、取り消しをすべて記録します。

エージェント開発者へ: - 取り消せない行動の前に一時停止しましょう。エージェントがすでに結果を形作ったあとでは遅すぎます。 - 拒否は曖昧な失敗としてではなく、制約付きの指示としてモデルへ戻します。

運用者へ: - 対象リソース、権限範囲、ロールバック手段が見えないツール呼び出しは承認しないでください。 - 粘着的な「常に承認」ではなく、短時間だけ有効な範囲付き付与を選びましょう。

なぜ承認プロンプトは失敗するのか

承認プロンプトが失敗するのは、文脈の多い判断を、文脈の少ないクリックに圧縮してしまうときです。

エージェントは、プロンプトに表示される以上の文脈を持っています。ファイルを読み、スレッドを要約し、一連の手順を計画し、ツールを選び、引数を埋め、実行タイミングを選んでいるかもしれません。しかし承認プロンプトに表示されるのは、多くの場合、最後の一手だけです。ユーザーが見るのは、コマンド、API呼び出し、ブラウザー操作、または同じエージェントが書いた許可依頼の文章です。

このインターフェースは、4つの失敗を生みます。

OWASPのAgentic Top 10は、この説得の失敗を直接取り上げています。リリース記事では、ASI09のHuman-Agent Trust Exploitationにおいて、自信に満ちた説明が人間の運用者を誤導し、有害な行動を承認させる可能性があると述べています。² このリスクに、悪意あるモデルは必要ありません。役に立とうとするエージェントであっても、弱い計画を過度に売り込み、不確実性を小さく見せ、無害な操作列の中に危険なツール呼び出しを埋め込むことがあります。

だからこそ、承認にはよりよい形が必要です。人が承認すべきなのは、依頼の吹き出しではなく、行動記録です。

承認は何を認可すべきか

本格的な承認は、境界のある条件のもとで、1つの具体的な行動を認可すべきです。

「Authenticated Delegation and Authorized AI Agents」の論文は、この広い問題を委任された権限として捉えています。ユーザーには、エージェント専用の認証情報、メタデータ、監査可能なアクセス制御設定を使って、エージェントの権限を制限し、明確な説明責任の連鎖を維持する方法が必要だという整理です。³

この考え方は、プロダクト設計にもきれいに対応します。承認には次の項目が必要です。

これらの項目がなければ、承認はボタン付きの雰囲気にすぎません。モデルは丁寧に頼めます。人間は素早くクリックできます。しかし、そのどちらも、その行動が正当なものだった証明にはなりません。

承認状態はどう動くべきか

承認状態は一時停止をまたいで残るべきですが、範囲は狭く保つ必要があります。

OpenAIのAgents SDKドキュメントには、有用な実行時パターンが説明されています。ツールはneeds_approvalを宣言でき、ランナーは実行前に承認ルールを評価します。未解決の承認は中断として表示され、開発者は保留中の各項目を承認または拒否でき、その実行はRunStateから再開できます。¹ ドキュメントでは、同じ実行内の後続呼び出しに対するalways_approveやalways_rejectのような継続的な判断も説明されています。¹

状態機械が重要なのは、一時停止したエージェント実行が、記憶からやり直したり、意図を再生成したり、承認文脈を失ったりすべきではないからです。中断地点から、判断を付けた状態で再開されるべきです。

継続的な判断という選択肢は、次の設計要件を生みます。継続的な承認には、必ず範囲と有効期限が必要です。

継続的な承認は疲労を減らせます。しかし広すぎる継続的な承認は、疲れた1クリックを、実行全体の影響範囲へ広げてしまいます。

承認は実行環境のどこに置くべきか

承認は、コミット地点の前に置くべきです。

コミット地点とは、エージェントが可逆的な作業から副作用へ移る瞬間です。本番リソースの変更、メッセージ送信、支出、コンテンツ公開、データ削除、キーのローテーション、権限変更、コードのデプロイなどが該当します。コミット地点のあとに人間が承認しても、それは認可ではなくインシデント対応です。

人間による監督に関する文献も、この区別を支えています。2026年のAI and Ethics論文は、AIが生成または行動する「作動的エージェンシー」と、人間が評価し、異議を唱え、上書きできる「評価的エージェンシー」を分けています。⁴ 有効な監督は、人がすべてのトークンを見続けることに依存できません。インターフェースは、人間の判断がまだ結果を変えられる地点に、その判断を残しておく必要があります。

つまり、エージェント製品には単純なルールがあります。

エージェントが危険な部分をすでに実行したあとに表示されるプロンプトは、見せかけを作るだけです。システムがすでに権限を使ってしまっているなら、人間は評価的エージェンシーを行使できません。

承認疲れをどう防ぐか

承認疲れはセキュリティ上のバグです。疲労は判断を変えるからです。

1回の実行で40回の承認を求めるなら、ユーザーがクリックする前にプロダクトはすでに失敗している可能性が高いです。運用者は各項目の判断をやめ、煩わしさの管理を始めます。攻撃者はこのパターンを悪用できます。繰り返し要求を生成し、危険な行動をバッチの中に隠し、危険な呼び出しを日常的なものに感じさせる言葉を使えます。

OWASPのAgentic Top 10は、人間とエージェントの信頼悪用を第一級のリスクカテゴリとして扱っています。² エージェントセキュリティ研究も、システム側から同じ形に到達しています。2026年3月のエージェント型AIセキュリティの体系化研究は、プロンプトインジェクション、RAG汚染、ツールとプラグインの悪用、マルチエージェント脅威にまたがる信頼境界を整理し、実行時監視とインシデント対応の統制も求めています。⁵ 2026年5月のセキュリティ監査可能なエージェントに関する論文は、静的な部品表と実行時ログだけでは証拠が断片化すると論じています。システムが能力、記憶、目標、推論の軌跡、行動を結び、検索可能な監査経路にできなければならないという主張です。⁶

承認設計は、価値の低いプロンプトを減らし、価値の高いプロンプトの質を上げることで疲労を下げるべきです。

目標は統制を減らすことではありません。意味のない統制を減らすことです。

承認UIには何を表示すべきか

承認UIが表示すべきなのは、エージェントの人格ではなく判断です。

まずはコンパクトな判断カードから始めます。

このカードは、ユーザーが1つの問いに答える助けになります。要求された行動は、証拠と範囲に見合っているでしょうか。

カードは正確な引数を隠すべきではありません。拒否を見えにくくしてはいけません。「承認」だけが設計された道で、「拒否」は例外のように扱われるべきではありません。よい承認画面では、拒否は通常の制御信号です。エージェントは、正確なメッセージを受け取るべきです。「ソースURLが検証されていないため拒否」や「このコマンドはリリース範囲外のファイルに触れるため拒否」のようにです。

チームは最初に何を作るべきか

より美しいプロンプトを作る前に、承認台帳を作りましょう。

最低限の台帳項目は次のとおりです。

1. 実行ID。
2. エージェントID。
3. 運用者ID。
4. ツール名。
5. ツール引数。
6. 対象リソース。
7. リスク区分。
8. 発火した承認ルール。
9. 証拠へのポインター。
10. 判断: 承認、拒否、自動承認、自動拒否、期限切れ、取り消し。
11. 判断時刻。
12. 有効期限条件。
13. 実行後の結果。
14. ロールバックまたは封じ込めへのポインター。

台帳は、承認をUIイベントから説明責任の記録へ変えます。あとから、よりよい問いを立てることもできます。

• どのツールが承認を求めすぎているか。
• どの運用者が高リスク行動を最も速く承認しているか。
• どの承認ルールが誤検知を起こしているか。
• 拒否された行動のうち、あとで安全な代替案が見つかったものはどれか。
• 承認された行動のうち、ロールバックを引き起こしたものはどれか。
• どの継続的な付与が長く残りすぎたか。

2026年5月のオペレーティングシステムセキュリティに関する論文は、エージェントがOS風の既知の問題に直面すると論じています。リソース分離、権限分離、仲介された通信です。⁷ 承認も同じ系統に属します。実行環境は、OSが特権操作を仲介するように、権限を仲介すべきです。狭く、一貫して、要求より長く残るログを伴って。

簡単なまとめ

AIエージェントの承認は、認可オブジェクトになる必要があります。一時停止してクリックさせるプロンプトはツール呼び出しを止められますが、それだけでは説明責任を担えません。有用な承認システムは、実行主体、行動、リソース、リスク、証拠、期間、有効期限、取り消し、監査を定義します。

プロダクト上の教訓は明確です。低リスクの作業は静かに進め、高リスクの作業は明示的に扱いましょう。そして、システムが範囲付きの行動記録を見せられる場面で、人間に流暢な説明だけを承認させてはいけません。

FAQ

AIエージェントにおける承認と認可の違いは何ですか？

承認は人間による判断イベントです。認可は、定義された条件のもとでエージェントに具体的な行動を実行させる、範囲付きの権限です。強いエージェントシステムでは、この2つを接続します。人間の承認によって、リソース、リスク、有効期限、証拠、監査項目を持つ狭い認可記録が作られます。

AIエージェントのすべてのツール呼び出しに承認が必要ですか？

いいえ。チームはリスクに応じて承認を振り分けるべきです。既知の範囲内の低リスク読み取りは、ログを残しながら静かに実行できます。中リスクの行動はまとめてレビューできます。メッセージ送信、公開、削除、デプロイ、支出、エクスポート、権限変更のような高リスク行動は、実行前に一時停止すべきです。

AIエージェントで継続的な承認は安全ですか？

継続的な承認は、範囲が狭く、短時間で失効し、見える状態に保たれるなら役に立ちます。読み取り専用ツールに対する実行限定の承認は妥当な場合があります。一方で、シェル、デプロイ、支払い、メール送信、削除に対する広い継続的承認は、1回の判断から大きすぎる権限を生みます。

AIエージェントの承認プロンプトには何を含めるべきですか？

承認プロンプトには、行動、リソース、ツール引数、実行主体、リスク区分、証拠、有効期限、ロールバック経路、監査先を含めるべきです。また、承認だけでなく、拒否、証拠要求、範囲分割の判断も用意する必要があります。

エージェント製品で承認疲れを減らすにはどうすればよいですか？

ポリシー内の低リスク行動は自動許可し、中リスクの判断はまとめ、コミット地点でだけ中断し、構造化された証拠を表示し、付与に有効期限を設け、拒否を通常の制御経路として記録します。よい承認は、曖昧な質問を減らし、より正確な質問を増やします。

参考文献