MCP と Skills

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

概要

Agent ループ は「モデルがどのようにツールを使うか」を解決するが、本稿は「どのように 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 に削減される。

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 年末に提案されオープンソース化され、現在ではベンダー横断的な事実上の標準となっている。

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

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 であり、これは直接 Agent ループに接続される。server が公開するツールは、モデルから見ればカスタムツールと同じであり、tool_use を生成し、ホストが実行し、tool_result をフィードバックする。

server の接続方法

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

{
  "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）を使用する。

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）——すべての内容を一度にコンテキストに詰め込まず、階層的に読み込む——にある。

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

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

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

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

組み込み vs カスタム

各エージェントは最大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 方法

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

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 は、シミュレートする7つのエージェント環境のうち、⁠第一に「ツール呼び出し (MCP)」を挙げている⁠——Anthropic 以外の最先端モデルでさえ、「MCP を通じたツール呼び出し」をエージェントの標準的な対話パラダイムとして訓練・シミュレートしている。MCP は、エージェントが世界と接触するための汎用インターフェースになりつつある。詳細は エージェントループとツール使用 の最前線セクションを参照。

ベストプラクティス

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

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

• 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 (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 方法