Claude Codeの/doctorで環境を診断、不要なスキルと古い指示を整理

Claude Codeが以前より遅く感じたり、精度が落ちたように見えたりするとき、原因はモデルそのものではないかもしれません。モデルの上に積み重ねたものすべてが原因である可能性があります。Anthropicは、モデルがタスクの前に毎回読む常設の指示であるClaude Codeのシステムプロンプトを80%以上削っても、コーディングのベンチマークで測定できるほどの低下はなかったとしています。同じ考え方は自分の環境にも当てはまります。古いルール、使っていないスキル、ほかのフォルダーから紛れ込む指示ファイルは、どれもセッションのたびに一緒に読み込まれます。組み込みの/doctorコマンドを使えば、こうした重荷を素早く見つけ、何を外すかを判断できます。

指示を減らしても結果が悪くならなかった理由

以前のモデルは指示しないと冗長になりがちだったため、システムプロンプトにはコメントの長さを厳しく制限するような、強い禁止ルールが数多く含まれていました。Opus 5、Fable 5、Fable 5.1といった新しいモデル向けに、Anthropicはこうしたガードレールを取り除きました。長いコメントに関するルールは、周囲のコードに合わせてコメントの密度、命名、書き方をそろえ、自分で判断せよという1行に置き換えられました。より強力なモデルはすでに優れた判断力を備えており、硬直したルールはむしろその妨げになるという考え方です。

Claude Codeを生み出したボリス・チャーニーはさらに踏み込みます。コーディングエージェントを使う開発者に対し、6カ月ごとにCLAUDE.mdファイル、スキル、フックを削除し、新しいモデルが自力で何をこなせるようになったかを確かめるよう勧めています。ここで指摘されている問題は「指示の負債」と呼べるものです。過去の一度のミスをきっかけに追加したルールが、モデルの更新で不要になった後もずっと有効なまま残っている状態です。ブランディングのミスの後でCLAUDE.mdに追加した「青だけを使う」といったルールが典型例です。

コンテキストは多ければ多いほどよいというわけでもありません。5つのモデルを対象にした2025年の研究では、必要な情報がすべてコンテキストウィンドウ（モデルが一度に読み込めるテキストの量）に収まっていても、入力が長くなるほど数学、質問応答、コーディングの性能が13.9%から85%低下しました。これは1年半以上前のモデルを使った統制実験なので、個人のCLAUDE.mdを削った場合に同じ数値がそのまま当てはまるとは限りません。

Anthropicは同じ考え方をツールにも適用しました。すべてのMCPツール定義を最初から読み込むのではなく（MCP、つまりModel Context Protocolは、AIモデルを外部のツールやデータにつなぐ標準規格です）、Claude Codeはツール検索ツールを使い、必要になったときにだけ定義を探せます。

トークン使用量は85%減り、精度は下がるどころか上がりました。

▲ 必要なときだけ読み込むツール

渡す情報は少なく、ただし大事なものは残す

AnthropicのApplied AIチームは、期待する振る舞いを過不足なく規定できる最小限の情報を目指すよう勧めています。最小限とは、必要な技術的詳細まで省くという意味ではありません。削るべきなのは手順を一つひとつ細かく指図する部分であり、残すべきなのはモデルが推測したり調べたりできない事実です。簡単に言えば、最良のコンテキストとは、最も低いコストで最良の結果を生む最小の量のことです。

いまのモデルにタスクを任せるときは、通常次の3つで十分です。

• 成果：「完了」とはどういう状態か
• 理由：なぜそれをするのか
• 制約：守らなければならない条件

理由を伝えることは、思っている以上に重要です。ある比較では、インタビューの書き起こしを2通りの方法で学習用ガイドにしました。書式ルール、ブランドテンプレート、リンクのルール、構成の指示を細かく指定した設定では、ブランド入りの見出しを備えた見栄えのよい文書ができました。一方、ガイドが学生向けであることだけを伝えた最小限の設定では、内容の構成がよりよく、技術的な説明がより詳しく、タイムスタンプも正確でした。意図を伝えると、Claudeはたとえ、直感的な説明、身近な例を自ら選んで使うようになります。見栄えのよさは、構成の弱さを覆い隠してしまうことがあるようです。

だからといって、背景情報をすべて消す必要はありません。文体、戦略上の目標、対象読者のようにその仕事に固有のコンテキストは残す価値があり、硬直した手順チェックリストは試したうえで削る価値があります。動画編集のルールのように特定の作業にだけ必要な詳細手順は、台本作成中ではなく、その作業をしているときにだけ読み込むべきです。よいCLAUDE.mdは短く保たれています。プロジェクトの目的、主な落とし穴、そして必要なときにだけ読む詳しい指示ファイルの場所を示すだけです。

/doctorが見つけるもの

Claude Codeで/doctorを実行すると、設定、プラグイン、MCPサーバー、スキル、メモリー、インストールパスにわたる10項目の読み取り専用チェックが始まります。レポートには、スキルごとのスコープ、インストール後の使用回数、推定の常駐トークン数、そして削除などの推奨判定が一覧で示されます。Claude Codeはスキルを登録する際、ファイル全体ではなく、スキルファイル冒頭の短いヘッダーであるYAMLフロントマターだけを読み込みます。それでも、登録されたスキルはどれもセッションのたびに一定のトークンを消費します。

実際の作業環境を1つ監査したところ、次のような結果が出ました。

35トークンの節約は取るに足らないように聞こえますが、長いセッションでは小さな無駄がすぐに積み重なります。使われていないスキルは削除しなくても、ローカルの設定ファイルで無効にできます。チェックが終わると、/doctorはすべて適用するか、項目を選ぶか、すべて残すか、カスタマイズするかを尋ねます。自動で提案された削除をうのみにせず、承認する前に一覧を確認しましょう。

▲ Claude Code環境の健康診断

設定だけでなくワークフローも監査する

同じやり方はワークフロー全体にも使えます。動画の台本作りに使うあるリポジトリーで、Claude Codeに対し、アイデアの段階から撮影できる台本までの流れを速くする最小の変更を示すよう依頼しました。既存の仕組みを再利用し、関係するファイルを正確に挙げ、まだ何も編集しないという条件付きです。

その結果、アウトラインを作るスキルと台本を書くスキルが、それぞれ一次資料のファクトチェックを別々に実行していることが分かりました。25のプロジェクトフォルダーのうち、調査内容を記録する標準のsources.mdファイルがあったのは3つだけで、調査結果が次の工程に引き継がれていませんでした。Claudeは2つのスキルにまたがる3カ所の修正を提案しました。アウトライン作成の段階で根拠をsources.mdに保存し、台本作成の段階では再調査せずにそのファイルを読むという内容です。工程間の受け渡しが標準化されていないと、同じチェックや呼び出しが繰り返されがちです。

まとめ：定期的に、そしてモデルを替えるたびに監査する

Claude Codeをもっと活用するには、指示を足すより減らすほうが効くことが少なくありません。実践的な手順は次のとおりです。

1. プロジェクトで/doctorを実行し、使われていないスキル、壊れたフロントマター、親フォルダーから紛れ込むCLAUDE.mdファイルを探します。
2. 見つかった項目を一つずつ確認し、使っていないスキルを無効にし、コロンを含むフロントマターの値を引用符で囲みます。
3. 過去のミスのために追加したCLAUDE.mdのルールを削除し、重複した案内をまとめ、作業ごとの手順は別ファイルに移します。
4. 仕事を任せるときは成果、理由、制約を伝え、構成はモデルに提案させます。
5. 設定を頻繁に変えるなら毎月、安定しているなら四半期ごとに監査し、メインのモデルを切り替えたときはすぐに監査します。モデルごとに指示の読み取り方が異なるためです。

/doctorと広範な監査をバックグラウンドタスクとしてスケジュールし、ワンクリックで承認できる推奨事項を表示させることもできます。個人のAI環境が劣化する最も一般的な理由は手入れが続かないことなので、この習慣を人の手から切り離すほうが長続きしやすいと考えられます。