「危険コマンド停止率、AIは89%、人間だと14%」 Claude Codeが「自動モード」をデフォルトにした理由:「有害な操作」の承認は、手動の方が2倍多い(2/2 ページ)
Anthropicは「Claude Code」のデフォルトモードを、都度承認から「自動」に切り替える。1053人を対象にした対照実験では、危険なコマンドを検知した割合が人のレビューを大きく上回ったという。
自動モードではプロンプトインジェクション攻撃が全て失敗
Anthropicは第三者のTrajectory Labsにプロンプトインジェクション(外部から不正な指示を紛れ込ませる攻撃)の評価も委託した。2026年7月17日時点で公開されていた「Claude Code v2.1.205」と「Codex v0.144.5」で、Anthropicには開示されていない72件の間接的なシナリオを10回ずつ試した。攻撃は「Claude Opus 4.7」に最適化されており、同モデルは評価対象に含まれないので、全てのモデルが未知の攻撃として受けたことになる。
自動モードで動作する「Claude Fable 5」「Opus 5」「Sonnet 5」に対しては、720回の攻撃が1件も成功しなかった。Codexの「自動レビュー」モードで動作する「GPT-5.6 Sol」では5.83%が成功し、「フルアクセス」モードでは19.03%だった。前者は、追加の保護なしで「権限をバイパス」モードで動作させたAnthropicの最新モデルの平均攻撃成功率0.09%より高い。実行時の推論レベルはGPT-5.6 Solが「max」、Claudeの各モデルが「high」だった。
両者は同一のWebブラウザ連携機能で評価されており、OpenAIやAnthropicが提供するChrome拡張機能などの保護機能はテストされていない。この結果は特定の製品の保護機能一式ではなく、基盤となるモデルの性能を測ったものとみるべきだとAnthropicは説明している。
Anthropic社内で防いだ3件の操作
自動モードはAnthropic社内のClaude Code利用でもデフォルトになっている。分類器が止めた操作は次の3件で、いずれも実行前に検知された。
- 社内ドライブへのアップロードに失敗したClaudeが同じレポートを公開のコード共有サイトに載せようとしたデータ流出
- 約2000のポッドにまたがるプロセスの一括終了と、数百基のGPUで実行中の学習ジョブを停止させかねない削除処理
- 読み取り専用の請求権限を求められたClaudeがアカウントのルートの完全な管理権限を持つロールを使おうとした権限昇格
自動モードの安全性を高めるための機能強化
Anthropicは、自動モードの安全性を高める機能も継続して追加しているという。
- 危険な操作の強制拒否
コードやシークレット(認証情報や秘密鍵)の外部送信など、データ漏えいにつながる操作は分類器が承認しない。組織独自の拒否ルールも設定できる - データのアクセスと共有先の検査
シークレットや機密情報の扱いをルール化し、「git push」コマンドやプルリクエスト(PR)の送信先が公開/非公開/信頼済みのいずれかを確認して、不適切な外部送信を防ぐ - 破壊的なGit操作を事前確認
「git reset --hard」コマンドなどを実行する前に、リポジトリの状態を確認し、未コミットの作業が失われるリスクを判断する - プロンプトインジェクション対策
Webページやファイル、ツール出力など外部から取得した内容をAPI側で検査し、悪意ある指示を検出した場合はClaudeのコンテキストに警告を追加する
モードの切り替え方
モードの切り替えは、CLIでは[Shift]+[Tab]キー、デスクトップアプリではモードのドロップダウンで行う。TeamsとEnterpriseプランでは、管理者は管理設定の「defaultMode」で組織全体のデフォルトモードを固定でき、「disableAutoMode」で自動モードを完全に無効にできる。
「Claude Enterprise」「Claude API」「Claude Platform on AWS」「Amazon Bedrock」「Google Cloud」のAgent Platform、「Microsoft Foundry」では、管理者が内容を確認する時間を設けるために当面はオプトインとなる。Anthropicはクラウド各社と連携して1カ月以内にデフォルトモードを「自動」に切り替える方針としていた。
Anthropicは、自動モードは大半のユーザーのリスクを減らすが、分類の仕組みに依存する異常リスクをなくすものではないとしている。本番環境のインフラに関わる重要な変更については、人間がClaudeの操作を確認することを引き続き推奨している。
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」を提唱した。エージェント実行層でのガバナンスを実現する新たな指針になるという。
