CLAUDE.mdには、Claude Codeへ毎回伝えるプロジェクトの前提を書きます。最初は「どのフォルダで何を作るか」「変更してよい範囲」「ビルド・テストコマンド」の3つで十分です。長い心得を並べるより、次の変更で確認できるルールを短く書くと、保守しやすいファイルになります。
この記事では、ルートに置くCLAUDE.mdを1枚作り、小さな変更で指示が使われたか確かめます。サブディレクトリへ分けるのは、担当領域ごとにコマンドや規約が違うときだけで構いません。
公式資料の確認日：2026年10月29日。テンプレートは編集側の作例です。Claude Codeでの適用・遵守率の実機比較は未実施です。
CLAUDE.mdに書くこと・書かないこと
Anthropicの公式メモリガイドでは、CLAUDE.mdは人が与える継続的な指示、auto memoryはClaudeが記録する知見として区別されています。CLAUDE.mdは参考にする文脈であり、処理を強制的に遮断する設定ではありません。書いた禁止事項だけで秘密情報へのアクセスを防げる、とは考えないでください。
たとえば「品質を高くする」は、何を確認すれば合格か不明です。「名前入力は空白だけならエラーにする。変更後は3ケースのテストを実行する」なら、コードとテスト結果で確かめられます。READMEを丸ごと写すより、Claude Codeが間違えやすい前提に絞りましょう。
| 曖昧な記述 | 確認できる記述の例 |
|---|---|
| きれいなコードを書く | このフォルダはES Modulesを使う |
| ちゃんとテストする | ルートで node --test を実行する |
| 関係ないところを変えない | 今回は src/validate.mjs と対応テストのみ変更する |
| 丁寧に報告する | 変更理由、実行コマンド、未確認項目を報告する |
「今回だけ必要な修正対象」は会話の依頼文に、「このリポジトリで常に使うコマンド」はCLAUDE.mdに置く、と分けると同じ指示を重複させずに済みます。
CLAUDE.mdの最小テンプレート
以下は依存パッケージのないNode.js教材を想定した例です。リポジトリのルートへ CLAUDE.md という名前で保存し、目的・フォルダ名・確認コマンドを自分の環境へ置き換えます。特に node --test は、実際にテストを実行できることを確認してから残してください。
# プロジェクトの前提
- 名前入力を検証する小さなJavaScript教材です。
- ソースは src/、テストは test/ に置きます。
- ES Modules（.mjs）を使います。
# 変更の範囲
- 依頼された不具合と対応テストを変更してください。
- 外部依存の追加、ネットワーク送信、公開は今回の対象外です。
- 既存の無関係な変更を取り消さないでください。
# 確認コマンド
- リポジトリのルートで node --test を実行します。
- 失敗した場合は入力値、期待結果、実際の結果を報告します。
- 実行できなかったテストを成功と報告しないでください。
# 完了時
- 変更理由、変更ファイル、確認結果、残る問題を短く説明します。
貼り付けたら、「src/ と test/ が存在する」「コマンドをその場所で実行できる」「今回限りの禁止事項を常設ルールに残していない」の3点を確認します。送信禁止などの文は作業範囲の指示であり、実際の権限設定の代わりにはなりません。
テストコマンドは作業場所とセットで書く
CLAUDE.mdのテストコマンドの書き方で大切なのは、コマンド名だけでなく「どこで」「何を確認するか」を書くことです。複数アプリを含むリポジトリで npm test だけを書いても、ルートと子フォルダで別の処理が走る場合があります。
## frontend/ の変更
- frontend/ へ移動して npm test を実行する。
- 入力フォームを変更したときは空入力・通常入力・上限超過を確認する。
- npm run build で配布用ビルドも確認する。
- パッケージが未導入なら、利用するlockfileとREADMEの導入手順を先に読む。
これは記述例であり、このサイトの教材に frontend/ やnpmスクリプトがあるという意味ではありません。実プロジェクトでは package.json のscripts、README、CI設定を照合します。コマンドが見つからなかったら、その場で適当なテスト名を発明させるのではなく、既存の確認方法を調べてもらいます。
テストが1件失敗したときも、結果は単に「失敗」で終わらせません。変更前にも失敗していたか、今回の差分が原因か、必要な環境変数がないだけかを分けます。認証情報の値を記事やログへ貼る必要はなく、変数名と不足している事実だけを記録します。
サブディレクトリの適用範囲を整理する
CLAUDE.mdはプロジェクトのルートだけでなく、担当領域のフォルダにも置けます。公式仕様では、作業場所までの親階層のファイルは起動時に読み込まれ、下位ディレクトリのファイルはその領域のファイルを扱うときに読み込まれます。複数の内容は文脈として結合されるため、「子を書けば親がすべて消える」という仕組みではありません。読込仕様の説明も確認してください。
sample-project/
CLAUDE.md 全体の目的、共通コマンド
src/
CLAUDE.md ソース固有の命名・依存方針
validate.mjs
test/
validate.test.mjs
ルートに「すべての関数名はcamelCase」、子に「すべてsnake_case」と書くより、ルートを「既存規約に合わせる」、子を「この領域はcamelCase」と限定した方が矛盾を減らせます。必要以上に階層を増やすと、どの記述を直すべきか分かりにくくなります。最初はルート1枚で始め、違う規約の領域ができてから分けましょう。
CLAUDE.mdの指示が無視されるときの確認
指示どおりに動かなかったとき、同じ禁止文を何度も追加する前に、読み込まれる場所と文の具体性を確認します。
- ファイル名が
CLAUDE.mdか、空ファイルや別拡張子になっていないかを確認する。 - Claude Codeを開始した作業場所と、対象ファイルの位置を確認する。
- 親・子・個人用の指示に矛盾がないかを読む。
- 「必要なら」「適切に」のような曖昧な表現を、条件と操作に分ける。
- 小さな1変更で試し、結果を差分とテストで確認する。
コードはまだ変更しないでください。
今回の作業に関係するCLAUDE.mdの場所と、そこにあるテスト手順を要約してください。
指示同士が矛盾している場合は、その箇所を挙げてください。
この質問への回答だけをもって適用確認が完了したとは判断しません。ファイルの存在と内容を自分でも照合し、実際の変更でテストが行われたかを見ます。「読みました」と「守れました」は別の確認です。
小さな変更でルールを試す
おすすめの練習は、空白だけの名前を受け付けてしまう検証関数を直すことです。次の依頼文では、対象と合格条件を固定しています。
名前入力が空白だけのとき、エラーにする変更をしてください。
先に対象ファイルと作業方針を説明してください。
既存の通常入力の動作は維持し、空文字・空白のみ・通常入力のテストを確認してください。
CLAUDE.mdに記載した作業場所とコマンドで検証し、実行結果を報告してください。
| 見る点 | 確認する証拠 |
|---|---|
| 変更範囲 | 差分に対象外ファイルが含まれないか |
| テスト | 実行コマンドと終了結果があるか |
| 命名 | 既存の名前の付け方から逸れていないか |
| 報告 | 未実施の確認を成功扱いしていないか |
失敗した項目だけをCLAUDE.mdへ反映します。たとえば命名は守れているのにテストが抜けたなら、命名規約を増やす必要はありません。こうして変更のたびに短く整えると、役に立つルールが残ります。
チームで更新するとき
CLAUDE.mdをGitで管理すれば、コードと同じレビューの流れで変更できます。更新理由と、実際に使えるコマンドかを確認しましょう。コマンドの名前が変わったときに古い記述を残すと、AIにも新しい参加者にも同じ混乱を生みます。
毎回長い手順を実行させたい場合は、常時読む前提と、必要時だけ呼ぶ手順を分ける選択肢があります。Claude Code Skillsの作り方では変更履歴の下書きを題材に説明します。導入がまだならClaude Codeのインストールを確認してください。
参考資料と確認範囲
- Anthropic：How Claude remembers your project — 2026年10月29日確認。
- テンプレートと練習用依頼文は本サイトが作成。Claude Codeでの繰り返し実験や遵守率の測定は未実施です。記述を自分のリポジトリへ合わせ、実行結果で確認してください。
本文執筆：Codex ／ 確認・編集：制作担当