目次
- CLAUDE.md とは何か — AI に「毎回言わなくていい指示」を覚えさせるファイル
- 具体的にどう読み込まれるか
- ブログ運営で CLAUDE.md を使うとどうなるか
- /init で最初の CLAUDE.md を作る手順
- /init の実行手順
- 生成後にやるべき3つのこと
- 何を書くか — ブログ運営なら「方針・役割・禁止事項」の3本柱
- 柱1：方針（どんなブログを作るか・文体・価値観）
- 柱2：役割（AIに任せること・自分に残すこと）
- 柱3：禁止事項（やってはいけないこと）
- 何を書かないか — 書きすぎると AI が指示を無視する
- 200行問題：なぜ指示が無視されるのか
- 書くべきでないもの
- 実際にやった失敗：書きすぎて分離した話
- 階層構造を使い分ける — Global・Project・Local・サブディレクトリ
- 4階層の読み込み順と役割
- 各階層に何を置くか
- 実例：サブディレクトリ CLAUDE.md の使い方
- 実運用の CLAUDE.md を公開 — ブログ自動化プロジェクトの実物
- 3ファイルの役割分担
- 親 CLAUDE.md の主要セクション
- プロジェクト CLAUDE.md の主要セクション
- サブディレクトリ CLAUDE.md の主要セクション
- CLAUDE.md を育てる — 最初に書いたものと1ヶ月後の変化
- v1（最初の状態）の構成
- 1ヶ月後に加わったもの
- 具体的に何が変化したか
- 育てるタイミング
- 周辺ファイルとの使い分け — rules / skills / agents / commands / Hooks / Memory
- 何をどこに書くか
- agents/ との使い分けが特に重要
- よくある質問
- Q: CLAUDE.md と .cursorrules は何が違うの？
- Q: CLAUDE.md を書いたのに AI が指示を守らないときはどうすれば？
- まとめ — あなたのブログに合った CLAUDE.md を書こう
CLAUDE.md は、コーディング規約のためのファイルだと思っていませんか。
確かに、「CLAUDE.md 書き方」で検索すると出てくる記事はほぼ全てがソフトウェア開発のユースケースです。Python のコーディング規約、Next.js のディレクトリ設計、CI/CD の手順書——そういった内容ばかりです。
でも、ブログ運営で使うとどうなるでしょうか。
「ですます調で書く」「感情を美化しない」「説教口調にしない」「品質審査を飛ばすな」——こういったルールを CLAUDE.md に書いておけば、Claude Code はセッションをまたいでもそのルールを守ってくれます。毎回「なるべく体験ベースで書いてください」と説明し直さなくてよくなります。
この記事では、実際にブログ自動化プロジェクトで運用中の CLAUDE.md（3種類・合計 1,000 行超）を抜粋しながら、何を書けばよいか・何を書かないべきか・どう育てていくかを解説します。
CLAUDE.md の基本仕様からはじめ、ブログ運営に特化した設計思想、実運用ファイルの公開、そして1ヶ月で何が変わったかの変遷まで、できるだけ具体的に書きます。
CLAUDE.md とは何か — AI に「毎回言わなくていい指示」を覚えさせるファイル
CLAUDE.md は、Claude Code がプロジェクト起動時に自動で読み込むファイルです。
通常の会話では、セッションをまたぐたびに「このプロジェクトでは〇〇をしてください」と再説明が必要です。でも CLAUDE.md に書いておけば、次のセッションでも Claude Code はその指示を覚えた状態で動きます。
Claude Code のドキュメントでは「プロジェクトメモリ」と呼んでいます。「設定ファイル」というより「プロジェクトの記憶」に近いイメージです。
具体的にどう読み込まれるか
Claude Code を起動すると、以下の順序でファイルが自動読み込みされます。
1. ~/.claude/CLAUDE.md（Global設定：全プロジェクト共通）
2. プロジェクトルートの CLAUDE.md（Project設定：チーム共有）
3. プロジェクトルートの CLAUDE.local.md（Local設定：Git管理外・個人上書き）
4. 各サブディレクトリの CLAUDE.md（ディレクトリ固有のルール）
これが「階層構造」で、詳しくは後述します。
ブログ運営で CLAUDE.md を使うとどうなるか
たとえば、ブログの記事ライター役として Claude Code を使うとき、毎回こんな指示を出しているとします。
・ですます調で書く
・感情を美化しない
・一般論だけで終わらせない
・教訓めいたまとめ方をしない
・品質審査を飛ばさずに進める
これを CLAUDE.md に書いておけば、「新しいセッションを始めるたびに読み直す」手間がなくなります。ブログ自動化の土台となる仕組みです。
AIでブログ運営を自動化する5ステップでも解説していますが、CLAUDE.md はブログ自動化全体のインフラ的な役割を果たします。
/init で最初の CLAUDE.md を作る手順
まだ CLAUDE.md がないプロジェクトで最初に使うのが /init コマンドです。
Claude Code のインストールがまだの方は、Claude Code の始め方と初期設定をご覧ください。
/init の実行手順
- Claude Code でプロジェクトフォルダを開く
- チャット入力欄に
/initと入力してEnterを押す - Claude Code がプロジェクトの内容を分析し、CLAUDE.md の下書きを生成する
生成される内容はこのようなイメージです（プロジェクトによって異なります）。
# Project Overview
This is a blog automation project using Claude Code.
## Key Technologies
- Markdown / YAML frontmatter
- WordPress REST API
- Python scripts
## Development Guidelines
- Follow existing file naming conventions
- Use UTF-8 encoding for all files
生成後にやるべき3つのこと
/init で生成されたファイルはあくまで出発点です。そのまま使うのではなく、以下の3点をまず行います。
1. 不要なセクションを削除する
/init は汎用的な内容を生成します。ブログ運営なら「Development Guidelines」の部分を丸ごと書き直すことになります。
2. 方針・役割・禁止事項の3本柱を書き足す
後述しますが、これが CLAUDE.md の核心部分です。
3. 他ファイルへの参照を整理する
詳細ルールは CLAUDE.md に全部書かず、別ファイルに分離します（rules/、agents/ など）。これも後で説明します。
何を書くか — ブログ運営なら「方針・役割・禁止事項」の3本柱
CLAUDE.md に何を書くかについて、上位の解説記事では「WHAT（何をするか）」「WHY（なぜするか）」「HOW（どうするか）」の3層構造を提案しているものが多いです。これはコーディング規約の文脈では有効な整理です。
でも、ブログ運営に翻訳すると、方針・役割・禁止事項 の3本柱の方がしっくりきます。実際に運用してみてそう感じました。
柱1：方針（どんなブログを作るか・文体・価値観）
ブログ運営において、AIに最初に理解させるべきは「このブログの方針」です。ターゲットは誰か、どんな文体で書くか、読者との距離感はどうするか。
実際に使っている親プロジェクトの CLAUDE.md から、「書き方の原則」セクションを抜粋します。
# 書き方の原則
## 文体の方針
- です・ます調
- やわらかい
- 誠実
- 安心感がある
- 読者を見下さない
- 説教しない
- 正解を押しつけない
- 一緒に考える距離感
- 未完成の自分として書く
- 感情を美化しすぎない
## 避けたいもの
- 不自然に感動的な文章
- 成功談に寄せすぎた語り方
- 強すぎる断定
- 一般論だけで終わるまとめ方
- いかにもAI的な無難な文章
箇条書きが多いですが、これで十分です。「わかりやすい文章を書く」という抽象的な指示より、「感情を美化しすぎない」「強すぎる断定は避ける」という具体的な指示の方が Claude Code には伝わります。
柱2：役割（AIに任せること・自分に残すこと）
ブログ運営では、AIと人間の役割分担を明確にしておくことが重要です。何でも AI に任せてしまうと、書き手の個性が消えます。
実際に使っている CLAUDE.md からの抜粋です。
## AIに任せたいこと
- 情報やメモの整理
- 主張の明確化
- 構成案の作成
- SEO観点での補助
- 言い回しや文体の整形
- Markdownや公開形式への整形
- SEO記事で個別性を入れる場所の提案
- 必要な質問の設計
## 自分に残したいこと
- 何を一番言いたいか
- 実際にあったこと
- その時どう感じたか
- どこに違和感や引っかかりがあったか
- 自分なりの視点や考え
この「任せること／残すこと」の分離が、ブログの個性を守る核心だと思っています。
柱3：禁止事項（やってはいけないこと）
禁止事項は、やんわりした「〜を避ける」ではなく、明確に「禁止」として書く方が Claude Code への伝達力が高いです。
# 禁止事項
## 内容面
- 事実にないことを足さない
- 感情を美化・演出しない
- 成功談や感動話に寄せない
- 教訓でまとめない
- 説教口調にしない
- 一般論だけの記事を作らない
## 進行面
- 品質審査を飛ばさない
- 他の役割の主務を勝手にやらない
- 書き手の言葉・体験・感情を無断で変えない
「禁止」という言葉を使うことで、Claude Code が判断に迷ったときの優先順位が上がります。「やわらかく書く」という方針と、「説教口調にしない」という禁止事項が矛盾しているように見えても、禁止事項が優先されます。
何を書かないか — 書きすぎると AI が指示を無視する
CLAUDE.md は書けば書くほど良いわけではありません。これは運用してみて痛感しました。
200行問題：なぜ指示が無視されるのか
CLAUDE.md が長くなりすぎると、Claude Code がすべての内容を等しく優先できなくなります。おおよそ 200行を超えると遵守率が下がる というのは、複数の技術記事で指摘されている共通の知見です。
実際に何が起きるかというと、後半に書いた指示が無視されるようになります。「スタイルリファレンスを必ず参照する」という指示を150行目に書いたとして、80行目の禁止事項と比べると参照頻度が下がる、という具合です。
書くべきでないもの
| 書かない方がよいもの | 理由 |
|---|---|
| APIキー・パスワード | セキュリティリスク。環境変数で管理する |
| 変更頻度の高い情報 | 毎回書き換えが必要になる。別ファイルで管理する |
| 他ファイルと重複するルール | .claude/agents/ や rules/ と同じ内容を書かない |
| 手順の詳細すぎる記述 | 概要だけ書き、詳細は別ファイルに分離する |
実際にやった失敗：書きすぎて分離した話
最初に CLAUDE.md を作ったとき、「とりあえず全部ここに書こう」と判断しました。記事ライターの詳細指示、SEO設計担当の詳細指示、品質審査の基準、禁止事項、文体ルール……全部1ファイルに詰め込みました。
結果、400行を超えたあたりで Claude Code の挙動が不安定になりました。「品質審査を飛ばすな」という指示が守られないことが増えてきました。
対処として、各役割の詳細定義を .claude/agents/ フォルダの個別ファイルに分離しました。CLAUDE.md には「役割一覧と受け渡しの原則のみ」を残し、詳細は agents/seo-designer.md、agents/article-writer.md などに書くようにしました。
Before（400行超・指示が抜ける）
# 記事ライターの詳細仕様
## 入力
- SEO設計担当からの記事構成案
- 体験インタビュアーからの体験素材シート
## 出力
### 記事本文
- Markdown形式
- 見出し構成に沿った本文
- （以下100行続く）
After（CLAUDE.md は概要のみ・詳細は別ファイル）
## チーム役割（CLAUDE.md側）
| 役割 | 詳細定義ファイル |
|------|----------------|
| 記事ライター | `.claude/agents/article-writer.md` |
| SEO設計 | `.claude/agents/seo-designer.md` |
| 品質審査 | `.claude/agents/quality-reviewer.md` |
現在の CLAUDE.md は約200行に収まっています。
階層構造を使い分ける — Global・Project・Local・サブディレクトリ
CLAUDE.md は1ファイルで使うものではありません。4つの階層を使い分けることで、「全プロジェクト共通のルール」と「このプロジェクト固有のルール」を整理できます。
4階層の読み込み順と役割
~/.claude/CLAUDE.md ← ① Global（全プロジェクト共通の個人設定）
↓
{プロジェクトルート}/CLAUDE.md ← ② Project（チーム共有・メインの指示書）
↓
{プロジェクトルート}/CLAUDE.local.md ← ③ Local（Git管理外・個人上書き）
↓
{サブディレクトリ}/CLAUDE.md ← ④ Sub（特定フォルダだけに適用）
優先順位は後から読まれるものが高く、矛盾があれば上書きされます。
各階層に何を置くか
| 階層 | 置くもの | 例 |
|---|---|---|
| Global | 個人の作業スタイル・どのプロジェクトでも変わらない好み | 「回答は日本語で」「コードはコメントつきで」 |
| Project | プロジェクト固有のルール・チームで共有するもの | ブログの方針・役割設計・禁止事項 |
| Local | Gitに含めたくない個人設定・一時的なテスト用ルール | ローカル環境のパス・テスト中のルール変更 |
| Sub | 特定フォルダだけに適用したいルール | 記事執筆フォルダ専用の文体ルール |
実例：サブディレクトリ CLAUDE.md の使い方
このブログ自動化プロジェクトでは、blog-automation/ というサブフォルダに専用の CLAUDE.md を置いています。このファイルには、記事執筆に特化したルールが書いてあります。
# ✍️ 記事執筆ガイドライン
## 文体の基本ルール
- 丁寧でやわらかい文章（です・ます調）
- 説教しない
- 正解を押し付けない
- 読者と同じ目線で語る
- 「未完成の自分」として書く
## 記事構成（最重要）
必ず以下の流れで書くこと：
① きっかけ（出来事）
② 体験（具体的な場面）
③ 感情（そのときの正直な気持ち）
④ 自問自答（なぜそう感じたか）
⑤ 気づき（自分なりの答え）
⑥ 一般化（少しだけ広げる）
⑦ 読者への問い or 余韻
プロジェクトルートの CLAUDE.md には「チーム設計」や「運用ルール」を書き、サブディレクトリの CLAUDE.md には「記事執筆に集中したルール」を書く、という分担です。
実運用の CLAUDE.md を公開 — ブログ自動化プロジェクトの実物
競合記事との一番の違いを出せると思っているのが、このセクションです。ほとんどの解説記事は「こう書くべき」という推奨を提示するだけで、「実際に何ヶ月も運用しているファイルの生の抜粋」を公開しているものはほとんどありません。
このプロジェクトで使っている CLAUDE.md は3階層構造になっています。
3ファイルの役割分担
claudecode/
├── CLAUDE.md ← 親（全プロジェクト共通・約200行）
│ ブログ・note・ツール開発すべてに適用
├── ai-blog-automation-lab/
│ └── CLAUDE.md ← プロジェクト（halolab.jp専用・約300行）
│ ログルール・ハウツー記事の品質基準
└── blog-automation/
└── CLAUDE.md ← サブディレクトリ（記事執筆専用・約130行）
文体・記事構成・禁止事項
親 CLAUDE.md の主要セクション
親 CLAUDE.md には、すべてのプロジェクトに共通する「根幹方針」を書いています。
# このプロジェクトの根幹方針
- 目的（3つ）
- 基本思想（AIは補助役）
- AIに任せたいこと
- 自分に残したいこと
- AI活用の原則
# 書き方の原則
- 記事に求めるもの
- 文体の方針
- 避けたいもの
- SEO記事の方針
- 体験記事の方針
# チーム設計
- 設計思想
- 役割一覧（10役）
- 受け渡しの原則
# 判断基準
- 優先順位（6項目）
- 矛盾時のルール
# 禁止事項
- 内容面
- チーム運用面
- 進行面
# 運用ルール
- subagentの呼び出し
- 品質審査の独立性
- 委譲の基準
- 自動完走モード（詳細）
- セッション運用ルール
特に「判断基準」の「矛盾時のルール」は、書いておいてよかったセクションです。
## 矛盾時のルール
- SEO vs 個別性 → 個別性を残し、SEO構成をそれに合わせる
- 完成度 vs 自分らしさ → 未完成でも自分らしい方を選ぶ
- 効率 vs 書き手の関与 → 書き手を省略しない。関与が価値の源泉
- 収益 vs 読者の信頼 → 信頼を優先。収益は信頼の結果
- スピード vs 品質審査 → 品質審査を省略しない
これを書いておくことで、Claude Code が判断に迷ったときに自分で優先順位を解決できるようになります。
プロジェクト CLAUDE.md の主要セクション
ai-blog-automation-lab/CLAUDE.md には、このブログプロジェクト固有のルールを書いています。
# 最重要ルール（ログが成果物）
- 作業後のログ保存ルール（5項目）
# ログ運用の階層
- 会話ログ / 作業ログ / 日次ログ / 意思決定ログ
# ハウツー記事の具体性ルール（6項目）
1. 読者が実際にやる手順を番号付きで明記
2. Claude Code への指示文の例をコードブロックで提示
3. 設定ファイルの実サンプル
4. スクリプトの擬似コードor短い実コード片
5. つまずきと解決を具体名で
6. 実数値（費用・本数・時間・上限値）
# ブログの基本方針
# Claude Codeの役割
# 文体ルール
# 中長期方針
# 禁止事項
「ハウツー記事の具体性ルール」を CLAUDE.md に書いたのは、以前に書いた記事が「内容が乏しい。もっと具体的に書いて」と差し戻されたからです。差し戻しの理由を CLAUDE.md に反映することで、次の記事から同じ問題が起きなくなりました。
これが「育てる」ということです。
サブディレクトリ CLAUDE.md の主要セクション
blog-automation/CLAUDE.md には、記事執筆に特化したルールだけを書いています。
# 目的
- 記事の完成条件（4項目）
# 文体の基本ルール
# 記事構成（7ステップのフロー）
# 文章の核（弱さ→内省→前進）
# 感情表現ルール
# 一般論の扱い（20〜30%以内）
# 禁止事項（8項目）
# 強みとして活かすこと
# 最後の一文ルール
このファイルが blog-automation/ フォルダ以下で Claude Code を使うときだけ自動読み込みされます。記事執筆以外のタスク（スクリプト修正など）で、余計なルールが適用されることを防ぎます。
合計で約 630行 になります。CLAUDE.md 1ファイルに書いたら確実に崩壊する量ですが、3ファイルに分散しているので、それぞれ200行前後に収まっています。
AI に「戦略を考えて」と頼んだら別人の戦略が返ってきた話は note で書いています。CLAUDE.md を作る前に読むと判断軸が見えてきます。
note：AI に戦略を考えてと頼んだら別人の戦略が返ってきた話
CLAUDE.md を育てる — 最初に書いたものと1ヶ月後の変化
CLAUDE.md は一度書いて完成するものではありません。実際の運用を経て、何度も書き直してきました。
v1（最初の状態）の構成
最初に書いた CLAUDE.md はシンプルでした。
# プロジェクト概要
# 文体ルール
# 禁止事項
3セクション、50行程度。「まずは書いてみよう」という気持ちで始めました。
1ヶ月後に加わったもの
+ # チーム設計（役割一覧・受け渡し原則）
+ # 判断基準（優先順位・矛盾時のルール）
+ # 運用ルール（品質審査の独立性・自動完走モード）
+ # セッション運用（タスク化・ログ紐付け）
# 文体ルール（変更なし）
# 禁止事項（内容を大幅追加）
- # 役割ごとの詳細手順（削除・agents/に分離）
- # 個別ツールの操作手順（削除・別ファイルに分離）
具体的に何が変化したか
追加したもの
- 「チーム設計」セクション：記事ライター・SEO設計・品質審査など、役割を分けて Claude Code をサブエージェントとして呼び出す設計が必要になった
- 「矛盾時のルール」：「SEO vs 個別性」のような矛盾が実際に発生し、Claude Code が迷う場面が出てきた
- 「自動完走モード」：インタビュー完了済みの素材から記事→審査→公開を自動連鎖させる仕組みを作った
- 「品質審査の独立性」：自己審査（自分で書いた記事を自分でチェック）の問題に気づき、別の subagent で審査するルールを追加した
削除・分離したもの
- 役割ごとの詳細手順：
.claude/agents/フォルダの個別ファイルに移した。CLAUDE.md には「役割一覧と参照先パス」だけを残した - 個別ツールの操作手順：
article_workflow.mdなどの専用ファイルに移した
禁止事項の変化（Before → After）
最初の禁止事項。
# 禁止事項（v1）
- 感情を美化しない
- 説教しない
- 一般論だけの記事にしない
1ヶ月後の禁止事項。
# 禁止事項（現在）
## 内容面（6項目）
- 事実にないことを足さない
- 感情を美化・演出しない
- 成功談や感動話に寄せない
- 教訓でまとめない
- 説教口調にしない
- 一般論だけの記事を作らない
## チーム運用面（5項目）
- 品質審査を飛ばさない
- 他の役割の主務を勝手にやらない
- 書き手の言葉・体験・感情を無断で変えない
- 戦略判断を編集長に相談せず決めない
## 進行面（最重要・厳守）
- 質問は1回につき1問だけ（複数問まとめて出さない）
- 現ステップの確認なしに次に進まない
「質問は1回につき1問だけ」という禁止事項は、実際に「複数問をまとめて提示された」という体験から追加しました。CLAUDE.md は「書き手が困ったこと」を記録していく場所でもあります。
育てるタイミング
経験上、CLAUDE.md を更新するのは次の2つのタイミングです。
- Claude Code が指示を守らなかったとき：指示の書き方が曖昧だったか、ファイルに書いていなかったかのどちらかです
- 運用で例外が出たとき：「通常はこうするが、〇〇のときは△△」という例外を書き足す
逆に言えば、「特に問題が起きていない」なら無理に更新しなくていいです。
周辺ファイルとの使い分け — rules / skills / agents / commands / Hooks / Memory
CLAUDE.md は単独で使うものではなく、周辺ファイルと役割を分担して使います。
何をどこに書くか
| ファイル・フォルダ | 書くもの | 使いどき |
|---|---|---|
CLAUDE.md |
プロジェクトの方針・役割一覧・禁止事項・判断基準 | セッションをまたいで常時適用したいルール |
.claude/rules/ |
ファイルパターン別のルール（.md なら〇〇、.py なら〇〇） |
ファイル種別で動作を変えたいとき |
.claude/skills/ |
特定の作業手順をパッケージ化したスキル定義 | 「記事公開フロー」「リライト分析」など、複数ステップの定型作業を1スキルにまとめるとき |
.claude/agents/ |
subagent の役割定義（入力・出力・やること・やらないこと） | Agent ツールで呼び出すサブエージェントを設計するとき |
.claude/commands/ |
カスタムスラッシュコマンドの定義 | 「/review」「/publish」など繰り返し使う処理を1コマンド化するとき |
| Hooks | ファイル保存・ツール呼び出しのタイミングで自動実行するスクリプト | 「お願い」ではなく「強制」したい処理（フォーマット自動修正など） |
| Memory | Claude が自動更新する会話メモ | セッション間でユーザーの好みや文脈を引き継ぐとき |
agents/ との使い分けが特に重要
ブログ運営で Claude Code をチームとして使う場合、agents/ との使い分けが重要です。
CLAUDE.md には「役割一覧と参照先パス」だけを書きます。
## チーム役割（CLAUDE.md側）
詳細定義は各agentファイルを参照：
- 記事ライター: `.claude/agents/article-writer.md`
- SEO設計: `.claude/agents/seo-designer.md`
- 品質審査: `.claude/agents/quality-reviewer.md`
agents/ の個別ファイルには、その役割の詳細を書きます。
# article-writer.md（記事ライター）
## 役割の要約
SEO設計担当が作った構成と、体験インタビュアーが整理した
体験素材を統合し、実際の記事本文を書く担当。
## 入力
- 競合分析レポート（00_competitor_analysis.md）
- 記事構成案（03_structure.md）
- 体験素材シート（02_interview_material_v*.md）
## 出力
- 04_draft_v{N}.md（frontmatter 7項目含む記事本文）
- 04_meta_v{N}.md（タイトル案・自己チェック結果）
この分離をしておくことで、CLAUDE.md は「憲法」、agents/ ファイルは「各部署の業務規定」という構造になります。
subagent の詳細な設計方法は、別記事で解説する予定です。
よくある質問
Q: CLAUDE.md と .cursorrules は何が違うの？
.cursorrules は Cursor エディタ専用のプロジェクト指示ファイルです。CLAUDE.md は Claude Code 専用です。どちらも「AIへのプロジェクト指示書」という役割は同じですが、読み込む AIツールが異なります。
Cursor を使っている場合は .cursorrules、Claude Code を使っている場合は CLAUDE.md を使います。両方使っている場合、それぞれ別ファイルで管理することになります。
Q: CLAUDE.md を書いたのに AI が指示を守らないときはどうすれば？
主な原因は3つです。
1. 行数が多すぎる（200行以上）：後半の指示が無視されやすくなります。.claude/agents/ などに分離して、CLAUDE.md 自体を200行以内に収めます。
2. 指示が曖昧：「わかりやすく書く」より「箇条書きは使わない」「結論は最後に書く」の方が伝わります。
3. コンテキストと関連性が低い：CLAUDE.md の内容と今のタスクが遠い場合、読み込まれていても参照されにくくなります。サブディレクトリの CLAUDE.md に分離して、関連性を高めます。
まとめ — あなたのブログに合った CLAUDE.md を書こう
CLAUDE.md はコーディング規約のためだけのファイルではありません。ブログ運営・コンテンツ制作・情報整理など、どんなプロジェクトでも使えます。
今日から始めるなら、この3ステップで十分です。
ステップ1：/init で始める
Claude Code でプロジェクトを開き、/init を実行します。自動生成されたファイルを土台にして編集します。
ステップ2：方針・役割・禁止事項の3本柱を書く
ブログなら「どんな文体で書くか」「AIに任せることと自分に残すことの分担」「やってはいけないこと」の3点を書くだけで、Claude Code の動きが大きく変わります。
ステップ3：運用しながら育てる
「指示が守られなかったとき」「例外が出たとき」に書き足していきます。最初から完璧なものを作ろうとせず、使いながら更新する感覚でいいと思います。
ブログ自動化の全体像については、AIでブログ運営を自動化する5ステップで解説しています。CLAUDE.md はその仕組みの土台になる部分です。
自分のプロジェクトに合った CLAUDE.md を作り、少しずつ育てていけるといいですね。
