MCPサーバーの正体
まず「サーバー」という言葉から始めましょう。これがほぼ全員をつまずかせるポイントだからです。MCPサーバーはデータセンターにある大きなマシンではなく、AIそのものでもありません。それは標準インターフェースを通じてAIアプリケーションに特定の機能を公開するプログラムです。ローカルでラップトップ上で動かすこともできますし、リモートでプラットフォーム上で動かすこともできます。それだけのことです。
私が読んだ中で最も明快な説明は、Hacker Newsのある開発者によるもので、まさにこの混乱を解きほぐしていました。
"One confusing thing to me was the word 'server'. An 'MCP server' is a server to the LLM 'client'. But the MCP server itself is a client to the thing it's connecting the LLM to. So it's more like an adapter or proxy."
これが持っておくべきメンタルモデルです。サーバーはAIエージェントと実際のシステム(ヘルプデスク、データベース、注文照会など)の間に位置し、両者を翻訳します。
MCPそのものは、この翻訳を普遍的なものにする標準です。Anthropicは2024年末にこれをオープンソース化し、ある具体的な問題を解決しました。AIに到達させたい新しいデータソースが増えるたびに、それぞれ独自の実装が必要だったのです。MCPは、その場当たり的なコネクタの山を単一のプロトコルに置き換え、一度作れば、どこにでも統合できるようにします。
このアーキテクチャは3つの要素からなり、それらをきちんと区別しておく価値があります。「AIエージェントMCPサーバー」という言葉が、そのうち2つを混同させてしまうからです。
- MCPホストとはAIアプリケーションのことです。Claude Desktop、Claude Code、Cursor、あるいはエージェントを組み込んだサポート製品などがこれにあたります。モデルが存在するのはここです。
- MCPクライアントとはホスト内部のコネクタです。ホストは話す相手のサーバーごとに1つのクライアントを立ち上げます。
- MCPサーバーとは、ツールとデータを公開するプログラムです。
つまり誰かが「AIエージェントMCPサーバー」と言うとき、通常はエージェントが接続するサーバーのことを指しています。エージェントとはホストとモデルを合わせたものであり、サーバーとは配線の反対側にあるものです。
サーバーが公開する3つのもの
MCPサーバーは3種類の機能を提供でき、公式のサーバー概念ドキュメントはそれぞれを誰が制御するかで線引きしています。この区別は見た目以上に重要です。
| プリミティブ | それが何か | 誰が制御するか |
|---|---|---|
| ツール | モデルが呼び出せるアクション: 注文を調べる、チケットにタグを付ける、返信を送る | モデル |
| リソース | アプリがコンテキストとして取り込む読み取り専用データ: ヘルプセンターの記事、チケット履歴 | アプリケーション |
| プロンプト | ユーザーが起動する再利用可能なテンプレート: 「このスレッドを要約して」 | ユーザー |
サポートエージェントにとって面白いのはツールです。ツールこそが、エージェントが単に読むのではなく何かを実行する手段だからです。そしてドキュメントはここで慎重で、ツールは実行前にユーザーの同意を必要とする場合があるとしています。顧客への返信を送れるエージェントは、少なくとも最初のうちは人間による承認ステップを置きたい、まさにその種のアクションです。
ローカルMCPサーバーとリモートMCPサーバー
もう1つ区別をしてから、サポートの話に移ります。MCPサーバーは、接続方法によって2種類に分かれます。
- ローカル(stdio)サーバーは、ホストと同じマシン上で動き、標準入出力を介して通信します。間にネットワークは介在しません。Claude Desktopがファイルシステムサーバーを起動する場合がこれにあたります。
- リモート(streamable HTTP)サーバーは別の場所で動き、HTTP経由で接続します。ベアラートークンやOAuthのような標準的な認証を伴います。
サポートにとって重要なのは「リモートMCPサーバー」の方です。ヘルプデスクはクラウド上にあるので、GorgiasやFrontがMCPサーバーを公開する場合、それは複数のエージェントが同時に接続できるリモートサーバーです。この「認証」という言葉を覚えておいてください。後で効いてきます。
カスタマーサポートではどう見えるか
ここから具体的になります。この1年で主要なヘルプデスクは自社のMCPサーバーを提供し始めており、そのパターンは一貫しています。アカウントを読むのには優れている一方、それに基づいて行動することには慎重です。
Gorgiasはmcp.gorgias.comに自社製のMCPサーバーを持ち、すべてのHelpdeskプランで無料です。公式のセットアップ手順では、Claudeをそこにつなぐステップがガイドされています。モデルはあなたが用意します。しかし読み取りはライブである一方、マクロの編集やAI Agent設定の書き込みは、オープンベータ期間中は制限されています。つまりClaudeはサーバー経由でGorgiasアカウントを見ることはできますが、まだそれを完全に運用することはできません。
Frontもmcp.frontapp.comで同様のものを提供しており、開発者向けサイトに文書化されています。オープンベータで、Enterpriseプランの制限はなく、アクションごとの課金もありません。興味深いのはその設計です。すべてのトークンは単一のFrontチームメンバーに紐づけられ、そのユーザーの役割に対してリアルタイムでチェックされます。またsend_messageは意図的にcreate_draftとは別に扱われ、フラグが立てられているため、クライアント側で送信のたびに確認が求められます。これは本当に優れたアシスタントです。しかし同時に、設計上、キューを自力で回すことは構造的にできません。
AtlassianのRovo MCPサーバーはJira Service Managementをカバーしていますが、これは「到達可能だが解決はされない」というギャップの最も鮮明な例です。そのJSMツールグループはわずか4つのツールで構成され、そのすべてがオンコール運用(アラートとスケジュール)向けです。リクエスト、リクエストタイプ、キュー、SLA、ポータル顧客向けのツールは一切ありません。サービスデスクのチケットは汎用のJiraツールを通じてしか到達できないため、エージェントには顧客からのリクエストではなく単なる作業アイテムとして見え、自分が書いたコメントがチケットを起票した本人に表示されるかどうかすら分かりません。
この3つを並べてみると、ある傾向が浮かび上がります。今日のヘルプデスクMCPサーバーは、スペクトルの「到達可能」側に強く偏っています。
これはどのサービスに対する批判でもありません。読み取りを優先し、書き込みには慎重なサーバーは、これを世に出す責任ある方法です。ただしそれは、MCPサーバーが与えてくれるのは情報通のアシスタントであって、あなたが眠っている間にチケットを閉じてくれるエージェントではないということを意味します。その両者の間の距離こそが、この記事の残りの部分です。
落とし穴: 到達可能であることは賢いこととは違う
これは、サポートリーダーが「MCP統合」プロジェクトにゴーサインを出す前に、最も内面化してほしい部分です。接続と能力を混同するのは簡単だからです。
MCPサーバーは、構造的には薄い翻訳レイヤーです。私が読んだあらゆる技術系スレッドで最も繰り返されていた指摘は、だいたいこのようなものでした。
"Regardless of whether the MCP 'server' is local or remote, it is JUST a wrapper around APIs. It's basically a translation layer to make your APIs adhere to the MCP spec, that's it."
サーバーがラッパーだとすれば、実際のサポート業務はどこで行われるのでしょうか。その下です。サーバーを立ち上げることは、小さく目に見える先端部分にすぎません。あなたのエージェントが本当に使えるかどうかを左右するのは、水面下のスタックです。
それらのレイヤーのうち3つは、書き出しておく価値があります。それぞれが、素のMCPサーバーがあなたを一人にしてしまうポイントだからです。
リトリーバルの質。 ナレッジベースをリソースとして公開するのは簡単ですが、エージェントにそれをうまく使わせることは簡単ではありません。ある開発者は、その失敗パターンを的確に言い表しました。
"There's very little actual engineering going in to designing MCP interfaces to actually efficiently work with the way LLM workflows actually operate. Many MCPs offer tools that allow an LLM to retrieve a list of 'things that exist' with the expectation the LLM will then pick something out of that list... massive lists of 'things that exist' eat tokens and context."
400件のヘルプ記事をコンテキストに詰め込み、モデルが正しいものを選んでくれることを願うサポートエージェントは、デモであって製品ではありません。リトリーバルの設計、つまりどうチャンク分けし、ランク付けし、エージェントに見せる範囲をどう絞るかによって、解決率が決まります。そしてMCPはその点について何もしてくれません。
セキュリティと権限。 先ほどの「認証」というフラグを思い出してください。このプロトコルは、認証まわりが有名なほど薄い状態で公開されており、最も鋭い警告は、まさにサポートが扱うデータに関するものです。
"Most providers don't support auth in their client implementations yet. Means it's only good for calling into public data. Private enterprise data is where there's huge value."
顧客チケット、注文履歴、アカウント記録。これらはすべて非公開の企業データです。さらに、ツール自身のパラメータが情報流出の経路となる、実際のプロンプトインジェクションの攻撃対象領域も存在します。これらはサーバーが存在するだけでは何一つ解決されず、あなたがその周りに構築するガードレールによって解決されます。
エージェントの判断力。 MCPは接続を標準化しますが、アプリケーションがモデルをどう使うかやコンテキストをどう管理するかについては、あえて指図しません。これが、このプロトコルの正体についての正直な見方です。
"MCP 'universal plugin system' claims are oversold. It is really just a standardized tool calling for AI agents... The 'system integration' benefits only matter when you have an LLM in the loop making decisions about which tools to use."
意思決定を行うループの中のLLM、それこそが製品です。MCPサーバーは、それをつなぐケーブルにすぎません。どちらも必要ですが、難しいのはそのうちの一方だけです。
自分で作るか、すでにそれであるチームメイトを雇うか
つまり2つの正直な道があり、どちらが合うかは、その水面下のスタックをどれだけ自分で所有したいかによります。
自分で作る。 エージェントをヘルプデスクのMCPサーバーに配線するか(あるいは独自のラッパーを書くか)、その上にリトリーバル、ガードレール、エスカレーションロジック、評価用のハーネスを構築し、解決できたかどうかにかかわらず、メッセージごとのトークン単位のモデル料金を負担し続けます。サポート自動化そのものが、あなたが構築している製品であり、単に片付けたい仕事ではないのなら、これが正しい選択です。完全なコントロールが得られる代わりに、それをエンジニアリングの時間で支払うことになります。この方向を検討しているなら、カスタマーサポートエージェントAPIとAIヘルプデスクAPIの記事がより深く掘り下げています。
スタック全体を提供するチームメイトを雇う。 私がほとんどのサポートチームに勧めたいのはこちらで、eeselはまさにそのために作られています。あと4層をラップしなければならないMCPサーバーの代わりに、eeselはすぐに働けるAIヘルプデスクのチームメイトとして、リトリーバル、ガードレール、エスカレーションロジック、そして会社のコンテキストをあらかじめ備えた状態で登場します。すでに使っているヘルプデスク(Zendesk、Freshdesk、Gorgias、Front、Help Scout)に接続し、過去のチケットとヘルプセンターで学習するため、プロトコルというよりも新しく採用した社員に近い存在です。
そしてこの記事全体を締めくくると: eeselのワークスペースはそれ自体がMCPサーバーです。npx @eesel/cli mcp tokenを実行するとURLとトークンが表示され、Claude、Cursor、あるいは任意のMCPクライアントがあなたのeeselエージェントを操作できるようになります。同じプログラム可能なサーフェスには、本物のCLI、webhook、そしてドメインごとの認証を備えたアウトバウンドAPIアクセスも含まれます。つまり、到達可能な部分と賢い部分の両方を、1か所で手に入れられるということです。
私が最も強調したい差別化要因は、素のMCPという道では決して得られないものです。それは、エージェントが実際の顧客に触れる前に、あなた自身の過去のチケット数千件に対して実行できるシミュレーションです。私たちがこれを作ったのは、自信満々に聞こえるボットが静かに間違った回答をしているのを何度も見てきたからです。MCPサーバーからの200 OKは、接続がうまくいったことを示すだけで、回答が正しかったことは決して示しません。シミュレーションこそが、顧客より先にそれを知る方法です。
eeselを試す
ここまで読んだなら、あなたはすでに正直なバージョンを理解しています。MCPサーバーはコネクタであって、エージェントではありません。それをヘルプデスクに配線するのは午後ひとつ分の作業ですが、その周りにリトリーバル、ガードレール、評価を構築するのは四半期分の作業です。
eeselはそれを丸ごとスキップします。既存のヘルプデスクの上に数分でインストールできるAIヘルプデスクのチームメイトで、過去のチケットとドキュメントで学習し、MCPサーバーを含むスタック全体を備えて提供されます。本番稼働前に自社の過去のチケットでシミュレーションして解決率を確認したり、返信に人間による承認ステップを残したりでき、解決済みチケット1件あたり0.40ドルのセルフサーブ料金で、席数課金はありません。無料で試せます。
よくある質問
AIエージェントMCPサーバーとは何ですか?
MCPサーバーはAIエージェントと同じものですか?
大手ヘルプデスクにはMCPサーバーがありますか?
サポート向けにAIエージェントMCPサーバーを運用するのにどれくらい費用がかかりますか?
MCPサーバーのセキュリティリスクは何ですか?
Article by
Kira
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
