WebMCP の評価
公開日: 2026 年 5 月 19 日
WebMCP は、生成 AI モデルを使用するエージェントをサポートしています。生成 AI を使用するシステムをテストするには、テストで確率的な結果をサポートする必要があります。1 つの入力に対して、精度が異なる何千もの回答が返される可能性があるためです。この テスト手法は評価と呼ばれます。
ツールを本番環境にリリースする前に、エージェントがツールを呼び出すタイミング、ツールの実行方法、許容される回答を理解していることを確認する必要があります。障害が発生する前に、障害の可能性に対処してください。
評価を作成して、システムと大規模言語モデル（LLM）のタッチポイントをテストします。
- モデルがツールの目的を説明とスキーマに基づいて理解していることを確認します。
- モデルがユーザーの意図をサポートするために、正しいパラメータで適切なツールを選択していることを確認します。
- モデルが受信した情報に基づいて動作していることを確認します（たとえば、情報を使用して別のツールを呼び出すなど）。
- ユーザー ジャーニーが正常に完了することを確認します。ユーザーの意図に基づいて、エージェントは提供されたツールを使用してウェブサイトでユーザー ジャーニーを正常に完了できますか？
モデルと通信しないシステム インタラクションについては、従来の決定論的テストを引き続き作成する必要があります。
障害モード
デベロッパーは、障害が発生する前にシステムをテストする必要があります。そのためには、システムが単独で、または外部要因とのやり取りで障害が発生する可能性があるタイミングを把握する必要があります。WebMCP の場合、ツール自体が失敗することがあり、エージェントがツールを想定どおりに使用できないことがあります。
WebMCP ツールが失敗することがあり、エージェントが WebMCP ツールで失敗することがあります。 たとえば、ユーザーが T シャツをカートに追加したいとします。
| 失敗 | 例 | トラブルシューティング |
|---|---|---|
| エージェントが正しいツールを選択できないか、間違ったツールを直接呼び出します。 |
エージェントが 
|
|
| エージェントが間違った順序でツールを呼び出します |
エージェントが 
|
|
| エージェントが間違った引数でツールを呼び出します |
エージェントが 
|
|
ユーザーがカートの中身を確認したい場合はどうすればよいですか？
| 失敗 | 例 | トラブルシューティング |
|---|---|---|
| ツールの出力が正しくないか、ツールが何かを逃しています。 | ユーザーが 
|
|
最後に、ツールは JavaScript が失敗する可能性がある方法で失敗する可能性があります。トラブルシューティングを行うには、次のことを確認します。
- ツールコードは、考えられるすべてのランタイム エラーと例外を適切に処理しますか？
- エラーはエージェントとモデルに適切に報告されますか？
- ツールが依存する外部 API またはサービスは正常ですか？
- エラー構造は、モデルが一時的な問題（再試行）と重大な障害を区別できるほど明確ですか？
ツールを単独でテストする
エージェントが「ピザを 1 枚ください」のようなリクエストに対してどのツールを呼び出すべきかわからない場合、複雑なユーザー ジャーニーでは対応できません。
ツールを単独でテストすることで、ブラウザ シミュレーションを実行する前にスキーマと説明を最適化できます。
ヒント: WebMCP ツール呼び出しは using navigator.modelContext.executeTool(...) でトリガーできます。
呼び出しの精度を測定する
デモの
WebMCP zaMakerを
ご覧ください。ユーザーが「ピザを 1 枚ください」と入力すると、モデルは
引数を使用して
"size":"Small"呼び出しを実行する意図を示すレスポンスを返します。set_pizza_size
expectedCall 関数は、想定される関数と引数を定義します。このアプローチでは、提供されたスキーマに基づいて、エージェントがユーザーの意図をサポートする正しいツールを選択することが確認されます。
{
"messages": [
{
"role": "user",
"content": "I'd like a small pizza."
}
],
"expectedCall": [
{
"functionName": "set_pizza_size",
"arguments": { "size": "Small" }
}
]
}
expectedCall は、ルールベースの決定論的テストを実行するために使用されます。
WebMCP ツールをコンポーネントのライフサイクルに関連付けることができます。つまり、アプリケーションの状態が WebMCP の想定と一致する場合にテストする必要があります。これを管理するには、評価する状態に関連するツールリストをすべて指定します。たとえば、ユーザーがエージェントと共同ブラウジングを行い、WebMCP zaMaker を開きます。
アプリケーションの状態
[
...
{
"name": "add_topping",
"description": "Add one or more toppings to the pizza",
...
},
{
"name": "set_pizza_size",
"description": "Set the pizza size directly.",
"inputSchema": {
"type": "object",
"properties": {
"size": {
"type": "string",
"enum": [
"Small",
"Medium",
"Large",
"Extra Large"
],
"description": "The specific size name."
},
}
}
},
{
"name": "set_pizza_style",
"description": "Set the style of the pizza (colors/theme)",
...
},
...
]
想定される呼び出し
...
"expectedCall": [
{
"functionName": "set_pizza_size",
"arguments": { "size": "Small" }
}
]
...
WebMCP を開くと、add_topping、set_pizza_size、set_pizza_style のツールが公開されます。これらの個々のツールを正確にテストするには、すべてのツールを含めて、シミュレートされた完全な状態を作成する必要があります。
注: エージェントは追加のツールにアクセスできる場合がありますが、提供したツールを評価することをおすすめします。
エージェントが必要に応じて適切なツールを呼び出すことがわかったら、ツール呼び出しに正しいパラメータが含まれていて、結果が想定どおりであることをテストできます。決定論的テストと確率的テストの 2 つのステップがあります。
決定論的テストを実行する
WebMCP ツールは JavaScript または HTML アノテーションとして構築されているため、決定論的テストを作成して次のタスクを実行できます。
- ツールロジックを確認します。
- 依存関係が正しく呼び出されたことを確認します。
- ユーザー インターフェースが想定どおりに更新されたことと、その他の意図的な副作用を確認します。
- 返された情報が想定される値と一致することを確認します。
- テスト パラメータを検証します。
たとえば、ツールで SearchComponent 関数を使用している場合は、SearchComponent のモックを渡してテストできます。可能な限り最良の結果を得るには、ツールが動作している環境をシミュレートしてください。これは、別のアプリケーション統合テストを作成する場合と同じ手法です。
確率的テストを実行する
モデル出力で次のツールを適切に呼び出す必要がある場合は、評価を作成する必要があります。
ユーザーは、ツールの機能を具体的に尋ねる直接的なクエリや、ツールを使用する必要があることを示唆する曖昧なクエリをモデルに送信できます。たとえば、「ピザにペパロニを追加して」は直接的なクエリです。 「ピザにすべての肉を入れて」はより曖昧で、モデルは add_topping ツールが必要であることと、どのトッピングを肉として定義できるかを理解する必要があります。
評価用のデータセットを作成するときは、ベースライン ツールの実行をテストする直接的なクエリと、モデルの推論とツール選択ロジックをテストするオープンエンドのクエリの両方を含めます。
コーヒー ショップを経営している場合は、エージェントに先月注文したのと同じコーヒーを再注文するように依頼するユーザーをサポートできます。過去の注文を検索するツール OrderHistoryService と、コーヒーを注文するツールを作成します。注文履歴サービスをテストするには、コーヒー商品の ID を返すモックを送信します。
この例では、モデルがクエリの意図を理解し、適切なツールを選択し、そのツールがアクションを実行するための適切な情報を提供しているかどうかを評価します。
モデルが get_order_history を呼び出さない場合、order_product に使用する item_id がわかりません。
エンドツーエンドのテスト
エンドツーエンドのテストを作成して、ユーザーとそのエージェントがジャーニーを正常に完了できることを確認します。個々のツールをテストするだけでなく、複数ステップのアクションが正しい順序で実行されることもテストします。
たとえば、オンラインの衣料品店を経営しているとします。ユーザーがエージェントに「黒いジャケットとジーンズを購入したいのですが、 使用されている素材の内訳を教えていただけますか？」と尋ねます。
エージェントによるジャーニーが成功した場合、次のようになります。
- 衣料品のカテゴリに移動します。
- リクエストされた衣料品のいずれかを見つけます（順序は重要ではありません）。
- 特定のアイテムを見つけます（
search_clothes）。 - 素材リストを含む商品の詳細を取得します（
get_product_details）。 - リクエストされたアイテムごとにステップ 2 ～ 4 を繰り返します。
エージェントがステップ 2 に到達すると、最初に黒いジャケットまたはジーンズを検索できます。順序は重要ではありません。ただし、残りのステップは順番に実行する必要があります。
エージェントが想定される順序でツールを呼び出すことを確認するエンドツーエンドの評価を作成します。
{
"messages": [
{
"role": "user",
"content": "I am looking to buy a black jacket and a pair of jeans.
Could you provide a breakdown of the materials used ?"
}
],
"expectedCall": [
{
"functionName": "navigate_to_category",
"arguments": { "category": "clothes" }
},
{
"unordered": [
{
"ordered": [
{
"functionName": "search_clothes",
"arguments": { "query": "black jacket" }
},
{
"functionName": "get_product_details",
"arguments": { "productId": "JACKET002" }
}
]
},
{
"ordered": [
{
"functionName": "search_clothes",
"arguments": { "query": "jeans" }
},
{
"functionName": "get_product_details",
"arguments": { "productId": "JEANS001" }
}
]
}
]
}
]
}
チェーンの途中で発生する障害を評価する
start_pizza_creator、set_pizza_style、set_pizza_size、start_checkout、add_discount_coupon、および complete_checkout。add_discount_coupon が失敗しましたが、プロセスは完了しました。つまり、ユーザーは割引を受けられませんでした。エージェントが複数のツールを順番に呼び出す必要がある場合があります。このプロセスの途中でツールが失敗するとどうなりますか？たとえば、ユーザーがクーポン コードを使用してピザを注文したいとします。
「ペストのピザを 1 枚ください。プロモーション コード FreePizza を使用してください。」
エージェントが add_discount_coupon で失敗し、定価のピザのチェックアウトに進む可能性があります。add_discount_coupon ツールをテストするには、モデルとやり取りせずに、このツール呼び出しシーケンスを手動で実行して、このシナリオをシミュレートします。ツールが失敗すると予想される状態にアプリケーションを移行します。この場合、start_checkout ツールの後です。その後、add_discount_coupon を単独で評価できます。
WebMCP を試す
ツールを単独で評価し、WebMCP 対応サイトを WebMCP 互換エージェントで評価してみましょう。
- GitHub で試験的な評価ツールをダウンロードします。
- AI 評価を作成するコースを確認します。