4つの仕組みの全体像
Claude CodeはAnthropicが提供するAIコーディングエージェントです。ターミナル上で動作し、コードの生成・修正・テスト・デプロイまで幅広い開発作業を支援します。
しかし、Claude Codeを何も設定せずに使い始めると、こんな経験をすることになります。
- 「うちはTypeScriptで書いて」と毎回言わないといけない
- 「テストはJestで」「CSSはTailwind」「APIはREST」と同じ指示を何十回も繰り返す
- 大量のファイルを調べさせたら、AIの回答精度がどんどん下がっていく
- 「この前教えたじゃん…」なのにAIが覚えていない
これらの問題を一挙に解決するのが、以下の4つの仕組みです。それぞれ「いつ情報が読み込まれるか」が異なるのがポイントです。
| 仕組み | たとえるなら | 解決する問題 | 読み込みタイミング |
|---|---|---|---|
| CLAUDE.md | プロジェクトの「憲法」 | 「毎回同じルールを説明する」手間をゼロに | 毎回のセッション開始時に自動 |
| Skills | 引き出しの「手順書」 | 「繰り返す作業手順」をコマンド一発で再利用 | 呼び出したときだけ |
| Subagents | 別室の「専門家」 | 「大量の情報でAIが混乱する」問題を隔離で解決 | タスク委任時に新しい文脈で |
| Agent Teams | 連携する「チーム」 | 「複数の担当が相談しながら進める」大規模開発を自動化 | チームリーダーが生成 |
4つの仕組みは「どれか1つを選ぶ」ものではなく、組み合わせて使うものです。CLAUDE.mdでプロジェクトの基盤を固め、Skillsで繰り返し作業を効率化し、SubagentsやAgent Teamsで大規模な作業を分担する。この階層的な使い方が、Claude Codeの真価を引き出します。記事の最後に「ECサイトの新機能開発」を題材にした組み合わせ実例も紹介しています。
CLAUDE.md ― プロジェクトの「憲法」
CLAUDE.mdは、Claude Codeがセッション開始時に必ず読み込む設定ファイルです。プロジェクトのコーディング規約、アーキテクチャの決定事項、よく使うコマンドなどを書いておけば、毎回のセッションで説明する必要がなくなります。
会話が長くなりAIが過去の文脈を圧縮（コンパクション）した場合でも、CLAUDE.mdの内容はディスクから再読み込みされるため、重要なルールが失われることはありません。
3つの配置レベル
CLAUDE.mdは配置場所によって適用範囲が変わります。
| レベル | 配置場所 | 適用範囲 | Git管理 |
|---|---|---|---|
| グローバル | ~/.claude/CLAUDE.md | 自分の全プロジェクトに適用 | 対象外（個人設定） |
| プロジェクト | ./CLAUDE.md | プロジェクト全体に適用 | チームで共有可能 |
| サブディレクトリ | ./src/CLAUDE.md | そのディレクトリ配下のファイルに適用 | チームで共有可能 |
さらに、.claude/rules/ディレクトリにルールファイルを置くことで、特定のファイルパターン（例: *.tsxファイルのみ）に限定したルールも設定できます。
書くべき内容と具体例
CLAUDE.mdには何を書けばいいのでしょうか。実際のプロジェクトで使われている内容のイメージを見てみましょう。
# プロジェクトルール ## 技術スタック – フロントエンド: React 19 + TypeScript – スタイリング: Tailwind CSS（styled-componentsは使わない） – 状態管理: Zustand（Reduxは使わない） – テスト: Vitest + Testing Library ## コーディング規約 – コンポーネントは関数コンポーネントのみ（classは禁止） – ファイル名はPascalCase（例: UserProfile.tsx） – 型定義は同じファイル内に書く（別ファイルに分けない） ## よく使うコマンド – テスト実行: npm run test – 型チェック: npm run typecheck – Lint: npm run lint ## 禁止事項 – any型の使用は禁止（unknownを使う） – console.logをコミットしない – 日本語のコメントは書かない（英語で書く）
この内容がCLAUDE.mdにあれば、「ユーザー一覧コンポーネントを作って」と指示するだけで、AIは自動的にReact + TypeScript + Tailwind CSSで、関数コンポーネントとして、PascalCaseのファイル名で、Vitestのテスト付きで生成してくれます。一度も「TypeScriptで書いて」と言わなくてよくなるのです。
CLAUDE.md無し → 「ユーザー一覧コンポーネントをReact + TypeScript + Tailwind CSSで作って。関数コンポーネントで。ファイル名はPascalCase。テストはVitestで。any型は使わないで…」と毎回10個以上の指示が必要
CLAUDE.mdあり → 「ユーザー一覧コンポーネントを作って」だけでOK。ルールは自動的に反映される
活用シーン
「変数名はキャメルケース」「APIレスポンスは必ずtry-catchで囲む」「テストは必ずJestで書く」といったルールをCLAUDE.mdに記載しておけば、チーム全員のClaude Codeが同じルールで動きます。新メンバーが入っても、AIが自動的にルールに従ったコードを生成します。
フロントエンド（React）とバックエンド（Python）が同じリポジトリにある場合、frontend/CLAUDE.mdにReactの規約、backend/CLAUDE.mdにPythonの規約を書いておけば、Claudeが作業するディレクトリに応じて自動的に適切なルールが適用されます。
CLAUDE.mdは200行以内に収めることが推奨されています。長すぎるとAIの注意が分散し、ルールの遵守率が下がります。「絶対に守ってほしいこと」に絞り、詳細な手順はSkillsに分離するのがベストプラクティスです。
Skills ― 必要なときに引き出す「手順書」
Skillsは、特定のタスクに対する作業手順をファイルとして定義し、スラッシュコマンド（例: /deploy、/review）で呼び出せる仕組みです。
CLAUDE.mdが「常にメモリにあるルール」だとすれば、Skillsは「必要なときだけ引き出す手順書」です。普段はファイル名と概要だけがメモリに入っており、ユーザーやAIが呼び出したときに初めて全文が読み込まれます。この「遅延読み込み」により、貴重なコンテキスト（AIが一度に扱える情報量）を節約できます。
Skillsの作り方
プロジェクトの.claude/commands/ディレクトリにMarkdownファイルを置くだけで、ファイル名がそのままスラッシュコマンド名になります。
.claude/commands/deploy.md → /deploy コマンドとして使える
.claude/commands/review.md → /review コマンドとして使える
~/.claude/commands/daily-standup.md → 全プロジェクト共通で /daily-standup として使える
ファイルの中身はMarkdown形式で、AIへの指示をそのまま書きます。たとえば、PRを作成するSkillは以下のようになります。
現在のブランチの変更内容をもとにPull Requestを作成してください。 手順: 1. git diff main…HEAD で変更内容を確認 2. 変更の要約を作成（日本語で） 3. gh pr create でPRを作成 PRのタイトルは「feat: 〇〇機能の追加」の形式にする。 本文には「変更の概要」「テスト方法」「レビューポイント」を含める。 引数が渡された場合は、それをPRタイトルに使う: $ARGUMENTS
このファイルを保存すると、ターミナルで /create-pr カート機能の追加 と打つだけで、AIがgit diffを確認し、変更の要約を作成し、PRを作成してくれます。チームの全員が同じ品質のPRを作れるようになります。
より高度な機能が必要な場合は、.claude/skills/{スキル名}/SKILL.md形式で作成できます。YAML形式のヘッダーで、使用ツールの制限やサブエージェントでの実行など細かい制御が可能です。詳細は公式ドキュメントをご確認ください。
CLAUDE.mdとの違い
| 比較項目 | CLAUDE.md | Skills |
|---|---|---|
| 読み込みタイミング | 常に読み込み | 呼び出し時のみ |
| コンテキスト消費 | 常に消費する | 使うときだけ消費 |
| 用途 | ルール・規約（受動的） | 作業手順（能動的） |
| 推奨ボリューム | 200行以内 | 制限なし（長くてもOK） |
活用シーン
/reviewコマンドでコードレビューを起動し、「セキュリティチェック→パフォーマンスチェック→命名規則チェック→テストカバレッジ確認」という一連の手順を自動実行。レビュアーによる品質のばらつきを防ぎ、見落としを削減します。
/deploy stagingで「テスト実行→ビルド→ステージング環境へデプロイ→動作確認URLの出力」までを一貫して実行。手順漏れやヒューマンエラーを防ぎつつ、新人でも安全にデプロイできる環境を整えられます。
/new-component Buttonで、プロジェクトの規約に沿ったReactコンポーネントファイル・テストファイル・Storybookファイルを一括生成。チームの規約を知らない新メンバーでも、正しい構成のファイルを即座に作成できます。
Subagents ― 独立して動く「専門家」
Subagents（サブエージェント）は、メインのClaude Codeセッションから独立した文脈で動作する専門エージェントです。たとえるなら、チームリーダーが「この調査をお願い」と別室の専門家に仕事を依頼し、結果だけを受け取る仕組みです。
なぜSubagentsが必要なのか
AIには「コンテキストウィンドウ」（一度に扱える情報量の上限）があります。これは人間でいう「ワーキングメモリ」のようなもので、情報を詰め込みすぎると注意力が散漫になり、回答の品質が落ちます。
たとえば、「このプロジェクトのセキュリティ脆弱性を洗い出して」と指示したとします。AIは数百のファイルを読み、依存ライブラリを調べ、設定ファイルを確認します。この情報が全てメインの会話に積み上がると、その後の「じゃあログインフォームを直して」という指示の精度まで下がってしまいます。
Subagentsは自分専用のコンテキストウィンドウで作業するため、メインの会話を汚しません。セキュリティ調査はサブエージェントが別室で処理し、「3件の脆弱性が見つかりました。詳細は…」という結論だけをメインに返します。メインのAIはクリーンな状態で次のタスクに取り組めます。
ユーザーがClaude Codeに指示する内容は今まで通りです。Claude Codeが内部で「これはサブエージェントに任せた方が効率的だ」と判断して自動的にサブエージェントを起動します。あるいは、ユーザーが明示的に「サブエージェントを使って調査して」と指示することもできます。ユーザーから見ると、少し待った後に整理された結果が返ってくるという体験になります。
仕組み
- 1. 委任 ― メインのClaudeが「このタスクをサブエージェントに任せよう」と判断
- 2. 起動 ― サブエージェントが独立した文脈で起動（メインの会話履歴は引き継がない）
- 3. 作業 ― サブエージェントがファイルの読み書き、コマンド実行などを独自に実行
- 4. 報告 ― 最終的な結果だけをメインに返す（途中経過は返さない）
- 5. 統合 ― メインのClaudeが結果を受け取り、作業を続行
活用シーン
「この関数がプロジェクト内のどこから呼ばれているか」を調べたい場合、サブエージェントに調査を委任します。サブエージェントは数百ファイルを走査し、結果を「この関数は12か所で使われており、主にユーザー認証フローで利用されています」とまとめて返します。メインの文脈は消費しません。
新しいライブラリの選定で、3つの候補を同時に調査したい場合、3つのサブエージェントを同時に起動して、それぞれに別のライブラリを調べさせます。すべての結果が揃ったらメインが比較表を作成。直列で調べるより大幅に時間を短縮できます。
テストの実行と結果の解析をサブエージェントに任せます。テストログは非常に長くなることがありますが、サブエージェントが処理してくれるので、メインには「全120テスト中、3件が失敗。原因はデータベース接続のタイムアウト」という要約だけが届きます。
サブエージェント同士は互いに通信できません。「AのサブエージェントがBのサブエージェントの結果を参考にする」といった連携が必要な場合は、次に紹介するAgent Teamsを使います。
Agent Teams ― 連携する「専門家チーム」
Agent Teamsは、2026年2月のOpus 4.6リリースとともに導入された実験的機能です。複数のClaude Codeセッションがタスクリストを共有し、互いにメッセージをやり取りしながら協力して作業を進めます。
Subagentsが「報告書を返すだけの独立した専門家」だとすれば、Agent Teamsは「Slackで会話しながらプロジェクトを進めるチームメンバー」のイメージです。たとえば、フロントエンド担当のエージェントが「APIのレスポンスにユーザーのアバターURLも含めてほしい」とバックエンド担当のエージェントに直接メッセージを送り、バックエンド側がそれに対応する、という流れが自動的に行われます。
SubagentsとAgent Teamsの違い
| 比較項目 | Subagents | Agent Teams |
|---|---|---|
| コミュニケーション | 親に結果を返すだけ | メンバー同士で直接やり取り |
| タスク管理 | 親が個別に指示 | 共有タスクリストで管理 |
| 適するタスク | 独立して完結する作業 | 作業中に連携が必要な作業 |
| トークンコスト | 低い（1倍） | 高い（3〜4倍） |
| 推奨カバー率 | 約90%のケース | 残り10%の複雑なケース |
チーム構成
- チームリーダー（自分のセッション） ― タスクの作成・割り当て、チームメイトの生成、最終結果の統合を行う
- チームメイト（自動生成されるセッション） ― それぞれ独立したClaude Codeセッションとして動き、タスクリストから作業を取得して実行する
チームメイトはプロジェクトのCLAUDE.mdやSkillsを読み込みますが、リーダーの会話履歴は共有されません。リーダーは「何を調べてほしいか」「どんな制約があるか」を明確に指示する必要があります。
活用シーン
新しいAPI機能の追加で、フロントエンド担当とバックエンド担当の2つのチームメイトを生成します。バックエンド担当がAPIのレスポンス形式を決めたら、フロントエンド担当にメッセージで通知。フロントエンドはそのレスポンス形式に合わせてUI側の実装を進めます。Subagentsでは不可能だった「作業中のリアルタイム連携」が実現します。
原因が特定できないバグに対して、3つのチームメイトにそれぞれ異なる仮説を追わせます。「データベースクエリが原因では？」「キャッシュの整合性では？」「外部APIのタイムアウトでは？」と並行調査し、発見した手がかりをリアルタイムで共有。1人では時間がかかるデバッグを大幅に短縮できます。
認証モジュールの刷新で、「旧コードの影響範囲調査」「新モジュールの実装」「テストの更新」「ドキュメントの更新」を4つのチームメイトに分担。タスクの依存関係（例: 実装完了後にテスト更新を開始）も設定できるため、自動的に順序立てて作業が進みます。
Agent Teamsは2026年3月時点で実験的機能のため、設定ファイルで明示的に有効化する必要があります。また、トークン消費がSubagentsの3〜4倍になるため、コスト管理にも注意が必要です。まずはSubagentsで90%のタスクをこなし、本当に連携が必要な場合だけAgent Teamsを使うのが現実的です。
4つの仕組みの使い分けガイド
「どの仕組みをいつ使えばいいか」を判断するためのフローチャートを整理しました。
- 毎回のセッションで必ず守るべきルールがある → CLAUDE.mdに記載
- 特定のタスクで繰り返す作業手順がある → Skillsで定義
- 重い調査や処理をメインの文脈から分離したい → Subagentsに委任
- 複数の担当者が作業中に連携する必要がある → Agent Teamsで協調
組み合わせの実例 ― ECサイトに「クーポン機能」を追加する
実際のプロジェクトでは、4つを組み合わせて使うのが最も効果的です。ここでは「ECサイトにクーポン割引機能を追加する」という架空のタスクで、4つの仕組みがどう連携するかをストーリー形式で見てみましょう。
開発者がClaude Codeを起動した瞬間、CLAUDE.mdが自動的に読み込まれます。「TypeScript必須」「APIはREST形式」「テストカバレッジ80%以上」「決済金額は必ず整数（セント単位）で扱う」といったルールが、この後のすべての作業に自動適用されます。クーポンの割引計算でも、AIは浮動小数点ではなくセント単位の整数演算で実装してくれます。
開発者が /new-api coupons と入力すると、APIの雛形が自動生成されます。このSkillには「ルーティングファイルの追加」「コントローラーの作成」「バリデーションスキーマの作成」「テストファイルの作成」という手順が定義されており、毎回手動で作る必要がありません。同様に、DB移行が必要になったら /db-migrate でマイグレーションファイルを生成します。
「既存のカート処理にクーポン割引をどう組み込むか」を検討するため、2つのSubagentsを同時に起動します。1つ目は「既存の注文・決済フローのコードを全て読み、割引処理の挿入ポイントを特定する」調査、2つ目は「他社のクーポン機能のDBスキーマ設計パターンを調べる」調査です。メインの会話を汚さず、それぞれの調査結果だけがコンパクトに返ってきます。
実装フェーズでは、3つのチームメイトを生成します。「API担当」はクーポンの作成・適用・検証のAPIを実装。「UI担当」はカート画面にクーポン入力フォームと割引表示を追加。「テスト担当」は「有効なクーポン」「期限切れ」「利用回数上限」などのテストケースを作成。API担当がレスポンス形式を決めたら、UI担当に「割引額はdiscount_amountフィールドで返す」とメッセージが自動送信され、UI側はそれに合わせて画面を実装します。
このように、4つの仕組みはそれぞれ別々のフェーズで活躍します。CLAUDE.mdが全工程を通じたルールの土台を提供し、Skillsが定型作業を瞬時に片付け、Subagentsが調査を並列化し、Agent Teamsが実装を分担・連携して進める。この連携により、1人の開発者が数時間かかっていた作業を大幅に短縮できます。
| シーン | 使う仕組み | 理由 |
|---|---|---|
| コーディング規約の統一 | CLAUDE.md | 常に適用すべきルールだから |
| PRの作成手順 | Skills | PRを作るときだけ必要な手順だから |
| ライブラリのバージョン調査 | Subagents | 調査結果だけ欲しく、途中経過は不要だから |
| API仕様変更に伴うフロント・バック同時修正 | Agent Teams | フロントとバックが仕様を確認し合いながら進める必要があるから |
まとめ
Claude Codeの4つのコンテキスト管理術は、それぞれ異なる課題を解決する仕組みです。
- CLAUDE.mdは「プロジェクトの憲法」。毎回自動で読み込まれ、ルールの徹底を実現する
- Skillsは「手順書の引き出し」。必要なときだけ読み込まれ、コンテキストを節約しながら繰り返し作業を標準化する
- Subagentsは「別室の専門家」。メインの文脈を汚さず、重い調査や処理を並列実行できる
- Agent Teamsは「連携する専門家チーム」。作業中にリアルタイムで情報を共有し、複雑な開発タスクを分担できる
- まずはCLAUDE.md + Skillsで基盤を固め、必要に応じてSubagents → Agent Teamsとステップアップするのがおすすめ
詳細な設定方法はClaude Code公式ドキュメントで確認できます。
