MCPのホスト・クライアント・サーバーを整理｜認証方式と接続先の選び方

AIツールを社内データや外部APIに接続する話は、モデルの世代交代より先に限界を迎えます。足りないのは新しいLLMではなく、コネクタの数です。N個のアシスタントとM個のデータ源を個別に実装すると、接続作業がN×Mに膨らみます。

📑目次

1. MCPは何を標準化し、何を決めないか
2. ホスト・クライアント・サーバは誰が何を持つか
3. テクノロジー担当が見るstdioとHTTPの認証差
4. 今つなぐか、stdio実験に留めるか
5. よくある質問
6. まとめ

Model Context Protocol（MCP） は、その接続手順を1つのオープンソース標準に揃えます。テクノロジー担当が今見るべき判断材料は、ホスト／クライアント／サーバの分担と、stdio か HTTP かで認証が分かれる点です。社内勉強会の要約だけでは、本番に載せる境界は決まりません。

---

MCPは何を標準化し、何を決めないか

公式の定義と発表

MCPは新しい大規模言語モデルではありません。公式の導入文書は、Claude や ChatGPT のような AIアプリケーションを、カレンダー、データベース、デザインツールなどの外部システムへつなぐオープンソース標準だと定義しています。比喩は USB-C です。ケーブル形状を揃えるので、機器ごとの専用コネクタを減らせます。

Anthropic の 2024-11-25 発表 は、データ源ごとのカスタムコネクタを、MCPサーバと MCPクライアントに置き換える、と書いています。データやツールをサーバ側で出し、クライアントがそこに接続する、という分担です。

---

独立ソースが記録する事実

独立した整理も同じ方向を向いています。日本語版 Wikipedia は次を記録しています。

• 2024年11月発表のオープン標準であること
• データシステム側がベンダーごとのコネクタではなく MCP を1回実装すればよいこと（N×M 問題）
• ホスト／クライアント／サーバ、サーバはローカルでもリモートでもよいこと
• OpenAI・Google DeepMind・AWS・Microsoft の採用
• 2025年12月の AAIF 移管

英語版 Wikipedia は、ベンダー独自の function calling や ChatGPT plugins を先行のつなぎと位置づけています。後続の Agent Skills はオンデマンド手順の併用標準であり、MCP の置換ではない、と書いています。

---

プロトコルが決めない範囲

一方、公式の architecture は範囲を狭く切ります。MCPが扱うのは文脈交換のプロトコルだけです。ホストが LLM をどう呼び、どの回答を採用するかは規定しません。

対応クライアントが増えたことと、自前サーバを本番に載せる準備ができたことは別です。後者は、次の役割分担と認証を見て決めます。

---

ホスト・クライアント・サーバは誰が何を持つか

3つの参加者

役割を取り違えると、認証設計の担当もずれます。公式architectureの参加者は次の3つです。

• ホスト: Claude Code や Claude Desktop のような AIアプリケーション。複数クライアントを調整する。
• クライアント: サーバ1つにつき1接続。ホストがサーバを増やすたびにクライアントを増やします。公式の例では、VS Code が Sentry 用とローカル filesystem 用に別クライアントを作ります。
• サーバ: ツール・リソース・プロンプトを出すプログラム。ローカルでもリモートでも構いません。STDIO のローカルサーバは通常1クライアント、Streamable HTTP のリモートサーバは多数クライアントを想定します。

GeeksforGeeks の整理 も、サーバが resources / tools / prompts を出し、クライアントは 1:1、ホストが複数クライアントを束ねる、と同じ分担です。

テクノロジー部門がホストを自作するのか、既存ホスト向けにサーバだけを提供するのかによって、次に設計すべき認証の範囲が変わります。

---

発見から実行までの手順

発見から実行までの手順は、公式architectureに従うと次の順序になります。

1. 任意だが推奨: server/discover で対応バージョンと capabilities を取る。応答のキャッシュ例は ttlMs 3600000。
2. tools/list でツール名と inputSchema を取る。キャッシュ例は ttlMs 300000。
3. tools/call で name を発見結果と完全一致させて実行する。
4. 変更通知が必要なら subscriptions/listen。通知はベストエフォートなので、再接続後は tools/list を取り直します。

---

2026-07-28の運用制約

2026-07-28 版の制約も運用に効きます。

• プロトコルはステートレスで、各リクエストの _meta に protocolVersion と capabilities を載せます。
• Sampling と Logging は非推奨です。
• 現行のクライアント primitive は Elicitation です。
• 仕様差分の詳細は MCP 2026-07-28 ステートレス仕様の要点 を参照してください。

判断は単純です。自社でホストを書く場合は、複数クライアントの許可モデルまでホスト側の責任になります。既存ホストに対してサーバだけを提供する場合は、提供するprimitiveと輸送方式（stdio / HTTP）を先に固定します。

---

テクノロジー担当が見るstdioとHTTPの認証差

輸送で切れる認証

認証は輸送方式によって大きく異なります。ノートPC上のstdio実験と、社内向けHTTPサーバは全く別物です。

公式の Authorization と Client Registration を軸にすると、差は次の表になります。

---

STDIOとHTTPの認証比較

軸	STDIO（ローカル）	Streamable HTTP（リモート）
典型	同一マシンのプロセス。filesystem サーバなど	遠隔の MCP サーバ。Sentry 例
認証仕様	Authorization 仕様は SHOULD NOT。資格情報は環境変数	HTTP なら SHOULD 従う。サーバは OAuth 2.1 リソースサーバ、クライアントは OAuth 2.1 クライアント
トークンの置き場	環境変数。クエリ文字列に載せない話は HTTP 側	毎リクエストの Authorization ヘッダに Bearer。クエリ文字列へは置かない
クライアント登録	この仕様の対象外	事前登録 → CIMD（HTTPS URL の client_id）→ 非推奨の DCR → 手入力
失敗時	プロセス権限と環境の問題	401 / 403 / 400。403 は insufficient_scope

---

認証仕様の出典

出典は次の3件です（2026年7月時点）。

• MCP architecture（2026-07-28）
• Authorization
• Client Registration

---

HTTP側で押さえる実装点

HTTP側で押さえるべき実装ポイントは次の通りです。

• MCPサーバは Protected Resource Metadata（RFC 9728）を実装し、クライアントはそこから認可サーバを発見します。
• 認可リクエストとトークンリクエストの両方に resource パラメータが必須です。スキームなし URL や fragment 付きは不正です。末尾スラッシュは意味が必要でない限り避けます。
• CIMD の client_id はパス付き HTTPS URL です。メタデータ JSON には client_id / client_name / redirect_uris が必須です。認可サーバが client_id_metadata_document_supported を出したら CIMD を使います。
• 登録の優先順は、事前登録 → CIMD → 非推奨の DCR → 手入力です。DCR は後方互換のための MAY であり、新規実装の既定にはしません。
• CIMD の client ID は認可サーバをまたいで持ち運べます。事前登録と DCR の資格情報は発行した issuer に結び、認可サーバ変更後に使い回しません。

---

本番公開の切り方

GeeksforGeeks にある Bearer API キー例は、個人向けリモート接続の二次整理です。マルチユーザーの HTTP 本番の既定は、仕様の OAuth 2.1 です。混ぜないでください。同意ダイアログが毎回出る運用を切る話は、MCP都度同意をOBOと認可サーバー4要件で切る判断基準 に分けて書いています。

テクノロジー現場の結論は明確です。stdio実験は環境変数とプロセス権限で十分です。社内向けHTTPサーバは、CIMDか事前登録とトークンのaudienceが揃うまで公開しません。

---

今つなぐか、stdio実験に留めるか

接続判断は、モデル比較ではなくチェックリストで決めます。以下の項目を1つでも満たさない場合は、リモート公開を待ちます。

• ✓ 足りないのは「新しいモデル」ではなく「ツール／データへの共通コネクタ」か
• ✓ 自社の役割はホスト実装か、既存ホスト向けサーバ提供か
• ✓ 最初のサーバは STDIO ローカルか、HTTP リモートか
• ✓ HTTP なら OAuth 2.1、Protected Resource Metadata、毎リクエスト Bearer、resource パラメータを設計しているか
• ✓ クライアント登録は事前登録または CIMD で、DCR を新規定にしないか
• ✓ Sampling / Logging に依存する古い実装を 2026-07-28 前提から外せるか
• ✓ 通知はベストエフォートなので、再接続後の tools/list 再取得があるか

次の一手は、ローカル STDIO で server/discover → tools/list → tools/call を1本通すことです。HTTP は CIMD または事前登録とトークン audience が揃うまで公開しません。仕様差分は MCP 2026-07-28 ステートレス仕様 を先に確認してください。

注意点もあります。MCPは LLM の使い方を決めません。権限境界は、ホスト側の許可モデルと、サーバ側のトークン検証の両方です。どちらか一方だけを「MCP対応」と呼ぶと、本番の責任分界が消えます。

---

よくある質問

MCPは新しいLLMですか

違います。公式は AIアプリケーションと外部システムをつなぐプロトコルだと定義しています。LLM の使い方はホスト側です。

---

ホストとクライアントは同じものですか

違います。ホストが AIアプリケーションです。クライアントはサーバ1つにつき1接続です。ホストはサーバを増やすたびにクライアントを増やします。

---

ローカルサーバでもOAuthが必要ですか

STDIO は Authorization 仕様の対象外です。資格情報は環境変数から取ります。HTTP 輸送なら OAuth 2.1 側です。

---

Dynamic Client Registrationでよいですか

仕様は DCR を非推奨にしています。新規は CIMD または事前登録です。

---

Agent SkillsでMCPは不要になりますか

英語版 Wikipedia は、Agent Skills をオンデマンド手順の併用標準とし、MCP の置換ではないと書いています。

---

発見は毎回必須ですか

server/discover は任意ですが、全サーバが実装する必須メソッドです。各リクエストの _meta でも版と capabilities を送ります。ステートレス前提では、キャッシュ TTL が切れたら取り直します。

---

まとめ

MCPの差分はモデル性能ではありません。ツールとデータをホスト／クライアント／サーバに分け、発見してから実行することです。テクノロジー担当の次の一手は、ローカル STDIO で server/discover → tools/list → tools/call を1本通すことです。HTTP は CIMD または事前登録とトークン audience が揃うまで公開しません。

2026-07-28 ではステートレス、Sampling 非推奨、通知はベストエフォートです。本番接続の前にこの3点を確認してください。対応クライアントの増加を、自前サーバの本番準備と同一視しないことが、接続判断の本体です。