「前にも同じ形式で書くよう伝えたのに、また違う返し方をしてくる」「プロジェクトのルールを毎回説明し直している」「コンテキストが切れた途端、すべてが振り出しに戻る」——Claude Code を日常的に使い始めると、こうした小さな摩擦が少しずつ積み重なっていきます。
その多くは、CLAUDE.md を「思いついたことを書き足すメモ帳」として扱っていることに行き着きます。視点を変えて、CLAUDE.md を「新しく加わるメンバーへの引き継ぎ書」として設計すると、Claude Code の振る舞いは驚くほど安定します。ここでは、私自身が個人開発で複数のブログ運用を任せる中で効いた設計の勘所を、順を追って整理します。
CLAUDE.md を「設定」ではなく「引き継ぎ書」として捉える
Claude Code は、毎回はじめてプロジェクトに参加するメンバーのようなものです。前回の文脈は、こちらが明示的に残さない限り引き継がれません。だからこそ、「初参加の人にこれだけは伝えておきたい」という情報を、過不足なく置いておく場所が CLAUDE.md です。
この発想に立つと、何を書き、何を書かないかの判断が一気に楽になります。一時的なメモや思いつきは外し、繰り返し参照される前提知識だけを残す。これが設計の出発点です。
CLAUDE.md の 3 層階層
CLAUDE.md は 3 つのレベルに分けて配置できます。これが最も重要な設計判断です。
グローバル設定（~/.claude/CLAUDE.md）
すべてのプロジェクトに共通する「仕事のスタイル」をここに書きます。コーディングスタイル（インデント、命名規則）、コミュニケーションの言語と口調、よく使うツールやライブラリのバージョン、自分の役割や専門分野などです。
ポイントは「変わらないもの」だけを書くことです。プロジェクト固有の情報をここに入れると、他のプロジェクトでノイズになります。
プロジェクト設定（./CLAUDE.md）
プロジェクトのルートに置く CLAUDE.md には、そのプロジェクト特有の情報を書きます。技術スタックとアーキテクチャ、ディレクトリ構成、デプロイ手順、API エンドポイントの一覧、ブランチ戦略などです。
「このプロジェクトを初めて触る人に説明すること」をすべて書くイメージです。Claude Code はまさにその「初めて参加するメンバー」なので、このレベルの情報が最も効果を発揮します。
プロジェクトルール（.claude/rules/）
条件付きで適用されるルールを個別ファイルとして分けます。たとえば frontend.md にはフロントエンド作業時のみ適用するルールを、testing.md にはテスト関連のルールを置きます。
本体が肥大化せず、ルールの追加・削除が手軽になるのがこの方式の利点です。
最小構成から始める CLAUDE.md の骨組み
いきなり完璧を目指すと、書くこと自体がおっくうになります。私の場合は、まず次のくらいの薄さで始めて、つまずくたびに一行ずつ足していくやり方が続きました。
# プロジェクト概要
個人ブログの記事を自動更新するリポジトリ。Next.js + Markdown。
# 技術スタック
- Next.js（App Router）/ TypeScript
- 記事は content/articles/ 配下に Markdown で配置
# 開発フロー
1. content/ に記事を追加・編集
2. ビルドは CI に任せる（ローカルでの本番ビルドは不要）
3. push 前に記事の本数が想定どおりか必ず確認する
# 行動規範
- 検証が通らないうちはコミットしない
- ファイルの削除は最終手段にする
- 不確実な情報を確定事項のように書かない
# よくあるつまずき
- （気づいたら日付つきでここに追記していく）最初の数行は機能の説明ではなく、「自分が一度はまった落とし穴」で埋めていくのがおすすめです。説明的な前提よりも、こうした失敗由来の一行のほうが出力の安定にずっと効きます。
サブエージェント設計 — 「1 エージェント = 1 タスク」の原則
Claude Code のサブエージェント（Task ツール）を活かすには、各エージェントの責任を明確に分けるのが肝心です。
たとえばリサーチ系のタスクでは、Web 調査エージェント（情報収集）、技術深掘りエージェント（コード分析）、批判的分析エージェント（リスクや問題点の指摘）、統合エージェント（各結果をまとめる）のように分けます。
CLAUDE.md に呼び出しパターンを書いておくと、Claude Code は自動的にこのワークフローを再現します。「リサーチが必要な場合は、まず Web 調査サブエージェントで情報を集め、技術深掘りサブエージェントでコードレベルの分析を行い、最後に統合サブエージェントで結果をまとめること」のように、フローそのものを言葉で定義しておくイメージです。
外部メモリシステムの構築
Claude Code のセッションにはコンテキストウィンドウの制限があるため、長期的な記憶を外部ファイルで持たせる仕組みが有効です。
意思決定ログ
.claude/decisions/ を作り、重要な設計判断を記録します。日付・背景・選択肢・決定内容・理由を構造化して残すと、「なぜこの方式を選んだのか」を後から正確にたどれます。
文体・トーン設定
ドキュメントやコメントの文体をファイルに定義しておくと、Claude Code は一貫したスタイルで出力します。技術記事の執筆や、チーム内のコミュニケーションスタイルの統一に特に効きます。
進行状況ログ
「現在の作業状況を .claude/progress.md に記録すること」と書いておくと、セッションが切れても前回の続きから滑らかに再開できます。
行動規範の明文化 — 「焦ったら止まれ」
CLAUDE.md に行動規範を書くことは、品質を安定させるうえで最も過小評価されているテクニックだと感じています。
「エラーが出たら、自己判断で直す前に内容を報告すること」「ファイルの削除は必ず確認を取ること」「テストが通らないときはコミットしないこと」「不確実な情報を確定事項のように書かないこと」——こうした規範は、「過去にやらかしたことリスト」から逆算して作ると、そのまま実用的なルールになります。
複数プロジェクト・複数マシンで運用するときの工夫
CLAUDE.md がじわじわ効いてくると、別のマシンでも同じ品質で動かしたくなります。私はクラウド同期のフォルダにプロジェクトを置き、CLAUDE.md と外部メモリを共有しています。こうしておくと、どの端末から作業を始めても同じルールと引き継ぎノートを Claude Code が読み込めます。
ただし、同期している前提を一つ崩すと静かに効果が薄れます。私が痛い目を見たのは、CLAUDE.md にある「最新の方針」と、本体の自動化スクリプトに書かれた「古い手順」がずれていたケースでした。方針を更新したら、それを実行するスクリプト側も同じタイミングで合わせる——この二重管理を怠ると、CLAUDE.md だけが正しくて現場が古い、という食い違いが生まれます。方針を書き換えたら関連する実行プロンプトも一緒に直す、というルール自体を CLAUDE.md に明記しておくと、この種のずれを未然に防げます。
もう一つ実感しているのは、外部メモリを「設定」ではなく「育てる引き継ぎノート」と捉える感覚です。気づいたつまずきを日付つきで書き留めておくと、次に同じ場面へ来たとき Claude Code が自分でそれを参照し、同じ轍を踏まなくなります。書き足すたびに、協業の相手が少しずつ賢くなっていく手応えがあります。
次の一歩
まずは、いま使っているプロジェクトの CLAUDE.md に「行動規範」の節を一つだけ追加してみてください。過去に一度つまずいた出来事を思い出し、それを再発させないための一行を書く。それだけで、Claude Code との次のセッションから手応えが変わってくるはずです。