Claude Codeで料理ブログ等のプロジェクトを始めて、毎セッション同じ説明を繰り返してしまう人向け
料理ブログ等のプロジェクトで毎セッション同じ説明（画像はどこに置く・frontmatterの書き方・ビルドコマンド等）を繰り返している時に、その指示をまとめて1ファイルに置いておけば毎回読み込んでもらえる、という形で導入する。公式の合図は「同じ訂正を2回打ったら CLAUDE.md に書く」
噛み砕くと、家族のレシピノートに近い
新しく入ったキッチンスタッフに毎日「砂糖はこの引き出し」「塩はこっち」と教え直すのはしんどい。だから紙のノートに書いて壁に貼っておく。CLAUDE.md はそれと同じ立て付けです。
料理ブログでいうと、こういう内容を書いておきます。
- 画像は
static/images/に置く - 記事は
content/posts/にYYYY-MM-DD-スラグ.mdで作る - frontmatter のタグは英語、カテゴリは日本語
- ローカル確認は
hugo server -D - 本番ビルドは
hugo --minify
これを CLAUDE.md に書いておけば、Claude Code は毎セッション開始時にこのノートを読んでから動き出します。私が「画像どこ置く？」を毎回打つ必要がない。
ノートを貼り直すのが面倒だっただけ。
CLAUDE.md は「強制する設定」ではなく「文脈」
ここを誤解すると痛い目に合います。CLAUDE.md は「絶対こう動け」を Claude Code に強制する設定ファイルではありません。公式は明確に context, not enforced configuration（強制設定ではなく文脈）と書いています。
つまり Claude は CLAUDE.md を読んでから動くけれど、書いた内容を100%守る保証はない。曖昧な指示や矛盾した指示は、しれっと無視されることがあります。
たとえば料理ブログで「ちゃんとした記事を書いて」と書いても効きません。「冒頭に150字以内のリード文を置いて、そのあとh2の見出しを最低3つ立てて、最後にFAQを置く」のように具体に落とすと効きます。
強制力が要る場面、たとえば「特定フォルダの編集を絶対ブロックしたい」みたいな話は、CLAUDE.md ではなく settings.json の permissions.deny 側で組みます。CLAUDE.md は行動ガイド、settings は技術的な遮断、と役割が分かれています。
料理ブログで /init の雛形を「読まれて効くファイル」に育てる4ステップ
料理ブログのフォルダ cooking-blog/ で /init を叩くと、Hugoの構成（content/、static/、config.yml 等）を観察した雛形 CLAUDE.md ができます。ただ、雛形は薄い。ここから実際に効くファイルに育てる4ステップです。
ステップ1: 雛形を全文読む
まずターミナルで雛形をそのまま読みます。
$ cat CLAUDE.mdまたは手元のエディタで開きます。読むと「ビルドコマンド」「ディレクトリ構成」「テスト手順」みたいな見出しが並んでいるはず。中身は Claude が観察した一次情報なので、そのままで効く部分と、私が書き足さないと効かない部分が混在しています。
ステップ2: 「同じ訂正を2回打ちそうな前提」を先回りで書く
料理ブログで私が過去に2回以上打ち直した訂正を、雛形の最後に追記します。
# プロジェクト固有ルール
- 画像は必ず static/images/ に置く（content/ 直下に置かない）
- 画像ファイル名は kebab-case（例: tomato-pasta-step3.jpg）
- 記事の frontmatter は必ず英語タグ＋日本語カテゴリ
- tags: [pasta, italian, weeknight]
- categories: [パスタ料理]
- 公開前に必ず hugo --minify でビルドエラーを確認具体的にしておくのが肝。「画像はちゃんと整理して」みたいな曖昧指示は効きません。
ステップ3: ビルド・確認コマンドを名前付きで覚えさせる
料理ブログで毎回叩くコマンドをブロックで書きます。
# ビルド・確認コマンド
- ローカル確認（下書きも含めて表示）: hugo server -D
- 本番ビルド: hugo --minify
- Lintチェック: markdownlint content/これがあると Claude は次のセッションで「動作確認お願い」と打った時に、いきなり hugo server -D を叩いてくれます。コマンド名を毎回伝えなくていい。
ステップ4: 「やってほしくないこと」も書く
意外と重要なのがこっち。やってほしくないことを明示します。
# やらないこと
- 既存の content/posts/ 配下の記事を勝手に書き換えない（私が指示した記事だけ）
- config.yml の baseURL は触らない（公開URLが壊れる）
- static/images/ の既存画像を削除しないこれがないと、Claude は「親切心」で勝手に古い記事の文言を整えたり、設定値を「もっといい値」に書き換えたりしてきます。やられて困った経験があれば、即書き足すのが正解。
3行追記で事故が止まる。
4ステップ終わったら、CLAUDE.md は150〜180行くらいに膨らんでいるはず。次のセッションから体感が変わります。
200行を超えたら .claude/rules/ に分割する
公式の目安は「CLAUDE.md は200行以内」。これを超えると、Claude が読んだ時に大事な指示が薄まって守られにくくなります。料理ブログでも、書きたいルールが増えてくると簡単に200行は突破します。
突破した時の解決策が .claude/rules/ への分割です。トピック別にファイルを切ります。
cooking-blog/
├── CLAUDE.md # メイン（80行くらいに圧縮）
└── .claude/
└── rules/
├── frontmatter.md # frontmatterの書き方
├── images.md # 画像の置き方・命名
├── publish.md # 公開フロー（hugoコマンド等）
└── recipe-format.md # レシピ記事の構成テンプレ各ファイルに paths: を frontmatter で書くと、特定ファイルを編集する時だけ読み込まれます。
---
paths:
- "content/posts/**/*.md"
---
# レシピ記事の書き方ルール
- 1記事に必ず「材料」「手順」「コツ」のh2を立てる
- 手順は番号付き箇条書き（1. 2. 3. ...）
- 完成写真と工程写真を最低3枚このルールは content/posts/ 配下のマークダウン記事を Claude が読む時だけ発火します。config.yml をいじっている時には読み込まれない。コンテキストが軽くなって、必要な時に必要なルールだけが効きます。
スコープ4種類の使い分け
CLAUDE.md は置き場所で「誰のための覚え書きか」が変わります。料理ブログ単独だと ./CLAUDE.md 1個で済みますが、複数プロジェクト・チーム作業に広がると4種類を使い分ける場面が出てきます。
| スコープ | 置き場所 | 用途 |
|---|---|---|
| プロジェクト共有 | ./CLAUDE.md または ./.claude/CLAUDE.md |
チーム全員で共有するプロジェクトのルール（git管理する） |
| プロジェクト個人 | ./CLAUDE.local.md |
そのプロジェクトの私だけの覚え書き（.gitignoreに入れる） |
| ユーザー全体 | ~/.claude/CLAUDE.md |
全プロジェクトで効く私の好み（インデント幅、コメント言語など） |
| エンタープライズ | OSごとの固定パス | 会社のIT/DevOpsが配布する組織ルール（個人で除外不可） |
Claude Code は起動時に、カレントディレクトリから上のディレクトリへ順に CLAUDE.md と CLAUDE.local.md を探していきます。見つかった分は全部つなげて読みます。~/.claude/CLAUDE.md も読まれる。だから「ユーザー全体に書いた好み」と「プロジェクト固有のルール」が両方一緒に効く構造になっています。
料理ブログを始めたばかりの段階だと、./CLAUDE.md 1個で十分。~/.claude/CLAUDE.md に書くのは、複数プロジェクトをまたいで共通する「私は2スペースインデント派」「コメントは日本語で」みたいな個人趣向だけにしておくと混線しません。
料理ブログでの使いどころ3シナリオ
シナリオ1: 同じ訂正を2回打った瞬間
「画像は static/images/ に置いて」と1セッションで言って、次のセッションでまた Claude が content/ 直下に画像を置いた。これが2回目の訂正。CLAUDE.md に書く合図です。
# 画像配置ルール（必ず守る）
- 全ての画像は static/images/ 配下に置く
- 記事フォルダ（content/）内に画像を置かない
- ファイル名は kebab-case で日付プレフィックス推奨3回目以降は来ない。手応えは初回からはっきり出ます。
シナリオ2: 新しい執筆者が増えた時の引き継ぎ
料理ブログを2人体制にする時、「新しく入った人が同じ前提で書ける」ためのドキュメントが要ります。CLAUDE.md は実質それを兼ねます。git管理されているので、相方が git pull してきた瞬間に同じルールが Claude にも相方の頭にも入る。マークダウンなので人間が読んでも普通に読めます。
「Claude のための文書」じゃなくて「人間とClaude両方が読む文書」と捉え直すと、書く動機が出やすい。
シナリオ3: 既存記事を勝手に書き換えられて困った時
Claude に「最新記事の表記ゆれを直して」と頼んだら、ついでに古い記事の見出しまで「もっと自然な日本語」に書き換えていた、という事故。原因は「触っていい範囲」を CLAUDE.md に書いていないからです。
# 編集スコープ
- 私が指定した記事だけを編集する
- 過去記事の文言は明示的な指示がない限り変更しない
- config.yml と layouts/ 配下は触らないこれを書いて以降、勝手な書き換えはほぼ止まりました。「やらないこと」を明示する欄は本当に効く。
初心者が踏みやすい落とし穴
- 200行を超えてもそのまま放置する。長いほど内容が薄まって守られなくなる。100行を超えた時点で
.claude/rules/分割を検討する - 「ちゃんと書いて」「いい感じに」みたいな曖昧指示を入れる。CLAUDE.md は強制設定ではなく文脈なので、曖昧な指示はしれっとスルーされる。「冒頭150字以内」「h2を最低3つ」のように検証可能な表現に落とす
- 矛盾するルールを複数書く。「画像は images/」と「画像は assets/」が両方書いてあると、Claude はどちらかを勝手に選ぶ。気付かないうちに片方を採用していて事故る
- 個人専用ルールを
./CLAUDE.mdに書いてgit管理してしまう。チームの相方に「このルール何？」と言われる原因になる。私だけの好みは./CLAUDE.local.mdか~/.claude/CLAUDE.mdに分ける - AGENTS.md を作って読まれると思っている。Claude Code は
CLAUDE.mdしか読まない。AGENTS.md派の他ツールと共存したい時は、CLAUDE.mdの冒頭に@AGENTS.mdと書いてインポートする - compact 後にルールが消えたと感じる。プロジェクトルートの
CLAUDE.mdは/compact後に再読込されるが、サブフォルダ内のCLAUDE.mdは次にそのフォルダのファイルを Claude が読んだ時に再読込される。会話の中だけで言ったルールは/compactで消える、と覚えておく - 「絶対やらせない」を CLAUDE.md で組もうとする。CLAUDE.md は文脈なので強制力がない。コマンド遮断・パス遮断は
settings.jsonのpermissions.deny側で組む - 巨大な README.md を
@README.mdでインポートして肥大化させる。インポートしたファイルも全部コンテキストに乗る。読ませたい部分だけ別ファイルに切り出してインポートする
関連するコマンド・ツールへの動線
CLAUDE.md は単独で完結するというより、他の仕組みと組み合わせて効きます。
- /init（イニット） － CLAUDE.md の雛形を自動生成するスラッシュコマンド。最初の1行目はここから生まれる
- /memory（メモリー） － 現在のセッションで読み込まれている CLAUDE.md・rules・自動メモリ一覧を表示するスラッシュコマンド。「ちゃんと読まれているか」の確認に使う
- /agents（エージェンツ） － 専門タスク用のサブエージェント定義を管理するスラッシュコマンド。サブエージェントは独自の CLAUDE.md を持てる
- Skills（スキルズ） － 必要な時だけロードされる手順書。CLAUDE.md が「常時読まれる文脈」なのに対し、Skills は「呼び出された時だけ発火する」役割
- Hooks（フックス） － ツール実行の前後で自動的に走るスクリプト。CLAUDE.md が「お願いベース」なのに対し、Hooks は「機械的な強制」を担当する
- MCP（エムシーピー） － 外部ツールを Claude Code に接続する仕組み。MCP接続の使い方ルールを CLAUDE.md に書いておくと安定する
- /clear（クリア） － 会話履歴を全消去するスラッシュコマンド。
/clearしても CLAUDE.md は次セッションで再読込されるので消えない - /compact（コンパクト） － 会話履歴を要約圧縮するスラッシュコマンド。プロジェクトルートの CLAUDE.md は
/compact後に自動で再注入される - Read（リード） － ファイル読み込みツール。Claude が CLAUDE.md を読む時もこのツール系統が裏で動く
- Write（ライト） － ファイル書き込みツール。CLAUDE.md を直接編集する時にも使われる
- Bash（バッシュ） － ターミナルコマンドを実行するツール。CLAUDE.md に「ローカル確認は
hugo server -D」と書いておくと、このツール経由でそのまま叩いてくれる
参考リンク
書き方
プロジェクト直下に CLAUDE.md（または .claude/CLAUDE.md）を置く。マークダウンで書く。200行以内が目安、超えたら .claude/rules/ にトピック別ファイルへ分割するやってみるとこうなる
入力
# プロジェクト固有ルール
- 画像は static/images/ 配下に置く
- 記事のfrontmatterは英語タグ＋日本語カテゴリ
- ローカル確認は hugo server -D
- 本番ビルドは hugo --minify
# やらないこと
- config.yml の baseURL を勝手に変更しない
- 既存記事を明示指示なく書き換えない出力例
（CLAUDE.md 自体は出力ファイルではなく、Claude Code 起動時に読み込まれる入力ファイル。/memory コマンドで現在読み込まれている CLAUDE.md 一覧が確認できる。設定が効いていれば、次セッション以降「画像どこ置く？」と聞かなくても static/images/ に置いて作業を進めるようになる）このページに出てきた言葉
- マークダウン
- 文章に見出しや箇条書きを軽い記号で付けられる書式。<code>#</code> で見出し、<code>-</code> で箇条書きになる
- frontmatter
- マークダウンファイルの先頭に書く設定ブロック。記事のタイトル・タグ・公開日などを構造化して並べる場所
- Hugo
- テンプレートとマークダウン記事から静的サイトを生成するツール（静的サイトジェネレーター）
- kebab-case
- 単語を小文字＋ハイフンでつなぐ命名スタイル（例: tomato-pasta）
- エディタ
- 文章を書いたり書き換えたりするためのアプリ。Windowsの「メモ帳」、Macの「テキストエディット」、VS Code、vim、nano など
- コンテキスト
- Claude が会話を組み立てる時に見ている材料一式。CLAUDE.md の中身もここに混ぜ込まれる
- .claude/rules/
- プロジェクトルールをトピック別に分割して置くフォルダ。中の <code>.md</code> ファイルは自動で読まれる
- paths（フロントマター項目）
- ルールファイル冒頭の設定で、特定のファイルパターンを Claude が読む時だけそのルールを発火させる指定
- .gitignore
- Gitに記録させたくないファイル名を並べておくテキスト。ここに書いたファイルはチーム共有から外れる
- CLAUDE.local.md
- 同じプロジェクトでも私個人だけの覚え書きを置くファイル。<code>./CLAUDE.local.md</code> として作って <code>.gitignore</code> に追記する
- リポジトリ
- プロジェクトのファイル一式と変更履歴をまとめて保存する箱（GitHub上で見えるあれ）
- コミット
- 変更を「ここまで保存」と区切るGitの操作