Claude Codeを長く使っていると、前より指示を外す、必要なファイルを読まない、途中で作業を終えるように見えることがあります。
この記事が答える問いは、「Claude Codeの精度が落ちたと感じたとき、モデルの能力低下と決める前に何を確認すればよいか」です。
確認するのは、症状、発生時点、会話の圧縮、指示と接続、大きな出力、新しいセッションでの再現という6項目です。
この記事はこんな人向け
- 長いセッションの途中から回答や実装が雑になったと感じる
/compactの後に要件や禁止事項が抜けたように見えるCLAUDE.mdやSkills（定型手順を再利用する機能）を用意したのに指示が反映されない- MCP（外部ツールとの接続）を追加した後から、ツールを使わない、途中で省略する症状が出た
- 不具合報告やチーム共有の前に、再現条件をそろえたい
1. まず「精度が落ちた」を一文にする
「精度が落ちた」だけでは、次に何を調べるか決まりません。観測した症状を、他の人が確認できる書き方へ変えます。
| 症状 | 観測できる書き方 | 最初に確認すること |
|---|---|---|
| 誤答 | 既存実装を読まず、存在しないAPIを提案した | 読んだファイル、モデル、セッション状態 |
| 指示逸脱 | 変更禁止と伝えたファイルを書き換えた | CLAUDE.mdの読み込み、指示の競合 |
| 途中省略 | テスト前に完了と答えた | 会話の残量、ツールエラー、承認待ち |
| 古い前提 | 訂正済みの仕様を再び使った | 再開した会話、圧縮後に残った情報 |
| ツール未使用 | 検索やMCPを使わず推測で答えた | 接続状態、権限、利用できるツール |
| 再現しない失敗 | 同じ依頼でも成功したり失敗したりする | 固定できていない条件、実行回数 |
利用者からは、長いセッションで制約が抜けたという報告、再開後にMEMORY.mdの内容が失われたという報告、長いセッションで手順の後半が省略されたという報告があります。いずれも利用者報告であり、原因が確定した事例や、現在のすべての環境で起こる不具合を示すものではありません。
2. 発生時点と現在の状態を保存する
新しい会話を始める前に、症状が出た直後の状態を残します。
- Claude Codeのバージョンと選択したモデル
/contextで見える現在のコンテキスト（現在参照している会話・指示・ツール情報）- 作業ディレクトリとコミット
/compactの前か後か、再開した会話か- 直前に大きなログ、差分、検索結果を読んだか
- MCPやSkillsを追加・変更した直後か
- いつまでは期待どおりで、どの操作の後から変わったか
Claude Codeの公式デバッグ資料では、/context、/doctor、/hooks、/mcpを使って、読み込まれた設定や接続状態を確認できます。
ただし、/contextの表示だけでは、内部で各情報がどの程度重視されたかまでは分かりません。
3. 圧縮の前後で残った情報を比べる
/compactは、長い会話をそのまま全量保持する操作ではありません。圧縮後は、重要な要件が残ったか、必要なファイルを読み直したかを確認します。
| 確認するもの | 圧縮前 | 圧縮後 |
|---|---|---|
| 中心の目的 | 一文で説明できる | 同じ目的を説明できる |
| 禁止事項 | 回答に反映された | 同じ禁止を守る |
| 対象ファイル | 読んだ履歴がある | 必要なら読み直した |
下位のCLAUDE.md | 対象範囲で読まれた | 該当ファイルを読んだ後に反映された |
| 完了条件 | テストや確認まで含む | 省略されていない |
公式資料では、プロジェクト最上位のCLAUDE.mdは圧縮後に読み直され、下位ディレクトリのCLAUDE.mdは、その範囲のファイルを読んだときに読み込まれると説明されています。
内部の要約全文や、情報ごとの保持率を確認できない場合は、想像で補わず、目的・禁止事項・対象ファイル・完了条件を短く再提示します。
4. 指示ファイルとMCPが実際に読み込まれたか確認する
ファイルを置いたことと、その実行で読み込まれたことは別です。
- 現在の作業ディレクトリとプロジェクト最上位を確認する。
/contextで読み込まれた指示を確認する。/mcpで接続状態と利用できるツールを確認する。/doctorと/hooksで設定やフックの問題を確認する。- 短い目印となる指示を置き、対象範囲で読まれたことを確かめる。
MCPが「接続済み」でも、利用できるツールが0件なら使えません。また、下位の指示ファイルは、対象ファイルを読むまで読み込まれない場合があります。
5. 大きな出力と長い指示を減らす
長いログ、巨大な差分、多数のMCPツール、長い指示書を一度に入れても、必ず良くなるわけではありません。診断中だけ、次の順に小さくします。
- 巨大なツール出力を、要点と参照先へ置き換える。
- 今回使わないMCPサーバーやツールを対象から外す。
- 長い指示から、目的・禁止事項・完了条件を抜き出す。
- 必要なファイルを明示して読み直させる。
- 同じ症状が残るか確認する。
この最小化で症状が消えても、1回だけでは原因を確定できません。どの長さやツール数から悪化するかという共通の境界値も、タスクと版が違えば変わります。
6. 新しいセッションで同じ条件を再現する
現在のセッションだけを直し続けると、何が効いたか分かりません。履歴を保存してから、新しいセッションを作ります。
| 固定する条件 | 記録する内容 |
|---|---|
| 入力 | 実際に渡した依頼文 |
| コード | コミット、未保存の変更 |
| 実行環境 | Claude Codeの版、OS、シェル、作業ディレクトリ |
| モデル | 表示名、確認できる実体、別モデルへの切り替え |
| 指示 | CLAUDE.md、Skills、追加した依頼文 |
| ツール | MCP、フック、権限、承認設定 |
| 判定 | 期待する変更、禁止変更、テスト、確認手順 |
新しいセッションでは、同じ依頼文、同じコミット、同じ版、同じモデル、同じツールと権限を使います。回答だけでなく、読んだファイル、ツール履歴、差分、テスト、停止理由も比べます。
一度の改善だけで原因を決めない
新しいセッションで改善しても、それだけで「長い会話が原因だった」とは言えません。偶然の出力差、モデルの切り替え、更新、権限、作業状態の違いでも結果は変わります。
反復回数と合格条件を先に決め、一つの条件だけを変えます。再現した条件だけを原因候補にし、確認できない項目は「不明」と残します。
直らないときに残す記録
不具合報告やチーム共有では、次を残します。
| 項目 | 内容 |
|---|---|
| 症状 | 何が期待と違ったか |
| 発生時点 | 更新、圧縮、再開、MCP変更のどの後か |
| 期待結果 | 合格と判断する条件 |
| 環境 | Claude Codeの版、モデル、OS、シェル、コミット |
| 読み込まれた指示 | CLAUDE.md、Skills、その他の指示 |
| ツール | MCPの接続状態、利用できるツール、使用履歴 |
| 結果 | 回答、差分、テスト、停止理由 |
| 不明 | 取得できない情報と、それによって判断できないこと |
今回確認できた範囲
公開仕様から、/contextなどの診断コマンド、圧縮後のCLAUDE.mdの扱い、MCPの接続確認、大きなMCP出力への注意を確認できます。Anthropicは過去の品質問題で、モデル以外の設定やセッション状態が原因だった事例も報告しています。
一方、今回の調査ではClaude Codeを使った比較実行を行っていません。新しいセッションでの改善率、再現率、速度差、費用差は不明です。公開Issueと手元の症状が同じ原因かどうかも、版とログを照合するまで分かりません。
参考資料
- Claude Code：Manage Claude’s memory
- Claude Code：Debug your configuration
- Claude Code：Connect Claude Code to tools via MCP
- Anthropic：April 23 quality postmortem
- 利用者報告：長いセッションで制約が抜けた
- 利用者報告：再開後にMEMORY.mdの内容が失われた
- 利用者報告：長いセッションで手順の後半が省略された
上のIssueはいずれも利用者報告であり、原因が確定した一次資料ではありません。症状を比べる手掛かりとして使い、対象の版と実行記録で確かめます。
まとめ
Claude Codeの精度が落ちたと感じたら、最初にモデルの能力低下と決めないでください。
症状、発生時点、会話の圧縮、指示と接続、大きな出力、新しいセッションでの再現という6項目を順に確認します。履歴と成果物を残し、一つだけ条件を変えて比べると、体感を再確認できる問題へ変えられます。