MCPサーバーとAgent Skills。
この2つを「どちらが優れているか」と比較する議論をよく見かけます。
でも実際はそうじゃないんですよね。
両者はそもそもスタックの異なるレイヤーに位置しています。
つまり、比較すること自体がズレているのです。
Redditでもこのテーマについて議論が盛り上がっていたので、その内容を整理しながら考えてみましょう。
MCPサーバーの役割は「接続」
MCPサーバーが担うのは、エージェントと外部システムをつなぐことです。
API、データベース、各種サービスに対して、標準化されたインターフェースでアクセスする仕組みを提供してくれます。
いわば「工具箱」のようなもの。
ドリルやレンチといった道具がそろっている状態です。
ただし、工具箱があるだけでは家具は組み立てられません。
MCPの仕様には、3つのプリミティブが定義されています。
- ツール（実行可能な関数）
- リソース（コンテキスト情報を提供するデータソース）
- プロンプト（やり取りを構造化するテンプレート）
エージェントはこれらを通じて外部システムとやり取りを行います。
Agent Skillsの役割は「案内」
一方、Agent Skillsはエージェントに「どう振る舞うべきか」を伝える仕組みです。
ワークフローや利用パターン、注意点などを構造化された形で記述します。
そうすることで、エージェントが適切にツールを使えるよう導くわけです。
工具箱の比喩で言えば、Agent Skillsは「組立説明書」にあたります。
「この種類のネジにはアーレンレンチを使う」「この部品はこの順序で取り付ける」といった指示が書かれた文書です。
Claude Codeの環境では、CLAUDE.mdファイルがまさにこの役割を果たしています。
ある開発者はPDF操作用のMCPサーバーを構築したそうです。
しかし、ツールの使い分けや注意すべき落とし穴、操作の連鎖方法についてはCLAUDE.mdに記述していたとのこと。
Skillsレイヤーがなければ、エージェントはツールにアクセスできても判断の質が落ちてしまいます。
「代替関係」ではなく「補完関係」
両者の違いを整理してみましょう。
MCPサーバーは、エージェントがシステムに「接続」する手段を提供します。
そしてAgent Skillsは、そのシステムを「正しく使う」ための知識を提供するもの。
レイヤーが違うのだから、どちらが優れているかという問いは成立しません。
実際にWeaviateのAgent Skillsを使った事例を紹介しましょう。
セマンティック映画検索アプリの構築において、ベクトル検索やRAGロジックを手動で組み立てる必要がなかったと報告されています。
Skillsがデータベースとのやり取り方法やクエリの生成方法をあらかじめ教えてくれるため、エージェントは迷わず作業を進められたのでしょう。
もちろん、反論もあります。
MCPのツール記述が十分に詳細であれば、Skillsは不要ではないか、という意見です。
確かに一理あるでしょう。
ツールの説明文がしっかり書かれていれば、エージェントは個々のツールを正しく使えるかもしれません。
ただし、複数のツールをどう組み合わせるか。
どんな手順で実行するか。
こうした「手続き的な知識」は、ツール記述だけではカバーしきれない場面が多いのも事実です。
まだ解決されていない課題もある
この議論には、さらに深い論点も存在します。
一つはディスカバリーの問題です。
MCPサーバーが5台なら、手動で設定ファイルを管理できるでしょう。
でも50台、500台になったらどうか。
エージェントが「このタスクにはどのMCPサーバーが使えるのか」を自動で見つける仕組みは、まだ標準化されていません。
A2Aプロトコルやagents.txtといった取り組みが始まってはいるものの、本格的な解決には至っていない状況です。
もう一つは権限管理の問題。
接続できて、使い方もわかった。
では、このエージェントは実際に何を触っていいのか？
本番環境では「アクセス」と「ガイダンス」だけでは不十分です。
「パーミッション」のレイヤーが求められます。
この点について、クリーンな回答を持っているチームはほとんどないでしょう。
まとめ
MCPサーバーとAgent Skillsは対立する概念ではありません。
異なるレイヤーで異なる役割を果たす、補完的な存在です。
実用的なエージェントスタックを構築するなら、どちらか一方を選ぶのではなく、両方を組み合わせることになるはず。
そして、ディスカバリーや権限管理といった未解決の課題にも目を向ける必要があります。
エージェント技術はまだ発展途上です。
こうした議論を深めていくことが、より堅牢なシステムの構築につながっていくのではないでしょうか。
