この記事は、自社サイトにWebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を載せようとしている、事業責任者や担当者に向けて書いています。読み終えると、ツールを何個にするかではなく、何を基準に絞り、いつ登録するかを判断できるようになります。
先に断っておくと、「何個がよい」という決まった数はありません。仕様の草案にも、そうした数値は示されていません。そこでこの記事では、数を決めるための軸を整理します。なお、WebMCPは草案の段階で、内容が変わり続けています。記事の内容は2026年10月20日時点の確認に基づきます。
ツールの設計そのものは、WebMCPのツール設計の記事で扱います。全体像を先に知りたい方は、WebMCPの入門記事から読むと流れがつかめます。
ツールが多すぎると、何が困るのか
ツールを増やせば、エージェントができることも増えます。そう考えがちですが、仕様の草案は逆の面も指摘しています。ツールの数は、モデルの文脈量（一度に読み込める情報の量）に制約される、という点です。
エージェントは、ツールの名前と説明を読んで、どれを呼ぶかを選びます。ツールが多いほど、その読み込み量は増えます。数が増えると起きやすい困りごとを、三つに分けて考えます。
- 文脈を圧迫する：説明文が長いツールを大量に並べると、肝心の会話や指示に使える余地が減ります。
- 選び間違いが増える：似たツールが並ぶと、エージェントが違うほうを選ぶ可能性が高まります。
- 説明が重なる：「商品を探す」と「商品を検索する」のように、役割が重なると、どちらが正しいか判断できません。
どのくらいの数から困り始めるかは、使うモデルやエージェントの作りで変わります。公式な目安は確認できていません。ですから、自社の環境で試して確かめるのが確実です。
絞り方：頻度・価値・リスクで選ぶ
では、どのツールを残すか。ここでは、頻度・価値・リスクの三つの軸で見る方法を紹介します。これは仕様に書かれた手順ではなく、考え方の一例です。
| 軸 | 問い | 高いときの扱い |
|---|---|---|
| 頻度 | 利用者はその操作をどのくらい頻繁に行うか | 優先して公開を検討する |
| 価値 | エージェントが代行すると、利用者と自社に意味があるか | 優先して公開を検討する |
| リスク | 誤って実行されたとき、取り消しにくい影響が出るか | 後回しにするか、確認を挟む設計にする |
頻度と価値が高く、リスクが低いものが、最初の候補です。たとえば、在庫や料金の照会のような、読み取りだけの操作です。草案には、読み取りのみを示すreadOnlyHintという注釈があります。こうした操作には、この注釈を付けられます。
逆に、予約や送金のように、実世界への影響が大きい操作もあります。草案には、そうした操作を示すconsequentialHintという注釈があります。クライアント（エージェントを動かす側）は、これを手がかりに確認を求められます。ただし、草案は確認を必須とは定めていません。ですから、自社側でも慎重に扱う必要があります。
最初は、少数の読み取り系ツールから始めるのが無理のない進め方です。そのうえで、反応を見ながら増やします。リスクの高い操作を最初から入れる理由は、あまりありません。
ページや状況に応じて、登録を切り替える
ツールを絞る方法には、もう一つあります。常に全部を見せるのではなく、いま必要なものだけを登録することです。草案は、状況に応じた動的な登録を勧めています。一方、Chromeのベストプラクティスは、静的な登録を多くのアプリの既定とし、ツールの数に上限はないが1つごとに文脈量と時間を使うので試して決めるよう述べています。どちらが合うかは、自社のツール数と画面構成で決めます。
登録と解除に使う仕組みを整理します。窓口はdocument.modelContextです。HTTPSなどの安全な接続が必要です。初期の資料にあった navigator.modelContext は、廃止の方向にあります。
| やりたいこと | 使う仕組み | 補足 |
|---|---|---|
| ツールを登録する | registerTool | 名前が重複する、または名前・説明が空だと失敗する |
| ツールを登録解除する | 登録時に渡す signal（AbortSignal） | signal を中止すると、登録が解除される |
| 増減に気づく | toolchange イベント | ツールが増えたり減ったりしたときに発生する |
| 一覧を確認する | getTools | 登録されているツールの一覧を取得する |
使い方のイメージは単純です。ページを開いたときに、そのページに合うツールを登録します。ページを離れる、または状況が変わったときに、signal を使って解除します。こうすれば、エージェントが見るツールの数は、その場面に必要な分だけになります。
toolchange イベントは、ツールの増減を知らせるものです。エージェント側は、これでツール一覧の変化に気づけます。自社の側も、想定どおりに登録と解除が動いているかを確かめる材料にできます。
名前や説明を変えるときは、解除してから登録し直す
運用で見落としやすい点があります。草案には、登録済みのツールの内容を更新する仕組み（updateTool のようなもの）が、いまのところありません。これは既知の課題として挙げられています。
そのため、ツールの名前、説明、入力スキーマ（入力項目の定義）を変えたいときは、次の手順になります。
- 変えたいツールを、signal で登録解除する。
- 新しい名前・説明・スキーマで、registerTool を呼び直す。
手順自体は難しくありませんが、変更の途中で一瞬ツールがない状態になります。エージェントが実行している最中に切り替えると、混乱するかもしれません。変更は、なるべく画面の切り替わりなど、区切りの良い場面で行うのが安全です。この点は、草案が将来変える可能性もあります。実装前に、最新の仕様を確認してください。
画面ごとのツール設計の例
ここでは、考え方をつかむために、架空の例を使います。以下はすべて架空の例で、実在のサイトや実績とは関係ありません。
架空の例：宿泊予約サイトの場合
| 画面 | 登録するツールの例 | 考え方 |
|---|---|---|
| 一覧ページ | 条件で宿を検索する／並び順を変える | 読み取り中心。軽い操作だけを出す |
| 詳細ページ | 空き状況を確認する／料金の内訳を調べる | その宿に関する照会に絞る |
| 購入（予約）ページ | 予約内容を確認する／予約を確定する | 確定は影響が大きい。確認を挟む前提で設計する |
この例では、一覧ページに予約確定のツールを出していません。詳細ページには、検索のツールを出していません。画面ごとに必要なものだけを登録するので、エージェントが見る選択肢は、数個程度に抑えやすくなります。
予約確定のツールには、consequentialHint を付けるのが筋です。さらに、ツールの説明に、確認を出すよう促す指示を含める方法もあります。Chromeの資料は、購入のような重要な操作で、ユーザーに確認ダイアログを出す指示を含められると述べています。
もう一点。この例の「何個」は、説明のための仮のものです。実際の数は、自社のサイトの作りと、使うエージェントで変わります。
ツール同士の重なりを避ける
数を絞っても、残したツールが重なっていては意味がありません。重なりを避けるための点検項目を挙げます。
- 一つのツールは、一つの目的に絞る。「検索も予約もできる万能ツール」は避ける。
- 名前は、動作が分かる言葉にして、似た名前を並べない。
- 説明には、「何をするか」に加え「いつ使うか」を肯定的な言葉で書く（Chromeの資料は、否定形の指示を避けるよう勧めています）。
- 条件の違いだけで別ツールにせず、入力項目で表せるものは一つにまとめる。
説明と実際の動作が食い違わないことも大切です。草案は、宣言と実際の動作が一致する保証がない点をリスクとして挙げています。たとえば、名前が finalizeCart なのに、実際には購入まで行ってしまう、といった例です。名前と動作は、一致させておきましょう。
入力スキーマの厳しさにも触れておきます。草案は、厳しすぎる検証がエージェントを止めうると指摘しています。execute 側でも入力を確かめ、次に何をすればよいか分かるエラーを返すのがよいとされています。この点はツール設計の記事で詳しく扱います。
見直しの周期と、使われないツールの削除
ツールは、登録して終わりではありません。サイトの機能が変われば、ツールも変わります。見直しの習慣を、最初から決めておくと楽です。
- 周期を決める：たとえば、機能を追加するたび、または数か月ごとに、一覧を点検する。周期は自社の更新頻度に合わせる。
- 使われ方を見る：どのツールが呼ばれ、どれが呼ばれないかを記録する。呼び出しの履歴は、DevToolsの呼び出し一覧（Invoked tools）で確かめられる。
- 使われないものを外す：目的が重なっているもの、画面から消えた機能に紐づくものは、削除を検討する。
- 説明を直す：呼ばれてほしいのに呼ばれないツールは、説明があいまいな可能性がある。
呼ばれない理由は、いくつか考えられます。説明が分かりにくい、似たツールに負けている、そもそも需要がない、などです。原因を決めつけず、一つずつ確かめてください。
見直しの結果は、記録に残しておくと役に立ちます。ツールを増やした理由と、外した理由を書いておけば、担当者が替わっても判断の筋道が残ります。チェックの観点は、AIエージェント対応サイトのチェックリストも参考になります。
注意点
- 仕様は変わります。W3Cのコミュニティグループの草案は、W3Cの標準ではありません。Chromeの資料も、議論の最中で変更される可能性があると明記しています。
- 対応状況は限られます。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、公式な確認ができていません。
- 数の目安は確認できていません。この記事の考え方は、判断の軸の一例です。自社の環境で試し、確かめてください。
- ツールは補完です。人が使う画面が主役であることに変わりはありません。ツールは、それを補うものです。
- 重要な操作は人が確認します。購入や送金のような操作は、確認の仕組みを自社でも用意してください。
プロンプトインジェクション（ツールの説明や出力に紛れた悪意ある指示）などの危険もあります。安全面は、専門家の確認も受けながら進めてください。
Otsumuに相談できること
ツールの棚卸しと、絞り込みの軸づくりは、社内で始められます。まずは、サイトでできる操作を書き出し、頻度・価値・リスクで仕分けてみてください。少数の読み取り系ツールから試すだけでも、多くの発見があります。
一方で、画面ごとの登録の切り替えや、重要な操作の確認設計は、実装との兼ね合いで難しくなりがちです。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しています。その一環として、サイトを「AIが使える形」にする設計も、ご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20