Claude Codeを本格的に使い始めて半年ほど経ちました。毎日のようにターミナルでClaude Codeを立ち上げて仕事をしているのですが、振り返ると一番試行錯誤したのがCLAUDE.mdの書き方だったなと思います。
私の業務はプロダクト戦略の策定や事業開発がメインで、ソフトウェア開発ではありません。市場調査をしたり、企画書の草案を作ったり、会議のアジェンダを整理したり。そういった日常業務をClaude Codeに手伝ってもらっています。最初は「AIにコードを書かせるツールでしょ？」と思っていたのですが、実はドキュメント管理やリサーチ、業務の自動化にもかなり使えることが分かってきました。
ただ、CLAUDE.mdを適当に書いていた頃は正直微妙でした。「さっき言ったのに同じミスする」「毎回同じことを説明している」が続いて、CLAUDE.mdにちゃんと向き合う必要があるなと気づいたのが運用3週目くらいだったと思います。
この記事では、半年間の運用で分かったCLAUDE.mdの実践的な育て方を書いていきます。テンプレートだけ貼って終わりではなく、どう設計して、どう分割して、どう鮮度を保つか。公式ドキュメントにはあまり書かれていない運用面の話が中心です。エンジニアではない方にも参考になるように書いたつもりなので、PM・企画職・事業開発の方はぜひ読んでみてください。
最初のCLAUDE.mdは3つだけ書けばいい
いきなり完璧なCLAUDE.mdを作ろうとすると手が止まります。最初に書くのは3つだけで十分です。
1. あなたの役割（Claude Codeに何をしてほしいか、2-3行） 2. 業務コンテキスト（どんな仕事をしているか、箇条書きで） 3. 禁止事項（やってほしくないこと）
具体的にはこんな感じになります。
## あなたの役割 あなたは[プロジェクト名]の戦略策定・事業開発を支援するAIアシスタントです ## 基本ルール - 日本語で応答 - 簡潔に、事実と推論は分ける - ソースを明示 ## 禁止事項 - 機密情報（社名・プロダクト名・事業数値）を外部に出さない - ファイルを勝手に削除しない - 推測で数字を作らない（データがなければ「不明」と明記）
この中で一番効果が高いのは、3番の禁止事項です。「推測で数字を作らない」「ファイルを勝手に削除しない」のように、具体的な行動レベルで書くだけでClaude Codeの振る舞いがかなり安定します。逆に「丁寧に仕事して」のような抽象的な指示はほとんど効きません。
注意したいのは、禁止事項を「あれもダメ、これもダメ」と10個も20個も並べないことです。数が多いと後半のルールが守られにくくなる傾向がありました。最初は3つ以内がお勧めです。
テンプレートは記事末尾に載せておきますが、まずは空のCLAUDE.mdを作って、この3つを書くところから始めてみてください。
半年で見つけた設計パターン
ここからが本題です。CLAUDE.mdを半年間運用する中で「最初から知っておきたかった」と思った設計パターンを紹介します。
コンテキストウィンドウの圧迫問題
CLAUDE.mdに書いた内容は、Claude Codeが毎回のセッション開始時にコンテキストウィンドウに読み込みます。つまり、CLAUDE.mdが長くなればなるほど、本来の作業に使えるコンテキストが減っていくわけです。
私の場合、業務で使うルールや手順を詰め込んでCLAUDE.mdが200行を超えたあたりから、長い会話の後半でルールを見落とす頻度が上がった実感がありました。「全部入り」で書くのではなく、本当にセッション冒頭で読んでほしい情報だけをCLAUDE.mdに残すのが重要だと気づいた瞬間でした。
@インポート記法で分割する
CLAUDE.mdが100行を超えてきたら、分割を検討するタイミングです。Claude Codeには @ファイル名 というインポート記法があり、CLAUDE.mdから他のマークダウンファイルを参照できます。
# CLAUDE.md @AGENTS.md ## 基本方針 ...
この @AGENTS.md と書くだけで、AGENTS.mdの内容もCLAUDE.mdと同じように読み込まれます。これを知ってから、CLAUDE.md本体は「基本方針と最重要ルール」だけに絞り、業務の詳細手順やエージェント設定は別ファイルに分離する設計に変えました。
もう一つの分割先として .claude/rules/ ディレクトリがあります。ここにマークダウンファイルを置くと、CLAUDE.mdに明示的にインポートしなくても自動で読み込まれます。日時表記のルール、外部ツール連携の手順など、特定ドメインのルールはこちらに分離すると管理しやすいです。
整理すると、こういう使い分けになります。
| 場所 | 役割 | 分割の目安 |
|---|---|---|
CLAUDE.md |
基本方針・概要・最重要ルール | 100行以内を推奨 |
@参照先（例: AGENTS.md） |
エージェント設定、業務手順書等 | 明示的に読ませたい情報 |
.claude/rules/*.md |
特定ドメインのルール | 自動読み込み。ルールが3つ以上になったら分離 |
プロジェクトCLAUDE.md vs ユーザーCLAUDE.md
意外と知られていない話なのですが、CLAUDE.mdには2つの階層があります。
- プロジェクトCLAUDE.md: リポジトリ直下に置く。そのプロジェクト固有の設定
- ユーザーCLAUDE.md:
~/.claude/CLAUDE.mdに置く。全プロジェクト共通の設定
たとえば「日本語で応答する」「レポートのフォーマットはこう」のようなルールは、プロジェクトごとに書くのではなく、ユーザーCLAUDE.mdに一度書けば全プロジェクトに適用される仕組みです。
同様に、~/.claude/rules/ に共通ルールを置くこともできます。日時表記のルール（必ず日本時刻基準で書く等）や応答スタイルの基本方針はユーザー側に置いて、プロジェクト固有の業務コンテキストや機密情報の取り扱いルールだけをプロジェクトCLAUDE.mdに書く運用に落ち着きました。
memory機能との棲み分け
Claude Codeには ~/.claude/memory/MEMORY.md というメモリ機能も用意されています。CLAUDE.mdとの使い分けが最初は分かりにくかったのですが、半年使ってみて落ち着いた整理はこうでした。
- CLAUDE.md: 「こうしてほしい」というルール・方針。意図的に設計するもの
- memory: 「こうだった」という事実・学び。セッション中に蓄積されるもの
CLAUDE.mdは「業務マニュアル」、memoryは「引き継ぎメモ」と考えると分かりやすいかなと思います。memoryに溜まった教訓のうち、繰り返し重要なものはCLAUDE.mdに昇格させる、という流れに落ち着いています。
私の場合、最初は私の役割や業務内容、覚えてほしいことをCLAUDE.mdにどんどん書き足していました。結果、ルールがうまく機能しなくなり、書いてあるはずの指示が無視される場面が増えていった。今思えば、情報を詰め込みすぎてコンテキストが汚染されていたんですよね。転機になったのは「ハーネスエンジニアリング」という考え方に出会ったことで、「AIへのお願い」ではなく「AIが正しく動く環境を設計する」という発想にシフトしてから、状況が明らかに改善しました。
やらかした失敗と対策
半年も使っていれば当然失敗もあります。特に痛かったものを共有します。
数字を勝手に作られた話
これが一番堪えた失敗です。市場規模の試算をClaude Codeに頼んだところ、それっぽい数字が返ってきたのでそのまま資料に使いかけました。後からよく見ると、元データには存在しない数字が混ざっていたんですよね。
Claude Codeは「わかりません」と言うより、もっともらしい数字を生成してしまうことがあります。これ以降、CLAUDE.mdの禁止事項に「推測で数字を作らない。データがなければ『不明』と明記する」を追加しました。たった1行ですが、追加してからは数字の捏造がほぼなくなりました。
CLAUDE.mdが長すぎてルールが無視される
前述の通り、CLAUDE.mdが肥大化するとClaude Codeがルールを見落とすようになります。禁止事項を10個以上書いていた時期がありましたが、後半に書いたルールほど守られない傾向が明確にありました。
対策としては、CLAUDE.mdの冒頭に「最重要ルール」を3つ以内で置き、詳細は .claude/rules/ に分離する構成にしました。冒頭に書いたルールは体感的にかなり遵守率が高いです。
# CLAUDE.md ## 最重要ルール - ファイルを勝手に削除しない - 推測で数字を作らない - 日時は日本時刻基準で記載する ## 詳細ルール 詳細は `.claude/rules/` 配下を参照
失敗ログを書かなかった初期の後悔
最初の2ヶ月くらいは、Claude Codeが期待と違う動きをしても「まあいいか」で流していました。これが後で効いてきて、同じミスが何度も繰り返されることに。
途中から「過去の失敗から学ぶ」セクションを作り、具体的な失敗と対策を記録するようにしたところ、再発がかなり減りました。
## 過去の失敗から学ぶ - データの列ヘッダーを確認せず年度を取り違えた → 数値を扱う時は必ず列ヘッダーで年度・単位を確認 - ユーザーが提示した具体的数字を無視して独自の推定を行った → ユーザーが具体例を出したら、それを基準に計算する
ポイントは、失敗を「ルール」に変換してCLAUDE.mdに書くことです。「こうするな」と書くだけでなく「代わりにこうしろ」もセットで書くと、改善幅が大きいと感じています。
個人的に一番効果を実感したのは、特定ドメインの業務ルールを別ファイルに分離し、必要なものだけを読み込ませる設計に変えたことです。1つのワークスペースに複数プロジェクトのコンテキストが混在していたのですが、ドメインごとにルールファイルを分けたことで、そのタスクに必要な情報だけが参照されるようになった。余計なコンテキストの汚染が減り、Claude Codeの応答精度が体感で上がりました。
育てるサイクル -- 書いて、使って、直す
ここまで設計パターンと失敗談を書いてきましたが、結局CLAUDE.mdは最初から完成形を目指すものではなくて、使いながら育てていくドキュメントです。私が落ち着いた運用サイクルを簡単にまとめておきます。
1. 使う: いつも通りClaude Codeで作業する 2. 違和感を拾う: 「なんか違うな」と思った瞬間をメモする 3. ルール化する: 違和感を具体的な指示に変換してCLAUDE.mdに追記 4. 定期的に棚卸し: 月1回くらいで古いルールを見直す
3番が一番大事です。「もっと丁寧にやって」ではなく「レポートの冒頭に結論を3行で書く」のように、行動レベルまで落とし込む。抽象的な指示はClaude Codeにはほとんど通じません。
棚卸しも地味に重要で、プロジェクトの方針が変わったのに古いルールが残っていると、Claude Codeが矛盾した指示に混乱することがあります。不要になったルールは消す勇気も必要です。
テンプレート（付録）
最後にテンプレートを載せておきます。エンジニアではなく、PM・企画職・事業開発向けに書いたものです。ただし、テンプレートはあくまでスタート地点。ここまで書いてきた通り、本当に大事なのはここからどう育てるかのほうです。
# CLAUDE.md ## あなたの役割 あなたは[プロジェクト名]の戦略策定・事業開発を支援するAIアシスタントです ## 基本ルール - 日本語で応答 - 簡潔に、事実と推論は分ける - ソースを明示 ## 業務コンテキスト - 主な業務: 市場調査、競合分析、企画書作成、会議準備 - よく使うツール: Google Drive、社内Wiki、Slack - データ分析: SQL（BigQuery）で顧客データを分析 ## 禁止事項（最重要） - 機密情報（社名・プロダクト名・事業数値）を外部に出さない - ファイルを勝手に削除しない - 推測で数字を作らない（データがなければ「不明」と明記） ## よく使うスキル - 競合リサーチ: [手順の概要] - 週次レポート作成: [フォーマットの場所] - 会議アジェンダ準備: [テンプレートの場所] ## 過去の失敗から学ぶ （運用しながら追記していく）
「あなたの役割」のセクションは、チームで使う場合に特に効果を発揮します。「戦略参謀として振る舞う」「秘書として会議運営をサポートする」のように役割を明確にするだけで、応答のトーンや情報の出し方がガラッと変わります。
余談ですが、エージェントチーム（Claude Codeで複数のエージェントを同時に動かす運用）を始めてからは、エージェントごとにCLAUDE.mdの役割定義を変えるという使い方もするようになりました。リサーチ担当にはデータの正確性を重視するルール、企画担当にはアイデアの幅を出すルール、という具合です。ここまでくると最初の「3つだけ書く」とは随分遠い場所にきた感がありますが、育てた結果こうなったという話なので、焦る必要はありません。
CLAUDE.mdは書いて終わりではなくて、業務と一緒に育てていくドキュメントだと思っています。最初は3つだけ書いて、使いながら足していく。100行を超えたら分割する。失敗したらログを残す。この繰り返しで、半年前とは比べものにならないくらいClaude Codeとの作業がスムーズになりました。
エンジニアでなくても、CLAUDE.mdを丁寧に育てればClaude Codeは頼れる業務パートナーになります。ぜひ、まずは小さく始めてみてください。
