WebMCP の評価
公開日: 2026 年 5 月 19 日、最終更新日: 2026 年 5 月 28 日
WebMCP は、生成 AI モデルを使用するエージェントをサポートしています。生成 AI を使用するシステムをテストするには、テストで確率的結果をサポートする必要があります。1 つの入力から、精度が異なる数千もの回答が得られる可能性があります。このテスト手法は、評価（eval）と呼ばれます。
ツールを本番環境にリリースする前に、エージェントがツールを呼び出すタイミング、実行方法、許容される回答を理解していることを確認する必要があります。障害が発生する前に、障害が発生する可能性のある箇所に対処します。
大規模言語モデル（LLM）とのシステムのタッチポイントをテストする評価を記述します。
- 説明とスキーマに基づいて、モデルがツールの目的を理解していることを確認します。
- モデルがユーザーの意図をサポートするために、正しいパラメータで適切なツールを選択していることを確認します。
- モデルが受け取った情報に基づいて動作していることを確認します（別のツールを呼び出すために情報を使用するなど）。
- ユーザー ジャーニーが正常に完了することを確認します。ユーザーの意図を踏まえて、提供されたツールを使用して、ウェブサイトでユーザー ジャーニーを完了できますか？
モデルと通信しないシステム インタラクションについては、引き続き従来の決定論的テストを作成する必要があります。
障害モード
デベロッパーは、障害が発生する前にシステムをテストして、障害を未然に防ぐ必要があります。そのためには、システムが単独で、または外部要因と相互作用して障害が発生する可能性のあるタイミングを把握する必要があります。WebMCP の場合、ツール自体が失敗し、エージェントがツールを想定どおりに使用できないことがあります。
WebMCP ツールが失敗する可能性があり、エージェントが WebMCP ツールで失敗する可能性があります。たとえば、ユーザーが T シャツをカートに追加しようとしているとします。
| 失敗 | 例 | トラブルシューティング |
|---|---|---|
| エージェントが適切なツールを選択できないか、間違ったツールを直接呼び出します。 |
エージェントは 
|
|
| エージェントが間違った順序でツールを呼び出す |
エージェントは 
|
|
| エージェントが間違った引数でツールを呼び出す |
エージェントが 
|
|
お客様がカートの中身を確認したい場合はどうすればよいですか？
| 失敗 | 例 | トラブルシューティング |
|---|---|---|
| ツールの出力が正しくないか、ツールで何かが見落とされています。 | ユーザーが 
|
|
最後に、ツールは JavaScript が失敗するあらゆる方法で失敗する可能性があります。トラブルシューティングを行うには、次のことを確認します。
- ツールコードは、発生する可能性のあるすべてのランタイム エラーと例外を適切に処理していますか？
- エラーはエージェントとモデルに適切に報告されますか？
- ツールが依存する外部 API やサービスは正常に動作していますか？
- エラー構造は、モデルが一時的な問題（再試行）と重大な障害を区別できるほど明確ですか？
テストツールを単独でテストする
エージェントが「ピザの S サイズを注文したい」などのリクエストに対してどのツールを呼び出すべきかを判断できない場合、複雑なユーザー ジャーニーでは対応できません。
ツールを個別にテストすることで、ブラウザ シミュレーションを実行する前にスキーマと説明を最適化できます。
通話の精度を測定する
デモの WebMCP zaMaker をご覧ください。ユーザーが「小さいピザを注文したい」とプロンプトを入力すると、モデルは "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 は失敗しましたが、プロセスは完了しました。つまり、ユーザーは割引を受けられませんでした。エージェントが複数のツールを順番に呼び出す必要がある場合があります。このプロセスの途中でツールが失敗した場合はどうなりますか？たとえば、ユーザーがクーポンコードを使用してピザを注文したいとします。
「ペスト ピザの S サイズを 1 枚ください。私のプロモーション コード FreePizza を使用してください。」
エージェントが add_discount_coupon で失敗し、全額のピザの購入手続きに進む可能性があります。add_discount_coupon ツールをテストするには、モデルを操作せずにこの一連のツール呼び出しを手動で実行して、このシナリオをシミュレートします。ツールが失敗すると予想される状態にアプリケーションを移行します。この場合は、start_checkout ツールの後です。その後、add_discount_coupon を個別に評価できます。
WebMCP を試す
ツールを分離して評価し、WebMCP 互換エージェントを使用して WebMCP 対応サイトを評価するテストを開始します。
- GitHub で試験運用版の評価ツールをダウンロードしてください。
- コース「AI 評価を作成する」を確認する。