auto modeがShift+Tabで有効化できない原因と対処法
Claude CodeでShift+Tabやdefaultモード設定からauto modeに入れないときの原因を、バージョン・プラン・モデル・設定ファイルの4系統で切り分けます。
Auto modeがShift+Tabで有効化できない原因は何か
Claude CodeでShift+Tabを押してもauto modeが切り替え候補に出てこない、あるいはpermissions.defaultModeに"auto"を設定しても反映されない場合、原因はおおむね5系統に分かれます。バージョンが古い、プラン・モデル・プロバイダーの組み合わせが対応外、defaultModeやdisableAutoModeの設定ミス、feature-flag取得の停止、そしてAnthropic側の一時的な無効化です。
原因は一つではありません。公式ドキュメントは、auto modeが利用できないと判定されたセッションはそのままManualモードで起動すると説明しています。この判定はセッション開始時に一度だけ行われるため、設定を直した後は新しいセッションを開き直す必要があります。
auto modeでは、通常のプロンプトの代わりに分類器(classifier)が操作を審査します。分類器が具体的に何を許可・拒否しているかはClaude Codeのauto mode分類器は何を止めているかで扱っています。ここでは「そもそも有効化できない」というより手前の問題を切り分けます。
バージョンが古いと選択肢自体に出ない
auto modeを既定の起動モードにする仕組みは、Claude Code v2.1.228以降(macOS・Linux・WSL)またはv2.1.233以降(Windows)を要求します。これより古いバージョンでは、既定の起動モードは常にManualです。
まずインストール済みのバージョンを確認します。
claude --version古い場合は更新します。
claude updateバージョンを上げても改善しないときは、次の節のプラン・モデル・設定の条件を確認します。
プラン・モデル・プロバイダーの組み合わせが対応外になっていないか
auto modeの利用条件は、プラン・組織設定・モデル・プロバイダーの4点で決まります。どれか一つでも外れると、Shift+Tabの切り替え候補からauto自体が消えます。
| 観点 | 条件 |
|---|---|
| プラン | 条件全プランが対象。ただしPro・Max・Teamだけが既定の起動モードとしてautoを使う |
| 組織設定 | 条件TeamとEnterpriseは既定で利用可能。管理者がdisableAutoModeを"disable"にすると組織全体で無効化される |
| モデル(Anthropic API・Claude Platform on AWS) | 条件Opus 4.6以降、Sonnet 4.6以降、Fableモデルのいずれか |
| モデル(Bedrock・Agent Platform・Foundry・gateway) | 条件Sonnet 5、Opus 4.7以降、Fableモデルのいずれかのみ |
Sonnet 4.5・Opus 4.5・Haiku・claude-3系のモデルは、どのプロバイダーでもauto modeに対応していません。使用中のモデルがこれらに当たる場合、バージョンや設定を直しても選択肢には出ません。
EnterpriseプランとClaude ConsoleのAPIキーによる利用は、既定の起動モードがManualです。claude -pのような非対話実行やAgent SDK経由の利用も同様にManualが既定になります。これらの利用形態でauto modeを使うには、defaultModeを明示的に"auto"へ設定するか、--permission-mode autoを指定します。
defaultModeを設定したのに反映されない典型パターン
defaultMode: "auto"を設定ファイルに書いたのにManualのまま起動する場合、書いた場所が原因であることが多くあります。"auto"と"bypassPermissions"の2つの値だけは、.claude/settings.jsonと.claude/settings.local.jsonから設定しても反映されません。この2つの値は~/.claude/settings.jsonか管理者設定(managed settings)からのみ有効になります。
{
"permissions": {
"defaultMode": "auto"
}
}このJSONは~/.claude/settings.jsonか管理者設定に置きます。プロジェクトの.claude/settings.jsonに置くと、Claude Codeは無言でこの値を無視し、既定の起動モードにフォールバックします。
一方、組織側が意図的にauto modeを止めているケースもあります。管理者設定でdisableAutoModeを"disable"にすると、Shift+Tabの切り替え候補からautoが完全に外れます。実行中のセッションがこの設定を受け取ると、auto mode disabled by settingsという表示に変わりauto modeを離脱します。v2.1.251より前は、この離脱がセッション終了まで維持されていました。組織単位の制限か個人設定のミスかを見分ける際の目印です。管理者による制限の条件はClaude CodeのdisableAutoMode設定で扱っています。
feature-flag取得が止まっているとPro・Max・Teamでも既定にならない
Pro・Max・Teamプランでauto modeが既定の起動モードになる仕組みは、Anthropicから機能フラグを取得できていることが前提です。次のいずれかに当たるセッションはこの取得自体が止まります。
DISABLE_GROWTHBOOK・DISABLE_TELEMETRY・DO_NOT_TRACK・CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICのいずれかを設定している- Amazon Bedrock・Claude Platform on AWS・Google Cloud's Agent Platform・Microsoft Foundryなどのサードパーティ経由で、ホスト側が
CLAUDE_CODE_PROVIDER_MANAGED_BY_HOSTを設定していない - Claude apps gateway経由のセッションである
取得が止まっている間は、Shift+Tabでauto自体は選べても、セッション開始時に既定でautoへ入ることはできません。該当する環境変数を外せば、次のセッションから通常どおり取得が始まります。
インストール直後や更新直後の最初のセッションも同様です。機能フラグがまだ届いていないため、Pro・Max・Teamでも一時的にManualで起動することがあります。フラグは同じセッション中に取得されるため、次に開くセッションからは解消します。
サーバー側で一時的に無効化されるケース — 2026年3月の実例
Anthropicは、個々のアカウントやセッションに対してauto modeをサーバー側で一時的に止めることがあります。この判定を受けたセッションは、そのセッションが終わるまでauto modeが使えないままになります。原因がバージョンや設定ではなく、こちら側に見える手がかりがない場合はこのケースに当たります。
この動きが分かりやすく現れた実例が、2026年3月に報告されたGitHub issue #33587です。Max・Proの利用者からは、defaultMode: "auto"を設定してもステータスバーに「auto mode temporarily unavailable」と表示され続けるという報告が相次ぎました。Shift+TabでもPlanとAcceptEditsの間しか切り替わらず、こうした報告が20件近く集まりました。
投稿から約2週間、報告者の一人が次の経緯を共有しました。auto modeはTeamプラン向けの研究プレビューとして先行公開され、Enterprise・APIユーザーへの展開が続いていたという内容です。個人向けのPro・Maxプランには、展開時期が明示されていませんでした。実際、このissueに集まったコメントでは、Teamプランの利用者だけが問題なくauto modeを使えていました。
2026年3月当時、コミュニティが見つけた内部フラグ(参考情報)
公式には文書化されていませんが、当時のコメントでは~/.claude.json内のcachedGrowthBookFeatures.tengu_auto_mode_configという内部フラグが"enabled": "disabled"になっているという報告が相次ぎました。この内部キー名はAnthropicが公開しているものではなく、現在の挙動を診断する方法としては使えません。段階的な公開の様子を伝える当時の記録として残します。
公式ドキュメントの現行仕様では、Pro・Max・Teamのすべてが既定の起動モードとしてauto modeを使う対象になっています。2026年3月当時のプラン制限そのものはすでに解消していますが、Anthropicがサーバー側で個別に一時停止する仕組み自体は今も残っています。バージョン・プラン・モデル・設定を確認しても原因が見当たらないときは、時間を置いて新しいセッションを開き直すのが妥当な対処です。
セッションの開始時ではなく、個別の操作の最中に「モデルが一時的に利用できないため安全性を判定できない」という表示が出る場合は、今回とは別の話です。これは分類器へのリクエストが失敗したときのエラーで、原因と対処はClaude Codeのauto mode安全性判断エラーで扱っています。
Bedrock・Agent Platform・Foundryで見落としやすい設定
Amazon Bedrock・Google Cloud's Agent Platform・Microsoft Foundry・signed-inのClaude apps gateway経由のセッションでは、v2.1.158からv2.1.206までの間だけ、CLAUDE_CODE_ENABLE_AUTO_MODE=1を設定しないとauto modeが有効になりませんでした。v2.1.207以降はこの環境変数を設定していても効果がなく、無視されます。古い手順書や社内Wikiがこの変数を必須と書いたまま残っている場合、実際には不要な作業をしていることになります。経緯はCLAUDE_CODE_ENABLE_AUTO_MODEとはで扱っています。
これらのプロバイダーではShift+Tabの切り替え候補にauto自体は既定で出ますが、セッションが起動時からautoになるわけではありません。起動時のモードを既定でautoにするには、ユーザー設定か管理者設定でdefaultMode: "auto"を明示します。
原因別の対処チェックリスト
切り分けに迷ったときは、次の順に確認します。
| 原因 | 主な症状 | 確認方法 | 対処 |
|---|---|---|---|
| バージョンが古い | 主な症状Shift+Tabでauto自体が出ない | 確認方法claude --version | 対処claude updateで更新する |
| モデルが対応外 | 主な症状Opus 4.5・Sonnet 4.5・Haiku使用時に出ない | 確認方法現在のモデルを確認する | 対処Opus 4.6以降・Sonnet 4.6以降・Fableへ切り替える |
| defaultModeの置き場所が違う | 主な症状設定してもManualのまま起動する | 確認方法.claude/settings.jsonか.claude/settings.local.jsonに書いていないか | 対処~/.claude/settings.jsonか管理者設定に移す |
| disableAutoModeが有効 | 主な症状候補からautoが消えている、auto mode disabled by settingsと表示される | 確認方法管理者設定(managed settings)を確認する | 対処組織による制限なら管理者に確認する |
| feature-flag取得が停止 | 主な症状Pro・Max・Teamでも既定でautoにならない | 確認方法DISABLE_TELEMETRY等の環境変数を確認する | 対処該当の環境変数を外し、次のセッションを待つ |
| サーバー側の一時停止 | 主な症状上記のどれにも当てはまらない | 確認方法診断コマンドで設定エラーがないか確認する | 対処セッションを終了し、新しいセッションを開き直す |
設定ファイルの妥当性はclaude doctorでも確認できます。
claude doctorセッション内から実行できる/doctorは、設定の検査に加えて、Pro・Max・Team相当の環境でdefaultMode: "auto"をユーザー設定に加えることも提案します。
/doctorまとめ
Shift+Tabやdefaultモード設定からauto modeに入れないときは、バージョン・モデル・設定ファイルの置き場所・feature-flag取得・サーバー側の一時停止という5系統のどこかに当てはまっています。上から順にclaude --version、使用モデル、defaultModeの書き場所、環境変数を確認すれば、大半は自分の環境だけで解決できます。どれにも当てはまらないまま原因不明で使えない場合は、Anthropic側の一時的な判定を受けている可能性が高く、セッションを開き直して様子を見るのが妥当です。