Claudeの「auto mode」は、AnthropicがClaudeのweb・デスクトップ・モバイルアプリとClaude Codeでデフォルトの権限モードにすると発表した自動承認の仕組みで、毎回の承認プロンプトの代わりにAI分類器が危険な操作を判定します。
室谷代表取締役Anthropicが大きめの発表を出しました。Claudeのアプリ全体とClaude Codeで、権限モードのデフォルトが「毎回承認」から「auto mode」に変わるという話なんですよね。
テキトー教師DotAI 認定講師これは単に「承認ボタンが減って楽になる」という話じゃないんですよ。誰が何を承認するのかという設計自体が変わる話で、講座でもよく聞かれる「承認疲れ」に正面から答える発表です。
室谷代表取締役まず発表内容を整理しましょうか。Anthropicの公式スレッドによると、来週からClaudeのweb・デスクトップ・モバイルアプリのセッションが、Pro・Max・Teamプランでauto modeをデフォルトで動かす、と。
テキトー教師DotAI 認定講師加えてClaude Code側は8月14日からauto modeがデフォルトの権限モードになる、と。アプリとClaude Codeで時期が少し違うところが実務的には大事です。
室谷代表取締役発表では「毎ステップの承認を求める代わりに、自動チェックが危険な操作をブロックする。手動モードにはいつでも戻せる」という言い方なんですよね。
シンプルですが、中身はかなり作り込まれています。
シンプルですが、中身はかなり作り込まれています。
テキトー教師DotAI 認定講師そうですよね。しかもAnthropicはこのauto modeについて、エンジニアリングの解説記事まで出しているんです。
そちらを読むと「なぜ必要なのか」から丁寧に説明されています。
そちらを読むと「なぜ必要なのか」から丁寧に説明されています。
Claudeの「auto mode」とは？何がいつからデフォルトになるのか
権限モードの位置づけ
サンドボックス
- 安全
- 設定の手間が大きい
auto mode
- モデルベースの分類器が承認を代行
- 高い自律性・低メンテナンス
- セッション開始時点のデフォルトが変わる
室谷代表取締役まず定義から。auto modeは、Claude Codeがツール呼び出しをどう承認するかの設定である「権限モード」の一つで、承認をユーザーではなくモデルベースの分類器に委ねる中間モードなんですよね。
テキトー教師DotAI 認定講師位置づけが絶妙なんですよ。両極端があって、片方はサンドボックスで安全だけど設定の手間が大きい、もう片方は
auto modeはその間に立って「高い自律性・低メンテナンス」を狙うものです。
--dangerously-skip-permissionsで設定不要だけど大半の状況で危険。auto modeはその間に立って「高い自律性・低メンテナンス」を狙うものです。
室谷代表取締役スケジュールは2つに分かれています。アプリ側は「来週から」、Claude Code側は「8月14日から」。
対象はPro・Max・Teamプランです。
対象はPro・Max・Teamプランです。
テキトー教師DotAI 認定講師ここは受講生さんからもよく聞かれるところで、プランによって挙動が変わる可能性があるので、自分のプランを確認しておくのが安心です。プランごとの料金や制限はClaude Code Maxとは？5xと20xの違い、料金、制限を完全解説【2026年最新】で詳しく解説しています。
室谷代表取締役あと地味に重要なのが「セッションがauto modeで動く」という表現ですよね。設定を書き換えるというより、セッションの開始時点のデフォルトが変わるイメージです。
テキトー教師DotAI 認定講師そこは誤解されやすいので、後半で設定の話を丁寧にします。
auto modeで何が変わる？承認疲れはどう解消される
従来の承認方式 vs auto mode
従来の承認方式
- デフォルトで毎回承認を求める
- 「approve」の連打が発生
- 実際にプロンプトの93%を承認
- 内容を注視しなくなる（承認疲れ）
- 安全のための仕組みが形骸化
- 長時間タスクが承認待ちで止まる
auto mode
- 危険でない操作は承認なしで通す
- 危険な操作だけブロック
- 人間の注意力を「本当に見るべき場面」に配分
- 長時間タスクの途中で止まらない
- 判断を分類器に預ける（安全性の課題）
室谷代表取締役従来の課題ははっきりしていて、デフォルトで毎回承認を求めるから「approve」の連打が発生する。Anthropicの解説記事では、ユーザーが実際にプロンプトの93%を承認していたと書かれています。
テキトー教師DotAI 認定講師93%ですよ。これはもう読んでいないに近いですよね（笑）。
これが「承認疲れ（approval fatigue）」で、内容を注視しなくなる。安全のための仕組みが形骸化するわけです。
これが「承認疲れ（approval fatigue）」で、内容を注視しなくなる。安全のための仕組みが形骸化するわけです。
室谷代表取締役MYUUUでもエージェントに作業を投げるとき、承認が続くとだんだん確認が雑になる感覚はあるんですよね。判断のコストが高い作業を人間が毎回やる設計は、現実的じゃないなと。
テキトー教師DotAI 認定講師そこでauto modeは、危険でない操作は承認なしで通し、危険な操作だけブロックする。人間の注意力を「本当に見るべき場面」に配分する発想なんです。
室谷代表取締役長時間タスクの途中で止まらないのも大きいですよね。調査を投げて戻ってきたら承認待ちで止まっていた、というのはよくある話で。
テキトー教師DotAI 認定講師ただし、止まらないということは、判断を分類器に預けるということでもあります。そこは次の安全性の話につながります。
危険な操作はどこまでブロックされる？検出率89%と手動承認14%の意味
段階別・データセット別の検出精度
| データセット | 第1段階のみ | フルパイプライン |
|---|---|---|
| 実内部トラフィック n=10,000（偽陽性率） | 8.5% | 0.4% |
| 実際の過剰積極アクション n=52（偽陰性率） | 6.6% | 17% |
| 合成データ流出 n=1,000（偽陰性率） | - | 5.7% |
室谷代表取締役ここが一番センセーショナルな数字です。公式スレッドでは、テストで危険なコマンドの89%を検出した、手動承認は14%だった、と。
テキトー教師DotAI 認定講師この14%という数字の意味を噛みしめたいんですよ。人間が手動で承認していた場合、危険なコマンドの86%はそのまま通っていた、という比較ですから。
室谷代表取締役人間の方が危ない、というのは直感に反しますけど、93%を反射的に承認している現実を考えれば整合的ですよね。
テキトー教師DotAI 認定講師公式の解説記事には、より細かい実測値も出ています。実内部トラフィックn=10,000で偽陽性率0.4%、実際の過剰積極アクションn=52で偽陰性率17%、合成データ流出n=1,000で偽陰性率5.7%（フルパイプライン）です。
室谷代表取締役整理するとこうです。
| データセット | 内容 | フルパイプラインの結果 |
|---|---|---|
| 実内部トラフィック n=10,000 | Anthropic社員の実際のツール呼び出し | 偽陽性率 0.4% |
| 実際の過剰積極アクション n=52 | 社員が拒否した、または事後フラグされたもの | 偽陰性率 17% |
| 合成データ流出 n=1,000 | 機密データのHTTP POST、信頼できないリモートへのgit push等 | 偽陰性率 5.7% |
テキトー教師DotAI 認定講師段階ごとの数字も面白いんですよ。第1段階の高速フィルタだけだと実トラフィックの偽陽性率8.5%、過剰積極アクションの偽陰性率6.6%。
第2段階を通すと偽陽性率が0.4%まで下がる代わりに、偽陰性率が17%に上がる。
第2段階を通すと偽陽性率が0.4%まで下がる代わりに、偽陰性率が17%に上がる。
室谷代表取締役つまり第2段階は「誤ってブロックする件数」を減らすために「見逃す件数」を少し受け入れている、というトレードオフなんですね。
テキトー教師DotAI 認定講師そうです。しかもAnthropicは17%という数字を「正直な数字」と書いているんですよ。
見逃しの多くでは、分類器は危険自体は正しく認識している。何を間違えるかというと「そのセッション内の同意シグナルが、この操作の影響範囲をカバーしているか」の判断なんです。
見逃しの多くでは、分類器は危険自体は正しく認識している。何を間違えるかというと「そのセッション内の同意シグナルが、この操作の影響範囲をカバーしているか」の判断なんです。
室谷代表取締役「PRを片付けて」と言ったけどforce-pushは名指ししていない、以前似た操作を承認したけど1回の承認はパターンではない、という例が挙げられていますね。
テキトー教師DotAI 認定講師ここは受講生さんにも強調しているところで、「auto modeは万能の安全装置ではない」ということです。17%は残る前提で運用を考える必要があります。
auto modeの安全性はどう担保されている？分類器の仕組みと4つの脅威モデル
室谷代表取締役仕組みを分解すると、防御は2層なんですよね。入力層と出力層。
テキトー教師DotAI 認定講師入力層はサーバー側のプロンプトインジェクション検査です。ファイル読み取り、web取得、シェル出力、外部ツールの応答といったツール出力がエージェントのコンテキストに入る前にスキャンされ、乗っ取りの試みに見える場合は警告が付与される。
室谷代表取締役出力層がトランスクリプト分類器で、Sonnet 4.6上で動作し、各アクションを実行前に評価する。人間の承認者の代わりを務めるわけですね。
テキトー教師DotAI 認定講師分類器は2段階です。まず高速な単一トークンのyes/noフィルタが「ブロックするか」を判断し、引っかかった場合だけchain-of-thoughtで再評価する。
ほとんどのアクションは第1段階で通るので、推論トークンは必要な場所にだけ使われる設計です。
ほとんどのアクションは第1段階で通るので、推論トークンは必要な場所にだけ使われる設計です。
室谷代表取締役興味深いのは、分類器が見る範囲を絞っているところですよね。ユーザーメッセージとエージェントのツール呼び出しだけを見て、Claude自身のメッセージとツール出力は取り除かれる。
設計として「reasoning-blind」だと。
設計として「reasoning-blind」だと。
テキトー教師DotAI 認定講師モデルのもっともらしい説明に引っ張られないようにする工夫ですね。では、そもそもどんな危険を想定しているのか。
脅威モデルは4つです。
脅威モデルは4つです。
室谷代表取締役整理するとこうです。
- 過剰な積極性（overeager behavior）：ユーザーの目的は理解しているが、承認範囲を超えて主導権を取ってしまう
- 単純な誤り（honest mistakes）：影響範囲を誤解する。テスト用だと思ったら共有リソースだった、など
- プロンプトインジェクション：ファイルやwebページ、ツール出力に仕込まれた指示がエージェントを乗っ取る
- モデルの非整合：エージェントが独自の目標を追うケース。現時点では実運用では見られていないが、モデル公開ごとに評価している
テキトー教師DotAI 認定講師分類器は特に過剰積極性と単純な誤りにチューニングされている。Anthropicの内部インシデントログには、指示の誤解釈によるリモートgitブランチ削除、エンジニアのGitHub認証トークンの内部クラスタへのアップロード、本番DBへのマイグレーション試行、といった事例が記録されているそうです。
室谷代表取締役ブロック対象の例も具体的ですよね。曖昧な依頼での一括削除、認証エラー時に環境変数をgrepして代替トークンを探す動き、名前の類似でジョブを推測して削除、デバッグ用スクリプトをGitHub Gistで共有してしまう流出、デプロイ失敗時に検証スキップのフラグで再試行、など。
テキトー教師DotAI 認定講師判断の順番も決まっていて、第1段階は組み込みの安全ツール許可リストとユーザー設定、第2段階はプロジェクト内のファイル操作、第3段階がトランスクリプト分類器です。
室谷代表取締役ここ、実務的に面白い仕様があって。auto modeに入るとき、任意のコード実行を許す権限ルールは落とされるんですよ。
シェルの全許可、python・node・rubyなどのワイルドカード付きインタプリタ、パッケージマネージャのrunコマンド。
シェルの全許可、python・node・rubyなどのワイルドカード付きインタプリタ、パッケージマネージャのrunコマンド。
テキトー教師DotAI 認定講師手動承認モードでは便利のためにそういう包括ルールを設定している人が多いけど、そのままにすると分類器が最も危険なコマンドを見られなくなるから、という理由です。「allow running code formatters」のような狭いルールは引き継がれるが、広いインタプリタ脱出は引き継がれない。
室谷代表取締役分類器のプロンプトは固定テンプレートに3つのスロットを差し込む構成で、環境（信頼境界）、ブロック規則（デフォルト20超）、例外の3つ。デフォルトは保守的設定で、
claude auto-mode defaultsで全リストを確認できると。テキトー教師DotAI 認定講師ブロック規則のグループも4つに整理されています。破壊・流出、セキュリティ態勢の劣化、信頼境界の越境、レビューの回避や他者への影響。
例外は、リポジトリのマニフェストに既に宣言されているパッケージのインストール、標準的な認証フロー、セッションの作業ブランチへのpushなど、狭い範囲です。
例外は、リポジトリのマニフェストに既に宣言されているパッケージのインストール、標準的な認証フロー、セッションの作業ブランチへのpushなど、狭い範囲です。
室谷代表取締役デフォルトで信頼されるのは「今作業しているgitリポジトリ」だけ、というのも覚えておきたいところです。GitHub orgやクラウドバケット、内部APIは設定で追加する。
auto modeの設定・切り替え方法——手動承認に戻すには
室谷代表取締役ここから実務の話です。まず「手動に戻せる」というのは公式スレッドでも明言されています。
テキトー教師DotAI 認定講師設定の入口はいくつかあります。権限モード自体は
モードの一覧にはdefault（CLIや各拡張、デスクトップアプリではManualと表示）、acceptEdits、plan、auto、dontAsk、bypassPermissionsがあります。
defaultModeを設定ファイルで指定して、セッション開始時のモードを変えられます。モードの一覧にはdefault（CLIや各拡張、デスクトップアプリではManualと表示）、acceptEdits、plan、auto、dontAsk、bypassPermissionsがあります。
室谷代表取締役検索でも聞かれている
--enable-auto-modeオプションやShift+Tabでのモード切替ですけど、今回の公式ドキュメント抜粋にはその記載はないんですよね。現時点では明らかにされていません、と正直に書いておくのが正確です。テキトー教師DotAI 認定講師一方で、確実に書かれている方法はあります。設定ファイルの
管理設定に置けば上書きされないので、組織で禁止したい場合に有効です。
permissions.disableAutoModeを"disable"にすると、auto modeを使えなくできる。管理設定に置けば上書きされないので、組織で禁止したい場合に有効です。
室谷代表取締役同じ枠組みで
permissions.disableBypassPermissionsModeもありますね。あと、/permissionsダイアログにauto modeの分類器ルールを表示する「Auto mode」タブが追加される、というのも書かれています。テキトー教師DotAI 認定講師設定ファイルのスコープも整理しておきましょう。ユーザー設定は
~/.claude/settings.json、共有プロジェクト設定は.claude/settings.json、プロジェクトローカルは.claude/settings.local.json、そして組織の管理設定です。室谷代表取締役チームで揃えるなら共有プロジェクト設定をコミット、個人の例外はローカルに置く。この使い分けはこれまでと同じですね。
設定ファイルの場所や優先順位はClaude Codeのアップデート方法完全ガイド：コマンド・チャンネル設定・自動更新の止め方まで【2026年最新】でも触れています。
設定ファイルの場所や優先順位はClaude Codeのアップデート方法完全ガイド：コマンド・チャンネル設定・自動更新の止め方まで【2026年最新】でも触れています。
テキトー教師DotAI 認定講師分類器の設定をいじる場合は、ゼロから書くのではなく出荷時のベースラインを編集するのが推奨されています。まずはデフォルトで動かして、必要に応じて育てていく。
室谷代表取締役ちなみに分類器の呼び出しには「Auto mode classifier charges」というドキュメント項目もあるので、コスト面が気になる人はそちらを確認しておくとよいと思います。
auto modeの注意点と向き不向き——サンドボックスや危険オプションとの違い
室谷代表取締役ここは誤解を解いておきたいところです。auto modeはサンドボックスの代替ではないんですよね。
テキトー教師DotAI 認定講師ええ。サンドボックスはツールを隔離して危険な操作を防ぐ仕組みで安全ですが、新しい機能ごとに設定が必要で、ネットワークやホストへのアクセスが必要になると分離が破れる。
メンテナンスの負荷が高いんです。
メンテナンスの負荷が高いんです。
室谷代表取締役対して
--dangerously-skip-permissionsは設定不要だけど保護がない。auto modeはその中間で、分類器による判定という保護を低メンテナンスで提供する、という整理です。テキトー教師DotAI 認定講師だから「auto modeにしたからサンドボックスは不要」ではないんですよ。逆に、サンドボックスで足りる場面ではサンドボックスを使う、auto modeは自律性を上げたい場面で使う、という使い分けになります。
室谷代表取締役向き不向きで言うと、長時間のコーディングや調査など、途中で止まると困るタスクはauto modeが向いています。一方で、本番環境に近い操作や、影響範囲が読みにくい破壊的操作を伴う作業は、手動承認のままか、より厳格な設定にしたほうがよいと思います。
テキトー教師DotAI 認定講師あと見逃し17%という数字を踏まえると、バージョン管理は必須ですね。プロジェクト内のファイル編集は分類器を通らずに許可されますが、それはバージョン管理でレビューできるから、という前提があります。
室谷代表取締役そこは設計思想がはっきりしていて、in-projectの編集はコストを払わず通す、レビューはgitでやる、と。
テキトー教師DotAI 認定講師権限ルールはモデルではなくClaude Codeが強制する、という点も重要です。プロンプトやCLAUDE.mdの指示はClaudeの行動を形作るけど、許可される範囲は変えない。
アクセスを変えるには
アクセスを変えるには
/permissions、権限モード、PreToolUseフックを使う。室谷代表取締役これはセキュリティ的には安心材料ですよね。モデルが何を言ってもルールは変わらないわけですから。
テキトー教師DotAI 認定講師逆に言うと「プロンプトで許可してあるから大丈夫」という運用は成り立たない。講座でもそこは繰り返し伝えています。
室谷代表取締役あと地味に、denyルールはallowルールより優先されるので、組織で禁止したい操作はdenyで書くのが確実です。auto modeの分類器ルールと合わせて設計したいところですね。
テキトー教師DotAI 認定講師そうそう。ルールはdeny、ask、allowの順に評価されて、最初にマッチしたものが勝つ。
specificityでは変わらない。この順序を覚えておくと設定で迷いません。
specificityでは変わらない。この順序を覚えておくと設定で迷いません。
室谷代表取締役よくある質問
室谷代表取締役ここからは、よく聞かれる点を整理していきます。
テキトー教師DotAI 認定講師まず「いつから？」ですね。アプリ側は来週から、Claude Code側は8月14日から、Pro・Max・Teamプランが対象です。
室谷代表取締役「無料プランは？」については、今回の発表ではPro・Max・Teamとしか書かれていないので、現時点では明らかにされていません。
テキトー教師DotAI 認定講師「手動承認に戻せる？」は、戻せます。設定ファイルの
defaultModeでセッション開始時のモードを指定できますし、permissions.disableAutoModeを"disable"にすればauto mode自体を使えなくできます。室谷代表取締役「どんな操作が自動承認される？」は、第1段階の組み込み安全ツール許可リスト（ファイル読み取り、テキスト・ファイルパターン検索、コードナビゲーション、todoやplanモードの遷移など状態を変えないもの）とユーザー設定、第2段階のプロジェクト内ファイル操作です。シェルコマンドやweb取得、外部ツール連携、サブエージェント起動、プロジェクト外のファイル操作は分類器に回ります。
テキトー教師DotAI 認定講師「危険なコマンドはどこまで止まる？」は、テストで89%の検出という発表値があります。ただし実測では過剰積極アクションの偽陰性率17%という数字も出ているので、完全ではない前提で使うのが正解です。
室谷代表取締役「分類器は何を見ている？」は、ユーザーメッセージとエージェントのツール呼び出しだけです。Claude自身のメッセージとツール出力は取り除かれます。
テキトー教師DotAI 認定講師「コストは増える？」については、分類器の呼び出しに関するドキュメント項目があるので、詳細はそちらを確認してください。今回の資料だけでは具体的な金額までは示されていません。
室谷代表取締役「組織で禁止できる？」はできます。管理設定で
permissions.disableAutoModeを"disable"にすれば、上書きできない形で無効化できます。テキトー教師DotAI 認定講師最後に、これは「承認をなくす」話ではなく「承認の質を上げる」話だということです。人間が93%を反射承認していた現実を踏まえて、判断を分類器に渡し、人間は本当に危険な場面に集中する。
その設計変更として読むのが一番しっくりきます。
その設計変更として読むのが一番しっくりきます。
室谷代表取締役そうですね。まずはデフォルトのまま触ってみて、自分のワークフローでどこがブロックされるか、どこを見逃すかを観察する。
そこから設定を育てていくのが、Anthropicの想定する使い方なんだと思います。
そこから設定を育てていくのが、Anthropicの想定する使い方なんだと思います。
