この記事は、Webサイトにツールを用意する担当のエンジニアと、何をツールにするかを決める企画者に向けて書いています。読み終えると、AIエージェントに正しく使われるツールの名前・説明・入力の決め方を、自分で判断できるようになります。
WebMCPは、サイトの機能を「ツール」としてブラウザ上のAIエージェントに公開する提案です。全体像はWebMCPとAIエージェント対応サイトの入門記事にまとめました。ここでは、その中のツール設計だけを掘り下げます。なお、この記事は仕様の草案をもとにしています。草案は変わり続けているため、実装の前に最新の資料を確認してください。
ツールとは何か：6つの部品
ツールは、AIに渡す「操作の取扱説明書」と、その操作の中身をひとまとめにしたものです。仕様の草案では、次の項目で構成されます。
| 項目 | 役割 | 必須か |
|---|---|---|
| name（名前） | ツールを見分ける名札。128文字以内 | 必須 |
| title（表示名） | 人に見せるための題名 | 任意 |
| description（説明） | 何をするツールかを、自然な言葉で伝える | 必須 |
| inputSchema（入力スキーマ） | 受け取る入力の形をJSON Schemaで定める | 任意 |
| execute（実行処理） | 実際に動くJavaScriptの関数 | 必須 |
| annotations（注釈） | 読み取り専用か、影響が大きいかなどの目印 | 任意 |
登録に使う窓口は、草案ではdocument.modelContextのregisterToolです。名前が重複したり、名前や説明が空だったりすると、登録は失敗します。
ここで大切なのは、AIが主に読むのは「名前」と「説明」と「入力スキーマ」だという点です（注釈なども手がかりになります）。関数の中身は読まれません。つまり、この3つの書き方が、そのままツールの使われ方を決めます。
原則1：1つのツールには、1つの操作だけを持たせる
「予約まわりのことを全部できるツール」は、便利そうに見えて、AIには扱いにくいものです。何ができるのかが説明に収まらず、入力も複雑になります。まずは、1つのツールで1つの操作に絞ります。
- 空き状況を調べる、と、予約を確定する、は別のツールにする
- 調べるだけのツールと、実際に何かが変わるツールを、混ぜない
- 人が画面で1回の操作と感じる単位を、目安にする
粒度の決め方は、後の節でもう一度触れます。
原則2：名前は「動詞＋対象」にする
名前は、見ただけで何をするか分かる形にします。たとえば「宿の空きを検索する」なら、searchAvailableRooms のように、動詞と対象を並べます。名前の長さは、草案では128文字以内という上限ですが、Chromeの安全性の資料は、名前30文字、説明500文字などの短い目安を示しています。短く保つのが安全です。
- 動詞を先頭に置く（search、get、create、cancel など）
- 対象を具体的にする（「data」「item」のような曖昧な語を避ける）
- サイト内で、似た名前を作らない
- 社内の略語や、画面の部品名をそのまま使わない
名前の付け方には、サイトの癖が出ます。複数のツールを並べたとき、同じ決まりで揃っているかを見直すとよいでしょう。
原則3：説明に「何をする・いつ使う」を肯定的に書く
説明は、AIがツールを選ぶ最大の手がかりです。次の3点を、短く入れます。
- 何をするか：結果として何が返るのか
- 似た操作との違い：Chromeの資料は否定形の指示を避けるよう勧めているため、肯定的な言い方で示す。例として「候補を探す段階で使う」
- いつ使うか：使うのに適した場面と、先に必要な手順
説明は、人に引き継ぐ業務メモのつもりで書くと失敗しにくくなります。似た操作との違いを書くと、別のツールとの取り違えを減らせる場合があります。ただし、説明の文章そのものにも、悪意ある指示が紛れ込むリスクが草案で挙げられています（プロンプトインジェクション）。説明に、外部から取り込んだ文章をそのまま入れないようにしてください。
原則4：入力は少なく、具体的にする
入力の項目が多いほど、AIは迷い、間違った値を入れやすくなります。Chromeの資料でも、JSON Schemaで入力と期待する出力を定義することで、AIの思い違い（幻覚）を減らせると説明されています。
- 本当に必要な項目だけを残す
- 自由な文章より、選択肢（決まった値の一覧）を使えるところは使う
- 日付や数量は、形式と範囲をスキーマで示す
- 各項目にも短い説明を付ける
項目を増やすことには、プライバシーの面の注意もあります。草案は、過剰なパラメータが「パーソナライズからフィンガープリント（端末や人の特定）へ」と進みうると指摘しています。入力は、目的に必要な分だけに絞るのが安全です。スキーマの細かい決め方は入力スキーマの設計で扱います。
一方で、スキーマを厳しくしすぎると、AIが先へ進めなくなることもあります。スキーマの検証だけに頼らず、execute の側でも入力を確かめ、次に何をすればよいかが分かるエラーを返す形が勧められています。エラーの書き方はエラー設計の記事にまとめます。
原則5：読み取り専用か、影響が大きいかを注釈で示す
ツールには、性質を伝える注釈を付けられます。草案にあるのは、主に次の3つです（Chromeの資料には、デバッグ用のdebugging注釈もあります）。いずれも初期値はfalse（付いていない状態）です。
| 注釈 | 意味 | 付ける例（架空） |
|---|---|---|
| readOnlyHint | 読み取りだけで、何も変えない | 空室の検索、料金の確認 |
| untrustedContentHint | 返す内容が信頼できない可能性がある | 利用者の口コミの取得 |
| consequentialHint | 実世界への影響があり、取り消しにくい | 予約の確定、支払い |
注釈は、AIを使う側のブラウザやアプリが、確認画面を出したり、内容を無害化したりする手がかりになります。ただし、草案の本文は、実行前のユーザー確認を必須とは定めていません。確認を出すかどうかは、使う側の実装しだいです。だからこそ、サイトの側でも、重要な操作を最初から一歩手前で止める設計が安全です。確認の考え方は人が確認する設計の記事で詳しく扱います。
悪い例と良い例（架空の例）
ここでは、架空の宿泊予約サイトを例に、ツールの書き方を比べます。実在のサイトや仕様に基づくものではありません。
| 項目 | 悪い例（架空） | 良い例（架空） |
|---|---|---|
| 名前 | doBooking | searchAvailableRooms |
| 説明 | 予約に関する処理を行います。 | 日付と人数から、空いている部屋の一覧を返します。予約の確定はしません。候補を探す段階で使います。 |
| 入力 | query（自由な文章）が1つだけ | checkIn、checkOut（日付）、guests（1以上の整数） |
| 注釈 | なし | readOnlyHint を付ける |
| 確定の操作 | 検索と予約が同じツールの中にある | 別ツールに分け、consequentialHint を付ける |
悪い例では、AIは「何が起きるか」を推測するしかありません。良い例では、調べるだけの安全なツールと、確定する重いツールが分かれています。AIも、使う人も、どこで慎重になるべきかが見えます。
宣言と実際の動作を一致させる
草案は、リスクの一つとして「意図の偽装」を挙げています。ツールの宣言（名前や説明）と、実際の動作が一致する保証がない、という問題です。草案の例では、finalizeCart という名前のツールが、実際には購入まで行ってしまうことが挙げられています。現状では、宣言を検証する手段もありません。サイトの善意が前提になっています。
事業者としては、次のことを守るのが基本です。
- 名前と説明に書いていない副作用を、実行処理に入れない
- 読み取り専用と宣言したツールは、本当に何も変えない
- 取り消しにくい操作には、その旨を説明と注釈の両方で示す
- 説明を変えたら、動作との差がないかを見直す
AIが使うツールの信頼は、宣言と動作の一致で成り立ちます。ここがずれると、利用者の損害にも、サイトの信用の低下にもつながります。
ツールの粒度の決め方
細かく分けすぎても、まとめすぎても、使いにくくなります。判断の目安を挙げます。
- 結果が変わるか：変わるものと変わらないものは分ける
- 取り消せるか：取り消せない操作は、単独のツールにする
- 入力が共通か：入力がほぼ同じなら、まとめる余地がある
- 説明が一文で言えるか：二文以上必要なら、分けることを考える
また、ツールの数が増えると、AIが読む情報量も増えます。草案も、ツール数はモデルが扱える文脈の量に制約されるとしています。ページの状況に応じて、いま使えるツールだけを登録する方法が勧められています。数の考え方はツールの数の決め方で整理します。
もう一つ注意点があります。草案には、登録済みのツールの内容を更新する仕組み（updateTool）がありません。名前・説明・スキーマを変えるときは、いったん登録を解除して、登録し直します。
Chromeの資料が勧める設計の姿勢
Chromeの公式資料には、設計の勧めとして次の考え方が示されています。
- 各要素の目的を明示する
- JSON Schemaで入力と期待する出力を定め、幻覚を減らす
- ページの状態をエージェントに共有する
- ブランドや、人を中心にしたデザインを保つ
- プログレッシブエンハンスメントとして扱う（あれば使われ、なくても画面は動く）
最後の点は、事業者にとって安心材料です。ツールは、人向けの画面を置き換えるものではなく、画面の上に重ねるものです。AIに使われなくても、サイトの価値は変わりません。サイト全体の準備項目は、AIエージェント対応サイトのチェックリストも参考にしてください。
設計を進める手順
いきなりコードを書かず、紙の上で次の順に進めると、手戻りが減ります。
- 利用者の目的を挙げる：人が画面で達成したいことを、一文ずつ書き出します。
- 操作に分解する：目的ごとに、調べる操作と、結果が変わる操作を分けます。
- 名前と説明を書く：実装より先に、AIに読ませる文章を仕上げます。
- 入力を絞る：説明を読んだAIが、迷わず値を決められるかを確かめます。
- 注釈と確認の位置を決める：どこで人が判断するのかを決めます。
- 試す：ChromeのDevToolsで、登録したツールの確認とスキーマの検証ができます。
ツールの文章をAIに下書きさせるのは有効ですが、宣言と動作が一致しているかは、人が確認してください。
誰にツールを見せるか
ツールは、登録した文書と同じオリジンの文書、およびブラウザに内蔵されたエージェントから見えるのが初期の状態です。他のオリジンに見せたいときは、登録時のexposedToで明示します。iframeの中の他オリジンに使わせるには、Permissions Policyのtools機能を許可するallow属性が必要で、ページ全体で無効にすることもできます。ツールの中身を考えるときは、誰がそれを呼べるのかも、あわせて決めておきます。
公開前のレビュー項目
ツールを公開する前に、次の項目を、作った人とは別の人が確認することをおすすめします。
- 名前は「動詞＋対象」で、他のツールと紛らわしくないか
- 説明に、何をする・何をしない・いつ使うが入っているか
- 1つのツールが、1つの操作に絞られているか
- 入力は必要最小限で、形式と範囲が示されているか
- 読み取り専用のツールに readOnlyHint が付いているか
- 取り消しにくい操作に consequentialHint が付いているか
- 外部の文章を返すツールに untrustedContentHint が付いているか
- 宣言と実際の動作が一致しているか
- 入力が誤りのとき、次の手が分かるエラーを返すか
- 登録するツールの数が、ページの目的に対して多すぎないか
注意したい点
- WebMCPはW3Cの標準ではなく、コミュニティグループの草案です。ChromeではChrome 149からオリジントライアルとして提供されていますが、Chromeの資料も、議論の最中で変更される可能性があると述べています。
- Edgeなど他のブラウザの対応時期は、公式な確認が取れていません。
- HTMLのフォームを使う宣言的APIは、Chromeの資料では紹介されていますが、W3Cの草案の本文にはまだありません。
- 登録窓口は、初期の資料のnavigator.modelContextから、document.modelContextへ移り、前者は廃止の方向とされています。古い解説をそのまま写さないでください。
- どのツールをAIに開くかは、セキュリティや個人情報にかかわる判断です。実装の前に、専門家の確認を受けることをおすすめします。
Otsumuに相談できること
ツールの名前や説明を見直す作業は、社内のエンジニアと企画の担当者だけでも始められます。まずは、サイトの機能を棚卸しして、読み取りだけの操作から1つ選び、この記事のレビュー項目で確認するところから試せます。
どの機能をAIに開くか、取り消せない操作をどう守るか、といった判断で迷うときは、外部の目が役に立ちます。Otsumuは、AIファーストの事業の再構築（事業の組み直し）を支援しています。ツール設計のレビューや、実際の開発まで、必要な範囲でご相談ください。
開発についてはAIエージェント開発をご覧ください。ご相談はお問い合わせから受け付けています。
この記事について
この記事はOtsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元：WebMCP仕様草案（W3C Web Machine Learning Community Group）、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20