AIエージェントを構築する開発者は、繰り返し直面する決断があります：エージェントがコードを超えた機能 — Web検索、画像生成、動画、ストレージ — を必要とするとき、それをどう追加するか？
3つのアプローチが議論を支配しています：MCPサーバー、Skills、Capability Runtimeです。これらはしばしば競合として位置づけられますが、そうではありません。スタックの異なるレイヤーで異なる問題を解決します。
選び方を説明しましょう。
3つのレイヤーを定義する
MCPサーバー：トランスポートレイヤー
MCP（Model Context Protocol）は、AIエージェントが外部ツールに接続する方法を定めたオープンスタンダードです。MCPサーバーは、検索、データベースクエリ、ファイル操作などのツールセットを公開する軽量プログラムで、MCP互換のエージェントなら誰でも呼び出せます。
MCPは接続の問題を解決します：エージェントはどうやって外部ツールを発見し呼び出すのか？インターフェースを標準化することで、各ツールが独自プロトコルを持つ代わりに、すべてがMCPを話します。
Skills：インストラクションレイヤー
Skills（エージェントスキルまたはSKILL.mdファイルとも呼ばれる）は、エージェントにツールの使い方やタスクの実行方法を教えるMarkdownドキュメントです。Skillは「CLIのインストール方法、利用可能なコマンド、エラーが発生した時の対処法」を伝えます。
Skillsはインストラクションの問題を解決します：エージェントはツールに接続した後、何をすべきかをどう知るのか？Skillがなければ、エージェントはツールを見ることはできてもワークフローを理解できません。
Capability Runtime：バンドルレイヤー
Capability Runtimeは、画像生成、動画、Web検索、クラウドストレージ、公開など、複数の機能を1つのエンドポイントの背後にバンドルする単一のCLI（またはAPI）です。5つの別々のMCPサーバーを設定する代わりに、1つのツールをインストールするだけです。
Capability Runtimeは統合の問題を解決します：設定、認証情報、トークンオーバーヘッドに溺れることなく、エージェントに多くの機能を与えるにはどうすればよいか？
レイヤー図
┌─────────────────────────────────────────────┐
│ あなたのAIエージェント │
│ (Claude Code, Cursor, Codex, Windsurf) │
├─────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────┐ │
│ │ MCP │ │ Skills │ │ Capability │ │
│ │サーバー │ │ (SKILL) │ │ Runtime │ │
│ │ │ │ │ │ │ │
│ │ ツールを│ │エージェント│ │ 機能を │ │
│ │ 接続 │ │ に指示 │ │ バンドル │ │
│ └─────────┘ └─────────┘ └─────────────┘ │
│ │
│ トランスポート インストラクション 統合 │
│ レイヤー レイヤー レイヤー │
└─────────────────────────────────────────────┘
これらのレイヤーのどれも他のレイヤーを置き換えません。実際、一緒に使うときに最も効果的です：
- MCPは接続する — エージェントをCapability Runtimeに接続
- Skillsは教える — エージェントにRuntimeのコマンドの使い方を指導
- Runtimeはバンドルする — 接続して指示する対象が1つだけになるよう機能を統合
各レイヤーを使うべきタイミング
MCPサーバーのみを使う場合：
よくメンテナンスされたMCPサーバーがある1〜2つの特定ツールが必要なとき。例えば、カスタムMCPサーバーを通じて会社の内部データベースにエージェントを接続する場合。あるいは既存のMCPサーバーを通じてGitHub統合を追加する場合。
MCPのみが理にかなうのは：
- 必要な機能がちょうど1〜2個のとき
- 機能が専門的であるとき（自社のデータベース、自社のAPI、自社のJira）
- サーバー設定を維持するDevOpsサポートがあるとき
- 1〜2サーバーのトークンオーバーヘッドが無視できるとき
Skillsを使う場合：
エージェントにツールへのアクセスだけでなく、ワークフローを理解させたいとき。Skillは単にコマンドを列挙するのではなく、インストール、認証、設定、検証、使用という順序を教えます。
Skillsが不可欠なのは：
- ツールに多段階のセットアッププロセスがあるとき
- エラー処理が重要なとき（「エラーXが出たらYを試せ」）
- エージェントがツールで自立的に作業できるようにしたいとき
- ワークフローをチーム全体で共有するとき
Capability Runtimeを使う場合：
4つ以上の機能が必要で、設定のオーバーヘッドが手に負えなくなってきたとき。これは個人開発者や小規模チームにとって最も一般的なシナリオです。
Capability Runtimeが理にかなうのは：
- エージェントが画像、動画、検索、ストレージ、公開を必要とするとき
- 6つのAPIキーと5つのMCPサーバー設定を管理したくないとき
- 複数サーバーのトークンオーバーヘッドがエージェントのパフォーマンスに影響しているとき
- 1回のインストール、1つの認証情報、1つの出力フォーマットで済ませたいとき
ハイブリッドアプローチ（ほとんどのチームが実際に使っている方法）
実際には、最適なセットアップは通常ハイブリッドです：
MCPサーバー（専門ツール） + Capability Runtime（汎用機能） + Skills（ワークフロー指示）
エージェントは以下に接続します：
- 1〜2個のMCPサーバー — 内部用または専門ツール用（データベース、Slack、Jira）
- 1個のCapability Runtime — 汎用機能用（画像、動画、検索、ストレージ、公開）
- 1個のSkillファイル — エージェントにRuntimeの使い方を教える
これにより、固有のニーズには最高のものを、それ以外には最小限のオーバーヘッドを実現できます。
トークンの現実
ハイブリッドアプローチは概念的にクリーンなだけでなく、測定可能な影響があります。各MCPサーバーはエージェントのコンテキストにツール説明を追加します。5つのMCPサーバーでは、ツール説明だけで15,000〜40,000トークンを消費します。
2つのMCPサーバー + 1つのCapability Runtimeのハイブリッドセットアップでは、これを約8,000〜14,000トークンに削減します。実際の作業に使えるコンテキストが10〜15%増える計算です。
よくある間違い
間違い1：MCPだけで十分だと思い込む
MCPはツールを接続します。ツールをバンドルせず、認証情報を管理せず、トークンオーバーヘッドも削減しません。5つ以上のMCPサーバーを実行しているなら、エージェントはそのすべてにコストを支払っています。
間違い2：Skillsがツールを置き換えると思い込む
Skillsはワークフローを教えます。機能を提供するわけではありません。Skillはエージェントに画像の生成方法を教えられますが、エージェントには依然として背後に実際の画像生成ツールが必要です。
間違い3：RuntimeがMCPを置き換えると思い込む
Capability Runtimeは汎用機能を統合します。専門的な統合の必要性を置き換えるものではありません。エージェントは依然として内部データベースやJiraに接続するためにMCPが必要です。Runtimeはほとんどのエージェントが共有する汎用的な機能を処理します。
1つの表で決断
| 必要なもの... | 使うもの... |
|---|---|
| 1〜2個の専門ツール | MCPサーバー |
| エージェントにワークフローを理解させたい | Skills |
| 4つ以上の汎用機能 | Capability Runtime |
| 上記すべて | ハイブリッド：MCP + Runtime + Skills |
結論
MCP vs Skills vs Capability Runtimeの議論は要点を見失っています。これらは同じスタックの3つのレイヤーであり、3つの競合アプローチではありません。
MCPはUSB-Cポートです。Skillsは取扱説明書です。Capability Runtimeは差し込むデバイスです。
エージェントには3つすべてが必要です。問うべきは「どれか」ではなく「それぞれどれだけか」です。
最終更新：2026年5月