「危ないコマンドの前に、人間が確認すればいい」。AIエージェントの事故対策として、まず思いつくのはこの発想でしょう。では承認の回数を増やせば、事故は本当に減るのでしょうか。
承認を挟んでも本番DBは消えた
「11回止めたのに本番DBが消えた」 AIエージェント“6つの暴走”と、人間の承認を増やしても防げない理由（＠IT）は、Dockerが整理したAIコーディングエージェントの重大インシデント6類型を手がかりに、事故を起こさない設計を考える記事です。ホームディレクトリ全体の削除や、オペレーター権限を継承したKiroが本番環境の再構築を選んで13時間停止した事例が挙がっています。見出しには、危険コマンドの停止率が「AIは89％、人間は14％」とあります。
一見すると「承認を厚くすれば防げる」
人間は文脈を知っていて、AIは知らない。だから最後の関門に人間を置く。この理屈は自然です。承認の回数を増やすほど、その分だけ危険な操作を止める機会も増えるように見えます。
しかし、14％という数字は、人間の注意力が承認の件数に追いつかないことを示しています。確認が何十回も続けば、承認は判断ではなく作業になります。セキュリティ運用の「アラート疲れ」と同じ構図が、エージェントの承認ダイアログでも起きるということです。
もう一つ見落とせないのは、事例の多くが「承認の不足」ではなく「権限の継承」に根があることです。エージェントはユーザーと同じ権限で動くので、判断を誤ったとき、その誤りが届く範囲は人間と同じだけ広くなります。
問うべきは承認の数ではなく、誤りが届く範囲
本質は、承認の量ではなく、誤った判断が届く範囲の設計です。サンドボックスで隔離する、最小権限にする、本番の認証情報をそもそも渡さない。こうした前提が先にあって初めて、人間の承認は意味を持ちます。承認は全件に置く関門ではなく、取り消せない操作にだけ置く希少な判断であるべきです。
この考え方は、開発現場の外にも広がりえます。エージェントごとに固有のIDと権限を持たせ、人間の従業員と同じように棚卸しする運用です。複数のエージェントが並行して動く組織では、承認者がボトルネックになります。権限設計がそのまま組織設計になっていくでしょう。
冒頭の問いへ
「人間の承認を増やせば事故は防げるのか」。答えは、承認しなくても壊れない範囲が先に定義されている場合に限り、承認は効く、です。承認を増やす前に、承認が要らない領域をどう広げるかを問う必要があります。
関連記事
- Welcome Beam: a 501B open model you can own, customize, and scale
- Microsoft’s commitment for AI in education: Protecting students, strengthening learning
- What we’ve learned from Microsoft’s own AI transformation
参考文献
コメント