この記事は、WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を実装する担当者や、その進行を見る事業責任者に向けて書いています。読み終えると、ツールが正しく選ばれ、正しく動くかを、どの道具で、どの順に確かめればよいかが分かります。
先に断っておくと、WebMCPはW3Cの標準ではなく、W3C Web Machine Learning Community Group の仕様草案です。Chromeではオリジントライアル（期間限定の試験提供）の段階で、内容は変わる可能性があります。この記事の内容は、2026年10月20日時点の確認に基づきます。
ツールの作り方はツール設計の記事で扱っています。全体像はWebMCPの入門記事から読むとつかめます。
テストは2層に分けて考える
WebMCPのツールは、普通のプログラムと、AIモデルが関わる部分が混ざっています。Chromeの資料に沿って、確かめ方を2層に分けると整理しやすくなります。
| 層 | 確かめること | 方法 |
|---|---|---|
| ツールのロジック | 入力を受けて、決めたとおりの結果や状態更新を返すか | 従来のテスト（単体テストなど） |
| モデルが関わる部分 | エージェントが正しいツールを選び、正しい引数を渡すか | eval（評価） |
前者は、これまでのWeb開発と同じです。同じ入力なら同じ結果が返るので、合否がはっきりします。後者は、モデルの出力が確率的で、毎回まったく同じとは限りません。だから、1回の成功で安心せず、複数の会話例で傾向を見るのがevalの考え方です。
この2層を混ぜないことが、最初のコツです。ツールが選ばれない原因が、説明文にあるのか、ロジックの不具合なのかを切り分けやすくなります。
DevToolsで、ツールの見え方と動きを確かめる
Chromeには、WebMCPのツールを確認する画面があります。DevToolsのApplicationタブを開き、サイドバーのWebMCPを選びます。ローカルで試すときは、Chromeの資料にあるフラグ（chrome://flags/#enable-webmcp-testing）を使います。
画面で見られるものを整理します。
| 項目 | 分かること |
|---|---|
| Available tools | 登録されているツールの名前と説明（エージェントから見える形）、呼び出し回数 |
| Invoked tools | 呼び出しの履歴。状態（Completed、Canceled、In Progress、Error）、入力、出力やエラー |
| フィルター | 名前、状態、種類（宣言的か命令型か）での絞り込み |
| 手動実行 | ツールを選び、パラメータを入れて「Run tool」で実行できる |
使いどころは三つあります。一つ目は、説明文の確認です。Available toolsに出る名前と説明が、そのままエージェントに見える内容です。読み返して、意味が通じるか、似たツールと紛らわしくないかを見ます。
二つ目は、手動実行です。エージェントを介さず、自分でパラメータを入れて動かせます。スキーマ（入力項目の定義）に違反した入力を渡すと、出力欄にエラーが出ます。想定外の入力にどう反応するかを、ここで確かめられます。
三つ目は、呼び出しの確認です。エージェントがツールを選んでくれないとき、呼び出しカウンターが増えているかを見れば、そもそも呼ばれていないのか、呼ばれたが失敗したのかが分かります。後者ならInvoked toolsで入力とエラーを追えます。
なお、Chromeの資料には、DevTools for agents という別の仕組みの list_webmcp_tools と execute_webmcp_tool もあります。ただし既定ではオフで、有効にするには --categoryExperimentalWebmcp を指定する必要があるとされています。実験的な機能と考えてください。
executeToolで、ツールを単体で動かす
プログラムからツールを動かすには、document.modelContext の executeTool を使います。仕様草案では、引数はツールと入力オブジェクト、任意の options（signal で中断できます）です。結果は文字列として返ります。
これは、ロジック層のテストに向いています。エージェントを使わず、決まった入力で呼び、返りを検査できるからです。確かめる観点の例を挙げます。
- 正しい入力で、期待した結果を返すか。
- 必須項目が足りない、型が違う、値が範囲外のとき、次の手が分かるエラーを返すか。
- 実行後に、画面の状態が更新されるか。
- 登録の解除後に、ツールが一覧から消えるか。
Chromeの資料は「検証はコードで厳しく、スキーマでは緩く」を勧めています。つまり、細かい検査はexecute側で行い、間違いに対しては自己修正できる説明的なエラーを返す、という考え方です。この振る舞いは、単体テストで確かめやすい部分です。エラーの設計はエラー設計の記事で、入力スキーマの書き方は入力スキーマの記事で扱います。
注意が一つあります。executeToolの結果は、ナビゲーション（ページ遷移）が起きた場合に null になる、とChromeの資料に書かれています。画面遷移を伴うツールをテストするときは、この点を踏まえてください。
evalで、選択と引数の確からしさを見る
モデルが関わる部分は、evalで確かめます。Chromeの資料によると、評価用のデータセットは、会話（messages）と、期待する呼び出し（expectedCall）の組で作ります。expectedCall には、ツール名（functionName）と引数（arguments）を書きます。
次は、考え方をつかむための架空の例です。実在のサイトや実績とは関係ありません。
| 項目 | 架空の例の内容 |
|---|---|
| 会話（messages） | 利用者「来週の金曜に、大阪で一泊できる宿を探して」 |
| 期待する呼び出し（expectedCall） | 宿を検索するツール。引数は、日付と地域と泊数 |
| 前提の状態 | 検索画面を開いた状態。その状態で出ているツール一覧を渡す |
ここで大事なのは、前提の状態です。Chromeの資料は、アプリを該当の状態にしたうえで、その状態で出すべきツール一覧をモデルに渡すよう勧めています。画面ごとにツールを登録し分けているなら、その切り替えまで含めて再現しないと、本番と違う条件で測ってしまいます。
複数の手順が続く場合は、期待する呼び出しをグループにして、順序を問う ordered と、順序を問わない unordered を使い分けます。たとえば「検索してから絞り込む」は順序が大事なので ordered、「二つの独立した照会」は unordered が合います。
実験的な評価ツールとして、GitHubの GoogleChromeLabs/webmcp-tools に evals-cli があります。Chromeの資料では実験的と位置づけられているため、使うときは最新の説明を確認してください。判定は、コードによる照合でも、別のモデルに採点させる方法（LLM-as-a-judge）でも行えるとされています。
何を測るのか
Chromeの資料が挙げる、測る対象を整理します。自社のツールに合わせて、優先順位をつけてください。
- 正しいツールの選択：目的に合うツールを選んだか。
- 引数：日付や地域など、会話から正しく値を取り出したか。
- 呼び出しの順序：複数手順の流れが、想定どおりか。
- 前の出力の利用：前のツールの結果を、次の呼び出しに生かしているか。
- 途中で失敗したときの挙動：エラーを受けて、立て直せるか。
- 旅路の完了：利用者の目的まで、たどり着けたか。
はじめから全部を測る必要はありません。まず「正しいツールを選ぶ」と「引数が合う」の二つから始め、足りなければ増やすのが無理のない進め方です。ツールの数や重なりが選択に影響することもあるので、設計の見直しはツール設計の記事と合わせて考えてください。
ロールプレイの会話から、evalを作る
evalの会話例を、ゼロから考えるのは大変です。Chromeの資料のツール作成手順には、ヒントがあります。利用者のゴールと初期状態を定義したうえで、利用者が実際に話す言葉で会話をロールプレイする、という手順です。
この会話の記録が、そのままevalの素材になります。作り方の流れを示します。
- 利用者のゴールを決める。成功の姿と、やってはいけないことも書く。
- 初期状態を決める。画面の状態、使えるフィルター、ログイン前か後か、など。
- 利用者の言葉で会話を書く。丁寧な依頼だけでなく、曖昧な依頼や、情報が足りない依頼も入れる。
- それぞれの会話に、期待する呼び出しを付ける。足りない情報があれば、利用者に尋ねるのが正解になる場合もある。
- 失敗の返答も試す。状態が違う、日付の形式が違う、結果がない、といった場面で、立て直せるか。
公開後は、ログを見て改善する、ともChromeの資料にあります。実際の利用者の言葉は、想像より多様です。ただし、ログには個人情報が含まれることがあります。保存や利用の方法は、社内の規程や、法務・個人情報の専門家に確認してください。
人が確認する場面の設計は人が確認する設計の記事にまとめています。購入や送金のような操作のテストでは、確認の流れまで含めて試してください。
よくある失敗と、評価の限界
Chromeの資料は、evalで見つかった問題への対処として、1つのモデルの癖に合わせた狭いルールを足さないよう勧めています。代わりに、ツールを一般化します。
これも架空の例で考えます。ある呼び出しで、モデルが敬称（さん、様など）を勝手に選んでしまい、evalが落ちたとします。「敬称は『様』に固定すること」と説明に書けば、そのevalは通るかもしれません。しかし、別のモデルや別の会話で破綻しやすくなります。Chromeの資料の例では、敬称を任意の項目にし、エージェントが利用者に選ばせるようにします。ツールの側を、より広い使い方に耐えるようにする発想です。
評価の限界も押さえておきましょう。
- 出力は確率的です。1回通っても、次も通るとは限りません。複数回の実行で傾向を見ます。
- 評価できるのは、自分が提供するツールまでです。利用者が使うエージェントの作りや、モデルの更新は、こちらでは制御できません。
- 安全面の保証にはなりません。Chromeの資料は、LLMの内側で安全を確保することは不可能だと述べています。プロンプトインジェクション（ツールの説明・入力・出力に紛れた悪意ある指示）への備えは、別に考える必要があります。
評価は、一度作って終わりではありません。ツールを足したり説明を直したりするたびに、同じevalを回し直し、前より悪くなっていないかを見る使い方が合います。
実装を終える前に確かめる項目は、AIエージェント対応サイトのチェックリストも参考になります。仕様や対応状況の最新は現状とロードマップの記事で扱っています。
注意点
- 仕様は変わります。W3Cのコミュニティグループの草案は、W3Cの標準ではありません。Chromeの資料も、議論の最中で変更される可能性があると明記しています。テストの手順や画面の名称も、変わることがあります。
- 対応状況は限られます。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- 評価ツールは実験的です。evals-cli は実験的なものと位置づけられています。導入前に、最新の状況を確認してください。
- テストは万能ではありません。確率的な出力を扱うため、通ったからといって、すべての場面で正しく動くとは言えません。
- 個人情報と安全性。テストや改善のためにログを使う場合の取り扱い、セキュリティの検証は、専門家の確認を受けながら進めてください。
Otsumuに相談できること
まずは社内で、画面ごとの利用者の目的を書き出し、ロールプレイの会話を数本作るところから始められます。DevToolsの手動実行だけでも、説明文の分かりにくさや、エラーの不親切さが見つかります。
一方で、評価用のデータセットの設計や、画面の状態を再現するテスト環境づくりは、実装との兼ね合いで手間がかかります。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、その一環として、サイトを「AIが使える形」にする設計と検証をご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20