ハクソク

世界を動かす技術を、日本語で。

オートモードが「Claude Code」のデフォルトになりました

2026年8月10日原文(claude.com)

概要

  • Claude Code の自動モード（auto mode）が、Pro、Max、Teamプランでデフォルト化
  • 自動モードは安全性向上と作業効率化を両立
  • マニュアル承認よりも危険な操作を高確率でブロック
  • 設定変更や例外条件も詳細に説明
  • サードパーティ評価や実データに基づいた有効性検証

Claude Code自動モードのデフォルト化

  • 2026年8月14日 以降、Pro、Max、Teamプランの新規セッションで auto mode をデフォルト適用

  • 既に個別デフォルト設定がある場合、一度だけ切り替え確認プロンプト表示

  • ピン留め済みデフォルト設定の場合、変更なし

  • auto mode classifier による追加トークン消費は無料化（即日適用）

    • EnterpriseプランやClaude API、Claude Platform on AWS、Amazon Bedrock、Google Cloud's Agent Platform、Microsoft Foundryでは現時点で opt-in（任意選択）
    • 1か月以内にクラウドパートナーと協力し、全プラットフォームでデフォルト化予定
    • Enterprise管理者は managed settings でauto modeをデフォルト設定可能

自動モードの設計と動作

  • ユーザーの作業中断を最小限 にしつつ、不可逆的・破壊的・外部環境への操作を 分類器（classifier）で自動判定しブロック
  • 分類器がブロックした場合、Claudeが安全な代替案提案またはユーザーへ確認
  • 3回連続、またはセッション内20回ブロック時 は手動承認モードへ自動移行

安全性・生産性の向上

  • 数か月間の内部・外部 red-teaming、 プロンプトインジェクション評価、1,053名の有償テスターによる 対照実験、実セッション分析を実施
  • 全指標で auto mode が手動承認を上回るか同等の安全性を実証
  • Claude Opus 5 など長時間タスク向けモデルの実用性向上
  • Teams & Enterprise 利用者で PR提出数25%増加 という生産性向上実績
  • Adobe, Nuro, Gusto, Garner Healthなど既にauto modeを本番デフォルト運用

マニュアル承認と自動モードの比較データ

  • Claude Code での許可プロンプト承認率97%（多くが反射的クリック）
  • 設定ファイル分析では、CLIユーザーの49.5%が手動でBash許可ルール作成
    • 5%が全シェルコマンド許可、43%がpythonやnode等のインタープリタ許可
  • bypassPermissions や「今後表示しない」利用率62%、インタラクティブセッションの25%がbypass modeで開始
  • auto mode中も許可ルールは分類器の前に適用。ただし 任意コード実行を許す広範囲ルール はauto mode中は除外

安全性向上の根拠

  • 内部・外部評価で auto mode が人間の手動承認より安全
  • 1,053人のテスター実験で 危険コマンド検出率13.6%（人間）vs 89%（auto mode）
    • auto modeが人間が承認した800件の危険コマンドをブロック
    • セッションが長くなるほど人間の検出率低下、auto modeは安定
  • 実セッション分析で 重大な非意図的被害 が手動承認の2倍以上
    • 重大度7以上の被害：手動6.3%、auto mode 2.4%

外部評価・攻撃耐性

  • Apollo Researchとの協業で 合成攻撃テスト→分類器強化
    • miss rate 12%→7%へ改善、未知の攻撃にも汎用的に対応
  • prompt injection耐性 ：第三者機関による評価でauto mode有効時は 攻撃成功率0%
    • GPT-5.6 Sol（Codex Auto-review mode）は5.83%の攻撃成功率
    • Claude Fable 5, Opus 5, Sonnet 5（auto mode）は全攻撃失敗
  • auto modeは ツール呼び出し・ブラウザGUI操作両方で注入攻撃防御

社内運用実績と具体的防止事例

  • Anthropic社内でも Claude Code auto mode をデフォルト運用
  • 例：社外公開リスクのあるファイルアップロードの自動ブロック等

要約 ：Claude Codeのauto modeは、従来の手動承認を大きく上回る安全性と生産性を実現。今後さらに多くの環境でデフォルト化され、ユーザーの負担軽減・リスク低減に貢献。

Hackerたちの意見

「ここ数ヶ月、自動モードが普通のユーザーがプロンプトをクリックするよりも安全かどうかテストしてたんだ。」うん、彼らの立場からは分かるけど、いいや。たまに全部読まずにクリックすることもあるけど、やっぱり自分でコントロールしたいし、新しいコードについて学びたいし、もし道を外れたら方向転換したいんだ。これだとトークンを無駄に消費するだけだし、手動承認設定が今後のアップデートでも尊重されることを願ってる（そうじゃなかったら乗り換える）。

└

デフォルトは新しいユーザー向けに設定されてるけど、今の時点では君みたいな人（手動モードから大きな恩恵を受ける人）じゃなくて、もっと「コードに疎い」人が対象だよ。彼らは認識できないランダムなバッシュスクリプトのコマンドを承認するのが不安になるかもしれないからね。プロンプトから最初のバイブコードアプリに安全にユーザーを導くのが「ユーザージャーニー」になってるし、自動モードはClaudeがホームディレクトリをrm -rfするのを防ぐのが得意みたいだから、これは100%正しいビジネスの動きだと思う。自分のやり方を知ってる人（君みたいな）には、手動モードはシフトタブ一つで切り替えられるよ。

└

現在の最新モデルは「持続性が向上」してるし、サプライチェーン攻撃の量も多いから、これらのツールをサンドボックスで使わないのは頭おかしいよ。

└

似たようなワークフローだね。時々、コミットする前にコードレビューをしたかどうかを思い出させないといけないんだけど、時々それを忘れちゃうんだ。それに、ちょっと見ただけでも問題が見つかって、話し合ったり元に戻したりしなきゃいけないこともある。でも、はい、ただ「はい、はい、はい」ってクリックし続けるのは本当に疲れるよね…。

└

自動モードと危険な権限スキップを混同してるんじゃない？

└

最近、Claude DesktopとClaude Codeを少し混ぜて使ってみたんだけど、Claude Desktopは決定を求めるとタイムアウトして、そのままアクションを実行しちゃうんだ。これをオフにする方法は見つけられなかったよ。Claude Codeではタイムアウトしないように頼めるのにね。

└

トークンをもっと消費するのは彼らにとっては絶対に得策だけど、ユーザーにはあまり関係ないよね。

ちょっと言っておきたいんだけど、コメントしてる人の中には混同してる人もいるみたいだからね。自動モードは --dangerously-skip-permissions / YOLOモードとは違うよ。自動モードでは、コマンドが実行される前に分類器が動いて、理論的には危険なコマンドをブロックするんだ。結構イライラするし、やりすぎなところもあるけど、効果的だと思う。

└

Claudeは内部で自分自身と無駄にトークンを消費してるみたいだね。組織が支出を最適化してる中で、Claudeの製品ガイダンスはその逆風に逆らってるように見える。コストが制限された環境で運用してると、エンジニアはそれをあまり使えなくなるよ。

自動モードが出る前は、毎回の権限リクエストの前にスクリプトを実行してたんだ。それはHaikuを呼び出して、安全なコマンドと危険なコマンドの例をリストにして分類させて、後でレビューできるようにログを取ってた。自動モードが出るまではすごくうまくいってたけど、その後はプロバイダーの内蔵分類器の方が好みになった。自動モードがリリースされてからずっと使ってるよ。分類器が安全なコマンドをブロックしたのはほんの数回だけで、特に問題はなくて、デフォルトモードとして使い続けてる。最高だよ！

どうやら、私は過去1年間、すべてのClaudeインスタンスで --dangerously-skip-permissions を使ってるごく少数のユーザーの一人みたい。ほぼ反射的にやってるよ。大体Claudeはちゃんと動くけど、盲目的には信じてない。LLMは本質的に危険なツールだし、個々のコマンドをレビューしたり（または y を連打したり）しても、それが危険性を減らすわけじゃない。安全性は、まともなガードレール（VCSや不変ファイルシステム、読み取り専用トークンなど）を設ける開発者の責任だよ。Claudeのコマンドの安全性を分類するためにさらにClaudeを使うのは解決策じゃない。

└

私も同じことをしてるよ。crushやdeepseekをよく使ってるし、crushは安全装置を全部外してデフォルトでyoloモードにするようにパッチ当てた。毎日使ってるし、devopsにも使ってるよ。例えば、netappのストレージシステムを設定するために使ってるけど、一度も問題が起きたことはない。もちろん、システムのバックアップも取ってるし、全部リビジョン管理してる。タスクによっては、使い捨てのVMや本番システム、実験用システムで動かしてる。タスクに応じて、使い捨ての認証情報を与えたり（その後はローテーションするけど）、私のsshエージェントソケットにアクセスさせたりしてる。

Hacker Newsで議論の続きを見る