最終更新 2026年10月17日

初回公開 2026年10月17日

【2026年版】CLAUDE.md / Cursor Rules 設計完全ガイド|AI生産性を2倍にするプロジェクト設定ファイルの書き方

Q: Q. CLAUDE.md と .cursorrules を両方書くべきですか?

A. Claude Code と Cursor の両方を使う場合は両方必要です。内容はほぼ同じになるので、片方を書いてもう片方にコピー&微調整するのが効率的。

Q: Q. CLAUDE.md は何行くらいが適切ですか?

A. 200〜300行以内が目安です。それ以上必要な場合は、サブドキュメントに切り分けてリンクを張ります。例:アーキテクチャの詳細は `docs/architecture.md` に書き、CLAUDE.md からはリンクで参照。

Q: Q. 既存プロジェクトでCLAUDE.md を導入する最短手順は?

A. 以下の3ステップが最短です。Claude Codeに「このプロジェクトを分析して CLAUDE.md のドラフト作成」を依頼生成されたドラフトを手動レビュー・加筆(30〜60分)チームレビュー → マージ

Q: Q. CLAUDE.md を書くと AI の応答が遅くなりませんか?

A. 微増しますが、生産性UP効果が圧倒的に大きいので総合的にはプラスです。200〜300行の CLAUDE.md 読み込みは数百ミリ秒の追加で、1回の作業で数分〜数十分の時間短縮に繋がります。

Q: Q. チームでCLAUDE.md を共有するベストプラクティスは?

A. 以下の3つを徹底してください。Git 管理下に置く(リポジトリルート)PR レビュー時に CLAUDE.md 準拠をチェック四半期に1回、チームミーティングで内容見直し

Q: Q. CLAUDE.md はクライアント案件で使えますか?

A. クライアントが Claude Code 利用を認めている前提で使えます。秘密保持契約(NDA)・情報漏洩リスクをクライアントと事前相談してから導入してください。多くの企業プラン(Claude for Enterprise等)では学習データ利用禁止設定が標準なので、業務情報がLLM学習に使われるリスクは低いです。

Q: Q. .cursor/rules/ の新形式に移行すべきですか?

A. 中規模以上のプロジェクトでは移行推奨です。ファイルタイプごと・ディレクトリごとにルールを分割できるため、ノイズが減ってAIの応答精度が上がります。小規模プロジェクトは .cursorrules 1本で十分です。

はじめに

「Claude CodeやCursorを使い始めたが、プロジェクトごとに同じ指示を繰り返している」
「CLAUDE.md があると便利と聞くが、何をどう書けば良いか分からない」
「AI生産性を2倍にする.cursorrulesの実例が欲しい」

こう感じている人は多いのではないでしょうか。
Claude Code の CLAUDE.md と Cursor の .cursorrules は、プロジェクト固有のコンテキストをAIに伝える最強の生産性向上ツールです。しかし適切に設計しないと、ただのメモ書きになってしまい効果が出ません。

しかも厄介なのは、設計のベストプラクティスが散在していて、実務で使える体系的なガイドがほぼないという点。公式ドキュメントは基本機能の説明に留まり、実際のプロジェクトでどう構造化するか・何を書くべきかが明示されていません。

この記事では、現役フリーランスSWEの筆者が、CLAUDE.md と .cursorrules の設計原則、記載すべき5要素、具体例、既存コードベースへの導入手順を2026年版で解説します。読み終わるころには、自分のプロジェクトに即適用できる設計テンプレが手に入ります。

CLAUDE.md / .cursorrules を30秒で理解

それぞれの位置づけ

ファイル	対象	配置場所	読み込みタイミング
CLAUDE.md	Claude Code	プロジェクトルート	セッション開始時に自動読み込み
.cursorrules	Cursor	プロジェクトルート	全プロンプトで自動付加
.cursor/rules/	Cursor(新形式)	ディレクトリ	ファイル/フォルダ単位で条件付き

これらが解決する課題

プロジェクトごとの命名規則・設計パターンを毎回説明する手間
使用ライブラリのバージョン・制約を忘れがち
テスト・リント・デプロイのコマンドをAIが知らない
特殊なアーキテクチャ(DDDやCleanアーキ等)を毎回説明
禁止事項(「console.log を本番コードに残すな」等)の徹底

記載すべき5要素

要素1:プロジェクト概要(100〜200字)

何のプロジェクトか・使用技術スタック・デプロイ先を簡潔に。AIが「どんな世界観で動けばいいか」を把握する基礎情報です。

記載例

# Project Overview
This is a SaaS task management app for freelancers.
- Frontend: Next.js 15 + TypeScript + Tailwind CSS
- Backend: Fastify + Prisma + PostgreSQL
- Hosting: Vercel (frontend) + Fly.io (backend)
- Auth: Clerk

要素2:ディレクトリ構造

プロジェクトの構造を可視化。AIが「どこに何があるか」を把握するための地図です。

記載例

## Directory Structure
- `src/app/`         - Next.js App Router pages
- `src/components/`  - Reusable React components
- `src/lib/`         - Shared utilities (date, format, etc.)
- `src/features/`    - Feature modules (vertical slice)
- `prisma/`          - Database schema and migrations
- `tests/`           - Vitest unit & integration tests

要素3:コーディング規約

命名規則・ファイル分割ルール・コメント方針などのチームの流儀を明示。

記載例

## Coding Conventions
- File naming: kebab-case for files, PascalCase for components
- Imports: Use `@/*` alias (no deep relative imports)
- Components: Server Components by default, "use client" only when needed
- API: tRPC procedures in `src/server/trpc/routers/`
- Errors: Use Result pattern (neverthrow) instead of throwing
- Comments: Only when the "why" is non-obvious

要素4:よく使うコマンド

テスト・リント・デプロイなど、AIが開発フローで実行するコマンドを一覧化。

記載例

## Common Commands
- `pnpm dev` - Start Next.js dev server
- `pnpm test` - Run Vitest tests
- `pnpm test:watch` - Vitest in watch mode
- `pnpm lint` - ESLint + Prettier check
- `pnpm typecheck` - TypeScript strict check
- `pnpm db:migrate` - Prisma migration dev
- `pnpm deploy:preview` - Deploy to Vercel preview

要素5:禁止事項とガードレール

「絶対にやってほしくないこと」を明示。AIの暴走を防ぐ最重要セクションです。

記載例

## Must NOT
- Do NOT use `any` type (use `unknown` and narrow)
- Do NOT commit `.env` files
- Do NOT use `console.log` in production code (use pino logger)
- Do NOT change database schema without creating a migration
- Do NOT disable TypeScript strict checks
- Do NOT delete tests without discussing in PR
- Do NOT add new dependencies without checking bundle size impact

CLAUDE.md の完全テンプレート

# CLAUDE.md

This file provides guidance to Claude Code when working with code in this repository.

## Project Overview
[プロジェクト概要を2〜3行]

## Tech Stack
- Frontend: [フレームワーク + バージョン]
- Backend: [フレームワーク + バージョン]
- Database: [DB種類 + ホスティング]
- Hosting: [デプロイ先]

## Directory Structure
[主要ディレクトリの説明]

## Coding Conventions
- Naming: [命名規則]
- Imports: [import ルール]
- Components: [コンポーネント設計方針]
- Errors: [エラーハンドリング方針]
- Testing: [テストの書き方]

## Common Commands
[開発中によく使うコマンド一覧]

## Must NOT
[禁止事項リスト]

## Context for AI
- When implementing new features, follow the vertical slice pattern (feature folders)
- When fixing bugs, add a regression test
- When refactoring, keep tests passing throughout
- When touching the DB schema, create a Prisma migration

## Related Documents
- [Design doc / ADR へのリンク]
- [API ドキュメントへのリンク]

.cursorrules の完全テンプレート

# プロジェクトルール

あなたは経験豊富な[言語]エンジニアです。
以下のルールに従ってコードを書いてください。

## プロジェクト概要
[Overview]

## 技術スタック
- [Tech 1]
- [Tech 2]
- [Tech 3]

## コーディング規約
- [Rule 1]
- [Rule 2]
- [Rule 3]

## 必ず守ること
- [禁止事項 1]
- [禁止事項 2]

## 回答スタイル
- 短く、具体的に
- コードを提示する時は、変更の意図も1行で説明
- 既存コードベースの流儀に従う(新しいパターンを勝手に導入しない)
- テストが必要な変更には必ずテストコードも提示

Cursor の新形式(.cursor/rules/)の活用

新形式のメリット

2025年に導入された新形式では、.cursor/rules/ ディレクトリに複数のルールファイルを配置できます。「このファイルを編集する時だけ適用するルール」など、条件付きの詳細な制御が可能です。

典型的なファイル構成

.cursor/rules/
├── global.md         # 全ファイル共通ルール
├── react.md          # *.tsx 編集時のみ
├── api.md            # src/api/ 配下のみ
├── test.md           # *.test.ts 編集時のみ
└── prisma.md         # prisma/ 配下のみ

記載例(react.md)

---
globs: ["**/*.tsx", "**/*.jsx"]
---

# React Component Rules
- Default to Server Components in Next.js App Router
- Add "use client" only when using hooks, event handlers, or state
- Use `interface` for props, suffix with `Props` (e.g., ButtonProps)
- Memoize expensive computations with useMemo
- Keep components under 200 lines (split if larger)

既存コードベースへの導入手順

ステップ1:AIにプロジェクト分析を依頼

既存コードベースにいきなり CLAUDE.md を書くのは難しいので、まずAIに分析させるのが最短です。

# プロンプト例
このプロジェクトを分析して、CLAUDE.md のドラフトを作成してください。
以下の観点で記載:
1. プロジェクトの技術スタック
2. ディレクトリ構造の説明
3. コーディング規約(既存コードから推測)
4. よく使うコマンド(package.json の scripts から)
5. 禁止事項(.eslintrc 等から推測)

ステップ2:ドラフトをレビュー・加筆

プロジェクト固有の文脈(ビジネスドメイン・歴史的経緯)を加筆
自動推測が間違っている部分を修正
チームでレビューして合意形成

ステップ3:段階的に拡張

最初は100〜200行の簡易版からスタート
AI の失敗パターンを観察し、ルールを追記
3ヶ月に1回程度の見直しサイクル

ステップ4:チーム内の共有ルール化

CLAUDE.md を Git 管理下に置く
PR レビュー時にも CLAUDE.md の遵守をチェック
新しいメンバーのオンボーディング資料として活用

CLAUDE.md 設計のNG例5つ

NG1:長すぎる(500行超)

AIのコンテキストウィンドウを圧迫します。200〜300行以内を目安に。詳細は別ドキュメントに切り分けてリンクを張ります。

NG2:曖昧な表現を使う

「できるだけ短く」「適切に書く」など曖昧な表現はAIが解釈に困ります。具体的な数値・パターンで書きましょう(「関数は50行以内」「ファイルは200行以内」等)。

NG3:禁止事項が多すぎる(20項目超)

禁止事項は本当に重要な5〜10項目に絞ってください。多すぎると優先順位が曖昧になり、AI が守りきれません。

NG4:プロジェクト固有の文脈がゼロ

一般的なベストプラクティスだけ書いても意味がありません。「このプロジェクトではなぜこの選択をしたか」の歴史的経緯・ドメイン知識を含めてください。

NG5:更新されず古い情報が残る

技術スタックやコマンドが変わってもCLAUDE.mdが更新されない=AIが古い情報で動く。四半期に1回の見直しをチーム運用に組み込んでください。

複数リポジトリでの運用

マルチリポジトリ構成の課題

フリーランスで複数クライアントの案件を並行する場合、プロジェクト間で CLAUDE.md が全く違うため、頻繁に切り替えると混乱します。

対応策1:ホームディレクトリに個人用CLAUDE.md

`~/.claude/CLAUDE.md` に自分の個人ルール(コメント方針・レスポンス言語等)を書くと、全プロジェクトで常用できます。

対応策2:プロジェクトテンプレートを用意

自分の案件で使い回せる CLAUDE.md テンプレートをGitHubのプライベートリポジトリに保存して、新規プロジェクト開始時にコピー配置するのが効率的です。

CLAUDE.md / .cursorrules が単価UPに繋がる理由

理由1:AI活用スキルの差別化シグナル

クライアント先での「AIを使いこなせるエンジニア」の証明として、CLAUDE.md の設計能力は強力な差別化要素になります。「AI生産性2倍のエンジニア」というブランディングが可能になります。

理由2:チーム全体の生産性向上役を担える

クライアント企業のチーム全体に CLAUDE.md 設計を広めることで、AIリード/AI推進の役割拡張ができ、単価UP交渉の材料になります。

理由3:短期間での高品質アウトプット

CLAUDE.md が整備されていれば、Claude Code の作業品質が跳ね上がり、同じ時間でPR数・リリース数が2〜3倍に。成果報酬型契約への移行も有利になります。

AI活用で単価UPする具体戦略はAI活用で単価UP交渉術を参照してください。

次の一手|AI生産性スキルを単価に変換する

CLAUDE.md / .cursorrules を使いこなせるようになったら、次はその生産性を実案件で証明して単価UPフェーズです。AI活用+MCP+CLAUDE.md設計のスキル組み合わせは、2026年の市場で希少価値が高く、月単価110〜150万円帯の案件に通りやすくなります。

👉 レバテックフリーランスでAI案件を見る(AI/Claude Code活用案件増加中)

登録・相談は無料。CLAUDE.md 設計スキルは、面談時の技術アピールとしても強力です。

よくある質問

Q. CLAUDE.md と .cursorrules を両方書くべきですか?

A. Claude Code と Cursor の両方を使う場合は両方必要です。内容はほぼ同じになるので、片方を書いてもう片方にコピー&微調整するのが効率的。

Q. CLAUDE.md は何行くらいが適切ですか?

A. 200〜300行以内が目安です。それ以上必要な場合は、サブドキュメントに切り分けてリンクを張ります。例:アーキテクチャの詳細は `docs/architecture.md` に書き、CLAUDE.md からはリンクで参照。

Q. 既存プロジェクトでCLAUDE.md を導入する最短手順は?

A. 以下の3ステップが最短です。

Claude Codeに「このプロジェクトを分析して CLAUDE.md のドラフト作成」を依頼
生成されたドラフトを手動レビュー・加筆(30〜60分)
チームレビュー → マージ

Q. CLAUDE.md を書くと AI の応答が遅くなりませんか?

A. 微増しますが、生産性UP効果が圧倒的に大きいので総合的にはプラスです。200〜300行の CLAUDE.md 読み込みは数百ミリ秒の追加で、1回の作業で数分〜数十分の時間短縮に繋がります。

Q. チームでCLAUDE.md を共有するベストプラクティスは?

A. 以下の3つを徹底してください。

Git 管理下に置く(リポジトリルート)
PR レビュー時に CLAUDE.md 準拠をチェック
四半期に1回、チームミーティングで内容見直し

Q. CLAUDE.md はクライアント案件で使えますか?

A. クライアントが Claude Code 利用を認めている前提で使えます。秘密保持契約(NDA)・情報漏洩リスクをクライアントと事前相談してから導入してください。多くの企業プラン(Claude for Enterprise等)では学習データ利用禁止設定が標準なので、業務情報がLLM学習に使われるリスクは低いです。

Q. .cursor/rules/ の新形式に移行すべきですか?

A. 中規模以上のプロジェクトでは移行推奨です。ファイルタイプごと・ディレクトリごとにルールを分割できるため、ノイズが減ってAIの応答精度が上がります。小規模プロジェクトは .cursorrules 1本で十分です。

まとめ ─ CLAUDE.md を武器化してAI生産性を2倍にする

CLAUDE.md / .cursorrules を効果的に活用するロードマップは以下です。

基本5要素を網羅:概要・構造・規約・コマンド・禁止事項
既存プロジェクトはAIにドラフト作成を依頼:最短1時間で導入可能
3ヶ月に1回見直し:AIの失敗パターンを観察してルール追記
チームでの共有ルール化:Git管理+PRレビュー時にチェック
フリーランス単価UPに応用:AI活用スキルの差別化シグナルとして

CLAUDE.md は「AIを使う」から「AIを使いこなす」への最短ステップです。2026年現在、設計能力の高いエンジニアはまだ少数なので、今から習得して差別化スキルにするタイミングです。

👉 Claude Code実践ガイド|フリーランス生産性2倍のAI駆動開発ワークフロー
👉 MCP(Model Context Protocol)入門完全ガイド
👉 AI活用で単価UP交渉術|Claude/Cursor時代の実践戦略
👉 Cursor Composer / Agent 完全活用ガイド
👉 AIコーディングツール徹底比較(3ツール深掘り版)
👉 AIコードエディタ徹底比較(5ツール網羅版)
👉 ChatGPTを使ったコードレビューの実践法

Tags #フリーランス