Claude Media
Claude Codeの応答品質が落ちたときの確認手順

Claude Codeの応答品質が落ちたときの確認手順

Claude Codeの応答が急に鈍く感じたときに疑う5つの原因と、/model・/effort・/context・/doctor・/rewindでの切り分け手順をまとめます。

Claude Codeの応答が急に鈍く感じても、エラーは何も出ていない。そういうときの原因は、モデルそのものの劣化より会話の状態にあることがほとんどです。Claude Codeはエラーも通知も出さずにモデルを切り替えることはありません。原因は主に5つに絞れます。フォールバックモデルへの切り替わり、意図しないモデル指定、思考の深さの設定、コンテキストウィンドウの圧迫、CLAUDE.mdやMCPツール定義の肥大化です。

この記事では、公式のトラブルシューティング手順に沿って、この5つを1つずつ確認するステップと、それでも改善しないときの報告方法までをまとめます。

Claude Codeがモデルを勝手に切り替える3つのケース

結論から言うと、Claude Codeが応答中にエラーも通知も出さずにモデルを切り替えることはありません。ただし、次の3つのケースに限りフォールバックモデルへ切り替わることがあり、これが「急に質が落ちた」と感じる最大の原因になります。

発生源何が起きるか気づき方
--fallback-modelフラグ何が起きるか可用性エラーの直後、その1ターンだけ指定した代替モデルで応答する気づき方トランスクリプトに通知が出る
Bedrock/Google Cloud's Agent Platformの起動チェック何が起きるか既定モデルが利用不可のとき、起動時に別モデルへ切り替える気づき方/modelの表示で気づける
自動モデルフォールバック何が起きるかFable 5・Opus 5でフラグの立ったカテゴリーに、そのカテゴリー用の代替モデルがある場合に切り替える気づき方トランスクリプトに通知が出る

3つ目の自動フォールバックと2つ目の起動チェックは、後述の/model確認で気づけます。1つ目の--fallback-modelはそのターンのトランスクリプト内の通知でしか分からず、/modelには反映されません。まず自分がこのいずれかの経路を使う設定をしていないか、思い出すところから始めます。自動フォールバックと起動チェックによる切り替えは、その1ターンでは終わらず、セッションが続く間は代替モデルのまま応答が続きます。元のモデルに戻すには/modelで明示的に選び直す必要があります。

なぜ最初のメッセージから自動フォールバックが起きるのか

自動モデルフォールバックは、何か危ういプロンプトを送った直後に起きるとは限りません。Fable 5とOpus 5はサイバーセキュリティと生物学の安全分類器を組み込んでおり、セッション最初のリクエストにはCLAUDE.mdの内容やgitステータスといった作業環境の情報が自動で含まれます。セキュリティ関連やバイオ関連のコードベースを開いただけで、この文脈だけが分類器に引っかかり、何も送っていないのにフォールバックが起きることがあります。

原因がプロンプト自体ではなく作業環境側にあるかを切り分けたいときは、claude --safe-modeで起動します。CLAUDE.md・skills・MCPサーバー・hooksといったカスタマイズを一切読み込まずに起動するモードで、gitステータスとディレクトリー名は引き続き含まれます。この状態でも同じフォールバックが起きるなら、原因はプロンプトの文言そのものにある可能性が高くなります。

claude --safe-mode

切り替わり自体を毎回自分で判断したい場合は、/configで「Switch models when a message is flagged」をオフにするか、設定ファイルのswitchModelsOnFlagfalseにします。フラグが立ったリクエストはその場で一時停止し、フォールバックモデルへ切り替えるか、プロンプトを編集して同じモデルで再試行するかを選べるようになります。生物学関連の分類器にはOpus 5用のフォールバック先が無いため、この設定をオンにしていてもOpus 5でのバイオ関連フラグはそのまま拒否で終わります。

カテゴリー別のフォールバックはv2.1.219以降の挙動です。それより古いバージョンでは、フラグの立ったFable 5のリクエストはすべて利用中プロバイダーの既定Opusモデルへ再実行されており、Opus 5自体はフォールバック元になっていませんでした。古いバージョンで検索した情報と手元の挙動が食い違う場合は、まずclaude updateでこの差を疑うとよいでしょう。

手順1: /modelと/effortで使用中の設定を確認する

/modelを引数なしで実行すると、現在のモデルが分かります。以前に/modelで選んだ結果や、シェルに残ったANTHROPIC_MODEL環境変数が原因で、意図より小さいモデルのまま作業していることがあります。

/model

思考の深さも見逃されがちです。/effortで現在の推論レベルを確認し、難しいデバッグや設計作業なら上げます。既定値はモデルによって違うため、最大値だと決めつけず先に確認します。

/effort

ANTHROPIC_MODEL環境変数は.zshrcなどに残ったまま忘れられていることが多く、モデルの取り違えの典型パターンです。この変数でモデルを固定する具体的な方法と優先順位はANTHROPIC_MODEL環境変数でモデルを固定する方法にまとめました。環境変数全体の一覧はClaude Code環境変数リファレンスを参照してください。指定したモデル名自体が誤っている場合は、最初のリクエストで別のエラーとして表れます。詳しくは「is not a recognized model id」の意味と対処を参照してください。

手順2: /contextと/doctorでコンテキストの圧迫を確認する

会話が長くなり、コンテキストウィンドウが埋まってくると、応答の質が落ちたように感じられます。/contextを実行すると、ウィンドウの使用状況が分かります。埋まっているなら、区切りのよいところで/compactを実行するか、/clearで会話をリセットします。

/context

コンテキストを圧迫する原因は会話の長さだけではありません。肥大化したCLAUDE.mdや、大量のMCPツール定義もコンテキストを消費し、応答の方向性に影響します。/doctorを実行すると、肥大化したメモリーファイルや使われていない拡張機能を検出できます。/contextではMCPツールが消費しているトークン量も確認できます。コンテキスト管理の考え方全体はClaude Codeのコンテキスト管理にまとめています。

/doctor

手順3: 訂正よりも/rewindでやり直す

応答が的外れだったとき、そのままスレッド内で訂正を重ねると、間違った応答が会話履歴に残り続けます。以降の応答がその間違いに引っ張られる形になり、質の低下がさらに進んだように感じられます。

Escキーを2回押すか/rewindを実行すると、そのセッションで送った各プロンプトの一覧がメニューに出ます。狙った時点を選ぶと、「コードと会話をまとめて戻す」「会話だけ戻す(コードは現状維持)」「コードだけ戻す(会話は現状維持)」「以降を要約して圧縮する」から選べます。応答の質だけを立て直したいなら、ファイルの変更はそのままに会話だけを戻す選択肢が使えます。訂正するより、具体的な指示を添えて聞き直すほうが、後続の応答が安定します。この機能の使い方はClaude Code rewindコマンドで/clear前まで戻るで詳しく扱っています。

それでも改善しないときは/feedbackで報告する

ここまでの確認で原因が見当たらないなら、/feedbackを実行し、期待していた応答と実際の応答の違いを具体的に書きます。この方法で送る報告には会話のトランスクリプトが含まれるため、Anthropicが実際の品質低下を診断する手がかりとして最も速く届きます。/feedbackが使えない環境では、エラー報告の手順に従います。

/feedback

よくあるつまずき

プロンプトインジェクション警告を品質低下と勘違いする。Claude Codeが自動的に会話へ追加した文脈(ファイルやWeb由来ではないもの)に対して疑わしいインジェクションの警告や拒否が出た場合は、claude updateで最新版にしてから再試行します。繰り返し出るなら、警告の対象になったテキストをプロンプトへ貼り直さず、そのまま報告します。

--fallback-modelの切り替えを/modelで確認しようとする。このフラグによる切り替えは1ターン限りの一時的なもので、/modelの表示には反映されません。トランスクリプト内の通知を探すのが唯一の確認方法です。

effortの既定値を全モデル共通だと思い込む。モデルごとに既定の推論レベルが違うため、「いつもより浅い」と感じたら/effortで実際の値を確認してから、上げる・下げるを判断します。

まとめ

Claude Codeの応答が鈍く感じるとき、原因の多くはモデルの劣化ではなく会話の状態にあります。/model/effortで設定を確認し、/context/doctorでコンテキストの圧迫を確認し、訂正よりも/rewindでやり直す。この順番で潰していけば、たいていの原因は特定できます。それでも解決しないなら/feedbackでトランスクリプトごと報告するのが、実際の回帰を突き止める最短経路です。

よくある質問

effortを上げると常に応答は遅くなりますか

思考量が増えるぶん応答時間は伸びる傾向がありますが、難しい設計判断やデバッグでは正確さが優先されます。単純な作業では既定値のままのほうが速く済むこともあるため、作業内容に応じて/effortで都度調整するのが実用的です。

フォールバックモデルへの切り替わりをログで確認できますか

--fallback-modelフラグによる切り替えと自動モデルフォールバックは、いずれもそのセッションのトランスクリプト内に通知が記録されます。Bedrock・Google Cloud's Agent Platformの起動チェックによる切り替えは、/modelの表示で分かります。

CLAUDE.mdの分割は/doctorが自動でやってくれますか

/doctorはCLAUDE.mdの肥大化を検出して知らせるところまでで、分割作業自体は手動です。検出された場合は、頻繁に参照する内容だけを残し、参照頻度の低い情報を別ファイルに切り出すと、コンテキストの消費を抑えられます。

訂正を重ねてしまった後でも/rewindは使えますか

使えます。/rewind/clearより前の会話であれば、間違った応答を含むやり取りをまとめて巻き戻せます。訂正を重ねた後ほど、修正するより最初の的外れな応答の直前まで戻って聞き直すほうが早く済むことが多くなります。

この記事を共有:XはてブLinkedIn