MCP・Skills・Tools・Subagents の違いは？2026 年 AI Agent 開発スタックの変化

結論から：Tools、MCP、Skills、Subagents は四つの互換な製品名ではなく、2026 年のエージェント・スタックにおける四つの異なる層である。Tools はモデルが見る呼び出し契約（名前 + JSON Schema）。MCP は Host と外部ツール・プロセス間の発見・呼び出しプロトコル。Skills はオンデマンドで読み込む手順プレイブック（どう仕事を終わらせるか）。Subagents は独自コンテキストを持つ委譲エージェント。これらを一つのバズワードに潰すと、デバッグする層を間違える。

本稿は 2026 年 9 月 11 日時点。既に MCP とは何か、Agent の JSON データフロー、契約としての JSON Schema を扱った。本稿が答えるのは次だけ：各層が何を担い、どう積み上がり、2026 年のスタックはどこへ収束しているか。

四層を一覧で

「エージェントにツールを足す」と言うとき、実は四つの別物を指していることが多い。次の表に当てはめよ：

一文で：Tools は「何を呼べるか」；MCP は「ツールはどこから来るか」；Skills は「この仕事をどう進めるか」；Subagents は「誰が、どのコンテキストでやるか」。JSON Schema は Tools と MCP を横断する。Skills と Subagents は主にプロンプト、ポリシー、セッション境界を司る。

Tools：モデル正面の呼び出し契約

Tool（または Function）は、モデルが見る最小の呼び出し単位である。ベンダー名は違う——OpenAI の Tools / Function Calling、Anthropic の Tool Use、Gemini の Function Declarations——形は同じ：ツールを宣言し、モデルが構造化 tool_calls を返し、Host が実行して結果をチャットに書き戻す。

ツール定義はだいたいこうなる：

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

振る舞いを本当に縛るのは JSON Schema：フィールド名、型、required、additionalProperties。モデルは入れ替わってよい；Schema はモデルに引きずられて漂流してはならない。検証の規律は Tool Calling が JSON Schema に依存する理由 を見よ。ここでの要点は単純：Schema なしの自然言語ツール説明は、2026 年もう本番契約にはならない。

Tools 層の境界は明確：実装が同一プロセスかリモートかは決めない。多段作業の分割も決めない。それは MCP と Skills / Subagents の領域である。

MCP：プロセス横断のツール・ソケット

MCP（Model Context Protocol）が答えるのは、Host プロセスの外でツールとコンテキストをどう発見・呼び出すかである。メッセージは JSON-RPC 2.0。よく使うメソッドは tools/list、tools/call、加えて Resources / Prompts。Host（Cursor、VS Code、Claude Desktop など）内の MCP Client が MCP Server に接続し、公開されたツールをモデルが理解する Tools 配列へ翻訳する。

正しい積み上げは次のとおり：

1. MCP Server が各ツールを inputSchema（やはり JSON Schema）で記述する；
2. Host が tools/list を呼び、モデルの Tool 宣言へマップする；
3. モデルが tool_calls を出す；
4. Host が Server へ tools/call を送り、result を対話へ書き戻す。

MCP を「もう一つの Function Calling」と呼ぶのは 2025–2026 で最も多い誤読である。Function Calling はモデル API 境界；MCP は Host ↔ Server 境界。現行仕様は 2026-07-28：セッション・ハンドシェイクなし、リクエストが _meta を運ぶ。詳細は MCP ガイド と 移行ガイド。

MCP が不要なとき：単一プロセス、Host にツールを直結、アプリ横断の再利用なし——Tool Calling だけで足りる。必要なとき：同一 Server を IDE / デスクトップで再利用、プロセス隔離、動的なツール発見。

Skills：再利用可能な手順プレイブック

Skill はもう一つの tool ではない——エージェントがオンデマンドで読み込める手続き知識である：いつ起動するか、どの手順か、何を検査するか、どのツールを使ってよいか。エンジニアリング上は多くの場合リポジトリの SKILL.md（または同等のルールパック）：タイトル、トリガー条件、チェックリスト、禁止事項、関連スクリプトパス。

Tools / MCP との対比：

2026 年、IDE エージェントは Skills を第一級にする：短い仕事は組み込み能力；長いフロー、チーム規範、運用プレイブックは Skills に置き、毎回システムプロンプトへ手引き全体を貼らない。Skill はどの Tools を呼ぶかを誘導し、「submit 前に JSON を検証」のようなゲートを課せる——だが通常 JSON-RPC メソッドではない。

よくある混同：パッケージ化したシェルスクリプトを Skill とも Tool とも呼ぶこと。目安——モデルが Schema 経由で一度呼び、構造化結果を得るなら Tool；文書がエージェントに「この五手順に従い、必要ならツールを呼べ」と書くなら Skill。

Subagents：コンテキスト分離つき委譲

Subagent は親が委譲する子セッションである：通常は独自コンテキスト窓、より狭いシステムプロンプト、より厳しいツール許可リスト、完了後に親へ返す要約。「関数を一つ足す」のではない。コンテキスト汚染を防ぎ、並列探索を可能にする。

典型用途：

• 隔離検索——子がリポジトリやログを掘る；親は結論だけ残す。
• 並列作業——フロントエンド変更、テスト、コピー翻訳が一つのコンテキストを奪い合わない。
• 役割の絞り込み——セキュリティレビュー、コード探索、CI 診断がそれぞれ専用プロンプトとツールを持つ。

実装では、Subagent はしばしば親に特殊な Toolとして露出する（例：Task / spawn_agent）。引数はタスク記述と種別；戻り値は子の最終回答。だからといって Subagent = Tool ではない。Tool は呼び出し面；Subagent は別の状態付き推論ループである。

Skills との境界：Skill は「どうやるか」；Subagent は「別セッションを開いてやる」を決める。Skill が「複雑な切り分けは CI Subagent を起動せよ」と定め、その Subagent が自分の Skills と Tools を読み込む、という重ね方ができる。

四層の積み上げ方

実タスクでは四層が同時に出ることが多い。例：「ブログを書いてデプロイ」（説明用。本サイトの内部プロトコルではない）：

1. 親が Skill を読み込む——「ブログ公開チェックリスト」：本文、ロケール、sitemap、IndexNow。
2. 親が Subagent を呼び、過去記事テンプレートを探索し、数十 HTML を主コンテキストに入れない。
3. メインセッションが Tools（ファイル読み書き、shell）でフロントを編集；ツールがプロセス外なら発見と呼び出しは MCP 経由。
4. 構造化パラメータが出るたび、JSON Schema がフィールドを固定する——特にマシンを離れる一跳び。

データフローを一行にすると：

User → Host / parent agent
      → Skills (pick the workflow)
      → Subagents (optional delegation)
      → Tool declarations (for the model)
      → optional MCP Client ↔ MCP Server
      → results written back into the dialogue

デバッグ早見表：モデルが誤ツールを呼ぶ → Tools / Schema；ツール・プロセスが繋がらない → MCP；手順が抜け続ける → Skill；コンテキストが爆発・汚染 → Subagent。

2026 エージェント・スタックで何が変わるか

2024 の「関数をプロンプトに詰め込む」と比べ、2026 は次の五つの移行に圧縮できる：

もう一本の主線は構造化出力とツール引数の合流：業務 JSON、ツール arguments、MCP inputSchema が同じ Schema 規律を共有する。Structured Output とは何か と OpenAI vs Gemini 比較 を参照。

製品側では、IDE エージェントはもはや「チャット + 補完」だけではない：既定スタックにツール呼び出し、MCP コネクタ、Skills ディレクトリ、起動可能なサブエージェントが並ぶ。ビルダーへの含意は——出荷するのは API だけでは足りない。発見可能なツール（MCP/Tools）+ 従えるワークフロー（Skills）+ 必要時に委譲できる役割（Subagents）である。

今なにを選び、なにを書くか

• ツールを公開する前に Schema を書け。additionalProperties: false を付け、required を埋める；本サイトのツールでブラウザ内の引数サンプルを検証する。
• アプリ横断で再利用が必要なときだけ MCP Server に包む。単一スクリプトを単一 Host に埋め込むなら MCP は不要。
• 繰り返すチーム・ワークフローは Skills に落とす。公開、移行、切り分け、セキュリティレビュー——手順が安定しているなら「モデルに思い出させる」に頼るな。
• コンテキストが長くなったら Subagent を切る。探索・読み取り専用・高ノイズ作業を優先して委譲；判断と最終パッチは親に残す。
• Skill で Schema を、Subagent で MCP を置き換えるな。プロセス ≠ 契約 ≠ 転送。混ぜると「ドキュメントには検証と書いてあるのに本番では一度も走らない」になる。

ローカル JSON 検査では inputSchema、モデルの引数サンプル、MCP tools/call 結果サンプルを保存し、JSON バリデータ と JSON Diff で照合する。データはブラウザを出ない——オンデバイス優先のプライバシー感覚と同じ。

FAQ

まとめ

Tools はモデルが何を呼べるかを定義し；MCP は外部プロセスからツールをどう発見・呼び出すかを定義し；Skills は手順どおり仕事をどう終わらせるかを定義し；Subagents はコンテキストをどう分離し委譲するかを定義する。2026 年のエージェント・スタックは「一つのチャット枠 + 場当たりの関数」から、この四層と JSON Schema 契約帯へ収束している。

スタックは内側から伸ばせ。まず Schema と Tools を正しくし、再利用・手順・コンテキストの圧力に応じて MCP、Skills、Subagents を足す。出荷前にサンプルをローカル検証せよ——モデルは変わってよい；フィールド名と required は変えてはならない。