スキルと MCP ツールは同じものではありません — それらを混同すると損をします。 真の違い、真の欠点、そして両方を組み合わせてより良いエージェントのワークフローを作る方法を学びましょう。

MCP スキル vs MCP ツール: 違いは何か、そしてそれらをどう組み合わせるか

誰もが MCP について話している。誰もがスキルについて話している。

ほとんどの人はそれらを使い回している — それがまさに問題だ。

それらは同じものではない。彼らは同じ問題を解決しない。そして間違った方を選ぶと、それは分かる。幻覚、文脈の膨張、タスクから逸脱するエージェント、プレッシャーの中で崩れるワークフロー。

それを修正しましょう。

コアとなるメンタルモデル

それを台所のようなものと考えてください。

MCP ツール はあなたの家電と食材です — オーブン、冷蔵庫、新鮮な野菜。 生の能力。これらがなければ、何も作られません。

スキル はあなたのレシピです — 熟練したシェフが材料をどう良いものに変えるかを示す、段階的な指示です。 それらがなければ、方向性のない力を持つことになります。

An agent with only MCP tools can do things but doesn't necessarily know how to do them well. An agent with only skills has great instructions but no way to act on them.

両方が必要です。

MCP ツールとは何か？

Model Context Protocol はオープン標準です — 現在は Linux Foundation の Agentic AI Foundation の下で動作しており、AI エージェントが外部システムへ接続する標準化された方法を提供します：データベース、API、ファイルシステム、GitHub、Slack、あなたの Angular CLI。

MCP サーバをクライアントに接続すると — Claude Code、Gemini CLI、またはカスタムエージェントであろうと — タイプ付き、決定論的なツールのセットにアクセスします。各ツールには明確な入力/出力スキーマがあります。エージェントがそれを呼び出すと、それは実行されます — 解釈も幻覚リスクも実行レベルにはありません。提案ではなく、構造化された API 呼び出しです。

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

MCP はエージェントが 自分の外へ到達する 方法です。 それは神経系です。

Use MCP when you need the agent to:

• 実際のシステム（データベース、ファイルシステム、API）へ読み取りまたは書き込みを行う
• 明確で監査可能な入力と出力を伴うアクションを実行する
• 自分が所有・制御していないツールに接続する
• 一貫したインターフェイスを通じて複数のサービスを統合する

スキルとは何か？

スキル は、Markdown ファイル（YAML フロントマター付き）と任意のスクリプト・リソースを含むフォルダです。単独では実行可能ではなく、プレイブックです。

ユーザーのリクエストがスキルの関連基準に一致すると、エージェントはそれらの指示を動的に読み込み、それに従います。それを、必要に応じてエージェントに専門家レベルの手続き的記憶を提供することだと考えてください。

---
name: angular-component-review
description: Review Angular components for Signal compliance and standalone architecture
---

# Angular Component Review

When reviewing an Angular component:
1. Check that all state uses signal() or computed() — never direct property mutation
2. Verify the component is standalone: true
3. Confirm no NgModule dependencies remain
4. Validate that @if / @for is used instead of *ngIf / *ngFor

エージェントは関連性がある場合にのみこれを読み込みます。関連性がない場合は、何の費用もかかりません。

スキルを使用する場面

• 一貫したプロセスやチェックリストに従う
• ドメイン固有の専門知識を適用する（あなたのコーディング標準、レビュ基準）
• 頻繁に変わらない知識をエンコードする
• 異なる会話で同じワークフローを再利用する

実際の欠点

ここが大半のガイドが止まる箇所です。止めるべきではありません。

MCP: トークン課税

接続するすべての MCP ツールは、その完全なスキーマをコンテキスト ウィンドウへ挿入します エージェントが1つのメッセージを処理する前に。各ツールは 550–1,400 トークンを消費します。GitHub、Slack、Sentry を接続すると、前払いで 55,000 トークン が消費される計算になります — 実際の作業が始まる前に Claude の 200k 制限の4分の1を超えるのです。Gemini を 1M+ トークンのウィンドウで使っている場合、それを無視できると思うかもしれません。やめてください。 余裕があるとしても、会話の各ターンごとに 55,000 トークンの生 JSON スキーマを投入すると、レイテンシが上がり、API コストが増え、モデルの焦点が薄まります。

あるチームは MCP サーバを3つ接続し、ツール定義だけで 200,000 トークン中 143,000 トークン を消費したと報告しています。エージェントには実際の会話に使えるトークンが 57,000 残っていました。

朗報として、 Claude Code や Gemini CLI のような現代的クライアントは MCP の「プログレッシブ・ディスカバリー」を採用しました — ツール名と説明のみを事前に読み込み（各約 20–50 トークン）、エージェントが実際にツールを必要とする時にのみ完全なスキーマを取得します。トークンのオーバーヘッドは約 85% 減少しました。しかし、この機能は MCP の設定がそれを使用するように構成されている場合に限り機能します。大半の設定はまだそうなっていません。

スキル: 老朽化の問題

スキルは Markdown ファイルです。自動で更新されません。Angular のパターンが進化した場合 — 例えば setInput() から Angular 20 の新しい宣言的 API に移行した場合 — あなたのスキルは手動で更新されるまで古い方法を教え続けます。

作成するスキルが増えるほど、保守の負担が増えます。 そしてスキルに微妙な誤りがあると、エージェントは自信を持ってそれに従います — エラーはなく、ただ静かに誤った出力になります。

両方: 選択の問題

エージェントにツールをあまりにも多く、またはスキルを多く与えすぎると、間違った選択をし始めます — 間違ったツールの呼び出し、間違ったプレイブックの発動、矛盾した指示を生み出すような組み合わせ。専門家は、常時 10–15 個のアクティブ MCP ツール 未満に抑えることを推奨します。

どう組み合わせるか

最も強力なパターンは、それらをレイヤーとして使うことです：

レイヤー1 — MCP がアクセスを提供します。
現在のタスクに実際にエージェントが必要とするものだけを接続します。Angular CLI、データベース、ファイルシステム。 軽く保つ。

Layer 2 — Skills provide expertise.
エージェントにそれらのツールをあなたの特定の文脈でどのように使用するかを伝えるスキルを作成します。単に「Angular CLIを実行する」だけではなく、コンポーネントを移行する際には ng generate をこれらのフラグで実行し、これらのパターンに対して検証します。

Layer 3 — Skills can orchestrate MCP.
スキルは、複数の MCP ツールを順番に呼び出す多段階のワークフローを定義できます。例：「Deploy & Notify」スキルは、GitHub MCPを使ってプッシュ、CI/CD MCPを使ってビルドをトリガーし、Slack MCPを使ってチームに通知する — すべて1つの一貫したプレイブックの下で。

---
name: angular-migration-workflow
description: Full workflow for migrating an Angular component to v21 patterns
---

# Migration Workflow
1. Use the Angular CLI MCP to check the current component version
2. Run ng update for the affected package
3. Apply the zoneless migration schematic
4. Review the output against the angular-component-review Skill
5. Run tests and report results

実践的な意思決定ガイド

ワークフローの改善

本番環境で実際に機能するパターンをいくつか：

1. ドメインごとに1つの MCP サーバー。 一度にすべてを読み込まないでください。「Angular 開発用」、「デプロイメント」、「コミュニケーション」用の別々の設定を作成し、セッションごとに必要なものだけを有効にします。

2. スキルをコードのようにバージョン管理する。 それらをリポジトリに置き、スタックを更新する際に見直します。Angular 19 パターン用のスキルは、Angular 21 では有害になります。

3. MCP ガードレールを作成するためにスキルを使う。 エージェントが破壊的な MCP アクションを呼ぶべきタイミングを判断するのに任せるのではなく、次のように明示的に指示するスキルを作成します: 「いかなる ng update を実行する前にも、必ずまず git ブランチを作成する。」

4. コンテキスト予算を測る。 エージェントが実際の作業を開始する前に、MCP セットアップが消費するトークン数を把握しておきます。コンテキストウィンドウの 30% がツール定義に使われている場合、設定に問題があります。

5. エージェントにシンプルなスキルの維持を任せる。 チームの現在の Angular バージョン規約のような急速に動く領域では、あなたが指示したときにエージェント自身がスキルファイルを更新するようにしましょう。手動で行うより速く、スキルの正直さを保ちます。

結論

MCPはエージェントに行動する能力を与えます。スキルは彼らにうまく行動する方法を教えます。

「MCP対Skills」の議論は虚構です。本当の問題は、アクセスが必要か、専門知識が必要か、あるいはその両方か？

ほとんどの実際の Angular ワークフローでは、両方が必要です。CLIを実行できるがアーキテクチャを知らないエージェントは、同じ間違いをより速く繰り返すだけです。パターンを知っているが実際のプロジェクトには手を付けられないエージェントは、高価な検索エンジンに過ぎません。

一緒に使用される場合、明確な境界と簡素な設定を備えていれば、それらは実際に機能するエージェント主導の開発の基盤となります。

以前、Angular 21 MCPと手動移行の終焉について書いたことがあります — Angular の MCP サーバー設定を初めて学ぶ人にとって良い出発点です。