Claude Code v2.1.283:古いAI指示を棚卸しする

古い指示の一覧から確認済み項目を選別する監査フローの抽象図

AIへの指示は、書いた日から少しずつ古くなります。以前のモデルでは必要だった「必ず段階的に考える」「この形式で毎回報告する」といった一文が、新しいモデルでは冗長になったり、別の指示と衝突したりする。ところが、CLAUDE.md、スキル、エージェント定義、コマンドを横断して点検する仕事は後回しになりがちです。

Claude Code v2.1.283に追加された/doctor prompt-auditは、その棚卸しを始めるための機能です。同じ更新では、利用可能なモデルを版まで固定するavailableModelsMatch: "exact"と、特定モデルを止めるdeniedModelsも追加されました。指示とモデルを別々に管理せず、「どのモデルに、どの指示を読ませるか」を一組で見直せる更新です。

v2.1.283で確認できる変更

Anthropicの公式リリースでは、/doctor prompt-audit(別名/checkup prompt-audit)が、CLAUDE.md、スキル、エージェント、コマンドを対象に、古いモデル向けの指示パターンを監査すると説明されています。改善項目として、古いパス、古いコマンド、矛盾する指示ファイルを先に示すことも明記されました。

モデル管理には二つの追加があります。availableModelsMatchをexactにすると、許可リストに書いた版だけを利用でき、新版は管理者が追加するまで止まります。deniedModelsは、許可リストに含まれる範囲からでも特定モデルを拒否できます。

ここは役割が違います。prompt-auditは指示の品質を調べる診断です。モデル制限は実行を止める管理設定。診断結果を読んでも、設定は自動で直りません。反対にモデルを固定しても、矛盾したCLAUDE.mdが良くなるわけではありません。

指示書は増えるほど強くなる、とは限らない

公式ドキュメントでは、CLAUDE.mdは強制設定ではなく、毎回コンテキストとして読まれる指示だと説明されています。具体的で短いほど従いやすく、1ファイル200行未満が目安です。二つのルールが矛盾すると、Claudeがどちらを選ぶかは一定しません。

社内運用で起きやすいのは、失敗するたびに注意書きを足すことです。「削除前に確認」「変更後にテスト」「本番は慎重に」。どれも単体では正しい。ただ、例外条件、確認者、完了基準がないまま増えると、AIは全部を読んでも次の行動を決められません。古いフォルダ名や廃止したコマンドが残っていれば、存在しない場所を探す時間まで増えます。

もう一つ厄介なのが、同じルールの重複です。会社共通、個人設定、案件直下、サブディレクトリに似た指示があり、一部だけ内容が違う。人間なら雰囲気で補えますが、AIにとっては優先順位の判断材料が不足します。指示書は追加より、正本と適用範囲を決める方が効きます。

棚卸しの前に指示書の型を揃えるなら、AIへの指示を、目的・材料・判断基準・禁止事項に分ける基本形から確認できます。監査で見つけた重複を、何を残すかまで判断しやすくなります。

監査結果を三つに仕分ける

/doctor prompt-auditを実行した後、指摘をそのまま一括修正するのは避けます。まず次の三つに分けます。

  1. 事実が古い: 廃止したコマンド、移動したパス、旧モデル名。現在の実行環境で確認し、更新または削除します。
  2. 指示が衝突する: 「自動で進める」と「必ず確認する」が同じ範囲にある状態。対象となる操作と承認条件を分けます。
  3. 書く場所が違う: 毎回読む必要のない長い手順はスキルへ、特定フォルダだけに必要なルールはパス指定のルールへ移します。必ず止めたい操作は、文章だけに頼らず権限やフックで制御します。

大切なのは、短くすること自体を目的にしないことです。削ってよいのは、コードや設定から分かる説明、重複、期限切れの注意書きです。事故歴、例外時の戻し先、会社固有の判断基準まで削ると、次の担当者が同じ失敗を繰り返します。

モデル更新を自動解禁しない

モデルの別名は、提供側の更新に合わせて新しい版を指すことがあります。日常の個人作業なら便利です。顧客データを扱う処理、夜間バッチ、承認付きの外部送信では、同じ別名でも出力傾向が変わる可能性を見ておく必要があります。

availableModelsMatch: "exact"は、新版を永遠に拒否する設定ではありません。受け入れ確認が終わるまで自動解禁しないための待合室です。deniedModelsは、既知の不具合、費用、地域、契約条件などで使わせたくない版を明示的に外す用途に向きます。

ただし、モデル名を固定すれば再現性が完全に保証されるわけではありません。ツール、外部API、参照データ、指示ファイルが変われば結果も変わります。版の固定は一つの条件であり、テストと実行ログの代わりにはなりません。

30分で行う受け入れ確認

  1. 監査を保存する。 v2.1.283以降で/doctor prompt-auditを実行し、指摘項目と対象ファイルを変更前に記録します。
  2. 一件ずつ裏を取る。 パスとコマンドが本当に古いか、現在のリポジトリとCIで確認します。監査の提案だけを根拠に削除しません。
  3. 重複元を探す。 会社、個人、案件、サブディレクトリの指示を並べ、同じ判断を複数箇所に書いていないか見ます。
  4. 代表作業を再実行する。 読み取りだけの調査、ファイル編集、テスト、承認が必要な操作を一件ずつ試します。
  5. モデル境界を確認する。 許可した版は起動でき、拒否した版と未承認の新版は止まるか確認します。
  6. 差し戻し条件を残す。 指示違反、テスト失敗、費用増、出力品質低下のどれで旧設定へ戻すか決めます。

全案件へ同時に入れる必要はありません。誤りを見つけやすく、外部送信や削除を伴わない一案件で試す方が安全です。そこで指示の遵守率と手戻りを見てから対象を広げます。

限定GOとHOLD

限定GO: まず監査だけを実行し、古いパス、廃止コマンド、明白な重複を人間が確認して直す。モデルの厳密許可は、顧客案件や無人処理など、変更影響が大きい範囲から使います。

HOLD: 監査結果による全ファイルの一括書き換え、根拠を残さない指示削除、テストなしのモデル切り替え。会社固有の例外や過去の事故対策が入った指示は、作成者か運用責任者が確認するまで残します。

この更新だけで、AIの指示管理が完成するわけではありません。prompt-auditが見つけるのは整理候補です。どのルールを会社共通にし、どれを案件だけに置き、どこを技術的に強制するかは運用側が決めます。

まず一つ変えるなら

最も利用頻度が高い案件で/doctor prompt-auditを一度実行し、上位三件だけ確認します。修正前後で、同じ代表タスクを実行してください。見る数字は、指示違反の件数、やり直し回数、完了までの時間です。

変更履歴には、直した文面だけでなく、なぜ残したか、なぜ削ったかも一行で記録します。次のモデル更新時に、同じ議論を最初からやり直さずに済みます。

指示書の価値は長さでは測れません。新しい担当者と新しいモデルが読んでも、同じ境界で動けるか。そこまで確認できた指示だけを正本に残すと、AIへ任せる仕事を増やしても、過去の注意書きに足を取られにくくなります。

一次情報

シェアはこちらから
  • URLをコピーしました!