Claude Code設定の全体像
Claude Codeは、CLAUDE.mdファイルを起点にプロジェクトの文脈を理解し、コード生成・レビュー・デバッグを行います。 しかし、設定ファイルの種類が多く、どこに何を書くべきか迷うことも少なくありません。
この記事では、CLAUDE.mdの書き方、.claude/rules/によるルールの分割管理、 Hooks・Skills・レビューエージェントの設定まで、実践的なベストプラクティスをまとめます。
graph TB
subgraph "グローバル設定"
A["~/.claude/CLAUDE.md<br/>全プロジェクト共通"]
B["~/.claude/settings.json<br/>権限・環境変数"]
end
subgraph "プロジェクト設定"
C["CLAUDE.md<br/>チーム共有ルール"]
D["CLAUDE.local.md<br/>個人用(.gitignore)"]
E[".claude/rules/*.md<br/>条件付きルール"]
F[".claude/settings.json<br/>プロジェクト設定"]
G["REVIEW.md<br/>レビュー専用ルール"]
end
subgraph "拡張機能"
H[".claude/skills/<br/>カスタムスキル"]
I[".claude/agents/<br/>カスタムエージェント"]
end
A --> C
B --> F
C --> E
C --> G
F --> H
F --> I
CLAUDE.mdの基本と階層構造
Claude Codeは起動時に複数のCLAUDE.mdファイルを読み込みます。 ファイルの配置場所によってスコープと優先度が異なり、後に読み込まれるほど優先度が高くなります。
| ファイルパス | スコープ | Git管理 | 用途 |
|---|---|---|---|
~/.claude/CLAUDE.md | 全プロジェクト共通 | No | 言語設定、個人の好み |
{root}/CLAUDE.md | プロジェクト全体 | Yes | チーム共通ルール・アーキテクチャ |
{root}/CLAUDE.local.md | プロジェクト個人用 | No | 個人のワークフロー |
{subdir}/CLAUDE.md | サブディレクトリ | Yes | ディレクトリ固有のルール |
.claude/rules/*.md | 条件付き or 全体 | Yes | モジュール化されたルール |
CLAUDE.mdに書くべきこと
Claude Code作者のBoris Cherny氏は約100行でCLAUDE.mdを運用しています。 公式ドキュメントでは200行以内が推奨されており、長くなるほどコンテキストを消費し遵守率が低下します。
書くべき内容は以下の4カテゴリに集約されます:
- 技術スタック: フレームワーク、言語、主要ライブラリのバージョン
- ビルドコマンド:
dev/build/test/lint - アーキテクチャ: ディレクトリ構成と各ディレクトリの役割
- コーディング規約: Claudeがデフォルトで間違えやすいプロジェクト固有のルール
# CLAUDE.md
## Tech Stack
- Framework: Astro 5 (静的サイト生成)
- UI: React (Islands Architecture)
- Styling: Tailwind CSS v4
- Deploy: Vercel
## Commands
npm run dev # 開発サーバー
npm run build # 本番ビルド
npm run test # テスト実行
## Architecture
- src/pages/ - ルーティング
- src/components/ - UIコンポーネント
- src/content/ - コンテンツ(.astroファイル)
- src/layouts/ - レイアウト
## Conventions
- 記事はHTML + Tailwind CSS(マークダウン不使用)
- クイズは必ず3〜5問含める
- コンポーネントはnamed exportを使用 書くべきでないこと
取捨選択の基準は「この指示がなければClaudeは間違えるか?」です。 以下はCLAUDE.mdに含めるべきではありません:
- Claudeが既にデフォルトでやっていること: 「セキュアなコードを書け」「テストを書け」など
- 一般的なコーディングルール: 「変数名は分かりやすく」「DRYを守れ」など
- コードから読み取れる情報: 既存のコード規約は実際のコードから学習される
- 一時的なタスク情報: 進行中の作業はメモリやTodoで管理する
ルールのモジュール化 — .claude/rules/
CLAUDE.mdが肥大化してきた場合、.claude/rules/ディレクトリにルールを分割できます。
各ファイルは独立したマークダウンで、フロントマターで適用条件を指定できます。
ディレクトリ構成例
.claude/rules/
├── frontend.md # フロントエンド規約
├── api.md # API開発ルール
├── testing.md # テスト方針
├── security.md # セキュリティルール
└── content.md # コンテンツ生成ルール 条件付きルール(globsベース)
フロントマターにglobsを指定すると、そのパターンに一致するファイルを操作する場合のみルールが適用されます。
これにより、フロントエンドとバックエンドで異なるルールを自動的に切り替えできます。
---
globs: "src/components/**/*.tsx"
---
# Reactコンポーネントルール
- propsにはTypeScript型定義を必ず付与する
- useEffectの依存配列は明示的に指定する
- client:load は即座に操作が必要な要素のみに使用する
- client:visible をスクロール下部の要素に優先的に使用する ---
globs: "src/content/**/*.astro"
---
# コンテンツ生成ルール
- 本文はHTML + Tailwind CSSで記述(マークダウン不使用)
- 見出し階層: h2 → h3 → h4(h1はレイアウト側で出力)
- 各記事の末尾にクイズ3〜5問を含める
- ビジュアル要素を最低2種類使用する settings.jsonで権限とHooksを管理
settings.jsonはClaude Codeの動作を制御する設定ファイルです。
CLAUDE.mdが「何をすべきか」を伝えるのに対し、settings.jsonは「何ができるか」を制御します。
| ファイルパス | スコープ | Git管理 |
|---|---|---|
~/.claude/settings.json | ユーザーグローバル | No |
.claude/settings.json | プロジェクト共有 | Yes |
.claude/settings.local.json | プロジェクト個人用 | No |
パーミッション設定
パーミッションはdeny → ask → allowの順で評価され、最初にマッチしたルールが適用されます。
セキュリティ上、denyリストを先に定義するのがベストプラクティスです。
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Bash(sudo:*)",
"Bash(rm -rf:*)"
],
"allow": [
"Bash(npm run lint)",
"Bash(npm run test:*)",
"Bash(npm run build)",
"Read(src/**)",
"Edit(src/**)",
"Write(src/content/**)"
]
}
} Hooks — 確実に実行される自動化
HooksはCLAUDE.mdと違い、100%確実に実行されます。 ツール実行の前後にシェルコマンドを差し込むことで、フォーマット・バリデーション・安全チェックを自動化できます。
| イベント | タイミング | 主な用途 |
|---|---|---|
PreToolUse | ツール実行前 | 危険なコマンドのブロック、入力の検証 |
PostToolUse | ツール実行後 | フォーマッター実行、リント、ログ記録 |
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "npx prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\""
}
]
}
],
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "echo \"$CLAUDE_TOOL_INPUT\" | grep -qE 'rm -rf|DROP TABLE|--force' && exit 2 || exit 0"
}
]
}
]
}
} カスタムSkillsの作り方
Skillsは、繰り返し行うワークフローをパッケージ化する仕組みです。
.claude/skills/{name}/SKILL.mdにマークダウンで定義し、スラッシュコマンドとして呼び出せます。
SKILL.mdの構造
---
name: deploy-production
description: >
プロダクション環境へのデプロイを実行するスキル。
「デプロイして」「本番に反映」「deploy」「リリース」
などのリクエストで発動。
allowed-tools: Bash, Read, Glob
---
# プロダクションデプロイ
## 前提条件チェック
1. mainブランチにいることを確認
2. 未コミットの変更がないことを確認
## 手順
1. `npm run build` でビルド
2. `npm run test` でテスト実行
3. テスト成功後、`vercel --prod` でデプロイ
4. デプロイURLを報告 descriptionのコツ
Claudeはスキルを「使わない」方向に偏る傾向があります。 descriptionにトリガーワードを明示的に列挙することで、適切にスキルが発動するようになります。
# 悪い例 — 発動しにくい
description: ダッシュボードを作成するスキル
# 良い例 — トリガーワードを明示
description: >
ダッシュボードを作成するスキル。
「ダッシュボード」「データ可視化」「メトリクス表示」
「グラフを作って」「分析画面」などユーザーがデータの
可視化に言及した場合は必ず使用すること。 レビューエージェントの設定
Claude Codeのコードレビュー機能は、PRの変更を複数の専門エージェントが並行分析し、 信頼度スコアに基づいてフィルタリングした指摘のみをコメントとして投稿します。
REVIEW.mdの活用
プロジェクトルートにREVIEW.mdを配置することで、
コードレビュー時の追加指示として活用できます(Claude Code公式のコードレビュー機能やカスタムスキルで参照可能)。
# Review Rules
## 必ずチェックする項目
- 新しいAPIエンドポイントには統合テストがあること
- DBマイグレーションは後方互換であること
- 環境変数の追加は .env.example にも反映されていること
- セキュリティ関連の変更はセキュリティチームのレビューを必須にする
## コードスタイル
- 関数は50行以内を推奨
- ネストは3段階まで
- 早期リターンを推奨
## スキップする項目
- /gen/ 配下の自動生成ファイルのフォーマット指摘
- フォーマットのみの変更
- テストファイルの命名規約(柔軟に許容) レビューの仕組み
PRの変更を解析
差分ファイルを読み取り、変更の種類(新機能・バグ修正・リファクタリング等)を判定
専門エージェントが並行分析
セキュリティ・パフォーマンス・ロジック・スタイルの観点で複数エージェントが同時にレビュー
信頼度スコアの算出
各指摘に0〜100の信頼度スコアを付与。コンテキストの確実性や重大度を加味
フィルタリングとコメント投稿
デフォルトでスコア80以上の指摘のみをPRコメントとして投稿。ノイズを最小限に抑制
カスタムエージェントの定義
.claude/agents/にマークダウンファイルを配置すると、
特定の役割に特化したサブエージェントを定義できます。
メインのClaude CodeセッションからAgentツールで呼び出されます。
.claude/agents/
├── security-reviewer.md # セキュリティレビュー
├── test-writer.md # テスト自動生成
└── doc-writer.md # ドキュメント生成 ---
name: security-reviewer
description: セキュリティ観点でコードをレビューする
tools: Read, Glob, Grep, WebSearch
model: sonnet
---
# Security Reviewer
コード変更に対してOWASP Top 10の観点でチェックする:
- SQLインジェクション・NoSQLインジェクション
- XSS(反射型・格納型・DOM型)
- 認証・認可の不備
- シークレットのハードコード
- 依存関係の脆弱性
重大度の高い問題を発見した場合は、修正案も提示する。 メモリシステムの運用
Claude Codeのメモリは~/.claude/projects/{hash}/memory/MEMORY.mdに保存され、
セッション間で学習内容を引き継ぎます。ただし、MEMORY.mdは200行制限があるため、
運用には工夫が必要です。
メモリ運用のベストプラクティス
- インデックスとして使う: MEMORY.mdは1行1エントリのインデックスにし、詳細は個別ファイルに分割
- 定期的に整理する: 10セッション後には約30%の冗長エントリが蓄積されるため手動整理を推奨
- 保存すべきもの: ユーザーの好み・フィードバック・プロジェクト文脈・外部リソースへの参照
- 保存すべきでないもの: コードから読み取れるパターン、git履歴で追える情報、一時的なタスク状態
実践的な設定例
ここまでの内容を踏まえ、実際のプロジェクトで使える設定の全体像を整理します。
# プロジェクト全体の構成
my-project/
├── CLAUDE.md # チーム共有ルール(Git管理)
├── CLAUDE.local.md # 個人設定(.gitignore)
├── REVIEW.md # レビュー専用ルール(Git管理)
├── .claude/
│ ├── settings.json # 権限・Hooks(Git管理)
│ ├── settings.local.json # 個人設定(.gitignore)
│ ├── rules/
│ │ ├── frontend.md # フロントエンド規約(globs付き)
│ │ ├── api.md # API規約(globs付き)
│ │ └── security.md # セキュリティルール(常時適用)
│ ├── skills/
│ │ ├── deploy/SKILL.md # デプロイスキル
│ │ └── generate/SKILL.md # コード生成スキル
│ └── agents/
│ ├── security-reviewer.md # セキュリティレビュー
│ └── test-writer.md # テスト生成
└── src/
└── ... Git管理の判断基準
| ファイル | Git管理 | 理由 |
|---|---|---|
CLAUDE.md | Yes | チーム全員で共有すべきルール |
CLAUDE.local.md | No | 個人の好み・ワークフロー |
REVIEW.md | Yes | レビュー基準はチームで統一 |
.claude/settings.json | Yes | 権限・Hooksはチームで統一 |
.claude/settings.local.json | No | 個人のパーミッション設定 |
.claude/rules/*.md | Yes | コーディング規約はチーム共有 |
.claude/skills/ | Yes | ワークフローはチーム共有 |
.claude/agents/ | Yes | エージェント定義はチーム共有 |
まとめ
Claude Codeの設定を効果的に管理するポイントを振り返ります:
- CLAUDE.mdは簡潔に: 200行以内、「なければ間違えるか?」を基準に厳選
- ルールは分割管理:
.claude/rules/でglobs条件付きファイルに分割 - 確実性が必要ならHooks: CLAUDE.mdはコンテキスト参照、Hooksは確実に実行
- レビューはREVIEW.mdで強化: プロジェクト固有のレビュー基準を定義
- 繰り返し作業はSkillsに: descriptionにトリガーワードを明示して発動率を上げる
- Git管理の境界を意識: チーム共有ファイルとローカル専用ファイルを明確に分離
理解度チェック
Claude Codeの設定ファイルの中で、指示が100%確実に実行されるのはどれですか?
キーボード: 1〜4 で選択、Enter で回答