この記事は、自社のサービスやデータをAIアプリから使える形で公開すべきかを考えている、事業責任者や開発担当者に向けて書いています。読み終えると、MCPサーバーとは何か、WebMCPとどう役割が違うのか、公開を判断するときにどんな軸で考え、設計で何に気をつけるかが分かります。
先に整理しておくと、MCPサーバーの公開は、WebMCPとは別の話です。ただ、両者はよく並べて語られます。そこで、本シリーズ（WebMCPシリーズ）の一部として、両者の関係を含めて扱います。なお、WebMCPは草案の段階で、内容が変わり続けています。この記事の内容は2026年10月20日時点の確認に基づきます。シリーズ全体の入口はWebMCPの入門記事です。
MCPとは何か
MCP（Model Context Protocol）は、AIアプリを外部のシステム、つまりデータ、ツール、ワークフローにつなぐためのオープンソースの標準です。Anthropicが開発しました。公式サイトには「AIアプリのUSB-C」というたとえがあります。機器ごとに違う端子を用意しなくても、共通の差し込み口でつながる、というイメージです。
登場する用語を、最低限だけ押さえます。
- ホスト・クライアント・サーバー：AIアプリ側がホストとクライアントにあたり、外部のシステムの窓口になるのがサーバーです。
- ツール：AIが呼び出せる操作です。
- リソース：AIが読める情報です。
- プロンプト：あらかじめ用意された指示の型です。
多くのAIアシスタントや開発ツールがMCPに対応しています。企業が自社のサービスを「MCPサーバー」として公開するとは、この共通の窓口を用意し、利用者のAIアプリから自社のデータや操作を呼べるようにすることです。バージョンごとの違いや、認可方式の細部については、この記事では扱いません。公式サイトの最新の仕様で確認してください。
WebMCPとの役割分担
名前が似ているので混同されがちですが、MCPとWebMCPは動く場所が違います。WebMCPは、Webサイトが自分の機能を「ツール」として、ブラウザ上のAIエージェントに公開する提案です。W3C Web Machine Learning Community Groupの草案によると、MCPと用語や考え方を共有する一方、WebMCPはオリジン、ブラウザの権限、DOM、タブの寿命といったWebの概念に合わせて設計され、ページ自身が「MCPのようなサーバー」として振る舞います。MCPは、主にサーバー側の接続（stdioやSSEなど）を想定しています。
Chromeの公式資料（WebMCPとMCPの比較のページ）は、違いを次のように表しています。
| 観点 | MCP | WebMCP |
|---|---|---|
| 動く場所 | 永続的（サーバーとデーモン） | 一時的（タブに紐づく） |
| 届く範囲 | 全域（デスクトップ、モバイル、クラウド、Web） | 環境限定（ブラウザのエージェント） |
| クライアント | ブラウザの内外を問わないAIエージェント | ブラウザ内蔵のエージェントのみ |
| 向いているもの | バックグラウンドでのAPI操作 | ライブのWeb UIの操作 |
使い分けについて、Chromeの資料は次の趣旨で書いています。MCPは「いつでもどこでも」データと操作を提供するもの。WebMCPは利用者がサイトを訪れているとき向きで、ツールはページが開いている間だけ存在する。そして、最も効果的なエージェント型アプリは、MCPとWebMCPの両方を使う。MCPはバックエンドのサービス層、WebMCPはブラウザ内の接続を担い、両者は競合ではなくパートナーだという位置づけです。
この表から、判断のヒントが得られます。利用者が自社サイトを開いていない場面でも使われたい機能（たとえば、バックグラウンドでの照会や、別のAIアプリからの呼び出し）は、MCPの領域です。利用者が画面を見ながら進める操作の補助は、WebMCPの領域です。どちらか一方に決める必要はなく、段階的に組み合わせる考え方もあります。WebMCP側の詳しい比較はWebMCPとMCPの違いの記事にまとめています。
認証やログイン状態の扱いは、両者で説明が異なる点です。Chromeの資料は、WebMCPは「ライブのタブにある、ログイン中のセッション情報、Cookie、DOM要素にアクセスする」と述べています。一方、W3Cの草案は、認証を規定しておらず、「ページ自身の実行環境で動く」というところまでしか述べていません。MCPについては、Chromeの比較表に認証・セッションの言及がありません。つまり、MCPサーバーを公開する場合の認証は、自社で設計して決める部分が大きいと考えておくのが安全です。
社内システムをつなぐ話との違い
当サイトには、社内システムをMCPでつなぐ記事があります。そちらは、自社の中の業務システムを、自社で使うAIアプリにつなぐ話です。使う人は社内の人で、権限も社内の仕組みで管理できます。
この記事で扱う「公開」は、使う人が社外にいる場合が中心です。違いを並べます。
| 観点 | 社内システムをつなぐ | 企業がサーバーを公開する |
|---|---|---|
| 使う人 | 社員など、身元が分かる人 | 顧客、取引先、第三者のAIアプリなど |
| 責任範囲 | 社内の運用ルールで決められる | 利用条件や契約で線を引く必要がある |
| 失敗の影響 | 社内にとどまりやすい | 社外の利用者や取引に及ぶ |
| 設計の重心 | つなぐ対象の整理と権限 | 誰に何を見せるかの線引きと、運用体制 |
公開は、窓口を社外に開くことです。社内向けより慎重な判断が要ります。
公開するかを決める五つの判断軸
MCPサーバーを公開するかどうかは、技術の問題である前に、事業の問題です。次の五つの軸で、順に確認します。これは仕様に定められた手順ではなく、考え方の一例です。
- 誰が使うのか：顧客、取引先、自社の別サービス、不特定の第三者のどれを想定するかで、必要な対策が変わります。想定する使い手が曖昧なまま公開すると、後から線引きができなくなります。
- どのデータ・操作を出すのか：公開したい理由を、一つずつ書き出します。「あれば便利そう」だけで出さないことが大切です。個人情報や取引条件が含まれるものは、公開の可否を別に検討します。
- 認証と権限をどうするのか：使う人を見分ける方法と、見分けた人に許す範囲を決めます。誰でも使える公開情報と、本人だけが見られる情報を、同じ窓口に混ぜないほうが管理しやすくなります。
- 責任範囲はどこまでか：AIが誤った操作をした、AIが情報を誤って解釈した、といった場面で、自社がどこまで責任を負うのかを考えます。利用規約や契約に関わるため、法務の専門家に確認してください。
- 運用体制があるか：公開後は、ログの確認、障害対応、問い合わせ対応、権限の見直しが続きます。担当者と手順を決めずに公開すると、そこが先に崩れます。
この五つのうち、一つでも答えが出ないものがあれば、まだ公開の段階ではありません。社内向けの利用や、読み取りだけの小さな範囲から始める、という選択肢もあります。
設計の要点（一般論として）
ここからは、MCPサーバーに限らず、外部に窓口を開くときの一般的な設計の考え方です。MCPの仕様として定められたものではありません。個々の実装は、公式サイトの最新の仕様と、社内のセキュリティ担当や専門家の確認を踏まえて進めてください。
読み取りと書き込みを分ける
データを見るだけの操作と、状態を変える操作は、別のツールとして用意します。読み取りだけのものは、リスクが低く、最初に公開しやすい候補です。書き込み、特に取り消しにくい操作（予約、送金、削除など）は、別の扱いにします。分けておけば、権限も別々に与えられます。
最小権限にする
使い手に与える権限は、目的に必要な最小限にします。「念のため広めに」は、事故のときに影響を広げます。また、一つの窓口が、システム全体に届くようにしないことも大切です。必要な範囲だけに届く、小さな窓口を用意します。
認証を設計する
誰が呼んでいるのかが分からない状態では、権限も制限もかけられません。認証の方式は、使い手の種類と、扱う情報の重さに合わせて選びます。具体的な方式の選び方は、MCPの最新の仕様と、自社のセキュリティ方針を確認してください。WebMCP側の認証と権限の考え方は、WebMCPの認証と権限の記事で整理しています。
ログを残す
誰が、いつ、何を呼んだのか。これが追えなければ、問題が起きたときに原因を調べられません。ログには個人情報が含まれうるので、何を残すか、どれだけ保管するかは、個人情報の取り扱いに詳しい専門家に確認してください。
人の確認をどこに置くか
取り消しにくい操作を、AIの判断だけで実行させない設計は、WebMCPでもMCPでも共通する考え方です。WebMCPの草案には、実世界への影響や取り消せない操作を示すconsequentialHintという注釈があり、クライアントが確認を出せるようにしています。ただし、草案は実行時の確認を必須とは規定していません。確認の仕組みは、自社でも用意する前提で考えるのが安全です。詳しくは人が確認する設計の記事をご覧ください。
ツールの作りは、WebMCPの設計論が参考になる
ツールの名前や説明、入力の決め方は、AIが正しく選べるかを左右します。Chromeの資料は、WebMCPのツールについて、1ツール1機能にすること、説明は「何をするか・いつ使うか」を肯定的な言葉で書くこと、失敗しても立て直せる説明的なエラーを返すことなどを勧めています。これらはWebMCPについての記述ですが、MCPのツールを設計するときの考え方としても参考になります。詳しくはツール設計の記事で扱います。
架空の例：予約サービスの場合
考え方をつかむために、架空の例を使います。以下はすべて架空の例で、実在の事業者や実績とは関係ありません。
ある予約サービスの運営会社が、空き状況の照会をAIアプリから使えるようにしたいと考えたとします。
- 誰が使う：まずは既存の登録会員。不特定の第三者への開放は、後の段階で検討する。
- どの操作：空き状況の照会のみ。予約の確定や取り消しは、最初は含めない。
- 認証と権限：会員を見分けられる方式にして、照会できる範囲を絞る。
- 責任範囲：AIが示した空き状況は参考情報であり、確定は予約画面で行う旨を、利用条件に明記する（文面は法務に確認）。
- 運用体制：呼び出しのログを確認する担当を決める。
この例では、読み取りだけの小さな範囲から始めています。予約を確定する操作は、利用者が画面で行う流れのままです。画面上の操作の補助は、将来WebMCPで検討する、という段階の分け方もできます。順番の考え方は、導入ロードマップの記事も参考になります。
よくある失敗
公開の判断や設計でつまずきやすい点を挙げます。
- 目的がないまま公開する：「流行っているから」で始めると、誰も使わず、運用の負担だけが残ります。
- 既存のAPIをそのまま出す：人や社内のプログラムを前提に作られたAPIは、AIが使う前提になっていません。名前や説明が分かりにくいと、選び間違いが起きます。AIが使いやすい形に整え直す作業が要ります。
- 読み取りと書き込みが混ざっている：一つのツールが両方を担うと、権限も確認も分けられません。
- 権限が広すぎる：「全部できる」窓口は、事故のときの影響も全部に及びます。
- ログと担当者がいない：問題が起きても、何が起きたか追えず、誰が対応するかも決まっていません。
- 外から来る内容を信用しすぎる：AIが読む内容に悪意のある指示が紛れる、プロンプトインジェクションという危険があります。Chromeの資料も、LLMの内側で安全を保証することは不可能だと述べています。外部由来の内容を返すツールには、その前提で注意が必要です。
- 公開後に見直さない：サービスが変われば、ツールも変わります。見直しの周期を決めておかないと、実態とずれていきます。
公開前の点検は、AIエージェント対応サイトのチェックリストの観点も使えます。ただし、このチェックリストはサイト向けのものなので、MCPサーバーの公開には、読み替えて使ってください。
注意点
- この記事の設計の要点は一般論です。MCPの仕様が定める内容ではありません。バージョンや認可方式の細部は、MCPの公式サイトで最新の情報を確認してください。
- WebMCPは草案です。W3Cのコミュニティグループの草案であり、W3Cの標準ではありません。Chromeではオリジントライアルとして提供され、資料は議論の最中で変更される可能性があると明記しています。
- 他のブラウザの対応は確認できていません。Edgeなどの対応時期は、公式な確認ができていません。
- MCPとWebMCPは補い合う関係です。どちらか一方で全部を賄うものではないというのが、Chromeの資料の見方です。
- 法務・セキュリティ・個人情報に関わる判断は、専門家に確認してください。責任範囲、利用条件、ログの扱い、認証方式の選定などが該当します。この記事は、それらを断定するものではありません。
Otsumuに相談できること
公開の判断軸の整理、つまり誰に何を見せるかの棚卸しは、社内で始められます。まず、自社のサービスでできる操作を書き出し、読み取りと書き込みに分けてみてください。それだけでも、公開の範囲が見えてきます。
一方で、どこから公開するか、認証や権限をどう組むか、MCPとWebMCPをどの順で入れるかといった設計は、自社のシステムとの兼ね合いで難しくなりがちです。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しています。その一環として、サービスをAIから使える形にする設計も、ご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。MCPについては、公式サイト（https://modelcontextprotocol.io/）の説明に基づきます。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20