「危険コマンド停止率、AIは89%、人間だと14%」 Claude Codeが「自動モード」をデフォルトにした理由:「有害な操作」の承認は、手動の方が2倍多い(1/2 ページ)
Anthropicは「Claude Code」のデフォルトモードを、都度承認から「自動」に切り替える。1053人を対象にした対照実験では、危険なコマンドを検知した割合が人のレビューを大きく上回ったという。
AIコーディング支援ツール「Claude Code」の「自動」モード(auto mode)は、「作業を中断されたくない」というユーザーのニーズと、有害な操作を避ける仕組みとの両立を狙った設計だ。
確認画面の代わりにツール呼び出しを分類器に通し、取り消しが効かない操作、破壊的な操作、ユーザー環境の外に向かう操作をブロックする。ブロックされると、Claudeは安全な方法を探すか、ユーザーに可否を尋ねる。3回連続、または1セッションで20回ブロックされて先に進めなくなると、手動承認に切り替わる。
自動モードでも、権限ルールは分類器より先に評価される。ただし「python:*」のように任意のコードを実行できる広い許可ルールは分類器を素通りさせるので、自動モードの間だけ無効になる。設定ファイル自体は書き換えられず、別のモードに切り替えれば再び有効になる。
この自動モードを「Pro」「Max」「Team」プランのデフォルト(既定)にすると、Anthropicは2026年8月7日(米国時間、以下同)に発表し、その理由について解説するブログを公開した。8月14日以降、これらプランでの新規セッションは自動モードで起動するようになっている。
別のデフォルトモードを設定している場合は、切り替えを尋ねる確認画面が1回だけ表示され、デフォルトモードを固定していれば変更されない。安全性を判定する分類器がツール呼び出しごとに消費する追加トークン分の課金は、これらのプランについて8月7日付で取りやめている。
「自動モード」をデフォルトにした理由
Anthropicがデフォルトモードを変更する理由として挙げるのが、手動レビューの形骸化だ。
Claude Codeでは、権限を求める確認画面の97%が承認されている。大半は安全な定型コマンドとみられるが、この承認率の高さは、多くのユーザーが内容を吟味せず反射的にクリックしていることが示唆される。
他の種類のダイアログでは判断はより慎重で、Claudeが計画を提示して承認を求める場合の却下率は39%に達するが、個別の権限要求は3%にとどまるという。
自動モードの方が危険なコマンドを止められる?
Anthropicは調査会社を通じて1053人の有償テスターを集め、専用環境でコーディングの対照実験を実施した。参加者は盲検法に従い、何が測定されているのかを知らされていない。セッションの途中で権限確認画面の一つが明らかに危険なコマンドに差し替えられ、承認するかどうかが記録された。承認しても危険な処理は実行されず、変更されたのは表示される文言だけだ。
テスターが危険なコマンドを止められたのは13.6%(1053件中143件)、自動モードは89%(1053件中937件)をブロックした。直接比較では、人間が承認した800件を自動モードがブロックし、逆に自動モードが許可したもののうち人間がブロックしたのは6件だった。
人間の検知率はセッションが長くなるほど下がり、序盤の約17%から、50回以上の確認を経た後には約5%まで落ちた。自動モードのブロック率は横ばいだった。
有害な操作の承認は、手動の方が2倍多い
現場の利用状況でも自動モードの方が有害な操作が少ないという結果が出ているという。
Anthropicは2026年5〜6月に、安全性監視の仕組みがフラグを立てたセッションを再評価した。対象は学習と分析へのデータ利用に同意したアカウントに限る。各セッションをモデルで採点し直し、被害の深刻度を0〜10で評価した。10は企業のソースコード全体の流出のような取り返しのつかない被害、7は本番データベースの行の削除、0はローカルで完結し元に戻せる操作に当たる。指示がどれだけ明示的だったかも別の尺度で採点した。
フラグが立ったセッションのうち、手動承認を経たものは、深刻な意図しない被害を含む割合が自動モードの2倍を超えた。本番環境レベル(深刻度7以上)では、ユーザーが明示的に求めていない有害な操作を含むセッションが手動承認で6.3%、自動モードで2.4%となり、この差は評価した全ての深刻度で確認された。
レッドチーム演習で見逃し率は12%から7%へ
AnthropicはAI安全性を評価する英国のApollo Researchと2週間のパイロットを実施した。コーディングの作業履歴に合成した攻撃を差し込むもので、広範な失敗、データの持ち出し、安全性に関わる脅威の3つのデータセットを対象とした。
Apollo Researchが成功した攻撃と提言を共有し、Anthropicは分類器に保護対象の環境の情報(リポジトリの公開/非公開、Gitの状態、データの取り扱いルール)を与えることを中心に対策した。
強化後、Apollo ResearchはAnthropicがアクセスできない別の攻撃セットで再テストした。自動モードはそれまで見逃していた攻撃の約半分を捕捉できるようになり、代わりに捕捉できていた攻撃の約2%を取りこぼした。見逃し率は12%から7%に下がっている。ただし、この攻撃は分類器の穴を見つけるための合成のもので、7%は現実のトラフィックでの見逃し率ではないという。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
AI開発はプロンプトからコンテキスト、ハーネスへと向かう ハーネス成熟度を測る3つのチェックリスト
「LLMを導入したのに生産性が上がらない」「レビューに追われる」 現場が直面する“限界”に対し、トップランナーたちが口をそろえて語るのが「ハーネスエンジニアリング」だ。先行者が明かす知見・ノウハウからハーネスエンジニアリングの実相に迫る。
優秀なAIでも「ファイル破壊」は防げない? Dockerが説く「モデルの性能」より重要なこと
Dockerは、AIエージェントの仕組みと安全に運用するための条件を解説した。自律的に動くAIエージェントは誤作動時の被害範囲が広がることから、モデルの性能よりもインフラ環境が重要だと指摘する。
AIが賢くなるほど、人間は弱くなる? セキュリティ業務に潜む「承認するだけ」のわな
AIによってセキュリティ業務の分析や判断は、かつてないほど速く、正確になりつつありますが、それで人間は本当に楽になるのでしょうか。業務を分類すると、AIに「任せるべき仕事」と「人間に残すべき仕事」の意外な境界線が見えてきました。
ITインフラ専門家の私でも、もうAIには勝てない――「Active Directory」障害対応をAIに丸ごと任せてみた結果
AIにメールや資料を書かせるのではなく、システムを変更できる管理者権限を渡し、ITインフラ障害の調査から対処まで任せたら、何が起きるのでしょうか。本連載「Microsoft MVP胡田のAI検証ラボ――情シス業務、AIにどこまで任せられるか」の第1回では、AIにActive Directoryの障害対応を丸ごと任せました。原因も調査手順も教えません。AIはどこまで自力で原因にたどり着き、どのようにシステムを変更したのか。実際の操作記録とともに検証します。
開発者の未来は「承認疲弊」? AIエージェントが従来のガバナンスを破壊する理由
Dockerは、自律的に動作するAIエージェントを前提とした新たなセキュリティフレームワーク「3C」を提唱した。エージェント実行層でのガバナンスを実現する新たな指針になるという。
