公開日: 2026 年 5 月 18 日
| 商品の解説 | ウェブ | 拡張機能 | Chrome ステータス | インテント |
|---|---|---|---|---|
| GitHub |  オリジン トライアル |
表示 | テストの目的 |
WebMCP ツールの宣言は明確である必要があります。デベロッパーやエージェントが出力を確認して再試行する必要がないようにします。命令型 API と宣言型 API のどちらを使用する場合でも、次のベスト プラクティスに従ってください。
- 構築する前に、ツール戦略を作成します。
- 明確な表現とセマンティック HTML を使用します。
- スキーマを設計して入力を処理します。
- 信頼性の高いツールを構築します。
- テストとデバッグを行います。
セキュリティを重視したツールの作成については、別途記事を公開しています。
ツール戦略を作成する
他のソフトウェア アプリケーションと同様に、まずツール戦略を計画する必要があります。
- 各ツールは 1 つの関数で構成する必要があります。たとえば、ユーザーを特定のフォームタイプに誘導するツールと、入力フィールドをユーザー情報と照合するツールなどです。エージェントがどのツールを使用すればよいか混乱する可能性があるため、重複するツールを作成しないように注意してください。同じ関数で複数のタスクをカバーできるかどうかを自問してください。
- ツールの登録を管理します。特定のページの状態でのみ有用なツールは、その状態になったときに登録し、その状態ではなくなったら登録を解除します。
- 複雑さを軽減する: ほとんどのアプリケーションでは、静的登録をデフォルトのアプローチにする必要があります。
- エージェントにタスクの完了を許可する。厳格な指示や否定的な指示を記述するのではなく、エージェントが正確な手順のフローを管理することを期待するのではなく、タスクを完了するために必要なことをエージェントが理解できることを前提とします。
許可されるツールの最大数はありませんが、各ツールはコンテキスト ウィンドウの一部を使用し、完了までの時間を増やします。提供するツールの数が多いほど、またツール間の重複が多いほど、エージェントが正しいツールを選択するのが難しくなります。テストを行って、アプリケーションに適したものを判断します。
これにより、目的が重複しない個々のツールを構築し、これらのツールが利用可能になるタイミングを管理できます。
明確な言語とセマンティック コードを使用する
明確で正確な言葉を使用して、ツールの名前を付け、その使用方法を説明します。これにより、エージェントは必要なものを見つけ、見つけたものを理解し、デベロッパーが想定したとおりにその情報を使用できます。
ツール名を記述する際は、実行と開始を区別し、何が起こるかを正確に説明する動詞を使用します。たとえば、create-event はイベントをすぐに作成するツールですが、start-event-creation-process はユーザーをフォームにリダイレクトしてイベントを作成するツールです。
明確な説明では、ツールが何をするか、いつ使用するかを説明する必要があります。制限などの否定的な表現ではなく、肯定的な表現と好みに基づいて説明します。
「天気にはこのツールを使用しないでください。」
制限事項は、的確な説明に暗黙的に含まれている必要があります。
「このツールでは、特定の日時に予定されているカレンダーの予定を作成できます。」
この言語は、モデルに何をすべきかを伝えるのではなく、ツールが実行できるアクションを記述します。
認知コンピューティングを最小限に抑える
複雑なタスクを完了する人間の認知負荷を最小限に抑える必要があるのと同様に、モデルの認知コンピューティングも最小限に抑える必要があります。
- ユーザー入力を受け入れる。エージェントに計算や入力文字列の変換を依頼することは避けてください。たとえば、ユーザーが「11:00 から 15:00 まで」と言った場合、ツールはこれを文字列として受け入れる必要があります。これらの時間間の分数を計算するようモデルに指示することは避けてください。
- 文字列、数値、列挙型など、パラメータの特定の型を宣言します。
- 特定の選択を行った理由を説明します。選択した内容は、一目でわかるようにしてください。理由を把握することで、エージェントはより適切な選択を行えるようになります。たとえば、e コマース ショップを運営している場合は、曖昧な ID（
shipping_id=1）ではなく、自然言語（shipping="Express"）で配送タイプを宣言します。
信頼性を優先する
エージェントと人間は、期待どおりに動作するツールから次のようなメリットを得られます。
- レート制限のグレースフル フェイルオーバーを設定します。ツールでは、価格比較などの合理的な繰り返しを許可する必要があります。ツールがレート制限されている場合は、意味のあるエラーを返すか、ユーザーにタスクを手動で実行するようアドバイスします。
- 関数が完了した後にインターフェースの状態を更新します。エージェントはインターフェースに依存して次のステップを計画しますが、関数はインターフェースの読み込みよりも完了に時間がかかることがあります。エージェントは、インターフェースが更新されたら、関数が完了したことを確認するか、更新を再度リクエストする必要があります。
- コードでは厳密に検証し、スキーマでは緩やかに検証する。制約とテストは、バイナリ ロジックを含む関数とコードに使用する必要があります。スキーマの制約は役立ちますが、保証されるものではありません。モデルが自己修正し、新しい有効なパラメータで再試行できるように、関数コードに説明的なエラーを追加します。
評価テストとデバッグ
評価テストを作成し、デバッグにツールを使用できるようにします。決定論的な単体テストとは異なり、出力が予期しない形式になる可能性があるため、評価をハードコードすることはできません。
- 問題を明確にする。入力タイプ、出力形式、追加の制約など、API 契約のように問題をフレーム化できます。
- ベースラインと理想的な結果を定義します。特にテキスト入力では、どのような結果が得られれば期待どおりの出力が得られるかを理解することが重要です。
- 出力を評価する方法を決定します。入力の質、有用性、次のタスクを達成する能力に基づいて、主観的で定性的な結果を特定して測定します。出力の評価には、ルールベースの出力（文字数制限）のコードベースのチェックや LLM-as-a-judge など、さまざまな手法を使用できます。
特定のモデルの問題を修正するために、狭いルールを追加することは避けてください。たとえば、敬称の選択フィールドを含めると、モデルが間違った選択をする可能性があります。この問題を修正するために狭いルールを追加するのではなく、ツールを抽象化して調整してください。このフィールドを省略可に設定するのが最善の方法かもしれません。次に、エージェントにユーザーにどの選択肢が適切か尋ねてもらい、ユーザーが結果に満足できるようにします。
意見交換とフィードバックの提供
WebMCP は現在活発な議論が行われており、今後変更される可能性があります。これらの API を試してフィードバックがある場合は、ぜひお聞かせください。
- WebMCP の説明を読む、質問を投稿する、ディスカッションに参加する。
- Chrome のステータスで Chrome の実装を確認してください。
- 早期プレビュー プログラムに参加して、新しい API をいち早く確認し、メーリング リストにアクセスしましょう。
- Chrome の実装についてフィードバックがある場合は、Chromium のバグを報告してください。