4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Code カスタマイズインターフェース完全ガイド — 設定の全体像と実プロジェクトでの運用例

4
Last updated at Posted at 2026-03-16

はじめに

Claude Code には、プロジェクトに合わせた振る舞いのカスタマイズ手段が数多く用意されています。CLAUDE.md は知っていても、Skills・Rules・Hooks・Agents など全体像を把握している人はまだ少ないのではないでしょうか。

この記事では Claude Code のカスタマイズインターフェースを利用頻度が高い順に解説 し、後半では 実際のプロジェクト(Nuxt2 → Next.js 移行)でどう運用しているか を具体的に紹介します。

カスタマイズインターフェース一覧

まず全体像を俯瞰します。

# インターフェース 設定場所 発火タイミング 一言で言うと
1 CLAUDE.md プロジェクトルート / .claude/ 自動(セッション開始時) プロジェクトの「説明書」
2 Skills .claude/skills/ 自動 + 手動(/skill-name 再利用可能なスラッシュコマンド
3 Rules .claude/rules/ 自動(セッション開始時) モジュール化されたルール集
4 Settings .claude/settings.json 自動(セッション開始時) 権限・環境変数・フック設定
5 Agents .claude/agents/ 自動(Claude が判断)+ 手動 専門特化したサブエージェント
6 MCP Servers .mcp.json / ~/.claude.json 自動(セッション開始時) 外部ツール連携
7 Hooks settings.json 自動(ライフサイクルイベント) ツール実行前後の自動処理
8 Commands(レガシー) .claude/commands/ 手動(/command-name Skills の旧形式

以下、それぞれ詳しく見ていきます。


1. CLAUDE.md — プロジェクトの「説明書」

利用頻度:★★★★★(必須)

何をするものか

セッション開始時に自動で読み込まれるMarkdownファイルです。プロジェクトの概要・技術スタック・コーディングルール・ワークフローなどを記述し、Claude にプロジェクトの文脈を伝えます。

設定ファイルの階層

CLAUDE.md                    # プロジェクト共有(Git管理)
.claude/CLAUDE.md            # 同上(.claude配下でも可)
CLAUDE.local.md              # 個人用(自動で .gitignore)
~/.claude/CLAUDE.md          # ユーザーグローバル(全プロジェクト共通)

上位(プロジェクト)ほど優先度が高く、すべてマージして読み込まれます。

書くべきことの例

  • プロジェクト概要と技術スタック
  • 絶対ルール
  • ビルド・テストコマンド
  • ワークフロー(Skills の呼び出し順序など)
  • ディレクトリ構成の概要

いつ使うか

常に。 すべてのプロジェクトで最初に用意すべきファイルです。


2. Skills — 再利用可能なスラッシュコマンド

利用頻度:★★★★☆(中〜大規模プロジェクトで威力を発揮)

何をするものか

/skill-name で呼び出せるカスタムコマンドです。Markdown + YAML フロントマターで定義し、プロンプトテンプレート・使用ツール制限・モデル指定などを設定できます。

設定ファイル

.claude/skills/<skill-name>/SKILL.md   # プロジェクト用
~/.claude/skills/<skill-name>/SKILL.md  # ユーザーグローバル

フロントマターの主要フィールド

---
name: review-code
description: "コードレビューを実行する。引数: -s <spec> -i <impl>"
# Claude が自動で呼び出すかどうか(デフォルト: false)
disable-model-invocation: false
# ユーザーが /review-code で呼べるか(デフォルト: true)
user-invocable: true
# 使用するモデル(省略時は親セッションと同じ)
model: sonnet
# フォークして別コンテキストで実行
context: fork
# 使用可能なツールを制限
allowed-tools:
  - Read
  - Glob
  - Grep
---

動的な値の埋め込み

引数: $ARGUMENTS # /skill-name の後に続くテキスト全体
個別引数: $1, $2 # スペース区切りの個別引数
シェルコマンド: !`date`! # 実行結果を埋め込み

いつ使うか

  • 手動発火: ユーザーが /skill-name と入力したとき
  • 自動発火: disable-model-invocation: false の場合、description に合致するタスクを Claude が検知したとき

ユースケースの例:

  • 定型的なワークフロー(仕様抽出 → 実装計画 → レビュー)
  • プロジェクト固有のコーディング規約を参照用ドキュメントとして配置
  • 外部ツール連携の手順書

3. Rules — モジュール化されたルール集

利用頻度:★★★★☆(チーム開発で特に有効)

何をするものか

.claude/rules/ 配下に置くMarkdownファイルで、セッション開始時に自動で読み込まれます。CLAUDE.md を分割して管理できるイメージです。

設定ファイル

.claude/rules/*.md           # プロジェクト用(再帰的に検索)
~/.claude/rules/*.md          # ユーザーグローバル

パス限定ルール

YAML フロントマターの paths で、特定のファイルパターンに対してのみ適用するルールを定義できます。

exmaple
---
paths: ["src/**/*"]
---

# セキュリティルール

- 環境変数は `env.ts` で Zod スキーマを定義し `env` 経由で参照する
- Server Actions は「認証→認可→バリデーション→処理」の順序を厳守
- `dangerouslySetInnerHTML` は原則禁止

CLAUDE.md との使い分け

CLAUDE.md Rules
用途 プロジェクト全体の概要・ワークフロー トピック別の詳細ルール
粒度 1ファイル(大きくなりがち) トピックごとに分割
パス限定 不可 paths フロントマターで可能
チーム運用 コンフリクトしやすい ファイル分割でコンフリクト回避

いつ使うか

常に自動で読み込まれます。 CLAUDE.md が肥大化してきたら Rules への分割を検討しましょう。


4. Settings — 権限・環境変数・動作設定

利用頻度:★★★☆☆(権限管理が必要なプロジェクトで使用)

何をするものか

JSON 形式で Claude Code の動作を制御します。ツールの許可/拒否、環境変数、フック設定などを定義します。

設定ファイルの階層

.claude/settings.json        # プロジェクト共有(Git管理)
.claude/settings.local.json  # 個人用(自動で .gitignore)
~/.claude/settings.json      # ユーザーグローバル

主な設定項目

example
{
  "permissions": {
    "allow": [
      "Bash(npm run build:*)", // ワイルドカードで許可
      "Bash(npx tsc:*)",
      "mcp__notion__notion-fetch", // MCP ツールの許可
      "WebSearch",
    ],
    "deny": [
      "Bash(rm -rf:*)", // 危険なコマンドを拒否
    ],
  },
  "env": {
    "NODE_ENV": "development", // 環境変数の設定
  },
  "hooks": {
    /* 後述 */
  },
}

いつ使うか

  • 毎回の権限確認ダイアログが煩わしいとき → allow に追加
  • チーム共通で禁止したい操作があるとき → deny に追加
  • MCP ツールの許可を事前に設定しておきたいとき

5. Agents — 専門特化したサブエージェント

利用頻度:★★★☆☆(複雑なワークフローで活躍)

何をするものか

特定の専門タスクに特化した「分身」を定義します。使用ツール・モデル・権限を制限でき、メインセッションとは独立したコンテキストで動作します。

設定ファイル

.claude/agents/<name>.md     # プロジェクト用
~/.claude/agents/<name>.md    # ユーザーグローバル

フロントマターの主要フィールド

example
---
name: review-architecture
description: FSDアーキテクチャのレビュー
tools: Read, Glob, Grep # 使えるツールを制限(読み取り専用など)
model: sonnet # コスト最適化のため軽いモデルを指定
---

Skills との違い

Skills Agents
実行コンテキスト メインセッション or フォーク 常に独立コンテキスト
呼び出し方 /skill-name(ユーザー発火) Skills や Claude が @agent-name で起動
主な用途 ワークフローの定義 専門的なタスク実行
ツール制限 allowed-tools で可能 tools で可能

いつ使うか

専門性が高い、もしくは何かに特化したタスクを実行する際に使いましょう。

Tips

  • 並列レビュー: アーキテクチャ・セキュリティ・UX など観点別に同時実行
  • コスト最適化: 読み取り専用タスクに軽量モデル(Sonnet/Haiku)を指定
  • 安全性: 書き込みツールを持たせないことで意図しない変更を防止

6. MCP Servers — 外部ツール連携

利用頻度:★★★☆☆(外部サービス連携時に使用)

何をするものか

Model Context Protocol(MCP)サーバーを通じて、Claude Code に外部ツールの機能を追加します。GitHub・Slack・Notion・ブラウザ操作など、多様な連携が可能です。

設定ファイル

.mcp.json                   # プロジェクト共有(Git管理)
~/.claude.json               # ユーザーグローバル

設定例

{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": ["@notionhq/notion-mcp-server"],
      "env": {
        "NOTION_TOKEN": "${NOTION_TOKEN}"
      }
    },
    "chrome-devtools": {
      "command": "npx",
      "args": ["@anthropic/chrome-devtools-mcp-server"]
    }
  }
}

いつ使うか

  • Notion・Slack・GitHub などの外部サービスと連携するとき
  • Chrome DevTools でブラウザ操作(スクリーンショット・DOM操作)をしたいとき
  • データベースに直接クエリを投げたいとき

7. Hooks — ツール実行前後の自動処理

利用頻度:★★☆☆☆(自動化を突き詰めたい場合に使用)

何をするものか

Claude Code のライフサイクルイベント(ツール実行前後・セッション開始時など)にフックして、シェルコマンドを自動実行する仕組みです。

設定場所

settings.json 内の hooks キーに定義します。

フックイベント一覧

イベント タイミング
SessionStart セッション開始・再開・コンパクション後
PreToolUse ツール実行前(ブロック可能)
PostToolUse ツール実行成功後
Notification Claude が通知を送信するとき
Stop Claude が応答を完了したとき

設定例: ファイル保存後に自動フォーマット

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": "prettier --write $CLAUDE_FILE_PATH"
      }
    ]
  }
}

いつ使うか

  • ファイル編集後に Prettier / ESLint を自動実行したいとき
  • 特定のファイルを保護(編集をブロック)したいとき
  • Claude が入力待ちになったときにデスクトップ通知を出したいとき

8. Commands(レガシー)

利用頻度:★☆☆☆☆(新規は Skills を使用推奨)

.claude/commands/<name>.md に置く旧形式のスラッシュコマンドです。Skills が上位互換のため、新規作成は Skills を使いましょう。既存の Commands は引き続き動作します。


ベストプラクティスまとめ

最小構成(個人の小規模プロジェクト)

CLAUDE.md                    # プロジェクト概要 + ルール + コマンド

これだけでも十分効果があります。

推奨構成(チーム開発)

CLAUDE.md                        # 概要・ワークフロー・絶対ルール
.claude/
├── rules/
│   ├── coding-conventions.md    # コーディング規約
│   ├── security.md              # セキュリティルール
│   └── ...
├── settings.json                # 共有の権限設定
└── settings.local.json          # 個人の権限設定(.gitignore)

フル構成(AI駆動開発)

CLAUDE.md                        # 概要・ワークフロー
.claude/
├── skills/                      # スラッシュコマンド群
│   ├── spec-extract/SKILL.md
│   ├── plan-create/SKILL.md
│   ├── review/SKILL.md
│   └── domain-guide/SKILL.md   # 参照用ドキュメント
├── agents/                      # 専門サブエージェント
│   ├── spec-extractor.md
│   ├── review-architecture.md
│   └── review-security.md
├── rules/                       # 自動読み込みルール
│   ├── security.md
│   └── tailwind-css.md
├── settings.json                # 共有設定
└── settings.local.json          # 個人設定
.mcp.json                        # MCP サーバー設定

判断のフローチャート

Claude に伝えたい情報がある
├── プロジェクト全体の文脈? → CLAUDE.md
├── 特定ファイルパターンに限定したルール? → Rules
├── 繰り返し実行するワークフロー? → Skills
├── 専門的な分析を並列で実行したい? → Agents(Skills から呼ぶ)
├── 外部サービスと連携したい? → MCP Servers
├── ツール実行前後に自動処理を挟みたい? → Hooks
└── 権限を事前に許可/拒否したい? → Settings

実プロジェクトでの運用例: eventos フロントエンド移行

ここからは、イベント管理SaaS「eventos」のフロントエンドを Nuxt2 → Next.js 16 に移行する実プロジェクト での運用を紹介します。大規模移行を、AI駆動のスペック駆動開発で進めています。

プロジェクトの .claude ディレクトリ構成

eventos-console/
├── CLAUDE.md
└── .claude/
    ├── eventos-config.json          # 移行元パス等の設定(.gitignore)
    ├── settings.local.json          # 個人の権限設定
    ├── skills/                      
    │   ├── spec-eventos/            # 仕様書抽出
    │   ├── plan-eventos/            # 実装計画作成
    │   ├── impl-eventos/            # 実装
    │   ├── review-eventos/          # 総合レビュー
    │   ├── notion-task/             # Notion タスク連携
    │   ├── nextjs-architecture/     # FSD アーキテクチャガイド
    │   ├── nextjs-coding-conventions/
    │   ├── nextjs-data-fetch/
    │   ├── nextjs-i18n/
    │   ├── nextjs-security/
    │   ├── nextjs-typescript/
    │   ├── nextjs-tailwind-css/
    │   ├── nextjs-seo/
    │   └── nextjs-ux-quality/
    ├── agents/                      # 7 Agents
    │   ├── spec-extractor.md
    │   ├── implementation-planner.md
    │   ├── review-architecture.md
    │   ├── review-code-style.md
    │   ├── review-security.md
    │   ├── review-spec-compliance.md
    │   └── review-ux-quality.md
    └── rules/                       # 4 Rules
        ├── coding-conventions.md
        ├── security.md
        ├── seo.md
        └── tailwind-css.md

CLAUDE.md の役割

プロジェクトの「トップページ」として、以下を簡潔に記載しています。

# eventos フロントエンド(Next.js移行)

## プロジェクト概要

イベント管理SaaS「eventos」のフロントエンドを Nuxt2 → Next.js 16 へ移行するプロジェクト。
AI駆動のスペック駆動開発で約100ページを移行する。

## ワークフロー

1. `/spec-eventos -u <url> <page-path>` — 仕様書抽出
2. `/plan-eventos <spec-path>` — 実装計画作成
3. `/impl-eventos <spec-path>` — 実装計画に沿って実装
4. `/review-eventos -s <spec-path> -i <impl-path>` — 総合レビュー

## 絶対ルール

- Server Component をデフォルトとし、Client Componentは最小限にする
- API通信は必ずNext.jsサーバー経由
- 外部データは必ずZodでバリデーション
- `any` 禁止、`unknown` + type guard を使う
- Feature-Sliced Design の依存方向を守る

## 参照すべきルール

実装時は該当するSkillを参照すること(自動で読み込まれる)

ポイントは CLAUDE.md 自体は簡潔に保ち、詳細はSkillsとRulesに分散させている ことです。「参照すべきルール」として Skills への誘導だけ記載しています。

Skills の2つの使い分け

このプロジェクトでは Skills を 2つの目的 で使い分けています。

① ワークフロー型 Skills(手動発火)

ユーザーがスラッシュコマンドで明示的に呼び出す Skills です。

Skill 呼び出し方 役割
spec-eventos /spec-eventos -u <url> <path> 移行元ページから仕様書を自動生成
plan-eventos /plan-eventos <spec-path> 仕様書から実装計画を生成
impl-eventos /impl-eventos <spec-path> Chrome DevTools で比較しながら実装
review-eventos /review-eventos -s <spec> -i <impl> 5観点の並列レビュー
notion-task /notion-task -p <url> -sv <sprint> .plan.md → Notion タスク連携

例えば /spec-eventos は内部で以下の処理を自動化しています。

  1. 設定ファイルの検証.claude/eventos-config.json の存在と妥当性チェック
  2. Chrome DevTools でUI参照 — PC/SPの両方のスクリーンショットとDOM解析
  3. spec-extractor エージェントを起動 — ソースコード解析と仕様書生成
# spec-eventos/SKILL.md のフロントマター
---
name: spec-eventos
description: "eventos移行用の仕様書を抽出する。引数: -u <url> <page-path>"
---

② ナレッジベース型 Skills(自動参照)

Claude が実装中に 自動で参照する ための技術ドキュメントです。description に詳しい説明を書くことで、関連するタスクの際に Claude が自動でロードします。

Skill 内容
nextjs-architecture FSD レイヤー構造・依存関係ルール
nextjs-data-fetch Server Components / Server Actions / Route Handler のパターン
nextjs-i18n Cookie ベースの国際化設定
nextjs-security 環境変数保護・CSRF対策・認証フロー
nextjs-typescript type vs interface・Zod スキーマパターン
nextjs-tailwind-css eventos カスタムカラー・z-index 規約
nextjs-seo 管理画面のSEO設定(robots: false
nextjs-ux-quality WCAG 2.2 AA 準拠・Core Web Vitals
# nextjs-architecture/SKILL.md のフロントマター
---
name: nextjs-architecture
description:
  Feature-Sliced Design(FSD)ベースのプロジェクトアーキテクチャルール。
  app/widgets/features/sharedのレイヤー構造、依存関係、コンポーネント粒度、
  Server/Client Componentの使い分けを定義。ファイル作成やディレクトリ設計時に参照する。
---

description が具体的なほど、Claude が適切なタイミングで自動参照してくれます。

Agents による並列レビュー

/review-eventos を実行すると、5つの専門エージェントが並列起動 してレビューを行います。

/review-eventos -s specs/cm-event/users.md -i app/(cm)/event/users
    │
    ├── @review-spec-compliance  — 仕様書との差分チェック
    ├── @review-architecture     — FSD 依存方向・レイヤー配置
    ├── @review-security         — XSS/CSRF・認証・環境変数
    ├── @review-ux-quality       — WCAG 2.2 AA・Core Web Vitals
    └── @review-code-style       — 命名規約・TypeScript 型

各エージェントは以下のように定義されています。

# agents/review-architecture.md
---
name: review-architecture
description: FSDアーキテクチャルール、依存関係、Server/Client Component分離のレビュー
tools: Read, Glob, Grep # 読み取り専用に制限
model: sonnet # コスト最適化
---

設計のポイント:

  • tools: Read, Glob, Grep で読み取り専用に制限 → 意図しないファイル変更を防止
  • model: sonnet でコスト最適化 → レビューは Opus でなくても十分な品質
  • 並列実行 → 5つのレビューが同時に走るため、直列実行の5分の1の時間で完了
  • レビュー開始時に 対応する Skill を読み込む 指示を含めている
## レビュー開始時

まず以下のルールファイルを読んでください:

- .claude/skills/nextjs-architecture/SKILL.md
- .claude/skills/nextjs-data-fetch/SKILL.md

Rules による自動適用ルール

常に意識させたいルールは Rules に配置し、セッション開始時に自動で読み込ませています。

# .claude/rules/security.md
---
paths: ["src/**/*"]
---

# セキュリティルール

詳細なコード例は `nextjs-security` スキルを参照。

## 必須ルール

- 環境変数は `env.ts` で Zod スキーマを定義し `env` 経由で参照する
- Server Actions は「認証→認可→バリデーション→処理」の順序を厳守
- 認証トークンは HttpOnly Cookie に保存(localStorage 禁止)
- `dangerouslySetInnerHTML` は原則禁止

Rules と Skills の使い分け:

  • Rules = 短い要約 + チェックリスト(常に読み込まれるので軽量に)
  • Skills = コード例を含む詳細なドキュメント(必要なときだけ読み込み)

Rules から「詳細は nextjs-security スキルを参照」と Skills へ誘導するパターンが効果的です。

Settings による権限管理

.claude/settings.local.json で、頻繁に使うツールの権限確認をスキップしています。

{
  "permissions": {
    "allow": [
      "Bash(npm run build:*)",
      "Bash(npm run lint:*)",
      "Bash(npx tsc:*)",
      "Bash(git status:*)",
      "Bash(docker exec:*)",
      "mcp__chrome-devtools__take_screenshot",
      "mcp__chrome-devtools__navigate_page",
      "mcp__chrome-devtools__take_snapshot",
      "mcp__notion__notion-fetch",
      "mcp__notion__notion-search",
      "mcp__notion__notion-create-pages",
      "mcp__eventos-console-api__read_project_oas_*",
      "WebSearch"
    ]
  }
}

MCP ツールも mcp__<server>__<tool> 形式で個別に許可できます。

MCP Servers による外部連携

このプロジェクトでは4つの MCP サーバーを活用しています。

MCP Server 用途
Chrome DevTools 移行元ページのスクリーンショット・DOM解析・インタラクション確認
eventos-console-api バックエンド Laravel API の OpenAPI スキーマ参照
Notion 実装タスクの作成・ステータス更新
IDE TypeScript の型エラー診断

特に Chrome DevTools MCP は仕様抽出で大きな役割を果たしています。/spec-eventos -u <url> でURLを渡すと、PC表示とSP(iPhone 16エミュレーション)の両方を自動で解析し、レスポンシブ対応の差分まで仕様書に反映します。

ワークフロー全体像

すべてのインターフェースがどう連携しているかを図にすると以下のようになります。

[ユーザー] /spec-eventos -u <url> <page-path>
    │
    ▼
[Skill: spec-eventos]
    ├── Chrome DevTools MCP でスクリーンショット + DOM 取得
    ├── [Agent: spec-extractor] ソースコード解析
    │     └── Rules (security, coding-conventions) を自動参照
    └── specs/<path>.md に仕様書を出力
    │
    ▼
[ユーザー] /plan-eventos specs/<path>.md
    │
    ▼
[Skill: plan-eventos]
    ├── [Agent: implementation-planner] 実装計画を作成
    │     └── Skills (nextjs-architecture, nextjs-data-fetch) を参照
    └── specs/<path>.plan.md に計画書を出力
    │
    ▼
[ユーザー] /notion-task -p <url> -sv <sprint>
    │
    ▼
[Skill: notion-task]
    ├── .plan.md のタスクを解析
    ├── Notion MCP でサブタスクを一括作成
    └── ステータス同期(-update モード)
    │
    ▼
[ユーザー] /impl-eventos <spec-path>
    │
    ▼
[Skill: impl-eventos]
    └── .plan.md の内容に沿って実装
    │
    ▼
[ユーザー] /review-eventos -s <spec> -i <impl>
    │
    ▼
[Skill: review-eventos]
    ├── [Agent: review-spec-compliance]
    ├── [Agent: review-architecture]   ← 並列実行
    ├── [Agent: review-security]       ← 並列実行
    ├── [Agent: review-ux-quality]     ← 並列実行
    └── [Agent: review-code-style]     ← 並列実行

運用で得られた知見

Skills は「ワークフロー型」と「ナレッジベース型」に分けると整理しやすい

  • ワークフロー型は /skill-name で手動発火し、内部でエージェントを起動する
  • ナレッジベース型は description を具体的に書くことで、Claude が必要なときに自動参照する

Rules は軽量に、Skills で詳細を補完する

Rules は常に読み込まれるため、要約 + チェックリストに留め、コード例を含む詳細は Skills に記載します。

Agents はコスト意識を持って設計する

レビューエージェントは読み取り専用 + Sonnet モデルに制限することで、品質を維持しつつコストを抑えています。Opus は判断が必要なメインセッションに集中させます。

Settings の allow は積極的に使う

MCP ツールやビルドコマンドの権限確認は作業のテンポを崩すため、信頼できるコマンドは事前に許可しておくと効率が上がります。


おわりに

Claude Code のカスタマイズインターフェースは、CLAUDE.md だけでも始められますが、Skills・Rules・Agents・MCP を組み合わせることで、プロジェクト固有の開発ワークフローを丸ごと自動化できます。

特に大規模プロジェクトでは、Skills でワークフローを定義し、Agents で専門タスクを並列実行し、Rules で品質を担保する という組み合わせが強力です。

まずは CLAUDE.md から始めて、プロジェクトの成長に合わせて他のインターフェースを段階的に導入していくのがおすすめです。

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?