はじめに
「今週は検証環境が使えない」と伝えた文が、来月の会話にも残っている。期限のある事情を覚えているだけなのに、いつの間にか恒久的な手順になる。そうなっていたら困ります。覚えてくれることと、今も正しいことは別です。
以前のモデルが何度も間違えたために足した指示も、モデルを替えた後まで同じ書き方で必要とは限りません。消してよいのか、残すべきなのか。その判断をしないまま、設定だけが増えていきます。
昨日の記事では、/skill-doctor でSkillsの使われ方を調べ、モデル更新時に指示を見直す話を書きました。今回は、その続きを .claude/rules/ とAuto memoryで考えます。自分で書いたルールも、Claudeが会話から残したメモも、その後の仕事に合わせて手入れしていきたいです。
Rulesは、対象に応じて指示を読み込ませるために使います。Auto memoryは、会話で分かった好みや事情を残します。コードの配置や開発手順、使うモデルが変わったら、どちらも今の仕事に合っているか確かめます。書いた場所だけでなく、どの経路で読み込まれたかも見る必要があります。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
Rulesは、必要になる場面と一緒に書く
RustのバックエンドとTypeScriptの画面が同居するプロジェクトを考えます。CLAUDE.mdには、認可の注意、画面のアクセシビリティ、テストの実行方法、リリースの手順が入っています。APIの設計を変えたら、認可やエラー応答の指示も探して直す必要があります。
これを4つのMarkdownに分け、CLAUDE.mdからすべてインポートすると、編集はしやすくなります。ただし、インポート先も起動時に読み込まれるため、指示の量は減りません。
Rulesも同様です。.claude/rules/ に移すだけなら整理にはなりますが、条件を指定していないルールは起動時に読み込まれます。対象を限定したいときに使うのが、paths です。
たとえば、APIの実装が backend/src/api/、テストが backend/tests/ にあるなら、.claude/rules/backend-api.md を次のようにします。
--- paths: - "backend/src/api/**/*.rs" - "backend/tests/**/*.rs" --- # APIを変更するとき - 認可は、要求されたデータの所有者まで確認する。 - エラー応答は、既存のAPIと同じ形式にそろえる。 - 動作を変更したら、成功時と拒否時の両方を検証する。 - 実行した検証と、環境の制約で実行できなかった検証を報告する。
公式資料の「読む」は、ファイルの内容が会話に入る経路を指します。ファイルを操作するすべてのツールに対して、毎回条件判定する仕組みではありません。後で扱うように、最近の報告ではネイティブの Read とシェルの cat で読み込み結果が分かれています。APIの配置を変えたら、本文だけでなく paths も直します。正しい指示が残っていても、対象のファイルに一致しなければ読み込まれません。
たとえば「変更したファイルのフォーマッターを必ず動かす」を実現したいなら、読み込む指示の整理とは別に、実行の仕組みを考えます。Hooksの記事で扱ったように、対象イベントへ処理を結びつける用途です。
1ファイル1テーマにすると、直す場所が分かる
公式ガイドは、Rulesを1ファイル1テーマに分け、内容の分かる名前を付けるよう勧めています。api-design.md や testing.md のような分け方です。サブディレクトリにも置けますが、rules/backend/ という配置だけで適用先がbackendへ限定されるわけではありません。対象は paths で指定します。
paths に *.rs と書くと、プロジェクト直下のファイルだけに一致します。配下のディレクトリまで含めるなら **/*.rs です。src/**/*.{ts,tsx} のように、波括弧で複数の拡張子をまとめて書けます。
ただ、先ほどの例を **/*.rs に広げると、APIと無関係なRustの処理にも同じ指示が入ります。例ではAPIの実装とテストを対象にしました。拡張子だけで決めず、その指示が必要になる仕事から範囲を絞ります。
本文も「適切に検証する」より、「別ユーザーのデータIDを渡したとき、アクセスを拒否することを確認する」と書く方が、結果を確かめられます。後から読んだ人にも、何を守るための一文なのか伝わります。目的が分からない「必ず」を積み重ねると、不要になっても消す判断ができません。
同じ注意をCLAUDE.mdとRulesの両方へコピーすると、片方だけ古くなる原因になります。食い違った指示が二か所にあると、Claudeはどちらかを任意に選ぶことがあります。Rulesへ移した一節は元のファイルから消し、関連する指示に矛盾がないか確かめます。
置き場所は、誰が更新するかで決める
指示を分けるなら、誰が変更に気づき、どこを直すかまで考えます。チームの決定が個人のメモにしかなければ、ほかの開発者は変更を知れません。逆に、個人の好みを共有のRulesへ入れると、本人以外の作業にも適用されます。
| 書きたい内容 | 置き場所の候補 | 更新するきっかけ |
|---|---|---|
| 変更時に既存の動作を保つ方針 | CLAUDE.md | チームの開発方針を変えたとき |
| APIのエラー応答に関する注意 | パスを指定したRules | APIの設計を変えたとき |
| 担当チームが管理するディレクトリの慣習 | そのディレクトリ内のCLAUDE.md | 担当チームが慣習を変えたとき |
| リリースノートの作成手順 | Skill | リリースの進め方を変えたとき |
| 個人が好む説明の詳しさ | Auto memoryや個人用の指示 | 本人の希望が変わったとき |
これは配置の提案です。たとえば「テストの方針」は、全体で共有する短い指示ならCLAUDE.mdに置けます。特定の領域だけの条件ならRulesに分ける方が、変更時に見つけやすくなります。
ディレクトリ内に置いたCLAUDE.mdも、Claudeがその配下のファイルを読むときに読み込まれます。ここでいう読み込みのきっかけがどのツールで発生するかは、CLIの動作とモードの影響を受けます。パスを指定したRulesと使い分けるなら、誰がどこで管理するかを考えます。
担当チームがコードと一緒に管理する指示なら、そのディレクトリのCLAUDE.mdが向きます。複数のディレクトリに散らばるマイグレーションファイルへ同じ注意を適用するなら、Rulesに集めると一か所で直せます。
個人の好みをすべてのプロジェクトで指示として読み込ませるなら、~/.claude/rules/ に置きます。ここのルールはプロジェクトのルールより先に読み込まれ、内容が重なればプロジェクト側が優先されます。
共有ディレクトリへのシンボリックリンクを .claude/rules/ に置く方法もあります。ただし、作業ディレクトリの外を指すリンクには、読み込みの条件があります。プロジェクトで外部インポートを承認するまで、リンク先のRulesは読み込まれません。承認後に読み込まれるのも、paths のないRulesだけです。
この承認画面が出るのは、プロジェクトの指示ファイルが @path を使って外部ファイルを読み込むときです。シンボリックリンクを置くだけでは表示されません。
チームのRulesはリポジトリにコミットします。複数のリポジトリへ配布するならPluginsにまとめると、更新する場所を集約できます。ファイルの共有方法を選ぶときも、修正した内容が利用先へ届くかまで確かめたいです。
個人用の置き場所については、過去記事の説明も更新しておきます。2025年のCLAUDE.mdの記事では CLAUDE.local.md を非推奨と説明しました。現在の公式資料では、個人用のプロジェクト指示を置く方法として案内されています。利用するときはGitの除外設定へ追加します。除外したファイルは、ほかのworktreeや開発者にそのまま届くわけではありません。
Auto memoryに残ったことを、チームの決定にしない
Auto memoryでは、Claudeが今後の会話で役立つ情報をファイルへ保存します。既定では有効で、/memory から内容の確認や有効・無効の切り替えができます。
/memory
標準の保存先は ~/.claude/projects/<project>/memory/ です。同じGitリポジトリのworktree間では共有されますが、別のマシンへ自動で配布されるチーム設定ではありません。
ここで、二人の開発者が同じリポジトリを扱う場面を考えます。一人は会話の中で「この作業では検証結果を先に知りたい」と伝え、もう一人は伝えていません。個人の説明の好みなら、その違いは自然です。
一方で、二人が同じ変更をするときに必ず確認してほしい内容まで、片方のメモだけに入っていたら困ります。共有したいルールだと判断したら、レビューできるプロジェクトの指示へ移します。そのときには元のメモも確認し、古い説明を残さないようにします。Auto memoryに保存されたことだけで、チームが採用した方針にはなりません。
記憶は、調査を始める手掛かりにもなります。ただ、「以前はここを直したら通った」という記録だけで、今回も同じ原因だとは決められません。記録を頼りに現在のファイルを読み、実行結果を確かめます。
「覚えて」と頼んだら、保存された内容まで読む
たとえば、レビュー結果の伝え方を訂正したなら、次のように頼めます。
レビューでは、変更が必要な不具合を先に知りたいです。 好みの違いによる提案は後に分けてください。 今後のレビューでも使う希望として覚えてください。
その後に /memory を開き、何が保存されたかを読みます。「好みの提案は不要」と解釈されていたら、そこを直します。伝えた内容と、次の会話へ渡る内容が一致しているかを確かめるためです。
まず1つの希望を保存し、別の会話でどのように引き継がれるか試すと、効果を判断しやすくなります。一度保存した希望も、次の仕事に合わなければ直せます。
公式資料では、記憶の種類を user、feedback、project、reference に分けています。利用者の背景、訂正した内容、進行中の仕事の事情、外部の参照先といった区分です。コードから調べられる構造や、CLAUDE.mdにある指示を、そのまま保存するための機能とはされていません。
会話を毎回丸ごと要約して保存する仕組みでもありません。残す情報を選ぶため、伝えたことがすべて保存されるわけではありません。
保存先は、たとえば次のような構成になります。入口となる MEMORY.md と、個別の内容を記したファイルを分けて置きます。
memory/ ├── MEMORY.md ├── feedback_review.md └── project_release.md
起動時には、MEMORY.md の先頭200行か25KBまでが読み込まれます。先に達した方が上限です。個別のメモは必要なときだけ読み込まれます。MEMORY.md には何の情報がどこにあるかを記し、詳しい内容は個別のファイルへ分けます。
上限を超えて省略された部分の行数と開始位置は、警告で確認できます。この表示は9月のv2.1.268で追加されました。v2.1.274では、VS CodeのCustomizeメニューにMemoryとInstructionsが追加されています。Memoryでは保存したメモや保存先を確認でき、InstructionsではCLAUDE.mdを編集できます。
Auto memoryは、定期的に棚卸しする
Auto memoryの保存期間は、セッション履歴とは別に考えます。公式資料では、cleanupPeriodDays で古いセッション履歴を削除しても、memoryディレクトリはその対象になりません。MEMORY.md と個別のトピックファイルは、利用者かClaudeが編集・削除するまで残ります。
つまり、Auto memoryには自動的な期限がありません。GitHubの#85075では、数か月前に書かれた MEMORY.md が毎回の会話へ読み込まれ、すでに変わったプロジェクトの説明が残っていた事例が報告されています。問題は、古いメモが存在することより、それに気づくきっかけがないまま起動時の文脈へ入り続けることです。
公式資料は、月1回のような点検周期を決めていません。自分の運用へ定期点検を入れるなら、固定日だけでなく、次の変化をきっかけにすると見落としにくくなります。
- モデルやCLIを更新したとき
- リポジトリの構成や担当範囲を変えたとき
- 大きな作業やリリースが終わったとき
MEMORY.mdの上限警告が出たとき
点検では、まず /memory からAuto memoryのフォルダーを開きます。MEMORY.md の各行から参照先をたどり、トピックファイルが残っているかを確認します。次に個別ファイルを読みます。YAML frontmatterがあるファイルには、v2.1.214以降のClaude Codeが modified の日時を記録します。日時は判断材料になりますが、古いから即削除するのではなく、内容が現在も正しいかを見ます。
内容は、公式の分類に沿って判断すると整理しやすくなります。user と feedback は今も続く好みや訂正なら残します。project は進行中の作業や期限が変わったら更新します。reference はIssueやダッシュボードの移転、リンク切れを確認します。完了した作業、解決済みの問題、以前の方針、同じ内容の重複は削除するか、現在の判断へまとめます。
MEMORY.md は入口なので、詳しい経緯を詰め込まず、一行の要約とトピックファイルへの参照にします。200行または25KBを超えると、書き込み自体は成功しても、次の会話では超えた部分が読み込まれません。
上限に近づいたら、古い項目を落とします。重複をまとめ、詳細をトピックファイルへ移すと、入口を短くできます。
整理後は /context を開き、残した入口と必要なRulesが実際に読み込まれているかを確認します。Auto memoryを無効にしても、すでに保存されたファイルが消えるわけではありません。消すと決めたメモは /memory から編集・削除し、無効化と整理を別の作業として扱います。
一時的な事情には、片付けるきっかけを残す
冒頭の「検証環境が今週は使えない」という情報は、今の作業には必要です。しかし、恒久的なRulesへ入れて忘れると、復旧後も検証を省く理由が残ります。残すときから、いつ確かめ直すかを考えます。
- 作業中は、接続できない事実と確認した日時を会話へ残す。
- 別の会話でも必要なら、再確認先を添えてメモへ保存する。
- 復旧したら、メモを削除するか、復旧済みへ直す。
「この環境のテストはいつも省略する」と要約されると、一時的な不具合が永続的な手順に変わってしまいます。保存内容の誤りは、新しい会話を始めても残ります。記憶が続くようになったからこそ、直す対象も会話の返事だけではなくなります。
チームの方針を変えるときも同じです。Rulesでエラー応答の形式を更新したら、メモに以前の形式が残っていないかも確かめます。「最新の形式を絶対に使え」と指示を足す前に、古い形式を指定する記述を消したいです。
Auto memoryを使わないプロジェクトでは、プロジェクトの設定に次を追加できます。既存の設定を残したうえで、この項目を組み込みます。
{ "autoMemoryEnabled": false }
モデルを替えたら、古い回避策も試し直す
前の記事では、モデルを更新したらSkillも試し直す方針を紹介しました。Rulesも同じように読み直し、合わなくなった指示は修正したほうがいい。これはClaude CodeやCodexを含め、モデルやエージェントを問わず続けたい手入れです。指示を読む相手が変わったのに、指示だけは完成済みとして扱わないようにします。
OpenAIの「Rethinking skills and prompts for GPT-6 Astra」でも、以前のモデルに必要だった細かな手順や強い制約を見直すよう勧めています。ここからRulesにも取り入れたいのは、過去の失敗を補う指示と、プロジェクトとして守る条件を分けて考えることです。
たとえば、調査不足への対策として「変更前に設計資料をすべて読む」と書いていたとします。小さな修正でも関係のない資料まで読むなら、対象の変更に必要な資料を示す書き方を試せます。一方、「別ユーザーのデータへアクセスさせない」という要件は、モデルを替えても残ります。モデルへの補助を減らすことと、仕事の要件を減らすことは分けて判断します。
比較するときは、新しいモデルで同じコードと依頼を使い、既存のRulesと見直した版をそれぞれ試します。期待した変更ができたか、必要な検証まで終えたか、不要な確認待ちが増えていないかを見ます。Rules以外の指示やAuto memoryもそろえないと、どの指示が結果を変えたのか分かりにくくなります。使ったモデル、Rulesの版、依頼、結果を残せば、次の更新時にも比べられます。
複数のモデルでRulesを共有するなら、それぞれで確かめます。あるモデルでは不要になった補助指示も、別のモデルでは役立つことがあります。共通のRulesには仕事の条件を残し、特定モデルのための回避策は分けられるかを検討します。
Auto memoryも点検の対象です。以前のモデルへ伝えた訂正が残っていれば、Rulesの修正内容と照合します。本人の好みや現在の事情は残し、古い回避策は今も必要かを確かめます。モデル更新をきっかけに、指示と記憶をまとめて読み直せます。
うまく読まれないなら、CLIの修正履歴も見る
正しい paths を書いても適用されない、除外したはずの指示が入る。そんなときは、CLIのバージョンも確認します。直近3か月にも、Rulesの読み込みに関する不具合が修正されています。
| 更新 | 修正されたこと | 関係する場面 |
|---|---|---|
| 7月・v2.1.198 | 対象ファイルへシンボリックリンク経由で到達すると、条件付きRulesが読み込まれない | 同じコードでも、開いたパスによって動作が違う |
| 7月・v2.1.211 | --setting-sources でprojectを外しても、下位のRulesが読み込まれる |
読み込み元を限定して調査したい |
| 8月・v2.1.239 | claudeMdExcludes でRulesのディレクトリやリンク自体を指定しても、リンク先しか照合されず除外できない |
リンクで共有したRulesを読み込み対象から外したい |
表にある claudeMdExcludes は、指示ファイルを読み込み対象から外す設定です。ファイルへのアクセスを禁止する設定ではありません。指定した指示ファイルが除外されないときも、文章を強める前に適用条件と修正履歴を見ます。
Rulesが「死んでいる」ときは、読み方を確かめる
ここまでRulesの整理方法を書いてきました。最近は「書いたRulesが読み込まれない」という別の問題も報告されています。
kawasin73さんは「Claude Code の Rules はもう死んでいる」という記事で、この問題を取り上げています。
Auto modeがファイルの読み書きをBashへ寄せることで、パスを指定したRulesや下位ディレクトリのCLAUDE.mdが読み込まれない状況です。
公式のMemoryの説明は、パスを指定したRulesが一致するファイルをClaudeが読むときに適用される、と説明しています。下位ディレクトリのCLAUDE.mdについても、そのディレクトリのファイルを読むときに読み込まれる説明です。
ところが、GitHub Issue #90450 と #92271 では、同じファイルを2つの方法で開いたときの違いが報告されています。ネイティブの Read とBashの cat や sed -n を比べた結果です。
この差は、ファイルの中身が取得できたかどうかではありません。Bashのコマンドは成功して内容も返しますが、Rulesを読み込むきっかけにならないことがあります。Auto modeや bypassPermissions では、セッションによって次のようなBash優先の指示が追加され、Read、Edit、Writeを使わずに作業するよう促されます。その結果、Rulesと、そのツール名に対して登録したHooksが同時に経路から外れます。
| 操作 | パスを指定したRules・下位CLAUDE.md | Read・Edit・Write向けのHooks |
|---|---|---|
ネイティブの Read |
報告された再現では読み込まれる | Readのフックが対象なら実行される |
Bashの cat、head、sed |
報告された再現では読み込まれない | Readのフックは実行されない |
起動時に読むルートCLAUDE.mdや paths のないRules |
この問題と同じ遅延読み込みではない | ツール呼び出しに依存しない |
ここで「Rulesが死んでいる」というのは、ファイルが消えたという意味ではありません。読み込み条件が満たされず、セッションから見えない状態を指します。すべての環境やすべてのモデルで同じになると確定したわけでもありません。Issueの報告では、同じモデル名やCLI版でもセッション単位の割り当てが異なり、サブエージェントは親セッションの割り当てを引き継ぐとされています。
2026年9月18日時点では、解決を確認できていない
2026年9月17日公開のv2.1.275のリリースノートには、このBash優先とRulesの読み込み欠落を直した記載はありません。
主要な #90450 はOpenのままです。9月10日に登録された下位ディレクトリのSkillsとCLAUDE.mdに関する #93403 もOpenです。#92271はクローズされていますが、投稿者が回避策を確認した後に閉じた記録です。修正コミットや開発元による解決報告ではありません。
この時点の記録だけでは、修正済みとは判断できません。すべてのセッションで起こるとも言えないため、自分のCLIと権限モードで、同じファイルを Read とBashの両方で開いて確認します。後のバージョンで試す場合は、リンク先のIssueとリリースノートも読み直してください。
利用者側で試せる対策
最も直接的な回避策として、Issueで検証された環境変数を新しいセッションの前に無効化する方法があります。既存の env を残したうえで、プロジェクトだけで試すなら .claude/settings.local.json に次を加えます。
{ "env": { "CLAUDE_CODE_THRIFTY_SONIC": "0" } }
これは公式の環境変数一覧に載っている利用者向け設定ではありません。Issue #92271と#90450のコメントで、値を文字列の "0" にするとBash優先の指示が出なくなったと報告されています。
名前や動作が将来も維持される保証はないため、設定したら同じ検証をし、CLIを更新したときにも試し直します。すでに始まったセッションへ後から追加しても、最初に入った指示を取り除けないという報告があるため、変更後は新しいセッションを使います。
Auto modeを使わないManualやAccept Editsでは、その指示が入らなかったという報告もあります。ただし、これは権限モードを変えればRulesの読み込みが必ず直るという公式保証ではありません。途中でモードを変えるのではなく、新しいセッションで確認します。
安全性に直結する指示は、遅延読み込みに頼らず、起動時に読むルートCLAUDE.mdや paths のないRulesへ短く置きます。すべてを移すとコンテキストが膨らむので、実行環境を起動できなくする、秘密を読む、データを消すといった失敗を止める条件だけを対象にします。対象範囲を限定するRulesは残し、読み込み経路が戻ったかを別に検証します。
ファイルへのアクセスを制限したいときは、RulesやHooksだけでなく権限ルールとSandboxも使います。
公式のPermissionsの説明では、Read と Edit の拒否ルールがBashにも適用されると説明しています。対象は cat、head、tail、sed、tee など、Claude Codeが認識できるファイル操作やリダイレクトです。
この説明は、静的なアクセス制御をBashへ広げる話です。Rulesの読み込みを戻す機能とは分けて考えます。
一方、PythonやNodeの任意スクリプトが内部で開くファイルまでは覆いません。すべてのプロセスを境界で止めるにはSandboxを使います。これはRulesを注入する方法ではなく、読ませてはいけない対象を守る方法です。
Hooksを使うなら、Edit|Write だけでなく Bash も監視対象にする方法があります。現在のHooksの仕様では、PreToolUseでBashのコマンドを確認し、askやdenyを返せます。ただし、シェルの引用、パイプ、複数コマンドを完全に判定するのは難しく、フックが止められるのは自分が判定できた操作だけです。Readの代わりにBashを使ったとき、組み込みのRules適用を後から再現してくれる仕組みでもありません。まずは危険な書き込みや保護対象へのアクセスを止める用途に絞ります。
書き込み後の検査なら、FileChangedフックが使えます。これはEditやWriteだけでなくBashや外部プロセスによる変更も検知できますが、ファイルが変わった後に動き、変更を事前に拒否する機能ではありません。フォーマット、生成物の再計算、既知の設定ファイルの検査に向いています。
製品側で検討されている方向
関連Issueで提案されている修正は、利用者が回避策を覚えることではありません。Bashが触ったパスを既存のRules読み込み処理へ渡す案があります。
下位に .claude/ や一致するRulesがあるときはBash優先の指示を弱める、読み書きはネイティブツールを優先して検索やパイプ処理だけBashへ任せる、といった案も出ています。読み込まれなかった理由を表示し、Auto modeがツール選択を変えたことを記録する提案もあります。
これは、公式のHooksガイドが「指定したツールの呼び出し」に対してHooksを説明し、Memoryガイドが「Claudeが読む」ことを条件にRulesを説明しているためです。Bash経由のファイル操作をどちらの説明に含めるかが明確でなく、ツール選択を変えるモードと組み合わせたときに、無言で機能が抜け落ちました。修正されるまでは、設定が存在することと、その設定が今回の経路で読み込まれたことを分けて確認します。
書き直したら、読み込みと仕事の結果を確かめる
Rulesを作ったときも、モデル更新に合わせて直したときも、新しい会話で対象のファイルをネイティブの Read で読ませます。Bash優先の問題を調べるときは、同じファイルを cat で読んだ結果も比べます。
たとえば、CLAUDE.mdへ検証用の一時的な目印を置きます。Readでは目印が入り、Bashでは入らないかを確認します。目印を実際の指示にせず、検証後に削除できるようにすれば、仕事の結果へ影響を残しません。
/context は、現在のコンテキストを確認する入口です。/memory で編集場所を探し、/context で実際に読み込まれたものを確認する、と役割を分けると迷いません。
パスを指定したルールが、いつ何をきっかけに読み込まれたかを記録するなら、InstructionsLoaded フックが使えます。CLAUDE.mdや .claude/rules/ のファイルが読み込まれるたびに、ファイルのパス、読み込みの理由、きっかけになったファイルを受け取ります。次の設定は、パスの一致と圧縮後の再読み込みだけをログへ追記します。
{ "hooks": { "InstructionsLoaded": [ { "matcher": "path_glob_match|nested_traversal|compact", "hooks": [ { "type": "command", "command": "jq -c '{file_path, load_reason, trigger_file_path}' >> ~/.claude/instructions-loaded.jsonl" } ] } ] } }
load_reason が nested_traversal の行は、下位ディレクトリを辿ったときの読み込みです。compact の行は、圧縮の後に指示が読み直されたことを示します。プロジェクト直下のCLAUDE.mdは /compact の後に自動で読み直されますが、paths 付きのルールは対象ファイルを次に読むまで戻りません。圧縮の後でルールが消えたように見えたら、対象ファイルをまだ読み直していないだけという可能性を先に確かめます。Bashで読んだ結果に対応する行がないことも、今回の問題を疑う手掛かりになります。
ただ、Claudeが「ルールを読みました」と答えても、それで検証は終わりません。小さな変更を依頼し、必要なテストを実行したか、結果を区別して報告したかを見る。書き直した効果も、削って問題がなかったかも、その後の仕事で確かめます。
期待どおりに動かなければ、症状に応じて確認する場所を変えます。
| 起きていること | 最初に確かめること |
|---|---|
| API向けのルールが出てこない | paths が実際の配置と一致し、対象ファイルを Read で読んだか。Bash優先の指示が入っていないか |
| 関係ない指示まで毎回出てくる | paths のないRulesや、CLAUDE.mdのインポートに残っていないか |
| 別の会話で古い方針に戻る | Auto memoryと個人用の指示に古い記述がないか |
| 別の開発者には伝わっていない | 個人の保存先だけに書いていないか |
| 共有先のプロジェクトでルールが読み込まれない | 作業ディレクトリの外を指すシンボリックリンクになっていないか |
/compact の後にルールが読み込まれなくなる |
対象ファイルを読み直したか。ログの load_reason に compact や path_glob_match が出ているか |
| モデルを替えたら、関係のない調査や確認待ちが増えた | 以前のモデル向けの細かな手順や、Auto memoryに残った訂正が影響していないか |
| 読んだと答えるが手順を飛ばす | 指示が曖昧でないか、実行結果を確認できる形になっているか |
最後の行は、置き場所だけでは解決しない問題です。たとえば「十分にテストする」では、何を終えたら十分なのかが分かりません。対象の変更で必要になる検証を示し、実行できなければその理由を報告するようにします。機械的に欠かさず行う処理は、HooksやCIにも持たせます。
残す一行ごとに「消したらClaudeが間違えるか」を考えます。コミット済みのCLAUDE.mdなら、/doctor がコードから読み取れる内容の削除案を出します。Rulesも、その指示が必要だった理由と、今の仕事で役立ったかを照らし合わせれば、残すか直すかを決めやすくなります。
最初から定期点検の項目を増やしすぎる必要はありません。APIを移したら paths を直す。モデルを替えたら、以前の失敗を防いでいたRulesを試し直す。検証環境が復旧したら、Auto memoryに残した「今週は使えない」も片付ける。Bashで読んだときにRulesが見えなければ、同じファイルを Read で開いて差を確かめる。コードや仕事を変えた日に、それを説明する指示も一緒に更新しておきたいです。
書いたことと、読まれたことは別です。残すのは指示そのものだけではなく、消すきっかけと、読み込まれたかを確かめる方法でもあります。
本を出しました。宣伝。
