CLAUDE.mdの書き方 — Claude Codeに常時読ませる「憲法」の設計方法と4つの必須項目

CLAUDE.mdとは — 毎回説明し直す内容を書き留める場所

CLAUDE.mdの本質は、毎回のセッションで説明し直していた前提を書き留めておく場所です。セッション開始時にClaudeが読む永続的な指示であり、技術的にはデフォルトのシステムプロンプトの後に追加されるユーザープロンプトとして扱われます。

「この会社は何をしている会社か」「ファイルはどこに何があるか」「どんな文体で書くべきか」「何をしてはいけないか」——こうした前提を書いておくことで、毎回ゼロから説明する必要がなくなり、出力のブレも減ります。

配置場所 — グローバルとプロジェクトの2レベル

自分の名前・役割・全業務共通の文体ルールなどはグローバルへ、事業や案件固有の情報はプロジェクトへ。この分担を守ると、プロジェクトが増えても設定が破綻しません。

当社の場合、グローバルに置いているのは出力言語・Gitのコミット単位・完了報告の型といった、どのプロジェクトでも同じことを言う作法です。一方プロジェクト側には、そのサイト固有の禁止事項と「どのファイルが正本か」の宣言を置いています。

迷ったときの判断基準はひとつで、「別のプロジェクトでも同じことを言うか」。同じならグローバル、そこでしか言わないならプロジェクトです。

書くべき4つの項目

当社のClaude Code研修では、CLAUDE.mdに書く内容を次の4項目に整理しています。

1. 1プロジェクトの目的 — 何をしたいのか、AIに何を期待しているのか
2. 2フォルダ構成と参照ルール — 「どの情報はどこを見るべきか」の索引。Claude Codeは必要な情報をファイル検索で探すため、この索引があると探索の精度と速度が大きく上がります
3. 3基本原則 — Claude Codeが知り得ない、自社・自分固有の判断基準（一般常識として自明な原則は書かない）
4. 4禁止事項・注意事項 — Claude Codeが知り得ない、固有の禁止事項

実物はこうなっている — 当社サイト運用のCLAUDE.md

抽象論だけだと書き出しづらいので、当社がこのコーポレートサイトの運用で実際に使っているCLAUDE.mdの節見出しをそのまま出します。運用しながら追記を重ねて12節になったものです。

# CLAUDE.md — company-site

## プロジェクト概要
## Webフォントはセルフホスト（next/font/google 禁止）
## リード獲得パイプライン（問い合わせ/診断/資料DL）
## 計測・SEO運用（GSC / GA4 / Bing / IndexNow / PSI）
## 共通ナレッジの参照（別リポジトリ）
## Codex互換（AGENTS.md・.agents/・.codex/）
## Git運用（コミット選別・プッシュと通知のフロー）
## 法務ドキュメントの改訂日
## コラム記事データのマークダウン規約
## お知らせ（News）データの規約
## サイトコンテンツの禁止事項
## 環境変数のセキュリティ方針（要点）

目的にあたるのは冒頭の「プロジェクト概要」の3行だけで、残り11節はすべて参照ルールか禁止事項です。先ほどの4項目でいえば、②と④が分量のほとんどを占めています。

ここから読み取れるのは、CLAUDE.mdの中身は「手順書」ではなく「索引と禁止」だということです。手順そのものは別ファイルに置き、CLAUDE.mdには「どこを見ればよいか」と「やってはいけないこと」だけを書きます。

参照ルールは「正本はどこか」を宣言する形で書く

②のフォルダ構成と参照ルールは、フォルダの一覧を書くことではありません。「この領域の正本はどのファイルか」「触る前に読ませるか」を宣言するのが実務上の書き方です。

## リード獲得パイプライン
運用のSSOTは `docs/lead-pipeline-runbook.md`。触る前に必ず読む。

## 計測・SEO運用
スクリプト本体は共有リポジトリ側にある。
修正は共有側で1回だけ行い、このリポジトリへコピーしない。

## 共通ナレッジの参照
教材・アーカイブの正本は別リポジトリにある。
このリポジトリへコピーを置かない（絶対パスで直接読む）。

ポイントは、内容そのものを書かず「正本の場所」と「触る前に読め」だけを書いていることです。CLAUDE.mdへ内容を写すと、正本を更新したときに両方直さないと食い違います。

この二重管理が、CLAUDE.md運用が破綻する最大の原因です。書いてあることが古いと一度でも分かると、人もAIもそのファイルを信用しなくなります。

やりがちなアンチパターン

① 何でも書き込んで肥大化させる

CLAUDE.mdは全セッションで読み込まれるため、書いた分だけAIが一度に処理できる情報量（コンテキストウィンドウ）を消費します。時々しか関係ない内容を入れると、毎回のコストになるうえ、重要なルールが埋もれて守られにくくなります。

依頼タスクに広く適用される内容だけを残し、特定タスクの手順はSkillsへ逃がしてください。

② 「絶対に守ってくれる」と期待する

CLAUDE.mdは強制設定ではなく、Claudeが参照するコンテキスト——つまり確率論の世界です。確実に守らせたいこと（ファイル削除の禁止、秘密情報へのアクセス禁止など、機械的に判定できるもの）は、permissions設定やhooksでガードします。「方針はCLAUDE.md、強制は仕組み」という分担が鉄則です。

詳しくは法人導入とセキュリティ対策をご覧ください。

③ セッション中に編集して「反映されない」と悩む

CLAUDE.mdはセッション開始時に読み込まれるため、セッション中に編集してもリアルタイムには反映されません。編集したらClaude Codeを再起動してください。

④ 複数のPC・メンバーにファイルコピーで配る

使うPCが2台に増えたり、チームで同じルールを使い始めたりすると、コピーで配った瞬間に版が分岐します。片方だけ直しても、もう片方は古いルールのままAIを動かし続けます。

当社では、全業務共通のグローバルCLAUDE.mdを1つのリポジトリに置き、各PCの ~/.claude/CLAUDE.md はそこへのシンボリックリンクにしています。実体は1ファイルなので、分岐そのものが起きません。

そのうえで運用ルール自体にも、編集してコミットし他のPCで git pull することが唯一の配布経路だと明記しています。手段を1本に決めておかないと、急いでいるときに必ずコピーが使われます。

応用 — 長くなってきたら rules に分割する

CLAUDE.mdが肥大化してきたら、共通方針だけをCLAUDE.mdに残し、対象が限定されるルールを .claude/rules/ フォルダに分割できます。rulesファイルは先頭に paths: を書くことで、特定のフォルダやファイルを扱うときだけ読み込ませることができます。

---
paths:
  - "05_Marketing/**/*.md"
---

# Marketing Rules
このフォルダ内の文章は、セールス導線とCTAを必ず確認する

「毎回必要な判断基準はCLAUDE.md、特定領域のルールはrules、特定タスクの手順はSkills」という3層構造にすると、コンテキストを無駄なく使えます。

同じルールを2つのAIツールに二重管理しない

Claude Codeと他のAIコーディングツールを併用すると、AGENTS.md のような別名の指示ファイルを求められます。ここで2本を手で書き分けると、必ず片方だけが古くなります。

当社はClaude Code側のCLAUDE.mdを原典と決め、AGENTS.md はそこへのシンボリックリンクにしています。実体は1ファイルなので、更新漏れが構造的に起きません。

リンクにできない生成物（設定ファイル等）は、原典から機械的に作り直す同期スクリプトを用意し、「変更したら同期して同じコミットに含める」というルールをCLAUDE.mdへ書いています。

育て方 — ルールは事故から生える

CLAUDE.mdは一度書いて終わりではなく、運用しながら育てるものです。おすすめの運用は、AIへの指示で「またこれを説明しているな」と感じた瞬間に、「今の内容をCLAUDE.mdに追記して」とClaude Code自身に頼むことです。

数週間もすれば、自分の業務に最適化された「憲法」が自然と出来上がります。最初から完璧な設計を目指す必要はありません。

もう一段効くのが、ルール文に「制定日」と「なぜそのルールができたか」を併記することです。当社の運用ルールは、そのほとんどが実際に起きた失敗から生えています。

- `git add -A` / `git add .` は使わない
  （並行セッションの未コミット変更を巻き込む・2026-06-18事故）

- 共有スクリプトはコピーせず、共有リポジトリを唯一の正本とする
  （コピーした瞬間に修正漏れの分岐が始まる・2026-07-04、
    コピー先に修正が届かなかった実例）

- ビルド時に外部フォント配信へ接続する仕組みは使わない
  （1ファイルの接続失敗で本番ビルドごと落ちる・2026-07-21デプロイ失敗の原因）

理由を書いておくと、後から読んだ人——未来の自分やAI——がそのルールを勝手に無効化できなくなります。「なんとなく厳しいだけの決まり」に見えるルールは、忙しいときに必ず省略されるからです。

裏を返すと、理由が書けないルールは本当に必要か疑ってよいサインです。事故が起きていないのに先回りで積んだ禁止事項は、守られないまま行数だけを食い、本当に守らせたいルールを埋もれさせます。