MCPサーバーとは？AIエンジニアが今知るべき連携の仕組み

目次

---

1. MCPサーバーとは何か

MCPサーバーとは、AIアプリケーションやAIエージェントに対して、外部データ、業務ツール、定型ワークフローを標準化された形で公開するためのサーバーです。MCPはModel Context Protocolの略で、AIがファイル、データベース、SaaS、社内API、検索システムなどとやり取りするための共通プロトコルとして使われます。

AIエージェントを実務で使うと、モデル単体の知識だけでは足りません。社内ドキュメントを読む、チケットを検索する、顧客情報を確認する、ブラウザを操作する、計算する、下書きを作る、場合によってはシステムへ更新をかける。こうした外部との接続を、アプリごと・モデルごと・ツールごとに個別実装していると、連携コード、認証、権限、ログ、エラー処理がばらばらになります。

MCPサーバーは、このばらばらになりやすい接続部分を「AIが理解しやすいツールやリソース」として整理します。AIアプリケーション側は、MCPクライアントを通じてMCPサーバーに接続し、利用可能な機能を発見し、必要に応じて呼び出します。たとえるなら、MCPサーバーはAIにとっての業務システム窓口であり、AIが外部世界へ安全に触れるための接続口です。

この記事では、MCPサーバーを初めて調べるAIエンジニアやIT担当者に向けて、Host・Client・Serverの関係、Resources・Tools・Promptsの違い、REST API連携との違い、社内導入時の設計ポイントを整理します。既存記事ではMCPの本番運用やセキュリティ設計を扱っているため、今回はその前段となる「仕組みの理解」に集中します。

2. なぜAIエージェントにMCPが必要なのか

生成AIの初期活用では、ユーザーがチャット画面に情報を貼り付け、AIが文章を要約したり、回答を作ったりする使い方が中心でした。この段階では、AIは受け取ったテキストだけを見て動きます。ところが、AIエージェントとして業務を任せる段階になると、AIは最新の社内情報を取りに行き、複数のツールを使い分け、途中結果を確認しながらタスクを進める必要があります。

たとえば、開発支援AIに「この障害の原因を調べて」と依頼したとします。実務では、コードだけでなく、Gitの変更履歴、監視ログ、チケット、過去の障害報告、デプロイ履歴、ブラウザ上の再現手順まで見なければ判断できません。これらを毎回人間が貼り付けていては、AIエージェントの意味が薄れます。AIが必要な情報へ自分でアクセスできる状態が必要です。

従来のやり方では、AIアプリケーションごとに個別のAPI連携を実装していました。あるAIツールにはSlack連携、別のAIツールにはGitHub連携、さらに別のAIツールには社内DB連携、といった具合です。この構成はPoCでは速く見えますが、運用が進むほど問題が出ます。認証方式がばらばらになり、権限管理が分散し、ログの粒度が合わず、モデルやAIアプリを変えるたびに連携を作り直すことになります。

MCPは、この問題を「AIアプリケーション」と「外部システム」の間に標準化された接続層を置くことで解決しようとする仕組みです。AIアプリケーションはMCPクライアントとしてMCPサーバーに接続し、サーバーが公開するResources、Tools、Promptsを使います。外部システム側は、MCPサーバーとして必要な機能を提供します。

重要なのは、MCPが単なるAPIラッパーではないことです。AIが使う前提で、ツール名、説明、入力スキーマ、リソースURI、ワークフローの意味を整理します。つまり、MCPサーバーを作る作業は、外部APIをAI向けに翻訳し、AIが安全に使える粒度へ分解する作業でもあります。

3. Host・Client・Serverの役割を整理する

MCPを理解するときに最初につまずきやすいのが、Host、Client、Serverという言葉です。どれも似て見えますが、役割ははっきり分かれています。

Hostは、ユーザーが実際に使うAIアプリケーションです。たとえば、AIチャット、AIコーディングツール、業務AIダッシュボード、社内AIエージェント基盤などがHostに当たります。ユーザーはHostに自然言語で依頼し、Hostはモデル、会話履歴、UI、認証、MCP接続などをまとめて扱います。

Clientは、Hostの中でMCPサーバーと通信する部品です。ユーザーが直接Clientを意識することはあまりありません。Clientは、どのMCPサーバーに接続するか、どの機能が利用できるか、ツール呼び出しの結果をどうHostへ戻すかを担当します。MCPでは、ClientとServerが標準化された手順でやり取りすることで、AIアプリケーション側の実装負担を下げます。

Serverは、実際に外部データや業務ツールへ接続する側です。たとえば、社内ドキュメントを検索するMCPサーバー、Gitリポジトリを読むMCPサーバー、CRMから顧客情報を取得するMCPサーバー、PlaywrightやChromeを操作するMCPサーバーなどがあります。Serverは、外部システムをそのまま丸ごとAIへ渡すのではなく、AIが使える機能としてResources、Tools、Promptsを公開します。

この構造にすると、AIアプリケーションを変えても、MCPサーバー側の連携資産を再利用しやすくなります。逆に、社内ツールが増えても、Host側はMCPという共通の入り口を通じて扱えます。企業でMCPが注目される理由は、この再利用性と分離にあります。

4. Resources・Tools・Promptsの違い

MCPサーバーが公開する代表的な要素は、Resources、Tools、Promptsです。ここを曖昧にしたまま設計すると、何でもToolにしてしまい、AIが読み取るだけでよい情報まで実行操作として扱ってしまいます。

Resourcesは、AIに渡す文脈やデータです。ファイル、データベーススキーマ、ドキュメント、設定情報、アプリケーション固有の状態などが該当します。Resourcesは「AIが参照するもの」と考えると分かりやすいです。たとえば、file://manuals/security-policy.md、db://schema/customers、ticket://incident/1234 のように、URIで識別できる情報として公開します。

Toolsは、AIが呼び出せる関数や操作です。検索する、計算する、APIを呼ぶ、チケットを作る、ブラウザを開く、メールの下書きを作る、といった動作が該当します。Toolsは入力スキーマと説明を持ち、AIはその説明をもとに、どのツールを呼ぶべきか判断します。つまり、Toolの説明文は人間向けの補足ではなく、AIの行動に影響する設計情報です。

Promptsは、再利用できる定型プロンプトやワークフローです。たとえば、障害調査の手順、コードレビューの観点、議事録要約の型、問い合わせ回答のテンプレートなどを、MCPサーバー側から提供できます。Promptsを使うと、ユーザーが毎回長い指示を書かなくても、組織として決めた手順や品質基準をAIに渡しやすくなります。

実務では、次のように分けると設計しやすくなります。

設計のコツは、「読むだけでよいもの」と「実行するもの」を分けることです。社内文書を参照するだけならResourceで足ります。検索条件を受け取って結果を返すならToolにします。複数の確認ステップを含む作業手順を標準化したいならPromptとして用意します。

5. REST API連携との違い

MCPを説明するとき、「結局REST APIと何が違うのか」と聞かれることがあります。これは自然な疑問です。MCPサーバーの裏側では、結局どこかのREST APIやGraphQL、DB、ファイルシステム、CLIを呼ぶことが多いからです。

違いは、対象が人間の開発者ではなくAIアプリケーションである点です。REST APIは、開発者が仕様書を読み、エンドポイントを選び、必要なパラメータを組み立て、エラー処理を実装する前提で設計されています。一方、MCPサーバーは、AIが「どの機能を使うべきか」を判断しやすいように、ツールの意味、入力スキーマ、説明、リソースの扱いを整理します。

たとえば、CRMのREST APIには GET /customers/{id}、PATCH /customers/{id}、POST /notes のようなエンドポイントがあるかもしれません。これをそのままAIへ渡すと、AIは業務文脈を理解しながらAPI仕様を選ぶ必要があります。MCPサーバーでは、これを 顧客情報を検索する、商談メモの下書きを作る、承認済みのメモを登録する といった、AIと業務に近い単位へ変換できます。

REST APIとMCPの関係は、対立ではありません。MCPサーバーの裏側でREST APIを使い、表側ではAI向けのToolsやResourcesとして公開する、という構成が現実的です。

MCPを導入しても、既存API設計が不要になるわけではありません。むしろ、既存APIをAIが使いやすい形へ変換し、権限、ログ、承認、入力検証を挟むための層としてMCPサーバーを置くと考えるのが実務的です。

6. 社内ツール連携での設計ポイント

MCPサーバーを社内ツール連携に使う場合、最初から多機能な万能サーバーを作ろうとしない方がよいです。AIが何でもできる状態は魅力的ですが、運用では権限、監査、エラー処理、誤操作のリスクが一気に増えます。最初は業務単位で小さく切り、読み取り中心から始めるのが現実的です。

まず決めるべきなのは、MCPサーバーの責務です。たとえば、問い合わせ対応用のMCPサーバーなら、社内FAQ検索、顧客契約状況の読み取り、回答テンプレートの取得までに絞る。開発支援用なら、リポジトリ検索、Issue確認、CIログ取得、テスト結果要約に絞る。経理支援用なら、請求書検索や支払状況確認に絞る。責務を分けると、権限とログも整理しやすくなります。

次に、Toolの粒度を決めます。低レベルなAPIをそのままToolにすると、AIが組み合わせを間違えやすくなります。逆に、業務に寄せすぎた巨大なToolにすると、内部で何が起きたのか追いにくくなります。実務では、「人間が承認しやすい単位」「ログで追いやすい単位」「失敗時にやり直せる単位」に分けるのが目安です。

たとえば、外部送信を含む業務では、send_email のような直接実行Toolをいきなり公開するより、まず draft_email_reply を作る方が安全です。AIは下書きを作り、人間が確認してから送信する。この段階でMCPサーバーに承認フローやログを組み込めば、本番運用へ進めやすくなります。

社内導入で見落としやすいのは、Tool説明文のレビューです。AIはTool名と説明文を読んで使い分けます。説明文が曖昧だと、AIは意図しない場面でToolを呼ぶ可能性があります。たとえば「顧客情報を更新する」だけでは広すぎます。「承認済みの商談メモだけをCRMに追加する」「契約金額や請求先情報は変更しない」のように、できることとできないことを明確に書く必要があります。

最後に、MCPサーバーは実装だけでなく運用対象として扱います。誰が管理するのか、どのHostから接続できるのか、認証情報はどこに置くのか、ログを何日保存するのか、モデル変更時に再評価するのか。これらを決めないままMCPサーバーだけ増やすと、AI連携の入口が社内に散らばります。

7. MCPサーバー導入前チェックリスト

MCPサーバーを初めて作る場合は、次の項目を確認すると設計の抜け漏れを減らせます。

このチェックリストの狙いは、最初から大規模なMCP基盤を作ることではありません。小さなMCPサーバーでも、責務、権限、ログ、承認を最初に決めておくことです。AIエージェント開発では、動くデモを作ることより、業務に残せる連携資産にすることが重要になります。

8. まとめ

MCPサーバーは、AIエージェントと外部システムをつなぐための標準化された接続口です。Host、Client、Serverの役割を分け、Resources、Tools、Promptsを整理することで、AIが社内データや業務ツールを扱いやすくなります。

ただし、MCPサーバーは単なる便利なAPIラッパーではありません。AIが使う前提で、Toolの意味、入力スキーマ、説明文、権限、ログ、承認を設計する必要があります。REST APIをそのままAIへ渡すのではなく、業務に合った安全な粒度へ翻訳することが、MCPサーバー設計の本質です。

OpenBridgeでは、AIエージェント開発、MCPサーバー設計、社内ツール連携、RAG、ローカルAI、AI利用ログ設計まで一貫して支援しています。MCPを導入する際は、まず小さな読み取り系ツールから始め、業務に必要なResources、Tools、Promptsを整理し、段階的に本番運用へ広げるのがおすすめです。