結論：/doctor prompt-auditで検出し、修正は差分と実行結果をレビューする
Claude Code 2.1.283では、/doctor prompt-auditまたは/checkup prompt-auditで、CLAUDE.md、Skills、agents、commandsに残る古いmodel向けのprompting patternを棚卸しできます。実行したら、stale path、古いcommand、矛盾する指示、thinkingに関する語句を結果ごとに分け、いきなり一括修正しないでください。監査は変更の候補を見つける工程、修正は業務責任者と開発者が承認する工程です。
この機能は、モデル更新後に「以前は必要だった指示が残っている」「projectのCLAUDE.mdと個人の指示が衝突する」「Skillの説明が古いpathを示す」といった課題に向きます。プロンプトの短縮や品質向上率を自動で保証するものではありません。変更前後の代表タスク、permission、tool呼び出し、テスト結果を同じ条件で比較します。
一次情報はClaude Code公式changelogとsettings公式文書です。前者は2.1.283のprompt-auditが対象とするCLAUDE.md、Skills、agents、commandsと、stale path・stale command・矛盾するinstructionを優先する改善を記載しています。後者は設定scopeと読み込み関係の正本です。指示ファイルを一つの巨大な正本へ集約する記事ではなく、監査と変更管理の手順に限定します。
監査対象とレビュー対象を比較する
| 対象 | 見つけたい問題 | 修正前の確認 |
|---|---|---|
| CLAUDE.md | 古いcommand、path、矛盾するproject方針 | scope、対象repository、現行の実行手順 |
| Skills | 旧modelを前提にした説明、古い参照先 | 発動条件、権限、tool、利用者 |
| agents / commands | 不要な手順、現行仕様と違う要求 | 呼び出し元、出力契約、停止条件 |
監査結果に「古い」と出ても、すぐに削除できるとは限りません。例えば、厳密な出力形式、社内用語、承認前に編集しないルールは、model更新とは別の業務要件です。一方、存在しないscript path、旧CLI option、過去のmodel専用の思考指定は、実行失敗や誤解を生みます。検出結果を、削除候補、要確認、維持の三つへ分類します。
設定scopeも重要です。managed settings、command line、project local、shared project、userの順序を把握しないと、projectの修正が全利用者へ反映されたと誤認します。逆にmanaged側の指示を下位設定で打ち消せる前提にすると、組織ポリシーの説明が崩れます。変更票には対象fileと適用scopeを必ず書きます。
prompt-auditを安全に回す8手順
- 対象repositoryを固定する。ルートdirectory、branch、Claude Codeのversion、実行者を記録します。
- 変更前の状態を保存する。CLAUDE.md、Skills、agents、commandsのcommitまたはhashと、代表タスクの結果を保存します。
- 読み込み範囲を確認する。project、user、managedのscopeを一覧にし、意図しない個人設定が混ざらない環境で実行します。
- 監査を実行する。対話セッションで
/doctor prompt-auditを使うか、同等の/checkup prompt-audit入口を使います。 - 問題を分類する。stale path、stale command、contradicting instruction、旧model向けpattern、thinking関連語句を別の行へ分けます。
- 影響を確認する。対象のSkillやagentを呼ぶtask、必要なtool、permission、出力形式、CIの呼び出し元を調べます。
- 最小差分を作る。一度に全ファイルを言い換えず、不要な一文の削除、pathの更新、矛盾の解消を別commitまたは別patchにします。
- 同じfixtureで再実行する。監査結果、diff、代表task、テスト、permission log、停止条件を比較し、承認後に共有branchへ反映します。
結果を変更へ移すチェックリスト
- 2.1.283の実行versionと対象branchを記録した。
- 対象fileのscope、owner、reviewer、最終更新日がある。
- 監査結果をstale、矛盾、業務固有、維持へ分類した。
- 旧model向けの文言を削除する前に現行modelと代表taskを確認した。
- 変更は最小差分で、permissionとtoolの影響を見た。
- 同じ入力で変更前後の出力とテストを比較した。
- ロールバックできるcommit、停止条件、利用者告知を用意した。
監査の価値は、警告の件数をゼロにすることではありません。残すべき社内用語や安全ルールまで削除すると、別の事故を招きます。結果の各行に「現行仕様との不一致」「実行不能」「重複」「意図した制約」の理由を付け、修正しない項目も明示します。こうすると、次回のmodel更新や担当者交代の際に、判断を最初からやり直さずに済みます。
共有する監査レポートには、秘密情報、個人情報、未公開repositoryの内容をそのまま含めないでください。file名と行、問題の種類、再現task、承認状態に絞り、原本へのアクセス権を分けます。修正後は、成功した例だけでなく、権限が必要な操作、存在しないpath、外部toolを使う操作が期待どおり停止するかも確認します。
新しいmodelへ移行する場合は、監査を移行作業の最後に置かず、候補の指示を決める前に実行します。古い指示が残ったまま評価すると、modelの差ではなくpromptの差を測ることになるためです。監査レポートのcommitと評価レポートのrun IDを相互リンクし、変更理由を追跡できる状態にします。
よくある質問と次の行動
毎日prompt-auditを実行すべきですか？
更新、model切替、Skills追加、運用ルール変更のタイミングが中心です。頻度より、同じ対象範囲と結果保存を守ることが重要です。
監査結果をAIに自動修正させてもよいですか？
提案生成までは可能でも、削除・権限・外部送信へ影響する変更は人間レビューを通します。特にmanagedやshared projectのファイルはowner承認を分けてください。
指示が増えすぎているか判断できません。
代表業務の完了条件、失敗時の停止、必要な承認を先に書き、重複する説明を比較します。Miraigentの無料診断では、指示・権限・評価を業務単位で棚卸しできます。
project指示の整理はAGENTS.mdの運用ガイド、権限の境界はClaude Code権限設定ガイド、組織設定の結果監査はmanaged settingsのOTelガイドも参照してください。Miraigentの無料診断で、監査結果を変更管理へつなぐ最小単位を決められます。