7月に行われたアムステルダムのレストラン200軒を対象としたテストでは、現在のAIアシスタントは、予約ウィジェットがiframe内に隠されているため、テーブル予約を完了できないことが明らかになりました。
なぜiframeがエージェントを妨げるのか
ほとんどのオンライン予約ツールは、埋め込み型のiframeとして提供されています。訪問者が「予約する」ボタンをクリックすると、カレンダーがポップアップ表示され、ユーザーが時間枠を選択します。人間にとってはスムーズなプロセスですが、AIエージェントにとっては、ここで処理が停滞してしまいます。
- エージェントはメインのHTMLページを解析します。
- 予約ボタンは、異なるドメインのURLを指しています。
- ブラウザはそのURLをiframe内で読み込み、親ページから分離させます。
同一オリジンポリシー（same-origin policy）により、親ページのスクリプトがiframeのDOMを読み取ったり、ネットワークコールを傍受したりすることがブロックされるため、ページ内容を読み取ってHTTPリクエストを送信するAIエージェントには、ボタンしか見えません。カレンダーや時間枠、あるいは確認フローにたどり着くことはできないのです。たとえボタンをクリックできたとしても、CAPTCHAの解決、レイアウト変更への適応、あるいは多くの予約サービスが採用しているアンチオートメーション（自動化防止）防御の回避といった課題が残ります。
不足しているマシンリーダブルなリンク
稼働中のレストランサイト163件を対象とした別の監査では、マシンリーダブル（機械判読可能）な予約データを公開していたのは、わずか9件でした。それら9件は、schema.orgのマークアップを使用して名前や住所などの基本情報を記載していましたが、エージェントが実行できる予約アクション（reservation actions）を含んでいるものは一つもありませんでした。Schema.orgにはこの目的のための ReserveAction といった型が定義されていますが、ほとんどのサイトは記述的なメタデータを公開しているだけで、実行可能な指示を公開していません。
実際には、アシスタントは単に「何をするか」だけでなく、「どのように」タスクを実行するかを伝える構造化データを探しています。ReserveAction やそれに相当するエンドポイントがなければ、エージェントは人間のクリックを模倣することに頼らざるを得ず、上述の通り、その手法は信頼性に欠けます。
UIを壊さない実用的な解決策
- 予約APIを公開する – 空き状況の照会や予約作成のためのJSONリクエストを受け付ける、軽量なHTTPエンドポイントを作成します。APIは日付、時間、人数、確認コードなどのフィールドを返します。これにより、ページをレンダリングすることなく、あらゆるエージェントがそのデータを利用できるようになります。
- APIの発見可能性を高める –
/.well-known/bookingのような周知の場所にポインタを配置するか、ページのschema.orgマークアップにReserveActionエントリを埋め込みます。これにより、スクレイピングを必要とせずに、エージェントに対して「ここにプログラムによる予約手段がある」ことを伝えることができます。 - Model Context Protocol (MCP) を採用する – MCPを使用すると、アシスタントは入力を渡し、構造化された出力を受け取ることで、外部ツールを直接呼び出すことができます。主要なAIプロバイダーはすでにMCPをサポートしているため、MCP互換のエンドポイントを実装しているレストランは、エージェントから組み込み関数のように呼び出すことが可能になります。
これらのステップを踏むことで、人間向けのビジュアルなiframeを維持したまま、エージェントに対して同じ予約データへのクリーンで信頼性の高い経路を提供できます。
まとめ
カレンダーをiframe内に埋め込むことは、人間にとっての視覚的なフローを保護しますが、AIアシスタントにとっては盲目な状態を作り出します。適切にドキュメント化された控えめな予約APIを追加し、標準的なメタデータやMCPを通じてそれを周知させることは、ウェブサイトを全面的に刷新することなく、新しい予約チャネルを開拓することにつながります。この取り組みは、次世代のデジタルアシスタントに対する視認性を高め、そのリスクは既存のUIで使用されているものと同じセキュリティコントロールで管理することが可能です。