Chapter 32: Claude Code の高度な使い方
CLAUDE.md、スキル、Hooks、カスタムエージェント
32.1 CLAUDE.md の設計パターン
CLAUDE.md はプロジェクトルートに置くことで、Claude Code がセッション開始時に自動ロードするコンテキストファイルです。単なるメモではなく、AI の振る舞いを宣言的に制御する設計書として扱うことが重要です。
階層構造と読み込み順序
Claude Code は以下の順序で CLAUDE.md を読み込みます。
~/.claude/CLAUDE.md # グローバル設定(全プロジェクト共通)
<project-root>/CLAUDE.md # プロジェクト設定
src/feature/CLAUDE.md # サブディレクトリ設定(指示テキストのみ)注意: スキル・エージェント定義はプロジェクトルートの
.claude/のみ有効です。サブディレクトリの.claude/は無視されます。
効果的な CLAUDE.md の構成
# プロジェクト: ECサービス API
## 技術スタック
- TypeScript 5.x + Node.js 22
- PostgreSQL 16(Prisma ORM)
- Vitest でユニットテスト
## コーディング規約
- 関数は純粋関数を優先。副作用は I/O 層に閉じ込める
- エラーは `Result<T, E>` 型で表現(never throw)
- `any` 型禁止。`unknown` を使い型ガードで絞り込む
## 禁止事項
- `console.log` をコミットしない(logger モジュールを使う)
- 環境変数の直書き禁止(`config/env.ts` 経由)
## よく参照するファイル
- `docs/api-spec.md` — REST API 設計書
- `docs/db-schema.md` — テーブル定義トークン予算の管理
CLAUDE.md のサイズが大きくなるほどコンテキストを圧迫します。目安として 500〜1000文字以内 に収め、詳細は別ファイルへのポインタで参照する設計にします。
## 詳細ドキュメント
- アーキテクチャ → `docs/architecture.md`
- セキュリティポリシー → `docs/security.md`
- テスト戦略 → `docs/testing.md`32.2 カスタムスキルの作成
スキルは .claude/skills/ 以下に Markdown ファイルとして定義します。Claude Code の / コマンドから呼び出せる再利用可能なプロセスです。
スキルファイルの構造
.claude/
└── skills/
├── pr-review.md # PR レビュースキル
├── db-migrate.md # DB マイグレーション手順
└── release.md # リリース手順スキルの例(pr-review.md):
---
name: PR レビュー
description: PR の品質チェックを実行する
command: pr-review
---
以下の手順で PR をレビューする:
1. `gh pr diff` で変更差分を確認
2. 型安全性を検証(`any` 型の使用をチェック)
3. テストカバレッジが 80% 以上か確認
4. エラーハンドリングの漏れを指摘
5. パフォーマンスリグレッションがないか確認
6. レビュー結果を Markdown テーブルで出力する自動ロードスキルと呼び出し型スキルの使い分け
| 種別 | 用途 | トークン消費 |
|---|---|---|
| 自動ロード | 常時必要なコンテキスト | 高(常時消費) |
呼び出し型(/ コマンド) | 特定タスク時のみ | 低(呼び出し時のみ) |
チームワークや PR レビューなど頻度が低いが複雑なプロセスは呼び出し型にすることで、全体のトークン予算を節約できます。
32.3 Hooks によるワークフロー自動化
Hooks は特定のイベントで自動実行されるスクリプトです。.claude/settings.json に定義します。
Hooks 設定の正しい形式
{
"hooks": {
"PostToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "echo '[Hook] Bash tool used'"
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "bash .claude/hooks/on-stop.sh"
}
]
}
]
}
}注意:
Event: [{ type, command }]の旧形式はエラーになります。hooks配列ラッパーが必須です。
実践的な Hooks の活用例
コミット前の自動フォーマット:
# .claude/hooks/pre-commit.sh
#!/bin/bash
npx prettier --write $(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(ts|tsx)$')
npx eslint --fix $(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(ts|tsx)$')
git add -uセッション終了時の進捗記録:
# .claude/hooks/on-stop.sh
#!/bin/bash
DATE=$(date +%Y-%m-%d)
echo "## $DATE" >> tasks/progress.md
git diff --stat >> tasks/progress.md利用可能なイベント一覧:
| イベント | タイミング |
|---|---|
PreToolUse | ツール実行前 |
PostToolUse | ツール実行後 |
UserPromptSubmit | プロンプト送信時 |
Stop | セッション終了時 |
32.4 カスタムエージェントの定義
.claude/agents/ 以下に Markdown ファイルを置くことで、専門的な役割を持つエージェントを定義できます。
エージェント定義ファイルの例
---
name: silent-failure-hunter
description: エラーハンドリングの欠落・例外の黙殺を検出する専門エージェント
---
あなたはコードの「黙殺」を探す専門家です。
## ミッション
以下のパターンを検出して報告する:
- 空の catch ブロック
- エラーを return しない非同期関数
- Promise の `.catch()` 漏れ
- `try/finally` のないリソース解放
## 出力フォーマット
severity: "CRITICAL | HIGH | MEDIUM"
file: "path/to/file.ts"
line: 42
issue: "空の catch ブロックでエラーが黙殺されている"
fix: "catch (e) { logger.error(e); throw e; }"エージェントチームの構成
複数エージェントを並列実行する場合の構成:
32.5 パーミッション設定の最適化
.claude/settings.json の permissions セクションでツール使用を細かく制御できます。
設定例
{
"permissions": {
"allow": [
"Bash(git *)",
"Bash(npm run *)",
"Bash(npx prettier *)",
"Read(**/*.ts)",
"Write(src/**)",
"WebFetch(https://api.github.com/*)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(curl * | bash)",
"Write(.env*)"
]
}
}パターンマッチングのルール
| パターン | 意味 |
|---|---|
Bash(git *) | git で始まる任意の bash コマンドを許可 |
Read(**/*.ts) | 任意の .ts ファイルの読み込みを許可 |
Write(src/**) | src/ 以下への書き込みを許可 |
WebFetch(https://api.github.com/*) | GitHub API へのアクセスのみ許可 |
本番環境のシークレットや .env ファイルへの書き込みを deny に追加することで、AIによる意図しない設定変更を防止できます。
TODO: あとで実際のスクリーンショットに置き換え -
.claude/settings.jsonのパーミッション設定画面と、制限に引っかかったときのエラー表示
チーム共有とローカルオーバーライド
.claude/settings.json # チーム共有(git 管理下)
.claude/settings.local.json # 個人設定(.gitignore に追加)settings.local.json は settings.json の設定を上書きします。個人の開発スタイルに合わせたカスタマイズを、チームの設定を壊さずに行えます。