AIエージェントの承認は安全装置にならない — 3件に1件の見逃し | GH Media
URLがコピーされました

AIエージェントの承認は安全装置にならない — 3件に1件の見逃し

URLがコピーされました
AIエージェントの承認は安全装置にならない — 3件に1件の見逃し

AIエージェントの導入検討で、必ず出てくる説明があります。「ファイルの削除やコマンドの実行は、その都度人が承認する形にしますので安全です」。稟議はこれで通ります。そして、通ったあとに誰も検証しないのが、この前提です。

人は本当に、危険な操作を承認画面で止められるのか。ベルギーの開発者 Alex Wauters が2026年5月末に公開したブラウザゲームは、この問いをそのまま計測可能にしたものでした。プレイヤーはAIコーディングエージェントからの要求を次々に見せられ、承認するか拒否するかを選びます。安全な要求を止めれば減点、危険な要求を通しても減点です。

集まったデータは40,000回以上のプレイ、409,000件の承認・拒否判断。結果は、Scale X が公開した統計によれば次のとおりです。

  • 平均正答率は 66.3%。つまり脅威の3件に1件を見逃している
  • 32.9%のセッションが、差し引きマイナスの点数で終了した

3分の1のプレイヤーは、通した脅威と止めてしまった安全な操作の減点が、正しく判断できた分を上回っています。何もしないよりスコアが悪いということです。

見逃す原因は注意力ではなく構造にある

この数字を「集中力が足りない」で片付けると、対策が精神論になります。実際には、承認画面が機能しない理由は設計側にあります。

1つめは、量です。エージェントは1タスクの中で数十回の操作を要求します。そのほとんどは無害です。無害な要求が続いたあとに危険な1件を混ぜられたとき、人の判断はすでに「承認」に寄っています。The Register の記事も、ノイズの多さが疲労を生み、疲労が事故を招く構図を指摘しています。

2つめは、文脈の欠落です。画面に出るのはコマンドや操作の断片で、それが何のために必要かは書かれていません。「この rm は正しいのか」を判断するには、直前までにエージェントが何をしたかを知っている必要がありますが、承認する人はたいてい、その履歴を追っていません。

3つめは、拒否のコストです。止めれば作業は中断し、エージェントは別の手を探し、また承認を求めてきます。安全側に倒すほど作業が進まないという圧力が常にかかっています。ゲームで「安全な操作を止めても減点」という設計になっていたのは、この現実を再現するためです。

無害な要求が大量に続いた後に危険な要求が紛れ込む構造と、文脈が画面に出ないために判断材料が欠けている状態を示した図

承認を減らす方向に設計する

対策は「もっと注意深く承認する」ではありません。承認の回数そのものを減らし、承認に失敗しても被害が出ない形にすることです。実装の観点では、次の順で効きます。

  1. エージェントに渡す権限を、タスク開始前に絞り込む。実行中に判断させるのではなく、そもそも危険な操作ができない権限で動かします。必要な範囲を必要な時間だけ渡す考え方は常時付与をやめてJITアクセスに寄せるで扱っています
  2. 実行環境を本番から切り離す。エージェントが直接触れるのは作業用の複製で、本番への反映は別経路にする。承認が1件抜けても、被害が本番に届かない構造にします
  3. 取り消せる操作と取り消せない操作を分ける。取り消せる操作は承認を求めず流す。承認を求めるのは、外部への送信・削除・権限変更など戻せないものだけに絞ります
  4. エージェントが使う資格情報を、人のアカウントと分ける。共有アカウントで動かすと、誰が何をしたかが事後に追えません。整理の手順は非人間アイデンティティの棚卸しにまとめています

3が効くのは、承認画面に出てくる件数が一桁台まで落ちるからです。1タスクあたり50件の承認が3件になれば、その3件は実際に読まれます。66.3%という正答率は、読まずに押している分を含んだ数字です。

発注側が確認すべき2つの質問

エージェント型の仕組みを外部に発注する場合、仕様書に「危険な操作は承認制」と書かれていたら、次の2点を聞いてください。

1つめは、1タスクあたり何回の承認が発生する想定か。回数を答えられない場合、承認は安全装置として設計されていません。「必要に応じて」という回答は、実質的に無制限という意味になります。

2つめは、承認が漏れたときに何が起きるか。「漏れない前提です」という回答が返ってきたら、そこが設計上の空白です。実測で3件に1件漏れるものを、漏れない前提で組んではいけません。

なお、承認画面をすり抜ける経路は人の不注意だけではありません。エージェントが読み込んだ外部の文書やWebページに指示が仕込まれ、エージェント自身が危険な操作を「正当な作業」として要求してくる経路もあります。この防御は別立てで必要で、間接プロンプトインジェクションへの防御で扱っています。

次にやること

すでにエージェントを試験導入しているなら、直近1週間の承認ログを開いて、承認した件数と、実際に中身を読んだと言える件数を数えてみてください。この2つの差が、いま安全装置として機能していない部分です。

差が大きいなら、増やすべきは注意力ではなく、承認を求めない設計です。権限の絞り込みと環境の分離のどちらから着手すべきかは、扱っているデータと業務によって変わります。

AIエージェントを業務に組み込む際の権限設計や実行環境の分離を含めて相談したい場合は、グリームハブの開発・AI・自動化のご相談で承っています。対象業務と扱うデータによって適切な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。

Sources

URLがコピーされました

グリームハブ株式会社は、変化の激しい時代において、アイデアを形にし、人がもっと自由に、もっと創造的に生きられる世界を目指しています。

記事を書いた人

鈴木 翔

鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

関連記事

「TECH」の記事一覧を見る