誰もが今、あらゆるものにモデルコンテキストプロトコル（MCP）サーバーを追加しています。その理由も分かります。MCPはクリーンです。標準化されています。サーバーを作成し、いくつかのツールを公開すれば、LLMはログプラットフォームにクエリを実行し、ダッシュボードを取得し、アラートを発報できるようになります。適切な抽象化だと感じます。
しかし、私は本気度の高い企業のチームが、本来はスキルで対応すべきワークフローのために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 に偏り過ぎていませんか、それともスキルを本格的に扱い始めていますか。
さらに重要なのは、実行レベルでの自律性とツールアクセスをどのように制御しているかです。
