新しいチャットを開くたびに「また同じことを説明している」という感覚が続いていた。Claude Codeを使い始めた方なら、同じ場面を経験しているかもしれない。CLAUDE.mdというプロジェクト情報ファイルの使い方を整理し直したときの記録——情報を2種類に分ける考え方と、設計後に何が変わったかを書く。同じ状況を感じていた方に、設計を変えるひとつのきっかけとして読んでもらえたら。
公開してから気づいた、AIへの説明コスト
サイトを公開して数週間が経ったころ、2つの問題が同時に目についた。
一つ目は、CLAUDE.md（AIへのプロジェクト説明ファイル）が長くなりすぎていたこと。自分で読み返してみると「どこに何が書いてあるか」が追いづらく、これではAIも正確に読み取れないと感じた。
二つ目は、新しいセッションを始めるたびに「このサイトのターゲットペルソナはこうで、こういう方針で運営していて…」と毎回前置きをしていたこと。書いている途中で「これ、前も説明したな」と気づく場面が何度もあった。
どちらも根っこは同じだった。AIへの情報の渡し方が設計されていなかった。
情報を2種類に分けることにした
最初はCLAUDE.mdにサイト運用のルールをすべてまとめていた。ペルソナ・文体ガイド・GA4の設計方針・デプロイ手順——「AIに知っておいてほしいこと」をそのまま一つのファイルに詰め込んでいた形だ。しかし調べていくうちに、CLAUDE.mdはそういった設計思想のファイルではないと分かってきた。AIへの「変わらないルール」を置くためのファイルだ、というのが本来の使い方だった。
整理していくと、AIに渡す情報には2種類あることが見えてきた。
- 永続的に渡す情報：プロジェクトの方針・ルール・コンセプトなど、毎回共通して前提にしてほしいもの
- テーマ別に参照させる情報：GA4の設計・文体ルール・デプロイ手順など、特定の作業時だけ参照すればいいもの
前者はCLAUDE.mdに置く。後者はdocs/配下にテーマ別のファイルとして置き、必要なときだけ参照させる。
これを分けることで、CLAUDE.mdには「このプロジェクトで常に守ってほしいこと」だけが残るようになった。
何を入れないかを先に決める
前述のように、最初は運用ルールを全部詰め込んでいた。気づくと、プロジェクト概要・技術構成・過去の経緯・運用ルール・文体ガイドが一つのファイルに混在していた。自分で読んでも何が核心なのか分かりにくくなっていた。
GA4のイベント設計と同じ構造だと気づいたのはそのときだった。GA4は「計測できるものを全部入れる」のではなく、「何を計測しないか」を先に決めることで機能する。自分がNotionで経験したのも同じ構造で、全ての情報を一か所に詰め込むと使いにくくなった。
AIへの情報設計も同じで、「何を入れないか」を決める判断が安定につながった。
CLAUDE.mdには永続契約（プロジェクトの基本方針・守ってほしいルール）だけを置き、テーマ別の詳細はdocs/に分けた。肥大化してきたら分割する、という運用ルールも同時に決めた。
サイト立ち上げ直後のCLAUDE.mdは、こんな状態だった。まさに制作メモ。作業が進むほど、情報が増えていくような形だ。
## 進捗状況（2026-05-22）
### ✅ 完了済み
- [x] LocalWP インストール・起動確認
- [x] Cocoon子テーマ インストール・有効化
- [x] GA4プロパティ作成・測定ID取得
...（実装チェックリストが延々と続く）
## GA4 イベントマップ
| イベント名 | 発火条件 |
|------------------------|--------------------------|
| top_cta_exp_click | 「実験を見る」クリック |
...（全イベントのテーブルが埋め込まれていた）
## ブランド
- キャッチ：AI×Web制作×GA4を試行錯誤する実験メディア
- 運営者：AO / X：@AO_weblab
...（ブランド詳細・ドメイン一覧が続く）整理は3段階で進んだ。まず実装チェックリストをTODO.mdに切り出した。次にGA4マップや技術構成など「更新が続く情報」をdocs/配下のファイルへ移した。最後に残ったブランド詳細やドメイン一覧も参照先だけ書いて本文を削った。
整理後のCLAUDE.mdはこうなった。「永続契約」はAIへの変わらないルールをまとめるために自分でつけたセクション名だ。
## 永続契約
- 不明な点は推測で進めず、着手前に質問する
- 指示された箇所のみ変更する
- 確信が持てない場合は「確証がありません」と先に述べる
## コンセプト
AI×Web制作×分析の実験メディア。LPを作り、GA4で計測し、改善を繰り返す記録サイト。
## ブランド・ドメイン
- サイト名：Web制作実験室 / 運営者：AO（X：@AO_weblab）
- 詳細 → docs/operations.md
詳細ドキュメント索引 → docs/README.md残ったのは「変わらないルールだけ」で、ボリュームは80行程度に納めている。
進捗チェックリストは完了すれば不要になるし、GA4マップは実験のたびに更新される。どちらもCLAUDE.mdに置く必要はなかった。
整理した後で気づいたことだが、最初からこの分け方を知っていれば、立ち上げ段階から設計できた。次のプロジェクトを始めるときは、Claude Codeを立ち上げた最初のチャットに、こういう順番で入力するつもりだ。
新しいプロジェクトを始めます。以下の方針でCLAUDE.mdの初期構成を作ってください。
方針：
- CLAUDE.md には変わらないルール・コンセプトだけを置く
- 更新頻度の高い情報（進捗・設計書・手順）は docs/ に分けて参照させる
プロジェクト概要：[概要を書く]上記のプロジェクトで docs/ 配下に置くべきファイルを、テーマ別（ドメイン型）で提案してください。
README.md を目次として、各ファイルの役割を一行で添えてください。フォルダの設計方針を先に決める
情報の種類が決まると、次は置き場の整理が問題になった。フォルダの構成自体にも、設計の方針が必要だということだ。
このサイトではdocs/配下に、ga4-events.md・writing-style.md・deploy.mdといったファイルをテーマ別に置いている。情報管理の整理方法のひとつで、自分が「ドメイン型」と整理している分け方があり、このサイトのやり方はそれに近い（Webのドメイン名とは別の概念）。
もう一つ、自分が「ライフサイクル型」と整理している分け方がある。どちらが優れているかではなく、自分のプロジェクトをどう管理したいかによって選ぶ観点のひとつとして整理しておく。
- ライフサイクル型：情報の「完成度・状態」を軸に分類する。inbox（未整理）→ draft（作業中）→ output（完成物）→ archive（使い終わり）という流れ。記事を書く・議事録を作るといった、成果物を生産する作業に向いている。ToDoリストやタスク管理ツールに近い発想
- ドメイン型：情報の「領域・テーマ」を軸に分類する。知識やルールを継続的に参照・更新する運用に向いている。WikiやNotionのページ分類に近い
このサイトは継続運用のプロジェクトなので、ドメイン型の方がしっくりきた。ga4-events.mdを開くとき「これは完成物か下書きか」より「GA4の設計情報である」という属性の方が重要だったからだ。
Claude Codeのようなツールは、自分のパソコンのフォルダを直接参照しながら動くAIなので、フォルダの構成がそのままAIへの文脈になる。フォルダの設計方針を先に整えておくと、AIへの文脈のつながりが変わってきた。
設計してから変わったこと
渡し方を整えてから、いくつかの変化があった。
- 指示が短くなった：毎回5〜10分かかっていた前置き説明が不要になり、「この記事のリード文を書いて」だけで伝わるようになった
- AIの返答のばらつきが減った：同じ指示でも、セッションによって文体やトーンがばらついていたのが落ち着いた
- 「AIが何を知っているか」を自分が把握できるようになった：CLAUDE.mdとdocs/のどちらに何があるかが整理されていると、「この指示には何の情報が必要か」を自分でも判断しやすくなった
ただ、完全に解決したわけではない。docs/のファイルが増えてくると「あの情報はどのファイルに書いたか」を探す手間が生まれてきた。「何を入れないか」を決めたように、「何をどのファイルに置くか」も継続的に見直す必要がある。今は、READMEを目次として使い、どこに何があるか・どの作業にどのスクリプトを使うかが一覧で確認できる体制で試している。
AIに渡す情報を設計することが、そのまま指示の設計につながっていると気づいた。
観察して分かったこと
- AIはセッションをまたいで記憶を持たないため、「永続的に渡す情報」と「テーマ別に参照させる情報」を分けて管理すると、AIの返答のばらつきが減った
- フォルダ設計には「ライフサイクル型（状態で分ける）」と「ドメイン型（領域で分ける）」があり、継続運用のプロジェクトにはドメイン型が合いやすかった
- CLAUDE.mdは書きすぎると機能しなくなる。GA4やNotionと同じで、「何を入れないか」の判断が、自分の場合はAIの返答の安定につながった
Xで制作の記録を随時発信しています。@AO_weblab