MCPサーバーとは｜2026年版の仕組み・権限境界・導入判断

MCPサーバーとは、AIアプリケーションのMCPクライアントに対し、ツール、リソース、プロンプトなどのコンテキストと機能をModel Context Protocolで提供するプログラムです。AIモデルそのものでも、データベースそのものでもありません。ローカルプロセスとして動く場合も、ネットワーク上のリモートサービスとして動く場合もあります。

この記事は、MCPという名称を知った導入責任者、開発者、情報システム担当者が、API直結や個別コネクターと比べて採用すべきか判断するための定義記事です。2026年7月28日版仕様の大きな変更を前提に、旧版の実装説明を混ぜず、導入評価票まで作ります。

MCPサーバーを一文で定義し、host・clientと役割を分ける

MCPサーバーは、MCPで接続する相手へ専門的なコンテキストと機能を公開するプログラムです。公開対象には、実行可能なtools、参照用のresources、再利用可能なpromptsがあります。サーバーが提供するものを、AIアプリケーション側のMCP hostが利用者体験、モデル連携、接続許可、セキュリティ方針と組み合わせます。

2026年7月28日版の公式Architectureは、MCPをclient-host-server構成としています。hostが複数のclientを管理し、一つのclientが一つのserverと通信する構成です。serverは独立した責務に集中し、hostは接続権限、同意、認可判断、複数serverからのコンテキスト統合を扱います^[1]。したがって「MCPサーバーへ接続すればAIが安全に全部使える」という理解は誤りです。

MCPサーバーは「AIに何でもさせる箱」ではなく、AIアプリケーションが利用できる文脈と操作を、発見可能な共通インターフェースとして提示する境界です。

MCPサーバーに関する五つの誤解を現行仕様で訂正する

第一の誤解は、MCPサーバーが必ず遠隔のWebサーバーだというものです。公式仕様はローカルプロセスとリモートサービスの両方を認めます。stdioは同じ端末上のプロセス間、Streamable HTTPはリモート通信で使えます。配置場所とserverという役割名を混同しません。

第二の誤解は、MCPがAIモデルやエージェントの判断方法まで決めるというものです。MCPはコンテキスト交換のプロトコルであり、モデルの選択、推論、最終的な業務判断、利用者画面を規定しません。host側が、モデルへどのtoolを見せるか、呼び出しを承認させるか、結果をどう会話へ戻すかを決めます。

第三の誤解は、接続しただけで認証・認可・安全性が完成するというものです。HTTPの認可仕様は用意されていますが、業務上の行レベル権限、承認、機密区分、削除禁止、監査保管は実装と運用で設計します。ローカル接続でもプロセス権限と利用可能データを限定します。

第四の誤解は、MCP serverが会話全文や他serverを自由に見られるというものです。Architectureは、serverが必要なコンテキストだけを受け取り、会話全体はhostに残り、server間の相互作用をhostが制御する設計原則を示しています^[1]。

第五の誤解は、2025年版のinitializeとsession IDが現行でも前提だというものです。2026年7月28日版ではプロトコルがstatelessになり、initialize handshakeとMcp-Session-Idが削除されました。新規設計は旧チュートリアルをそのまま写さず、版互換性を先に確認します^[2]。

2026年7月28日版MCPの発見・一覧・呼び出しを順に追う

現行MCPはJSON-RPC 2.0を基礎にし、データ層とtransport層を分けます。データ層には版と能力の発見、tools・resources・prompts、要求・応答、通知などがあります。transport層は同一端末のstdio、またはリモート向けのStreamable HTTPを扱います。MCPサーバーの業務ロジックは、この通信の内側で接続先APIやファイルへアクセスします。

2026年版では各要求が自己完結し、要求の_metaにprotocolVersion、clientCapabilities、原則としてclientInfoを含めます。serverは必須のserver/discoverで対応版、能力、識別情報を通知します。

clientは版を選び、利用したい機能が能力として宣言されているか確認します。版が合わない場合はUnsupportedProtocolVersionErrorで継続しません。公式Key Changesは、このstateless化、server/discover追加、initialize削除を主要変更として明示しています^[2]。

toolを使う流れは、発見、一覧、選択、呼び出し、結果返却です。clientがtools/listを送り、serverは現在の認可で利用できるtool名、説明、inputSchemaなどを返します。AIアプリケーションは候補をモデルへ提示し、モデルのtool callを受け取った後、hostのポリシーと利用者承認を確認してtools/callへ変換します。serverは引数を検証し、処理結果またはエラーを返します。

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "customer_lookup",
    "arguments": {"customer_id": "C-1042"},
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "support-host",
        "version": "3.2.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

上のJSONは仕組みを示す簡略例です。実際のHTTPでは仕様が定めるheader、認可、エラー処理も必要です。resultには2026年版で必須になったresultTypeが入り、通常完了はcomplete、追加入力が必要なMulti Round-Trip Requestではinput_requiredを使います。長期状態が必要なtoolは、暗黙のsessionに頼らず、serverが発行したhandleを通常の引数として次の呼び出しへ渡します。

tools・resources・promptsでできることとMCPだけではできないこと

toolsは、AIアプリケーションが呼び出せる実行機能です。検索、計算、ファイル操作、API呼び出し、データ更新などを表せます。公式Tools仕様は、toolをモデルが発見して呼び出せるものとしつつ、人が呼び出しを拒否できる状態、公開toolの表示、操作前確認を推奨しています^[3]。inputSchemaと必要に応じたoutputSchemaを定義し、自然文だけで引数を受けません。

resourcesは、ファイル内容、データベース記録、API応答など、参照用のコンテキストをURIで提供します。読み取り対象をtoolで表す設計も可能ですが、resourceとして発見・読取できる形にすると、データと操作の責任を分けやすくなります。promptsは、利用者が選べる再利用可能な対話テンプレートです。tool、resource、promptのどれを実装するかはserverの目的で選びます。

MCPだけでは、データの正しさ、業務ルール、利用者の職務権限、モデル出力の正確さ、操作の承認、損失の補償、監視体制は完成しません。serverがtoolを公開しても、hostがモデルへ見せるか、利用者が実行を許すか、接続先がその操作を受け付けるかは別の判断です。MCPを採用する目的は責任を消すことではなく、境界を共通形式で接続しやすくすることです。

API・function calling・コネクター・データベースとの境界を比較する

MCPとAPIは排他的ではありません。APIは個別サービスが提供するHTTPやRPCなどのインターフェースで、MCP serverはそのAPIを呼ぶadapterになれます。接続先APIの認証、rate limit、取引整合性はMCPへ置き換わらず、server内で扱います。特定AIアプリ一つから特定API一つだけを呼ぶなら、MCP層を増やす価値が小さい場合があります。

function callingまたはtool callingは、モデルとアプリケーションの間で構造化されたtool候補と引数を扱う仕組みです。MCPはserverの発見、通信、primitive、版互換性などを定めます。hostはMCPから得たtool定義をモデルのtool callingへ変換できますが、二つは同義ではありません。モデルAPI固有のtool形式とMCP wire protocolを分けて設計します。

製品固有コネクターやプラグインは、UI、認証、運用、マーケットプレイス審査を含む配布単位です。内部でMCPを使う場合もあれば、独自APIの場合もあります。データベースやベクトルストアはデータを保持・検索する基盤で、MCP serverはそれらをresourceやtoolとして公開する接続層です。server自身に大規模な正本データを複製しなくても構いません。

比較軸は、対応host数、公開機能数、再利用性、版管理、認可、監査、latency、障害範囲、保守所有者です。MCPという流行語ではなく、接続を共通化する便益が一層増える運用費を上回るかで判断します。

MCPの権限境界をhost・server・接続先の三層で設計する

第一層はhostです。利用者がどのserverへ接続できるか、どのtoolをモデルへ提示するか、呼び出し前に何を表示し、誰の承認を求めるかを決めます。serverが返したtool一覧を無条件に採用せず、許可リスト、署名・配布元、期待する一覧hash、変更通知を検証します。読み取りtoolでも機密情報を返すなら確認対象です。

第二層はMCP serverです。入力schemaだけでなく、認証主体、scope、対象レコード、操作、件数、金額、宛先、時間帯を業務規則で検証します。Model Context Protocol公式仕様「Authorization」2026-07-28版は、protected MCP serverがOAuth 2.1 resource serverとして動き、access tokenが自分をaudienceとして発行されたかを検証し、自分のresource向けでないtokenを受け入れたり中継したりしてはならないと定めています^[4]。authorization headerは各HTTP要求に含め、query stringへtokenを置きません。

第三層は接続先です。MCP serverのサービスIDに全権限を渡さず、顧客検索、下書き保存、確定、削除を別scopeへ分けます。serverが認可を通しても、接続先が行レベル・項目レベルで拒否できるようにします。利用者委任とserver自身の権限を混ぜず、監査ログには利用者、client、server、接続先主体を結び付けます。

tool: update_customer_note
host_approval: required
mcp_scope: customer.note.write
record_filter: assigned_customer_only
max_records: 1
allowed_fields: [note_draft]
forbidden_fields: [credit_limit, identity_document]
token_audience: https://mcp.crm.example
on_mismatch: deny_and_alert

MCPサーバーの導入可否を八段階で確認する

導入手順はserverを立てる前に、再利用の目的と責任者を確認します。API直結で十分な一組の連携にMCPを足すと、版、認可、監視、SDK更新の運用だけが増えます。複数hostから同じ専門機能を安全に再利用する、tool一覧を発見可能にする、接続境界を標準化するなど、採用理由を一文にします。

1. 利用者とhostを列挙する。誰がどのAIアプリから使うか、ローカル・リモート、対応protocolVersionを記録します。
2. 業務境界を決める。読み取り、下書き、更新、送信、削除を分け、MCPで扱わない操作を明記します。
3. primitiveを割り当てる。参照はresources、実行はtools、定型対話はpromptsとし、責任が重なる設計を見直します。
4. schemaとエラーを定義する。入力・出力、必須項目、上限、業務エラー、再試行可能性を機械検証できる形にします。
5. transportと認可を設計する。stdioのプロセス権限、またはHTTPのOAuth、audience、scope、token保管を決めます。
6. 承認と監査をhostへ実装する。tool名、対象、変更内容を利用者に示し、呼び出し・拒否・結果を共通IDで記録します。
7. 互換性・安全・障害を試験する。非対応版、一覧変更、schema逸脱、token不正、timeout、部分障害、二重呼び出しを確認します。
8. 限定公開し停止演習を行う。読み取りから始め、対象利用者を限定し、資格情報無効化と手作業切替を実演してから権限を広げます。

成果物は、host・server台帳、primitive一覧、tool schema、権限表、評価ケース、停止・再開手順です。Model Context Protocol公式仕様「Key Changes」2026-07-28版はserver/discoverを必須にしたため、対応版と能力を手書き資料だけで管理せず、実際のdiscovery応答と配布物を照合します^[2]。

MCP採用適合度の評価式と導入判定票を使う

MCP採用の価値は、接続できたかだけで測りません。再利用性、発見・互換性、権限境界、監査・運用、性能・費用を0〜100で評価します。以下の式は公式仕様の採点法ではなく、API直結とMCP化を同じ基準で比較する編集部提案です。式は M = 0.25R + 0.20D + 0.25A + 0.20O + 0.10E です。Rは複数host・機能での再利用、Dは版・能力・schemaの発見を表します。Aは認可と操作制約、Oは監査・変更・障害対応、Eはlatencyと成功一件当たり費用です。

MCP採用適合度 M = 0.25R + 0.20D + 0.25A + 0.20O + 0.10E
tool呼出成功率 = 正常完了したtools/call数 ÷ 全tools/call数 × 100
schema適合率 = 入出力schemaに適合した応答数 ÷ 全応答数 × 100
認可拒否正解率 = 正しく拒否した不正要求数 ÷ 不正要求総数 × 100
p95追加遅延 = MCP経由p95時間 - API直結p95時間
成功一件当たり費用 = MCP運用総費用 ÷ 業務上の成功件数

重大ゲートは、未許可toolの公開、token audienceの不一致受入れ、他利用者データの返却、承認なしの書き込み、監査不能な操作を0件とします。一件でもあればMの点数に関係なく不合格です。想定例としてR=90、D=95、A=88、O=80、E=70ならMは86.5点です。二つのhostから同じserverを再利用できても、越権が一件あれば採用しません。

80点以上を採用候補、65〜79点を限定試行、65点未満を見送りとする数値は想定例です。利用hostが一つしかない小規模案件ではRの便益が低く、直接APIが妥当な場合があります。点数より、どの運用負担を共通化できるかを具体的な作業時間で示します。

2025年11月版から2026年7月版への変更を実装前に確認する

Model Context Protocol公式仕様「Key Changes」2026-07-28版は、前版2025-11-25からprotocol-level sessionとMcp-Session-Idを削除し、initializeとnotifications/initializedも削除しました。各要求がprotocolVersionとclientCapabilitiesを持ち、server/discoverが対応版・能力・識別情報を返します^[2]。古いclientと新しいserverを接続する場合、SDK名だけで互換と判断せず、wire上のprotocolVersionと実際のmessageを試験します。

通知も変更され、tools/list、resources/list、prompts/listの接続ごとの差異を廃止し、変更通知はsubscriptions/listenで購読します。長時間処理のtasksはcoreから公式extensionへ移り、sampling、roots、loggingはdeprecatedになりました。新規実装ではdeprecated機能に依存せず、既存実装は廃止時期と代替経路を台帳へ登録します。

互換性試験では、現行・一つ前の対応版、未知の将来版、欠けた_meta、能力未宣言、一覧変更、handle期限切れを含めます。仕様書の版だけでなく、host、client SDK、server、extensionの版を一つの構成IDへまとめます。

MCP接続の停止条件とMCPサーバーが向かないケースを決める

即時停止の条件には、token audienceの不一致受け入れ、未登録toolの表示・実行、他利用者・他部門データの返却があります。承認対象の書き込みが無承認で実行された時や、監査IDを持たない操作が発生した時も即時停止します。hostでserver接続を無効化し、serverの資格情報を失効させ、接続先で該当サービスIDを止めます。三層のどこか一つだけ止めて終えません。

部分停止は、特定toolのerror率が連続十分間で5%を超えた場合に使えます。p95遅延がSLAの二倍になった場合や、tools/listのhashが未承認で変化した場合も対象です。schema適合率が99%未満、またはhandle期限切れが急増した場合も同様です。数値は想定例です。読み取りresourcesを継続できても書き込みtoolsだけ閉じる構成なら、業務を完全停止せず安全側へ縮小できます。

MCP serverが向かないのは、利用hostが一つ、操作が一つ、既存API clientが安定し、共通発見や再利用の便益がほとんどない案件です。toolの所有者、schema、認可、監視、停止担当を決められない案件にも向きません。高リスク操作を利用者へ表示・拒否させるUIがない場合は、read-onlyへ限定します。公式Tools仕様が人による拒否可能性と確認UIを推奨している点も、運用設計の根拠になります^[3]。

再開では、停止原因を評価ケースへ追加し、server/discover、一覧、認可、call、接続先更新、監査まで一件を通します。旧版へ戻す場合も、暗黙sessionへ依存する変更が再び入らないか確認します。

次に取る行動

候補業務を一つ選び、利用host、接続先、公開するtools・resources・prompts、対象外操作を一覧にしてください。API直結とMCP化を、再利用、発見、権限、運用、効率の五領域で採点し、重大ゲートを別に確認します。採用候補なら2026-07-28版のserver/discover、各要求の_meta、statelessな状態handle、HTTP認可を実装・試験し、read-onlyの限定公開から始めます。完成物は構成図、primitive台帳、権限表、評価票、停止・再開手順の五点です。

初回レビューでは、利用者がtool実行を拒否できるか、別serverの資格情報へ到達できないか、同じ要求を再送しても二重更新にならないかを実機で確認します。三項目のどれかが未確認なら公開範囲を広げず、検証記録と担当者の承認がそろってから次の権限段階へ進めます。

参考文献・出典

1. Model Context Protocol公式仕様「Architecture」：MCPサーバー・client・hostの役割を定義、仕様版＝2026-07-28、更新日＝2026年7月28日（版URL）、参照日＝2026年7月30日。
2. Model Context Protocol公式仕様「Key Changes」：仕様版＝2026-07-28、公開・更新日＝2026年7月28日、参照日＝2026年7月30日。前版2025-11-25からの差分を参照。
3. Model Context Protocol公式仕様「Tools」：MCPサーバーが公開する実行機能の公式仕様、仕様版＝2026-07-28、更新日＝2026年7月28日（版URL）、参照日＝2026年7月30日。
4. Model Context Protocol公式仕様「Authorization」：仕様版＝2026-07-28、更新日＝2026年7月28日（版URL）、参照日＝2026年7月30日。