この記事は、予約・宿泊・飲食のサイトを運営する事業責任者や担当者に向けて書いています。WebMCP（Webサイトが自分の機能を「ツール」としてブラウザ上のAIエージェントに公開する提案仕様）を自社に当てはめるとき、AIに開く操作と、人が持つべき判断をどう分けるか。読み終えると、その整理の軸と、最初の一歩が分かります。
先にお断りします。WebMCPはW3Cの標準ではなく、W3C Web Machine Learning Community Group（コミュニティグループ）の仕様草案です。Chromeではオリジントライアル（期間限定の試験提供）として使える段階で、内容は今後変わりえます。この記事は2026年10月20日時点の確認に基づきます。また、文中の予約サイトの例はすべて架空の例です。
WebMCPの全体像はWebMCPの入門記事で扱っています。先にそちらを読むと、この記事の用語がつかみやすくなります。
予約サイトでWebMCPを考える前提
予約・宿泊・飲食のサイトは、WebMCPと相性がよい業種の一つとして語られます。理由は単純で、利用者の操作が「日付と人数を決め、候補を絞り、予約する」という手順で整理しやすいからです。Chromeの公式資料も、使いどころの例に「絞り込みと予約」を挙げ、ホテルの検索と絞り込みを例にしています。資料に出てくるツール名は、search_hotels と filter_search_results です。
ただし、前提を二つ押さえておく必要があります。
- 人が関わる使い方が主です。仕様の位置づけでは、人が使う画面が主役のままで、WebMCPはそれを補うものです。Chromeの資料も、ローカルのブラウザで人が関わる（human in the loop）使い方を主に想定すると述べています。
- 画面は見える状態のままです。ツールはページ上で動くので、エージェントが操作した結果は、利用者の画面にも反映されます。
つまり、「AIが勝手に予約まで済ませる仕組み」を作るものではありません。利用者がAIに頼んで下調べや入力を進め、最後は人が確かめる。そういう分担を、サイト側が設計しておくための道具です。
AIに開く操作の候補
まず、予約サイトでできる操作を書き出し、AIに開いてよいものかを仕分けます。下の表は考え方の一例で、仕様に書かれた手順ではありません。内容はすべて架空の例です。
| 操作（架空の例） | 性質 | AIに開く考え方 |
|---|---|---|
| 空き状況の照会 | 読み取りのみ | 最初の候補。状態を変えないので始めやすい |
| 条件での絞り込み（立地・設備・時間帯など） | 読み取りのみ | 最初の候補。結果は画面にも反映させる |
| 予約の仮押さえ | 状態が変わる | 保持時間や解除の扱いを決めてから。慎重に検討する |
| 予約内容の変更 | 状態が変わる | 影響を確かめたうえで、人の確認を挟む前提で設計する |
| 予約の取消 | 取り消しにくい場合がある | キャンセル規定との関係が深い。人の判断を残す |
| 予約の確定 | 実世界への影響が大きい | 人が最終確認する設計を前提にする |
上から下へ、リスクが高くなっていきます。最初に公開するのは、上の二つ、つまり読み取りだけの操作が無理のない選択です。仕様の草案には、読み取りのみを示す readOnlyHint という注釈があります。一方、予約や送金のように、実世界への影響が大きく取り消せない操作には、consequentialHint という注釈があります。クライアント（エージェントを動かす側）は、これを手がかりに、利用者へ確認を求められます。
どのツールを何個出すかは、別の論点です。数を絞るときは、自社の操作を書き出して、頻度・価値・リスクで見る方法が使いやすいでしょう。ツールの作り方はWebMCPのツール設計の記事で詳しく扱っています。
Chrome資料の例：ホテルの検索と絞り込み
Chromeの公式資料（use-cases のページ）は、賃貸やホテルの「絞り込みと予約」を使いどころの例に挙げています。ホテルでは、search_hotels と filter_search_results というツールが紹介されています。出典は、ChromeのWebMCP公式資料です。
この例から読み取れる設計のポイントは、次のとおりです。
- 「探す」と「絞る」を、別のツールに分けている。一つのツールに何でも詰め込まない。
- 既存のフォームがあれば、それをツールにできる。Chrome資料は、2ステップでツールにできると説明しています。
- 情報が足りないときは、エージェントが利用者に尋ねる。利用者がフォームを手で埋めて送信することもできる。
なお、この資料には「使わない方がよい場面」についての記述はありません。予約のどこまでをAIに任せるかは、資料が決めてくれるものではなく、自社で判断することになります。
また、ツールの作り方を示す別のページ（build-tools）には、航空券の例が出てきます。get_user_profile、search_flights、filter_flights、lookup_flight、book_flight という流れで、各ステップごとに画面を更新する、という考え方です。宿泊や飲食でも、「照会、絞り込み、詳細確認、予約」の順に、画面と一緒に進める発想が参考になります。
入力の設計：日付・人数・形式
予約サイトの入力は、日付、人数、時間帯、部屋やコースの種類などです。エージェントが正しく入力できるように、ツールの入力スキーマ（入力項目の定義）を設計します。Chrome資料のベストプラクティスから、予約に当てはまる点を挙げます。
- 日付の形式を明示する。「YYYY-MM-DD」のように、期待する形式を説明に書く。資料も、日付の形式が違う場合は、正しい形式を伝えるエラーを返す例を示しています。
- 型を具体的にする。人数は数値（number）、部屋タイプや席種のような選択肢は enum（列挙）にする。
- 自然言語の値を使う。資料は、数字のIDより、人が読める値を勧めています。たとえば、料理のコースを番号ではなく名前で受け取る、といった形です。
- 計算や変換をモデルにさせない。宿泊数の計算などは、生の入力（チェックインとチェックアウトの日付）を受け取って、サイト側で行う。
- 検証はコードで厳しく、スキーマでは緩く。Chrome資料の言葉です。スキーマを厳しくしすぎるとエージェントが止まることがあるため、細かな検証は execute（実行する処理）の中で行い、次の一手が分かるエラーを返す。
曖昧な依頼への備えも大切です。たとえば利用者が「来週末に二人で」と頼んだとき、日付も場所も確定していません。Chrome資料は、推測せず、足りない引数を尋ねられる柔軟さを持たせるよう勧めています。必須の項目と任意の項目を分けておくと、エージェントは何を尋ねればよいか判断できます。
入力のデータ量にも気をつけてください。仕様の草案は、過剰なパラメータによるプライバシー漏えいを、リスクとして挙げています。予約に本当に必要な項目だけを受け取る設計が基本です。どの個人情報を受け取るかは、法務や情報セキュリティの専門家に確認してください。
人が持つべき判断
予約・宿泊・飲食では、人が最後に確かめるべき判断がいくつもあります。ここでは、次の三つを軸に考えます。
予約の確定
予約の確定は、利用者にも事業者にも影響が大きい操作です。Chromeの資料は、購入などの重要な操作で、ユーザーに確認ダイアログを出す指示をツールに含められると述べています。ただし、W3Cの草案の本文は、ツール実行時のユーザー確認を必須とは定めていません。クライアントが、重要な操作の前に確認を出せる、という位置づけです。したがって、確認の仕組みは、自社の画面側でも用意するのが安全です。
具体的には、ツールが予約を「確定」するのではなく、予約内容を画面に表示し、利用者が確認ボタンを押して確定する形が考えられます。Chrome資料の宣言的API（HTMLのフォームに属性を付けてツールにする方式）では、既定で利用者が送信ボタンを押して完了します。なお、この宣言的APIは、Chromeの資料では紹介されていますが、W3Cの草案の本文にはまだ含まれていません。
キャンセル規定の確認
キャンセル料や変更の条件は、契約や消費者保護に関わる内容です。エージェントが規定を要約して伝えると、誤りが生じるかもしれません。規定の表示は、サイト上の正式な文面を利用者に見せる形にし、同意は人が行うようにしておくのが無難です。
なお、業種ごとの法令（旅館業、飲食、消費者保護など）の要件がどうなるかは、この記事では踏み込みません。自社の業態に関わる法令や表示のルールは、専門家に確認してください。
例外への対応
満席、特別な要望、アレルギーへの配慮、団体での利用など、例外的な相談は、人が受けたほうがよい場面が多くあります。エージェントが対応できない依頼は、問い合わせの導線へ案内する。そうした逃げ道を、ツールの返答に含めておきます。
確認の設計は人の確認（human in the loop）の記事で詳しく扱っています。
よくある失敗
予約で起こりやすい失敗を、架空の例で整理します。仕様に書かれた失敗例ではなく、設計時に想定しておくための点検項目です。
| 失敗（架空の例） | 起こること | 備え |
|---|---|---|
| 二重予約 | エージェントが同じ依頼を繰り返し呼び、同じ枠に予約が重なる | サーバー側で枠の重複を判定する。ツールに頼らず、既存の予約処理の検証をそのまま使う |
| 仮押さえの放置 | 仮押さえしたまま、枠が長く塞がる | 保持時間とその後の扱いを決める。解除の手段も用意する |
| タイムアウト | 処理に時間がかかり、結果が返る前に中断される | execute が受け取る signal（中断用）を処理に渡す。結果が不明なときは、再確認の方法を返す |
| 日付や人数の誤入力 | 過去の日付や、上限を超える人数で呼ばれる | コード側で検証し、直し方が分かるエラーを返す |
| 名前と動作の食い違い | 「確認」のつもりのツールが、実際は確定まで行う | 名前と動作を一致させる。確定は別のツールに分ける |
| 汎用的なエラー | 「失敗しました」だけで、エージェントが次の手を打てない | 状態が違うのか、形式が違うのか、結果がないのかを区別して伝える |
Chrome資料は、失敗しても立て直せる返答を勧めています。例として、「状態が違うので先に検索してください」「日付の形式はYYYY-MM-DDで」「結果なし、条件を変えてください」といった伝え方が挙げられています。汎用エラー、生のAPIエラー、無言の失敗は避けるよう書かれています。
名前と動作の食い違いは、仕様の草案もリスクとして挙げています。宣言と実際の動作が一致する保証がない、という点です。草案の例では、finalizeCart という名前のツールが、実際には購入まで行ってしまうことが挙げられています。予約でいえば、「仮押さえ」のつもりのツールが確定まで進んでしまう、といったことです。
安全面で気をつけること
予約サイトは、個人情報（氏名、連絡先、同行者の情報など）を扱います。WebMCPの安全面について、仕様の草案とChrome資料が述べていることを整理します。
- 見える範囲。ツールは既定で、登録したページと同じオリジンの文書や、ブラウザ内蔵のエージェントから見えます。他のオリジンに見せるには、exposedTo で明示します。
- プロンプトインジェクション。ツールの説明や入力、出力に紛れた悪意ある指示により、エージェントが意図しない動きをするおそれがあります。口コミや問い合わせ内容のような利用者生成の内容を返すツールには、untrustedContentHint という注釈を付けられます。
- ログイン状態。W3Cの草案は、認証の扱いを定めていません。一方、Chromeの資料（MCPとの比較のページ）は、WebMCPが、ライブのタブにあるログイン中のセッション情報やCookie、DOM要素にアクセスすると述べています。マイページの予約情報をどう扱うかは、慎重な設計が必要です。
Chromeの安全性の資料は、「LLMの内側で安全を保証することは不可能」と述べ、指針は暫定的だとしています。個人情報や決済に関わる設計は、専門家のレビューを受けてください。
最初の一歩
予約サイトで始めるなら、次の順が無理のない進め方です。
- 操作を書き出す。自社サイトの予約に関わる操作を、一覧にする。
- 読み取りだけを選ぶ。空き状況の照会と絞り込みから始める。状態を変える操作は後回しにする。
- 既存の入力画面を見直す。日付や人数の入力に、ラベルや説明が十分にあるかを点検する。
- 試して確かめる。Chromeの開発者ツール（DevTools）のApplicationタブにWebMCPの項目があり、登録されたツールや呼び出しの履歴を確認できます。手動でツールを実行して動きを見ることもできます。
- 人の確認を設計する。予約の確定やキャンセルを扱う段階になったら、確認の画面を先に決める。
WebMCPは、あれば使われ、なくても動く、プログレッシブエンハンスメント（段階的な機能追加）として扱うのが、Chrome資料の勧めです。人が使う画面の品質を保つことが、前提になります。点検の観点は、AIエージェント対応サイトのチェックリストも参考にしてください。
注意点
- 仕様は変わります。W3Cのコミュニティグループの草案は、W3Cの標準ではありません。Chromeの資料も、議論の最中で変更される可能性があると明記しています。
- 対応状況は限られます。Chromeではオリジントライアルとして提供されています。Edgeなど他のブラウザの対応時期は、確認できていません。
- この記事の例は架空です。表や流れは考え方の例で、実在のサイトや実績とは関係ありません。効果を示すものでもありません。
- 法令や契約は専門家に確認を。キャンセル規定、個人情報の取り扱い、業法に基づく表示などは、断定せず、専門家に確認してください。
- 重要な操作は人が確認します。予約の確定や取消を、エージェント任せにしない設計を前提にしてください。
Otsumuに相談できること
操作の棚卸しと、AIに開く範囲の仕分けは、社内で始められます。まずは、予約に関わる操作を書き出し、読み取りだけのものから試してみてください。
一方で、既存の予約システムとの接続、二重予約の防止、確認画面の設計は、実装との兼ね合いで難しくなりがちです。Otsumuは、AIファーストの事業再構築（事業の組み直し）を支援しており、その一環として、サイトを「AIが使える形」にする設計もご一緒できます。
詳しくはAIエージェント開発をご覧ください。具体的なご相談は、お問い合わせからどうぞ。
この記事について
この記事は、Otsumu株式会社が執筆しました。確認日は2026年10月20日で、WebMCPの仕様は変動中です。参照元は、W3C Web Machine Learning Community Group の仕様草案、WebMCPの提案リポジトリ、ChromeのWebMCP公式資料です。
執筆：Otsumu株式会社 ／ 編集日 2026.10.20