CLAUDE.mdの書き方：Claude Codeにプロジェクトの規則を伝える方法

要点： CLAUDE.mdには毎回説明し直すプロジェクトの規則を短く具体的に書いてください。作業コマンド、修正時の注意、完了報告の基準など実際に確認できる内容が適しています。全ての文書をコピーするより、必要な規則を選んで書き、プロジェクトが変わったらファイルも更新する必要があります。

1. CLAUDE.mdに入れる内容を選ぶ

公式文書はCLAUDE.mdを、プロジェクトや利用者の作業に関する継続的な指示を書くMarkdownファイルと説明しています。プロジェクトファイルの位置と読み込まれる範囲は、メモリの公式文書で確認できます。プロジェクトルートのCLAUDE.mdを出発点にできます。

適した候補は新しい作業ごとに繰り返して伝える内容です。例えば「利用者が既に変更したファイルを保全する」「このプロジェクトの日付は韓国時間で表示する」「画面の文言は用語集の表現を使う」など、コードだけでは意図が分かりにくい規則です。一時的な作業の詳細な要求は会話で伝え、継続して適用する規則をファイルに残してください。

2. 短い記述例から始める

以下は架空のタスク管理ウェブプロジェクトの例です。コマンドとパスは実際のリポジトリに合わせて変える必要があります。そのまま貼り付けても検証環境ができたり、テストが実行されたりするわけではありません。

# 프로젝트 규칙
## 목적
한국어 사용자를 위한 개인 할 일 관리 화면이다.

## 작업 방식
- 작업 시작 전 기존 변경 사항을 확인하고 보존한다.
- 요청한 기능과 관계없는 파일은 수정하지 않는다.
- 화면 문구는 docs/terms.md의 용어를 따른다.

## 검증
- package.json에서 실제 실행 가능한 검증 명령을 확인한다.
- 관련 검증을 실행하고 명령과 결과를 보고한다.
- 화면 동작 변경은 정상 입력과 빈 입력을 함께 확인한다.

## 완료 보고
- 변경 파일과 이유를 간단히 정리한다.
- 실행하지 않은 검증은 실행했다고 쓰지 않는다.
- 남은 문제와 확인하지 못한 조건을 명시한다.

この例の要点は、文が検査可能な行動につながることです。「完璧に作る」は完了の判断が難しいものの、「空の入力で案内が表示されるか確認する」には比較対象があります。プロジェクトに用語集がなければその規則を削除するか、実際の文書を先に整理してください。

3. 実行コマンドは確認したものだけを書く

別のプロジェクトの例を見てnpm testやnpm run buildをそのまま書くと、実際には存在しないコマンドになることがあります。設定ファイルとプロジェクトの案内でコマンドを確認し、何を検証するかも記録してください。簡単な構文検査と全体の統合テストが別の作業なら、一行ずつ目的を説明すれば十分です。

例えば「UI文言の修正後は指定画面を開いて改行を確認する」と「計算ロジックの修正後は境界値の事例を確認する」は検証方法が異なります。全ての変更で同じ長い作業を繰り返させるより、変更に必要な検証を選ぶ基準を書いてみてください。実際の実行の有無と結果は各作業の報告で確認します。

4. 指示と権限設定の役割を区別する

「実際の顧客ファイルは開かない」という文は意図を説明する指示です。ツールアクセスを技術的に制限する必要があれば、権限設定を別途扱います。Anthropicの文書はCLAUDE.mdを強制設定として扱わないと説明し、ツール権限は別の規則で管理します。設定方法は、公式の権限案内を参照してください。

また、公開リポジトリに置くCLAUDE.mdにパスワードやAPIキーを書かないでください。必要な値の名前と見つける手順を説明し、実際の秘密の値は貼り付けずに記述します。「環境変数Xが必要」と「Xの実際の値を記録する」は別の内容です。規則ファイルを共有する範囲も確認してください。

5. 規則が増えたときの整理方法

古いコマンド、重複した表現、互いに矛盾する規則から削除・修正してください。「新しいコードではAライブラリを使う」と「Aはもう使わない」が並ぶと、どちらに従うか不明確になります。規則を加える際は、必要な理由と適用する作業が読者に分かるように書いてください。

ファイルの適用を確認するときは、Claudeに現在の作業に適用する指示と根拠のパスを整理させ、自分で比較できます。ただしAIが規則を説明しただけで全作業が規則に従うとは判断できません。完了後も変更ファイルと検証結果を確認し続ける必要があります。

定期確認には簡単な三つの質問を使ってください。「現在のプロジェクトで使えるコマンドか」「他の規則と矛盾するか」「回答や変更結果で遵守を確認できるか」。答えられない文は、より具体化するか個別作業の説明へ移す候補です。

6. ファイルに入れる規則と個別の会話に残す条件を分ける

規則ファイルを全作業の記録帳として使うと、過去と現在の要求が混ざる場合があります。「プロジェクトで常に必要な約束」と「今回の依頼だけに必要な選択」を分けてみてください。例えば今回の画面のボタン色は作業依頼に書き、全画面で従う用語集は継続的な指示に含められます。

規則を一つ加えるときは「このプロジェクトで繰り返し発生する問題か」を考えてください。一度の回答が気に入らないからと全作業に長い手順を強制すると、小さな修正も不要に複雑になる場合があります。問題が繰り返すときに適用条件も書く方が管理しやすくなります。

7. 適用範囲を理解してファイルを分ける

現在の公式メモリ文書は、利用者の指示、プロジェクトの指示、下位領域の指示を区別しています。作業ディレクトリとその上のパスにあるCLAUDE.mdは開始時に読み込まれ、下位フォルダーの指示は関連ファイルを読む過程で含まれる場合があります。複数の指示は単に一つに置き換わるファイルではなく、一緒に文脈へ入るため矛盾を調べる必要があります。

[가상 배치 예시]
my-project/
  CLAUDE.md                 공통 약속
  docs/
    CLAUDE.md               문서 표현과 출처 기록 규칙
  src/
    ui/
      CLAUDE.md             화면 문구와 표시 검토 규칙

この配置は必須の公式フォルダー構成ではなく、役割を説明する例です。小さなプロジェクトならルートの一ファイルで十分な場合があります。分けるならルートに全作業共通の約束を置き、下位ファイルにその領域だけに必要な差を書いてください。同じ検証コマンドを三ファイルにコピーすると、次に変わったとき全て修正する必要があります。

「現在適用される指示のパスと今回のファイルに関係する規則を列挙して」と頼み、意図したファイルを読むか調べられます。ファイルが抜けていれば、内容を長くするより作業位置とファイル配置を比較してください。回答が指示に言及したことと、実際の変更が指示に従ったことは別々に確認する必要があります。

8. 抽象的な規則を検査可能な文に変える

右の文は架空のプロジェクトの要求を整理したものなので、そのまま適用する前に自分のプロジェクトの正常動作を定める必要があります。例えば結果0件で案内を表示することが全アプリに共通の正解ではありません。規則ファイルは製品の決定を記録する場所であり、AIが勝手に決定を確定する場所ではありません。

현재 CLAUDE.md를 검토해 주세요. 파일은 수정하지 마세요.
각 규칙에 대해 다음을 정리하세요.
- 적용할 작업의 종류
- 지켰는지 판단할 결과나 근거
- 코드나 설정과 충돌하는 부분
- 이번 작업만의 요구가 섞인 부분
모호한 규칙에는 구체화한 문장 초안을 제안하세요.
근거가 없는 실행 명령과 경로는 만들지 마세요.

9. 架空の規則の矛盾を整理する例

架空のルート指示に「画面文言は全ての場合に英語」、UI指示に「新しい画面文言は韓国語」とあると仮定します。近くのファイルに書かれているだけでチームの決定を代わりに確定するより、どの作業にどの規則を適用したいか確認する必要があります。適用範囲を明示すると矛盾が減ります。

[수정 전 가상 지침]
루트: 화면 문구는 영어로 쓴다.
UI 폴더: 새 화면은 한국어로 쓴다.

[작성자가 제안한 정리 예시]
루트: 기존 화면 문구는 이번 작업에서 번역하지 않는다.
UI 폴더: 새 한국어 화면의 문구는 docs/terms.md를 따른다.
대상 화면 목록은 개별 작업 요청에서 지정한다.

この修正案は既存画面の維持と新しい画面の作成という異なる対象を区別した例です。実際の決定が「全画面を韓国語へ移行」なら全く別の規則が必要です。整理前に製品の選択を確認し、その選択を指示に移す必要があります。

/initで作った草案を読むとき

公式文書の/initは開始用の指示を作る際に使えます。生成された草案では、見つけたコマンドが実際の設定にあるか、ファイル構成を長く複製しすぎていないか、プロジェクトではなく個人の好みを共通規則にしていないか確認してください。自動生成されただけで承認済みのチーム規則になるわけではありません。

/init 초안에서 다음 부분을 다시 검토해 주세요.
1. 명령은 설정 파일의 근거 위치를 함께 적으세요.
2. 일반적인 설명과 이 프로젝트만의 주의점을 구분하세요.
3. 실행하지 않은 명령을 성공한 것으로 쓰지 마세요.
4. 서로 다른 폴더 지침이 충돌하면 목록으로 보여 주세요.
5. 제안은 먼저 검토 가능한 초안으로 제시하세요.

コマンドや保存形式が変わる作業を終えたら、関連する指示も探してください。変更したコードの説明が指示と異なるままだと、次の作業で誤った前提を再利用することがあります。規則の数より、現在のコード・チームの決定・検証手順が互いに一致しているかが重要です。

よくある質問とミスの解決

自動作成できますか？ 公式文書には/initで開始用ファイルを作る方法があります。生成内容も実際のコマンドとチームの規則に合うか確認してください。長いほどよいですか？ 必要な指示を明確に維持することが目的です。規則が無視されているようなら？ ファイル位置、適用範囲、矛盾する指示を確認し、実際の違反を具体的に比較してください。

公式の出典と確認日

• Claudeがプロジェクトを記憶する仕組み
• 権限を設定する

公式文書確認日：2026年10月3日。画面と提供条件は後に変わることがあります。