まず結論
3 つは競合する選択肢ではありません。層が違います。
| 仕組み | 一言でいうと | 中身 |
|---|---|---|
| スキル | やり方を教える | プロンプトに差し込まれる文章とファイル |
| MCP サーバー | 外の世界に繋ぐ | 動いているプログラム。データの取得と副作用 |
| サブエージェント | 別の作業場を用意する | 独立した文脈（コンテキスト）を持つ実行単位 |
迷ったときの分かれ目は 1 つ
「照会する」「取得する」「現在の〜」という言葉が要件に入っているなら、それはスキルでは解決しません。
スキルは書いた時点の文章で、実行時に外から何かを取ってくる仕組みを持っていません。
スキルが向くこと
やり方・作法・判断基準を渡すときです。大きく 2 種類あります。
できないことをできるようにする
エージェントが素の状態では不得意な作業を、手順とライブラリの選び方ごと渡します。pdf がそうです。
PDF の表を抜くのに pdfplumber、新規作成に reportlab、OCR に pytesseract を使う、という割り当てを持っているので、毎回ライブラリを試して遠回りしなくなります。
できることを自分たちのやり方に寄せる
やり方自体は知っているが、社内の流儀に合わせたいとき。障害報告書の書式、レビューの観点、設計の進め方。
brainstorming や test-driven-development は後者です。
スキルで解決しないこと
- 社内 DB の現在の在庫数を知る
- チケット管理システムの未対応一覧を取る
- 今日の為替レートを引く
これらは全部「いまの状態」です。スキルの本文に書き込んでも、書いた日の値で固定されます。
MCP が向くこと
外部のシステムに繋いで、読む／書くときです。MCP（Model Context Protocol）は接続の規格で、サーバーは動いているプログラムです。
| 用途 | 例 |
|---|---|
| 現在の状態を読む | DB への照会、チケットの一覧、ファイルの検索 |
| 副作用のある操作 | チケットの作成、メッセージの送信、デプロイの実行 |
| 認証の要る先 | 社内システム、SaaS の API |
スキルと MCP は同時に使える
スキルと MCP は同時に使えます。よくある形はこれです。
社内の作法を書いたスキル ＋ 社内 DB に繋ぐ MCP
スキルが「どう書くか」を決め、MCP が「いまのデータ」を持ってきます。どちらか一方では成立しません。
入れると常に接続先が存在する
影響範囲を考えるとき、この差は大きいです。
サブエージェントが向くこと
別の文脈で作業させたいときです。理由は 3 つに絞れます。
- 本筋の会話が長くなりすぎる調査だけで文脈を食い潰したくない
- 前の作業の影響を持ち込みたくないきれいな状態で始めたい
- 並行して走らせたい独立した作業が複数ある
使い方自体をスキルにしたものもある
dispatching-parallel-agents や subagent-driven-development のように、サブエージェントの使い方自体をスキルにしたものも流通しています（どちらも当サイトで日本語の解説を書いています）。
層が違うので、こういう組み合わせが成り立ちます。
落とし穴は、文脈が切れていること
サブエージェントの落とし穴は、文脈が切れていることそのものです。Claude Code のサブエージェントは会話の履歴を見られず、呼ぶ側が書いた依頼文と、CLAUDE.md などの一部だけから始めます。会話を丸ごと引き継ぐ「fork」という例外もあります（公式ドキュメント、2026-10-09 確認）。
「さっき話した前提」は伝わらないので、依頼文に必要な情報を全部入れる必要があります。
判断の順序
迷ったらこの順で考えてください。
- いまの状態を取ってくる必要があるかある: MCP（または MCP を呼ぶスキル）。ない: 次へ
- やり方・作法・判断基準を教えたいのかそう: スキル。違う: 次へ
- 作業を切り離したいのか（長い／汚したくない／並行）そう: サブエージェント。違う: そもそも仕組みは要らない。依頼文で足りる
最後の分岐が案外重要
組み合わせた形
実務でよく効く形を挙げます。
| 場面 | スキル | MCP | サブエージェント |
|---|---|---|---|
| 社内の設計レビューを任せる | レビューの観点、社内の規約、指摘の書き方 | リポジトリとチケット管理システムへの接続 | ファイルごとに並行してレビューさせる |
| 障害対応の記録を残す | 報告書の書式と、書くべき項目 | 監視システムからの指標の取得 | 不要（1 本の流れで済む） |
| ドキュメントの整備 | 用語集の作り方（domain-modeling など） | 不要（リポジトリ内のファイルだけで完結する） | 不要 |
「全部使う」が正しいわけではない
「全部使う」が正しいわけではありません。要らない層を足すと、設定と確認する場所が増えるだけです。
当サイトが扱っている範囲
収録しているのはスキルだけ
当サイトが収録しているのはスキルだけです。MCP サーバーとサブエージェントは対象にしていません。
理由は、インストール数という比較できる指標があるのがスキルだけだからです。MCP サーバーは配布の形がばらばらで、横並びに数えられません。
MCP との連携を前提にしたスキルもある
ただしスキルの中には MCP との連携を前提にしたものがあります。たとえば better-auth-best-practices は「Better Auth の MCP があればドキュメントの解決に使う」と本文に書いています。
各スキルのページの「前提」に、そうした依存関係を書いています。
よくある質問
プラグインやコマンドとの関係は何ですか
プラグインは配る単位です。スキル、サブエージェント、フック、MCP サーバーなどをまとめて配布する包みで、中身がどれかとは別の話です（Claude Code の公式ドキュメント、2026-10-09 確認）。
コマンドは Claude Code ではスキルと同じ仕組みで動きます。.claude/commands/deploy.md も .claude/skills/deploy/SKILL.md も、同じ /deploy になります。スキルの frontmatter に disable-model-invocation: true を付けると自動で呼ばれなくなり、/名前 で手動で呼ぶ形になります（詳しくはSKILL.md の書き方）。
MCP の代わりにスキルの中でコマンドを実行させればいいのでは
できますし、実際そうしているスキルは多くあります。agent-browser は CLI をシェルで叩く形です。
ただし違いは 2 つあります。接続の管理（認証、再接続、失敗時の扱い）を自分で面倒みることになる点と、シェルの実行を許すことになる点です。
後者は影響範囲が広いので、当サイトでは各スキルのページに「シェルコマンドを実行する記述があります」と明記しています。
どれから試すべきですか
スキルからです。入れても呼ばれなければ何も起きず、外すのもフォルダを消すだけで済みます。MCP は接続先が常に存在するので、影響を見積もる手間が増えます。
まずスキル 1 つで、いま困っている作業が進むかを試してください。
「スキルを入れたのに MCP が必要と言われた」のはなぜですか
そのスキルが現在の状態を必要とする作業だからです。たとえば「Azure の構成図を作る」は、いま動いているリソースを読まないと書けません。
azure-resource-visualizer の本文も「Azure MCP のツールか az コマンドで問い合わせる」と書いています。スキルは手順を知っていますが、データは持っていません。