mcp-server-offering

MCP サーバーの提供

あなたはMCP製品サーフェスの設計者です。SaaS製品がMCPサーバーを通じてAIエージェントに公開する内容を設計します。どのツールを、どのような安全制限のもとで、どの認証を通じて提供し、どのようにバージョン管理して効果を測定するかを決め、エージェントが製品を確実に操作できるようにし、ベンダーが投資の効果を把握できるようにします。

これは設計レイヤーです。skills.shで人気のMCP「ビルダー」スキルや言語別ジェネレーターは、もう一段低いレイヤーにあります。何を公開すべきかが決まった後に、サーバーコードのひな型を生成します。MCPを提供するかどうかは、もう一段上の samber/developer-platform-skills@api-integration-surface-strategy で決定します。このスキルは、MCPがロードマップに載った後から取り組みます。

メモリ（推奨）： メモリがファイルに保存されている場合は、developer-platform-context.md の使用を検討してください。別のメモリシステムを使用している場合は、そちらを利用してください。このファイルは参考資料であり、必須ではありません。タスク情報は別々のセクションに分けてください。完了したタスクは削除してください。タスクには日付を追加し、一般的なプロジェクトのコンテキストには日付を付けないでください。インタビューへの回答は、タスクによって異なる場合があります。

確認事項

設計に着手する前に、以下を確認してください。回答によって後続のステップが変わります。まとめて質問してください。これは戦術的な設計タスクであり、戦略インタビューではありません。

1. 需要の証拠：購入者のRFPやセキュリティ質問票にMCPが登場していますか？ 顧客やコミュニティが構築したサーバーが、すでに不足を補っていますか？（コミュニティサーバーの存在は、需要の兆候であると同時に、置き換えられる可能性も示します。ステップ6を参照してください）
2. ツールセットは、既存のどのAPIサーフェスを基盤にできますか？ 安定したパブリックREST／GraphQL契約、内部専用API、それとも機械可読なインターフェースがまったくない状態ですか？（最後の場合は、ROIの捉え方が変わります。ステップ1を参照してください）
3. 書き込みの許容範囲：リリース時点では読み取り専用でも問題ありませんか？ エージェントが本当に必要とする書き込み操作はどれですか？ そのうち、取り消せないもの、金銭的な影響が大きいもの、人にメッセージを送信するものはどれですか？
4. ホスティング方針：多数のクライアントにサービスを提供するリモートエンドポイントですか？ それとも、開発者自身のツールのそばで動作するローカルプロセスですか？ すでにどのようなマルチテナントのエッジインフラがありますか？
5. 認証インフラ：製品にはすでにOAuth 2.1対応の認可サーバーがありますか？ それとも、MCPが初めてのOAuth利用者になりますか？（認可サーバー側は samber/developer-platform-skills@oauth2-provider-design の対象です。このスキルが担うのは、MCPリソースサーバーの方針のみです）
6. サーバーのリリース期限、調達要件を満たすためのものか、成長を重ねる製品サーフェスなのか、そして工数の上限（エンジニアリング時間、継続的なメンテナンスの許容度、可逆性）。これらの回答によって、以下の選択肢の優先順位も変わります。RFPの厳しい期限がある場合は、マネージドホスティングと読み取り専用でのリリースが優先されます。成長を重視する場合は、後回しにされがちな選択肢が優先されます。

対象ユーザーの分類：エージェントの利用者タイプ

どの種類のエージェントが呼び出すのか、どの程度人の監督を受けるのかによって、設計は変わります。

• エンドユーザー向けアシスタントクライアント（チャットアプリ、デスクトップアシスタント）：人が会話を見守ります。クライアント側の承認プロンプトが機能し、Markdown形式の応答が重要で、MCP Apps UI（ステップ8）が役立ちます。書き込み操作のリスクは、人が混乱して承認を急ぐことであり、人のいないループではありません。
• エンタープライズエージェント群：バックグラウンドエージェントで、多くの場合、顧客独自のゲートウェイの背後で動作し、ときには人の監督なしで稼働します。確実に機能するのはサーバー側の強制のみです（運用担当者はクライアントを差し替えられます）。利用者の特定と監査が最も重要であり、エンタープライズ管理の認可とプライベートレジストリミラーが配布方法を左右します。
• 開発者ツールクライアント（IDEおよびCLIエージェント）：技術的な知識が豊富で、ローカルのstdioトランスポートを問題なく利用し、営業経由ではなくレジストリやドキュメントを通じて発見します。

該当する中で最も厳しい要件を持つタイプに合わせて設計してください。無人のエンタープライズエージェント群にも安全なサーフェスなら、監督下のアシスタントにもそのまま対応できます。逆は成り立ちません。

ワークフロー

1. 開発投資の規模を見積もります。
2. ツールの提供範囲を厳選します。
3. 書き込みツールの安全パターンを適用します。
4. ホスティングと認証を選択します。
5. ツールの提供範囲をバージョン管理します。
6. 見つけやすいように公開します。
7. エージェントの導入状況を測定します。
8. 段階的に展開します。

各ステップのセクションは、以下に順番どおり記載されています。

ハーネスに永続メモリがある場合は、このワークフローで決定した内容を記録してください。

• 厳選したツールのリストと、各ツールのリスク層。
• ホスティングと認証の方針。
• サーバーが現在どの展開段階にあるか。
• 独自のテレメトリに基づいて再調整したすべてのしきい値。

こうすることで、次回の実行では既知の提供範囲を拡張でき、ユーザーはセッションのたびに設計を説明し直す必要がなくなります。

1. 開発投資の規模を見積もる

率直に言えば、ほとんどの B2B SaaS ベンダーにとって、MCP サーバーは競争上の防衛策であり、調達における必須条件になりつつあります。競争上の問いは「MCP に対応しているか」から「MCP に適切に対応しているか」へと変わっています。

• 信頼できる一次情報として影響データを公開しているベンダーは、ほんの一握りです。Atlassian の公表値は、現時点で最も充実したデータセットです。1 営業日あたり 500 万件以上のツール呼び出しがあり、その約 3 分の 1 が書き込みで、トークンを 48％ 削減しながら回答の正確性が 44％ 向上しています。

• 引用可能な本番導入の基準値は、2025 年 12 月に 300 人の技術リーダーを対象に実施された調査です。ソフトウェア組織の約 41％ が、限定的から広範な範囲で MCP を本番導入しているとされています。

• エンタープライズ向けのエージェント型パイロットのうち、本番環境に到達するのはわずか 11～14％ であり、ステップ 3～4 で解消するアイデンティティ、監査、アクセス制御の不足が、まさにその停滞の原因です。

• 防衛策という捉え方に当てはまらない例が一つあります。公開 API をまったく持たないベンダーです。MCP サーバーを提供している企業のおよそ半数は公開 REST API を持っていませんでした。こうした企業にとって、MCP は初めて提供する機械可読インターフェースであり、防衛策としての重複ではなく、真に新しい顧客獲得チャネルです。

• 予算は現実的に見積もってください。デモ品質のサーバーなら数時間で構築できますが、本番品質のものには数週間かかり、その大部分はセキュリティレビューとテストに費やされます。さらに、継続的なメンテナンスも必要です（手作業で構築するシンプルな API 統合サーバーだけでも、推定 150～250 時間かかります）。この差を、ステップ 4 のホスティングメニューで費用として見積もります。

• すべてに優先する判断基準は次のとおりです。実際の購入者向け RFP で MCP が必須要件として挙がっている場合は、段階的なタイムライン（ステップ 8）を短縮し、書き込みツールまたは UI へ直ちに進んでください。反対に、2 四半期が経過してもツール呼び出し量が横ばいで、RFP での需要も現れない場合は、サーバーをメンテナンス負荷の低い必須要件として扱い、需要が実証されるまで本番環境向けの構築を明示的に先送りしてください。

すべてのビジネスケースは、references/evidence-and-do-not-cite.md を根拠にしてください。この資料では、証拠の強さを順位付けし、広く流布しているものの誤りが実証されているか、検証できない数値を列挙しています。そのような数値を引用すると、ビジネスケース全体の信頼性が損なわれます。

2. ツールの構成を厳選する

網羅性と厳選のどちらを重視するかという議論には、すでに決着がついています。厳選が選ばれました。未解決のトレードオフとして提示しないでください。

• 分析対象となった1,412台のサーバー全体で、実環境におけるツール数の中央値は5です。

• ツールのメタデータだけで、作業を始める前にエージェントのコンテキストウィンドウの40〜50％を消費することがあります。

• 主要ベンダーのガイダンスは一致しています。ユーザーのワークフローからトップダウンで設計し、APIエンドポイントからボトムアップで設計しないこと。「1サーバー、1つの仕事」とし、ツール数は5〜15個にします。

• 手作業で並行するツール群を構築するのではなく、既存の安定したAPIコントラクトからツールを導き出してください。ホスト型サーバーを公開した主要プラットフォームはすべて、既存のRESTまたはGraphQL APIを基盤に生成しています。コントラクトがまだ安定していない場合、それは親プロジェクト内の兄弟プロジェクトで取り組むべき順序の問題であり、手作業で構築する理由にはなりません。

• 細分化されたエンドポイントをワークフローレベルのツールにまとめてください（get_user() + upload_file()ではなく、upload_file(path, owner)を1つにする）。エージェントが知りたいのは「どのエンドポイントがあるか」ではなく、「どの作業ができるか」です。

• 汎用の任意エンドポイント実行手段、クライアントが選択的に有効化するツールセットのグループ化、動的なツール読み込みといった幅広いパターンは、幅広さが必要だと実証されるまで、デフォルトの構成ではなく、必要に応じて採用してください。

• 実測で最も効果の高い設計要素はツールの説明文です。説明文だけを調整することで、コードを変更せずにエージェントのエラー率が明確に低下しています。各説明文は、異文化の協力者に向けて書くようにしてください。ツールを使うタイミング、必須パラメーターと任意パラメーター、想定される出力、類似するツールとの違いを記載します。ここには十分なエンジニアリングの時間を割いてください。

• パラメーターを間違えにくい形にしてください（ポカヨケ）。正しい使い方を説明して期待するだけでなく、誤った呼び出しを構造上難しくするように引数を設計します（相対識別子ではなく絶対識別子を使う、自由記述文字列ではなく列挙型を使うなど）。

• 仕組み：

  • 動詞から始まり、サービス名を接頭辞にしたsnake_caseの名前を使います（acme_list_invoices）。名前空間は、エージェントが実行する他のすべてのサーバーと共有されます。
  • limitパラメーターに対応し、カーソルとhas-moreフィールドを返します。デフォルトでは20〜50件を返します。
  • JSONとMarkdownのレスポンス形式に対応します。
  • 読み取り専用、破壊的操作、べき等性に関する注釈は正確に設定し、セキュリティ制御ではなくクライアント向けのヒントとして扱います。
  • ツールのエラーは、内部情報が漏れるプロトコルエラーとしてではなく、実行可能な対応を示すメッセージとともに結果内で報告します。

• 各ツールにはリスクレベルを1つだけ割り当ててください（ステップ3）。読み取りと取り消し不能な書き込みの両方を行うツールは、2つのツールに分けます。

MCP Apps：ツールがインタラクティブなUIを返す場合

MCP Appsは公式のMCP拡張機能です（識別子 io.modelcontextprotocol/ui、仕様リビジョン2026-01-26）。ツールがインタラクティブなHTMLインターフェース（グラフ、フォーム、ビューアー、ダッシュボードなど）を返し、テキストのブロックではなく会話内に表示できるようにします。これは、上記の厳選されたツール群に追加する任意のレイヤーとして扱い、決して置き換えないでください。

MCP Appsがサーバーの他の要素と異なる理由：

• 読み手が異なります。 このインターフェースにあるほかのすべてのツールは、エージェントに回答します。モデルが結果を読み取り、推論し、ユーザー向けに要約します。一方、アプリは人間に回答します。ユーザーが直接クリック、フィルタリング、承認を行い、モデルが目にするのは、アプリがコンテキストに渡すと判断した情報だけです。
• 単なるツールの結果とは異なります。 テキストや構造化された結果は一度きりの回答であり、フォローアップのたびにモデルのターンがもう一度必要になります。アプリは状態を保持するため、ステップごとにプロンプトを送らずにユーザーが情報を詳しく調べられ、サーバーのツールをアプリ自身で呼び出すこともできます。
• リンク先にある単独のウェブアプリとは異なります。 アプリは、そのアプリを生み出した会話の隣に表示されるため、タブを切り替える必要も、コンテキストを失うこともありません。サーバーがすでに公開している MCP ツールを通じてデータにアクセスするため、別途 API、ログイン、セッション管理を用意する必要はありません。また、結果をホストに渡すこともでき、ホストはユーザーの同意を得たうえで、ユーザーが接続しているほかの機能を通じて処理します。
• 自社製品に埋め込むウィジェットとは異なります。 自社のページは、自分で管理するホストのひとつです。MCP App は、管理できないさまざまなホスト上で、デフォルトですべてのアクセスを拒否するコンテンツセキュリティポリシーを備えたサンドボックス内で実行されます。また、アプリが利用できる機能はホストごとに決定されます。

ホストが実行する順に、動作の仕組みを説明します。

1. 宣言する。 ツールの説明には _meta.ui.resourceUri が含まれ、同じサーバー上の ui:// リソースを指します。ホストはツールが呼び出される前にそのリソースを先読みできるため、ツールの入力をアプリにストリーミングできます。
2. 取得する。 ホストは ui:// リソースを読み込みます。これは HTML ページで、通常は JavaScript と CSS もまとめられています。外部スクリプトとアセットは、_meta.ui.csp に記載されたオリジンからのみ読み込まれます。
3. レンダリングする。 ウェブホストは、サンドボックス化された iframe 内にページをレンダリングします。アプリは親ページの DOM、Cookie、ローカルストレージにアクセスできず、親ページを移動させることもできません。カメラやマイクなどの追加機能は、_meta.ui.permissions を通じて要求します。
4. 通信する。 アプリとホストは、MCP の方言である postMessage を介して JSON-RPC をやり取りします。一部のメソッドはコアプロトコル（tools/call）と共通で、大半のメソッドには ui/ プレフィックス（ui/initialize）が付きます。アプリはサーバーのツールを呼び出し、ホストがプッシュする最新の結果を受け取り、メッセージを送信し、モデルのコンテキストを更新できます。

サーバーごとではなく、ツールごとに判断します。

• インタラクションが必要で、テキストでは対応できない場合にのみ、アプリを提供します。
  • 複雑なデータの調査（地域を詳しく調べる、ホバーして詳細を確認する、指標を切り替えるなど）。
  • 10 回にわたって質問をやり取りする代わりに、相互依存する多数のオプションを、検証やデフォルト値を使って一度に設定する場合。
  • パンやズームを使ってリッチメディア（PDF、3D モデル、生成画像）を表示する場合。
  • ユーザーが再度要求しなくても更新される、リアルタイムのモニタリング。
  • キューの項目をひとつずつ処理する場合（経費の承認、問題のトリアージ、変更のレビューなど）。
• それ以外は、通常のツールの結果を使います。 アプリを追加すると、ビルド、テスト、アクセシビリティ、セキュリティレビューを個別に行う第 2 のフロントエンドが必要になり、ツールが存在する限り保守が必要です。情報の検索、ステータスの確認、単一の書き込みに UI を加えても、何も得られません。
• 会話内にとどまる利点がない場合は、単独のウェブアプリとリンクを優先します。 周囲のコンテキストが不要で、サーバーへのツール呼び出しも、ホストに接続されたほかの機能の利用も必要ない場合が該当します。

設計ルール：

• UI なしでも、アプリに紐づくすべてのツールを完全に使えるようにします。 この拡張機能はオプトイン方式です。クライアントとサーバーの両方が、機能ネゴシエーション時にこの拡張機能を宣言する必要があります。そのため、この機能に対応していないホスト、ヘッドレスクライアント、バックグラウンドのエージェント群には、プレーンな結果のみが返されます。すべての呼び出しで構造化データとテキストの完全な結果を返し、UI は同じデータをより豊かに表示するビューとして扱います。
• UI から開始された呼び出しも、手順 3 と同じリスク階層を通します。 アプリ内でのクリックは承認ではありません。アプリが要求する書き込み操作にも、そのリスク階層に応じたゲートを適用します。ドライラン、確認、支出上限、人による承認など、モデルがツールを直接呼び出した場合とまったく同じです。
• ホストへの委任は、同意を条件とします。 アプリは、ユーザーのほかの接続済み機能を使って目標を達成するようホストに依頼できます（例：「この会議を予定に入れる」）。ただし、ユーザーの同意を前提とします。その同意が得られることに成功が依存するフローは、決して設計しないでください。
• 必要最小限を宣言します。 _meta.ui.csp には、アプリが実際に読み込む外部オリジンのみを記載し、ジョブに必要な機能だけを要求します。オリジンを追加するたびに、侵害された依存関係がアクセスできる範囲が広がります。可能な場合は、アセットをリソースにバンドルしてください。
• モデルやユーザーが提供したデータは、データとして描画します。 信頼できない入力をウェブアプリでエスケープするのと同じように、UI でもエスケープしてください。サンドボックスが保護するのはホストであり、アプリ自体の完全性ではありません。
• ui:// リソースをツールと一緒にバージョン管理します（手順 5）。 結果の形式が変わると、そのツールのアプリは気づかれないまま動作しなくなります。同じリリースで両方を出荷し、非推奨期間中は古い形式も読み取れるようにしてください。
• 公式ツールキットを使って構築します。 references/mcp-apps-build.md では、create-mcp-app エージェントスキルまたは手動セットアップ、サーバーでの registerAppTool / registerAppResource、UI での App クラス、単一ファイルへのバンドル、ローカルテストを通じて、アプリの作成方法を説明しています。
• フレームワークに依存しないようにします。 @modelcontextprotocol/ext-apps の App クラスは便利なラッパーであり、必須ではありません。公式のサンプルには、React、Vue、Svelte、Preact、Solid、Vanilla のテンプレートが用意されています。チームがすでに保守しているものを選んでください。

ホストの対応状況とテスト：

• ホストによって対応状況は異なり、MCP 拡張機能のクライアント対応表はコミュニティによって保守されています。2026-09 時点では、Claude（Web と Desktop）、ChatGPT、Cursor、VS Code GitHub Copilot、Microsoft 365 Copilot、Goose、Postman、MCPJam、Archestra.AI、PostHog Code が記載されています。顧客にホストへの対応を約束する前に、必ず再確認してください。
• 少なくとも 2 つのホストと、拡張機能に対応していないクライアント 1 つでテストし、プレーンな結果へのフォールバックを確認してください。ext-apps リポジトリの basic-host サンプルを使うと、本番ホストなしでアプリをローカルに描画できます。

（手順 7 で）クライアントごとに、アプリ描画ありの呼び出しとテキストのみの呼び出しを測定し、インタラクティブなジョブの完了状況（詳細表示の利用、フォームの送信、キュー項目の処理完了）も測定します。描画されてもまったく使われないアプリは、リターンのない保守コストです。アプリを廃止し、ツールは残してください。

3. 書き込みツールの安全性パターンを適用する

名前の付いた6つのパターンについて、それぞれ特定のベンダーによる実証例をreferences/write-safety-patterns.mdで詳しく説明しています。これらは競合するものではなく、積み重ねて適用するものです。そのため、この順位は導入する順序を示しており、どれをどれの代わりに採用するかを示すものではありません。評価軸によって順位が異なるため、それぞれ別に示します。

• 保護：リスク段階別のポリシーゲート > ヒューマン・イン・ザ・ループ承認 > スコープ付き認証情報 == 読み取り専用の分離 > 冪等性 + 支出上限 > ドライランによる事前チェック
• 労力：リスク段階別のポリシーゲート > ヒューマン・イン・ザ・ループ承認 > ドライランによる事前チェック > 冪等性 + 支出上限 > スコープ付き認証情報 == 読み取り専用の分離
• 効率（労力あたりの保護）：スコープ付き認証情報 == 読み取り専用の分離 > リスク段階別のポリシーゲート > 冪等性 + 支出上限 > ドライランによる事前チェック > ヒューマン・イン・ザ・ループ承認

ヒューマン・イン・ザ・ループ承認は、実装に数時間しかかからないにもかかわらず、労力の順位では2番目です。その真のコストは、承認対象の呼び出しがあるたびに、人間の注意を継続的に消費することです。それが永遠に続きます。承認に値する呼び出しにはまさに適切ですが、それ以外のすべてに適用するのは現実的ではありません。スコープ付き認証情報と読み取り専用の分離が3つの評価軸すべてで同順位なのは、実質的な理由があります。どちらも適切に動作するエージェントからは見えないサーバー側の強制措置であり、新たな仕組みではなく認証情報モデルの設定で実現できます。また、読み取り専用の分離は、スコープ付き認証情報を極限まで適用したものにすぎません。

• 既定の段階：最初からスコープ付き認証情報と、検証済みの読み取り専用モードを採用し、封じ込め可能なすべての書き込みにヒューマン・イン・ザ・ループ承認を適用します。取り消せない操作やデプロイを起動するツールは、既定で無効にします。効率性が最も高い2つのパターンでこの組み合わせを実現でき、承認も併用できるのは、初期の書き込み量が少ないためです。この条件はいずれ失われます。そのとき、下記の後回しにされている選択肢を優先することになります。
• 後回しにされている選択肢：サーバー側のリスク段階別ポリシーゲートを導入します（すべての呼び出しを「読み取り専用」「最小限の影響」「封じ込め可能な書き込み」「重大」に分類し、許可するか、エージェントの実行者情報を付加して非同期監査に回すか、ハンドラーの実行前にブロックします）。最も高い保護を実現する一方で、構築の労力も最も大きいため、効率性の順位では常に最下位になり、導入が先送りされ続けます。それでも、バックグラウンドエージェントが人の監視なしで動作するようになったとき、人間が承認できる量を超えて書き込みが増えたとき、または最初の書き込みインシデントが発生したときは、直ちに優先してください。このパターンを構築したベンダーは、人の監視なしに動作したエージェントが数千件のチケットをクローズしたことを受けて、これを導入しました。
• すべてのパターンが満たすべきテスト：強制措置がサーバー側にあるため、エンドユーザーがクライアントを切り替えて回避できないこと。クライアント側の承認プロンプトやアノテーションのヒントだけでは、このテストを満たせません。
• 業界の課題は正直に伝えましょう。取り消し／ロールバックは、エコシステム全体でほぼ整備されていません。実際の可逆性を実現する解決策ではなく、実行者情報の記録と監査証跡が、現在の代替手段です。
• この順位は既定の目安であり、絶対的な決まりではありません。質問3の書き込みリストと、ユーザーについて把握している情報を踏まえて順位を付け直してください。書き込みによってメール送信や送金を行う製品なら、ドライランと上限設定をすぐに優先します。一方、純粋な分析製品なら、既定の段階を超える対策が必要ない場合もあります。

4. ホスティングと認証を選択する

ホスティング形態は3つあり、以下の順です。

• 労力：セルフホストのリモート > リモートのマネージドプラットフォーム > ローカル stdio
• 価値：セルフホストのリモート == リモートのマネージドプラットフォーム > ローカル stdio
• 効率：リモートのマネージドプラットフォーム > ローカル stdio > セルフホストのリモート

価値が同等なのは本当です。エージェントクライアントから見ると、どちらも OAuth で保護された同じエンドポイントです。カスタムのサーバー側ポリシーレイヤーやデータレジデンシーの制約が生じるまでは、ホスティング形態が購入者に見えることはありません。これらがまさに次の形態へ移行する条件です。

• デフォルトの選択肢：リモートのマネージドプラットフォーム。 プロトコルは最初の20か月で後方互換性のない改訂を4回重ねました。マネージドプラットフォームなら、この変化と必須の OAuth 機構への対応を吸収できます。また、エンタープライズ連携がいくつか存在するようになると、マネージドを選ぶ経済的な利点はさらに大きくなります。質問6の厳しい期限も、この選択肢を後押しします。
• 労力不足で後回しになる選択肢：セルフホストのリモート。 制御性が最も高い一方、労力も最大です。本番環境向けの品質に達するまで数週間かかり、その後も継続的な保守が必要です。MCP サーバー 自体 が製品である場合（垂直 SaaS、独自データセット、規制対象のワークフローなど、顧客が対価を払うのはエージェントアクセス）、ステップ3のカスタムなリスク階層ポリシーレイヤーを自社インフラで実行する必要がある場合、または既存のマルチテナントエッジインフラによって労力の評価が変わる場合に、こちらへ移行します。
• ユーザー自身のファイルやプロセスを扱う開発者向けツール製品なら、ローカル stdio に切り替えます。クライアントは1つで、ホスティングの労力はほぼゼロ、認証情報には環境変数を使い、以下の OAuth 要件からも明示的に除外されます。エンタープライズのエージェント群がホスト型エンドポイントを利用するため、対象ユーザーがそのような環境なら、単に優先度を下げるのではなく、選択肢から完全に除外します。
• この順位付けはデフォルトであり、絶対的なルールではありません。質問4〜6に基づいて順位を付け直してください。

リモート形態に共通する認証ルール（仕様改訂には日付が付いており、頻繁に変わるため、常に引用元が最新版か確認してください。このセクションは2026-07-28の改訂に基づいています）：

1. MCP サーバーは OAuth 2.1 のリソースサーバーです。トークンを検証しますが、発行はしません。その背後にある認可サーバーの設計は samber/developer-platform-skills@oauth2-provider-design の範囲なので、ここでは MCP 固有の方針だけを扱います。
2. 保護リソースのメタデータ（RFC 9728）を公開します。
   • リソースインジケーター（RFC 8707）を必須とし、このサーバー向けに発行されたものではないトークンはすべて拒否します。これにより、ある MCP サーバー向けに発行されたトークンが別のサーバーに対して再利用されるのを防ぎます。
   • 2026-07-28の改訂では、発行者の検証（RFC 9207）も必須となり、トランスポートの中核はステートレス方式に書き換えられています。すべてのサーバーインスタンスを通常のロードバランサーの背後で相互に置き換え可能に設計し、セッションを特定のインスタンスに固定してはいけません。
3. 呼び出し元のベアラートークンを上流 API に転送してはいけません。仕様では、この混乱した代理人の形態を明確に禁止しています。トークン交換を通じて独自の上流トークンを取得し、上流システムに対する OAuth クライアントとして動作してください。
4. コンプライアンス統計は、1つの数値としてではなく、二峰性の分布として捉えてください。よく引用される OAuth コンプライアンス率が一桁台なのは、コミュニティの stdio サーバーが長い裾野を形成しているためです。一方、ベンダーがホストするサーバーでは OAuth 2.1 がデフォルトです。適切に実装することがエンタープライズのセキュリティ審査を通過するための要件であり、この集団では最低限必要な条件であって、特別に際立つものではありません。
5. 形態にかかわらず、最低限以下の対策を講じてください。
   • すべての入力をスキーマで検証し、サイズと範囲に上限を設けます。
   • パスをサニタイズします。
   • 内部エラーをクライアントに漏らしてはいけません。
   • ローカルで実行する HTTP サーバーでは、Origin ヘッダーを検証し、localhost にバインドします（DNS リバインディング対策）。

5. ツールサーフェスにバージョンを付ける

3つのレイヤーはそれぞれ別々にバージョン管理します。「MCP のバージョン管理」を1つの判断として扱うのは誤りです。

1. プロトコルのバージョン：日付ベースの改訂に、正式な機能ライフサイクル（Active → Deprecated → Removed）を設けます。最後の2段階の間隔は最低12か月です。非推奨化を追跡しましょう。たとえば、元のトランスポートはプロトコルの初期に猶予期間に入りました。また、再現可能なビルドのため、SDK のバージョンは正確に固定します。
2. サーバーのパブリック API：通常のセマンティックバージョニングを適用します。ツールセット名の変更や削除はメジャーバージョンアップに相当します。エージェントは名前を手がかりにツールを見つけるため、名前を変更すると気づかれないまま動作しなくなります。一般的な非推奨化の仕組みについては samber/developer-platform-skills@api-versioning-policy の領域です。ここで扱うのは、その下のレイヤーです。
3. ツールサーフェスの契約そのもの（名前、説明、スキーマ）：現時点で、これを標準化する仕様はありません。ツールの説明はコンパイルされるインターフェースであり、ドキュメントではありません。カタログに登録されたツール61,097件を分析した結果、説明の文言を変えると、モデルがそのツールを選択する確率が測定可能なほど変化することが分かっています。これは JSON スキーマに手を加えなくても発生する破壊的変更であり、スキーマの差分を確認する CI では検出できません。もはや何も明確なエラーを出しません。エージェントはただ適応し、ときには誤った動作をします。

仕様による強制がないため、レイヤー3では次の規律を守ります。

• すべての変更を加算的にすることを原則とし、ツール名を変更する代わりに古い名前をエイリアスとして残します。
• サーフェス全体（名前＋説明＋スキーマ）のハッシュを計算し、気づかれない変更を検出します。
• CI でゴールデンプロンプトの動作テストを実行します。説明を編集した後も、代表的な固定タスクの一連のテストで適切なツールが選択され、呼び出されることを確認します。
• レスポンスのエンベロープにバージョンマーカーを含め、すべての呼び出しで記録します。
• 少なくとも90日間の非推奨化期間を設け、機械可読なレスポンスヘッダーで通知します。

説明の編集も、ドキュメントの修正としてではなく、コード変更と同じレビューゲートを通してリリースします。

6. 見つけてもらえるように公開する

• DNS 検証済みの逆ドメイン名前空間を使って、公式 MCP レジストリに公開します。その掲載が何を示すのか把握しておきましょう。レジストリは名前空間の所有権の証明とコミュニティによるモデレーションを備えたメタデータカタログであり、セキュリティを保証するものではありません。購入者への信頼性の根拠として、掲載を過信しないでください。
• 公式レジストリへの掲載は必要ですが、それだけでは不十分です。開発者は厳選されたサードパーティのディレクトリも参照するため、1か所に掲載して終わりにせず、他のディレクトリにも広く掲載します（その自動化ツールもあります）。
• 大企業の顧客がレジストリを、許可リスト方式の社内カタログにミラーリングすることを想定します。掲載情報のメタデータとバージョン履歴を正確に保つ必要があるのは、人が閲覧するためだけでなく、ポリシーを適用するマシンが再利用するためです。
• ファーストパーティのサーバーは、一度公開すると、同じ製品のコミュニティ製代替品と並んで競合するのではなく、代替品に取って代わる傾向があります。質問1でコミュニティ製サーバーが見つかった場合、質の高い公開は、エージェントが現在信頼している非公式なサーフェスを置き換える手段にもなります。

7. エージェントの導入状況を測定する

• 独自のイベントスキーマを作るのではなく、ツール呼び出しを OpenTelemetry のスパン（セッション → ツール呼び出し → 下流の操作）として計測します。エンタープライズ環境でこのデータを利用するのは、顧客の既存のオブザーバビリティスタックであり、自社のダッシュボードだけではありません。ツールの対象範囲が広がるほど、個々のツールに手作業で計測を追加するより、自動計測するラッパーのほうが有効です。
• 指標の統一セットは、呼び出し数、成功率／エラー率、ツール別の使用状況、アクティブユーザー数、クライアントの内訳（どのエージェントクライアントから呼び出されているか）です。その目的は二つあります。サーバーが実際に使われていることを確認することと、導入が広く進んでいるのか、特定の範囲に集中しているのかを把握することです。
• レジストリへの掲載やパッケージのダウンロード数で測れるのは、インストールへの関心であり、実行時の使用状況ではありません。導入状況を判断するには、サーバー内のテレメトリだけが答えを示します。ダウンロード数を使用状況の数値としてビジネスケースに含めないでください。
• テレメトリが唯一の可視化レイヤーではないことを前提にしてください。大規模な顧客は、自社のゲートウェイを介してサーバーに接続します。指標は排他的なものではなく、相関付けできるように設計してください（安定したツール名、リクエスト ID など）。
• データが十分に整ったら公開しましょう。エコシステムで最も有力な ROI の証拠は、あるベンダーによる一次情報の開示です。呼び出し数、書き込みの割合、非技術系ユーザーの割合、エンタープライズの割合、コホート別の継続率、精度、トークン効率の向上が含まれています。目指すべき開示形式の詳細は、references/evidence-and-do-not-cite.mdを参照してください。
• 顧客ごとの統合エラーを、対応を担う開発者にフィードバックするのは、samber/developer-platform-skills@integration-error-observabilityの領域です。

8. 段階的に展開する

各ステージの詳細、しきい値、MCP Apps を採用するかどうかの判断基準は、references/rollout-stages-and-thresholds.mdを参照してください。概要は次のとおりです。

1. 読み取り専用でリリース：厳選した 5～15 個のツールを用意し、初日から OAuth 2.1 と OpenTelemetry を導入して、レジストリに公開します。実際のエージェントクライアントによるツール呼び出し数が持続的に増加し（デモによる一時的な急増を除く）、ツールのエラー率が 2% 未満の場合にのみ、次の段階に進みます。
2. 書き込み機能を段階的に導入：リスク階層をサーバー側で適用し、範囲を限定した書き込みには承認を設け、重要なツールはデフォルトで無効にします。スコープを限定した認証情報、実行者の記録と非同期監査、冪等性キー、可能な場合はドライランも導入します。監査証跡に問題がなく、実行者不明の書き込みがゼロで、承認フローの信頼性が実証された場合にのみ、書き込みの範囲を拡大します。
3. 差別化する：最も価値の高いワークフローを一つ選び、インタラクティブな MCP Apps UI（承認画面、フィルター可能なダッシュボード、設定ウィザードなど）を導入します。ただし、その対象顧客のセキュリティチームが、アシスタント内に iframe でレンダリングされるサードパーティ製 UI を受け入れることを検証した後にしてください。これはまだ未解決の問いであり、受け入れが確定しているわけではありません。レイヤー 3 のバージョン管理規律を組織に定着させ、影響を示す指標を公開します。

ステップ 1 の RFP 圧力による例外は、両方向でこの順序に影響します。調達における強い要求があればステージを飛び越えて進み、2 四半期続けて横ばいなら、サーバーをステージ 1 のまま維持し、標準装備として保守します。

失敗パターン

アンチパターンのチェックリストです。それぞれが、そのままレビューで指摘される問題です。

• 包括的なミラー化の罠：API エンドポイントごとにツールを1つ用意します。エージェントはよく似た選択肢の中から誤ったツールを選び、作業が始まる前にコンテキストがメタデータで埋め尽くされます。
• 本番環境でしか使えない破壊的なツール。ドライランも承認ゲートも、デフォルトで無効にする段階もありません。コミュニティ製サーバーでは、実際の顧客に通知メールを黙って送信する注文キャンセルツールが公開されたことがあります。
• 派生ツールが利用できるのに、手作業で並行するインターフェースを構築します。二重の保守が必要になり、実際の API 契約との乖離が必ず生じます。
• ツールの説明文の変更をドキュメントの修正としてリリースし、レビューと動作テストを回避します。その結果、エージェントが選択するツールが気付かれないまま変わります。
• 呼び出し元のベアラートークンを上流に転送します。これは仕様で禁止されている、混乱した代理人のパターンです。
• 読み取り専用フラグを検証せずに信頼します。ベンダーの文書化されたバグにより、フラグが設定されているにもかかわらず書き込みツールが公開された事例があります。ロックダウンをテストしてください。設定しただけで安心してはいけません。
• ツールのアノテーション（読み取り専用／破壊的といったヒント）をセキュリティ制御として扱います。これらはクライアント向けの参考メタデータであり、適用はサーバー側で行う必要があります。
• 事業計画で、誤りだと判明した普及率の統計を引用します。references/evidence-and-do-not-cite.md の引用禁止リストを参照してください。
• セッションに固定されたサーバー設計です。プロトコルがステートレスに書き換えられたため、インスタンス間で互換性があることが基本的な期待になっています。

測定

4つの二者択一のゲートがあります。すべて合格するまで設計を反復してください。

• 安全性の網羅性：書き込み可能なすべてのツールに、リスク階層がちょうど1つ割り当てられ、ステップ3の分類体系にある名前付きパターンが少なくとも1つ含まれていること。また、取り消し不能なすべてのツールに承認ゲートがあるか、デフォルトで無効になっていること。未対応の書き込みツールが1つでもあれば不合格です。
• 認証への準拠（リモートサーバー）：保護リソースのメタデータが公開されていること、トークンの対象者が検証されていること、ベアラートークンが上流に転送されていないこと。仕様自体の MUST 要件に基づく二者択一の判定です。
• エビデンスの健全性：作成した事業計画や成果物に、引用禁止リストの数値が一切含まれていないこと。
• キュレーション：公開するインターフェースは、実証済みの網羅性要件が文書化されている場合を除き、5～15個のツールに収めます。また、すべてのツール名がステップ2の規則に従っていること。

段階移行のしきい値（エラー率2％未満、監査証跡に不備がないこと）は、あるベンダーの読み取り専用から始める運用に基づくもので、業界標準ではありません。自社の最初の1か月を基準に調整するデフォルト値として扱い、ステップ7の普及指標はしきい値の合否ではなく、基準値を設定するための傾向として扱ってください。

呼び出し例

• 「安定した REST API があり、エージェントからのアクセスを求める顧客もいます。当社の MCP サーバーを設計してください。どのツールを公開し、書き込みを行うツールをどのように保護すればよいですか？」
• 「当社の MCP サーバーは60個の API エンドポイントをミラー化しており、エージェントが間違ったツールを呼び出し続けています。インターフェースを再設計してください。」
• 「エージェントが当社の MCP サーバー経由で注文を作成・キャンセルできるようにしたいです。リリース前に、安全性、承認、監査のモデルを設計してください。」
• 「経営陣は競合他社が MCP サーバーをリリースしたため、当社も導入を求めています。実際にはどれくらい投資すべきで、どの順番で進めるべきですか？」

参考資料

• references/write-safety-patterns.md - 名前の付いたベンダー実装を含む6つの書き込み安全パターン、悪い例、承認プリミティブの詳細です。
• references/rollout-stages-and-thresholds.md - Go／No-Goのしきい値を含む3つのロールアウト段階と、MCP Apps UIの判断です。
• references/evidence-and-do-not-cite.md - 強さの順に並べた導入／ROIのエビデンス、準拠すべき開示モデル、引用してはいけない誤りと判明した数値です。

同じコレクションの関連資料：

• samber/developer-platform-skills@api-rate-limit-policy - エージェントのトラフィックに適用されるクォータとスロットリングポリシーです。ツールごと、認証情報ごとの制限も含みます。
• samber/developer-platform-skills@developer-portal-design - MCP サーバーのドキュメント、接続ガイド、認証情報を掲載する開発者ポータルについて説明します。
• samber/developer-platform-skills@cli-interface-design - シェルを使うエージェントが最初に利用することの多いCLIインターフェイスです。同じく厳選した内容を提供し、ミラーに依存しない方針ですが、契約は異なります。
• samber/developer-platform-skills@ide-extension-offering - ワンクリックでセットアップできるようにサーバーをバンドルするエディター拡張機能です。公開は拡張機能が担い、サーバーの設計はここで扱います。
• samber/developer-platform-skills@agent-skill-offering - サーバーまたはCLIとともに提供され、コードと同じバージョンで管理されるAgent Skillです。シェルを使うコーディングエージェント向けに、SkillとMCPのどちらを選ぶかを扱います。
• samber/developer-platform-skills@agent-integration-surfaces - サーバーを取り巻くエージェントクラスの計画です。エッジアクセスのポリシー、エージェントのIDと委任、プロビジョニング後のクレームによる登録、複数のインターフェイスでのエージェント利用を扱います。