CLAUDE.mdに何を書く？ そのまま貼れるテンプレ7本と禁止事項の作り方

「CLAUDE.md、とりあえず技術スタック書いとけばいいんでしょ？」

僕も最初はそう思っていました。Astro と TypeScript と Tailwind、はい書いた。で、満足してClaude Codeに作業を頼んだら——同じミスを3回繰り返されました。テストを毎回飛ばす。消しちゃいけない設定ファイルに手を伸ばす。「直しました！」と言いながらビルドが通っていない。

スタックを書くだけのCLAUDE.mdは、新人に「うちはJavaの会社だよ」とだけ伝えて現場に放り込むのと同じです。何を知っているかは伝わるけど、どう動けばいいかはひとつも伝わっていない。

この記事では、僕が実案件でそのまま使っているCLAUDE.mdテンプレを7本、コピペできる形で置いておきます。スタックの説明ではなく、「やる順番」と「やってはいけないこと」に振り切ったやつです。

この記事の要点

• CLAUDE.mdで本当に効くのは技術スタックではなく、**作業手順（Working Rules）と禁止事項（Do Not）**の2つ。
• 用途別に7本のテンプレを用意した。個人開発／コンテンツサイト／API／チーム／レガシー／自動化／モノレポ。自分のリポジトリに一番近い1本を選んで貼るだけ。
• どのテンプレも、貼ったあとに自分用のDo Notを3行足すのが必須。これが事故を止める。
• 長く書くほど良いは誤解。CLAUDE.mdはマニュアルではなく運用ファイル。短い行動ルールが勝つ。
• Claude Codeが同じ失敗を3回繰り返したら、AIではなくCLAUDE.mdの粒度を疑う。

このページは、Claude Code 完全入門ガイド と CLAUDE.mdの書き方完全ガイド の間を埋める「現物カタログ」のつもりで作りました。理屈はそっちで読んで、ここからは実物を持って帰ってください。

良いCLAUDE.mdが、地味にやっていること

強いCLAUDE.mdは、賢いことを書いているわけではありません。次の3つの「あるある事故」を、地味に潰しているだけです。

• 編集する場所は合っているのに、そのプロジェクト固有のお作法を外す
• 修正自体はできたのに、回すべきテストや確認を飛ばす
• どこまでが自分の担当範囲か曖昧で、探索が広がりすぎて時間を溶かす

この3つを防ぐために、最低限ほしい項目はこうです。

項目	役割	効き目
技術スタックと主要コマンド	前提を揃える	中
ディレクトリの役割	探索範囲を絞る	中
プロジェクト固有ルール	お作法を守らせる	大
作業手順（順番）	確認の抜けを防ぐ	大
禁止事項（Do Not）	事故を止める	特大

上2つはおまけで、効くのは下3つです。とくに作業手順と禁止事項を書いた瞬間、Claude Codeは別人のように落ち着きます。「どう進めるか」と「何をするな」——人間の新人に渡すマニュアルと、結局おなじなんですよね。

ここから先は実物です。コードブロックの中身を、自分のCLAUDE.mdにそのまま貼ってください。

1. 個人開発のWebアプリ向け

ひとりで小さなサービスを回しているなら、まずこれです。

# Project Overview

Customer-facing Astro site with a small Node API.

## Tech Stack

- Frontend: Astro 5 + TypeScript
- Styling: Tailwind CSS
- Backend: Node.js 22
- Tests: Vitest

## Key Directories

- `site/src/pages/` route entrypoints
- `site/src/components/` reusable UI
- `site/src/content/` blog and docs content
- `scripts/` operational scripts

## Common Commands

- Build: `cd site && npm run build`
- Test: `npm run test`
- Search content: `rg "keyword" site/src/content`

## Working Rules

- Prefer minimal diffs over wide refactors
- Keep copy changes aligned with existing brand tone
- When editing UI, verify mobile width before calling the task done

## Do Not

- Do not rename routes unless required
- Do not delete analytics or SEO fields
- Do not claim deploy success without checking the public URL

ここで一番効いているのはスタック説明ではなく、Working RulesとDo Notの最後の行です。「モバイル幅を確認するまで完了と言うな」「公開URLを見るまでデプロイ成功と言うな」。この2行を入れる前、僕はPCの画面では崩れていないUIを、スマホで見たら全部はみ出していた、という事故を何度かやりました。成功条件を文章で縛ると、それが消えます。

2. 記事・PDF・商品導線があるコンテンツサイト向け

このブログ自体がそうですが、収益導線のあるサイトは一般的な開発テンプレだと弱すぎます。

# Project Overview

Multilingual Claude Code content site with free PDF lead magnet, Gumroad products, and consultation funnel.

## Business Goal

- Priority 1: free PDF registration
- Priority 2: Gumroad product clicks and purchases
- Priority 3: consultation inquiries

## Content Rules

- Every new article must include internal links
- Every article must include free PDF, product, and consultation CTA paths
- Use the same slug across all locales when publishing multilingual posts

## Verification Workflow

1. Build the site
2. Deploy the site
3. Open the public URL
4. Check mobile layout
5. Confirm CTA destination links

## Do Not

- Do not publish only one locale when the article requires all locales
- Do not treat build success as release success
- Do not prioritize pageviews over conversion path quality

ポイントはDo Notの最後、「PVよりコンバージョン導線の質を優先しろ」と明記している点です。これを書かないと、Claude Codeは「読まれそうな記事」を作るほうに寄っていって、肝心のCTAが薄いページを量産します。ビジネスゴールに優先順位を付けて先頭に置くだけで、出力の方向がガラッと変わりました。

3. バックエンドAPI向け

整合性が命のAPIには、「直す前に読む」「直したら言語化する」を強制します。

# Project Overview

Internal TypeScript API for billing and account management.

## Tech Stack

- Node.js 22
- Fastify
- PostgreSQL + Prisma
- Zod
- Vitest

## Directory Map

- `src/routes/` HTTP handlers
- `src/services/` business logic
- `src/repositories/` DB access
- `src/lib/` shared utilities

## Required Workflow

1. Read the route or service first
2. Check for existing schema and tests
3. Make the smallest safe change
4. Run unit tests or type checks
5. Summarize risk in plain English

## Do Not

- Do not bypass Zod validation
- Do not edit migrations casually
- Do not touch billing logic without tests

この中で僕が一番気に入っているのは、Summarize risk in plain Englishの1行です。直訳すると「リスクをふつうの言葉でまとめろ」。これを入れると、Claude Codeが「直しました」で終わらず、「この変更は課金ロジックの境界に近いので、月次バッチに影響する可能性があります」みたいに、影響範囲を勝手に言語化してくれます。レビューの初手が一気に楽になります。

4. チーム開発向け

チームで本当に困るのは、生産性不足よりレビューしづらい差分です。それを先回りします。

# Team Workflow

- Work on the current branch only
- Do not revert changes you did not make
- Call out uncertainty before making broad edits
- Prefer review-friendly patches over large rewrites

## Pull Request Expectations

- Mention user-facing behavior changes
- Mention test coverage gaps
- Flag security, permissions, and deploy risks first

## Approval Boundaries

- Ask before deploy commands
- Ask before editing CI, infra, or secrets-related files
- Ask before changing lockfiles unless required

Do not revert changes you did not make（自分がやっていない変更を勝手に戻すな）は、地味ですが効きます。AIは「ついで」に近くのコードを”きれいに”しようとして、他人の意図的な記述を巻き戻すことがあるんです。承認境界の切り分けについては Approval / Sandbox 設定ガイド で詳しく書いたので、チーム運用ならそちらも合わせてどうぞ。

5. レガシーコード向け

古いコードの改修では、「きれいさ」より「壊さないこと」が正義になります。

# Legacy Repo Notes

- This codebase has inconsistent patterns
- Prefer compatibility over elegance
- Preserve behavior unless the task explicitly allows change

## Investigation First

1. Explain current behavior
2. Locate the smallest responsible file set
3. Identify risks before editing

## Do Not

- Do not rename public methods casually
- Do not introduce new frameworks
- Do not rewrite files only to match modern style

Prefer compatibility over elegance（美しさより互換性を優先）。レガシー案件では、これが一番大事になることが多いです。放っておくとClaude Codeは善意で「最新のスタイルに書き直しますね」と言ってきますが、レガシーではそれが事故の入口。Do rewrite files only to match modern style を禁止に入れて、その善意に蓋をしておきます。

6. 自動化・運用スクリプト向け

メール送信、デプロイ、外部API書き込み——副作用のあるスクリプトを触らせるなら、最初の候補はこれです。

# Automation Rules

- Dry-run whenever the script supports it
- Log intended side effects before executing
- Prefer idempotent operations
- Keep secrets out of logs and generated files

## Required Checks

- Confirm environment variables used
- Confirm target environment
- Confirm output path or destination service

## Do Not

- Do not send emails, deploy, or publish without explicit approval
- Do not delete generated assets unless cleanup is requested

Log intended side effects before executing（実行前に、何をやらかすつもりか書き出せ）が安全弁です。「これから本番に120通メールを送ります」と先に宣言させれば、人間が「待った」をかけられる。Dry-run whenever the script supports it とセットで、取り返しのつかない操作に必ずワンクッション挟まります。

7. モノレポ向け

複数アプリと共有パッケージが同居しているなら、「どのパッケージが責任を持つか」を先に書きます。

# Monorepo Map

- `apps/web/` customer app
- `apps/admin/` internal admin tool
- `packages/ui/` shared UI
- `packages/config/` lint and tsconfig presets

## Ownership Rules

- Web UI work should stay inside `apps/web/` unless the task clearly needs a shared component change
- Shared package edits require checking downstream usage
- Avoid version or config churn unless necessary

## Verification

- Run the narrowest relevant build or test command first
- Describe cross-package impact before editing shared code

Ownership Rulesを書くだけで、横断編集の事故がかなり減ります。apps/web/の小さな修正のはずが、いつのまにかpackages/ui/の共有コンポーネントに手が入って、apps/admin/まで巻き込んで壊れる——これがモノレポの典型事故。担当範囲を最初に宣言させて、共有コードに触る前に「下流への影響を説明しろ」と一言入れておきます。

どのテンプレを選ぶべきか

7本も並べると迷うので、選び方を1行ずつにしておきます。

• UIやプロダクトが中心 → 個人開発テンプレ
• 記事・PDF・Gumroad導線がある → コンテンツサイトテンプレ
• 整合性が命 → APIテンプレ
• 調整コストが高い → チーム or モノレポテンプレ
• 事故コストが高い → レガシー or 自動化テンプレ

7本を全部混ぜる必要はありません。むしろ混ぜると長くなって効きが落ちます。1本を土台にして、自分の現場で行動が変わるルールだけ足す。これが正解です。

CLAUDE.mdでやりがちな失敗4つ

僕が実際に踏んだ地雷を、そのまま共有します。

失敗1. 会社Wikiみたいに長く書く。 説明が長いほど良い、は完全に誤解でした。CLAUDE.mdはマニュアルではなく運用ファイルです。長文の背景説明より、短い行動ルールのほうが何倍も効きます。読むのは人間じゃなくてAIだ、という前提を忘れがちなんですよね。

失敗2. コマンドだけ書いて、手順を書かない。 npm run test とだけ書くより、billingを触ったらtestを必ず回す のほうが圧倒的に強い。コマンドは「存在」を伝えるだけ。手順は「いつ使うか」まで伝えます。

失敗3. 禁止事項がない。 これが一番もったいない。.envを触るな、公開URL未確認でデプロイ成功と言うな、force pushするな。たった一文が、一晩の事故を防ぎます。Do Notセクションは飾りではなく、保険です。

失敗4. 更新しない。 Claude Codeが同じ失敗を3回繰り返したら、たいていAIのせいではなく、CLAUDE.md側の粒度が足りていません。そのときは叱るのではなく、ルールを1行追記する。CLAUDE.mdは書いて終わりではなく、育てるファイルです。

よくある質問

Q. CLAUDE.mdはプロジェクトのどこに置けばいいですか？ A. リポジトリのルートに CLAUDE.md という名前で置けば、Claude Codeが自動で読み込みます。モノレポなら各パッケージ直下にも置けて、近いほうが優先されます。実際の置き方と、効いているかの確認はこの2コマンドだけです。

# プロジェクトのルートに置くだけ。Claude Codeが起動時に自動で読み込む
cat > CLAUDE.md <<'EOF'
# Project
（上のテンプレをそのまま貼る）
EOF

# 効いているか確認：ルールを聞き返してみる
claude -p "このプロジェクトのCLAUDE.mdにあるDo Notを3つ挙げて"

詳しい配置ルールは公式の Claude Code documentation を確認してください。

Q. 日本語で書いてもちゃんと効きますか？ A. 効きます。僕は禁止事項や手順を日本語で書くこともあります。ただ、テンプレ自体は英語で書いておくと、海外のメンバーやサンプルとも揃えやすいので、この記事では英語ベースにしています。中身が伝わればどちらでも問題ありません。

Q. 長いCLAUDE.mdと短いCLAUDE.md、どっちがいい？ A. 短いほうです。目安は1画面に収まる程度。長くなってきたら、それは別ドキュメントに切り出すサインです。CLAUDE.mdには「行動が変わるルール」だけを残してください。

Q. テンプレを貼ったあと、最初に何を足せばいいですか？ A. 自分の案件用のDo Notを3行です。「触られると困るファイル」「やられると困る操作」「言われると困る嘘（例: 未確認なのに成功報告）」をそれぞれ1行ずつ。ここが一番リターンの大きい追記です。

Q. CLAUDE.mdとpermissions（権限設定）はどう違いますか？ A. CLAUDE.mdは「お願い・方針」、permissionsは「強制力のある許可リスト」です。禁止事項を本気で守らせたいなら、両方を併用します。権限の分け方は Claude Code 完全入門ガイド でも触れています。

実際に試した結果

CLAUDE.mdに技術スタックしか書いていなかった頃、僕はClaude Codeの出力に毎回ハラハラしていました。「今回はちゃんとテスト回してくれるかな」と。

Working RulesとDo Notを足してから、その不安がほぼ消えました。とくに「公開URLを見るまでデプロイ成功と言うな」の1行は、効果がはっきり数字に出ます。それ以前は「デプロイできました」のあとに実際は404、みたいなことが月に何度かありましたが、入れてからはゼロになりました。

結論はシンプルです。CLAUDE.mdは、AIを賢くするためのファイルではなく、AIに事故らせないためのファイル。スタックを足すより、禁止事項を3行足すほうが、体感10倍効きます。まずは自分のリポジトリに一番近いテンプレを1本貼って、Do Notを3行だけ書き足してみてください。

CLAUDE.mdの設計思想そのものをもっと深掘りしたい人は CLAUDE.mdの書き方完全ガイド を、AIに作業を安全に任せる「足場」全体の話は AIに「全部やっといて」は事故のもと をどうぞ。テンプレ集や設定例を手元にまとめて持っておきたいなら、無料の Claude Code Quick Reference Cheatsheet と、hooks・permissionsまで踏み込んだ The Complete Claude Code Setup & Configuration Guide が役に立ちます。教材を一通り見たい方は 教材一覧 から、チーム標準化まで一緒に詰めたい方は 導入相談 へどうぞ。