公開日: 2026 年 5 月 18 日
WebMCP ツールの宣言は明確で、 デベロッパーやエージェントが出力を確認して再試行する必要がないようにする必要があります。Imperative API と Declarative API のどちらを使用する場合でも、次のベスト プラクティスに従ってください。
- ビルドする前に、ツール戦略を作成します。
- 明確な言葉とセマンティック HTML を使用します。
- スキーマを設計して入力を処理します。
- 信頼性の高いツールを構築します。
- テストとデバッグを行います。
セキュリティを重視したツールの作成については、別途説明しています。
ツール戦略を作成する
他のソフトウェア アプリケーションと同様に、最初の手順はツール戦略を計画することです。
- 各ツールは 1 つの関数で構成する必要があります 。たとえば、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 のバグを報告してください。