Claude Codeの使い方完全ガイド：CLAUDE.md・Skills・Subagents・Hooksを基礎から解説

初心者がClaude Codeを使い始めると、いきなり見慣れない用語が大量に押し寄せてくる。

「CLAUDE.md」「SPEC.md」「Skills」「Subagents」「Hooks」「MCP」「Plugins」……。

公式ドキュメントを読んでも、どれが設定ファイルで、どれが拡張機能で、どれが自動化の仕組みなのか、最初は区別がつきにくい。

筆者も同じ壁にぶつかった。
しかし、4つの基本概念さえ押さえれば、Claude Codeの全体像は一気にクリアになる。

この記事を読むと、次のことが分かる。

何から手を付けるべきか：まずCLAUDE.mdを1つ作るだけで、Claudeの挙動が安定する
4つの概念の使い分け：ルール（常駐）、スキル（必要時）、分業（サブエージェント）、強制（フック）の違い
便利なビルトイン機能：Claudeが自動で質問してくれる仕組み、ToDoリストの活用法
拡張の入口：MCPやPluginsは「必要になってから」で十分。ただし何ができるかは知っておく

記事の構成は、「まず日常で使う基本機能」→「慣れたら触る拡張機能」という順番になっている。

最初から全部を覚える必要はない。上から順に使ってみるうちに、全体像が掴めるように配慮して整理した。

冒頭の用語テーブルとプロジェクト構成図だけでも、見通しがクリアになるはずだ。

ざっくり全体像：用語の整理（ここだけ読んでもOK）

まず覚える（必須）

用語	役割	実用例
`CLAUDE.md`	いつも効く「ルール／前提」	実行コマンド、禁止事項、Doneの定義を書く
Skills	必要なときだけ読み込む「手順書」	PRレビュー観点、コミット文面の規約を定義する
Subagents	分業する「専門家」	探索（読む）と実装（書く）を分離する
Hooks	必ず動く「自動化／ガード」	フォーマット自動化、危険コマンドのブロック

必要になったら触る（拡張）

用語	役割	実用例
Plugins / Marketplace	便利機能をワンクリックで追加	`commit-commands`でコミットをワンコマンド化
MCP	外部ツール連携の仕組み	Jira/Slack/DBから情報を読み、実装に繋げる
LSP	「定義ジャンプ」などのコード知能	型エラーや参照をClaudeが拾いやすくする

典型的なプロジェクト構成

Claude Codeと一緒に開発するとき、プロジェクトのディレクトリ構造としては、次のようなフォルダ・ファイルを配置することになる。

my-project/
├── CLAUDE.md                # ← プロジェクトのルール（チーム共有）
├── CLAUDE.local.md          # ← 個人用の上書き（.gitignore推奨）
├── .claude/
│   ├── settings.json        # ← Hooks等の設定
│   ├── skills/
│   │   └── commit-message/
│   │       └── SKILL.md     # ← スキル定義
│   └── agents/
│       └── safe-researcher.yml  # ← カスタムサブエージェント
├── docs/                    # ← 補助ドキュメント（任意）
│   ├── SPEC.md              #    機能仕様、設計判断の記録
│   └── ARCHITECTURE.md      #    構造の概要、重要な設計方針
├── src/
│   └── ...                  # ← 既存のソースコード
└── ...

すべてを最初から用意する必要はない。

まずは後に詳しく解説するCLAUDE.mdだけ作り、必要に応じて.claude/配下を育てていく流れが自然だ。

Claude Codeの超基本：まず起動して触ってみる

各概念の解説の前に、「本当にClaude Codeを初めて使う」という人のために、「とにかく一度Claude Codeを動かしてみる」方法も説明しておく。

細かい設定や概念は後回しにして、まずは会話しながらコードを読み書きする感覚を掴んでほしい。

Claude Codeをインストールする

Node.js（v18以上）がインストールされていれば、以下のコマンド1つでインストールできる。

npm install -g @anthropic-ai/claude-code

インストールが完了したら、次のステップに進もう。

Claude Codeを起動して質問する

ターミナルでプロジェクトのフォルダに移動する
claudeと入力して起動する
初回はログインを求められるのでログインする（Pro/Maxプランの月額課金、またはAPIキーでの従量課金）

起動したら、さっそく質問してみよう。

このプロジェクトの構造を教えて

Claudeがフォルダやファイルを探索し、全体像を説明してくれる。

ここまでで「Claudeがプロジェクトを読んで理解している」感覚が掴めるはずだ。

小さな変更を頼んでみる

次に、小さな変更を頼んでみよう。

READMEにこのプロジェクトの概要を1行追記して

Claude Codeは変更を提案し、実行前に許可を求めてくる。
内容を確認して「Yes」で承認すると、ファイルが編集される。

この「許可を求めてから実行する」挙動が、Claude Codeの安全装置だ。

いきなりプロジェクトのコードが壊れることはないので、気軽に試してみてほしい。

最初に理解したい4つの概念（ルール／スキル／分業／フック）

Claude Codeの基本挙動を理解したら、作業中のプロジェクト特有の背景やルールを理解させるなど、簡単なカスタマイズを行なっておくと良い。

Claude Codeの挙動をコントロールする方法は、大きく4つ存在する。それぞれ役割が異なるので、適切に使い分けたい。

ざっくり言うと、CLAUDE.mdは常駐、Skillsは必要時、Subagentsは分業、Hooksは強制である。

以下、重要な順に、一つ一つ具体例とともに解説していく。

1) `CLAUDE.md`：毎回効く「ルール」とプロジェクト説明書

なぜCLAUDE.mdが必要か

ChatGPTやClaude、GeminiなどのチャットUIでコードを相談するとき、こんな経験はないだろうか。

毎回「このプロジェクトはTypeScriptで…」と前提を説明し直す
「テストはnpm testで」と何度も伝える
前に教えたはずのルールを忘れて、また同じミスをする

Claude Codeでは、この問題をCLAUDE.mdというファイルで解決する。

CLAUDE.mdに書いた内容は、セッションを開始するたびに自動で読み込まれる。つまり「このプロジェクトではこうしてね」という前提知識が、毎回リセットされずに引き継がれる。

これがClaude Codeの最大のアドバンテージの一つだ。

自動で読まれるからこそ「短く強く」

ただし、自動で読まれるということは、常にコンテキスト（Claudeの記憶領域）を消費するということでもある。

CLAUDE.mdを長くしすぎると、肝心の作業に使える余裕が減ってしまう。

そこで守りたい原則は、「短く、強く、常に必要なことだけ」だ。

筆者が./CLAUDE.mdに最低限入れるのは、次の4カテゴリである。

プロジェクト概要（何のリポジトリか、重要な前提）
実行・テスト・フォーマット（Claudeが迷う一番の原因）
制約（壊してはいけない仕様、互換性、方針）
できれば避けたいこと（触ってはいけないフォルダ、秘密情報）

逆に、毎回は使わない長い手順書や、特定タスク専用のチェックリストは、Skills（後述）に逃がした方がよい。

スコープを分けて運用する

Claude Codeは、スコープの違う複数のCLAUDE.mdを使い分けられる。
プロジェクトが大きくなったら、次の3つを分けておくと混乱しにくい。

スコープ	パス例	使い分け
Project	`./CLAUDE.md`	リポジトリ固有の文脈（チーム共有）
Project Local	`./CLAUDE.local.md`	個人だけの上書き（ローカル事情）
Global User	`~/.claude/CLAUDE.md`	全プロジェクト共通の安全ルールや作法

ポイントは「チームで共有すべき情報」と「個人だけで良い情報」を混ぜないことだ。

./CLAUDE.mdはリポジトリに入れてチームで育て、~/.claude/CLAUDE.mdと./CLAUDE.local.mdは個人の事情として切り離すと運用が楽になる。

ただし、最初からすべてを用意する必要はない。
まずは./CLAUDE.mdを1つ作るだけでよい。

ここが空のままだと、Claudeが善意で勝手に推測して迷走しやすい。

活用例：`CLAUDE.md`で「迷わない実行手順」を固定する

たとえば、プロジェクト直下に次のようなCLAUDE.mdを置く。

要点は「実行・テスト・フォーマット・禁止事項」を短く書き、迷ったときの判断基準を渡すことだ。

## Project
- このリポジトリは何をするものか（1〜2文）

## How to run
- 開発: `npm run dev`
- テスト: `npm test`

## Definition of Done
- テストが通る
- 既存の挙動を壊さない
- 変更理由をPR説明に書く

## Never do
- 秘密情報（APIキー、トークン、`.env`）を出力・コミットしない

補足
セキュリティの前提：.envや認証情報はプロジェクト内に置かれがちで、Claude Codeはファイルを読みながら作業する。そのため「秘密情報は出力しない／コミットしない」をルール化しておくと、事故が減る。

CLAUDE.mdだけでは足りなくなったら

プロジェクトが大きくなると、CLAUDE.mdに全部詰め込むのは無理が出てくる。
そこで役割を分けたドキュメントを作るのがおすすめだ。

ファイル	置く内容	いつ参照される
`CLAUDE.md`	常に守るルール、コマンド、禁止事項	毎回（自動で読まれる）
`docs/SPEC.md`	機能の要件、仕様、ユースケース	実装前の計画時に読ませる
`docs/ARCHITECTURE.md`	構造の概要、レイヤー設計、依存関係	大きな変更や新機能追加時

SPEC.mdやARCHITECTURE.mdは、Claude.mdとは異なり、毎回自動で読み込まれることはない。

必要な場面で「docs/SPEC.mdを読んで」と明示的に指示するか、スキルの中で@docs/SPEC.mdとして参照する。

特に、新たな開発プロジェクトを始める際には、毎回SPEC.mdを作るのがおすすめだ。

Claudeとのチャットのやり取りだけで仕様を決めるより、明文化・ファイル化しておくことで、Codex・ChatGPT・Geminiなどの他のAIにも同時に相談することができ、プランニング段階の質が上がる。

後述する「Planモードでのスペック駆動開発」と組み合わせると、設計→実装の流れがスムーズになる。

2) Skills：必要なときだけ読み込む「作業手順書」

CLAUDE.mdとの違い

前のセクションで「CLAUDE.mdは常にコンテキストに入る」と説明した。
では、たまにしか使わない長い手順書はどうすればいいか？

例えばPRレビューの観点リストや、リリース作業のチェックリストは、毎回必要なわけではない。
これをCLAUDE.mdに全部書くと、普段の作業で無駄にコンテキストを消費してしまう。

そこでSkillsの出番だ。

Skillsは「必要なときだけ読み込まれる」設計になっている。
セッション開始時にはスキル名と説明文だけを見て「このスキルが必要か？」を判断し、必要になって初めて本文を読み込む。

つまり、スキルをいくら増やしても、最初からコンテキストが膨れない。

	CLAUDE.md	Skills
読み込みタイミング	常に（セッション開始時）	必要時のみ
向いている内容	毎回守るルール、禁止事項	特定タスクの手順書
コンテキスト消費	常に消費する	使うときだけ

補足
Skillsは業界標準になりつつある：Skillsの仕組みは、Anthropicがオープン標準として公開したことで注目を集めている。OpenAI（Codex CLI）、Cursor、GitHub Copilotなど、主要なコーディングエージェントが次々と採用し始めた。「MarkdownとYAMLだけで能力を拡張できる」というシンプルさが評価されており、MCPよりも導入障壁が低いと言われている。

サンプル：Conventional Commitsをスキル化する

具体例を見た方が早い。「Conventional Commits」という仕様をスキル化してみよう。

Conventional Commitsは、コミットメッセージにfeat:（新機能）やfix:（バグ修正）などの接頭辞を付けるルールだ。
変更の種類が一目で分かり、CHANGELOGの自動生成やセマンティックバージョニングとの連携にも使える。
仕様はconventionalcommits.orgで公開されている。

この仕様をスキル化すると、チーム全員が同じフォーマットでコミットできるようになる。

例えば、以下のようなSKILL.mdファイルを作成する。

---
name: conventional-commit
description: Generate commit messages following Conventional Commits specification. Use when the user asks to commit, write commit messages, or summarize staged changes.
---

Conventional Commits仕様に従ってコミットメッセージを生成する。

## フォーマット
<type>(<scope>): <description>

## typeの種類
- feat: 新機能
- fix: バグ修正
- docs: ドキュメントのみの変更
- refactor: リファクタリング（機能追加でもバグ修正でもない）
- test: テストの追加・修正
- chore: ビルドプロセスや補助ツールの変更

## ルール
- descriptionは日本語で、50文字以内を目安にする
- 本文が必要な場合は、「なぜ」を中心に書く

（※実運用するなら、もう少しMarkdown部分に詳細な仕様を書き込んだ方が良い。）

以降、「スキルを使ってコミットして」と頼むだけで、この仕様に従ったコミットメッセージが作成される。

SKILL.mdの構造

上の例を見ると、SKILL.mdの構造はびっくりするほどシンプルだ。

YAMLフロントマター：nameとdescriptionが必須
Markdown本文：自由にテキストで仕様を書き込む

ポイントはdescription（説明文）である。
Claudeは説明文を見て「このスキルを使うべきか」を判断するため、曖昧だと発火しない。
「いつ使うか」をはっきり書くのがコツだ。

スキルの作り方と置き場所

作り方自体はシンプルだ。

.claude/skills/<skill-name>/フォルダを作る
その中にSKILL.mdを置く
Claude Codeに「利用可能なスキルを教えて」と聞いて読み込みを確認する

置き場所は2種類ある。

種類	パス	使える範囲	用途
プロジェクトスキル	`.claude/skills/<skill-name>/SKILL.md`	そのプロジェクトのみ	チームで共有するルールを定義
個人スキル	`~/.claude/skills/<skill-name>/SKILL.md`	全プロジェクト共通	自分だけの作業スタイルを定義

プロジェクトスキルはリポジトリ内の.claude/skills/に置く。
gitにコミットすれば、チームメンバー全員が同じスキルを使える。

個人スキルはホームディレクトリ配下に置く。
一度作れば、どのプロジェクトでも呼び出せる。

ヒント
ルールとスキルの切り分け：たまにしか使わない指示はスキルに逃がすと、CLAUDE.mdが肥大化しにくい。逆に「毎回守ってほしい前提」はCLAUDE.mdに置いた方がブレが減る。

ヒント
スキルは「本文を分割」できる：スキルはSKILL.mdだけで完結させる必要はない。詳細なリファレンス（例：社内API一覧）を別ファイルに切り出し、SKILL.mdからリンクしておくと、必要なときだけ読ませやすい。

ヒント
スキルは「スクリプト」も同梱できる：スキルフォルダ内にスクリプトを置いておけば、Claudeに実行させて結果だけを受け取る、という使い方もできる。長い説明が必要な検証処理ほど、スクリプトに逃がすと運用が安定する。

他にどんなスキルが作れるか

スキルの可能性は広い。チームや個人で作れる例をいくつか挙げる。

PRレビュー観点：セキュリティ、パフォーマンス、命名規則のチェック項目
リリースノート生成：コミット履歴から変更点をまとめるフォーマット
社内API連携：APIエンドポイントの一覧と使い方（別ファイルにリファレンスを分離）
データ分析ワークフロー：CSVの読み込み→集計→グラフ出力の手順
ドキュメント作成：PDF、Excel、PowerPointの生成ルール（公式スキルとして提供済み）

スキルは「Markdownで書ける能力拡張」だ。
コードを書かなくても、手順書を整備するだけでClaudeの精度が上がる。

3) Subagents：タスクを分業して、コンテキストを汚さない

なぜ「別のワーカー」が必要か

Claude Codeと長く会話していると、コンテキスト（Claudeの記憶領域）がだんだん埋まってくる。
特に探索作業（ファイルを開いては閉じ、検索を繰り返す）は、試行錯誤のログがどんどん溜まる。

すると困るのが「肝心の実装段階でコンテキストが足りない」という事態だ。
調査で集めた情報が多すぎて、本題の作業に使える余裕がなくなる。

Subagentsは、この問題を「別のワーカーに任せる」ことで解決する。

サブエージェントは独自のコンテキストを持ち、結果だけをメインの会話に返す。
調査の試行錯誤はサブエージェント側で完結するため、メインの会話がきれいなままで済む。

もう一つのメリットは「暴走の防止」だ。
サブエージェントには使えるツールを制限できるので、「調べるだけで編集はしない」という役割分担が作れる。

組み込みサブエージェント

Claude Codeには、最初から使える組み込みサブエージェントがある。

名前	役割	使いどころ
Explore	読み取り専用で高速探索	関係ファイルの洗い出し
Plan	調査してプランを提示	実装前の設計検討
General-purpose	探索と修正の両方	複雑で長いタスク

自動委譲と明示的な指示

多くの場合、Claudeはタスクの内容から自動的にサブエージェントを選んで委譲する。
例えば「このコードベースを調べて」と頼めば、Claudeは自動でExploreを使う。

ただし、明示的にサブエージェントを指定することもできる。

Exploreエージェントを使って、認証まわりのファイルを調べて

これをバックグラウンドで並列に調査して

自動委譲でうまくいくことが多いが、「確実にExploreを使いたい」「並列で調べてほしい」といった場合は明示的に指示すると意図通りに動きやすい。

活用例：「探索→実装」の2ステップで事故を減らす

サブエージェントを意識した典型的なワークフローは次の通りだ。

ステップ1：Exploreで調査

> ログイン失敗時のエラーハンドリングを調べて。関係するファイルをリストアップして。

Claudeは読み取り専用のExploreサブエージェントを使い、ファイルを開いては閉じ、構造を把握する。
この試行錯誤はサブエージェント側で完結し、メインの会話には「結果だけ」が返ってくる。

ステップ2：結果を受けて実装

> さっき調べた箇所に、ログ出力を追加して。

メインの会話はきれいなままなので、実装作業に十分なコンテキストが残っている。

このように「まず調べる→次に直す」を分けるだけで、長いセッションでも安定しやすくなる。

もう一歩：カスタムサブエージェントを作る（チーム共有もできる）

/agentsから「Create New subagent」を選ぶと、カスタムサブエージェントを作成できる。

公式ドキュメントでは、サブエージェントにはnameとdescriptionが必須で、必要に応じてツール制限やモデル選択もできる、と説明されている。

例えば「読み取り専用で安全に調査する係」を作るなら、イメージは次の通りだ。

---
name: safe-researcher
description: Read-only research agent. Use when you want to investigate files without making edits.
tools: Read, Grep, Glob, Bash
disallowedTools: Write, Edit
---

チームで共有するなら、プロジェクト内の.claude/agents/に置く運用が分かりやすい。

4) Hooks：LLMの気分に任せない「強制実行」の仕組み

Claudeは「お願い」を忘れることがある

CLAUDE.mdやSkillsに「フォーマットを揃えて」と書いても、Claudeが忘れることはある。
LLMの判断には揺らぎがあるため、100%守らせるのは難しい。

「お願い」ではなく「強制」したいルールには、Hooksを使う。

Hooksは、Claude Codeの特定のタイミングで必ず実行されるシェルコマンドだ。
例えば「ファイルを編集したら、必ずフォーマッタを走らせる」という処理を、Claudeの判断を介さずに自動化できる。

つまり、以下のような使い分けになる。

	CLAUDE.md / Skills	Hooks
実行される保証	Claudeの判断次第	必ず実行される
向いている内容	ガイドライン、手順	機械的な後処理、ブロック

よく使うフックイベント

Hooksは「いつ発火するか」をイベントで指定する。まず触るなら次の4つで十分だ。

イベント	タイミング	用途例
`PreToolUse`	ツール実行前	コマンドのログ記録、危険操作のブロック
`PostToolUse`	ツール実行後	フォーマッタ実行、lint修正
`PermissionRequest`	権限確認時	通知、自動応答
`SessionStart` / `SessionEnd`	セッション開始・終了	記録、通知

活用例：編集後に自動でフォーマットを揃える

Claudeが生成したコードは動くが、インデントがずれていたり、チームのスタイルと合わなかったりすることがある。
CLAUDE.mdに「フォーマットを揃えて」と書いても、Claudeが忘れることはある。

そこでHooksの出番だ。
「ファイルを編集したら、必ずフォーマッタを実行する」というルールを強制できる。

設定は/hooksコマンドから行う。

/hooksと入力してフック管理画面を開く
「Add Hook」を選択する
イベントは「PostToolUse」（ツール実行後）を選ぶ
マッチャーに「Edit|Write」と入力する（編集または新規作成時に発火）
実行するコマンドにフォーマッタを指定する（例：npx prettier --write "$FILE_PATH"）

これで、Claudeがファイルを編集するたびに自動でフォーマッタが走る。
Claudeの判断に頼らず、機械的に処理されるので確実だ。

設定は~/.claude/settings.json（個人用）または.claude/settings.json（プロジェクト用）に保存される。
慣れてきたらJSONを直接編集することもできる。

注意
Hooksの取り扱い注意：フックは自動実行され、環境の認証情報にアクセスできる。ネットで見つけた設定をコピペする前に、必ず中身を確認しよう（公式ドキュメントでも警告されている）。

初心者がすぐ使える便利ツール：AskUserQuestion、ToDoリスト

ここまでで「ルール」「スキル」「分業」「フック」の4大概念を押さえた。これらはすべて「Claudeの振る舞いをカスタマイズする仕組み」だった。

ここからは少し視点を変えて、Claude Codeに最初から組み込まれている「ツール」を紹介する。ツールは、Claudeが実際に手を動かすための道具だ。

Claude Code の裏側では、Claudeが以下のようなツール群を組み合わせて行動している。

ツール名	役割
`Read`	ファイルを読む
`Write` / `Edit`	ファイルを作成・編集する
`Bash`	シェルコマンドを実行する
`Grep` / `Glob`	ファイルを検索する
`TodoRead` / `TodoWrite`	タスクを管理する
`AskUserQuestion`	ユーザーに質問する

ツールは、ユーザーが明示的に呼び出す必要はない。Claudeが会話の文脈から判断して、必要なツールを自動で選んで使う。

例えば「このファイルを読んで」と頼めば、Claudeは自動でReadツールを使う。「エラーを直して」と頼めば、Readで調査し、Editで修正し、Bashでテストを走らせる。

ただし、一部のツールは「意識して使う」と便利なものがある。ここでは特に初心者が知っておくと得をする2つを紹介する。

AskUserQuestion：曖昧さを「質問」で潰す

Claude Codeは賢いが、曖昧な依頼に対しては「推測して実装→意図とズレる→手戻り」のループに陥りやすい。

AskUserQuestionツールは、このループを最初から断ち切る。

どう起動するか

AskUserQuestionは、Claudeが「曖昧さ」を検知したときに自動で発動する。ユーザーが「このツールを使って」と指示する必要はない。

例えば「ログイン機能を追加して」と頼むと、Claudeは「認証方式は？」「エラー時の挙動は？」といった不明点に気づく。

このとき、Claudeは勝手に推測せず、AskUserQuestionを使って選択肢付きの質問を投げてくる。

質問: APIエラーをどう扱いますか？
A) 即座に失敗（シンプルでデバッグしやすい）
B) リトライ（最大3回自動再試行）（推奨）
C) カスタムハンドラ（独自ロジックを実装）

ユーザーは選択肢を選ぶか、自由入力で答えるだけでよい。結果として、Claudeは「推測」ではなく「ユーザーの意図」に基づいて実装を進められる。

ヒント
質問を「誘発」することもできる：「質問ツールを使って」と伝えると、AskUserQuestionが発動しやすくなる。逆に「推測して進めて」と伝えれば、質問を抑制できる。

活用例：スペック駆動の開発フロー

AskUserQuestionが特に効くのは、Planモード（後述）と組み合わせた「スペック駆動開発」だ。手順は次の通りである。

Planモードに入る（Shift+Tabを2回）
「この機能を追加したい」と大まかに伝える
Claudeが不明点を質問してくる（AskUserQuestion）
選択肢を選びながら、仕様を固める
仕様が固まったら、別セッションで実装に入る

このフローでは、実装開始前に設計判断がほぼ終わっている。結果として、「動くけど意図と違う」という手戻りが激減する。

ヒント
固まった仕様はdocs/SPEC.mdに残す：Planモードで固めた仕様は、docs/SPEC.mdに保存しておくと再利用しやすい。次回の実装セッションで「docs/SPEC.mdを読んで、この仕様を実装して」と伝えるだけで、コンテキストを引き継げる。

ToDoリスト：Claudeの「今やること」が見える

Claude Codeには、タスク管理用のビルトインツール（TodoRead、TodoWrite）がある。これも基本的には自動で動くが、ユーザーが意識して使うと効果が高まる。

どう起動するか

ToDoリストの起動パターンは2つある。

自動発動：複雑なタスクを頼むと、Claudeが自動でToDoを作成・更新する
明示的に頼む：「タスクをToDoリストにまとめてから始めて」と伝える

自動発動に頼ると、Claudeが「ToDoを作るほどでもない」と判断して作らないこともある。確実にToDoを使わせたいときは、明示的に頼む方が安定する。

ToDoの見え方

ToDoの各項目には、次の3つのステータスがある。

pending：未着手
in_progress：作業中
completed：完了

Claude Codeの画面では、このToDoリストがリアルタイムで更新される。複数ファイルにまたがる修正でも「今どこをやっているか」が一目で分かるのが強みだ。

┌──────────────────────────────────────────┐
│ ✔ TodoWrite Update todo list with 5 items │
└──────────────────────────────────────────┘
1. ✅ 既存のログイン処理を調査
2. 🔧 エラーハンドリングを追加（作業中）
3. ❌ テストケースを追加
4. ❌ READMEを更新
5. ❌ lintを通す

自分からToDoを作らせる

Claudeは自動でToDoを作るが、明示的に頼むとより確実だ。例えば、次のように依頼する。

> この機能を追加するためのタスクをToDoリストにまとめてから作業を始めて

こうすると、Claudeは最初にToDoを作成し、1つずつ消化しながら進める。作業が長引いても「何が終わって、何が残っているか」が明確になる。

ヒント
ToDoは「迷子防止」に効く：長い作業をしていると、Claudeが途中で方針を見失うことがある。ToDoを作らせておくと、軌道修正しやすくなる。

拡張は必要になってからでいい：MCPとPlugins

ここまでの4要素（CLAUDE.md、Skills、Subagents、Hooks）だけで、日常の作業は十分にこなせる。

ただし「外部サービスと連携したい」「便利なコマンドを追加したい」という段階になったら、MCPとPluginsの出番だ。

この章では、細かい設定手順には踏み込まず「何ができるか」「どんな場面で使うか」を中心に紹介する。

興味が湧いたら、公式ドキュメントで詳細を確認してほしい。

MCP：Claude Codeを外部ツールに繋ぐ仕組み

MCPは「Model Context Protocol」の略で、Claude Codeと外部ツールを繋ぐための標準規格だ。
平たく言えば「Claudeが外の世界にアクセスするための窓口」である。

MCPを使うと、たとえば次のようなことが可能になる。

チケット駆動の開発：JiraやLinearのチケットを読み、その内容に沿って実装してPRを作る
データ分析：PostgreSQLやBigQueryに直接クエリを投げ、結果をもとにコードを修正する
監視との連携：SentryやDatadogのエラーログを確認し、原因を特定して修正する
コミュニケーション統合：Slackのスレッドを読み込み、議論の内容を踏まえて作業する

導入はclaude mcp add <name>コマンドで行う。

ただし、次に紹介する「プラグイン」がMCPサーバーを同梱しているケースも多い。
初心者は、まずプラグイン経由で体験してから、必要に応じてMCPを直接設定する流れがスムーズだ。

ヒント
MCPは「AIとツールの橋渡し」：MCPはClaude Code専用ではなく、AIエージェント全般で使われるオープンな規格。一度覚えると、他のツールでも応用が利く。

Plugins / Marketplace：便利機能をワンクリックで追加する

プラグインは、スラッシュコマンド、エージェント、フック、スキル、MCPサーバーなどを「ひとまとめにしたパッケージ」だ。
公式の「マーケットプレイス」から、よく使われるプラグインを探してインストールできる。

/pluginと入力すると、プラグイン管理画面が開く。
ここから「Discover」タブでプラグインを探し、気になるものをインストールするだけだ。

マーケットプレイスには、たとえば次のようなプラグインが揃っている。

カテゴリ	プラグイン例	できること
Git操作	`commit-commands`	コミット作成をワンコマンドで完結
外部連携	`github`, `slack`, `notion`	各サービスのMCPサーバーを自動設定
コードレビュー	`pr-review-toolkit`	PRレビュー専用のエージェントを追加
コード知能	`typescript-lsp`, `pyright-lsp`	型エラーや定義ジャンプをClaudeが認識

プラグインをインストールすると、コマンドは/plugin-name:commandの形で追加される。
例えばcommit-commandsをインストールすると、/commit-commands:commitでコミット操作が使えるようになる。

LSP：Claudeに「コード知能」を与える

LSPは「Language Server Protocol」の略で、VS Codeなどのエディタが「定義ジャンプ」「型エラー表示」「参照検索」を実現するために使っている仕組みだ。

Claude Codeにもこの機能を追加できる。
TypeScriptやPythonなど、主要な言語向けのLSPプラグインがマーケットプレイスに用意されている。

LSPプラグインを入れると、Claudeが「この変数はどこで定義されている？」「この関数の呼び出し元はどこ？」といった情報をリアルタイムで把握できるようになる。

大きなコードベースでの作業効率が上がる。

補足
LSPプラグインには「言語サーバー」が必要：LSPプラグインは、システムに対応する言語サーバー（typescript-language-serverなど）がインストールされている前提で動く。エラーが出たら、まず言語サーバーのインストール状況を確認しよう。

拡張に興味が湧いたら

MCPやPluginsは、Claude Codeの可能性を大きく広げる仕組みだ。
ただし、最初から全部を使いこなす必要はない。

まずは基本の4要素（CLAUDE.md、Skills、Subagents、Hooks）で日常作業を回す
「外部サービスと繋ぎたい」と思ったらMCPを調べる
「この操作を毎回やるのは面倒」と思ったらマーケットプレイスでプラグインを探す

公式ドキュメントの「MCPを使用してClaude Codeをツールに接続する」「マーケットプレイスを通じてプリビルトプラグインを発見してインストールする」が、次のステップへの入口になる。

まずはこの順で試す：1週間で「使える」ようになる

全部を一度に覚える必要はない。
以下の順番で1つずつ試していけば、1週間後には「Claude Codeを使いこなしている」と実感できるはずだ。

claudeで起動し、コードベースの概要を質問する → Claudeがプロジェクトを理解する感覚を掴む
./CLAUDE.mdを作り、実行・テスト・禁止事項だけを書く → 毎回説明し直す手間がなくなる
Skillsを1個だけ作る（例：コミットメッセージ規約） → チームのルールをClaudeに覚えさせる
「探索→実装」を意識して分ける → 長いセッションでもコンテキストが足りなくならない
Hooksを1個だけ入れる（例：フォーマット自動化） → Claudeが忘れても機械的に処理される
必要に応じて/pluginや MCPで拡張する → ここまで来れば、何が必要か自分で判断できる

ヒント
会話は「単目的」に切る：話題が混ざると、指示の優先順位が崩れて手戻りが増えやすい。目的が変わったら/clearで会話を切り替える方が、結果的に速い。

まとめ：4つの概念さえ押さえれば怖くない

この記事では、Claude Codeの基本概念を整理した。
振り返ると、覚えるべきことは4つだけだ。

概念	一言で言うと
CLAUDE.md	「このプロジェクトではこうして」という常駐ルール
Skills	「この作業はこの手順で」という必要時の手順書
Subagents	「調査は別の人に任せて」という分業の仕組み
Hooks	「これは絶対やって」という強制処理

最初から全部を使う必要はない。
まずはCLAUDE.mdを1つ作るだけで、Claudeの挙動は大きく安定する。
慣れてきたらスキル、サブエージェント、フックと広げていけばよい。

迷ったときは、公式ドキュメントに戻るのが早い。

クイックスタート：インストール、ログイン、最初の変更
一般的なワークフロー：探索、バグ修正、サブエージェント活用
エージェントスキル：SKILL.mdの書き方、置き場所
フック：イベント一覧、設定方法

ぜひ手を動かして試してみてほしい。
1週間後には「Claude Codeなしでは開発できない」と感じているかもしれない。