Claude Code で「CLAUDE.md に書いたルールが反映されない」「hooks が発火しない」といった不具合に遭遇すると、原因の切り分けは思いのほか厄介だ。設定は managed・user・project・local の4スコープに分かれており、どこかで上書きされているケースが少なくない。この状態を一発で可視化してくれるのがスラッシュコマンド /doctor で、仕様は公式ドキュメント「Debug your configuration」にまとまっている。
/doctor が見ているもの
セッション中に /doctor を実行すると、次の項目を検証する。
- 設定ファイルの無効なキー
- JSONスキーマのエラー
- インストールの健全性
- （v2.1.196以降）同一スコープ内で重複したサブエージェント名と、どちらが使われているかの表示
典型例が hooks の matcher を配列で書いてしまうミスだ。本来は "Edit|Write" のような単一の文字列で指定する必要があり、配列にするとスキーマエラーとなってフックごと無効化される。こうした間違いはユーザー自身では気づきにくいが、/doctor はスキーマ違反として検出してくれる。
見つけた問題をその場で直す「f」キー
/doctor が問題を検出した際は、f キーを押すと診断レポートがそのまま Claude に送られ、対処法の提示までつながる。エラーメッセージをコピーして検索する手間がなく、設定ファイルの場所も同時に渡るため、Claude 側も的確に修正しやすい。トラブルシューティングを「読む→調べる→直す」から「押す→直る」まで縮めた点に、このコマンドの実質的な価値がある。
claude doctor（CLIコマンド）は別物
紛らわしいが、ターミナルから直接実行する claude doctor は、セッション内の /doctor とは役割が異なる。ヘルプには次のように説明されている。
Usage: claude doctor [options]
Check the health of your Claude Code auto-updater. Note: The workspace trust
dialog is skipped and stdio servers from .mcp.json are spawned for health
checks. Only use this command in directories you trust.
こちらは自動アップデーターの健全性を確認するのが主目的で、実行時には .mcp.json に登録された stdio サーバーが実際に起動する。ヘルプが「信頼していないディレクトリでは実行しないように」と注意しているのはそのためだ。ログインが通らない場合（macOS の Keychain ロック絡みなど）のトラブルシューティングにも登場する。名前は同じでも中身は別物なので、使う際は「セッション内の /doctor」と「ターミナルの claude doctor」を区別しておく必要がある。
似たコマンドとの使い分け
設定まわりの診断コマンドは /doctor のほかにも複数あり、公式ドキュメントの一覧がそのまま使い分けの目安になる。
| コマンド | 見られるもの |
|---|---|
/context | コンテキストウィンドウの中身全体（システムプロンプト・メモリ・スキル・会話） |
/memory | 読み込まれた CLAUDE.md とルールファイル、自動メモリ |
/hooks | 現在有効なフック設定 |
/mcp | MCPサーバーの接続状態 |
/permissions | 現在有効な許可・拒否ルール |
/status | 有効な設定ソース（managed設定が適用されているか等） |
/doctor | 設定ファイルの妥当性・スキーマエラー・インストール健全性 |
「機能が読み込まれているか」を確認したいなら /context や /memory、「なぜ反映されないのか」を確認したいなら /doctor、という役割分担になる。
使いどころ
Claude Code の挙動がおかしいと感じたら、まず /status で有効な設定ソースを確認し、次に /doctor で設定ファイル自体の妥当性を疑う。それでも解決しない場合は claude --safe-mode（v2.1.169以降）でカスタマイズを全て無効化して起動し、問題が再現するかどうかを見る、というのが公式が推奨する順序だ。設定は積み重なるほど「どこかがおかしい」状態に陥りやすいため、/doctor は定期的に実行しておいて損はない。
参考
この記事は Claude Sonnet 5 が執筆しました。