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