この記事は、WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）のツールを公開した、または公開を計画している運用担当者や事業責任者に向けて書いています。読み終えると、ツールの効果と問題を見るための指標を、自社のサイトに合わせて設計する手順が分かります。
先に断っておくと、WebMCPは草案の段階です。本番サイトでの計測について、標準的な手法は確認できていません。この記事の指標や手順は、仕様に書かれたものではなく、考え方の一例です。確認は2026年10月20日時点の内容に基づきます。
ツールの作り方はツール設計の記事、全体像はWebMCPの入門記事で扱っています。
計測について、公式資料で確認できること・できないこと
まず、足場になる事実を整理します。Chromeの公式資料は、開発者向けツール（DevTools）のApplicationタブにWebMCPの画面があると説明しています。そこでは、次のことが確認できます。
- Available tools：エージェントから見える形のツール名と説明、そして呼び出し回数。
- Invoked tools：呼び出しの履歴。状態（Completed／Canceled／In Progress／Error）、入力、出力やエラーが見える。
- フィルター：名前、状態、種類（宣言的／命令型）で絞り込める。
エージェントがツールを選んでくれないときは、この呼び出しカウンターで確認する、というのがChromeの資料の案内です。また、設計の最後の手順として「公開後はログを見て改善する」ことも勧めています。
一方で、公開した本番サイトで、利用者ごとの呼び出しをどう集計するか、という標準的な手法は、資料から確認できていません。DevToolsは、開発者の手元で確かめるための道具です。本番の数字は、自社でログを設計して取ることになります。
ほかにも、確認できていないことがあります。Chromeの安全性のページには、認証・ログ・入力検証・データ最小化の具体的な指針がありません。ですから、ログの設計は、自社の判断と専門家の確認が前提です。
見る指標の候補
指標は、多ければよいわけではありません。「ツールが使われているか」「使われた結果うまくいったか」「事業に何かつながったか」の三段で考えると整理しやすくなります。以下は候補の一覧です。数値の目標や相場は、ここでは示しません。
| 指標 | 何が分かるか | 見るときの注意 |
|---|---|---|
| 呼び出し回数 | ツールが選ばれているか。使われないツールの発見 | 回数が多いことが成功とは限らない。やり直しで増えることもある |
| 成功率 | 呼び出しが正常に終わった割合 | 「何をもって成功とするか」を、ツールごとに先に決める |
| エラーの種類 | 入力の誤り、状態の不一致、結果なしなど、直す場所 | 種類を分けて記録しないと、原因が見えない |
| 人の確認に至った割合 | 重要な操作で、利用者の確認や取り消しがどのくらい挟まったか | 確認が多い＝悪い、ではない。設計意図どおりかを見る |
| 離脱 | ツールの途中で、利用者が操作をやめた地点 | どの手順でやめたかを見る。理由は推測にとどめる |
| 問い合わせや購入への寄与 | ツール経由の操作が、事業の成果につながったか | 因果の断定は難しい。他の経路との比較は慎重に |
成功率やエラーは、Chromeの資料が示す設計の考え方と相性がよい指標です。同資料は、失敗しても立て直せる返答（たとえば「状態が違うので先に検索してください」「日付の形式が違うのでYYYY-MM-DDで」「結果なしなので条件を変えてください」）を勧めています。こうした返答の種類をそのままエラーの分類にすると、ログが読みやすくなります。詳しくはエラー設計の記事で扱います。
草案が用意しているイベントを、手がかりにする
仕様の草案には、ツールの動きを知るためのイベントがあります。
- toolchange：ツールの増減。
- toolactivated：Chromeの宣言的APIの資料では、エージェントが項目を入力し終えたとき（送信の前）。草案での意味と異なる場合があるため、混同しないでください。
- toolcancel：実行が中断されたとき。
実行の開始と中断が分かれば、「始まったのに終わらなかった」数を数える材料になります。ただし、これらのイベントを集計に使うときの作法は、仕様にも資料にも書かれていません。自社のページで、どのイベントを拾うかは、動作を確かめながら決めてください。
また、execute（ツールが実行する処理）には、入力オブジェクトと中断用のsignalが渡されます。草案では、エージェントの種類などを渡すオブジェクトはありません。つまり、どのエージェントが呼んだかを、execute側で知る仕組みは、現時点では見当たりません。
エージェント起因の操作を見分ける
「人が自分で操作した場合」と「エージェントが操作した場合」を分けて見たい、という要望はよくあります。分けられると、エージェント経由の成果を、別の数字として追えるからです。
Chromeの資料によると、宣言的API（HTMLのフォームにtoolnameとtooldescriptionを付けてツールにする方式）では、フォームの送信イベントにSubmitEvent.agentInvokedがあります。これがtrueなら、エージェント起因の送信です。
ここで注意が必要です。
- SubmitEvent.agentInvokedは、宣言的APIの場合の話です。命令型API（registerToolで登録する方式）で、同じように見分ける仕組みは、確認できていません。
- 宣言的APIは、Chromeの資料では紹介されていますが、W3Cの草案の本文（2026年10月時点）には、まだ含まれていません。仕様の位置づけが変わる可能性があります。
- 宣言的APIの既定の動きは、利用者が送信ボタンを押して完了する形です。toolautosubmit属性を付けると、モデルの呼び出し時に自動で送信されます。どちらの設定かで、ログの意味も変わります。
命令型APIのツールでは、自社のコードの側で、どのツール経由の処理かを記録する方法が考えられます。たとえば、ツールの処理の中から呼ぶ内部の関数に、「ツール経由」という印を渡す設計です。これは一例で、仕様の機能ではありません。
自社のログを設計する
本番の計測は、自社のログが頼りです。次の点を、最初に決めておくと後が楽です。
- 何のために取るかを決める：「ツールの選ばれ方」「エラーの直し先」「確認の挟まり方」など、改善に使う目的から逆算する。目的のない記録は、取らない。
- 個人情報を残さない：ツールの入力には、氏名、連絡先、住所などが入ることがあります。ログには、入力の中身そのものではなく、「どの項目が空だった」「形式が違った」といった種類の情報にとどめる設計を検討してください。
- 保存期間を決める：必要な期間だけ保存し、過ぎたら消す。期間は、目的と社内の規程に合わせて決める。
- 誰が見られるかを決める：閲覧できる人を限る。
- 出力の扱い：ツールが返した内容に、利用者の情報が含まれる場合は、同様に注意する。
Chromeの資料は、ツールが返す出力の量を短く保つ目安（1.5K文字程度）を挙げていますが、これはエージェントに渡す内容の上限の目安で、ログの設計の指針ではありません。混同しないでください。
個人情報の取り扱い、同意の取り方、保存期間の決め方は、法令や業界のルールに関わります。この記事は、それらに適合することを示すものではありません。実際の設計は、法務や個人情報保護の専門家に確認してください。
数字を、改善のサイクルにつなぐ
数字は、見るだけでは役に立ちません。見たあとに何を直すかを、あらかじめ対応づけておきます。以下は一例です。
| 見えたこと | 考えられる原因 | 試すこと |
|---|---|---|
| 呼び出しが少ないツールがある | 説明が分かりにくい。似たツールに負けている。そもそも需要が少ない | 説明を見直す。重なりを整理する。不要なら外す |
| 入力の誤りが多い | 項目名や説明があいまい。型や選択肢が不明確 | スキーマと説明を直す。入力スキーマの記事も参照 |
| 状態の不一致が多い | 呼ぶ順序が伝わっていない | エラー文に、次にすべきことを書く |
| 途中の中断が多い | 確認の場面で利用者が迷っている | 確認画面の文言と流れを見直す。人の確認の記事を参照 |
改善の手順は、おおまかに次の流れです。
- 指標とログの項目を決める。
- 手元（DevToolsなど）で、ツールが意図どおり呼ばれるか確かめる。
- 公開して、自社のログで確認する。
- 原因の仮説を立て、ツールの説明・スキーマ・エラーを直す。
- 直した結果を、また見る。
手元の確認では、Chromeの資料にある評価（eval）の考え方が使えます。モデルが関わる部分、つまりツールの選択や引数が正しいかを、あらかじめ用意した会話の例で確かめるものです。資料は、実験的な評価ツールがGitHubで公開されていることも示しています。ツール自体の処理は、従来どおりのテストで確かめます。
なお、ツールの内容を変えるときは、登録解除と再登録が必要です。草案には、登録済みのツールを更新する仕組みが、いまのところありません。頻繁に直す場合は、その手間も見込んでください。この点は現状とロードマップの記事も参照してください。
画面ごとの計測の例
ここでは、考え方をつかむために、架空の例を使います。以下はすべて架空の例で、実在のサイトや実績とは関係ありません。
架空の例：中古家具の通販サイトの場合
| ツール（架空） | 見る指標 | 読み方の例 |
|---|---|---|
| 商品を検索する | 呼び出し回数、結果なしの種類 | 結果なしが多ければ、検索条件の説明や、候補の出し方を見直す |
| 在庫を確認する | 成功率、エラーの種類 | 商品の指定の誤りが多ければ、商品IDの渡し方を説明に書く |
| 注文内容を確認する | 確認に至った割合、中断 | 購入の直前で中断が多ければ、確認画面の分かりやすさを見る |
この例の「結果なしの種類」「中断」は、あくまで説明のための項目です。実際にどの項目を取るかは、サイトの作りと目的で決まります。数字の良し悪しの基準も、ここでは示しません。まず自社の数字を取り、その変化を見るところから始めてください。
よくある失敗
- 指標だけを追う：呼び出し回数を増やすために、似たツールを増やしたり、説明を誇張したりすると、かえって選び間違いが増えます。指標は、利用者の目的が果たせたかを見るための手段です。
- 同意のない計測：利用者に知らせず、入力内容を残すような計測は避けてください。何を、何のために取るかを、プライバシーに関する説明に反映することを検討してください。具体的な書き方は専門家に確認を。
- 個人情報をそのまま保存する：入力の中身を丸ごと残すと、管理の負担と漏えいの危険が増えます。
- 成功の定義がない：何をもって成功とするかを決めないまま、成功率を出しても読めません。
- 寄与の言い切り：ツール経由の成果が、そのまま事業の成果とは限りません。他の経路との重なりを考えてください。
- 安全面を後回しにする：ツールの説明や出力に、悪意ある指示が紛れる（プロンプトインジェクション）危険は、計測とは別に対策が必要です。
公開前後の点検には、AIエージェント対応サイトのチェックリストも使えます。
注意点
- 仕様は変わります。W3Cのコミュニティグループの草案は、W3Cの標準ではありません。Chromeの資料も、議論の最中で変更される可能性があると明記しています。
- 対応状況は限られます。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- 計測の標準手法は確認できていません。この記事の指標は、考え方の一例です。自社の目的に合わせて設計してください。
- ツールは補完です。人が使う画面が主役であることに変わりはありません。
- 法務・個人情報・セキュリティは専門家に確認してください。ログの設計は、これらに関わります。
Otsumuに相談できること
指標の洗い出しと、ログに残す項目の整理は、社内でも始められます。まず、公開したツールごとに「何ができれば成功か」を書き出してみてください。
一方で、ログの設計や、改善のサイクルを回す体制づくりは、サイトの作りや社内の規程との兼ね合いで難しくなりがちです。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、その一環として、サイトを「AIが使える形」にする設計と、その運用もご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20