CLAUDE.mdを育てたら、Claude Codeが別物になった——実例付き完全ガイド

2026年3月10日2026年3月12日

URLをコピーしました！

攻略本なしでRPGをクリアしようとするプレイヤーを想像してください。ゲーム自体はクリアできるかもしれませんが、隠し要素や効率的な進め方を知らないまま、無駄な時間を費やすことになります。Claude CodeをCLAUDE.mdなしで使うのは、まさにその状態です。

毎回「このプロジェクトはTypeScriptで書いています」「テストはVitest使っています」「.envはコミットしないでください」——同じことを説明し続けていませんか？CLAUDE.mdを正しく育てれば、そのすべてが不要になります。

CLAUDE.mdとは何か

CLAUDE.mdはClaude Codeが自動的に読み込む「永続的な指示書」です。プロジェクトのルートディレクトリに置くだけで、Claude Codeはセッション開始時にその内容を記憶した状態で動き始めます。

通常、AIとの会話はセッションをまたいで記憶が引き継がれません。しかしCLAUDE.mdがあれば、プロジェクト固有のルール・技術スタック・禁止事項をClaude Codeに「常識」として持たせることができます。一度書けば、毎回説明する手間がゼロになるわけです。

絶対に書くべき5項目

1. プロジェクト概要（技術スタック・言語・フレームワーク）

Claude Codeが最初に把握すべき情報です。ここが曖昧だと、適切でない言語やライブラリの提案が返ってきます。

## プロジェクト概要
- **サイト**: GitHub Pages（main ブランチ / ルート配信）
- **技術スタック**: HTML / CSS / JavaScript（バニラ）、Firebase RTDB、WordPress REST API
- **言語**: 日本語メイン
- **デプロイ**: main ブランチへの push で自動反映

2. コーディング規約（命名・インデント・コメントの方針）

プロジェクトごとに統一したいルールを明記します。特に複数ファイルにまたがる作業では、一貫性が重要です。

## コーディング規約
- インデント: スペース2つ（HTMLもJSも統一）
- 変数名: camelCase（JS）、kebab-case（CSS クラス名）
- コメント: 日本語で書く。「何をしているか」より「なぜそうしているか」を書く
- 関数は1つの責務のみ。100行超えたら分割を検討する

3. 絶対NGライン（commitしてはいけないもの・触ってはいけないファイル）

セキュリティと運用の観点で最も重要な項目です。ここを明示しておくと、うっかりミスをClaude Code側でも防いでくれます。

## NGライン（必ず守ること）
- `.env` ファイルは絶対にコミットしない（.gitignore 必須）
- APIキー・トークンをコードにハードコードしない
- `dist/` `node_modules/` は編集しない
- main ブランチへの直接 push はしない（PR経由のみ）
- 機密情報を含むファイルを公開リポジトリに push しない

4. よく使うコマンド・ワークフロー

Claude Codeが作業の流れを把握できると、一連のタスクをスムーズに実行できます。「commit したら push する」などの暗黙のルールを明示しましょう。

## ワークフロー
- **開発**: feature ブランチで作業 → PR → main マージ
- **commit したら毎回 push する**（確認不要）
- push 後は `open` コマンドでページを開いて確認する
- デプロイ確認: `curl -s https://example.com | head -20`
- ログ確認: `tail -f logs/app.log`

5. モデル使い分けルール（重い作業はOpus・定型はSonnet）

Claude Codeはデフォルトで起動時のモデルを使い続けます。どの作業にどのモデルを使うかをあらかじめ定義しておくと、コストと品質のバランスが最適化されます。

## モデル使い分け
**Sonnet のまま進める作業:**
- コード編集、バグ修正、ファイル操作
- 既存パターンに沿った実装・定型タスク
- データ更新、ファイル変換

**Opus への切替を提案する作業:**
- 新機能のゼロからの設計・実装
- アーキテクチャ変更・大規模リファクタ
- CLAUDE.md・運用ルールの改定
- 複数システムにまたがる横断的な作業

育て方のコツ——最初から完璧を目指さない

CLAUDE.mdは「完成品」を最初から作る必要はありません。むしろ、作業しながら気づいたことを随時追記する運用が現実的です。

たとえば作業中に「あ、これ毎回説明しているな」と気づいたら、その場でCLAUDE.mdに追記します。「このAPIはPATCHではなくPOSTしか受け付けない」「画像は medium サイズを使う（large は 403 になる）」——こういった細かい注意事項の蓄積が、Claude Codeの精度を上げていきます。

目安として、プロジェクト開始時は10〜20行、1ヶ月後には50行、安定してきたら100行前後になるのが自然な成長ラインです。

実際のCLAUDE.md断片（BuildHub運営で使っているサンプル）

BuildHubの運営で実際に使っているCLAUDE.mdの一部を公開します。

## BuildHub WordPress設定
- WP REST API エンドポイント: https://www.buildhub.jp/wp-json/wp/v2/
- カテゴリ: Claude Code(2), AI開発ツール(3), ニュース(4), まとめ記事(1)
- 記事投稿前に必ずスラッグ重複チェックを実行する
- アイキャッチ: Pexels API で取得（顔なし画像のみ使用）
- WAF注意: SiteGuard が PUT/PATCH/DELETE をブロックする → POST のみ使用

## 自動処理ルール
- セッション開始時にフックが AUTO-PROCESS を出力した場合、確認なしで自動実行する
- Firebase pending キューを取得 → Gemini で変換 → WP 投稿 → 完了マーク
- エラーが出たら自己診断して修正を試みる。3回失敗したら詳細を報告する

## 鉄則
1. commit したら毎回 push する（確認不要）
2. push 後は open コマンドでページを開いて確認する
3. 新ページ・ツールを追加したら apps カタログへの追記も同時に行う

このように、APIの仕様・運用ルール・ワークフローの組み合わせで、Claude Codeが「勝手に正しい判断をしてくれる」状態を作れます。