この記事は、WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を、まず検証環境で試してみたい技術者や企画担当者に向けて書いています。読み終えると、最初の1ツールを動かして確認するまでの流れと、つまずきやすい点が分かります。コードは載せず、文章と表で手順を説明します。
先に断っておくと、WebMCPは草案の段階で、内容が変わり続けています。この記事の内容は2026年10月20日時点の確認に基づきます。実際に作業するときは、最新の公式資料を見直してください。
全体像を先に知りたい方は、WebMCPの入門記事から読むと流れがつかめます。
最初に決めておくこと：検証環境で、読み取り専用の1ツール
最初から複数のツールを公開しようとすると、何が原因で動かないのか切り分けにくくなります。まずは1つに絞り、動作を確かめるのが無理のない進め方です。
最初の1つには、読み取り専用の操作を選ぶのがよいでしょう。状態を変えないので、誤って実行されても影響が小さいからです。たとえば、商品の在庫を照会する、営業時間を返す、といった操作です。購入や送金のように取り消しにくい操作は、設計も確認の仕組みも重くなるため、最初の題材には向きません。
もう一つ大事なのは、本番ではなく検証環境で行うことです。理由は次の三つです。
- 仕様が変わりうる：Chromeの資料は、議論の最中で変更される可能性があると明記しています。本番に載せると、仕様の変更に合わせて急いで直す事態になりかねません。
- 実際に何が見えるかを確かめたい：エージェントから見たツールの姿は、人間が見る画面とは別物です。公開前に確認する場が必要です。
- 実験の機能を使う：Chromeではオリジントライアル（開発中の機能を、期間を区切って試せる仕組み）として提供されています。本番の利用者に影響が出ないよう、切り離して試すのが安全です。
全体の流れ
最初の1ツールを動かすまでの流れを、表にまとめます。手順は筆者が整理したもので、仕様に定められた手順ではありません。
| 順番 | やること | ポイント |
|---|---|---|
| 1 | 読み取り専用の1ツールを選ぶ | 利用者の目的に近く、状態を変えない操作にする |
| 2 | 名前・説明・入力スキーマを決める | 名前と説明は短く、何をするかが分かる言葉にする |
| 3 | registerToolで登録する | 名前が重複する、または名前・説明が空だと失敗する |
| 4 | DevToolsで見えるか確認する | Applicationタブの中のWebMCPを開く |
| 5 | 手動で実行する | パラメータを入れて、結果とエラーを見る |
| 6 | エージェントから呼んでみる | 呼ばれない場合は、説明と呼び出し回数を確認する |
以降では、各段階で何を考えるかを順に説明します。
ステップ1〜2：名前・説明・入力スキーマを決める
WebMCPのツールは、名前、自然言語の説明、入力スキーマ（入力項目の定義。JSON Schemaという形式で書く）、実行する処理（JavaScriptの関数）で構成されます。このうち、最初に時間をかけたいのは名前と説明です。エージェントはこの二つを読んで、使うかどうかを判断するからです。
長さには注意が必要です。W3Cの草案では、名前は128文字以内とされています。一方でChromeの安全性に関する資料は、エージェントに見せる量の目安として、ツール名とパラメータ名は30文字、ツールの説明は500文字、パラメータの説明は150文字、ツールの出力は1.5K文字を挙げています。これは、ツールが渡す内容の上限の目安として示されたものです。草案の上限より実質的に短いので、短く書いておくのが安全です。
説明は、「何をするか」と「いつ使うか」を、肯定的な言葉で書きます。Chromeのベストプラクティスも、制限は暗黙に伝え、硬直した手順や否定形の指示は避けるよう勧めています。ツールの設計全体の考え方は、ツール設計の記事で扱います。
入力スキーマは、型（文字列、数値、選択肢）を具体的にします。ここで一つ、実装でよく迷う点があります。Chromeの資料には「検証はコードで厳しく、スキーマでは緩く」という考え方が出てきます。スキーマを厳しくしすぎると、エージェントが先に進めなくなるからです。詳しくは入力スキーマの記事にまとめています。
ステップ3：registerToolで登録する
登録の窓口は、document.modelContextです。各ドキュメントに存在し、HTTPSなどの安全な接続が必要です。初期の資料にあったnavigator.modelContextは、廃止の方向にあります。古い解説を読むときは、この違いに注意してください。
registerToolには、ツール本体と、任意のオプションを渡します。オプションには、他のオリジンに公開するためのexposedToと、登録を解除するためのsignalがあります。最初の検証では、どちらも使わなくて構いません。既定では、同じオリジンの文書と、ブラウザ内蔵のエージェントから見える状態になります。
実行する処理（execute）は、解析済みの入力オブジェクトと、中断用のsignalを受け取ります。Chromeの資料の例では、executeは文字列を返します。草案でも、executeTool経由で受け取る結果は文字列化されます。まずは、短い文章で結果を返すところから始めるとよいでしょう。
返し方では、エラーの扱いも考えておきます。足りない情報があるとき、日付の形式が違うとき、結果がないときに、次に何をすればよいか分かる文面を返します。「状態が違うので先に検索してください」といった具合です。汎用的なエラーや、生のAPIエラーをそのまま返すのは避けます。エラー設計の記事で詳しく扱っています。
注釈と、登録の解除
読み取り専用のツールには、readOnlyHintという注釈を付けられます。状態を変えないことを示すもので、確認が必要かどうかを判断する材料になります。ほかに、返す内容が信頼できない可能性を示すuntrustedContentHintと、取り消せない操作を示すconsequentialHintがあります。いずれも既定はfalseです。ただし、注釈は宣言にすぎず、実際の動作と一致する保証は仕様にありません。名前や説明と実際の動作は、自社で一致させる必要があります。
登録を解除したいときは、登録時にAbortSignalを渡し、あとで中止します。Chromeの資料によると、Chrome 153以降は、実行中の処理を中断せずに登録解除できます。検証中は、ページの状態に合わせて登録と解除を試しておくと、後の運用のイメージがつかめます。なお、登録済みのツールの名前や説明を更新する仕組みは、草案にまだありません。変えたいときは、解除してから登録し直します。
環境の準備：オリジントライアルとフラグ
（この準備は、手順の最初に済ませます。）WebMCPは、Chrome 149からオリジントライアルとして提供されています。試す方法は、大きく二つあります。
| 方法 | 向いている場面 | 案内 |
|---|---|---|
| ローカル検証用のフラグ | 手元のChromeで、まず動作を確かめる | chrome://flags/#enable-webmcp-testing で有効にする、とChromeの資料にある |
| オリジントライアル | 自社の検証用のオリジンで試す | 登録の手順やトークン（試験への参加を示す文字列）の扱いは、公式資料で確認する |
トークンの具体的な設定値や、設定の細かな手順は、この記事では書きません。公式の手順は更新されるため、Chromeの公式資料の最新版を見て進めてください。
なお、Edgeなど他のブラウザの対応時期は、公式な確認ができていません。検証の結果が、そのまま他のブラウザで再現するとは限らない点も、頭に入れておきましょう。
ステップ4〜5：DevToolsで確認し、手動で実行する
登録できたら、まず人間の目で確かめます。ChromeのDevToolsには、WebMCP用の画面があります。ApplicationタブのサイドバーからWebMCPを開きます。
| 画面の項目 | 見えるもの | 使いどころ |
|---|---|---|
| Available tools | エージェントから見える形の名前と説明、呼び出し回数 | 意図した姿で登録されているかの確認 |
| Invoked tools | 呼び出しの履歴。状態、入力、出力やエラー | 呼ばれた結果の確認。状態はCompleted、Canceled、In Progress、Error |
| フィルター | 名前、状態、種類（宣言的か命令型か）で絞り込み | ツールが増えたときの絞り込み |
手動実行では、ツールを選び、パラメータを入れて、Run toolを押します。入力がスキーマに合わないときは、出力欄にエラーが出ます。ここで、想定どおりの結果とエラーの文面が返るかを確かめます。エージェントを動かす前に、ツール単体の動きを固めておくと、後の切り分けが楽になります。
エージェントがツールを選んでくれないときは、呼び出しのカウンターを見ます。回数が増えなければ、そもそも選ばれていません。その場合は、名前や説明が分かりにくい可能性があります。
ステップ6：エージェントから呼ぶ
最後に、エージェントから実際に呼んでみます。Chromeの資料では、検証用の拡張機能（Example Agentic Chrome ExtensionとModel Context Tool Inspector Extension）が紹介されています。こうした道具を使うと、エージェントがツールを選んで実行する流れを確認できます。
確認のときは、利用者が実際に話しそうな言葉で依頼してみます。Chromeの資料も、設計の段階で会話をロールプレイすることを勧めています。曖昧な依頼をしたとき、エージェントが推測せずに足りない情報を尋ねられるか、失敗したときに立て直せるか、といった点も見ます。評価の考え方は、公式資料のevalsのページにまとまっています。
ここまでの結果は、記録しておきましょう。どの言い回しで呼ばれ、どれで呼ばれなかったかが、説明の改善の手がかりになります。ツールを増やす前に、この1つで十分に確かめることが大切です。ツールの数の考え方は、AIエージェント対応サイトのチェックリストも参考になります。
よくある失敗
ここでは、検証でつまずきやすい点を挙げます。これは筆者が整理した例で、すべての環境で起きるわけではありません。
| 症状 | 考えられる原因 | 確認すること |
|---|---|---|
| 登録で失敗する | 名前が重複している、または名前や説明が空 | 同じ名前を二重に登録していないか。ページ遷移や再描画で、登録が重なっていないか |
| DevToolsに出てこない | 機能が有効になっていない。安全な接続でない | フラグやトライアルの設定。HTTPSなどで開いているか |
| エージェントが選ばない | 説明が分かりにくい、似たツールがある | 呼び出し回数。説明の「何をするか・いつ使うか」 |
| 実行すると止まる | スキーマが厳しすぎる。エラーの文面が不親切 | スキーマを緩め、コード側で検証して、次の手が分かるエラーを返す |
| 古い解説どおりに動かない | navigator.modelContextなど、廃止方向の記述に従っている | 最新の公式資料と草案の日付 |
もう一つ、見落としやすい点があります。読み取り専用のつもりでも、返す内容に利用者の情報が含まれることがあります。公開の範囲は既定で同じオリジンに限られますが、他のオリジンに見せるときは、見せてよい相手かどうかを慎重に考えてください。
注意点
- 仕様は変わります。W3Cのコミュニティグループの草案は、W3Cの標準ではありません。Chromeの資料も、変更される可能性があると明記しています。
- 対応状況は限られます。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- 本番に出す前に、見直しが必要です。この記事の内容は、検証環境で動かすところまでです。公開の判断には、セキュリティや運用の観点の確認が別に必要です。
- 安全面は専門家の確認を。プロンプトインジェクション（ツールの説明や出力に紛れた悪意ある指示）などの危険があります。個人情報や法務に関わる部分は、専門家に確認しながら進めてください。
- 重要な操作は人が確認します。購入や送金のような操作は、確認の仕組みを自社でも用意してください。人が確認する設計の記事が参考になります。
今後の動きは、WebMCPの現状と今後の記事で随時整理しています。
Otsumuに相談できること
最初の1ツールを動かすところまでは、社内の技術者だけで進められることも多いでしょう。まずは、読み取り専用の操作を1つ選び、検証環境で試してみてください。
一方で、どの操作をツールにするかの見極めや、重要な操作の確認設計、既存システムとの兼ね合いは、悩みどころになりがちです。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しています。その一環として、サイトを「AIが使える形」にする設計も、ご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20