🛠️ Claude Code 初心者ガイド
初心者でもわかる！
CLAUDE.md で Claude Code を賢く使う方法
CLAUDE.md で Claude Code を賢く使う方法
たった1ファイル書くだけで、Claudeがあなたのプロジェクトを”覚えて”くれる。
毎回同じ説明をしなくても、ずっと高品質なコードを生成してくれる設定術。
毎回同じ説明をしなくても、ずっと高品質なコードを生成してくれる設定術。
「毎回同じことを説明するのが面倒…」そのお悩み、解決します
- Claude Codeに「このプロジェクトはTypeScript使ってるよ」と毎回伝えている
- インデントや命名規則を毎回プロンプトに書くのが手間
- セッションをまたぐと文脈がリセットされてしまう
- もっと自分のプロジェクトに合ったコードを出してほしい
これらはすべて CLAUDE.md を設定するだけで解決できます。この記事では初心者の方でも3〜5分で導入できるよう、具体例を交えてわかりやすく解説します。
📋 目次
CLAUDE.mdとは何か？──「事前説明書」という考え方
Claude Codeは、会話のたびにフレッシュなコンテキストウィンドウで起動します。つまり、昨日教えたこと・先週決めたルール・プロジェクトの構成──これらをセッションをまたいで覚えてはくれません。
そこで登場するのが CLAUDE.md です。
💡 一言で言うと？
CLAUDE.mdは「Claudeへの事前説明書」です。プロジェクトの概要・技術スタック・コーディング規約・コマンドなどをここに書いておくと、毎セッションの冒頭に自動で読み込まれ、Claudeがプロジェクトをよく知る”チームメンバー”のように振る舞ってくれます。
Claude Codeの2つのメモリシステム
Anthropicの公式ドキュメントによれば、Claude Codeにはセッションをまたぐ2つのメモリ機構があります。
| 種類 | 誰が書くか | 何が保存されるか | 対象 |
|---|---|---|---|
| CLAUDE.md | あなた（人間） | プロジェクトルール・コーディング規約・ビルドコマンドなど | この記事のメインテーマ |
| Auto memory | Claude自身 | あなたの修正・好み・デバッグの知見などを自動学習 | v2.1.59以降で利用可 |
📌 重要な考え方
公式ドキュメントは「CLAUDE.mdはルールを強制する設定ファイルではなく、Claudeが参照するコンテキストとして扱われる」と述べています。具体的で簡潔に書くほど、一貫した動作が得られます。
どこに置く？──3つのスコープを理解する
CLAUDE.mdは置く場所によって適用範囲が変わります。3種類を使い分けることで、各ファイルを短くシンプルに保てます。
| 種類 | ファイルパス | 適用範囲 | 書くべき内容 |
|---|---|---|---|
| グローバル | ~/.claude/CLAUDE.md |
すべてのプロジェクト | コミット形式の好み・エディタ設定・個人のコーディングスタイル |
| プロジェクト | /project-root/CLAUDE.md |
そのプロジェクト全体（チーム共有） | 技術スタック・ビルドコマンド・コーディング規約・アーキテクチャ概要 |
| ローカル（個人） | /project-root/CLAUDE.local.md |
自分だけ（.gitignore推奨） | 個人的なワークフローの癖・ローカル環境固有の設定 |
✅ 初心者はまずここから
最初は プロジェクトルートの CLAUDE.md だけ作れば十分です。グローバルやローカルは慣れてから追加していきましょう。複数のファイルは「上書き」ではなく「追加」で合算されます（より具体的な設定が優先）。
作成方法──
claude /initから始める3ステップ-
プロジェクトルートでターミナルでプロジェクトのルートディレクトリに移動し、コマンドを実行します。Claude Codeがプロジェクトを自動分析して、基本的なCLAUDE.mdの雛形を生成してくれます。
claude /initを実行する$ cd my-ec-site
$ claude /init
✓ Analyzing project structure…
✓ Detecting tech stack: Node.js, TypeScript, PostgreSQL
✓ Created CLAUDE.md in project root
→ Review and edit the file to fit your project -
生成されたCLAUDE.mdを開いて確認・編集する自動生成された内容を確認し、プロジェクトに合わせて追記・修正します。次のセクションの「基本フォーマット」を参考に内容を充実させましょう。VS CodeやZedなどのエディタで普通のMarkdownファイルとして編集できます。
-
claude コマンドで動作を確認する次回以降のセッションで、Claudeが設定内容を正しく参照しているか確認します。「このプロジェクトはどんな技術スタック？」と聞いてみると、CLAUDE.mdの内容を踏まえた回答が返ってくるはずです。$ claude
✓ Loaded CLAUDE.md (project root)
✓ Loaded ~/.claude/CLAUDE.md (global)
Claude Code ready — project context loaded
⚠️ /init を使わずに手動で作成することもできます
プロジェクトルートに
CLAUDE.md という名前のMarkdownファイルを新規作成するだけでOKです。ファイルが存在すればClaudeが自動で読み込みます。
基本フォーマット──何を書けばいいか
公式ドキュメントや実際の利用事例を踏まえると、効果的なCLAUDE.mdは5つのセクションで構成されます。「書けば書くほど良い」ではなく、具体的で簡潔であることが重要です。
推奨5セクション（優先度順）
CLAUDE.mdプロジェクトルートに配置
# プロジェクト名
## 1. ビルド・実行コマンド（最重要！）
# Claudeがコマンドを誤って実行するのを防ぐ。最優先で書く。
– インストール： npm install
– 開発サーバー起動： npm run dev
– テスト実行： npm run test
– ビルド： npm run build
– Lint： npm run lint
## 2. プロジェクト概要
# 何を作っているか・誰が使うか・現在の状態
– 概要： ECサイト向けREST API
– 技術スタック： Node.js 20, TypeScript, PostgreSQL, Docker
– チーム規模： 3名
## 3. コーディング規約
# 「常にXをすること」というルール
– インデント： スペース2つ
– 命名：ファイルは kebab-case、クラスは PascalCase、関数は camelCase
– エラー処理： try-catchを使い、意味のあるエラーメッセージを含める
– コメント： 「何をするか」ではなく「なぜそうするか」を書く
## 4. アーキテクチャ概要
# ディレクトリ構成・主要モジュールの役割
src/
├── api/ # エンドポイント定義
├── services/ # ビジネスロジック
├── models/ # DBスキーマ
└── utils/ # 共通ユーティリティ
## 5. 常に守ること / 絶対にしてはいけないこと
– 常に： Zodを使ってリクエストのバリデーションを行う
– 常に： 新機能にはJestのユニットテストを追加する
– 禁止： envファイルの値をハードコーディングしない
– 禁止： anyをTypeScriptの型として使わない
## 1. ビルド・実行コマンド（最重要！）
# Claudeがコマンドを誤って実行するのを防ぐ。最優先で書く。
– インストール： npm install
– 開発サーバー起動： npm run dev
– テスト実行： npm run test
– ビルド： npm run build
– Lint： npm run lint
## 2. プロジェクト概要
# 何を作っているか・誰が使うか・現在の状態
– 概要： ECサイト向けREST API
– 技術スタック： Node.js 20, TypeScript, PostgreSQL, Docker
– チーム規模： 3名
## 3. コーディング規約
# 「常にXをすること」というルール
– インデント： スペース2つ
– 命名：ファイルは kebab-case、クラスは PascalCase、関数は camelCase
– エラー処理： try-catchを使い、意味のあるエラーメッセージを含める
– コメント： 「何をするか」ではなく「なぜそうするか」を書く
## 4. アーキテクチャ概要
# ディレクトリ構成・主要モジュールの役割
src/
├── api/ # エンドポイント定義
├── services/ # ビジネスロジック
├── models/ # DBスキーマ
└── utils/ # 共通ユーティリティ
## 5. 常に守ること / 絶対にしてはいけないこと
– 常に： Zodを使ってリクエストのバリデーションを行う
– 常に： 新機能にはJestのユニットテストを追加する
– 禁止： envファイルの値をハードコーディングしない
– 禁止： anyをTypeScriptの型として使わない
💡 最優先で書くべきは「ビルド・コマンドセクション」
実際の利用事例から「最もインパクトが大きいセクション」として、ビルド・テスト・Lintコマンドの明記が挙げられています。Claudeはコマンドを推測しようとして誤って実行することがあるため、これを明記するだけで多くの失敗を防げます。
実践例──ECサイトAPIプロジェクトのCLAUDE.md
より実践的な例として、ECサイトのバックエンドAPIプロジェクトの場合を見てみましょう。
CLAUDE.mdECサイトAPIの実践例
# ECサイト バックエンドAPI
## ビルド・開発コマンド
npm install # 依存関係のインストール
npm run dev # 開発サーバー起動（port:3000）
npm run test # Jest テスト実行
npm run test:watch # テストのウォッチモード
npm run build # TypeScriptコンパイル
npm run lint # ESLintチェック
## プロジェクト概要
– 目的：アパレルECサイト向けのREST API
– 利用者：管理者（商品・在庫管理）とエンドユーザー（購入・決済）
– 技術スタック：Node.js 20, TypeScript 5, Express, PostgreSQL 15, Redis, Docker
– 認証：JWT（accessToken 15分, refreshToken 7日）
## コーディング規約
### 命名規則
– ファイル名：kebab-case（例: user-service.ts）
– クラス名：PascalCase（例: ProductService）
– 関数・変数：camelCase（例: getUserById）
– 定数：UPPER_SNAKE_CASE（例: MAX_RETRY_COUNT）
– DBテーブル：snake_case（例: order_items）
### APIレスポンス形式（必ず統一すること）
// 成功時
{ “success”: true, “data”: { … }, “timestamp”: “ISO8601” }
// エラー時
{ “success”: false, “error”: { “code”: “ERROR_CODE”, “message”: “…” } }
### 必須ルール
– 常に：Zodでリクエストのバリデーションを実施する
– 常に：エンドポイントにはJestのテストを追加する（カバレッジ80%以上）
– 常に：非同期処理はasync/awaitを使い、try-catchを入れる
– 禁止：TypeScript の any 型の使用
– 禁止：APIキーや認証情報のハードコーディング（.envから取得）
## アーキテクチャ
src/
├── api/routes/ # ルーティング（エンドポイント定義のみ）
├── services/ # ビジネスロジック（ここに処理を書く）
├── models/ # Prismaスキーマ・型定義
├── middleware/ # 認証・バリデーション
└── utils/ # 共通ユーティリティ
## Gitワークフロー
– ブランチ：feature/xxx または fix/xxx
– コミット：Conventional Commits形式（例: feat: add cart endpoint）
– マージ：PR必須・CI通過・1名以上のレビュー承認が必要
## ビルド・開発コマンド
npm install # 依存関係のインストール
npm run dev # 開発サーバー起動（port:3000）
npm run test # Jest テスト実行
npm run test:watch # テストのウォッチモード
npm run build # TypeScriptコンパイル
npm run lint # ESLintチェック
## プロジェクト概要
– 目的：アパレルECサイト向けのREST API
– 利用者：管理者（商品・在庫管理）とエンドユーザー（購入・決済）
– 技術スタック：Node.js 20, TypeScript 5, Express, PostgreSQL 15, Redis, Docker
– 認証：JWT（accessToken 15分, refreshToken 7日）
## コーディング規約
### 命名規則
– ファイル名：kebab-case（例: user-service.ts）
– クラス名：PascalCase（例: ProductService）
– 関数・変数：camelCase（例: getUserById）
– 定数：UPPER_SNAKE_CASE（例: MAX_RETRY_COUNT）
– DBテーブル：snake_case（例: order_items）
### APIレスポンス形式（必ず統一すること）
// 成功時
{ “success”: true, “data”: { … }, “timestamp”: “ISO8601” }
// エラー時
{ “success”: false, “error”: { “code”: “ERROR_CODE”, “message”: “…” } }
### 必須ルール
– 常に：Zodでリクエストのバリデーションを実施する
– 常に：エンドポイントにはJestのテストを追加する（カバレッジ80%以上）
– 常に：非同期処理はasync/awaitを使い、try-catchを入れる
– 禁止：TypeScript の any 型の使用
– 禁止：APIキーや認証情報のハードコーディング（.envから取得）
## アーキテクチャ
src/
├── api/routes/ # ルーティング（エンドポイント定義のみ）
├── services/ # ビジネスロジック（ここに処理を書く）
├── models/ # Prismaスキーマ・型定義
├── middleware/ # 認証・バリデーション
└── utils/ # 共通ユーティリティ
## Gitワークフロー
– ブランチ：feature/xxx または fix/xxx
– コミット：Conventional Commits形式（例: feat: add cart endpoint）
– マージ：PR必須・CI通過・1名以上のレビュー承認が必要
✅ ポイント：ディレクトリの役割まで書くと効果的
「services/ にビジネスロジックを書く」という情報があれば、Claudeは自動で適切なファイルにコードを配置してくれるようになります。これが「毎回言わなくてよくなる」体験のコアです。
効果を体感──CLAUDE.mdあり・なしで何が変わるか
実際にCLAUDE.mdの有無でClaudeの回答がどう変わるか、具体的なやり取りで比較してみましょう。
「ユーザー登録APIのエンドポイントを作って」と依頼した場合
❌ CLAUDE.md なし
あなた
ユーザー登録APIのエンドポイントを作って
Claude（問題のある回答）
var express = require('express') で作りました。バリデーションは後でつけてください。テストは省略しています。→ JavaScriptで生成（プロジェクトはTypeScript）
→ Zodバリデーションなし
→ テストなし
→ レスポンス形式が独自（統一形式と違う）
✅ CLAUDE.md あり
あなた
ユーザー登録APIのエンドポイントを作って
Claude（良い回答）
TypeScript + Zodでバリデーション付きエンドポイントを
→ TypeScriptで正しく生成
→ Zodバリデーション自動追加
→ Jestテストセット付き
→ 統一レスポンス形式で出力
→ 適切なディレクトリに配置
src/api/routes/user.ts に作成し、ビジネスロジックは src/services/user-service.ts に分離しました。レスポンスは統一形式に準拠、Jestテストも追加しています。→ TypeScriptで正しく生成
→ Zodバリデーション自動追加
→ Jestテストセット付き
→ 統一レスポンス形式で出力
→ 適切なディレクトリに配置
CLAUDE.mdで得られる効果
説明の手間がゼロに
毎回「TypeScript使ってる」「Zodでバリデーションして」と書く必要がなくなる
コードの一貫性が上がる
命名規則・レスポンス形式・エラー処理が全コード統一される
テストが自動でついてくる
「テスト書いて」と毎回言わなくても自動でJestテストが追加される
適切な場所にコードが置かれる
ディレクトリ構成を知っているので、どのファイルを作るか正確に判断できる
「育てるもの」として運用するコツ
CLAUDE.mdは完成形を一度に書こうとしないのがポイントです。最初は短くていい──プロジェクトと一緒に少しずつ育てていくものです。
💡 公式ドキュメントの推奨アドバイス
「新しいチームメンバーが生産性を上げるために必要な情報と同じ内容を書くとよい」「すべてのセッションで保持すべき事実に限定すること」とされています。書きすぎると重要なルールが埋もれてしまいます。
段階的に育てるロードマップ
Day 1
最小限で始める
claude /init で自動生成 → ビルドコマンドとプロジェクト概要だけ確認・修正する。完璧でなくていい。
1週目
繰り返し指示したことを追記する
「あ、また同じことClaudeに言った」と気づいた瞬間がCLAUDE.mdに書き足すタイミング。例：「Zodを使ってと3回言った → CLAUDE.mdに追加」
1ヶ月後
コーディング規約を整備する
チームで「こういうパターンが良い」と判断したことをどんどん追記。APIレスポンス形式・命名規則・テスト方針など。
3ヶ月後
不要な記述を整理・slim化する
長くなりすぎたCLAUDE.mdは効果が薄れる。「本当に毎回必要か？」と見直し、サブディレクトリのCLAUDE.mdに分割することも検討。
効果的な書き方のポイント
- 「毎回Claudeに言っていること」が追記のタイミング──繰り返しが書き足すサイン
- 書くのは「Claudeの動作を変えること」だけ──変化しない情報は書かない
- 長い手順書はCLAUDE.mdではなく別ファイルに書き、
@docs/setup.mdでインポートする - 「常にXすること」「絶対にYしないこと」の形式で書くと指示が明確になる
- Auto memoryと組み合わせると、ClaudeがデバッグのコツなどをBuildコマンドなど自動で学習してくれる
⚠️ 注意：書きすぎると逆効果
CLAUDE.mdが長くなりすぎると、重要なルールが埋もれてしまい、一貫した動作が得られにくくなります。「50行以内に収める」を目安に、本当に必要な情報だけを書きましょう。細かい手順は別ファイルに移して参照する形が推奨されています。
よくある質問
CLAUDE.mdに書いた内容は絶対に守られますか？
Anthropic公式ドキュメントによれば、CLAUDE.mdは「強制されるルール」ではなく「Claudeが参照するコンテキスト」として扱われます。より具体的で簡潔な指示ほど一貫して従ってくれます。曖昧な指示は解釈にぶれが生じることがあるため、「常に〜すること」「絶対に〜しないこと」という明確な形式で書くのがおすすめです。
CLAUDE.mdをGitで管理するべきですか？
チームで共有するプロジェクト用のCLAUDE.md（プロジェクトルート）はGitにコミットするのが推奨です。一方、個人設定のCLAUDE.local.mdはチーム全員に適用するものではないため、.gitignoreに追加して管理から除外しましょう。
claude /initが使えない場合はどうすればいいですか？手動でプロジェクトルートに
CLAUDE.md という名前のファイルを作成するだけでOKです。中身が空でも認識されます。この記事の「基本フォーマット」セクションを参考に、ビルドコマンドだけ書いた最小構成から始めましょう。サブディレクトリにも CLAUDE.md を置けますか？
はい、置けます。例えば
src/api/CLAUDE.md に「このディレクトリ内のAPIはすべてZodで検証すること」といったAPIモジュール固有のルールを書けます。Claude Codeはディレクトリを遡りながら複数のCLAUDE.mdを読み込み、合算して使います（より具体的な設定が優先されます）。Auto memoryとCLAUDE.mdはどちらを使えばいいですか？
目的が違うので、両方使うのが理想です。CLAUDE.mdはチームのルールや技術スタックなど「最初から決まっていること」を書く場所。Auto memoryはClaude Code v2.1.59以降で使える機能で、セッション中にあなたが修正したことや好みをClaudeが自動で学習・保存してくれる機能です。
個人のグローバルCLAUDE.mdには何を書けばいいですか？
~/.claude/CLAUDE.md には、どのプロジェクトでも共通する個人的な好みを書きます。たとえば「コメントは英語ではなく日本語で書いてほしい」「複雑な概念を説明するときは図や例を使ってほしい」「コードの前に必ず要件を確認してほしい」などです。まとめ
CLAUDE.mdは、たった数行書くだけでClaude Codeの回答品質を劇的に向上させることができる、最もコストパフォーマンスの高い設定です。
大切なのは「完璧なものを一度に作ろうとしない」こと。最初はビルドコマンドとプロジェクト概要だけでいい。「また同じことClaudeに言った」と気づいたときに少しずつ追記していく──そのサイクルを続けることで、あなたのプロジェクトを深く理解するAIパートナーが育っていきます。
📌 この記事のまとめ
- CLAUDE.mdはClaudeへの「事前説明書」。セッション開始時に自動で読み込まれる
- 置き場所は3種類：グローバル（~/.claude/）・プロジェクト（ルート）・ローカル（個人）
claude /initで自動生成される雛形をベースに始めると楽- 最優先で書くべきはビルド・テスト・Lintのコマンド
- 書き方のコツは「常にXすること」「絶対にYしないこと」の明確な形式
- 「繰り返しClaudeに言っていること」を気づいたたびに追記する運用が鉄板
- 長くなりすぎたら整理・slim化する。50行以内が目安
- 最初は短くてOK。プロジェクトと一緒に育てるものと考える
📎 参考リンク
Anthropic公式ドキュメント「Memory」：code.claude.com/docs/en/memory
掲載情報：2026年5月時点 ／ Claude Code v2.1.59以降でAuto memoryが利用可能
掲載情報：2026年5月時点 ／ Claude Code v2.1.59以降でAuto memoryが利用可能
