今、あらゆる場所でModel Context Protocol（MCP）サーバーの導入が進んでいます。その理由はよくわかります。MCPはシンプルで、標準化されているからです。サーバーを構築してツールを公開するだけで、LLM（大規模言語モデル）がログプラットフォームに対してクエリを実行したり、ダッシュボードを取得したり、アラートを発報したりできるようになる。まさに、求めていた「適切な抽象化」だと感じます。
しかし、私は本気度の高い企業のチームが、本来はスキルで対応すべきワークフローのためにMCP統合の構築に何週間も費やし、逆に本当にMCPが必要なケースのためにスキルを構築しているのを見てきました。この混乱のせいで、現場では貴重な時間が失われています。
私の考えはこうです。
MCPは「配管（インフラ）」であり、スキルは「専門知識」そのものです。
MCPサーバーは、次の問いに答えます。エージェントは何ができるのか？
MCPはモデルにツールへのアクセス権を与えます。例えば「このAPIをクエリせよ」「このデータセットを読み込め」「このシステムに書き込め」といった指示を可能にします。MCPは、LLMと現実世界をつなぐ接続レイヤーであり、いわば「能力を付与するもの」なのです。
スキルは別の問いに答えます。エージェントはこの種の問題をどう考えるべきか？
スキルとは、パッケージ化された判断力です。それは一連の手順やドメイン特有の経験則であり、専門家が実践する「Xを見たら、Zをする前にまずYをする」といった推論そのものです。スキルはワークフローをコード化し、MCPはアクセスをコード化します。
その両方が必要不可欠です。しかし、これらは代替可能なものではなく、一方が必要な場面でもう一方を使ってしまうと、期待通りの結果は得られません。
これが破綻するケース
ログ解析プラットフォームを運用するセキュリティ運用チームを例に挙げましょう。彼らがAIを活用してアラート調査を効率化しようとする際、直感的に考えるのが「MCPサーバーの構築」です。ログ検索ツール、脅威インテリジェンス照会ツール、アセットコンテキスト取得ツールを公開すれば、LLMがアラートを「調査」できるようになる、と考えます。
しかし、実際にはできません。完全とは言えないのです。
あなたがエージェントに与えたのは「アクセス権」に過ぎません。調査の「ワークフロー」を教えていないのです。「S3バケットに対するCSPMアラートが発生したら、まずCloudTrailを確認し、過去24時間のIAMアクティビティを照合し、エスカレーションの前にバケットが機密情報としてタグ付けされているかチェックする」といった手順を組み込んでいません。これはMCPの問題ではなく、スキルの問題です。
MCPツールを持ちながらスキルがないエージェントは、あらゆるシステムへのアクセス権はあっても、調査経験が一度もない新人アナリストのようなものです。何でもクエリはできますが、何を、どの順番で、どのような仮説に基づいてクエリすべきかを知りません。
スキルはトレーニングであり、MCPは入館証です。
実際にMCPが必要な場合
エージェントが、通常はアクセスできないライブデータやシステムにリアルタイムでアクセスする必要がある場合に、MCPサーバーが必要になります。
- 時間枠内のイベントをログプラットフォームから照会すること
- SIEMから現在のアラート状態を取得すること
- モニターをプログラムから作成または更新すること
- ライブCMDBと照合して資産インベントリを確認すること
これらはツール呼び出しであり、ステートレスで、データを返し、アクションを実行します。MCPは、そのための適切な抽象化レイヤーです。
また、複数のエージェントや複数のインターフェース間で同一の機能へのアクセスを共有したい場合にもMCPが必要です。ログプラットフォーム用にMCPサーバーを1つ用意し、すべてのエージェント、インテグレーション、IDEプラグインが同じサーバーと通信する。これこそがプロトコルの正しい活用法です。
本当にスキルが必要になるとき
以下の例のように、判断が組み込まれた再現可能なワークフローをコード化するときに、スキルが必要になります。
- このアラートタイプを調査する（正しい手順、検証すべき仮説、出力の構成方法は次のとおり）。
- このログ形式をパースする（考慮すべきエッジケース、ベンダーの誤り、正しいフィールド抽出方法は次のとおり）。
- この脅威パターン向けの検出ルールを作成する（方法論、ルールがノイジーになる要因と、精度が高くなる要因）。
- インシデントの振り返りを実施する（収集すべき情報、タイムラインの組み立て方、答えるべき問いは次のとおり）。
これらはツール呼び出しではなく、ワークフローです。エージェントはツールが存在することを知るだけでなく、そのツールを使って何をすべきかを知る必要があります。
スキルはMCPツールを呼び出すことができます。実際に機能するパターンとは、スキルが推論フレームワークを提供し、MCPがデータアクセスを提供することです。スキルが指揮を執り、MCPが実行するのです。
私が使っているテスト
「これはスキルにすべきか、それとも MCP サーバーにすべきか」と聞かれたとき、私は必ず次の質問をします。
もしチームの熟練専門家が手動でこれを行うとしたら、難しいのはデータへのアクセス権を得ることでしょうか？ それとも、データを入手した後にどう対処すべきかを判断することでしょうか？
難しいのがアクセスならMCPが必要であり、判断ならスキルが必要です。
正直に言えば、大抵の場合、難しいのは「判断」です。だからこそ、MCPサーバーだけでは期待したようには機能しないのです。あなたはエージェントに車のキーを渡しただけで、運転の仕方を教えていないのですから。
実践的な考え方
本来はワークフローの問題であることに対してMCPサーバーを構築するのはやめましょう。スキルを第一級の成果物として扱い、ランブック（手順書）を維持するのと同じように、設計、テスト、バージョン管理を行い、時間をかけて改善していくべきです。
MCPサーバーはインフラストラクチャであり、スキルはチームの専門知識をパッケージ化したものです。どちらも重要ですが、それぞれ異なる問いに対する答えなのです。
現在の比率はどうなっていますか？ MCPに偏りすぎていませんか？ それともスキルを真剣に扱い始めていますか？
さらに重要なのは、実行レベルでどのように自律性とツールへのアクセスを制御しているかということです。
