CLAUDE.md は Claude Code がセッション開始時に自動で読み込むプロジェクトの取扱説明書です。書いておくほど提案の精度が上がりますが、白紙から書き起こすのは案外おっくうなもので、結局空のまま放置されがちです。
そこでこの記事では、プロジェクト種別ごとにコピペで使える CLAUDE.md の雛形を配布します。まず共通ベースを置き、その上に Web フロントエンド・バックエンド / API・モノレポ・コンテンツ系の差分を載せる構成です。自社プロジェクトに合わせて削り込めば、5 分で実用的な CLAUDE.md が完成します。各項目がなぜ効くかは CLAUDE.md にこれを書くと品質が上がる 8 つの項目 で詳しく解説しているので、合わせて読むと理解が深まります。
テンプレートの使い方 — 自社プロジェクトへの当て込み手順
テンプレートは「埋める」のではなく「削る」発想で使うのがコツです。まず共通ベースをリポジトリ直下に CLAUDE.md として置き、自分のプロジェクト種別の差分セクションを追記します。そのうえで、当てはまらない行を消し、固有名詞(技術スタック・コマンド・ディレクトリ名)を実際の値に書き換えます。
書き換えの順番は、技術スタック → コマンド → ディレクトリ構成 → NG ルールの順がやりやすいです。技術スタックが決まればコマンドとディレクトリは芋づる式に埋まり、最後に「このプロジェクトで特に守ってほしいこと」を NG ルールとして足す流れになります。
注意点として、テンプレートをそのまま全部貼ると行数が膨らみ、読み込みトークンが増えて応答が遅くなります。300 行を超えそうなら詳細を別ドキュメントに切り出し、CLAUDE.md からはポインタで参照する形に保ってください。Claude Code の初期セットアップ全体の流れは Claude Code を実務に導入するセットアップガイド にまとめています。
共通ベース雛形 (概要・NG ルール・コマンド)
どの種別でも土台になる共通部分です。これだけでも置く価値があります。
# CLAUDE.md
## プロジェクト概要
- プロダクト名 / 会社名: ◯◯
- 概要: 一言で何をするものか (2〜3 行)
- 技術スタック: 言語・主要フレームワーク・インフラ
## 絶対遵守ルール (NG)
- main ブランチへの直接 push は禁止。必ず PR を作る
- 型エラー・lint エラーを残したままコミットしない
- 既存の命名規約・ディレクトリ構成に従う(勝手に新設しない)
- 不明点は推測で進めず、前提を明示して確認する
## コマンド
- セットアップ: ◯◯
- 開発サーバー: ◯◯
- テスト: ◯◯
- lint / format: ◯◯
- ビルド: ◯◯
## 作業の進め方
- 変更後は必ずテストと lint を実行して結果を確認する
- 1 コミット = 1 論理変更単位。コミットメッセージは変更意図を書くNG ルールは抽象的なベストプラクティスより、明示的な禁止条項のほうが守られます。「きれいに書く」ではなく「as any を使わない」のように、判定できる粒度で書くのがポイントです。
Web フロントエンド向けテンプレート
共通ベースに、以下を追記します。コンポーネント設計やスタイリングの方針を明示すると、AI が既存の流儀に沿った実装をしてくれます。
## アーキテクチャ方針
- React 18 + TypeScript + Vite。ルーティングは React Router
- スタイリングは Tailwind CSS。インライン style は使わない
- 状態管理はまずローカル state。グローバルが必要な場合は相談
## ディレクトリ構成
src/
├── components/ # 再利用 UI(ui/ は基本パーツ)
├── features/ # 機能単位のモジュール
├── hooks/ # カスタムフック
└── utils/ # 純粋関数のユーティリティ
## フロント固有 NG
- any 型を使わない。props は型で縛る
- 既存コンポーネントを探してから新規作成する(重複を避ける)
- a11y: 画像に alt、ボタンは button 要素を使うディレクトリの各行に役割コメントを添えておくと、「どこに何を書くべきか」を AI が即座に判断できます。新規ファイルが散らからない効果が大きい項目です。
バックエンド / API 向けテンプレート
サーバーサイドでは、レイヤー構成とエラー処理・テスト方針を書いておくと品質が安定します。
## アーキテクチャ方針
- 言語/FW: Node.js + Hono(または Go, Python など)
- レイヤー: handler → service → repository の 3 層を厳守
- DB アクセスは repository に集約。handler から直接叩かない
## API 規約
- レスポンスは { data, error } 形式で統一
- 入力は必ずスキーマでバリデーション(zod など)
- 認証が必要なエンドポイントは明示する
## テスト方針
- service 層はユニットテスト必須
- 外部依存はモック。DB はテスト用コンテナを使う
## バックエンド固有 NG
- 秘密情報をコードにハードコードしない(環境変数を使う)
- SQL は直接結合せずプレースホルダを使うレイヤーの責務分担を明文化しておくと、AI が handler に業務ロジックを書き込むような構成崩れを防げます。テスト方針を添えるのも、実装と一緒にテストを書かせるうえで効果的です。
モノレポ・複数パッケージ向けテンプレート
モノレポでは「どこを触っているか」を AI が見失いやすいので、パッケージ構成と作業範囲のルールを最上位に書きます。
## モノレポ構成
- パッケージマネージャ: pnpm workspaces(または Turborepo)
packages/
├── web/ # フロントエンド
├── api/ # バックエンド
├── ui/ # 共有コンポーネント
└── config/ # 共有設定(eslint, tsconfig)
## 作業範囲のルール
- 1 つのタスクでは原則 1 パッケージ内に変更を閉じる
- 共有パッケージ(ui, config)の変更は影響範囲を必ず確認
- ルートからのコマンドと各パッケージ内コマンドを混同しない
## コマンド(ルートから)
- 全体ビルド: pnpm -r build
- 特定パッケージ: pnpm --filter web dev各パッケージにも個別の CLAUDE.md を置けます。ルートには全体像と横断ルールを、各パッケージにはそこ固有の事情を書く二段構成にすると、文脈の混線が減ります。
コンテンツ・ライティング系プロジェクト向けテンプレート
ブログや技術記事を管理するリポジトリでは、表記スタイルガイドを CLAUDE.md に書いておくと文章の一貫性が一気に上がります。このサイト自体もこの方針で運用しています。
## コンテンツ規約
- 形式: Markdown / MDX。frontmatter の必須項目は title, slug, published
- 文体: です・ます調。地の文中心で誇張表現を避ける
## 表記ルール(校正で弾く対象)
- 公式スペース表記: 「AI 駆動開発」「Claude Code」「Cursor」
- 「リプレイス」(リプレースではない)、「税抜」(税抜きではない)
- コロン止めの箇条書きや意味のない太字を多用しない
## 校正コマンド
- 文章 lint: npm run lint:text
- 公開前に必ず textlint / prh チェックを通す表記の判定基準を書いておくと、AI が文章を生成する段階で表記ゆれを自分で回避してくれます。校正コマンドを併記しておけば、書いた後にセルフチェックまで自走させられます。
テンプレートを育てる運用 (定期見直し)
CLAUDE.md は一度書いて終わりではなく、コードと同じ頻度で更新するドキュメントとして扱うのがおすすめです。AI が同じミスを繰り返したときは、それを 1 行の NG ルールに変換して追記する。この「失敗を即ルール化する」サイクルが、テンプレートをそのプロジェクト専用の精度に育てます。
逆に、もう守られている当たり前のルールや古くなった進捗情報は削っていきます。状態系の記述(「Phase 1 完了」など)は stale 化しやすいので、仕様変更のタイミングで見直すルールにしておくと、AI が古い文脈で提案する事故を防げます。定型作業を カスタムスラッシュコマンド として切り出し、CLAUDE.md からはその存在に触れる程度にとどめると、本体を索引として軽く保てます。
関連: CLAUDE.md ベストプラクティス
テンプレートはあくまで出発点です。なぜその項目を書くのか、書きすぎるとどうなるかといった判断軸は CLAUDE.md にこれを書くと品質が上がる 8 つの項目 で解説しています。雛形を貼ったうえで、自社プロジェクトに本当に効く形へ削り込む参考にしてください。
CLAUDE.md の整備や Claude Code を使った AI 駆動開発の進め方で迷ったら、AI 駆動開発のクリエイティブスタジオである FIXIT にご相談ください。実プロジェクトでの運用知見をもとに、最適な始め方を一緒に設計します。AI 駆動開発の進め方を相談する。