この記事は、BtoB SaaS（企業向けのクラウドサービス）を運営する事業責任者や担当者に向けて書いています。WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を自社サービスに使うとき、どの操作をAIに開き、どの判断を人が持つべきかを整理します。読み終えると、開く操作の候補を仕分ける基準と、最初の一歩が分かります。
WebMCPは草案の段階で、内容が変わり続けています。この記事の内容は、2026年10月20日時点の確認に基づきます。例はすべて架空の例で、実在のサービスや実績とは関係ありません。
WebMCP全体の概要は、先にWebMCPの入門記事で確認すると、流れがつかみやすくなります。
BtoB SaaSの画面は、料金ページ、ヘルプ、トライアル申込、ログイン後の管理画面、サポート窓口と、役割の違う場面が並んでいます。利用者の側も、導入を検討する担当者、実際に使う担当者、契約や権限を管理する管理者と、立場が分かれます。
ブラウザ上のAIエージェントが、こうした利用者の代わりに調べたり入力したりする場面は、今後増えるかもしれません。そのとき、画面をなぞって操作させるのではなく、サービス側が「この操作はツールとして使ってよい」と明示できるのがWebMCPの考え方です。エージェントは、ツールの名前と説明、入力スキーマ（入力項目の定義）を読んで呼び出します。
ただし、BtoB SaaSには、誤操作の影響が大きい画面が含まれます。たとえば、管理画面の設定変更は、一つの誤りが組織全体に及びます。何でも開けばよいわけではなく、開く操作と開かない操作を分ける作業が中心になります。
WebMCPは、W3C（Web技術の標準化団体）のコミュニティグループが公開している仕様草案です。W3Cの標準ではなく、標準化の手順に載った仕様でもありません。Chromeでは、Chrome 149 からオリジントライアル（一部のサイトで試せる実験的な提供）として使えます。Chromeの資料も、議論の最中で変更される可能性があると明記しています。Edgeなど他のブラウザの対応時期は、確認できていません。
また、WebMCPは人が関わる使い方を主に想定しています。画面を使う人が主役で、ツールはそれを補う位置づけです。完全に自律して、画面なしで動かす運用を想定した仕組みではありません。この前提は、後の「人が持つべき判断」にも関わります。
AIに開く操作の候補
BtoB SaaSでよくある場面を、開く操作の候補として並べます。これは仕様に書かれた分類ではなく、考え方の一例です。注釈は、草案とChromeの資料にあるreadOnlyHint（読み取りのみ）、consequentialHint（実世界への影響や取り消せない操作）、untrustedContentHint（返す内容が信頼できない可能性）を使っています。
| 場面 | ツールの例（架空） | 性質 | 扱いの考え方 |
|---|---|---|---|
| 料金・機能の照会 | プランの比較を取得する／機能の有無を調べる | 読み取り | 最初の候補。readOnlyHintを付けられる |
| ヘルプ検索 | ヘルプ記事を検索する／記事の要約を返す | 読み取り | 候補。利用者の投稿を含むなら、untrustedContentHintを検討する |
| トライアル申込 | 申込フォームの入力を支援する | 書き込み | フォームを見える形で残し、送信は本人が押す設計が無理がない |
| サポート問い合わせの起票 | 問い合わせ内容の下書きを作る／起票する | 書き込み | 下書きまでをツール、送信は本人の確認にする案がある |
| 管理画面での設定変更 | ユーザーを追加する／権限を変更する | 書き込み（影響大） | 権限と確認が要る。consequentialHintの対象。慎重に判断する |
上から下へ行くほど、誤ったときの影響が大きくなります。照会やヘルプ検索は、情報を返すだけなので、比較的始めやすい領域です。一方、設定変更は、権限の問題と取り消しにくさの両方があります。
サポート問い合わせの起票については、Chromeの資料がサポート関連の例（保証請求の手続きを始めるツールなど）を挙げています。ここでの「起票」は、サポートへの問い合わせを新しく登録することです。内容に個人情報や契約情報が含まれる場合の扱いは、自社の規程や専門家の確認を踏まえて決めてください。
ログイン後の画面にだけツールを出す考え方
BtoB SaaSでは、ログインの前と後で、見せてよい操作が大きく違います。料金の照会は誰にでも出せますが、ユーザー追加はログインした管理者にだけ意味があります。
WebMCPでは、ツールはページが開いている間だけ存在します。ChromeのMCP比較の資料は、ツールが一時的で、タブに紐づくと説明しています。この性質を使うと、画面の状態に合わせて登録と解除を切り替える設計ができます。Chromeのベストプラクティスも、ページの状態に合わせて登録し、使えなくなったら解除するよう勧めています。
- ログイン前の公開ページ：料金・機能の照会、ヘルプ検索、トライアル申込など
- ログイン後の一般画面：自分に関する情報の照会、問い合わせの下書きなど
- ログイン後の管理画面：管理者の画面を開いている間だけ、設定変更系のツールを登録する
ここで注意したいのは、認証の扱いです。W3Cの草案は、認証やCookie、ログイン状態の扱いを定めていません。「ページ自身の実行環境で動く」という範囲までしか述べていないのです。一方、Chromeの資料（MCPとの比較）は、WebMCPが「ライブのタブにある、ログイン中のセッション情報、Cookie、DOM要素にアクセスする」と説明しています。
つまり、ログイン中の利用者の権限で動くことが想定される一方、権限の検査は仕様が代わりにやってくれるものではありません。ツールを出さないことと、実行されても権限の外なら拒否することの両方を、サービス側のコードで担う必要があります。ツールを出す・出さないは、あくまで入口の話です。
ツールの数を増やしすぎないための考え方は、WebMCPのツール設計の記事が参考になります。
管理画面は、権限と確認が最も重要
管理画面の操作をAIに開くかどうかは、慎重に決める領域です。ここでは、考え方を三つに分けます。
1. 権限は、サービス側で検査する
画面の表示制御だけでは、サーバー側の処理が守られるわけではありません。ツールが見えている・見えていないに関係なく、実行時にその利用者がその操作を許されているかを、サーバー側を含めて、漏れなく検査してください。画面の表示制御だけに頼るのは、避けたほうがよい設計です。
2. 影響の大きい操作には、確認を挟む
consequentialHint は、取り消せない、または影響の大きい操作を示す注釈です。クライアントはこれを手がかりに、利用者の確認を求められます。ただし、草案の本文は、ツール実行時のユーザー確認を必須とは定めていません。確認を出すかどうかはクライアント次第で、仕様が保証するものではありません。
そのため、重要な操作は、サービス側でも確認の段階を設けるのが安全です。たとえば、設定の変更内容を画面に表示し、管理者が確定ボタンを押して初めて反映される、という設計です。Chromeの宣言的API（HTMLのフォームに注釈を付けてツールにする方式）では、既定で利用者が送信ボタンを押して完了します。toolautosubmit 属性を付けると自動送信にもできますが、管理画面の重要な操作では、慎重に検討してください。なお、この宣言的APIは、Chromeの資料では紹介されていますが、W3C草案の本文にはまだありません。
3. 「開始」と「実行」を分ける
Chromeのベストプラクティスには、動詞で「開始」と「実行」を区別する考え方があります。たとえば、即座に作成するツールと、フォームへ誘導するだけのツールを別にします。権限の変更なら、「変更を実行する」ツールではなく、「変更の画面を開き、内容を入力した状態にする」ツールにとどめる案です。最後の確定は、人が画面で行います。
確認の設計は、人の確認（ヒューマン・イン・ザ・ループ）の記事で詳しく扱っています。
人が持つべき判断
AIに開く操作を決めるとき、どの判断を人に残すかを先に決めておくと、設計がぶれません。BtoB SaaSでは、次のような判断が人に残る候補になります。
| 判断 | 人に残す理由（考え方） |
|---|---|
| 契約・料金プランの確定 | 金銭と契約に関わる。取り消しにくい |
| 権限の付与・剥奪 | 組織のセキュリティに直結する。管理者の責任の範囲 |
| 設定の一括変更 | 影響範囲が広い。誤りが全員に及ぶ |
| データの削除・エクスポート | 取り消せない、または情報漏えいにつながる |
| サポートへ送る内容の最終確認 | 機密や個人情報が混ざる可能性がある |
これは網羅的な一覧ではありません。自社のサービスで、誤ったときに取り返しがつかないものは何かを、実際の業務に沿って洗い出してください。
よくある失敗
以下は、BtoB SaaSで起きそうな失敗の例です。いずれも架空の想定で、実際の事例ではありません。
- 権限の取り違え：一般ユーザーの画面にも、管理者向けのツールが登録されたままになる。ツールの登録条件と、実行時の権限検査の両方が必要です。
- 設定の一括変更を一つのツールにする：「全ユーザーの権限を更新する」のような広い操作を一つのツールにまとめると、入力を誤ったときの影響が大きくなります。対象を絞り、1ツール1機能にします。
- 名前と動作の不一致：名前が「設定を確認する」なのに、実際には変更まで行う。草案は、宣言と実際の動作が一致する保証がない点をリスクとして挙げています。
- 説明が長すぎる、または多すぎる：草案の名前の上限は128文字ですが、Chromeの安全性の資料は、名前30文字、ツールの説明500文字などの短い目安を示しています。短く保つほうが安全です。
- 利用者の投稿をそのまま返す：ヘルプのコメント欄などに悪意ある指示が紛れると、プロンプトインジェクション（エージェントに読ませる内容に紛れ込ませた、悪意ある指示）につながる恐れがあります。返す内容が信頼できないなら、untrustedContentHint を検討します。
- エラーを返さず、黙って失敗する：権限がないときに無言で終わると、エージェントも利用者も原因が分かりません。次の手が分かるエラーを返します。
エラーの返し方は、Chromeの資料で、状態が違う・形式が違う・結果がないといった場面ごとに、立て直せる返答にするよう勧められています。業務のルールに反する場合は、ルールと誘導先を伝えるとよいでしょう。
最初の一歩
いきなり管理画面から始める必要はありません。無理のない順序を、考え方の一例として示します。
- 操作の棚卸し：サービス上でできる操作を書き出し、場面（公開ページ、ログイン後、管理画面）ごとに並べる。
- リスクで仕分け：読み取りだけのもの、書き込みだが戻せるもの、取り消しにくいもの、の三つに分ける。
- 読み取り系から試す：料金・機能の照会やヘルプ検索など、readOnlyHint を付けられる少数のツールから始める。
- ローカルで確認する：Chromeのフラグ（chrome://flags/#enable-webmcp-testing）とDevToolsで、ツールの一覧、呼び出しの履歴、スキーマの検証を確かめられる。
- 評価してから広げる：利用者が実際に話しそうな言葉で依頼を想定し、正しいツールが選ばれるかを確かめる。確認できてから、書き込み系へ進む。
なお、WebMCPは、すでにあるAPIやバックエンド連携の代わりではなく、補完する位置づけです。Chromeの資料も、MCPとWebMCPは競合ではなく、併用できるものとして述べています。バックエンドの連携が必要な場面は、従来の方法を検討してください。
公開前の点検項目は、AIエージェント対応サイトのチェックリストにまとめています。
注意点
- 仕様は変わります。W3Cコミュニティグループの草案はW3Cの標準ではなく、Chromeはオリジントライアルです。他ブラウザの対応時期は確認できていません。
- 認証の扱いは仕様の外です。草案は認証やログイン状態を定めていません。権限の検査は、サービス側で行ってください。
- 確認は仕様が保証しません。草案は実行時の確認を必須としていません。重要な操作の確認は、自社でも用意してください。
- 表の内容は一例です。どの操作を開くかは、自社のサービスとリスクの許容度で変わります。
- 法令や契約、個人情報の扱いは、専門家に確認してください。業種や契約形態によって求められる対応が異なります。この記事では、個別の法令には踏み込みません。セキュリティ面も、社内の担当者や専門家の確認を受けながら進めてください。
Otsumuに相談できること
操作の棚卸しとリスクの仕分けは、社内で始められます。まず、サービスでできる操作を書き出し、誤ったときの影響で分けてみてください。
権限の設計、確認の仕組み、画面ごとの登録の切り替えは、実装との兼ね合いで判断が難しくなりがちです。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、その一環として、サービスを「AIが使える形」にする設計もご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20