Skillsと他のClaude機能の使い分け
— 全体像の中のSkills
Claudeには7つのカスタマイズ機能があり、それぞれ異なる問題を解決します。Skillsが万能なわけではなく、すべてをSkillsに詰め込むのは典型的な間違いです。本記事では各機能の役割・判断基準・組み合わせパターンを体系的に整理します。
Claudeのエージェント機能群は、Skills（手続き的知識）、Prompts（即時指示）、Projects（背景知識）、MCP（ツール接続）、Subagents（タスク委譲）、CLAUDE.md（常時ルール）、Hooks（自動処理）の7つで構成されます。各機能には明確な得意領域があり、組み合わせることで包括的なカスタマイズが実現できます。
この記事で学べること
7つのエージェント機能群の全体像と役割
各機能との詳細比較と判断基準
迷ったときの判断フローチャート
複数機能を組み合わせた実践例
前提知識: Part 1のSkillsの基本概念を理解していると読みやすいですが、この記事は独立した「選び方ガイド」として設計しています。
エージェンティックな構成要素の全体像
まずは7つの機能を俯瞰し、各機能が「何を解決するか」を一目で把握できるようにします。
Skills
「やり方」を教える再利用可能な専門知識パッケージ
Prompts
その場限りの会話指示
Projects
特定テーマの背景知識を常時提供するワークスペース
MCP
外部ツール・データソースへの接続レイヤー
Subagents
独立した実行コンテキストでの専門タスク委譲
CLAUDE.md
プロジェクト全体に常時適用されるルール（Claude Code専用）
Hooks
イベント駆動の自動処理（Claude Code専用）
Key Insight
Skillsは「トピックに関連するときにClaudeが自動的に適用すべき知識」がある場合に使い、他の機能と併用するのがベストプラクティスです。「どれか一つを選ぶ」のではなく「適材適所で組み合わせる」のが正しいアプローチです。
詳細比較表
6つの主要機能を7つの観点で横断比較します。Skills列をハイライトしているので、他機能との違いを視覚的に把握できます。
| 観点 | Skills | Prompts | Projects | MCP | Subagents | CLAUDE.md |
|---|---|---|---|---|---|---|
| 提供するもの | 手続き的知識 | 即時の指示 | 背景知識 | ツール接続 | タスク委譲 | プロジェクト規則 |
| 持続性 | 会話横断 | 1会話のみ | プロジェクト内 | 常時接続 | セッション横断 | 常時適用 |
| 含むもの | 指示+コード+資産 | 自然言語 | 文書+文脈 | ツール定義 | エージェントロジック | Markdown |
| 読み込み | 動的（必要時） | 毎ターン | 常時（RAG含む） | 常時 | 呼び出し時 | 常時 |
| コード実行 | ✅ | — | — | ✅ | ✅ | — |
| 対応環境 | 全環境 | 全環境 | Claude.ai | 全環境 | Code, SDK | Claude Code |
| 最適な用途 | 専門ワークフロー | 一回限りの依頼 | 文脈の一元管理 | 外部データ接続 | 独立した専門タスク | コーディング規約 |
この表から浮かび上がる3つのポイント
Skillsは「必要時のみ動的に読み込まれる」唯一の知識提供手段
PromptsとProjectsはコードを実行できない
CLAUDE.mdとHooksはClaude Code専用
各機能との個別比較
Skills vs Prompts
Prompts
一時的で反応的。会話ごとに消え、ユーザーが毎回入力する必要がある。
例: 口頭での指示
Skills
永続的で能動的。一度作成すれば何度でも使え、Claudeが自動的に適用タイミングを判断する。
例: 体系化されたマニュアル
判断基準: 同じプロンプトを3回以上書いていると気づいたら、それはSkillに変換すべきサインです。「毎回レポートのフォーマットを指定している」「コードレビューのチェックポイントを毎回列挙している」といった状況が該当します。
併用パターン
Skillで基盤的な専門知識（フォーマット・構成ルール）を提供し、Promptでタスク固有の文脈（「今回は第3四半期の売上データに焦点を当てて」）を補足する。Skillsが「常にこうやる」を定義し、Promptsが「今回はこれを」を指定する関係です。
Skills vs Projects
Projects
「何を知るべきか」を提供。200Kトークンのコンテキストウィンドウに文書をアップロードし、背景知識として常時読み込み。
= 「これを知っておいて」
Skills
「どうやるか」を提供。必要時のみ動的に読み込まれる手続き的知識で、コード実行も可能。
= 「こうやって」
判断基準: 知識（What）ならProject、手順（How）ならSkill。製品仕様書・市場調査レポート → Project。技術ドキュメント作成手順・データ分析ワークフロー → Skill。複数のProjectで同じ指示をコピーしていたら、Skillに抽出すべきサインです。
併用パターン
「Q4製品ローンチ」Projectに市場調査や製品仕様をアップロードし、「技術ドキュメント作成」Skillで構成・フォーマット・作成手順を定義する。Projectが「何について書くか」の文脈を提供し、Skillが「どう書くか」のプロセスを提供します。
Skills vs MCP
SkillsとMCPの関係は最も重要な組み合わせの一つです。ハードウェアストアに例えると、MCPは「棚に並んだ工具にアクセスできること」、Skillsは「どの工具をどの順番で使い、どう修理するかを知っている店員の専門知識」に相当します。
MCP
「何に接続するか」を提供。外部ツールやデータソースへの標準化されたアクセスレイヤー。
Google Drive, Slack, GitHub, DB…
Skills
「そのツールをどう使うか」を提供。取得データの処理順序、ワークフロー実行、出力フォーマットのロジック。
手順・判断基準・品質基準
判断基準: アクセスの問題ならMCP、使い方の問題ならSkill。「Claudeにデータベースを参照させたい」→ MCP。「データベースを参照するとき、常に日付範囲でフィルタしてからクエリを実行してほしい」→ Skill。
併用パターン: 会議準備ワークフロー
Notion Meeting Intelligence
MCP: Notion接続
ページ検索
読み取り
作成
接続 → ロジック
Skill: Meeting Intelligence
検索すべきページの特定（プロジェクト、過去の議事録、関係者情報）
2つのドキュメントを構造化（内部プリリード / 外部アジェンダ）
フォーマット基準の遵守を確認
コンポーザブル設計
1つのSkillが複数のMCPサーバーを調整でき、1つのMCPサーバーが多数のSkillをサポートできます。新しい接続を追加すれば既存のSkillがそれを活用でき、Skillを改善すれば接続済みの全ツールに反映されます。
注意: MCPサーバーにもツール使用のヒントが含まれることがあります。経験則として、MCPの指示は「サーバーとツールの正しい使い方」、Skillの指示は「特定プロセスやマルチサーバーワークフローでの使い方」をカバーすべきです。MCPが「JSONで返せ」と言い、Skillが「Markdownテーブルでフォーマットせよ」と言うような矛盾は避けてください。
Skills vs Subagents
Subagentsは独立した実行コンテキストで動作し、固有のコンテキストウィンドウ・カスタムシステムプロンプト・特定のツール権限を持ちます。Skillsは現在の会話コンテキストに統合されます。
| 観点 | Skills | Subagents |
|---|---|---|
| 実行コンテキスト | 現在の会話に統合 | 分離された別コンテキスト |
| ツールアクセス | メイン会話と同じ | 個別に制限可能（例: 読み取り専用） |
| Skills継承 | — | 自動継承されない（明示的リスト必要） |
| 適したケース | 会話全体で適用される知識の強化 | 特定タスクの委任・並列処理 |
判断基準: 隔離と権限制御が必要ならSubagent、会話内の知識強化ならSkill。Skillsは「トレーニング教材」のように誰でも読み込めるもの、Subagentsは「専門の従業員」のように独自のコンテキストを持つ独立した存在です。
重要: Subagentsは親のSkillsを自動的に継承しません。SubagentにSkillを使わせるには、エージェント定義ファイルで明示的にリストが必要です。ビルトインエージェント（Explorer、Plan、Verify等）はSkillsを利用できません。
Skills vs CLAUDE.md
| 観点 | Skills | CLAUDE.md |
|---|---|---|
| ロードタイミング | タスクマッチ時に自動 | 毎会話で常時ロード |
| 用途 | 特定タスクの専門知識 | プロジェクト全般のルール |
| 対応環境 | 全プラットフォーム | Claude Code専用 |
| 含められるもの | 指示+コード+参照ファイル | Markdownのみ |
判断基準: 常に適用すべきルールはCLAUDE.md、特定タスクでのみ必要な知識はSkills。「テストなしでmainにマージしない」→ CLAUDE.md。「PRレビューのチェックリスト」→ Skill。複数プロジェクトで同じ指示をCLAUDE.mdにコピーしていたら、Skillに抽出すべきサインです。
Skills vs Hooks
Skills — リクエスト駆動
ユーザーの依頼内容に基づいてClaudeが起動を判断。Claudeの推論・判断に影響するガイドライン。
例: 「PRレビューを依頼されたらチェックリストに沿ってレビュー」
Hooks — イベント駆動
ファイル保存時やツール呼び出し時に自動実行。Claudeのアクションに伴う自動処理。
例: 「ファイル保存するたびにフォーマットチェック」
判断基準: 「いつも自動でやってほしい」ならHook、「依頼されたらやってほしい」ならSkill。HooksはClaude Code専用です。
判断フローチャート
「どの機能を使うべきか」迷ったとき、以下のフローに立ち返ってください。
同じ指示を繰り返し入力している
3回以上同じプロンプトを書いたらSkill化のサイン
Skill を作成
特定プロジェクトの背景知識を常に参照したい
製品仕様書、リサーチ資料、顧客データ等の静的知識
Project を使用
外部ツールやデータソースに接続したい
Google Drive、Slack、GitHub、データベース等
MCP を使用
独立した専門タスクを隔離して委譲したい
権限制御が必要、並列処理したい場合
Subagent を使用
プロジェクト全体に常時適用するルールがある
コーディング規約、禁止事項等（Claude Code専用）
CLAUDE.md を使用
ファイル保存時等に自動処理を走らせたい
イベントトリガーの自動処理（Claude Code専用）
Hook を使用
一回限りのリクエスト
今後繰り返さないならSkill化は不要
Prompt で十分
Key Insight
実際には複数の機能を組み合わせるケースがほとんどです。「MCP か Skill か」ではなく「MCP と Skill」で考えるのが正しいアプローチです。
組み合わせの実践例: 競合分析リサーチエージェント
全機能がどう協調するかを、「競合分析リサーチエージェント」の構成例で見てみましょう。5つの構成要素がそれぞれ明確に異なる役割を果たし、単独では不可能な高度なワークフローを実現します。
競合分析リサーチエージェント — アーキテクチャ
PROMPT
「トップ3競合のAI機能を分析し、ギャップを特定して」
PROJECT: Competitive Intelligence
業界レポート、競合製品ドキュメント、顧客フィードバック、過去のリサーチサマリー
SKILL: competitive-analysis
GDriveフォルダ構造ナビ、分析フレームワーク、レポートフォーマット基準
MCP接続
SUBAGENT: market-researcher
ツール: Read, Grep, Web検索
SUBAGENT: technical-analyst
ツール: Read, Bash, Grep
実行フロー
Projectのコンテキスト読み込み
アップロード済みの業界レポートや製品仕様を把握。自社の製品戦略という「レンズ」を通して分析すべきことを理解。
MCPで外部データソースにアクセス
Google Driveから社内資料を検索、GitHubで競合OSSを確認、Web検索でリアルタイム市場情報を収集。
Skillが分析フレームワークを提供
GDriveのどのフォルダを最初に見るか、どの命名規則のファイルが最新版か、分析結果をどう構造化するかをClaudeに教える。
Subagentsが並行して専門作業を実行
market-researcherが市場トレンドを分析し、technical-analystが技術的な強み・弱みを評価。それぞれ独立したコンテキストで作業。
Promptの指示に基づいて最終レポート生成
途中で「特にヘルスケア業界のエンタープライズ顧客に焦点を当てて」といった方向性調整も可能。
各構成要素の役割整理
Project
背景知識の提供（業界レポート、自社戦略）
MCP
外部データへのアクセス（GDrive、GitHub、Web）
Skill
分析手順とフォーマットの定義（ワークフローロジック）
Subagents
専門タスクの並列実行（市場調査、技術分析）
Prompt
具体的な依頼と方向性の指示
まとめ
核心的な区分
Skills =「どうやるか」（手続き的知識）、Projects =「何を知るべきか」（背景知識）、MCP =「何に接続するか」（ツール接続）。この3つの区分を覚えておけば、大抵のケースで迷いません。
最も実用的な判断基準
「同じ指示を繰り返し書いている」ことに気づいたらSkill化のサイン。知識はProject、接続はMCP、隔離はSubagent、常時ルールはCLAUDE.md、自動処理はHook。
最も重要な原則
これらの機能は排他的ではなく、組み合わせて使うものです。競合分析リサーチエージェントの例が示すように、各構成要素がそれぞれの得意領域を発揮することで、単独では不可能な高度なワークフローが構築できます。
機能選定 クイックリファレンス
繰り返す手順
→ Skill
背景知識
→ Project
外部接続
→ MCP
タスク隔離
→ Subagent
常時ルール
→ CLAUDE.md
自動処理
→ Hook
一回限り
→ Prompt
homulaの支援体制
homulaは、エンタープライズ企業向けにAIエージェントの戦略策定・PoC・実装・運用・内製化までを一気通貫で支援するAIインテグレーターです。Skills・MCP・オーケストレーションツールを組み合わせた最適な構成設計を、400社超の支援実績に基づくノウハウで提供しています。
よくある質問
Promptsは「その場限りの口頭指示」、Skillsは「体系化されたマニュアル」です。同じ指示を3回以上繰り返しているなら、Skillに変換すべきサインです。Skillは一度作成すれば何度でも再利用でき、Claudeがタスク内容を見て自動的に適用タイミングを判断します。
いいえ、MCPとSkillsは補完関係にあります。MCPは外部ツールやデータソースへの「接続」を担い、Skillsはそのツールを「どう使うか」のロジックを定義します。併用することで、接続先のデータをどう処理し、どんな順序でワークフローを実行するかを体系化できます。
CLAUDE.mdは全会話に常時読み込まれ、Skillsは必要時のみ動的に読み込まれます。同じルールが両方に存在する場合は矛盾が生じるため、常時適用すべきルール（コーディング規約等）はCLAUDE.mdに、特定タスクでのみ必要な知識はSkillsに分離するのが推奨設計です。
Subagentsは親のSkillsを自動継承しません。SubagentにSkillを使わせるには、エージェント定義ファイルで明示的にSkillをリストする必要があります。ビルトインエージェント（Explorer、Plan等）はSkillsを利用できませんが、カスタムSubagentは明示的に設定すれば利用可能です。
homulaは、Skills・MCP・オーケストレーションツールを組み合わせたAIエージェントの戦略策定からPoC・実装・運用までを一気通貫で支援しています。5日間のブートキャンプで、最適な機能構成を含むプロトタイプとROI試算を構築できます。400社超の支援実績に基づく技術選定のノウハウを提供しています。
AIエージェントの最適な機能構成を設計しませんか？
homulaは、Skills・MCP・オーケストレーションツールを組み合わせたAIエージェントの戦略策定からPoC・実装・運用までを一気通貫で支援します。5日間のブートキャンプで、動くプロトタイプとROI試算を構築できます。