MCPサーバーとは？仕組み・使い方・安全な選び方【2026年】

MCPサーバーとは、AIアプリケーションに外部データや操作機能を提供するプログラムです。AIとファイル、データベース、業務SaaSなどの接続方法を共通化します。

MCPはModel Context Protocolの略です。接続ごとに専用連携を作る負担を減らせる一方、導入すれば自動的に安全になる規格ではありません。企業では、サーバーへ渡すデータと実行権限を先に整理する必要があります。

本記事は、MCP公式ドキュメントと公式仕様を基に解説します。2026年7月31日の確認時点では、仕様の「Latest」URLは2026年7月28日版へ転送されます。仕様は更新されるため、実装時には必ず最新版と利用するSDKの文書を確認してください。

MCPサーバーとは？AIと外部システムをつなぐ機能提供側

MCPサーバーは、MCPに沿って外部システムの機能を公開する側です。たとえば、指定した文書を読む機能や、業務システムへ登録する機能を提供します。AIモデルそのものや、利用者が会話する画面を指す言葉ではありません。

MCP全体の成り立ちや仕様範囲は、MCPとは何かを解説した記事もご覧ください。

従来の個別連携と何が違うのか

従来は、AIアプリと外部サービスの組み合わせごとに接続処理を作る方法が一般的でした。認証、機能一覧、引数、結果形式、エラー処理を個別に実装する必要があります。接続先やAIアプリを変更すると、連携部分の改修も発生しやすい設計です。

MCPは、機能の発見や呼び出しなどの共通ルールを定めます。AIアプリと外部システムが同じプロトコルへ対応すれば、連携資産を再利用しやすくなります。ただし、業務API自体が不要になるわけではありません。MCPサーバーの内部から既存APIを呼び出す構成も一般的です。

MCPサーバーが提供するTools・Resources・Prompts

MCPサーバー側の主要なプリミティブは、Tools、Resources、Promptsの3つです。名称が似ていても、利用目的とリスクが異なります。

要素	役割	企業での例	主な注意点
Tools	処理や操作を実行する	顧客情報の検索、チケット登録、集計処理	更新・削除・送信などの副作用
Resources	データや文脈を提供する	規程、設計書、データベースの読み取り結果	機密情報と閲覧権限
Prompts	再利用できる作業手順を提示する	議事録整理、レビュー手順、定型分析	指示内容と入力データの妥当性

Toolsは、モデルが利用候補として選べる実行機能です。説明文だけでなく、実際に何を変更できるかで危険度を判断します。読み取りと削除を同じ権限区分にしないことが基本です。

ResourcesはAIが参照する情報、Promptsは利用者が選べる作業テンプレートです。いずれも元システムの権限を引き継ぎ、必要な範囲だけを公開します。

MCPホスト・クライアント・サーバーの仕組み

公式アーキテクチャでは、Host、Client、Serverを明確に区別しています。「MCPクライアント」という言葉だけでAIアプリ全体を指す説明もあります。しかし、責任分界を考える際は3役に分ける方が正確です。

構成要素	主な役割	企業が確認する事項
MCP Host	ユーザー体験、許可、複数接続を統括	誰が接続を許可し、実行を承認するか
MCP Client	特定サーバーとの接続とセッションを維持	接続先、対応機能、セッション管理
MCP Server	Tools・Resources・Promptsを公開	実行権限、データ範囲、認証、ログ

MCP Hostは許可・接続・ユーザー体験を管理する

Hostは、利用者が操作するAIアプリケーション側の統括役です。サーバーへの接続、利用許可、モデルとの情報連携などを管理します。企業では、Hostの承認画面や管理者ポリシーも安全性を左右します。

MCP Clientは特定サーバーとのセッションを維持する

Clientは、Hostの内部で特定のMCPサーバーとの通信を担当します。通常は、1つのClientが1つのServerとの論理的な接続を維持します。機能一覧の取得や、要求と応答の受け渡しも担います。

MCP Serverは機能を公開する

Serverは、接続先のデータや操作をMCP形式で公開します。ローカルファイルを扱う小さなプロセスも、ネットワーク上のサービスもServerになれます。既存のAPIやデータベースを包むアダプターとして作ることも可能です。

接続から機能利用までの基本フロー

基本的な流れは次のとおりです。

1. HostがClientを通じてServerへ接続します。
2. 双方が対応機能などを確認し、接続を初期化します。
3. Clientが利用可能なTools、Resources、Promptsを取得します。
4. 利用者の依頼に応じて、Hostやモデルが使う機能を判断します。
5. 必要に応じて利用者が実行を承認します。
6. ClientがServerへ要求を送り、Serverが処理結果を返します。
7. Hostが結果をモデルや利用者へ提示します。

モデルが外部システムへ直接接続するとは限りません。問題発生時に備え、各層のログと責任者を決めておきます。

MCPサーバーとAPI・RAG・Function Callingの違い

MCP、API、RAG、Function Callingは競合製品ではありません。それぞれ異なる層を担い、1つのシステムで併用できます。

項目	主な目的	主な役割	MCPとの関係
MCP	AIと外部機能の接続方法を共通化	機能発見、データ取得、呼び出し	接続インターフェース
API	システム同士が通信する窓口を提供	業務処理やデータを公開	Server内部から利用できる
RAG	関連情報を検索して回答根拠へ加える	検索、絞り込み、文脈付与	検索機能をMCPで公開できる
Function Calling	モデルが構造化された関数呼び出しを生成	関数選択と引数生成	Host側でTool利用に使える

MCPとAPIは競合ではなく標準化層と実装手段

APIは、サービス固有のデータや処理を公開する手段です。一方のMCPは、AIアプリが外部機能を見つけて使う接続方法を標準化します。MCPサーバーが既存APIを呼び、結果をToolやResourceとして返す構成も取れます。

既存APIの前段にMCPサーバーを置く構成も可能です。APIの基礎はOpenAI APIの解説も参考にしてください。

RAGは知識検索、MCPは接続インターフェース

RAGは、質問に関連する情報を検索して、モデルの回答根拠へ加える設計です。MCPは検索方式を定めません。キーワード検索、ベクトル検索、データベース検索のいずれも接続先になり得ます。

RAGの検索機能をMCP Toolとして公開することも可能です。Resourcesとして文書を提示し、Host側で回答生成に使う構成も考えられます。設計と評価方法はRAGの仕組みと導入ガイドで解説しています。

Function Callingはモデル側、MCPは接続側の標準化

Function Callingは、モデルが利用すべき関数と引数を構造化して出力する仕組みです。MCPは、Serverが公開するToolの発見や呼び出しを共通化します。HostがMCP Toolをモデルへ伝える際に、Function Callingを使う場合があります。

つまり、Function Callingだけでも独自連携は作れます。複数のHostで再利用する場合にMCPが役立ちます。

MCPサーバーの主な種類と企業での活用例

MCPサーバーは、製品名のランキングより用途で分類すると選びやすくなります。同じサービス向けでも、提供元や権限範囲、運用方式が異なる場合があります。

ファイル・社内文書

ファイルや文書管理システムの内容を読み、検索や要約に利用する種類です。規程の確認、提案資料の下調べ、複数文書の差分整理などに使えます。

対象フォルダと拡張子を絞り、共有領域全体を無条件に公開しないでください。

ソースコード・開発管理

リポジトリ、Issue、変更履歴、CI結果などへ接続する種類です。調査、レビュー補助、Issue作成、定型的な更新に利用できます。Claude Codeでの具体的な接続は、Claude Code MCP連携ガイドもご覧ください。

本番変更は高リスクです。最初は読み取り専用とし、既存のレビューを残します。

データベース・分析

データベースへの問い合わせや集計処理を提供する種類です。自然言語による分析補助や、定例レポートの下準備に向いています。

接続ユーザーは参照専用とし、表、件数、実行時間を制限します。

Web・業務SaaS

Web検索や、顧客管理、プロジェクト管理などへ接続する種類です。情報収集から登録までを一つの対話で進められる点が利点です。

下書きと送信を別Toolにし、外部送信前の確認と監査ログを残します。

---

MCPを含む生成AI連携の要件整理や安全な導入計画にお悩みの場合は、株式会社NexaのAI顧問サービスへご相談ください。

---

ローカルMCPサーバーとリモートMCPサーバーの違い

代表的な接続方式は、ローカル用途のstdioと、ネットワーク経由のStreamable HTTPです。配置場所だけで安全性を判断せず、実行主体と権限を確認してください。

比較軸	ローカル／stdio	リモート／Streamable HTTP
主な配置	利用者端末や同一環境	社内サーバーやクラウド
通信	標準入力・標準出力	HTTPリクエスト
認証	プロセス起動と端末権限が中心	HTTP認証や認可が重要
更新	各端末への配布管理が必要	サーバー側で集中更新しやすい
監査	端末ごとのログ収集が必要	集中監査を設計しやすい
主なリスク	ファイル、環境変数、子プロセス	トークン、通信先、セッション、公開範囲

ローカルは端末権限・依存パッケージを審査する

stdioでは、HostがServerを子プロセスとして起動し、入出力で通信します。ネットワークへ公開しない構成を取りやすい点は利点です。ただし、「ローカルだから安全」とは限りません。

Serverは、起動した利用者の権限でコードとして動きます。ファイル、環境変数、認証情報、子プロセス、外部通信へ触れる可能性があります。配布元、依存パッケージ、起動内容、更新経路を確認してください。

リモートは認証・通信先・集中監査を確認する

Streamable HTTPは、複数利用者への提供や集中運用に向いています。一方で、ネットワーク越しの攻撃と認証情報の管理が必要です。HTTPS、認証・認可、Origin検証、接続先制限を設けます。

セッション識別子は認証情報の代わりではありません。推測困難にし、安全に保管し、利用者とのひも付きを検証します。社内向けでも、インターネット公開と同等の前提で境界を設計してください。

企業は5軸でローカルとリモートを選ぶ

比較時は、次の5軸を並べると判断しやすくなります。

1. 実行主体：誰の権限で処理が動くか
2. データ送信先：入力と結果がどこを通り、保存されるか
3. 認証情報：誰が発行し、どこへ保存し、いつ失効するか
4. 操作範囲：読み取り、更新、削除、外部送信のどこまで可能か
5. 監査能力：誰が何を実行したか追跡できるか

小規模な検証ではstdio、全社提供では集中管理できるリモートが候補です。ただし、最適解は用途と統制要件で変わります。

MCPサーバーを安全に選ぶ6つのチェックポイント

「おすすめ一覧」から選ぶ前に、以下の6項目を確認してください。MCP RegistryやGitHubへの掲載は、互換性を探す手掛かりです。掲載されているだけで、企業利用の安全性が保証されるわけではありません。

1. 提供元と保守状況

公式提供か、第三者提供か、社内開発かを確認します。リポジトリの所有者、ライセンス、リリース履歴、脆弱性報告窓口も確認対象です。名称が似た偽パッケージを避け、公式文書から配布先をたどってください。

仕様変更や脆弱性へ対応する体制と、更新停止時の代替策も確認します。

2. 渡すデータと保存先

Serverへ送る入力、返る結果、ログに残る内容を整理します。個人情報、顧客情報、認証情報、ソースコードなどを分類してください。外部事業者を使う場合は、保存地域、保持期間、再利用条件も確認します。

必要な要求だけを送り、本文やトークンを無条件にログへ残しません。

3. 必要権限とOAuthスコープ

権限は「動作する最小範囲」に絞ります。読み取りだけの用途に、更新や削除のスコープを与えてはいけません。組織全体の管理者トークンではなく、用途別の専用資格情報を使います。

共有の強い権限で動かさず、利用者、用途、環境ごとに認可します。

4. 実行環境と外部通信

ローカルServerなら、読めるディレクトリや実行できるコマンドを確認します。コンテナや専用ユーザーで分離し、不要な外部通信を制限する方法が有効です。依存パッケージの取得元と固定方針も管理します。

リモートでは公開範囲と転送先を確認し、許可する宛先を限定します。

5. 操作確認と監査ログ

更新、削除、送信、購入、本番変更などは実行前確認を設けます。可能であれば、変更内容だけを表示するdry-runを用意します。重要操作では、申請者と承認者を分ける方法も有効です。

ログには利用者、時刻、Tool、対象、結果を残し、秘密情報はマスキングします。

6. 接続解除・失効・緊急停止

導入前に止め方を確認します。Serverの無効化、トークン失効、Client接続解除、通信遮断を短時間で行える状態が理想です。担当者が不在でも実施できる手順書を用意します。

資格情報を定期更新し、使われていない接続を削除します。

MCPサーバーの危険性と企業が取るべき対策

MCPの危険性は、AIが外部データを読むだけでなく操作も実行できる点にあります。ただし、危険だから避けるのではなく、信頼境界と権限を明確にすることが重要です。

Toolsを実行権限として分類する

Toolを読み取り、作成、更新、削除、外部送信、本番変更に分類します。名称ではなく実装と権限を確認し、後者ほど強い承認と件数制限を設けます。

token passthroughと資格情報混同を避ける

token passthroughを避け、対象、発行者、有効期限、スコープを検証します。MCPと下流APIの認可を分け、キャッシュやセッションも利用者単位で分離します。

Confused Deputy・SSRF・セッションハイジャックを想定する

Confused Deputy対策では、操作対象と利用者の意図を処理ごとに確認します。SSRF対策では、URLの宛先とリダイレクト後の接続先を制限します。セッションはHTTPSで扱い、短い有効期限と利用者へのひも付けを徹底します。

Rootsをサンドボックスと誤認しない

Rootsは扱うべき範囲を示しますが、完全なOSサンドボックスとは限りません。OS権限、専用ユーザー、コンテナを併用し、強制できる境界を設けます。

プロンプトインジェクション前提で承認を残す

外部文書中の指示をモデルが命令と誤認する可能性があります。権限変更や外部送信を自動化せず、重要操作には利用者の明示承認を残します。

MCPサーバーを導入する7ステップ

企業導入では、設定から始めず、目的と禁止事項から決めます。次の7ステップなら、小さな検証から本番運用へ移行できます。

1. ユースケースと禁止操作を決める

対象業務、利用者、期待成果を一つに絞ります。削除、外部送信、本番更新など、検証中の禁止操作も定義します。

2. 対応Hostを確認する

必要なMCP機能とTransportへの対応を確認します。管理者制御、承認表示、ログ出力の有無も比較してください。

3. ServerとTransportを選ぶ

公式配布元を確認し、用途と提供範囲に合うServer、Transportを選びます。配布や更新を担う保守責任者も決めます。

4. データ・権限・認証を棚卸しする

入力、出力、保存、ログのデータフローを図にします。APIスコープ、ファイル範囲、通信先、認証情報の担当者を一覧化します。

5. 分離した検証環境で起動する

検証用アカウントとテストデータを使い、最初は読み取り専用にします。本番の認証情報は流用せず、件数や実行時間へ上限を設けます。

6. Inspectorなどで動作を確認する

MCP Inspectorなどで公開機能を確認します。不正入力や権限不足に加え、ログと承認もテストします。

7. 段階導入し、監査・失効・停止を運用する

限定利用から始め、更新時は再テストします。権限棚卸し、ログ監査、緊急停止訓練を継続してください。

MCPサーバーを自作する基本手順

既存Serverが要件に合わない場合は自作できます。ただし、仕様追従、認証、監視、脆弱性対応は自社の責任です。

TypeScript SDKまたはPython SDKを選ぶ

公式にはTypeScript SDKとPython SDKがあります。保守体制と実行環境に合うSDKを選びます。固定コードを転用せず、対象バージョンのREADMEと公式仕様を参照してください。

最小限のTools・Resources・Promptsを定義する

Toolの入力、出力、副作用、必要権限を文書化します。Resourcesの公開範囲を絞り、Promptsは目的が分かる形にします。

入力検証・認証・エラー処理・ログを実装する

モデルが生成した引数も外部入力として検証し、下流APIでも認可します。秘密を含まないエラーと監査ログを残し、二重登録も防いでください。

Inspectorと検証用Clientでテストする

Inspectorに加え、実際に使うHostからも接続して対応差を確認します。権限外の対象や内部URLを試し、dry-runと承認が働くかテストします。

MCPサーバーに関するよくある質問

MCPサーバーは無料ですか？

MCPという仕様はオープンですが、利用費が必ず無料とは限りません。Serverの提供条件、接続先サービス、API利用、クラウド実行環境などで費用が発生します。未確認の料金表ではなく、提供元と接続先の最新条件を個別に確認してください。

MCPサーバーは会話をすべて読めますか？

必ず会話全体を読めるわけではありません。Serverが受け取る内容は、Hostの実装と利用機能によって変わります。ただし、Toolの引数やResource要求には、依頼内容や機密情報が含まれる可能性があります。

導入前に、HostからServerへ何が送信されるかを検証してください。Serverのログと外部送信先も確認し、不要な情報を渡さない設計にします。

GitHubにあるMCPサーバーは安全ですか？

公開されているだけでは安全と判断できません。ソースコードを読めることは審査の利点ですが、悪意や脆弱性がない保証ではありません。提供元、依存関係、権限、通信先、更新履歴を確認してください。

公式のServersリポジトリも探索の起点にできます。ただし、掲載と企業向けの安全保証は別と考え、検証環境で審査します。

ローカルとリモートのどちらが企業向けですか？

一律の答えはありません。ローカルは端末内で完結させやすい一方、各端末の配布と監査が課題です。リモートは集中管理しやすい一方、認証とネットワーク境界の設計が必要です。

利用者数、データ機密性、更新頻度、監査要件、運用体制の5軸で選んでください。方式にかかわらず、最小権限と停止手順は必要です。

MCPサーバーはどこで探せますか？

接続先サービスの公式ドキュメントを最初に確認してください。そのうえで、MCP Registryや公式Serversリポジトリを探索の起点にできます。パッケージ名だけで検索せず、公式サイトから配布元へ移動すると偽装を避けやすくなります。

MCPサーバーの作成に必要なものは？

公開する業務機能、接続先のAPIやデータ、対応SDK、実行環境が必要です。加えて、認証・認可、入力検証、ログ、監視、停止方法を設計します。試作品を動かすだけでなく、保守責任者と更新手順まで決めて完成です。

まとめ｜MCPサーバーは小さく試し、権限とデータを管理する

MCPサーバーは、AIへTools、Resources、Promptsを共通仕様で提供するプログラムです。Hostが利用体験と許可を統括し、ClientがServerとの接続を維持します。Serverは機能提供側であり、生成AIモデルそのものとは限りません。

APIは業務機能の窓口、RAGは検索を使う設計、Function Callingはモデル側の呼び出し機構です。MCPはそれらを置き換えず、AIとの接続を標準化する層として組み合わせられます。

企業は、提供元、データ、権限、実行環境、監査、停止方法の6項目で選定してください。ローカルでもコードは利用者権限で動くため、無条件に安全ではありません。最初は単一用途、読み取り専用、検証環境から始める方法が堅実です。

社内データとAIをつなぐ前に、権限・データ・運用を整理したい場合は、株式会社NexaのAI顧問サービスをご活用ください。

出典・参考資料

本記事は、以下の公式一次情報を2026年7月31日に確認して作成しました。「Latest」は確認時点で2026年7月28日版へ転送されます。

• MCP公式ドキュメント：Introduction
• MCP公式ドキュメント：Architecture
• MCP公式仕様：Latest
• MCP公式仕様：Transports
• MCP公式仕様：Authorization
• MCP公式仕様：Security Best Practices
• MCP公式GitHub：Servers
• MCP Inspector
• MCP Registry