「スキルが出てきたから、MCPはもう要らない」。この言い方は半分だけ正しくて、実装の現場では役に立ちません。先に結論を言うと、MCPサーバーとスキルはどちらかが勝つ関係ではなく、置き場所が違う道具です。判断軸は新しさでも流行でもなく、「破られたら事故になる境界か、日々変えたい手順か」。境界はMCPサーバーへ、手順はスキルへ。私は両方を毎日動かした結果、この分け方に落ち着きました。
対象読者は、エージェントに新しい能力を足すとき「MCPサーバーを立てるべきか、SKILL.mdを書くべきか」で手が止まった人です。素材はGitHub公式ブログが2026年9月に出した「skillsはMCPを殺したのか」という一次情報と、自作MCPサーバー（ツール55本）とスキル13個を同じリポジトリで併用している自分の運用です。
「スキルがMCPを殺した」論はどこから来たか
スキル（Agent Skills）は、手順や知識をMarkdownファイルにまとめてエージェントに読ませる仕組みです。仕様も実装も軽く、MCPサーバーを立てるより圧倒的に手軽なので、「ツール連携もスキルで書けばよいのでは」という声が出てくるのは自然な流れでした。
この問いにGitHub公式ブログが2026年9月18日の記事で正面から答えています。
GitHub公式ブログ: Should you read the code? Is RAG dead? And did skills kill MCP?We dive into these questions and other AI hot takes on the latest episode of the GitHub Podcast.github.blog
記事の整理はシンプルです。MCPは「ツールとデータへ接続するための標準的な方法（a standard way to connect to tools and data）」、スキルは「パッケージ化された専門知（packaged expertise）」。そして結論はこう書かれています。
Use standards for shared interfaces. Use skills for context, process, and best practices.
共有されるインターフェースには標準（＝MCP）を、文脈・手順・ベストプラクティスにはスキルを使う。置き換えではなく補完関係だ、という整理です。
方向性としてはこの通りだと思います。ただ、この一文だけでは現場で手が止まります。困るのは、**大抵の機能はどちらでも実装「できてしまう」**からです。SNSに投稿する機能を例にすると、MCPサーバーのツールとして生やすこともできるし、「このAPIをcurlでこう叩く」というスキルを書くこともできる。できる・できないでは決まらないので、別の軸が要ります。
形の違いを先に並べる
判断の前に、2つの形が何者かを整理しておきます。
| 観点 | MCPサーバー | スキル |
|---|---|---|
| 実体 | 独立して動くサーバー（プロセス） | Markdownファイル（SKILL.md） |
| エージェントとの関係 | プロトコル経由でツールを呼び出す | 手順書としてコンテキストに読み込む |
| 制約の強制力 | サーバー側で検証・拒否できる | 従うかどうかは最終的にモデル次第 |
| 配布範囲 | MCP対応クライアントすべてから使える | 置いたリポジトリ・環境で使える |
| 変更コスト | 実装・テスト・デプロイ | ファイルを編集してコミット |
仕様の一次情報はMCP公式サイトとClaude Codeのスキル公式ドキュメントにあります。
この表で一番効くのが3行目の強制力です。MCPサーバーはツール呼び出しを受ける側にコードがあるので、入力を検証して不正なら拒否できます。スキルは精巧な指示ですが、指示である以上、守られない可能性が構造的に残ります。ここが使い分けの本線になります。
自分の運用ではこう分けている
私はSNS運用と記事公開をエージェントに任せる仕組みを動かしていて、同じリポジトリの中にMCPサーバーとスキルが同居しています。
**MCPサーバー側（自作のCloudflare Workers、ツール55本）**に置いたのは、外部への公開操作です。ThreadsやInstagramへの投稿、この記事のような記事公開は、すべて自作MCPサーバーのツール経由でしか実行できません。サーバー側には確認フラグの必須化と、KVを使った公開回数の上限（時間あたり・日次）を実装してあり、エージェントがどんな指示を受けていようと上限を超える公開はサーバーが拒否します。認証トークンもWorkerの中にだけ置き、エージェント側の環境には渡しません。作り方は別記事にまとめてあります。
MCPサーバーの自作入門｜Cloudflare Workersで作って本番運用するまで自作MCPサーバーをCloudflare Workersで動かす手順を、実運用中のコードで解説します。公式TypeScript SDKでの最小構成、入力スキーマ・Bearer認証・confirm必須・KVの回数制限という「断る側」の設計、ツール表面を固定するテストまでまとめます。www.tentspace.net
**スキル側（13個）**に置いたのは、手順と判断基準です。記事をどう書くか、公開前審査をどう回すか、調査で何を見るか。これらは週次の振り返りで頻繁にチューニングする対象で、変更はMarkdownの編集とPRで済みます。差分がレビューできて、戻すのもgit revert一発。この軽さはサーバー実装では得られません。スキルの作り方も別記事があります。
つまり「破られたら事故になる境界」がMCPサーバー、「毎週変えたい手順」がスキル。きれいに聞こえますが、最初からこう設計していたわけではありません。
分け方を確定させたのは「守られなかった指示」
運用の初期、公開回数の上限のような制約も、プロンプトやスキルに書けば足りるのではと考えていました。その想定は実測で崩れます。詳細はエージェントハーネスの記事に書きましたが、公開前審査を全部通過しているのに、指示ファイルに書いた運用ルールが2週間守られていなかった、という回帰を自分の運用で観測しました。指示は読まれ、審査も通り、それでも振る舞いはずれる。これが起きるとわかった以上、「書いておいたから守られるはず」を境界の設計に使えなくなりました。
そこで制約を置く場所を変えました。投稿回数の上限はスキルの文言からWorkerのコードへ移し、超過したらツール呼び出し自体が失敗する形にしました。この実装の経緯は回数制限の実装記録にあります。逆方向の失敗もあります。文体ガイドのような毎週動く判断基準をサーバー側に固定してしまうと、チューニングのたびにデプロイが要る。それは明らかに過剰なので、手順側は徹底してスキルに寄せました。
こうして事故ベースで置き場所を移していった結果が、冒頭の分け方です。あとからGitHubの記事を読んで、「interfaces are standards, process is skills」と同じ形に落ちていたことに気づきました。ただし私の理解では、理由の重心は少し違います。標準だからMCPなのではなく、サーバー側で実行されるコードは無視できないからMCPなのです。
どちらで実装するかを決める3つの質問
自分が新しい能力を足すときに使っている質問を3つに整理します。
質問1: それが破られたら事故になるか。 公開回数、送信先、認証情報、課金。守られなかったときに外部へ実害が出るものは、MCPサーバー（またはhooksのようなコード側の強制）に置きます。スキルに書いた制約は「だいたい守られる」までしか保証しません。
質問2: それは手順・判断基準・文体か。 「この順で調べる」「この基準で判断する」「この口調で書く」は、スキルに置きます。特に変更頻度が高いものほどスキル向きです。境界の強制力は要らず、変更の軽さが効くからです。
質問3: 誰に配るか。 自分のリポジトリの中だけで完結するならスキルで足ります。MCP対応の複数クライアントやチーム外から同じ能力を使わせたいなら、共有インターフェースとしてMCPサーバーにする価値が出ます。チーム内のClaude Codeにまとめて配りたい中間帯はプラグインという選択肢もあります。
実際には1つの機能で両方使うことがよくあります。私の運用だと、記事公開の実行はMCPサーバーのツールですが、「どの順で審査を通し、失敗したら何回まで修正するか」という呼び出し手順はスキルに書いてあります。インターフェースと手順が別の場所にあるのは、分業として自然な形です。
まとめ——「どちらが新しいか」で決めない
MCPサーバーとスキルの使い分けを、3つの質問に落としました。
- 破られたら事故になる境界 → MCPサーバー（コード側で強制）
- 頻繁に変えたい手順・判断基準 → スキル
- 配布先が自分の環境を越えるか → 越えるならMCP、越えないならスキル
「skillsはMCPを殺したのか」という問いの立て方自体が、実装の判断には向いていません。次の一歩としては、いま自分のエージェントに生やしている能力を1つ選んで、「これが破られたら困るか」と問うてみるのがおすすめです。困るのにプロンプトにしか書いていない制約があったら、それが最初に移すべきものです。