[MCP·Skill #3] MCP・Skill・サブエージェント、いつ何を使う？

AIコーディングツールを拡張する方法は、最近ますます増えています。MCPでツールを接続し、Skillで手順を登録し、サブエージェントに作業を委任します。

SeokWoo LeeシニアiOSソフトウェアエンジニア公開 2026年7月14日更新 2026年8月26日読了 5 分

3つとも「モデルの能力を拡張する」と説明されるため、実際にどれを使うべきか迷いがちです。

一言でまとめると、MCPは手、Skillはマニュアル、サブエージェントは同僚です。

この記事では、それぞれが何を拡張するのか、どの基準で選ぶのか、組み合わせるとどのような構成になるのかを整理します。

まずは要点から見ていきましょう。

3つがそれぞれ拡張するもの

まず表で比較してから、1つずつ見ていきます。

区分	MCP	Skill	サブエージェント
拡張対象	能力（ツール・データ）	知識（手順・ノウハウ）	実行主体
実体	プロトコル・サーバープロセス	Markdownフォルダー	別コンテキストのセッション
たとえ	手	マニュアル	同僚

MCPは、モデルの外側にあるシステムへ手を伸ばすための経路です。DBの照会、社内APIの呼び出し、ブラウザー操作など、モデルだけでは物理的に不可能なことを可能にします。コードが実行される別サーバーが存在する点が特徴です。

Skillは新しい能力を与えるものではなく、すでに可能な作業をうまく行えるようにします。リリースノートの形式、レビューのチェックリスト、社内文書のルールなど、「どのように行うか」という知識をファイルに保存します。実体は単なるMarkdownです。

サブエージェントは、独立したコンテキストウィンドウを持つもう1つのモデルインスタンスです。本体の会話履歴を汚さずに、調査や探索などの作業を切り出して任せられます。大量のファイルを調べさせても、本体のコンテキストには結論だけが戻ります。

選択に迷ったら、次の3つを順番に問いかけます。

1つ目。モデルが今、物理的にできないことですか？社内DBの照会のようにアクセス自体が不可能なら、答えはMCPです。どれだけ知識を与えても、ない手が生えるわけではありません。

2つ目。できるけれど、方法を毎回説明する必要がありますか？その場合はSkillです。繰り返し使うプロンプトはすべてSkillの候補です。

3つ目。作業量が多く、コンテキストが汚染されますか？調査や探索の結果で会話が雑然とするなら、サブエージェントに隔離するタイミングです。

逆に言えば、アクセスがなければMCP、ノウハウがなければSkill、コンテキストがなければ（不足していれば）サブエージェントです。

3つは二者択一ではありません。実際によく設計された自動化は、ほとんどがこのような形です。

コードレビューの自動化を例にすると、レビュアーのサブエージェントを定義し（主体）、そのエージェントがチームのレビュー・チェックリストSkillに従い（方法）、GitHub MCPサーバーでPRコメントを残す（能力）という構成です。

役割が重なるのではなく、層が異なることがわかるでしょう。「誰が／どのように／何を使って」という3つの質問に、それぞれ対応します。

境界が見えれば、アンチパターンも見えてきます。

1つは、Skillで十分な作業にMCPサーバーを作るケースです。たとえば「コミットメッセージの規約を適用する」は知識の問題なので、Markdownを数行書けば終わります。そのためにサーバーを書くのは本末転倒です。サーバーには保守コストとセキュリティレビューのコストも伴います。

もう1つは、すべてを1つの本体セッションで処理するケースです。本体で大規模なコードベースを直接探索すると、ファイルのダンプがコンテキストを埋め尽くし、実装に使う余地がなくなります。探索はサブエージェントに委任し、本体は結論だけを受け取るのが定石です。

まとめると、能力がなければMCP、ノウハウがなければSkill、人手がなければサブエージェントです。

それぞれの詳しい内容はMCP編とSkill編で扱っているので、この記事の基準を使い、作ろうとしている自動化がどの層の問題なのかをまず判断してみてください。