🈯
Claude Codeの機能が多くて混乱している人へ

2026/01/18に公開
Claude
Claude Code
tech
 はじめにClaude Codeを触り始めると、「Skills」「Custom Commands」「Hooks」「サブエージェント」「MCP Servers」...と、似たような機能がいくつも出てきて混乱しませんか？

それらを使わなくても開発効率は使っていない時よりもかなり上がっているので、私は自腹で月300ドル払っていましたが、半年ほどあまり活用していませんでした。しかし活用したところかなり便利だったので一度まとめてみます。
この記事では、各機能の使い方だけでなく、「なぜその機能が存在するのか」「どういう問題を解決するのか」という思想から説明していきます。思想を理解すれば、新しい場面に遭遇しても自分で判断できるようになりますし、「この機能、こういう使い方もできるんじゃないか」というアイデアも浮かびやすくなるのかなと思います。

 Claude Codeの考え方を理解する
 なぜこんなに多くの拡張機能があるのか「機能が多すぎてよくわからない」状態になっている人も少なくないとおもいます。

Claude Codeの拡張機能が多いのには理由があります。開発ワークフローには様々な「タイミング」と「主体」が存在するからです。

たとえば、「コードをフォーマットする」という単純な作業を考えてみましょう。これには複数のアプローチがありますね。
ユーザーが明示的に「フォーマットして」と指示する方法
Claudeがコードを書いた後に自動的にフォーマットする方法
ファイルを保存するたびにシステムが自動実行する方法
どれも「フォーマットする」という結果は同じですが、トリガーのタイミングと主体が異なります。

Claude Codeの拡張機能は、この「誰が」「いつ」トリガーするかという観点で整理すると理解しやすくなります。少し整理してみましょう。
ユーザーが明示的にトリガーする機能

スラッシュコマンドがあります。/deployや/testのように、ユーザーが意図的に実行するものです。Claudeは呼び出されるまで何もしません。「今このタイミングで実行したい」というときに使います。
Claudeが自動的に判断してトリガーする機能

skillsとサブエージェントがあります。ユーザーが「このPRをレビューして」と言ったとき、Claudeは自分で「これはコードレビューのスキルを使うべきだ」と判断します。claude codeを使うユーザーはスキルの存在を知らなくても、その恩恵を受けられるのです。
システムが自動的にトリガーする機能

HooksとCLAUDE.mdがあります。Hooksはファイル保存やコマンド実行といったイベントに反応して自動実行されます。CLAUDE.mdはセッション開始時に自動的に読み込まれ、Claudeの行動指針となります。
この分類を頭に入れておくと、「この機能はどこに実装すべきか」という判断がしやすいかと思います。

 CLAUDE.md - Claudeの記憶を設計する
 CLAUDE.mdとは何か「CLAUDE.mdってプロジェクトの説明文を書くファイルでしょ？」と思っていませんか？実は、それだけではありません。CLAUDE.mdは、セッション開始時にClaudeが自動的に読み込む「記憶ファイル」です。Claudeの行動を制御する設定ファイルとして機能します。

たとえば、チームで「関数は50行以内」「エラーメッセージは日本語」というルールがあるとします。毎回Claudeに伝えるのは面倒ですし、忘れることもありますよね。CLAUDE.mdに書いておけば、Claudeはセッション開始時にそのルールを覚えてくれます。

 複数のCLAUDE.mdが存在する理由「CLAUDE.mdって1つじゃないの？」と思うかもしれません。実際の開発では、適用したいルールのスコープが異なります。プロジェクト固有のコーディング規約があり、個人的な好みもあります。Claude Codeはこれらを階層的に管理できるようになっています。
プロジェクトメモリ（.claude/CLAUDE.md）は、チーム全員で共有する設定です。Gitで管理されるため、プルリクエストでレビューできます。ここには「このプロジェクトで誰もが守るべきルール」を書きます。
# プロジェクトメモリの例（.claude/CLAUDE.md）
## 技術スタック
- フロントエンド: Next.js 14 (App Router)
- バックエンド: Hono on Cloudflare Workers
- DB: Cloudflare D1 (SQLite)

## コーディング規約
- コンポーネントは`src/components/`に配置。機能単位でサブディレクトリを作る
- API呼び出しは必ず`src/lib/api/`経由。直接fetchしない
- エラーメッセージは日本語で統一

## やってはいけないこと
- `any`型の使用禁止。
- `console.log`をコミットしない。デバッグには`src/lib/logger.ts`を使う
ローカルプロジェクトメモリ（CLAUDE.local.md）は、自分のマシンだけで有効な設定です。.gitignoreに自動追加されるため、チームには共有されません。プロジェクトメモリの内容を上書きしたいときに使います。
# ローカルプロジェクトメモリの例（CLAUDE.local.md）
## 自分の環境固有の設定
- 開発サーバーはポート3001で起動している（3000は別プロジェクトで使用中）
- ローカルDBは`~/.local/dev.db`に配置

## プロジェクトルールの例外
- 自分はVimキーバインドを使っているので、保存時の自動フォーマットは無効化している
- テスト実行時は`--watch`オプションをつけて実行してほしい
ユーザーメモリ（~/.claude/CLAUDE.md）は、すべてのプロジェクトで適用される個人設定です。どのプロジェクトでも一貫して適用したい自分の好みを書きます。
# ユーザーメモリの例（~/.claude/CLAUDE.md）
## 言語設定
- 説明やコメントは日本語で書いてほしい
- コミットメッセージはprefixを記載すること

## コーディングスタイル
- 新規ファイルはTypeScriptで作成。JavaScriptは使わない
- 関数コンポーネントを優先。クラスコンポーネントは使わない
- テストはVitestで書く

## 作業スタイル
- 変更を加える前に、まず現状のコードを読んで理解してから作業してほしい
- 大きな変更をする前に、方針を確認してほしい
優先順位について補足すると、同じ設定が複数の場所に書かれている場合、ローカルプロジェクトメモリ > プロジェクトメモリ > ユーザーメモリの順で適用されます。たとえば、ユーザーメモリで「TypeScriptを使う」と書いていても、プロジェクトメモリで「このプロジェクトはJavaScript」と書かれていれば、そちらが優先されます。
※エンタープライズメモリは省略してます

 効果的なCLAUDE.mdの書き方CLAUDE.mdを書くときに最も重要なのは、具体的で検証可能な指示を書くことです。
「きれいなコードを書いて」という指示は役に立ちません。何が「きれい」かはClaudeには判断できないからです。「インデントは2スペース」「関数は50行以内」「publicメソッドにはJSDocを書く」のように、Claudeが機械的に判断できる形で書く必要があります。
もう一つ重要なのは、チームの暗黙知を明文化することです。長く開発を続けていると、「このディレクトリにはこういうファイルを置く」「この関数はこういう理由でこう書く」といった暗黙のルールが蓄積されますよね。新しいメンバーがこれを学ぶには時間がかかりますが、CLAUDE.mdに書いておけばClaudeはすぐに理解します。
## プロジェクト構造
このプロジェクトはクリーンアーキテクチャを採用しています。依存関係は必ず内側から外側への一方向にしてください。

- `domain/` - ビジネスロジック。外部依存なし。
- `application/` - ユースケース。domainのみに依存。
- `infrastructure/` - 外部サービス連携。すべてに依存可能。
- `presentation/` - UI層。applicationのみに依存。

新しい機能を追加するときは、まずdomainにエンティティとリポジトリインターフェースを定義し、次にapplicationにユースケースを実装し、最後にinfrastructureでリポジトリを実装してください。

 @記法とファイル参照CLAUDE.mdが長くなりすぎると、読みにくくなりますし、Claudeのコンテキストウィンドウも圧迫します。@記法を使えば、関連ドキュメントを参照させることができます。
# API設計
詳細な仕様は @docs/api-spec.md を参照してください。

# デプロイ手順
@docs/deployment.md に従ってください。
Claudeは必要に応じてこれらのファイルを読み込みます。すべてをCLAUDE.mdに書く必要はありません。
ただし、コードブロック内の@は展開されません。`@package.json`と書いても、package.jsonの内容は読み込まれません。これは意図的な設計で、npmパッケージ名などを書くときに誤って展開されないようになっています。
https://code.claude.com/docs/en/memory
(@を記載しなくてもファイル名だけでよしなに参照してくれているので動きますが)

 SkillsとCustom Commands
 なぜ2つの仕組みがあるのか「SkillsとCustom Commandsって何が違うの？どっちもClaudeに特定の作業をさせるものじゃないの？」という疑問は多いです。確かに、どちらも「Claudeに特定の作業をさせる」ための仕組みです。しかし、設計思想が異なります。
Custom Commands

ユーザーが/command-nameで明示的に呼び出します。

「デプロイして」「テストを実行して」のように、ユーザーが意図的に実行するアクションに向いています。
Skills

Claudeが自動的に検出して適用します。

ユーザーが「このPRをレビューして」と言ったとき、Claudeは「これはコードレビューのスキルを使うべきだ」と自分で判断します。ユーザーはスキルの存在を知らなくても、その恩恵を受けられます。
この違いは些細に見えますが、実際には大きな意味を持ちます。Custom Commandsは「ユーザーがその存在を知っている」ことが前提です。一方、Skillsは「ユーザーが知らなくても適用される」ため、チーム全体の品質を底上げする仕組みとして機能します。

 Skillsの自動検出メカニズム「Claudeはどうやってスキルを自動検出しているの？」と気になりませんか？このメカニズムを理解すると、効果的なスキルを作れるようになります。

Claude Codeの起動時、すべてのスキルのnameとdescriptionだけがメモリに読み込まれます。スキル本体（SKILL.mdの内容）はまだ読み込まれません。これは起動速度を保つためです。
ユーザーが何かを入力すると、Claudeはその内容と各スキルのdescriptionを比較します。マッチするスキルが見つかると、そのSKILL.mdの完全な内容が読み込まれ、実行されます。

つまり、descriptionの書き方がスキルの発見可能性を決定します。
# これでは検出されにくい
description: ドキュメント関連の作業を支援

# これなら検出されやすい
description: PDFファイルからテキストや表を抽出する。フォームへの入力、
             ドキュメントの結合も可能。ユーザーがPDF、フォーム、
             文書抽出について言及したときに使用。
後者の例では、ユーザーが言いそうな言葉（PDF、フォーム、抽出）を明示的に含めています。これにより、Claudeは「ユーザーがPDFについて話している」→「このスキルを使うべきだ」と判断できます。

かなり面倒くさいように見えますが、「XXXのスキルを作成して」と指示して、そこからカスタマイズをしていく方法で簡単に作成できるかと思います。

 context: forkの意味と使いどころcontext: forkは、スキルを独立したサブエージェントとして実行するオプションです。

通常、スキルはメイン会話のコンテキスト内で実行されます。スキルが大量のファイルを読み込んだり、長い出力を生成したりすると、メイン会話のコンテキストウィンドウを圧迫します。

context: forkを設定すると、スキルは独立したコンテキストで実行されます。どれだけファイルを読み込んでも、メイン会話には影響しません。結果だけが要約されてメイン会話に返されます。

これは、コードベース全体を分析するスキルや、大量のログを処理するスキルで特に有用です。

 Custom Commandsの使いどころCustom Commandsは、Skillsよりもシンプルです。単一の.mdファイルで定義し、ユーザーが明示的に呼び出します。典型的な使用例は、頻繁に実行する定型作業です。

/deploy stagingでステージング環境にデプロイする、

/review ステージされている変更をレビューする、

/test unitでユニットテストを実行する、といった具合です。
---
allowed-tools: Bash(git:*)
---

## 現在の状態
- ブランチ: !`git branch --show-current`
- 未コミット変更: !`git status --short`
- 最近のコミット: !`git log --oneline -5`

## 実行内容
上記の状態を確認し、適切なコミットメッセージを生成してください。
このコマンドを実行すると、Claudeは現在のGitの状態を把握した上でコミットメッセージを提案できます。

 SkillsとCustom Commandsの選択基準いくつかの観点から整理してみます。

 観点1：誰がトリガーするかClaudeに自動判断させたい → Skills。

たとえば、チームでReactコンポーネントの書き方に独自ルールがあるとします。これをSkillsとして定義しておけば、ユーザーが「ボタンコンポーネントを作って」と言うだけで、Claudeは自動的にそのルールを適用します。
ユーザーが意図的に実行したい → Custom Commands。

「テストを実行して」「ドキュメントを生成して」といった操作は、/testや/generate-docsと明示的に呼び出すほうが自然です。

 観点2：コンテキストが必要かどうか現在の作業状態を知る必要がある → Custom Commands。

コミットメッセージの生成には「今ステージングされているファイル」を知る必要があります。!記法を使えば、コマンド実行時にその情報を取得できます。
# .claude/commands/commit.md
現在のGitの状態を確認:
!git status --short
!git diff --cached --stat

上記を踏まえて適切なコミットメッセージを提案してください。
Skillsでは!記法が使えません。

 ケース別判断API呼び出しのモック生成（MSWなど、チーム独自ルールあり）

→ Skills。「モックを作って」と言えば自動的にルールが適用される。
依存関係の更新チェック（npm outdatedの実行と分析）

→ Custom Commands。!npm outdatedで現在の状態を取得して分析。
Storybookストーリー作成

→ どちらも可。「作ったら必ずストーリーも」ならSkills、「必要なときだけ」ならCustom Commands。
レガシーコードのリファクタリング（手順がドキュメント化されている）

→ Skills。リファクタリング依頼時に自動で手順を参照。

 サブエージェント - コンテキスト管理
 サブエージェントが解決する問題サブエージェントはメイン会話とは独立したコンテキストで動作するため、どれだけファイルを読み込んでも、メイン会話のコンテキストを消費しません。

たとえば、「このコードベースで認証がどのように実装されているか調べて」とClaudeに頼んだとします。Claudeは何十ものファイルを読み、それぞれの関係を分析する必要があります。これをメイン会話で行うと、すぐにコンテキストウィンドウが埋まってしまいます。
サブエージェント（この場合はExploreエージェント）を使えば、探索作業は独立したコンテキストで行われます。メイン会話には「認証はJWTを使用しており、主要な実装はsrc/auth/にあります」といった要約だけが返されます。そのためコンテキストが圧迫されてしまうことを防ぎます。

 ビルトインサブエージェントの特性Claude Codeには、目的別に最適化されたビルトインサブエージェントがあります。それぞれの特徴を理解しておくと、適切な場面で活用できます。
Exploreエージェントは、コードベースの探索に特化しています。ファイルの読み込みと検索だけができ、編集はできません。「認証の実装を探して」「エラーハンドリングのパターンを分析して」といったタスクに最適です。
Planエージェントは、実装計画の策定に特化しています。コードを読むことはできますが、編集はできません。「この機能をどう実装すべきか」という質問に、コードベースを分析した上で回答します。

 カスタムサブエージェントの作成カスタムエージェントも作成できます。

たとえば、セキュリティレビューに特化したエージェントを作るとします。このエージェントは、コードを読んでセキュリティ上の問題を指摘しますが、コードを修正する権限は持ちません。誤って脆弱性のあるコードを書いてしまうリスクを避けるためです。
# .claude/agents/security-reviewer.md
---
name: security-reviewer
description: セキュリティ脆弱性のレビュー。コードを読んで問題を指摘するが、
             修正は行わない。PRレビューやセキュリティ監査で使用。
model: sonnet
tools:
  - Read
  - Grep
  - Glob
disallowedTools:
  - Write
  - Edit
  - Bash
permissionMode: dontAsk
---

# セキュリティレビュー手順
あなたはセキュリティ専門家として、コードをレビューします。
以下の観点でチェックし、発見した問題を重要度順にリストアップしてください。

## チェック項目
### 入力検証
ユーザー入力が適切に検証されているか確認します。SQLインジェクション、
コマンドインジェクション、パストラバーサルの可能性がないか調べてください。

### 認証・認可
認証のバイパスが可能な箇所がないか確認します。また、認可チェックが
適切に行われているか、権限昇格の可能性がないか調べてください。

### データ保護
機密情報（パスワード、APIキー、個人情報）が適切に保護されているか
確認します。ログへの出力、エラーメッセージへの含有に注意してください。
このエージェントは、descriptionに「PRレビュー」「セキュリティ監査」と書いてあるため、ユーザーがこれらの言葉を使うと自動的に起動します。

 Hooks - イベント駆動の自動化
 Hooksとは何か「ファイルを保存したら自動的にフォーマットしたい」「危険なコマンドを実行しようとしたらブロックしたい」...こういった自動化を実現するのがHooksです。

Hooksは、特定のイベントが発生したときに自動実行されるシェルコマンドです。SkillsやCustom Commandsとの違いは、トリガーのタイミングです。Skillsはユーザーの発言内容に反応し、Custom Commandsはユーザーの明示的な呼び出しに反応します。Hooksは、ツールの実行やセッションの開始といったシステムイベントに反応します。

 Hookイベントの種類Claude Codeは様々なイベントを提供しています。主要なものを見ていきましょう。
PreToolUseは、ツールが実行される直前に発火します。「このコマンドを実行していいか」を判断するのに使います。たとえば、rm -rfのような危険なコマンドをブロックしたり、特定のファイルへのアクセスを禁止したりできます。
PostToolUseは、ツールが実行された直後に発火します。「実行結果に対して何かする」のに使います。ファイルを保存した後に自動フォーマットを実行したり、コマンドの実行ログを記録したりできます。
UserPromptSubmitは、ユーザーがプロンプトを送信したときに発火します。入力内容を検証したり、追加のコンテキストを注入したりできます。
SessionStartは、セッションが開始されたときに発火します。環境変数の設定や、必要なサービスの起動に使います。
Stopは、Claudeが応答を完了したときに発火します。クリーンアップ処理や、結果の通知に使います。

 Hookの入力と出力Hookはstdin経由でJSON形式のデータを受け取ります。どのイベントでも、セッションID、現在の作業ディレクトリ、権限モードなどの共通情報が含まれます。

PreToolUseとPostToolUseでは、実行されるツールの名前と入力パラメータが含まれます。たとえば、Bashツールの場合は実行されるコマンドが、Writeツールの場合はファイルパスと内容が含まれます。
{
  "session_id": "abc123",
  "hook_event_name": "PreToolUse",
  "tool_name": "Bash",
  "tool_input": {
    "command": "npm run build",
    "description": "Build the project"
  }
}
Hookの終了コードは、その後の処理を制御します。終了コード0は成功を意味し、処理が続行されます。終了コード1は非ブロッキングエラーで、標準エラー出力が表示されますが処理は続行されます。終了コード2はブロッキングエラーで、処理がブロックされます。これは、危険な操作を防ぐために重要です。

 実践例：ファイル保護特定のファイルへの書き込みを禁止するHookを作ってみましょう。.envファイルやpackage-lock.jsonなど、Claudeに編集させたくないファイルがありますよね。
#!/usr/bin/env python3
import json
import sys

# 保護するファイルパターン
PROTECTED_PATTERNS = [
    '.env',
    'package-lock.json',
    'yarn.lock',
    'secrets/',
    '.git/',
]

try:
    data = json.load(sys.stdin)
except json.JSONDecodeError:
    # JSONのパースに失敗したら、何もせず続行
    sys.exit(0)

# ファイルパスを取得
file_path = data.get('tool_input', {}).get('file_path', '')

# 保護パターンに一致するかチェック
for pattern in PROTECTED_PATTERNS:
    if pattern in file_path:
        # 標準エラー出力にメッセージを書き、終了コード2でブロック
        print(f"このファイルは保護されています: {file_path}", file=sys.stderr)
        print("編集が必要な場合は、手動で行ってください。", file=sys.stderr)
        sys.exit(2)

# 問題なければ続行
sys.exit(0)
このスクリプトを.claude/hooks/file-protection.pyに保存し、settings.jsonで設定します。
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR\"/.claude/hooks/file-protection.py"
          }
        ]
      }
    ]
  }
}
matcherは正規表現で、どのツールに対してHookを実行するかを指定します。この例では、WriteまたはEditツールに対してのみHookが実行されます。

 MCP Servers - 外部サービスとの連携
 MCPとは何か「ClaudeからGitHubのPRを操作したい」「Sentryのエラーを確認したい」「Notionにメモを書きたい」...こういった外部サービスとの連携を実現するのがMCP（Model Context Protocol）です。
MCPがない場合、外部サービスと連携するには、APIキーを設定し、curlコマンドを書き、レスポンスをパースする必要があります。MCPを使えば、これらの複雑さが抽象化され、Claudeは「GitHubのPR一覧を取得して」「Sentryの最近のエラーを見せて」と自然に操作できます。

 MCPサーバーのスコープMCPサーバーの設定は、3つのスコープで管理できます。
userスコープは、すべてのプロジェクトで使用されます。個人の開発環境でよく使うサービス（GitHub、個人のデータベースなど）に適しています。設定は~/.claude.jsonに保存されます。
projectスコープは、特定のプロジェクトで使用され、Gitで共有されます。チーム全員が使うサービス（プロジェクト専用のデータベース、監視サービスなど）に適しています。設定は.mcp.jsonに保存されます。
localスコープは、特定のプロジェクトで使用されますが、共有されません。個人的なテスト環境への接続などに適しています。
# userスコープで追加（すべてのプロジェクトで使用）
claude mcp add --scope user github --transport http

# projectスコープで追加（チームで共有）
claude mcp add --scope project --transport stdio db -- npx -y @bytebase/dbhub --dsn "..."
どのスコープにMCPが置かれているかは /mcp で確認可能です。

 組織でのMCP管理組織でClaude Codeを使う場合、許可するMCPサーバーを制限したいことがあります。managed-mcp.jsonを使えば、IT部門がMCPサーバーの許可リストと拒否リストを設定できます。
{
  "allowedMcpServers": [
    {"serverName": "github"},
    {"serverUrl": "https://mcp.company.com/*"}
  ],
  "deniedMcpServers": [
    {"serverName": "dangerous-server"}
  ]
}
この設定により、承認されたMCPサーバーのみが使用可能になります。

 コンテキストウィンドウ消費を意識した設計SkillsやCustom Commandsを使い慣れてくると、「あれもこれもClaudeに自動化させよう」と考えるようになります。

たとえば、コミット時に以下のことをすべて自動化したいとします。
変更内容を分析してコミットメッセージを生成
Asanaのタスクを完了状態に更新
Notionのドキュメントを更新
Slackで非エンジニアに完了報告を送信
仕様書のバージョンを更新
これらをひとつのコマンドにまとめると、確かに便利です。でも、問題があります。

Claudeは各ステップで「何をすべきか」を考え、外部サービスとやり取りし、その結果を解釈する必要があります。この過程で、大量のコンテキストウィンドウを消費します。ファイルの読み込み、APIレスポンスの解析、次のアクションの判断...すべてがコンテキストに蓄積されていきます。

先ほどの例にあるようなスキルを作成してコミットさせたところ、一瞬でlimitに達してしまいました。

 コンテキスト消費が大きくなるパターンどういった操作がコンテキストを大量に消費するのか、把握しておくと対策しやすくなります。
複数の外部サービスとのやり取りは、特にコンテキストを消費します。MCPサーバー経由でAsana、Notion、GitHub、Slackなどと通信すると、それぞれのAPIレスポンスがコンテキストに蓄積されます。

大量のファイル読み込みも注意が必要です。「関連するファイルをすべて読んで」という指示は、数十ファイルを読み込む可能性があります。

反復的な処理も問題になります。「すべてのテストファイルをチェックして」という指示で100個のファイルを順番に処理すると、その都度コンテキストが増えていきます。

長い出力を生成する処理も同様です。詳細なレポートや長いドキュメントを生成すると、その分コンテキストを消費します。

 コンテキスト消費を抑える設計パターンでは、どうすれば効率的にコマンドを設計できるでしょうか。いくつかのパターンを紹介します。
パターン1：責務を分割する
ひとつの大きなコマンドを、複数の小さなコマンドに分割します。
# ❌ すべてを1つのコマンドで実行
/release-complete
# コミット、Asana更新、Notion更新、Slack通知、仕様書更新をすべて実行

# ✅ 責務ごとに分割
/commit          # コードをコミット
/task-done       # Asanaのタスクを完了
/update-docs     # Notionを更新
/notify-release  # Slackに通知
分割することで、各コマンドのコンテキスト消費を抑えられます。また、必要なコマンドだけを実行できるようになります。何でもできる汎用スキルを動かすのは楽ですが、それほどまでに複数mcp呼び出してやりたいことがあるのであればそれは業務のやり方を見直した方が良さそうです🙏
パターン2：サブエージェントを活用する

前述のように、サブエージェント（context: fork）は独立したコンテキストで動作します。コンテキストを大量に消費する処理は、サブエージェントに委譲しましょう。
# スキルの設定
---
name: analyze-codebase
description: コードベース全体を分析する
context: fork  # 独立したコンテキストで実行
---
サブエージェントが何十ファイルを読み込んでも、メイン会話のコンテキストは消費されません。
パターン3：必要最小限の情報に絞る

外部サービスから情報を取得するとき、必要な情報だけを取得するようにします。
# ❌ すべての情報を取得
Asanaのタスク詳細をすべて取得して、その内容を確認してください。

# ✅ 必要な情報だけを取得
Asanaのタスクのステータスと期限だけを確認してください。
パターン4：バッチ処理よりも対話的な処理

大量の処理を一度に実行するよりも、対話的に進める方がコンテキストを管理しやすくなります。
# ❌ すべてを一度に処理
プロジェクト内のすべてのTODOコメントを見つけて、それぞれについてIssueを作成してください。

# ✅ 対話的に処理
プロジェクト内のTODOコメントを5件見つけてください。
（確認後）最初の2件についてIssueを作成してください。

 まとめClaude Codeの拡張機能は、一見複雑に見えますが、「誰が」「いつ」トリガーするかという観点で整理すると理解しやすくなります。
ユーザーが明示的にトリガーするものはCustom Commandsです。/deployや/testのように、意図的に実行するアクションに使います。
Claudeが自動的に判断してトリガーするものはSkillsとサブエージェントです。ユーザーの発言内容から適切な処理を選び、必要に応じて専門エージェントに委譲します。
システムが自動的にトリガーするものはHooksとCLAUDE.mdです。イベントの発生やセッションの開始に反応して、自動的に処理を実行します。
これらを適切に組み合わせることで、チームの規約を自動的に適用し、危険な操作を防ぎ、定型作業を自動化できます。最初は複雑に感じるかもしれませんが、各機能の設計思想を理解すれば、適切な使い分けができるようになります。
まずはCLAUDE.mdから始めてみてください。プロジェクトの概要とコーディング規約を書くだけで、Claudeの出力品質が大きく向上します。その後、必要に応じてSkillsやHooksを追加していけば、徐々に強力な開発環境が構築できます。
そして、コンテキストウィンドウの制約も忘れずに。複雑なコマンドを作りすぎると、セッションが早々に終わってしまいます。「1コマンド1責務」を意識して、効率的なワークフローを設計しくのが良いと思います。
!最後まで読みましたね？

いいねとフォローお待ちしております♡
はじめに

Claude Codeの考え方を理解する

なぜこんなに多くの拡張機能があるのか

CLAUDE.md - Claudeの記憶を設計する

CLAUDE.mdとは何か

複数のCLAUDE.mdが存在する理由

効果的なCLAUDE.mdの書き方

@記法とファイル参照

SkillsとCustom Commands

なぜ2つの仕組みがあるのか

Skillsの自動検出メカニズム

context: forkの意味と使いどころ

Custom Commandsの使いどころ

SkillsとCustom Commandsの選択基準

観点1：誰がトリガーするか

観点2：コンテキストが必要かどうか

ケース別判断

サブエージェント - コンテキスト管理

サブエージェントが解決する問題

ビルトインサブエージェントの特性

カスタムサブエージェントの作成

Hooks - イベント駆動の自動化

Hooksとは何か

Hookイベントの種類

Hookの入力と出力

実践例：ファイル保護

MCP Servers - 外部サービスとの連携

MCPとは何か

MCPサーバーのスコープ

組織でのMCP管理

コンテキストウィンドウ消費を意識した設計

コンテキスト消費が大きくなるパターン

コンテキスト消費を抑える設計パターン

まとめ

Discussion
