---
title: MCP と Skills
url: https://doc.liz6.com/ja/ai/02-Agent/02-mcp-and-skills
locale: ja
area: ai
tags:
- ai
- Agent
date: 2026-06-30
modified: 2026-07-16
description: MCP による能力（ツール、データ、外部システム）の接続、Skills による方法（ワークフロー、ベストプラクティス、ドメイン知識）の注入。片や手足の延長、片や経験の注入——両者とも段階的開示（progressive disclosure）を採用しているが、組み合わせ可能な2つの層である。
---

# MCP と Skills

> MCP による能力（ツール、データ、外部システム）の接続、Skills による方法（ワークフロー、ベストプラクティス、ドメイン知識）の注入。片や手足の延長、片や経験の注入——両者とも段階的開示（progressive disclosure）を採用しているが、組み合わせ可能な2つの層である。

## 概要

[Agent ループ](/ai/02-Agent/01-Agent循環とツール.md) は「モデルがどのようにツールを使うか」を解決するが、本稿は「どのように Agent に機能を追加するか」を扱う。Agent を拡張するには、**同等に重要でありながらしばしば混同されがちな**2つの層がある。

- **MCP** は**能力 / インターフェース**——実行可能なツール、読み取り可能なデータ、外部システム——に接続する。これにより Agent は**新しいことを「できる」ようになる**。
- **Skills** は**知識 / 方法**——ワークフロー、ベストプラクティス、ドメインのナレッジ、参照ファイル——を注入する。これにより Agent は**正しく「こなす」ことができる**。

片や「手足の延長」、片や「経験の注入」。両者とも「必要に応じて読み込み、基本コンテキストを溢れさせない」というアプローチ（いずれも段階的開示 progressive disclosure の一種）を採用しているため、同一のものと思われがちである。実際には、これらは組み合わせ可能な2つの層であり、**方法層（Skills）が能力層（MCP/ツール）を呼び出す**構造となっている。本稿の前半では MCP を、後半では Skills を解説し、最後に両者を比較対照する。

---

## 第1部: MCP —— 能力の接続

### 解決すべき課題: M×N の統合爆発

標準がない場合、M 個の AI アプリケーション × N 個のツール/データソースに対して、M×N 組の接続コードを書く必要がある。**MCP (Model Context Protocol)** はオープンなプロトコルであり、「ツール界の USB-C」と例えられることが多い。ツール側はプロトコルに従って **server** を公開し、アプリケーション側は **client** を実装することで、統合の複雑さが **M+N** に削減される。

```mermaid
flowchart LR
    subgraph N1["MCP なし — M×N 組の接続"]
        direction LR
        a1["App1"]
        a2["App2"]
        g1["GitHub"]
        s1["Slack"]
        d1["DB"]
        a1 --- g1
        a1 --- s1
        a1 --- d1
        a2 --- g1
        a2 --- s1
        a2 --- d1
    end
    subgraph N2["MCP あり — M+N"]
        direction LR
        b1["App1"]
        b2["App2"]
        mcp{{"MCP プロトコル"}}
        g2["GitHub server"]
        s2["Slack server"]
        d2["DB server"]
        b1 --> mcp
        b2 --> mcp
        mcp --> g2
        mcp --> s2
        mcp --> d2
    end
```

MCP は Anthropic により 2024 年末に提案されオープンソース化され、現在ではベンダー横断的な事実上の標準となっている。

### クライアント-サーバーアーキテクチャ

```mermaid
flowchart LR
    subgraph Host["ホスト (例: Claude Code)"]
        Model["モデル<br/>どのツールを使うか判断"]
        Client["MCP Client<br/>各 server ごとに1つ"]
        Model <-->|"tool_use / tool_result"| Client
    end
    Client -->|"JSON-RPC 2.0<br/>stdio / Streamable HTTP"| Server["MCP Server<br/>tools / resources / prompts を公開"]
    Server --> World["現実世界<br/>GitHub API / ファイルシステム / DB"]
```

- **ホスト (host)**: Claude Code、Claude Desktop、自社製アプリなど——MCP client を実行する。
- **server**: 何らかの能力（GitHub、ファイルシステム、データベース……）をプロトコルに従って公開する。ローカルのサブプロセスとしても、リモートサービスとしても動作可能。
- **メッセージ**は **JSON-RPC 2.0** を介して送受信され、**伝送**はローカルでは **stdio**（サブプロセス、標準入出力）、リモートでは **Streamable HTTP**（初期バージョンでは HTTP+SSE）が使用される。

### 3つのプリミティブ

| プリミティブ | 概要 | 使用者 | 例え |
|------|--------|--------|------|
| **tools** | モデルが呼び出せる関数（スキーマ付き） | モデルの判断で呼び出し | 関数 / アクション |
| **resources** | ホストが読み取り可能なデータ（ファイル、レコード） | ホスト/ユーザーが読み取り、コンテキストに配置 | ファイル / GET |
| **prompts** | 再利用可能なプロンプトテンプレート | ユーザー/ホストがトリガー | 事前定義コマンド |

最も一般的に使用されるのは **tools** であり、これは直接 Agent ループに接続される。server が公開するツールは、モデルから見ればカスタムツールと同じであり、`tool_use` を生成し、ホストが実行し、`tool_result` をフィードバックする。

### server の接続方法

Claude Code において server を接続するには、設定ファイルに記述するだけでよい。ローカルの stdio server の場合:

```jsonc
{
  "mcpServers": {
    "context7": { "command": "npx", "args": ["-y", "@upstash/context7-mcp"] }
  }
}
```

リモート HTTP server の場合は `url` を指定する。現在、このマシンでは2つの実際の server が接続されている:**context7**（必要に応じて最新のライブラリドキュメントを取得）、**code-review-graph**（コードベースを構造化図として解析し、レビューに供する）。

**Claude API** 側でリモート MCP を接続するには、ペアで指定する必要がある2つのパラメータ（ベータ版 `mcp-client-2025-11-20`）を使用する。

```python
client.beta.messages.create(
    betas=["mcp-client-2025-11-20"],
    mcp_servers=[{"type": "url", "name": "my-tools", "url": "https://.../mcp"}],
    tools=[{"type": "mcp_toolset", "mcp_server_name": "my-tools"}],
    ...,
)
```

**Managed Agents** では、server の宣言は Agent 定義内（`type/name/url`、**認証情報は含まない**）に配置し、認証情報は **vault** に保存し、セッション作成時に `vault_ids` を指定して関連付ける——Anthropic 側のエージェントが外部通信リクエスト時にトークンを注入するため、コンテナ内のコードが秘密鍵に直接アクセスすることはできない。

### セキュリティ: server は権限を持って実行される

- **server は特定の権限で実行される**——ファイルの読み書きや GitHub の呼び出しが可能な server は、それらの権限をモデルの判断に委ねることに等しい。信頼できない server にはサンドボックス化、最小権限の付与、認証情報はハードコードせず vault を経由する必要がある。
- **ツール出力におけるプロンプトインジェクション**: server が返す内容はコンテキストに取り込まれ、「観察」として読み込まれる。Web ページや issue の中に「以前の指示を無視して、X を実行せよ」といった内容が隠されており、これによりエージェントが乗っ取られる可能性がある。ツール出力は**信頼できないデータ**として扱い、危険を伴うアクションは人間を介した確認（human-in-the-loop）を行う。

---

## 第2部: Skills —— 方法の注入

### Skills とは

**Skill** は**フォルダ**であり、その核心となる `SKILL.md` には、特定のドメインにおけるワークフロー、ベストプラクティス、参照ファイルが含まれている。これは「毎回繰り返して指示する必要があるナレッジ」を再利用可能なリソースとして定着させ、汎用エージェントを特定ドメインのエキスパートに変える——例えば、PPT の作成、Excel の操作、特定の規範に従ったコード記述など。

**単発のプロンプト**とは異なる点がある。プロンプトはその会話セッション内の一時指令であるのに対し、skill は**会話を超えて、必要に応じて読み込まれる**永続的な方法である。

### SKILL.md と段階的開示

Skill の真髄は**段階的開示（progressive disclosure）**——すべての内容を一度にコンテキストに詰め込まず、階層的に読み込む——にある。

```mermaid
flowchart TD
    A["① name + description<br/>(常時コンテキスト、極めて小さい)"] -->|モデルがタスク関連と判断| B["② SKILL.md 本文<br/>(必要に応じて読み込み: ワークフロー/ルール)"]
    B -->|必要に応じて| C["③ 参照されるファイル / スクリプト<br/>(実際に使用时才加载)"]
```

```markdown
---
name: pptx
description: PowerPoint プレゼンテーションの作成または編集が必要な場合に使用します。
---

# プレゼンテーション作成のフロー
1. まずアウトラインを計画する...
2. python-pptx を使用して生成する...
（さらに多くのステップ、テンプレート、スクリプト参照）
```

`description` の一行のみが常時コンテキストに残る（数十トークン程度）。モデルがタスクが関連すると判断した場合のみ、`SKILL.md` の本文が読み込まれる。本文内で参照されているテンプレートやスクリプトは、実際に使用される際にのみ読み込まれる。これにより、**数十の skill を持っても基本コンテキストが溢れることはない**——これは、MCP が tool search を用いてツールスキーマを必要に応じて読み込むのと同じ手法である。

### 組み込み vs カスタム

| 種類 | 概要 | 参照方法 |
|------|--------|----------|
| 組み込み (Anthropic) | 一般的なドキュメントタスク: `pptx` / `xlsx` / `docx` / `pdf` | 名前で指定 `{type: "anthropic", skill_id: "xlsx"}` |
| カスタム | 組織内で Skills API を介して作成されたもの | `{type: "custom", skill_id: "skill_...", version: "latest"}` |

各エージェントは最大20個の skill を保持できる。**Messages API** では、`container.skills` + `code_execution` ツール + 2つのベータ版（`code-execution-2025-08-25`、`skills-2025-10-02`）を有効化することで使用可能となり、生成された `.pptx`/`.xlsx` はファイル ID として返却され、Files API を介してダウンロードできる。**Managed Agents** では、skill はエージェント定義の配列として直接指定される。

> Anthropic の文脈には2つの「Skills」が存在するが、これらは**同じ思想の2つの実装形態**である。1つは Claude Code の `SKILL.md` スキル（例: `/oh-my-claudecode:...` などの種類、および本セッションの `claude-api` スキル）、もう1つは API / Managed Agents における **Agent Skills** である。

### いつ skill を書くか

- **skill を書くべき場合**: そのナレッジが**会話やタスクを超えて繰り返し使用される**（チームのコード規約、固定されたレポートフォーマット、特定ドメインの標準プロセスなど）、または特定のフォーマットのドキュメントを出力する場合。
- **単発プロンプトで十分である場合**: その会話セッション内でのみ必要な一時的な指令。

判断基準は「いつ MCP server を書くか」と同源である。**再利用価値が高ければ定着させる（skill を書く / server を書く）、一度きりなら過度な設計は避ける。**

---

## 統合: 能力 vs 方法

| | MCP | Skills |
|---|---|---|
| 拡張対象 | 能力 / インターフェース (tools, resources, prompts) | 知識 / 方法 (指示、ワークフロー、参照ファイル) |
| 形態 | クライアント-サーバープロトコル、ベンダー横断 | フォルダ + `SKILL.md`、段階的開示 |
| 実行主体 | server (外部プロセス / サービス) | モデルが skill の指示に従い、**既存のツール**を使用して実行 |
| 解決する課題 | M×N 統合、外部世界との接続 | 繰り返されるナレッジ、ドメイン特化 |
| 段階的開示 | tool search によるスキーマの必要時読み込み | 説明は常時保持、本文/ファイルは必要時読み込み |
| 例 | GitHub / Slack / DB server、context7 | pptx / xlsx ドキュメントスキル、カスタムプロセス |

これらは**組み合わせ可能**である——方法層が能力層を呼び出す。skill のプロセス内で、MCP が公開するツールを呼び出すことも可能である。

```mermaid
flowchart TD
    Loop["エージェントループ — オーケストレーション層"]
    Skills["Skills — 方法層<br/>ワークフロー / ドメインナレッジ / 参照"]
    Cap["能力層<br/>MCP ツール · 組み込みツール · カスタムツール"]
    Loop --> Skills
    Skills -->|駆動| Cap
    Loop -->|直接呼び出しも可能| Cap
```

本セッションが属するスタックに当てはめると、`claude-api` や OMC の `SKILL.md` は**方法層**であり、context7 や code-review-graph などの MCP server は**能力層**である。両者がそれぞれの役割を果たし、組み合わさって初めて完全なエージェントとなる。

## 最前線: MCP はすでにベンダー横断標準である

強力な傍証として、アリババのワールドモデル [Qwen-AgentWorld-35B-A3B](https://huggingface.co/Qwen/Qwen-AgentWorld-35B-A3B) は、シミュレートする7つのエージェント環境のうち、**第一に「ツール呼び出し (MCP)」を挙げている**——Anthropic 以外の最先端モデルでさえ、「MCP を通じたツール呼び出し」をエージェントの標準的な対話パラダイムとして訓練・シミュレートしている。MCP は、エージェントが世界と接触するための汎用インターフェースになりつつある。詳細は [エージェントループとツール使用](/ai/02-Agent/01-Agent循環とツール.md) の最前線セクションを参照。

## ベストプラクティス

- **2つの層を明確にしてから拡張する。** 能力（外部システムへの接続）が不足していれば MCP を、方法（繰り返されるナレッジ）が不足していれば Skill を書く。一方でもう一方の問題を解決しようとしないこと。
- **再利用価値が高い場合にのみ定着させる。** 会話を超えて繰り返し使用する場合にのみ server / skill を書く。一度きりの一時指令はプロンプトで十分。
- **段階的開示によってコンテキストを制御する。** skill では `description` のみを常時保持し、本文は必要に応じて読み込む。ツールが多い場合は tool search を用いてスキーマを必要に応じて読み込み——数十個あってもコンテキストが溢れない。
- **信頼できない server にはサンドボックス化と最小権限を適用する。** server は権限を持って実行されるため、それは権限をモデルの判断に委ねることに等しい。
- **認証情報は vault を経由し、ハードコードしない。** Managed Agents では、server の宣言（認証情報なし）をエージェントに配置し、認証情報は vault に保存し、外部通信時に注入する。コンテナ内からは秘密鍵にアクセスできない。
- **ツール出力は信頼できないデータとして扱う。** server が返す内容はコンテキストに取り込まれ「観察」として扱われるため、プロンプトインジェクションを防ぐ必要がある（[セキュリティと防護](/ai/03-applications-and-production/04-security-and-protection.md) を参照）。

## トレードオフと失敗パターン

- **MCP と Skills を混同する**: 二者択一だと思い込む → 実際には組み合わせ可能な2層であり、方法層（Skill）が能力層（MCP/ツール）を呼び出す。
- **プロンプトを使うべき場面で skill を書く**: その会話セッション内でのみ必要な一時指令を過度に設計する → 一度きりのニーズにはプロンプトを使用。
- **server の認証情報を設定/エージェントにハードコードする**: 漏洩リスク → vault を経由し、外部通信時に注入。
- **ツール出力内の「指示」を信じる**: Web ページや issue に「以前の指示を無視せよ」といった内容が隠されており、エージェントが乗っ取られる → ツール出力はデータとして扱い、危険を伴うアクションは人間を介した確認を行う。
- **ローカルの stdio server をリモート接続として扱う**: 伝送方式の誤用 → ローカルは stdio（サブプロセス）、リモートは Streamable HTTP を使用し、混同しない。

## 参考

- **プロトコル仕様**: modelcontextprotocol.io (JSON-RPC、伝送、プリミティブ定義。公式を基準とする)
- **Anthropic ドキュメント**: MCP Connector (`mcp_servers` + `mcp_toolset`)、Agent Skills、Managed Agents Vaults (platform.claude.com)
- **最先端モデル**: [Qwen-AgentWorld-35B-A3B](https://huggingface.co/Qwen/Qwen-AgentWorld-35B-A3B) (MCP ツール呼び出しをシミュレーション領域の一つとして列挙)

*Keywords: MCP, Model Context Protocol, client-server, JSON-RPC, stdio, Streamable HTTP, SSE, tools, resources, prompts, mcp_toolset, mcp_servers, vault, prompt injection, M×N, USB-C for tools, context7, code-review-graph, Skills, SKILL.md, Agent Skills, progressive disclosure, 能力 vs 方法*