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では、アカウントが該当モデルを呼び出す権限を持たない場合にもこの無印表示が出て、権限が付与されるまでリトライのたびに再発します。

ブロックとの違い — 保留は再試行回数にカウントされない

auto modeは、分類器が3回連続または合計20回アクションをブロックすると、自動でプロンプト確認に切り替わります。しかし分類器リクエストの失敗による保留は、このしきい値にカウントされません。安全性を「不明」と判断しているだけで、「危険」と判断したわけではないためです。

保留になったアクションは/permissionsの「Recently denied」タブにも出ません。分類器の応答がパースできなかったときや、別の安全チェックが分類器自身のリクエストを拒否したときは、通知すら出さずに静かに拒否されます。

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

やや紛らわしいパターンとして、会話に含まれる内容が原因で分類器へのリクエスト自体が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で動いているセッションではOpusモデルが分類器を担当し、Anthropic API以外のプロバイダーではそのプロバイダーの既定Opusモデルが使われます。

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

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

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

Sub-agentsを使っている場合、分類器は3つの時点でサブエージェントの作業を確認します。まずサブエージェントが起動する前に、委譲されたタスクの説明そのものを評価し、危険そうなタスクは起動時点でブロックします。次にサブエージェント実行中は、その1つ1つのアクションが親セッションと同じルールで分類器を通ります。最後にサブエージェントが完了すると、分類器はその全アクション履歴を再確認し、懸念が見つかれば結果に警告を付け加えます。この返却時チェックのリクエスト自体が別の安全チェックに拒否された場合でも、Claude Codeはサブエージェントの結果をそのまま返します。ただし「未レビューであり信用できないものとして扱うべき」という警告が添えられます。起動前のタスク説明チェックはClaude Code v2.1.178以降が必要で、それより前のバージョンでは実行中と完了時の2点だけが対象でした。

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

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

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

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

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

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

何をすればよいか

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

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

よくある質問

保留が続くとauto mode自体が止まりますか

止まりません。分類器リクエストの失敗による保留は、通常のブロック回数のしきい値(3回連続・合計20回)にカウントされません。そのため保留が何度続いても、それ単独でauto modeがプロンプト確認モードへ切り替わることはありません。

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

rm・rmdirによるcritical pathへの削除は分類器の判定対象ですが、判定が保留になっても許可はされません。保留は「安全と確認できない」状態であり、既定で拒否側に倒れます。

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

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

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

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

サブエージェントの結果に警告が付いていたら何を疑えばよいですか

サブエージェント完了時の分類器チェック自体が失敗し、結果が未レビューのまま返された可能性があります。この場合Claude Codeはサブエージェントの作業結果自体は返しますが、内容を信用しきらず、必要な操作は自分で確認してから先に進めるのが安全です。

まとめ

auto mode安全性判断エラーは、アクションが危険だからではなく、分類器への判定リクエストが一時的に失敗したために出ます。ほとんどは数秒後のリトライで解消し、この種の保留はauto modeの通常のブロックしきい値とは別枠で扱われます。