MCP vs Skills：AIエージェントの「手足」と「脳」、なぜ今分離すべきなのか？
MCP vs Skills：AIエージェントの「手足」と「脳」、なぜ今分離すべきなのか？
AIエージェントにツールを繋ぎ込んだとき、思ったより不安定で戸惑った経験はないだろうか。
意図しないツール呼び出しが起きたり、同じ処理をループしたり、期待した応答が返ってこなかったり。
裏側はどちらもFunction Callのはずなのに、なぜうまく使いこなせないのか？
自分の場合、ツール群（MCP）と実行ロジック（Skills）を分けて整理したところ、挙動がかなり安定するようになった。最近はコミュニティのフレームワークでも、この「能力と戦略の分離」を設計原則に据えるものが出てきている。
この記事では、MCPとSkillsがそれぞれ何を解決するのかを整理する。
先に結論だけ言うと、MCPはAIの「何ができるか」を決め、Skillsは「どうやるか」を決める。
クイックリファレンス：MCPとSkillsの違い
| 項目 | MCP (Model Context Protocol) | Skills (スキル) |
|---|---|---|
| 役割 | ツール・リソース・プロンプトの接続を標準化するプロトコル | タスク実行のベストプラクティスを構造化した手順書 |
| 解決する課題 | 相互運用性——AIに統一された「手」と「目」を渡す | 実行ロジック——AIに「脳」の思考プロセスを与える |
| 実体 | JSON-RPC 2.0ベースのサーバープログラム | 構造化されたPromptテキストや設定ファイル |
| 開発で書くもの | ツールのロジックやリソース提供を包むコード | トリガー条件・手順・Few-Shotなどの文書 |
| なかったらどうなるか | モデルが砂場に閉じ込められ、外の世界に触れない | 武器だけ持たされて、振り回すだけの新人になる |
1. 共通の土台：Function Call
違いを語る前に、共通点を押さえておく。
MCPとSkillsは、いずれも**Function Call（関数呼び出し）**という仕組みの上に成り立っている。
もともと「次の単語を予測する」だけだったLLMが、Function Callによって外の世界に手を伸ばせるようになった。仕組みはこうだ：
- 開発者が「呼び出せる関数」の定義（名前・説明・引数の型）をJSONスキーマでモデルに渡す
- ユーザーの入力に対し、モデルが「この関数をこの引数で呼ぶべき」と判断し、構造化JSONを出力する
- アプリケーション側がそのJSONを受け取り、実際の関数を実行する（モデル自身が実行するわけではない）
- 実行結果をモデルに返し、モデルがそれをもとに最終回答を生成する
カレンダーの確認、メール送信、ファイル読み込み……すべてこの流れで動いている。
MCPはこのFunction Callを標準プロトコルに昇華したもの。Skillsは、Function Call経由で呼ばれるツール群をどう組み合わせるかを定義するもの。関わり方は違うが、根っこは同じ技術基盤に立っている。
2. MCPとは何か：AI接続の「USB規格」
MCP（Model Context Protocol） を一言で言えば、「AI向け外部接続の標準化プロトコル」。
これまで、ClaudeやChatGPT、ローカルのOSSモデルにツールを繋ぐたびに、それぞれ専用のアダプターを書いていた。モデルを乗り換えるとツール側も書き直しになる。地味に手間がかかる作業だった。
MCPはこの車輪の再発明を終わらせるために生まれた。PCのUSB規格をイメージするとわかりやすい。MCP仕様に沿ってServerを一つ作れば、対応するAIクライアントならどれでもプラグアンドプレイで接続できる。
MCPが提供する3つのプリミティブ
MCPは単なる「ツール接続」だけではない。仕様上、以下の3種類のプリミティブが定義されている：
| プリミティブ | 役割 | 制御主体 |
|---|---|---|
| Tools | 実行可能な関数（API呼び出し、DB検索、ファイル操作など） | モデルが判断して呼び出す |
| Resources | 読み取り専用のデータソース（設定ファイル、ログ、ドキュメントなど） | アプリケーション側が注入する |
| Prompts | 再利用可能なプロンプトテンプレート | ユーザーが選択・トリガーする |
通信にはJSON-RPC 2.0が使われ、ローカル接続（stdio）とリモート接続（Streamable HTTP + OAuth 2.1）の両方に対応している。
具体例：
AIにGitHubのIssue一覧を読ませたい場合。GitHub MCP Serverを開発して、Issue取得をToolとして、リポジトリ情報をResourceとして公開する。Agentの基盤をどう入れ替えても、このServerはそのまま使い回せる。
つまり、MCPは「AIが外部世界と繋がるための標準インターフェース」。
3. Skillsとは何か：ベテランの「作業手順書」
MCPで接続先は揃った。でも、それだけでは足りない。
初心者に最高級のメスを渡しても、手術はできないのと同じ話だ。
ここで登場するのがSkills。
本質は、構造化された高度なPrompt文書——人間がそのタスクで培ったベストプラクティスを、再利用できる形に落とし込んだSOP（標準作業手順書）と言える。
ちゃんと作り込まれたSkillは「記事を書いて」みたいな一言では終わらない。こういう要素が定義されている：
- トリガー条件：どんな状況でこのスキルを発動するか
- 実行ステップ：データ分析 → 資料収集 → 草稿作成、のような具体的な流れ
- 出力フォーマット：Markdown、JSON、特定のコード規約など
- エラー時の対処：MCPツールの呼び出しが失敗したときのリトライ方法や代替手段
- Few-Shot：正例と反例を示して、モデルの暴走を防ぐ
Skillsはそれ自体がFunction Callを呼ぶわけではない。あくまで「どのツールを、どんな順番で、どんな条件で使うか」をモデルに伝えるための設計書だ。実際の実行は、モデルがSkillsのガイドに従ってFunction Call経由でMCPツールを呼び出すことで行われる。
以前、エラー処理をSkillに定義し忘れたことがある。結果、Agentが空のDBテーブルを何度も繰り返し検索してしまい、無駄なAPI呼び出しが発生した。境界条件をSkillに追加してからは、同じ問題は起きていない。
4. 協調関係：部品と組み立て図
Agent設計でMCPとSkillsをごちゃ混ぜにすると、コードが一瞬でスパゲッティになる。
この二つは上下の関係にある：
- MCPは能力層（部品）——標準化されたツール・リソース・プロンプトテンプレートの提供。AIに「何ができるか」を与える。
- Skillsは戦略層（組み立て図）——それらの部品をどう組み合わせて目的を達成するかの設計書。AIに「どうやるか」を教える。
たとえば一つのSkillの中で、「ファイル読み込みMCP（Resource）」で情報を取得し、「Web検索MCP（Tool）」で補足調査し、「メール送信MCP（Tool）」で結果を報告する——といった一連のワークフローを定義できる。
分離しておく最大のメリットは、部品の追加（新しいMCP Serverの開発）と設計書の改善（Skills Promptの修正）を独立して進められること。片方をいじっても、もう片方には影響しない。
まとめ
Promptだけでシステム連携を解決しようとしないこと。逆に、業務判断をハードコードで済ませようとしないこと。
- 基盤側を担当しているなら：MCPに寄せる。ファイルシステム、DB、外部APIを標準的なMCP Serverとして公開し、Tools / Resources / Promptsを適切に分類する。
- 業務ロジック側を担当しているなら：Skillsを磨く。頭の中の「仕事の進め方」を構造化して、AIが迷わない実行ガイドに落とし込む。
あなたのAgentは今、ツール層と戦略層を分けているだろうか？ それとも全部一枚岩？ 使い分けの基準があれば、ぜひコメント欄で聞かせてほしい。