MCP vs Skills論争に決着をつける試み。AIエージェントの「拡張手段」を実装・設計・セキュリティで徹底比較する

はじめに

こんばんは、mirukyです。

「MCPはもう死んだ」「Skillsが新しい標準だ」、、などなど。
ニーチェ？
ここ数週間、特に英語圏のX（旧Twitter）やHacker Newsでこの手の議論が絶えません。2026年4月2日に投稿された下記の記事は、特に話題になっていましたね。

MCPとSkillsはどちらもAIエージェントの能力を拡張する仕組みですが、設計思想がまったく異なります。MCPは プロトコル であり、Skillsは フォーマット です。この違いを理解せずに「どちらが優れているか」を論じても意味がありません。

本記事では、MCPとSkillsの仕様・設計思想・実装パターン・セキュリティモデルを一次ソースに基づいて比較し、「結局どう使い分ければいいのか」に対する私の結論を述べます。

なお、私はMCPサーバーの自作経験とSkillsの実践経験の両方を持っています。

本記事の情報は2026年4月時点のものです。MCP仕様はprotocolVersion 2025-06-18、Agent Skills仕様はagentskills.io掲載版を参照しています。

目次

1. MCPとは何か
2. Skillsとは何か
3. アーキテクチャの比較
4. 実装パターンの比較
5. セキュリティモデルの比較
6. コンテキストコストの比較
7. エコシステムと互換性
8. 結論：使い分けの判断基準

1. MCPとは何か

1-1. 設計思想

MCP（Model Context Protocol） は、AIアプリケーション（ホスト）と外部サービス（サーバー）を接続するための 通信プロトコル です。Anthropicが開発し、現在はLinux Foundation傘下のオープンプロジェクトとして管理されています。

MCPの核心は 関心の分離 です。LLMは「何をしたいか」だけを知っていればよく、「どうやるか」はMCPサーバーが処理します。デビッド氏の表現を借りれば、MCPは Connector（接続器） です。

1-2. アーキテクチャ

MCPはクライアント・サーバーアーキテクチャを採用しています。

通信はJSON-RPC 2.0で行われ、トランスポート層は2種類あります。

トランスポート	方式	用途
Stdio	標準入出力	ローカルプロセス間通信
Streamable HTTP	HTTP POST + SSE	リモートサーバー通信

1-3. 3つのプリミティブ

MCPサーバーは3種類のプリミティブを公開できます。

プリミティブ	役割	ディスカバリ	実行
Tools	LLMが呼び出せる関数（API呼び出し、DB操作等）	tools/list	tools/call
Resources	コンテキストデータの提供（ファイル内容、データベースレコード等）	resources/list	resources/read
Prompts	インタラクションテンプレート（システムプロンプト、few-shot例等）	prompts/list	prompts/get

各プリミティブはJSON Schemaで入出力が型定義されます。ツールの例を示します。

{
  "name": "get_weather",
  "title": "Weather Information Provider",
  "description": "Get current weather information for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City name or zip code"
      }
    },
    "required": ["location"]
  }
}

1-4. ライフサイクル

MCPは ステートフル なプロトコルです。接続時にケイパビリティ（対応機能）のネゴシエーションを行い、ツール一覧の変更はリアルタイム通知で同期されます。

この動的なライフサイクルにより、MCPサーバーが新しいツールを追加したり、既存のツールを変更したりすると、接続中のクライアントに即座に反映されます。

2. Skillsとは何か

2-1. 設計思想

Agent Skills は、AIエージェントに手順的知識（手順書、ワークフロー、ドメイン知識）を提供するための オープンフォーマット です。Anthropicが開発し、現在はagentskills.ioで仕様が公開されています。

デビッド氏の表現を借りれば、Skillsは Manual（マニュアル） です。MCPが「接続」を担うのに対し、Skillsは「知識」を担います。

2-2. ディレクトリ構造

Skillsの実体は、 SKILL.md を含むディレクトリです。

my-skill/
├── SKILL.md           # 必須：メタデータ + 手順書
├── scripts/           # 任意：実行可能スクリプト
├── references/        # 任意：詳細ドキュメント
└── assets/            # 任意：テンプレート、リソース

2-3. SKILL.mdのフォーマット

SKILL.md はYAMLフロントマター + Markdownコンテンツで構成されます。

---
name: pdf-processing
description: Extract PDF text, fill forms, merge files. Use when handling PDFs.
license: Apache-2.0
metadata:
  author: example-org
  version: "1.0"
---

# PDF Processing

1. `check_service_status` で対象ファイルの状態を確認する
2. テキスト抽出にはPythonの `pdfplumber` を使用する
3. ...

Agent Skills仕様で定義されているフロントマターは以下のとおりです。

フィールド	必須	説明
name	はい	最大64文字。小文字英数字とハイフンのみ
description	はい	最大1024文字。何をするか、いつ使うか
license	いいえ	ライセンス名または同梱ファイルへの参照
compatibility	いいえ	環境要件（対応製品、必須パッケージ等）
metadata	いいえ	任意のキー・バリューペア
allowed-tools	いいえ	スキル使用時に自動承認するツールのリスト

Claude Codeはこの仕様を拡張し、 context: fork （サブエージェント実行）、 disable-model-invocation （手動起動のみ）、 hooks （スキルライフサイクルフック）などの追加フィールドをサポートしています。

2-4. プログレッシブディスクロージャ

Skillsは 段階的読み込み を前提に設計されています。

段階	内容	トークンコスト
起動時	name + description（全スキル分）	約100トークン/スキル
アクティベート時	SKILL.md全文	推奨5,000トークン以下
必要時	scripts/, references/, assets/	必要分のみ

この設計により、スキルが10個あっても起動時のコンテキスト消費は約1,000トークンに抑えられます。詳細な手順書やスクリプトは実際に使うときだけ読み込まれます。

2-5. 対応ツール

Agent Skills仕様は多くのAIツールで採用されています。公式サイトに掲載されている対応製品は以下のとおりです。

Claude Code、OpenAI Codex、Gemini CLI、Cursor、Kiro、Goose、Amp、Roo Code、Junie（JetBrains）、OpenCode、Mistral AI Vibeなど。

3. アーキテクチャの比較

3-1. 通信方式

MCPとSkillsは根本的に異なるレイヤーで動作します。

項目	MCP	Skills
本質	通信プロトコル	ドキュメントフォーマット
通信方式	JSON-RPC 2.0（Stdio / HTTP）	なし（ファイル読み込み）
ステート	ステートフル（接続を維持）	ステートレス（読み切り）
実行場所	MCPサーバー（ローカルまたはリモート）	エージェントのホスト環境
更新検知	リアルタイム通知（list_changed）	ファイル監視（実装依存）

MCPサーバーは「ツールを実行する主体」です。LLMが tools/call を送ると、MCPサーバーが処理を実行して結果を返します。

一方、Skillsは「手順を記述した文書」です。LLMがスキルを読み込み、 LLM自身が 手順に従って既存のツールを実行します。実行主体はあくまでLLMです。

3-2. データフロー

MCPのデータフローを示します。

Skillsのデータフローを示します。

この違いは重要です。MCPではLLMはツールの内部実装を知る必要がありません。Skillsでは、LLMが手順を理解し、適切なツールを選択して実行する判断力が求められます。

3-3. ポータビリティ

MCPの強みは クロスプラットフォームの接続性 です。リモートMCPサーバーは、Claude Code、ChatGPT、VS Code、モバイルアプリなど、MCPクライアントを実装した任意の環境から利用できます。

Skillsの強みは クロスツールの互換性 です。Agent Skills仕様に準拠した SKILL.md は、Claude Code、Codex、Gemini CLI、Cursorなど対応ツール間でそのまま流用できます。ただし、CLIの実行が必要なスキルは、ターミナルを持たない環境（ChatGPTのWebインターフェースなど）では動作しません。

4. 実装パターンの比較

4-1. MCPの実装例

MCPサーバーの実装は、言語固有のSDKを使用します。Pythonでの最小例を示します。

# mcp_server.py
from mcp.server import Server
from mcp.types import Tool, TextContent

server = Server("example-server")

@server.tool()
async def get_user(user_id: str) -> list[TextContent]:
    """指定したIDのユーザー情報を取得します。"""
    # 実際にはDBやAPIに接続
    return [TextContent(type="text", text=f"User {user_id}: John Doe")]

MCPサーバーを使うには、ホスト側で設定が必要です。

{
  "mcpServers": {
    "example": {
      "command": "python",
      "args": ["mcp_server.py"]
    }
  }
}

4-2. Skillsの実装例

同じ機能をSkillsで実現する場合、手順書として記述します。

---
name: get-user
description: ユーザー情報を取得する。ユーザーIDが指定された場合に使用する。
allowed-tools: Bash(curl *)
---

# ユーザー情報取得

1. 以下のcurlコマンドでAPIにリクエストを送る
2. レスポンスのJSONから必要な情報を抽出する

## 手順
curl -s https://api.example.com/users/{user_id} \
  -H "Authorization: Bearer $API_TOKEN"

MCPとSkillsの実装コストを比較すると、次のような傾向があります。

項目	MCP	Skills
初期実装コスト	高（サーバー実装が必要）	低（マークダウンを書くだけ）
メンテナンスコスト	中（バージョン管理、デプロイ）	低（ファイル編集のみ）
テスト容易性	高（JSON-RPCでユニットテスト可能）	低（LLMの解釈に依存）
型安全性	高（JSON Schemaで入出力を定義）	低（自然言語の記述に依存）
認証の統合	OAuth、APIキー等をプロトコルレベルで処理	ユーザーが環境変数やファイルで管理

4-3. 「純粋な知識」と「実行を伴う操作」

ここが使い分けの最大のポイントです。デビッド氏も記事で強調していますが、Skillsが真価を発揮するのは 実行を伴わない知識の提供 です。

【Skillsが得意なパターン】

• コーディング規約の教育（「このリポジトリではこのスタイルで書け」）
• ワークフローの標準化（「PRレビューはこの手順で行え」）
• 既存ツールの使い方の教育（「curlでこのAPIを叩くときはこのフォーマットで」）
• ドメイン知識の提供（「この業界用語はこういう意味」）

【MCPが得意なパターン】

• 外部サービスとの接続（Notion、GitHub、Sentry等）
• 認証が必要な操作（OAuthフロー、APIキーの管理）
• リアルタイムデータの取得（メトリクス、ログ、通知）
• 状態を持つ操作（データベースクエリ、ファイル操作）

冒頭の記事の言葉を引用します。

If a Skill's instructions start with "install this CLI first," you've just added an unnecessary abstraction layer and extra steps. Why not just use a remote MCP instead?
（スキルの手順が「まずこのCLIをインストールしてください」で始まるなら、不要な抽象化レイヤーと余計な手順を追加しただけだ。リモートMCPを使えばいいのでは？）

この指摘は的を射ています。CLIのインストール、認証トークンの管理、環境変数の設定といった手順をSkillsに記述するのは「マニュアルに『電話帳を調べて電話をかけろ』と書く」ようなもので、MCPという「直通電話」が存在するなら、そちらを使うべきです。

5. セキュリティモデルの比較

5-1. MCPのセキュリティ

MCP仕様はセキュリティ要件を明確に定義しています。

【サーバー側の義務】

• すべてのツール入力をバリデーションする
• 適切なアクセス制御を実装する
• レート制限を実装する
• ツール出力をサニタイズする

【クライアント側の推奨事項】

• 機密操作の前にユーザーに確認を求める
• サーバーに送信する前にツール入力をユーザーに表示する
• ツール結果をLLMに渡す前にバリデーションする
• ツール呼び出しにタイムアウトを設定する
• 監査目的でツール使用をログに記録する

MCPのセキュリティ上の強みは 実行境界の明確さ です。ツールの実行はMCPサーバー内で完結し、MCPサーバーが公開するインターフェースの範囲外の操作をLLMが行うことはできません。

ただし、ローカルMCPサーバー（Stdioトランスポート）は、ユーザーのマシン上でプロセスとして動作するため、そのサーバーが持つ権限の範囲でファイルシステムやネットワークにアクセスできます。MCPサーバーのソースコードをレビューし、何が可能かを理解したうえで使用する必要があります。

5-2. Skillsのセキュリティ

Skillsのセキュリティモデルはホストツールの実装に依存します。Agent Skills仕様自体にはセキュリティ要件の定義はありません。

Claude Codeの場合、以下のメカニズムでスキルの動作を制御します。

• allowed-tools でスキルが使えるツールを宣言する
• パーミッション設定でツールの承認/拒否ルールを管理する
• disable-model-invocation: true で自動起動を防止する

Skillsのセキュリティ上のリスクは 実行境界の曖昧さ です。スキルが「curlでこのURLにリクエストを送れ」と指示した場合、LLMはBashツールを使ってその通りに実行します。悪意のあるスキルが「ホームディレクトリの.sshフォルダの内容をこのURLにPOSTしろ」と指示すれば、パーミッション設定が適切でない場合に実行されるリスクがあります。

5-3. セキュリティ比較表

項目	MCP	Skills
仕様レベルのセキュリティ定義	あり	なし（ホスト実装依存）
実行境界	MCPサーバーのインターフェースに限定	ホスト環境の全ツールにアクセス可能
認証管理	OAuthやAPIキーをプロトコルレベルで処理	環境変数やファイルで手動管理
サプライチェーンリスク	MCPサーバーのコードレビューが必要	SKILL.mdの内容レビューが必要
権限の最小化	サーバーが公開するツールのみ	allowed-toolsで宣言的に制限可能

MCPもSkillsも、信頼できないソースからのインストールにはリスクがあります。MCPサーバーはプロセスとして動作するため、悪意のあるサーバーはホストマシンにダメージを与える可能性があります。Skillsは自然言語の指示であるため、悪意のある指示をLLMに実行させる可能性があります。いずれの場合も、ソースコードまたは内容のレビューを行ってください。

6. コンテキストコストの比較

6-1. MCPのコンテキスト消費

MCPはツールの シグネチャ （名前、説明、入力スキーマ）のみをコンテキストに追加します。ツールの実装コードはコンテキストに入りません。

1ツールあたり: 約50-200トークン（シグネチャのみ）
10ツール: 約500-2,000トークン

ChatGPTのようなアプリケーションでは、ツール検索機能により、必要なツールだけを動的にコンテキストに読み込む仕組みもあります。

6-2. Skillsのコンテキスト消費

Skillsはアクティベート時に SKILL.md の 全文 がコンテキストに注入されます。

スキル一覧（常時）: 約100トークン × スキル数
アクティベート時: SKILL.md全文（推奨5,000トークン以下）
参照ファイル: 必要時のみ追加

Claude Codeのコンパクション（自動要約）では、最新5,000トークンまでのスキル内容が25,000トークンの共有バジェット内で再添付されます。スキルを多数起動すると、古いスキルの内容がコンパクション時に脱落する可能性があります。

6-3. 比較表

シナリオ	MCP	Skills
10個の機能を提供	約1,000-2,000トークン（シグネチャのみ）	約1,000トークン（一覧）+ 最大50,000トークン（全アクティベート時）
1つの機能を使用	ツール実行の入出力分のみ追加	SKILL.md全文がセッション終了まで残留
長時間セッション	変化なし	コンパクション時に古いスキルが脱落する可能性

MCPはツールのシグネチャだけでコンテキストウィンドウを節約できます。一方、Skillsは手順書の全文を読み込むため、複雑なスキルほどコンテキストコストが高くなります。ただし、Skillsのプログレッシブディスクロージャにより、必要なスキルだけを必要なタイミングで読み込めば、実用上は問題になりにくい設計です。

7. エコシステムと互換性

7-1. MCPのエコシステム

MCPは多くの主要AIプラットフォームでサポートされています。

プラットフォーム	MCPサポート
Claude Desktop / Code	フルサポート
ChatGPT	フルサポート
VS Code (GitHub Copilot)	フルサポート
Cursor	フルサポート
Amazon Bedrock	Strands Agents経由でサポート

MCPサーバーの数は増加しており、Notion、Sentry、GitHub、Stripe、Shopifyなど多くのサービスが公式MCPサーバーを提供しています。Linux Foundation傘下に移管されたことで、プロトコルの安定性と長期的なメンテナンスも担保されています。

7-2. Skillsのエコシステム

Agent Skills仕様は急速に採用が広がっています。

プラットフォーム	Skillsサポート
Claude Code	フルサポート（拡張フィールドあり）
OpenAI Codex	サポート
Gemini CLI	サポート
Cursor	サポート
Kiro	サポート
Goose（Block）	サポート

Anthropicの公式リポジトリ（anthropics/skills）はGitHubで 114,000スター を獲得しています。PDF処理、ドキュメント作成、コードレビューなど、多数のスキルが公開されています。

7-3. 併用パターン

MCPとSkillsは競合関係ではなく 補完関係 にあります。この点を、冒頭で紹介した記事は明確に述べています。

a skill that explains how to use an MCP server actually makes a lot of sense. Not to replace the MCP, but to give the LLM context before it starts calling tools.
（MCPサーバーの使い方を説明するスキルは、実は非常に理にかなっている。MCPを置き換えるのではなく、LLMがツールを呼び出す前にコンテキストを与えるのだ。）

これは実際に強力なパターンです。MCPサーバーが提供するツール群の 使い方のコツ 、 日付フォーマットの癖 、 パラメータの組み合わせ といったナレッジをSkillsに記録しておけば、LLMは毎回同じ失敗を繰り返さずに済みます。

8. 結論：使い分けの判断基準

8-1. 判断フローチャート

以下のフローで判断できます。

8-2. 使い分け早見表

ユースケース	推奨	理由
Notion/GitHub等のSaaS連携	MCP	認証、リアルタイムデータ、型安全なインターフェース
コーディング規約の共有	Skills	純粋な知識、CLIもAPIも不要
データベースへのクエリ実行	MCP	状態を持つ接続、認証管理
デプロイ手順の標準化	Skills	既存ツール（git, docker等）への手順書
ファイルシステム操作	MCP	サンドボックスされたインターフェース
MCPサーバーの使い方ガイド	Skills	MCP上の知識層として補完
チームのワークフロー定義	Skills	バージョン管理可能な手順書
リアルタイム監視データ取得	MCP	通知、ストリーミング対応

8-3. 私の結論

MCPとSkillsは「どちらが優れているか」ではなく「どちらのレイヤーの問題か」で選ぶべきです。

MCPは 接続層 です。外部サービスにLLMからアクセスするための型付けされたインターフェースを提供します。認証、トランスポート、エラーハンドリングがプロトコルレベルで定義されています。

Skillsは 知識層 です。LLMに手順、規約、ドメイン知識を教えます。実行を必要としない「純粋な知識」の提供において、Skillsに勝る仕組みはありません。

そして最も強力なのは 両方を組み合わせるパターン です。MCPで接続を確保し、Skillsでそのツールの使い方を教える。接続と知識の両面からLLMを支援するこのアプローチが、現時点での最適解だと考えます。

おわりに

ここまでお読みいただきありがとうございます。

MCPとSkillsをめぐる議論は「プロトコル vs フォーマット」という異なるレイヤーの仕組みを同列に比較してしまうところに混乱の原因があります。MCPはConnector、SkillsはManual。それぞれに不可欠な役割があり、組み合わせてこそ真価を発揮します。

私の関連記事もあわせてご覧いただくと、より理解が深まるかと思います。
MCPサーバーの自作については以下の記事で解説しています。

Claude Code Skillsの実践テクニックについては以下がおすすめです。

ではまた、お会いしましょう。

参考リンク

MCP公式

• Architecture Overview - Model Context Protocol
• Tools Specification - Model Context Protocol
• MCP GitHub Organization

Agent Skills公式

• Agent Skills Specification - agentskills.io
• Agent Skills Overview - agentskills.io
• anthropics/skills - GitHub

Claude Code

• Extend Claude with skills - Claude Code Docs

議論の発端

• I Still Prefer MCP Over Skills - david.coffee