MCPの時代は終わった？――Skillsにコンパイル時代のツール統合設計¶

この記事の対象者

MCPとSkillsの違いを整理したいエンジニア
エージェント設計でトークン効率を改善したい実務者
「MCPは時代遅れ」という言説の実態を知りたい方

この記事のポイント¶

「MCPは時代遅れ」という言い回しが、実際には何を指しているのか
Skills（SKILL.mdベース）の考え方と、MCPとの違い
コンテキスト消費がどこで発生するのかの分解
結局どちらを採用すべきかの判断基準

まず結論：「MCPが時代遅れ」ではなく、運用パターンが問題視されている¶

最初に言い切っておきます。

MCPというプロトコル自体が古いわけではありません。批判の対象になっているのは、「MCPサーバーを巨大なAPI辞書として公開し、LLMに探索させながら低レベル操作を繰り返させる」という運用パターンです。

つまり論点は「MCPを使うかどうか」ではなく、「どう使うか」です。

用語の確認¶

本題に入る前に、この記事で使う用語を簡単に整理しておきます。

用語	意味
MCP（Model Context Protocol）	LLMが外部ツールを呼び出すための共通インターフェース
コンテキスト	LLMが一度に処理できる情報の範囲（会話履歴＋指示＋データ）
トークン	LLMが扱うテキストの単位。日本語だと1文字≒1〜2トークン程度
Skills	作業手順をパッケージ化してエージェントに渡す仕組み（Anthropicが提唱）

MCPの基本：LLMが外部ツールを呼び出す仕組み¶

MCPは、LLMが外部ツールを呼び出すときの「共通の作法」を整えるプロトコルです。

クライアント（IDEやチャットUI）がMCPサーバーに接続
サーバーが提供するツール（関数）をLLMが呼び出す
結果がLLMに返され、会話に反映される

ここまではシンプルです。問題になるのは次の部分です。

MCPの全体像を把握したい方へ

MCPの構造やユースケースの全体像は「MCP完全理解ダッシュボード」でまとめています。

「MCPでコンテキストが溶ける」とは何が起きているのか¶

「コンテキストが溶ける」という表現がよく使われますが、トークン消費には2種類あります。この区別が重要です。

探索トークン（ツール選択・手順探索）¶

LLMが「どのツールを使うか」「引数は何か」を探す過程で消費されるトークンです。

どのAPIを使えばいい？
引数の形式は？
失敗した、別の方法は？

この「やり方を探す会話」が積み上がると、コンテキストを圧迫します。

実データトークン（処理対象のデータ量）¶

実際に取得したデータ（Slackのログ、ドキュメントの内容など）が消費するトークンです。

これはMCPでもSkillsでも、データ量が多ければ必ず発生します。

ポイント

「MCPは重い」と言われるとき、主に問題になっているのは探索トークンです。

Slack連携の例：MCPで何が起きがちか¶

具体例として「特定のSlackスレッドを集めて議事録化したい」というケースを考えます。

MCPサーバーがSlackの低レベルAPIを多数公開している場合、LLMは以下のような探索をしがちです。

スレッドの特定方法を探す（検索？履歴？URL指定？）
候補から絞り込む方法を探す
取得APIで本文を抜く
レート制限や権限エラーで失敗 → 別ルートを探索
取れたログを整形して議事録化

この「探索＋試行錯誤」が探索トークンを押し上げます。

Skillsとは何か：作業単位のパッケージング¶

Skillsは、作業手順をあらかじめまとめてエージェントに渡す考え方です。

構成要素は以下のとおりです。

SKILL.md：手順・ルール・入力仕様を記述したファイル
スクリプト：定型処理を自動化するコード
関連リソース：テンプレートや設定ファイル

Skillsのポイントは、LLMに見せる「探索対象」を狭めることです。

SlackのAPI全体を見せるのではなく、「議事録化」という作業の入口だけを渡す。これにより探索トークンが減ります。

Skills関連リソース

Skillsは万能ではない¶

ただし、Skillsを入れれば探索がゼロになるわけではありません。

LLMは結局SKILL.mdを読んで判断します。SKILL.mdが曖昧だったり、想定外の入力が来たりすると、探索は発生します。

Skillsが効果を発揮するのは以下の条件が揃うときです。

作業が定型化できる
入力仕様が明確
例外処理が限定的

なお、Anthropicの公式ガイドラインでは、SKILL.mdの本文を500行以下に抑えることが推奨されています。Skillsにもコンテキスト管理の制約はあります。

MCPとSkillsは併用できる¶

ここまで対比的に説明してきましたが、MCPとSkillsは二者択一ではありません。

Anthropicの公式見解では、MCPがLLMを外部サービスに接続し、Skillsがツールの効果的な使用方法を教えるという役割分担で、両方を組み合わせて使うことが想定されています。

たとえば、NotionのMCPサーバーで接続を確立しつつ、Notion用のSkillsでデータの扱い方をLLMに教える、という構成が可能です。

MCPが有意になる条件¶

では、MCPはどういう場面で有効なのか。トークン以外の要素が支配的になるケースです。

統制を一箇所に寄せたいとき¶

監査ログ、権限管理、レート制限などをサーバー側で一元管理できます。MCPアーキテクチャはセキュリティと制御されたアクセスを重視しており、組織がAIアシスタントの接続先を厳密に管理できる設計になっています。

複数のクライアントで同じ統合を共有したいとき¶

IDEエージェント、チャットUI、バッチ処理、他チームのボットが同じ接続・権限モデルを使えます。

探索自体に価値があるとき¶

「毎回問いの形が違う」「横断検索が目的」といったケースでは、Skillsに固定するとかえって柔軟性を失います。

PoC段階で変化が大きいとき¶

要件が固まっていない段階でSkillsを作り込むと、手戻りが大きくなります。

MCPの集約にはトレードオフがある¶

MCPサーバーに統合を集約すると統制点が1つになりますが、以下のリスクも伴います。

サーバー障害で全エージェントが影響を受ける
API更新が全クライアントに波及する
サーバー管理者がボトルネックになる

一方、Skills分散にも「スキルの散在・重複」「監査の困難さ」「属人化」といった課題があります。

集中と分散のトレードオフであり、どちらが正解というわけではありません。

実装パターンの詳細

MCPサーバーの具体的な実装パターンについては「MCP Server実装パターン」を参照してください。

判断基準：チェックリスト¶

Skills優先になりやすいケース¶

同型の作業を週1回以上の頻度で回す
仕様が安定している
失敗コストが高く、再現性が必要
ローカルやCIで完結できる

MCP優先になりやすいケース¶

問いの形が毎回違う（探索に価値がある）
複数チーム・複数クライアントで共有したい
監査・権限・秘匿を一箇所で統制したい
PoC段階で要件が流動的

まとめ¶

「MCPは時代遅れ」という言い回しの正体は、プロトコルへの批判ではなく、運用パターンへの批判です。

MCPは「繋ぐ・共有する・統制する」方向に強い
Skillsは「繰り返しを固定化し、探索を減らす」方向に強い
両者は併用可能であり、目的に応じて組み合わせる

どちらを採用するかは、トークン効率だけでなく、統制・共有・変化への耐性といった要素を含めて判断する必要があります。

補足：Code Execution with MCPについて¶

この記事では触れませんでしたが、Anthropicは2025年にMCPとコード実行を組み合わせる新しいパターンを提唱しています。

これは、エージェントがMCPサーバーをコードAPIとして扱い、ツールをオンデマンドで読み込み、データを実行環境内で処理してからモデルに返す方式です。公式の検証では、15万トークンから2,000トークンへの削減（98.7%減）を実現した例も報告されています。

多数のMCPサーバー（10以上）を扱う複雑なワークフローや、大量の中間データを処理するケースでは、この方式が有効です。

詳細はAnthropicのエンジニアリングブログ「Code Execution with MCP」を参照してください。