MCP導入の進め方｜FDEが現場で実践する5ステップと設計の勘所

MCPとは何で、なぜ企業導入が進んでいるのか？

MCPは、AIエージェントと社内外のツールやデータをつなぐオープン標準です。個別連携の開発コストを下げられるため、企業での採用が広がっています。

MCP（Model Context Protocol）は、Anthropicが2024年11月に公開したプロトコルです。LLMアプリケーションがファイル、データベース、SaaS、社内APIといった外部コンテキストにアクセスする方法を共通化しています。公開後はOpenAIやGoogle、Microsoftなど主要なAIベンダーも対応を表明しました。そのため、特定ベンダーの独自仕様ではなく、業界の共通インターフェースとして扱われるようになっています。

MCPの基本構造はどうなっているのか？

MCPは「ホスト・クライアント・サーバー」の3層で構成されます。通信にはJSON-RPC 2.0を使います。

サーバーが公開する機能は、主に次の3つです。

1. Tools：モデルが呼び出せる関数（チケット作成、SQL実行など）
2. Resources：モデルが参照できるデータ（ファイル、ドキュメント、レコード）
3. Prompts：再利用できる定型の指示テンプレート

通信方式（トランスポート）は2種類あります。ローカルで動かす場合はstdio、リモートで動かす場合はStreamable HTTPを使うのが基本です。

企業がMCPに注目する理由は何か？

企業が注目する一番の理由は、AIとツールの連携を「N×M問題」から解放できる点です。一度作った連携を、複数のAIアプリで使い回せます。

MCPがない場合、AIアプリがN個、ツールがM個あれば、最大でN×M通りの個別連携が必要になります。MCPに準拠すれば、ツール側はMCPサーバーを1つ用意するだけで、対応する複数のホストから使えます。FDEとして現場に入ると、「Copilotでも自社エージェントでも同じ社内データを使いたい」という要望は多い印象です。こうした要望に応えやすくなる点で、MCPは導入の動機を説明しやすい技術だと感じます。

MCPは従来のAPI連携と何が違うのか？

MCPはAPIを置き換えるものではありません。APIの手前に「AIが自分で理解して呼び出せる層」を加えるものです。

REST APIやGraphQLは、人間の開発者がドキュメントを読んで実装することを前提にしています。MCPでは、サーバーが自分の持つツールの名前・説明・入力スキーマをクライアントに伝えます。モデルはその説明を読んで、どのツールをいつ使うかを判断します。

機能面での違いはどこにあるのか？

一番の違いは、機能を動的に見つけられることと、モデルが呼び出す前提で設計されていることです。認証や実行の仕組み自体はAPIを使い続けます。

APIをそのままMCP化すればよいのか？

APIのエンドポイントを1対1でMCPツールに変換するやり方は、多くの場合うまくいきません。業務の単位でツールを設計し直す必要があります。

現場でよく見る失敗は、数十個のエンドポイントをそのままツールとして公開してしまうことです。ツールが多すぎるとモデルが選び間違えやすくなります。説明文がコンテキストを圧迫して、精度とコストの両方が悪くなりがちです。たとえば「顧客を検索する」「顧客の契約状況をまとめて返す」のように、ユーザーが実際にやりたいことの単位でツールをまとめると、安定しやすいと考えています。

MCP導入はどう進めるのが確実か？

確実に進めるには、ユースケースを1つに絞ることです。そのうえで、読み取り専用から段階的に広げる5ステップが有効です。

MCPは技術的には始めやすい反面、「とりあえずサーバーを立てた」で止まってしまうことが少なくありません。FDEの立場からは、業務成果につながる順番で進めることをおすすめします。

MCP導入の5ステップとは何か？

5ステップは「業務選定→データ棚卸し→ツール設計→検証→本番展開」です。各ステップの終わりに完了条件を決めておくことが大切です。

最初のユースケースはどう選ぶべきか？

最初は「読み取り中心」で、「間違えても被害が小さい」業務を選ぶのが安全です。書き込み系は2段階目以降に回しましょう。

候補になりやすいのは、社内ナレッジの検索、問い合わせ履歴の要約、データ分析の下調べなどです。反対に、発注、送金、顧客への送信のように外部へ影響が出る操作は、最初の対象から外しておくほうが無難です。私自身の感覚では、最初の数週間は「現場が毎日使うかどうか」を見るのが一番の評価指標になります。精度の数字よりも、継続して使われているかのほうが導入の成否を正直に表すことが多いです。

ツール設計で押さえるべき勘所は何か？

設計の勘所は「少ない数・明確な説明・狭い権限」の3点です。モデルが迷わない設計が、そのまま精度に効いてきます。

1. ツール数を絞る：1つのサーバーで公開するツールは、必要なものに限ります
2. 説明文は仕様書として書く：いつ使うか、いつ使わないかを明記します
3. 入力スキーマを厳密にする：列挙型や必須項目を指定して、自由入力を減らします
4. 出力は要約して返す：生データをそのまま大量に返さず、モデルが扱える量に整えます
5. エラーメッセージで次の行動を示す：「権限不足のため管理者に確認」のように、回復の手がかりを返します

MCP導入でFDEはどんな役割を担うのか？

FDEは、業務要件とMCPの技術設計の間を埋める役割を担います。PoCで終わらせず、現場に定着させるまで伴走する担当者です。

Palantirが広めたFDE（Forward Deployed Engineer）は、顧客の現場に入り込み、課題の発見から実装・定着までを担う職種です。MCP導入は、まさにFDEの強みが活きるテーマです。プロトコル自体はシンプルでも、「どの業務を、どのデータで、どの権限で」AIに任せるかは、現場を理解していないと決められないからです。

FDEが担う具体的な業務は何か？

FDEの業務は、要件の整理・ツール設計・評価・社内展開の4つに大きく分けられます。どれも現場との対話が出発点です。

エンジニア個人にはどんなスキルが求められるのか？

求められるのは、実装力に加えて「業務を言語化する力」と「セキュリティを設計する力」です。プロトコルの知識だけでは足りません。

技術面では、TypeScriptやPythonの公式SDKでMCPサーバーを実装できること、OAuthを含む認可の仕組みを理解していることが土台になります。ただ、FDEとして差がつくのは、現場の暗黙知をツールの説明文や評価セットに落とし込めるかどうかだと考えています。MCPに関わった経験は、FDE職を目指すエンジニアにとって、「AIを業務に実装した」ことを具体的に示せるポートフォリオになりやすい領域です。

MCP導入で注意すべきセキュリティと運用の課題は？

一番大きなリスクは、プロンプトインジェクションと過剰な権限の組み合わせです。最小権限と人間による承認で被害を抑える設計が欠かせません。

MCPを使うと、モデルが外部データを読み、外部システムを操作できるようになります。便利になる一方で、攻撃される面も広がります。MCPの仕様自体にも、セキュリティに関するベストプラクティスが盛り込まれるようになってきました。それでも、運用側の設計に任される部分は大きいままです。

代表的なセキュリティリスクは何か？

代表的なリスクは、インジェクション・ツール汚染・権限の過剰付与・トークンの不適切な扱いの4つです。それぞれ別の対策が必要です。

特に注意したいのは、「社内データを読める」「外部に送信できる」「信頼できない入力を読む」の3つが1つのエージェントにそろう構成です。この組み合わせはデータ流出につながりやすいため、設計の段階で分けておくことをおすすめします。

運用で見落としがちな課題は何か？

見落としやすいのは、サーバーの乱立・監査ログの不足・仕様の改訂への追従です。導入より運用のほうが長く続きます。

1. 野良サーバーの乱立：各部署が独自にMCPサーバーを立てると、誰がどのデータにアクセスしているか把握できなくなります。社内のサーバー登録簿やゲートウェイで一元管理する方法が考えられます
2. 監査ログ：「誰の依頼で、どのツールが、どの引数で呼ばれたか」を記録しないと、事故が起きたときに原因を追えません
3. 仕様の改訂：MCPの仕様は日付付きのバージョンで改訂が続いています。SDKやサーバーの更新計画を運用に組み込んでおく必要があります
4. コストと遅延：ツールの説明文や大きなレスポンスはトークン消費を増やします。定期的に棚卸しすると効果があります

現場の実感としては、PoCの段階でセキュリティ担当者を巻き込んでおくと、本番展開のときの手戻りが大きく減ります。MCPは「つなげば動く」技術だからこそ、どこまでつなぐかを決める判断が、導入する側の腕の見せどころです。FDEはその判断を、技術と業務の両方の言葉で説明できる立場にいます。

姉妹メディアの関連記事