MCP vs Agent Skills論争の本質を整理する：カテゴリエラーに惑わされないために¶

この記事の対象者

MCPとAgent Skillsの違いを整理したいエンジニア
SNSの論争に惑わされず技術選定したい実務者
AIエージェント設計のトレンドをキャッチアップしたい方

はじめに¶

2025年後半、AIエージェント界隈で「MCP vs Agent Skills」という論争が起きている。SNSでは「MCPは不要、Agent Skillsの時代だ」という声が目立ち、一見するとAgent SkillsがMCPを置き換えたかのような議論が展開されている。

しかし、この議論を追っていくと、どうも話が噛み合っていない。本記事では、この論争の本質を整理し、実務者としての見解を述べる。

MCPとAgent Skillsとは何か¶

まず両者の基本を押さえておく。

MCP（Model Context Protocol）¶

Anthropicが2024年11月25日に発表したオープンプロトコル。AIエージェントが外部サービス（Slack、Google Drive、Notion、データベースなど）に接続するための標準インターフェースを提供する。

[Claude] ←→ [MCPクライアント] ←→ [MCPサーバー] ←→ [外部サービス]

要するに「外部接続のための通信規格」である。

Agent Skills¶

2025年10月16日にAnthropicがリリースした機能で、2025年12月18日にはオープンスタンダード（agentskills.io）として公開された。SKILL.mdファイルと関連スクリプトをフォルダにまとめ、Claudeが特定タスクを実行する際のベストプラクティスを提供する。

~/.claude/skills/           # 個人設定
  └── docx/
      └── SKILL.md         # Word文書作成のノウハウ
  └── pptx/
      └── SKILL.md         # PowerPoint作成のノウハウ

.claude/skills/             # プロジェクト設定
  └── custom-task/
      └── SKILL.md

要するに「タスク実行のナレッジベース」である。

論争の構図：なぜ「代替」と言われているのか¶

SNSで見かける「Skills優位派」の主張を整理すると、こうなる。

MCPの主要ユースケースはプライベートデータへのアクセスだった
しかしプライベートデータの価値は限定的で、ウェブ検索で十分なケースが多い
MCPはコンテキスト汚染を引き起こし、実用上の問題が大きい
Agent Skillsの登場でMCPを使う理由がなくなった

一見もっともらしいが、4番目の結論に論理の飛躍がある。

論争の本質：カテゴリエラー¶

MCPとAgent Skillsは、そもそも比較対象として並べるものではない。

観点	MCP	Agent Skills
本質	外部接続のプロトコル仕様	タスク実行のナレッジ集
機能	外部APIを呼び出す	ベストプラクティスを参照する
例えるなら	HTTP/HTTPS	マニュアル・手順書

Slackにメッセージを送りたい、Jiraのチケットを操作したい、社内DBを参照したい——これらの需要に対し、Agent Skillsは"接続の標準プロトコル"を提供するものではない。外部API操作は、ホスト環境のツール（curl/SDK/CLI等）や、別途用意した接続機構に依存する。MCPは外部接続を"統一仕様"として扱えるのに対し、Skillsは"手順・資産の再利用"を提供する、という違いがある。

では、なぜ「代替」という議論が成立しているように見えるのか。

実際に起きていること¶

論争の実態を図示すると、こうなる。

【従来】
MCPでSlack接続 → コンテキスト汚染・設定が面倒

【現在の流れ】
MCPやめる → curlやCLIで直接API叩く → Agent Skillsでその手順を整備

【SNSでの語られ方】
「Agent SkillsがMCPを代替した」

つまり、Skillsが代替しているのではなく、bashやcurlが代替している。Agent Skillsは単にその使い方を教えているだけだ。

本質的な対立軸は「MCP vs Agent Skills」ではなく、「MCPというプロトコル vs 従来手法（CLI/API直叩き）」である。

MCPへの不満の実態¶

MCPが敬遠される理由は「コンテキスト汚染」だけではない。実務上のペインを列挙すると：

設定の煩雑さ: 設定ファイルの管理が面倒（Claude DesktopはJSON、Claude Codeは.mcp.json/~/.claude.json、Codexはconfig.toml等、クライアント依存）
品質のばらつき: 各MCPサーバーの実装品質が一定しない
デバッグの困難さ: 問題発生時の切り分けが難しい
OAuth設定の複雑さ: 認証周りの設定ハードルが高い
過剰なデータ返却: サーバー側が制御なくデータを返し、コンテキストを圧迫

これらは「プロトコルとしての設計・実装の問題」であり、「外部接続という需要が消えた」わけではない。

実務的な棲み分け¶

では、実際にどう使い分けるべきか。

個人開発・小規模プロジェクト¶

MCPは不要なケースが多い。CLI + Agent Skillsで十分。

外部接続が必要なら、curlやCLIで直接叩く
その手順をSkillsとして整備すれば再利用可能
MCPの設定コストに見合うメリットがない

エンタープライズ・チーム開発¶

MCPが有効なケースがある。

監査ログ・権限管理が必要な環境
複数人で同じ接続設定を共有する場合
OAuth認証を組織的に管理する必要がある場合

両方を組み合わせる

MCPを使う場合でも、Agent Skillsでラップしてコンテキスト汚染を制御する工夫は有効。両者は排他的ではなく、組み合わせて使える。

まとめ¶

「MCP vs Agent Skills」論争の本質を整理すると：

両者は代替関係ではない。プロトコル（通信規格）とナレッジ（手順書）という異なるレイヤーの話
実際の対立軸は「MCP vs 従来手法」。Agent Skillsは従来手法を使いやすくしたラッパー
MCPへの不満は設計・実装の問題。外部接続の需要自体は消えていない
ユースケースで棲み分けるのが現実解。個人ならCLI直叩き、エンタープライズならMCPも選択肢

SNSの議論は往々にして「どっちが優れているか」という二項対立に収斂しがちだが、技術選定は常に文脈依存である。自分のユースケースに照らして判断すべきであり、流行りに流される必要はない。