Claude Codeを使い始めると、毎回のように「このプロジェクトは何か」「どのファイルを触ってよいか」「変更前に何を確認するか」を説明したくなります。
その繰り返しを減らすための最初の設定が、CLAUDE.mdです。これは、プロジェクトの前提・日常的に守るルール・よく使う確認手順をClaude Codeへ伝えるMarkdownファイルです。Claude Codeは各セッションの開始時にこのファイルをコンテキストとして読み込みます。[1]
ただし、CLAUDE.mdは「禁止したから絶対に実行されない」設定ではありません。Claude Codeの行動を案内する文書であり、コマンド実行やファイル変更を実際に許可・拒否するのはパーミッション設定やHookです。[1] [2]
この記事の結論:CLAUDE.mdには、毎回説明している「プロジェクトの前提」「守る制約」「確認の進め方」を短く書きます。最初から完璧にしようとせず、同じ修正を2回説明した時点で1項目ずつ追加するのが安全です。
CLAUDE.mdでできること・できないこと
まず、役割を分けて理解します。CLAUDE.mdはプロジェクトの文脈を伝える場所です。権限や自動実行を制御する場所ではありません。
| やりたいこと | 主に使うもの | 例 |
|---|---|---|
| 毎回説明する前提を伝える | CLAUDE.md | 「変更前に目的・対象・確認方法を説明する」 |
| 特定の操作を許可・拒否する | パーミッション設定 | .envを読ませない、コマンド実行の都度確認する |
| 必ず実行する検査を作る | Hook | 編集前後にルール違反を検査する |
| 必要な時だけ使う長い手順をまとめる | Skill | 技術記事レビューやリリース前チェック |

この違いを理解しておくと、「CLAUDE.mdに書いたのに守られなかった」「禁止したはずの操作を防げない」という混乱を避けられます。会社PCや重要なプロジェクトでは、行動ルールと権限設定を同じものとして扱わないことが大切です。
最初のCLAUDE.mdに書く3つのこと
情報を増やしすぎると、重要なルールが埋もれます。最初は、次の3区分だけで十分です。
1. このプロジェクトが何か
Claude Codeが判断に必要な最小限の背景です。「検証用のリポジトリか」「本番運用中のコードか」「どの言語や構成を使うか」を、短い文章で書きます。
2. 日常的に守る制約
毎回伝え直すルールを選びます。たとえば、実データを扱わない、変更前に提案を出す、テスト方法を示す、といった内容です。曖昧な「きれいに書く」ではなく、「変更前に対象ファイルと確認方法を箇条書きで示す」のように、確認できる書き方にします。[1]
3. 確認・作業の進め方
よく使うテストコマンドや、変更後に確認する項目を残します。まだ検証手順が決まっていない段階では、無理にコマンドを埋めず「テスト手順を提案してから実行する」と書くだけでも構いません。
個人PCのテスト用:最小の記載例
次の例は、実データを置かない検証用リポジトリのための出発点です。自社のシステム名、接続先、APIキー、顧客情報は書かないでください。
# このリポジトリについて
Claude Codeの動作を確認するための個人用テストリポジトリです。
実データ・秘密情報・会社のファイルは置きません。
## 作業で守ること
- ファイルを変更する前に、目的・対象ファイル・確認方法を短く説明する
- 秘密情報、APIキー、パスワード、個人情報を作成・出力・保存しない
- 不明な点がある場合は、変更ではなく確認質問を先に出す
## 確認の進め方
- 変更後は、何を変更したかを箇条書きで要約する
- テスト方法が決まっていない場合は、実行前に提案する
これは完成形ではありません。実際にClaude Codeを使い、同じ修正や注意が繰り返された時にだけ、短いルールを追加してください。大きな手順書や特定ディレクトリだけに必要な指示は、後からSkillや.claude/rules/へ分ける方が読みやすくなります。[1]
書くこと・書かないことの判断表
| 書いてよい候補 | 書かない・別の場所へ置く候補 |
|---|---|
| プロジェクトの目的 | APIキー、パスワード、トークン |
| ディレクトリの役割 | 顧客名、個人情報、社内限定の接続情報 |
| 命名規則、テスト方法、確認手順 | 数十手順に及ぶ作業マニュアル |
| 「変更前に確認する」などの共通ルール | 特定のファイルだけに必要な詳細ルール |
| チームで共有してよいプロジェクト前提 | 自分だけのローカル環境情報 |
プロジェクトで共有する内容は./CLAUDE.mdまたは./.claude/CLAUDE.mdに置き、個人だけのプロジェクト固有メモはCLAUDE.local.mdに置いてGitの管理対象から外す方法があります。Claude Code公式は、ユーザー・プロジェクト・ローカル・組織管理のそれぞれで異なる配置先を案内しています。[1]
Windowsで安全に試す手順
ここでは、会社PCや業務データではなく、個人PCの空のテストフォルダだけで確認します。まだClaude Codeを導入していない場合は、先に公式の導入手順を確認してください。[3]
- PowerShellを開き、個人用のテストフォルダを作ります。
$lab = Join-Path $HOME "Documents\claude-code-lab\claude-md-test"
New-Item -ItemType Directory -Force -Path $lab | Out-Null
Set-Location $lab
- 上の最小例を
CLAUDE.mdとして保存します。メモ帳、VS Code、任意のエディターで構いません。 - 同じフォルダでClaude Codeを起動します。
claude
- Claude Code内で
/contextを実行し、Memory filesにCLAUDE.mdが表示されるか確認します。[1] - 次のように依頼します。
このリポジトリで作業する前に、適用されているルールを3点要約してください。
ファイル編集やコマンド実行は、まだ行わないでください。
期待する結果は、CLAUDE.mdに書いた「個人テスト用」「秘密情報を扱わない」「変更前に説明する」といったルールが、要約に含まれることです。この確認だけでは権限が強制された証明にはなりません。次の記事で、Claude Codeのパーミッション設定を別に確認します。
うまく反映されない時の確認順
| 確認すること | 見直すポイント |
|---|---|
| 起動した場所 | CLAUDE.mdがあるフォルダ、またはその配下でclaudeを起動しているか |
| ファイル名 | CLAUDE.md.txtにならず、正確にCLAUDE.mdになっているか |
/contextの表示 | Memory filesに読み込み対象として表示されるか |
| 親フォルダの指示 | 上位フォルダにもCLAUDE.mdがあり、ルールが重なっていないか |
| ルールの書き方 | 矛盾するルール、抽象的すぎる指示、長すぎる説明がないか |
Claude Codeは、起動した作業ディレクトリから上位へたどって見つけたCLAUDE.mdとCLAUDE.local.mdを読み込みます。指示が矛盾すると、どちらを優先すべきかが不明になりやすいため、重複や古いルールは定期的に削ります。[1]
最初から完璧にしない
CLAUDE.mdは、一度書いて完成する文書ではありません。Claude Codeに同じ注意を2回した、レビューで同じ抜けを見つけた、新しいメンバーにも毎回説明している、といった場面が追加の合図です。[1]
逆に、まだ一度しか使っていない手順や、特定作業だけの長い手順は、すぐにCLAUDE.mdへ入れない方が安全です。まずは短く始め、必要になった項目だけを増やしてください。
次に読む記事
- Claude Desktop側のMCPを安全に試す前提は、会社PCでMCPを安全に試すチェックリストで確認できます。
- Claude Codeで「何を実行してよいか」を扱う次の記事では、パーミッション設定と
CLAUDE.mdの役割の違いを検証します。 - MCPの基本を先に確認したい場合は、MCPとは?Claude Desktopでできること・できないこと・安全な試し方も参照してください。

コメント