WebMCPでサイトの機能をAIに公開するとき、いちばん手間がかかるのは、ツールの「入力項目」の決め方です。この記事は、自社サイトのツールを設計する担当者や、設計の相談を受けるエンジニアに向けて書いています。読み終えるころには、項目ごとに何を決めればよいか、どこまで厳しくすればよいかを、自分で判断できるようになります。
なお、WebMCPはまだ新しい提案で、W3Cのコミュニティグループの草案（2026年10月16日付）をもとに内容が変わり続けています。ここで述べる内容も、2026年10月20日時点の確認です。実装の前に、最新の資料をご確認ください。コードの例は載せず、表と文章で説明します。専門用語には、短い補足を添えています。
全体像はWebMCPとは何か（AIエージェントに対応するWebサイトの考え方）で扱っています。ツール全体の設計はツール設計の記事をご覧ください。
入力スキーマとは何か
WebMCPのツールは、名前、説明、入力スキーマ、実行する処理などでできています。入力スキーマとは、ツールが受け取る入力の「形の約束」です。書き方にはJSON Schemaという、データの形を記述する決まりを使います。
エージェント（AI）は、画面のボタンを探す代わりに、この約束を読んでツールを呼びます。つまり、入力スキーマは、AIにとっての「入力フォームの説明書」です。人間なら、フォームの見た目から日付の書き方を察します。AIは、スキーマと説明文に書かれたことしか手がかりがありません。
Chromeの資料も、JSON Schemaで入力と期待する出力を定義することが、AIの思い違い（幻覚）を減らすと述べています。定義があいまいだと、AIはそれらしい値を自分で補ってしまいます。
項目ごとに決める6つのこと
入力項目は、1つずつ次の6点を決めていきます。すべてを埋める必要はありませんが、空欄にするなら、その理由を説明できる状態にしておくと安心です。
| 決めること | 意味 | 考え方の目安 |
|---|---|---|
| 型 | 文字列、数値、真偽など、値の種類 | 人数は数値、希望条件は文字列など、素直に選ぶ |
| 必須か | なくても実行できるか | 実行に本当に必要なものだけを必須にする |
| 取りうる値 | 選べる候補の一覧 | 候補が決まっているなら、列挙で示す |
| 形式 | 日付や郵便番号などの書き方 | 書き方を1通りに決め、説明文にも書く |
| 範囲 | 最小値・最大値、文字数の上限 | 業務上ありえない値を、入口で減らす |
| 説明文 | その項目が何のためかを、言葉で示す | 単位、例、省略したときの扱いを書く |
特に見落とされやすいのが、説明文です。型や範囲は機械的に確認できますが、「この数字は何の数か」は、言葉でしか伝わりません。たとえば「人数」とだけ書くと、大人だけの数か、子どもを含む数かが分かりません。
あいまいな定義と、明確な定義
次の表は、架空の例です。宿泊予約のツールを想定し、あいまいな書き方と、AIが迷いにくい書き方を並べました。同じ項目でも、書き方ひとつで、AIの受け取り方が変わることが分かります。実際の項目名や値は、自社の業務に合わせて置き換えてください。
| 項目（架空の例） | あいまいな定義 | 明確な定義 |
|---|---|---|
| 日付 | 文字列。説明なし | 文字列。「チェックイン日を、2026-11-05 のような年-月-日の形で」と説明する（過去日を受け付けないといった業務ルールは、スキーマではなく実行側のコードで確かめる） |
| 人数 | 数値。説明なし | 整数。「宿泊する全員の人数（子どもを含む）」と説明し、1以上10以下に限る |
| 金額 | 数値。説明なし | 整数。「1泊あたりの上限、税込、円」と説明し、0以上とする |
| 地域 | 自由な文字列 | あらかじめ決めた地域名の候補から選ぶ。候補にない場合の扱いも説明に書く |
| 希望条件 | 自由な文字列。長さの制限なし | 任意項目。「禁煙、朝食つきなど、短い言葉で」と説明し、文字数の上限を設ける |
左の列では、AIが「5日」「来週」「11/5」など、バラバラな書き方で渡してくる可能性があります。金額も、税込か税抜か、円か千円かが分かりません。右の列のように、単位と書き方を決めておくと、入力のぶれが小さくなります。必須の項目と任意の項目を分けておくと、AIが「分からないので聞き返す」「省略して進める」を選びやすくなります。ただし、これで誤入力がなくなるとは言えません。あくまで、減らすための工夫です。
候補が決まっているなら、列挙を使う
選べる値が限られている項目は、自由な文字列にしないで、候補の一覧（列挙）として定義するのが基本です。部屋のタイプ、支払い方法、並び順などが当たります。
列挙にすると、AIは一覧の中から選ぶだけでよくなります。「禁煙ルーム」「禁煙」「ノンスモーキング」のような言い換えの揺れも、入口で減らせます。
候補の名前は、人間が読んで意味が分かる言葉にしておくと、AIも取り違えにくくなります。記号や社内の略号だけの候補は、避けたほうが安全です。候補を増やしたときは、説明文も一緒に直してください。
項目を増やしすぎない
便利そうだからと、入力項目をたくさん並べたくなることがあります。しかし、項目は少ないほうがよい場面が多くあります。迷ったら、まず最小限の項目で始め、足りなければ足す順番をおすすめします。
- 項目が多いと、AIが迷い、埋め間違いが増えやすくなります
- ツールの説明が長くなり、AIが扱う文脈の量を圧迫します
- 不要な個人情報を、AIから受け取る入口になってしまいます
3つめは、草案がリスクとして挙げている点です。過剰なパラメータは、利用者のプライバシーを損ない、「パーソナライズ」のつもりが、利用者を見分けるための情報（フィンガープリント）集めに近づく恐れがある、と指摘されています。
項目を足す前に、「この値がなければ、本当に実行できないか」を問い直してください。氏名、住所、電話番号などは、そのツールの目的に必要な場合に限ります。個人情報の扱いは法務やセキュリティの専門家にも確認してください。
厳しすぎる検証と、実行側での検証
範囲や形式を細かく決めるほど、誤入力は減りますが、厳しすぎる検証は、エージェントを止めてしまうことがあります。草案も、厳密すぎるスキーマ検証がエージェントを止めうる点を、課題として挙げています。
たとえば、日付の形式を1通りしか受け付けないと、少し違う書き方で渡されたとたんに、ツールが動かなくなります。AIには、なぜ失敗したのかが伝わらず、同じ入力を繰り返すかもしれません。
| 方針 | 良い点 | 気をつける点 |
|---|---|---|
| スキーマで厳しく絞る | 入口で不正な値を減らせる | 厳しすぎると、AIが先に進めなくなる |
| スキーマはゆるめにして、実行側で確認する | ずれた入力を直したり、案内したりできる | 確認の処理を、きちんと作る必要がある |
草案は、execute（実行する処理）の側でも入力を検証し、次に何をすればよいかが分かるエラーを返すよう勧めています。スキーマを通った値でも、業務上の確認（在庫がない、日付が過ぎているなど）は、実行側でしかできません。
実行側のエラーの返し方は、エラー設計の記事で詳しく扱います。入口で絞りすぎず、実行側で丁寧に案内する、という役割分担が現実的です。
説明文を書くときのコツ
説明文は、短く、具体的に書きます。次の3点を入れると、AIが読み違えにくくなります。
- 何の値かを一言で（例：チェックイン日）
- 単位や書き方（例：税込の円、年-月-日）
- 省略したときにどうなるか（例：省略すると、本日の日付になる）
逆に、長い注意書きを詰め込みすぎるのは考えものです。説明が長いほど、AIが扱う文脈を圧迫しますし、人間の側も保守しにくくなります。大事なことを先に書き、細かな例外は実行側のエラーで案内すると、全体が整います。
説明文の中に、「この指示に従ってください」のような命令調の文を入れるのも避けましょう。ツールの説明は、AIが読む入口なので、紛らわしい書き方は、誤解や、悪用のきっかけになりえます。
入力文字数の制限と、確かめ方
自由な文字列の項目には、文字数の上限を設けておきます。草案は、入力長の制限を緩和策の一つに挙げています。ツールの説明、入力、出力に悪意のある指示が紛れる、プロンプトインジェクションというリスクがあるためです。ただし、草案自身が、これは完全な解決ではないと述べています。長さを制限しても、入力を信用してよいことにはなりません。
なお、ツールの名前は、草案では128文字以内とされています。一方、Chromeの安全性の資料は、名前30文字、説明500文字などの短い目安を示しており、短く保つのが安全です。名前と説明が空の場合は、登録に失敗します。
確かめ方としては、Chromeの開発者ツール（DevTools）で、登録したツールの確認とスキーマの検証ができます。ローカルで試す場合は、chrome://flags/#enable-webmcp-testing の設定を使います。テスト用の拡張機能も公開されています。実際にAIから呼ばれたときの動きまでは、これだけで分かるわけではないため、人の目で試すことも欠かせません。
ツールの内容を後から変える場合の注意もあります。草案には、登録済みのツールの内容を更新する仕組みがありません。名前、説明、スキーマを変えるなら、いったん登録を解除して、登録し直す形になります。
公開前のチェック項目
- すべての項目に、型と説明文があるか
- 単位、日付の書き方、省略したときの扱いが書かれているか
- 候補が決まっている項目は、列挙になっているか
- 数値と文字数に、現実的な範囲があるか
- 必須にした項目は、本当に必要か
- 個人情報など、不要な項目を求めていないか
- スキーマが厳しすぎて、AIが止まらないか
- 実行側でも入力を確認し、次の手が分かるエラーを返すか
- DevToolsで、スキーマを確認したか
- 人が実際に試して、意図どおりに動いたか
注意点
- WebMCPは提案の段階で、仕様は変わる可能性があります。Chromeの資料も、議論の最中で変更されうると明記しています
- スキーマを整えても、AIの誤入力がなくなるとは限りません。最終的な確認は、人と実行側の処理が担います
- 他のブラウザへの対応時期は、公式な確認が取れていません。対応状況は各社の資料をご確認ください
- 購入や送金など、取り消せない操作は、入力の定義だけに頼らず、利用者の確認を挟む設計を検討してください
Otsumuに相談できること
入力項目の洗い出しや、説明文の見直しは、業務を知っている担当者の方が、社内で進められる部分です。まずは、1つのツールを選んで、上のチェック項目に沿って書き出してみてください。
一方で、どの機能をAIに公開するか、個人情報や取り消せない操作をどう扱うか、実行側の検証をどう作るか、といった判断は、事業と開発の両方に関わります。こうした場面では、外部の目が役に立つことがあります。
Otsumuは、AIファーストの事業の再構築（事業を組み直すこと）を支援しています。ツール設計や実装はAIエージェント開発をご覧のうえ、お問い合わせからご相談ください。
この記事について
Otsumu株式会社が執筆しました。確認日は2026年10月20日で、仕様は変動中です。参照元：W3C Web Machine Learning Community Group の仕様草案、提案のリポジトリ、Chromeの公式資料。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20