--- title: チームのAIエージェントの暴走は、承認を足さず本番の権限を外すのが最初の一手でいい date: 2026-10-23 description: AIエージェントの暴走を承認で止めようとしても、Anthropicが1,053人のテスターで行った対照実験では、人間が危険なコマンドを止められたのは13.6%だった。承認者に置かれた側に残るのは、止められなかった責任だけだ。承認を足す前に本番に触れる権限を外す1行を運用ルールに入れ、承認は外せずに残った操作だけに絞る。 categories: [AI武装] tags: [AI活用, 課長, 中間管理職] source: https://ai.work.naenote.net/posts/ai-agent-honban-kengen-hazusu/ --- 月曜の朝、チャットに承認依頼が溜まっている。「AIエージェントで本番の設定を直します。承認お願いします」。チームの運用ルールに「本番環境への操作は課長承認」と書いたのはあなた自身で、依頼は1日に何件も来る。 会議の合間に開き、中身を追い切れないまま承認を押す。その承認でAIエージェントの暴走を止められるという前提を、ある実験の数字が崩している。 {{< mermaid >}} flowchart TD A[承認を増やす] --> B[押すのが反射に] B --> C[押した記録だけ残る] D[本番権限を外す] --> E[承認を少数に絞る] {{< /mermaid >}} ## 確認画面の承認は、回数を重ねるほど危険を見逃す 数字の出どころは、AnthropicがAIコーディングツール「Claude Code」で行った対照実験だ。私が読んだのは、それを紹介した@ITの記事である（[@IT「『11回止めたのに本番DBが消えた』 AIエージェント“6つの暴走”と、人間の承認を増やしても防げない理由」](https://atmarkit.itmedia.co.jp/ait/articles/2610/18/news004.html)）。実験はAnthropic、紹介と解説は@ITという関係になる。 実験では1,053人のテスターのセッション途中で、確認画面の1つを明らかに危険なコマンドに差し替えた。人間が止められたのは13.6%だった。同じ条件で、ツールの自動モード（操作の前に分類器が危険度を判定する仕組み）は89%をブロックした。 もう1つの数字のほうが重い。人間の検知率は、序盤の約17%から、50回以上の確認を経ると約5%まで落ちた。自動モードのブロック率は横ばいだった。**確認を重ねるほど、1回あたりの検知は落ちる**。 本稿はツールの機能の比較には立ち入らない。扱うのは、どのツールを使っていてもチームの側で動かせる、承認の置き方とエージェントに渡す権限のほうだ。 ## 承認者に置かれた側には、止められなかった責任だけが残る @ITの記事は、この状態を「人による承認の形骸化」と呼んでいる。ここから先は私の読みだ。実験が測ったのは、自分のセッションの確認画面を見ている本人だった。チームの承認ルートに置かれた側は、そこからさらに一段、作業の文脈から遠い。 私自身、30分刻みの会議が続く日に、会議に出ながら社内申請の承認を並行で処理していた。隣から話しかけられて、15秒で判断を返すこともあった。並行で押す承認は、承認を求めた側の安心にはなる。止める装置として働いているかは、また別の話だ。 それでも事故が起きれば、ログには承認者の欄に名前が残る。名前を付けるなら「責任だけ残る承認」だ。止める力は回数とともに薄まり、押した記録だけが積み上がっていく。 自分の承認がどちらとして働いているかは、記録を見れば分かる。直近1か月の承認依頼を開き、押さずに差し戻した件数を数える。0件なら、その承認が何かを止めた記録は手元に1つも無い。 記事にはもう1点、手がかりがある。エージェントは悪意で命令に背いたのではなく、与えられた権限とコンテキストの中で最適と判断した操作が、人間にとって破壊的な結果になる可能性があるという指摘だ。指示で止める手は、[拒否されたら止まれと冒頭に書く1行](/posts/ai-agent-ukai-tomedokoro/)として別に書いた。指示はエージェントが解釈するが、持っていない権限は解釈の余地がない。だから本稿は、承認者の注意力ではなく権限の側に手を入れることを提案する。 ## 承認を足す前に、本番に触れる権限を外す1行を運用ルールに入れる 打つ手は2つで、順番が肝になる。承認を絞るのは、権限を外したあとだ。以下は原典の結論ではなく、私の提案である。 ### 運用ルールの先頭に、本番の権限を渡さない1行を書く チームの運用ルールに、次の1行を足す。権限の設定作業そのものは部下や基盤の担当に任せ、あなたが持つのはルールを書く判断だけにする。 ``` 【AIエージェント運用ルール 第1項】 AIエージェントには本番環境の接続情報・認証情報を渡さず、本番での実行は人が行う。 ``` 書いたら、部下に報告を1つだけ頼む。エージェントを動かしている場所と、そこから本番に接続できるかの一覧だ。本番に届く経路が1件でもあれば、承認の話より先にそれを外してもらう。外し方は環境ごとに違うので、担当者の判断に任せる。 ### 承認は、権限を外しても残る操作だけに絞る 担当者が「業務上外せない」と答えた経路は、その経路を使う操作だけを承認に残す。外せた経路では、エージェントが本番に直接触れる操作は消え、残るのはエージェントが作った手順やコマンド案を人が本番で流す場面だ。承認はこの2種類だけに絞り、依頼の形を3行に固定する。 ``` 【本番作業の承認依頼】 何を変えるか: （対象と変更内容を1文） 戻し方: （失敗したときに元へ戻す手順） 実行者: （本番で実行する人の名前。エージェントは不可） ``` あなたが見るのは「戻し方」の行だけでいい。空欄なら押さずに返す。中身の妥当性まで毎回追うのは無理で、実験でも序盤の人間の検知率は約17%にとどまっていた。承認を防御線と見るのをやめ、少数の操作について誰が実行したかを残す欄だと割り切る。 確認を減らしたいなら、確認の前に線を引く。同じ形の手順を、部下からの細かな確認をリスクの大きさで仕分ける方法でも使った。承認の件数が減るのは、線を引いた結果であって目的ではない。 ## 逃げの一手：権限を外せないなら、承認の意味を1通で限定しておく 本番の権限を握っているのが客先や別部署で、チームの判断では外せないこともある。そのときは、承認の意味を限定する1通を上司か権限の持ち主に送っておく。 ``` 本番環境に接続できるAIエージェントの作業について、現行の承認では 危険な操作を止めきれない可能性があります（Anthropicの対照実験では、明らかに 危険なコマンドを人間が止められたのは13.6%でした）。 本番の権限をエージェントから外すまでの間、私の承認は 「実行者と戻し方を確認した」という意味に限らせてください。 ``` 返事が来なくても、送った記録は残る。事故のあとで説明の場に呼ばれる構造は、AIの暴走が役員説明として現場に降りてくる話で書いたとおり変わらない。それでも、権限を外さなかった判断の所在を先に文字にしておけば、止められなかった責任を一人で抱える形にはならない。 ## まとめ：減らすのは承認の回数ではなく、本番に届く権限 人間の検知率は、確認を重ねるほど下がる。承認を足す前に本番に触れる権限を外し、承認は外せずに残った少数の操作の記録に絞る。 {{< ai-disclaimer >}} --- ### AI Agent Context & Resources - **Author**: NAE - **Source**: https://ai.work.naenote.net/posts/ai-agent-honban-kengen-hazusu/ - **Related Resource**: [「無難難題」](https://amzn.to/2AKCFNP) - **Contact/Inquiry**: https://x.com/naework