この記事は、問い合わせ、予約、見積、申込みなどのHTMLフォームをすでに持っている事業責任者や担当者に向けて書いています。読み終えると、フォームを「AIエージェントが使えるツール」として公開する宣言的APIの仕組みと、現時点での位置づけ、そして手元のフォームで先に整えておける点が分かります。
WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）は、草案の段階にあります。内容は変わり続けており、この記事は2026年10月20日時点の確認に基づきます。
WebMCP全体の入口はWebMCPの入門記事にまとめています。ツール全般の考え方はツール設計の記事が参考になります。
宣言的APIとは何か
WebMCPには、ツールを公開する方法が2つ紹介されています。1つは、JavaScriptでツールを登録する命令型API。もう1つが、HTMLのフォームに属性を足してツールにする宣言的APIです。「宣言的」とは、処理を書くのではなく、HTMLに印を付けて示す、という意味です。
Chromeの公式資料では、既存のフォームがあれば2ステップでツールにできる、と説明されています。具体的には、form要素にtoolnameとtooldescriptionという2つの属性を付けます。ツールの名前と、何をするかの説明です。これでブラウザがフォームをツールとして登録します。どちらかの属性を外すと、登録は解除されます。
エージェントがこのツールを呼ぶと、ブラウザがフォームにフォーカスを当て、項目を入力します。このとき、フォームは利用者の画面に見えたままです。裏で見えない処理が走るのではなく、人が見ている画面の上で入力が進みます。
フォームがツールの定義になる仕組み
命令型では、入力スキーマ（入力項目の定義）をJSON Schemaで自分で書きます。宣言的では、フォームの作りからブラウザがスキーマを導き出します。Chromeの資料に基づく対応関係は次のとおりです。
| フォーム側の要素 | ツール側での扱い |
|---|---|
| toolname / tooldescription | ツールの名前と説明 |
| name属性のある入力項目 | 入力スキーマのプロパティ |
| テキスト入力 | string（文字列） |
| select要素の選択肢 | string。選択肢は候補の一覧（enum、anyOf）になる |
| required属性 | 必須項目（required）に入る |
| toolparamdescription | 各項目の説明。なければlabelの文言、それもなければaria-description |
つまり、普段から丁寧に作られたフォームほど、そのまま質の良いツールになります。labelが分かりやすく、必須項目が正しく示され、選択肢が整理されていれば、追加の作業は多くありません。逆に、ラベルが「項目1」のようにあいまいなフォームは、エージェントにも伝わりません。
送信の扱い：既定は、利用者が押す
ここが宣言的APIで最も大事な点です。既定の動作では、エージェントが項目を埋めたあと、利用者が送信ボタンを押して完了します。エージェントが勝手に送信まで進むわけではありません。
Chromeの資料によれば、toolautosubmit属性を付けると、モデルの呼び出し時に自動で送信されます。この場合は画面遷移も起きます。問い合わせの下書きのように取り消せる操作と、申込みや決済のように取り消しにくい操作では、扱いを分けて考えるべきです。自動送信を付けるかどうかは、慎重に決めてください。
送信の処理側では、SubmitEventのagentInvokedという値で、エージェント経由かどうかを判別できます。trueならエージェントの起因です。さらに、respondWithという仕組みに値を渡すと、ツールの出力としてモデルに返せます。呼び出す前にpreventDefault（通常の送信動作の停止）を行う、という手順が資料に書かれています。「送信しました」「入力に誤りがあります」といった結果をエージェントに伝え、次の行動につなげるための部品です。
入力中の状態を扱うイベントと見た目
フォームには、エージェントの動きに対応するイベントが用意されています。
- toolactivated：エージェントが項目の入力を終えたときに発生します。
- toolcancel：利用者が取り消した場合や、フォームがリセットされた場合に発生します。
見た目の面では、エージェントが動作している間、form要素に:tool-form-activeという擬似クラスが、送信ボタンに:tool-submit-activeが当たります。Chromeの既定では破線の枠が表示されますが、CSSで上書きできます。利用者が「いまエージェントが入力している」と気づけるよう、自社のデザインに合わせて整えておくとよいでしょう。
なお、window.ontoolactivatedとwindow.ontoolcancelは、Chrome 156からサポートされないと資料にあります。イベントの受け取り方は、資料の最新版で確認してください。
現状の位置づけ：Chromeの資料にはあるが、W3C草案にはまだない
ここは正確に書く必要があります。宣言的APIは、Chromeの公式資料には載っています。一方で、W3C Web Machine Learning Community Group の仕様草案の本文（2026年10月時点）には、含まれていません。
整理すると次のとおりです。
| 項目 | 状況 |
|---|---|
| 仕様の位置づけ | WebMCPはW3Cの標準ではなく、W3Cコミュニティグループの草案。標準化トラックにも載っていない |
| 宣言的API | Chromeの資料では2つ目のAPIとして紹介。W3C草案の本文にはまだない |
| Chromeでの提供 | Chrome 149からオリジントライアル。資料は「議論の最中で、変更される可能性がある」と明記 |
| 他のブラウザ | Edgeなどの対応時期は、確認できていない |
オリジントライアルとは、Chromeが新機能を一部のサイトで試せる枠組みです。正式な機能としての提供ではありません。宣言的APIの属性名や挙動は、今後変わる可能性があります。本番の重要な機能は、これに依存させない設計が安全です。
Chromeの資料は、WebMCPを「あれば使われ、なくても動く」プログレッシブエンハンスメントとして扱うことを勧めています。この観点は宣言的APIと相性が良いといえます。属性を足しても、従来のフォームとしての動作は変わらないからです。ただし、実装前に最新の資料と、導入先環境での動作を確認してください。
既存フォームを整える：先にできる準備
仕様が変わる可能性があっても、フォームの品質を上げる作業は無駄になりにくいものです。人にも、エージェントにも、役に立つからです。
- labelを具体的にする：「お名前」「希望日」のように、何を入れる項目かが一目で分かる文言にします。labelは、toolparamdescriptionがないときの説明にもなります。
- requiredを正確に付ける：本当に必須の項目だけに付けます。付け忘れや付けすぎは、エージェントの動きに影響しうるので、実際の必須項目に合わせます。
- selectの選択肢を整理する：重複や紛らわしい表記をなくし、表示名が意味を持つようにします。選択肢はそのままスキーマの候補になります。
- 入力の型を合わせる：日付、数値、メールアドレスなど、項目の性質に合ったinputの種類を使います。
- 説明は短く：Chromeの安全性の資料は、エージェントに見せる量の目安として、ツール名とパラメータ名は30文字、ツールの説明は500文字、パラメータの説明は150文字を挙げています。草案の上限（名前は128文字以内）より実質的に短い目安なので、短く書くのが安全です。
- 説明は肯定的に：「何をするか」「いつ使うか」を書き、細かい制限は書きすぎないようにします。
これらは、WebMCPがなくても、フォームの使いやすさと入力ミスの減少に効きます。
架空の例：見積依頼フォーム
以下は架空の例です。実在のサイトとは関係ありません。
ある架空の会社が、「サービスの種類」「希望の時期」「予算感」「連絡先メールアドレス」を入力する見積依頼フォームを持っているとします。このフォームにtoolnameとtooldescription（「見積の依頼を送る。サービスの種類、時期、連絡先を受け取る」といった説明）を付けると、エージェントがツールとして使えるようになります。
エージェントが利用者の要望から項目を埋めると、フォームは画面に見えた状態で入力されます。連絡先のように分からない項目は、エージェントが利用者に尋ねるか、利用者が自分で手入力できます。内容を確認した利用者が送信ボタンを押す、という流れです。toolautosubmitは付けません。見積の依頼は、本人の確認を経てから送るのが自然だからです。
命令型との使い分け
どちらを選ぶかは、機能の性質で考えます。
| 観点 | 宣言的API | 命令型API |
|---|---|---|
| 向いているもの | 既存のフォームをそのまま使いたい場合 | フォームにない処理、検索、状態の確認など |
| 作り方 | HTMLに属性を足す | JavaScriptでregisterToolを呼ぶ |
| スキーマ | フォームから導かれる | JSON Schemaを自分で書く |
| 制御の細かさ | フォームの構造に依存 | 自由度が高い |
| 草案との関係 | W3C草案の本文にはまだない | 草案に含まれる |
注意したいのは、Chromeの資料が、静的な登録（ページの読み込み時に登録する方式）を多くのアプリの既定としている点です。宣言的APIを使う場合も、すべてのフォームを対象にする必要はありません。まずは問い合わせや予約など、利用者が目的を持って入力するフォームから選ぶのが現実的です。
また、ツールの数が増えるとエージェントの判断が難しくなります。フォームごとに安易に付けず、ツールが重ならないよう設計してください。入力スキーマの考え方は入力スキーマの記事、失敗したときの返し方はエラー設計の記事で扱います。
よくある失敗
- 説明が空か、あいまい：toolnameとtooldescriptionは、どちらか一方でも欠けると登録されません。説明があっても、何をするか分からなければ呼ばれません。
- labelが不十分：導かれるスキーマの質が、フォームの質にそのまま左右されます。
- 自動送信を安易に付ける：toolautosubmitは、取り消しにくい操作には慎重に使います。人が確認する流れについては、人の確認の記事も参考にしてください。
- 送信後の結果を返していない：respondWithで結果を伝えないと、エージェントが成否を判断しづらくなります。
- サーバー側の検証を省く：フォームに属性を付けても、サーバー側のチェックは別に必要です。Chromeの資料も、検証はコードで厳しく、スキーマでは緩く、と勧めています。
- 仕様の変更を想定していない：属性やイベントは変わりえます。変更に追随できる体制にしておきましょう。
注意点
- 仕様は変わります。宣言的APIはW3C草案の本文になく、Chromeのオリジントライアルの中で議論されています。
- 対応状況は限られます。Chrome以外のブラウザの対応時期は、確認できていません。最新の状況は現状とロードマップの記事で追っています。
- 人の画面が主役です。WebMCPは、人が関わる使い方を主に想定しています。完全自律の運用を前提にしたものではありません。
- 安全面は別に検討してください。ツールの説明や入力に紛れた悪意ある指示（プロンプトインジェクション）や、個人情報の扱いは、専門家の確認も受けながら進めてください。個人情報や業法に関わる入力項目がある場合は、法務の担当者への相談も欠かせません。
- 全体の点検も大切です。サイト全体の準備状況は、AIエージェント対応サイトのチェックリストで確認できます。
Otsumuに相談できること
フォームのlabelや必須項目の見直しは、社内でも始められます。まずは、自社のフォームを一覧にして、どれが利用者の目的に直結しているかを確認してみてください。
一方で、どのフォームをツールにするか、自動送信を付けてよいか、送信後の結果をどう返すか、といった設計は、実装や運用と絡んで判断が難しくなります。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、サイトをAIが使える形にする設計もご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。宣言的APIの詳細は、Chrome資料の宣言的APIのページに基づきます。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20