Claude Codeのauto mode安全性判断エラー — 保留時の挙動と対処

auto mode cannot determine the safety of ...と表示されたら、auto modeの分類器モデルへのリクエスト自体が失敗し、判定を出せなかったという意味です。アクションが危険と判断されたわけではありません。読み取り・検索・作業ディレクトリ内の編集は分類器を経由しないため、この状態でもそのまま動き続けます。

auto mode安全性判断エラーとは何か

auto modeは、実行しようとするアクションごとに別モデル(分類器)へ安全性の判定を求めます。この判定リクエスト自体が失敗すると、Claude Codeはアクションを自動承認できず、次のようなメッセージを出します。

<model> is temporarily unavailable, so auto mode cannot determine the safety of <tool> right now. Wait a moment and then try this action again.

「危険と判定してブロックした」のではなく、「判定そのものが成立しなかった」という点が、通常のauto modeブロックとの決定的な違いです。分類器の判定ルール自体を知りたい場合はClaude Codeのauto mode分類器は何を止めているかで扱っています。

5つの失敗カテゴリ

Claude Codeが失敗の種類を特定できるときは、カッコ書きでカテゴリ名を添えます(v2.1.229以降。それ以前はカテゴリ名のないWait briefly and then try this action againという表示でした)。

カテゴリ名が付かない(無印の)表示は、複数の失敗が重なったときに出ます。Amazon Bedrockでは、アカウントが該当モデルを呼び出す権限を持たない場合にもこの無印表示が出て、権限が付与されるまでリトライのたびに再発します。

画面に出る3種類の「判定不能」メッセージ

分類器が判定を出せなかったときの表示は、失敗の仕方で3通りに分かれます。再試行が効くかどうかが違うので、文面で見分けるのが近道です。

<model> is temporarily unavailable, so auto mode cannot determine the safety of <tool> right now

Auto mode could not evaluate this action and is blocking it for safety — run with --debug for details

a safety check separate from auto mode blocked this request because of earlier conversation content

2つ目の「応答を読み取れない」型は、unavailableの型と違ってモデルは応答しています。ただ、その応答を判定として解釈できなかったため、念のため拒否しています。

サーバー側の分類器レビューで判定が返らないとき

Anthropic APIへの直結やクラウド(Bedrockなど)、LLMゲートウェイを通す経路では、判定をサーバー側で行う場合があります。直結の対話ターミナルではPro・Max・Teamでv2.1.271以降、クラウドとゲートウェイはv2.1.278以降が目安です。この経路で判定が返らないと、次のメッセージが出ます。

The server-side auto mode classifier gave no verdict (timed out), so auto mode cannot determine the safety of <tool>.

判定なしが10回連続すると、auto modeはそのターンを止めます。-pでは実行がエラーで終わります。サーバー側レビューでは個別の分類器呼び出しがないため、トークン加算の対象にもなりません。サーバー側レビューを使わない設定はCLAUDE_CODE_AUTO_MODE_SERVER=0です。

ブロックとの違い — しきい値に数えない保留と、公式が明言していない保留

auto modeは、分類器が3回連続または合計20回アクションをブロックすると、自動でプロンプト確認に切り替わります。この3回・20回は設定で変えられず、合計のカウンターはセッション中に持続して、自身のしきい値でフォールバックが起きたときだけ戻ります。

ここで数えない対象として公式が明記しているのは、auto modeとは別の安全チェックが分類器自身のリクエストを拒否した場合だけです。前述の3型のうち、3つ目がこれにあたります。モデル不可用型や応答不可読型の保留をしきい値に数えるかどうかは、公式のどのページにも書かれていません。「失敗による保留はしきい値と無関係」と読み替えると、書かれていない範囲まで断定することになります。

数え方が不明でも、運用で困る場面は多くありません。保留はアクションを実行せず、リトライか別作業への切り替えで先へ進めるためです。ただし、保留が続いたあとに確認プロンプトへ切り替わった場合、その保留がしきい値に数えられたのかどうかは公式の記述からは判断できません。切り替わったあとも、承認したアクションからauto modeは再開します。

応答を読み取れなかったときと、別の安全チェックが分類器のリクエストを拒否したときは、Claude Codeが記録を残さずにアクションを拒否します。そのため、/permissionsの「Recently denied」タブにも出ません。この保留がバースト状に連続する典型例はauto modeの分類器が応答不能になるとBashが止まる原因と回避策にまとめました。

分類器の既定ルールにもリトライの扱いがある

保留が出たあとにClaudeが同じコマンドを再実行しても、それ自体が回避行為と見なされることはありません。claude auto-mode defaults --label "Transient"を実行すると、v2.1.286の既定ルールに次の1件だけが出てきます(英語の原文を要約しています)。

Transient Retry: Retrying the same or a reformulated action after a transient failure
(network error, 5xx, timeout, rate-limit, lock contention) ... is NOT Auto-Mode Bypass.
The retried action is still evaluated against every other BLOCK rule ...
An obfuscated retry (encoding, indirection, renaming to evade the block) IS Auto-Mode Bypass.

要点は2つです。一過性の失敗後の再試行は、それだけでは「auto modeの回避」として扱われません。一方で、元のアクションがブロック対象だったなら、再試行も同じルールで止まります。エンコードや間接呼び出しで書き換えて通そうとする再試行は、回避行為として扱われます。保留とブロックを混同しないための線引きとして、この区別が役に立ちます。

同じコマンドで既定ルールの規模も確認できます。v2.1.286でclaude auto-mode defaultsを実行すると、allowが17件、soft_denyが72件、hard_denyが1件、environmentが21件でした。数字は版によって変わりうるため、手元の件数は自分の環境で実行して確かめてください。

会話内容が原因で分類器自身が拒否されるケース

やや紛らわしいパターンとして、会話に含まれる内容が原因で分類器へのリクエスト自体がAPI側の安全チェックに拒否されることがあります。

Auto mode could not evaluate this action and is blocking it for safety — a safety check separate from auto mode blocked this request because of earlier conversation content — it isn't about the action itself — run with --debug for details

この場合、Claude Codeはアクションを拒否しつつ「これはアクション自体への判断ではない」とClaudeに伝え、リトライではなく他の作業を続けるよう促します。リトライしても同じ会話内容が同じ理由で再びフィルタに引っかかるため、有効な対処ではありません。会話を新しく始めるか、対話セッションなら別の権限モードに切り替えて手動承認する必要があります。v2.1.225より前は、この種の拒否も通常のブロックと同じ扱いで再試行しきい値にカウントされていました。

分類器はどのモデルで動いているか

判定に使われる分類器は、既定では/modelで選んでいるモデルとは別に、Claude Sonnet 5が担当します。Anthropicがサーバー側で設定した分類器モデルがある場合はそちらが優先されます。セッションのモデルがClaude Sonnet 4.6のときや、availableModelsでSonnet 5が使えないよう制限されているときは、セッション自体のモデルが分類器としても使われます。このフォールバック先は、Fableモデル(5.1 / 5)で動いているセッションではセッションのモデルではなくOpusモデルになります。Anthropic API以外のプロバイダーでは、そのOpusはANTHROPIC_DEFAULT_OPUS_MODELに設定したモデル、未設定ならOpus 5です。

セッション内で最初にauto modeの判定リクエストを送った時点で、このSonnet 5既定が実際に使えるかどうかが確定します。成功すればセッションを通してSonnet 5が分類器として使われ続け、モデルが利用できなかった場合はフォールバック先に切り替わります。一度確定した分類器モデルは、そのセッションの間は変わりません。初回リクエストでモデルが使えなかった場合は、保留ではなくフォールバック先の分類器に切り替わります。

分類器の呼び出しは、Enterpriseプランでトークン使用量に加算されます。Claude API・Claude Platform on AWS・Bedrock・Google Cloud・Foundryのアカウントでも同じです。1回のチェックは会話の一部と実行予定のアクションを送るため、実行前に往復1回分のレイテンシが加わります。読み取りと作業ディレクトリ内の編集は分類器を経由しないため、負荷が乗るのは主にシェルコマンドとネットワーク操作です。

サブエージェントでの分類器チェック

Sub-agentsを使っている場合、分類器は3つの時点でサブエージェントの作業を確認します。

会話がコンテキストウィンドウを超えたとき

分類器が読む会話の分量には上限があります。超えると次のメッセージとともに、対話セッションでは手動承認プロンプトへフォールバックします。

Auto mode classifier transcript exceeded context window — falling back to manual approval (try /compact to reduce conversation size)

対話セッションなら、そのアクションはプロンプトで承認か拒否を選びます。/compactで会話量を減らせば、以後のアクションは再び分類器の対象に戻ります。

非対話モード(-p)での挙動

--permission-prompt-toolを指定していない非対話実行では、承認を求めるプロンプト自体がありません。--input-format stream-jsonなしの-p実行で、バックグラウンドのSub-agentsに委譲したタスクがこの失敗に当たると、エラー結果が返ります。文面はAgent aborted: auto mode classifier request refused by the safety safeguard in headless modeのような形です。それ以外の場所では、メインの会話にそのまま拒否が伝わります。サーバー側の判定なしが10回続いた場合を除き、実行は止まらず続きます。しきい値に達した通常のブロックでも同様で、非対話モードのランはそこで停止しません。

何をすればよいか

• 数秒待ってからもう一度同じアクションを試す(Claude自身が自動的に再試行することが多い)
• リトライが失敗し続けるなら、読み取り専用の作業を先に進めて後で戻る
• Amazon Bedrockで無印表示が続く場合は、対象モデルを呼び出せるIAMポリシーになっているか確認する
• OAuthトークンの期限切れが原因のときは自動で再取得・再試行されるため、通常は何もしなくてよい(v2.1.216以降)

auto modeの既定化や有効化条件そのものを確認したい場合はClaude Codeのauto mode既定化で確認したい設定、Bedrock・Vertex・Foundryでの有効化手順はCLAUDE_CODE_ENABLE_AUTO_MODEとはにまとめています。

よくある質問

rm -rfのような危険な操作もこの保留の対象になりますか

rm・rmdirでcritical path(/や~など)を消すコマンドは、既定では分類器を通りません。auto modeではターミナルに2分のカウントダウン付きの確認が出て、答えなければ拒否されます。-pやVS Code拡張のチャットパネルなどプロンプトを出せない場所では、即座に拒否されます(v2.1.281以降)。そのため、この保留の対象にはなりません。

このエラーはどの権限モードでも出ますか

分類器を使うのはauto modeと、plan mode中に分類器がコマンドを判定する設定を有効にしている場合です。Manual・acceptEdits・dontAsk・bypassPermissionsモードでは分類器そのものを使わないため、このエラーは出ません。

判定チェックの途中で権限モードを切り替えるとどうなりますか

分類器のチェックが保留になっている最中に権限モードを切り替えると、新しいモードでは要求しなかったはずの判定結果はそのまま破棄されます。切り替え後のモードに応じて、改めてプロンプトで確認を求められるか、dontAskモードなら自動的に拒否されます。

まとめ

文面に「separate from auto mode」が含まれていれば、リトライせず会話を新しくするか、別の権限モードで手動承認します。それ以外はまずリトライで、繰り返すときはカテゴリ名とBedrockの権限を見ます。