AIエージェントが人に代わってフォームを埋め、申し込みを送信する動きが実サービスとして動き始めました。2026年8月18日、GoogleはGemini in Chromeを米国の全Androidユーザーへ広げ、操作代行機能「auto browse」もスマートフォンで使えるようにしています。本記事では、AIエージェント経由の予約・申し込みに対応するために何を確認すればいいのかを、当社が自社サイトを実際に診断した結果とあわせて整理します。
この記事でわかること
- 残る関門は送信の最後にある： 当社サイトを8項目で診断したところ、入力欄もボタンも通っていて、条件によって止まりうるのは送信の1か所だけでした。
- 止まった＝非対応ではない： 申し込みが完了しない理由には、サイトの不具合ではなくエージェント側の安全設計によるものが混ざります。分けて考えないと直す場所を間違えます。
- 直す時間より切り分けの時間： 修正そのものは1〜2時間で終わることが多く、時間がかかるのはどこが異常値かを特定する工程です。
まず自社サイトを診断した——8項目は通り、残ったのは送信の1か所だけ
（自社検証）当社サイトの申し込み導線を2026年9月3日に診断したところ、8項目はすべて正常でした。残ったのは1つだけです。
診断の対象は、aidaim.co.jp のトップページに置いた申し込みのCTAから、お問い合わせページのフォーム送信までです。人間のブラウザでは問題なく送信できる導線を、初期HTMLの中身とフォームの構造から見ています。
通っていたのは、フォームの本体にあたる部分でした。お問い合わせページのフォームはサーバー側で出力されていて、JavaScriptを実行する前の初期HTMLの時点で入力欄26個とテキストエリア、送信ボタンがすべて存在します。チェックボックスとラジオボタンはラベル要素が入力欄を包む形で書かれており、どの選択肢が何を意味するかは機械からも読み取れます。送信ボタンも装飾したdiv要素ではなく、本物の送信ボタン要素でした。Cookie同意のオーバーレイも入っていません。
導線の入口も通っていました。トップページの申し込みボタンは、いずれもお問い合わせページのURLを直接指しており、ページ内アンカーで宙に浮いているものはありません。エージェントは「お問い合わせを押す」の一手で目的のページへ到達できます。
残ったのは、送信の最後です。
フォームにはreCAPTCHA v3が入っています。v3は画面にチェックボックスを出さないスコア型で、JavaScriptがバックグラウンドでトークンを作り、サーバー側がそのスコアを見て通すか落とすかを決めます。自動操作は低いスコアが出やすく、しきい値を下回れば送信は拒否されます。厄介なのは、その拒否が誰にも見えないことです。訪問者はエラーの理由を知らされず、サイト側の管理画面にも「落ちた申し込み」は残りません。
（アイダイム分析）注目したいのは、8項目を満点で通過しても「エージェントが確実に申し込める」とは言い切れない点です。HTMLの作りで直せる部分をすべて直したあとに、スコア型のbot対策という判断の要る関門が最後に残ります。ここは技術の問題ではなく、スパムをどこまで許容するかという運用方針の問題です。チェックリストを全部埋めれば終わり、という話にならないのはこのためです。
機械がページをどう巡回し解釈するかという前提は「検索エンジンのクローラー（bot）の仕組みと制御方法」で解説しています。
申し込みを完了できない8つの原因と、アイダイムの実測結果
AIエージェントが申し込みを完了できない原因は、サイト側に限れば8類型に整理できます。それぞれ確認方法と直し方が決まっています。
AIエージェントは、画面の見た目、HTMLの構造、アクセシビリティツリーという3つの経路を組み合わせてページを読み取ります。Google公式の開発者向けガイド「エージェント フレンドリーなウェブサイトを構築する」も、必要な操作をインターフェースに明示すること、ボタンとリンクは本物の要素を使うこと、role と tabindex を指定すること、ラベルを入力欄に紐付けること、クリックできる領域を8平方ピクセルより大きくすることを挙げています。人間の見た目ではなく、HTMLの意味的な構造が申し込み成立の可否を分けます。
（自社検証）当社代表は臨床検査技師として10年以上、検査値が正常範囲にあるかを1項目ずつ判定する精度管理の実務に携わってきました。「正常か、異常値か」で切り分ける見方は、サイトの診断にそのまま使えます。技術に詳しくなくても、項目ごとに正常・異常を付けていけば、どこが機械にとっての異常値かを特定できます。
下の表は8つの原因に、当社サイトを診断した結果を並べたものです。
| 原因 | 症状 | 確認方法 | 直し方 | 自社で直せるか | 当社の実測 |
|---|---|---|---|---|---|
| JS実行後にしか描画されない | 初期HTMLが空の外殻で、フォームやカレンダーが見えない | ページのソースを表示し、フォーム要素が含まれるか見る | サーバー側で描画する、主要素を初期HTMLに含める | 構成による | 正常 |
| Cookie同意が本文を覆う | 同意するまで内容が隠れ、先へ進めない | 同意前にフォームが見えているか確認する | 覆い隠さない実装に変更する | 直せる | 正常 |
| 入力欄にラベルがない | どの欄に何を入れるか機械が判断できない | 各入力欄にラベルまたは aria-label があるか見る | ラベルで包むか for 属性で紐付ける | 直せる | 正常 |
| div で作った偽ボタン | 「送信する」が操作可能と認識されない | ボタン要素・リンク要素・送信ボタンで作られているか見る | 本物のボタン要素に置き換える | 直せる | 正常 |
| 閉じられないモーダル | ポップアップから抜けられず申し込みが止まる | 閉じるボタンが常に見え、キーボードで押せるか | 閉じる導線を明示し、キーボード操作に対応する | 直せる | 正常 |
| エージェントを一律で拒否する認証・bot対策 | スコアやチャレンジで送信が落ち、落ちたことが記録に残らない | reCAPTCHA・Turnstile等の種別としきい値を確認する | しきい値の見直し、署名済みエージェントの扱いを決める | 方針判断が要る | 異常値（reCAPTCHA v3） |
| 極端に遅い読み込み | 処理が長引き、途中で接続が切れる | 表示速度を計測し、極端に遅い箇所を探す | 不要なJavaScriptを減らす | 直せる | 正常 |
| 引き継げないログインの壁 | 認証情報を渡せず、そこで止まる | 申し込み前にログインが必須になっていないか | ログインを任意化し、代替の導線を用意する | 方針判断が要る | 該当なし |
8つのうち、ラベル・ボタン・モーダルの3つはHTMLの意味的な構造を整えるだけで対応できます。Webアクセシビリティ指針が15年以上前から推奨してきた内容と重なる項目で、新しく発明された難題ではありません。
一方、bot対策と認証の2つは方針判断を伴います。ここで注意したいのは、CAPTCHAやログインが「あること自体」を失格と見なさないことです。2026年後半に入り、Geminiは許可されたサイトについてパスワードマネージャーを使ったサインインを扱えるようになりました。bot対策の側でも、Cloudflareが主導するWeb Bot Authが2026年9月1日にIETFのワーキンググループ文書となり、エージェントの運用者を署名で識別する仕組みの標準化が進んでいます。壁の有無ではなく、正規の委任エージェントまで一律で落とす実装かどうかが分かれ目です。
（実務知見）当社がサイト制作や構造化マークアップ代行で入った案件のうち、申し込みフォームの前にCAPTCHAやログインを置いているのは全体の2割ほどです。しかもその多くは当社が標準で入れているものではなく、クライアントからの依頼で後から追加したものでした。スパム対策として必要だから入っているケースが大半で、外せば済むという単純な話にはなりません。だからこそ「入れる・入れない」ではなく「しきい値をどう置くか」「正規のエージェントをどう通すか」の設計として扱う必要があります。
表示速度の改善手順は「ページ表示速度とSEOの関係・改善方法」で解説しています。
Q. CAPTCHAを入れていると、AIエージェントからの申し込みは必ず落ちますか。
A. 必ず落ちるとは限りません。画面にチェックボックスを出す方式は機械が解けませんが、スコア型はしきい値の設定次第で通ります。まず自社が入れている方式としきい値を確認するところから始めるのが現実的です。
壁の扱いを決める前に、そもそも「止まった」のがサイトのせいなのかを切り分ける必要があります。
サイトの不具合ではない停止——エージェント側の安全制御と仕様制限
申し込みが完了しない理由は3つに分かれ、サイト側で直せるのはそのうち1つだけです。残る2つは手を入れても届きません。
AIエージェントで予約や申し込みを試した人の報告を見ると、止まる場面として繰り返し挙がるのは、ログイン、送信や決済の直前で本人の確認を求められる場面、サイト側の制限、誤ったクリックや途中でのタスク放棄、そして確認画面の情報が足りずに判断できない場面です。このうち「送信前に確認を求める」はエージェントの不具合ではなく、意図された設計です。副作用のある操作を勝手に実行しないよう、確認を挟むことが公式に定められています。
下の表は、止まった理由を誰が直せるかで分けたものです。
| 止まり方 | 代表的な場面 | 対応 |
|---|---|---|
| サイト側で直せる停止 | フォームが初期HTMLに無い、ボタンが本物でない、リンク先のアンカーが存在しない、bot対策が一律で落とす | 8つの原因の表に沿って直す |
| エージェント側の仕様で止まる | 誤ったクリック、途中でのタスク放棄、扱えないと判断して中断する | 直せない。ページを単純にして誤りにくくするのが唯一の手当て |
| 利用者の確認が必要な正常停止 | 送信直前、決済直前に本人の承認を求める | 直さない。確認画面に必要な情報が載っているかだけ整える |
（アイダイム分析）3つを混ぜたまま「対応していない」と判断すると、直す必要のない場所に手を入れることになります。とくに3つ目を不具合とみなして確認を省く方向に動くのは、利用者にとっても事業者にとっても危険です。エージェントの利用者から見て「何をいくらで、いつ確定したのか」が確認画面で分からなければ、その承認は事後の追認にしかなりません。確認を消すのではなく、確認画面に載る情報を整えるのが正しい方向です。
止まり方の切り分けができたら、次は自分のサイトで実際に測ります。
自分で確かめる3ステップ——時間がかかるのはチェック、直すのは1〜2時間
自社サイトの診断は、初期HTMLの確認、キーボードだけでの完遂、実際のエージェントでの申し込みテスト、の順で進めます。
手順1 初期HTMLとアクセシビリティを確認する
初期HTMLに、フォームと入力欄と送信ボタンが最初から入っているかを確認します。
ページのソースを表示し、あわせて各入力欄にラベルが付いているか、送信が本物のボタン要素かを見ます。ブラウザの開発者ツールでJavaScriptを無効化してから再読み込みする方法は、初期HTMLに何が入っているかを手早く見るための補助として有効です。ただし、これだけで合否は決められません。AIエージェントは画面の見た目とアクセシビリティツリーも併せて読むため、JavaScriptを実行できるエージェントも存在します。
手順2 キーボードだけで申し込みを完了できるか試す
マウスを使わず、キーボードだけで申し込みを最後まで進められるかを試します。
Tabキーとスペース・Enterだけで操作し、途中でフォーカスが飛ぶ、押せない要素がある、モーダルから抜けられないといった箇所は、機械にとっても同じ場所でつまずきます。
手順3 実際のエージェントで申し込みテストをする
ブラウザ操作型のエージェントに、自社サイトの申し込みを実際に実行させます。
どこまで進み、どこで止まったかを記録します。前の章の3分類のどれに当たるかを判定してから、直す対象を決めます。
（実務知見）構造化マークアップ代行で入ったとき、初期HTMLにフォームやボタンが出ているかの点検から、ラベルとボタン要素の修正までを一式でやると、手を動かす時間そのものは1〜2時間ほどで収まります。時間がかかるのは修正ではなく、どこが異常値なのかを切り分ける工程のほうです。項目を1つずつ正常・異常で判定していく作業に大半の時間を使います。海外では「監査は数時間、修正は1〜2日」といった目安も出ていますが、対象ページ数や予約システムの構成で大きく変わるため、一般的な相場としては受け取らないほうが安全です。
Q. JavaScriptを無効にしてフォームが消えたら、対応できていないということですか。
A. そう決めつけることはできません。JavaScriptを実行できるエージェントもあるため、無効化テストは初期HTMLの中身を見るための補助と考えるのが適切です。合否は手順2と手順3まで進めて判断します。
診断してみて、そもそも申し込みフォームが自社サイトにないという場合もあります。
予約導線が自社ドメインの外にあるとき——MTG予約ツールとiframeの責任境界
申し込み導線を外部サービスに出している場合、直せる範囲はつなぎ方で決まります。
自社のHTMLをいくら直しても、外部サービス側で完了できるかどうかは変わりません。
BtoBの商談予約では、自社サイトのボタンから日程調整ツールへ渡す構成がよく使われます。この場合、自社サイトの役割は「ツールまで正しく届けること」までで、そこから先の入力欄や送信ボタンの作りは自社の管轄外です。どこまでが自分の責任かは、サイトとツールのつなぎ方で変わります。
| つなぎ方 | エージェントから見た挙動 | 自社で直せる範囲 | ツール側に依存する範囲 |
|---|---|---|---|
| 別ドメインへ遷移する | ボタンを押すと別サービスのページへ移る | ボタンが本物のリンク要素か、リンク先が正しいか | 遷移後の入力欄・送信・bot対策のすべて |
| iframe で埋め込む | 自社ページの中に別ドメインの枠が入る。中身は別文書として扱われる | 枠の外側の導線と、枠が確実に表示されるか | 枠の中の構造すべて |
| サブドメインを使う | 見た目は自社だが実体は別サービス | 導線と、テンプレートで調整できる範囲 | サービス側の出力仕様 |
| 自社ドメイン内にフォームを置く | すべて自社ページの中で完結する | 8つの原因のすべて | なし |
当社サイトは表のいちばん下、自社ドメイン内にフォームを置く形です。そのため8項目のすべてを自分で診断できました。一方、日程調整ツールへ渡す構成については、当社ではまだエージェント経由での完了可否を実測していません。ツールごとに描画方式もbot対策も異なるため、本記事では「つなぎ方で責任範囲が変わる」という枠組みまでを示し、個別サービスの可否は断定しません。
（アイダイム分析）外部ツールを使っている場合でも、自社側でできることは残ります。ボタンを本物のリンク要素にすること、リンク先を間違えないこと、遷移前のページで何を申し込むのかが読み取れる状態にしておくことです。とくにリンク先の取り違えは、制作会社の交代やページ改修のあとに紛れ込みやすく、人間のクリックでは気づかれないまま残ります。外部ツールの対応を待つ前に、自社側の入口が生きているかを確認する価値はあります。
日本国内でも、AIエージェントを前提にした導線づくりは始まっています。ぐるなびは飲食店とのマッチングを担うAIエージェント搭載アプリ「UMAME!」を2026年1月に正式リリースし、6月4日には「今の気分」から店を提案する機能を追加しました。約59万店舗の情報を持つ媒体側が、エージェント向けの入口を自前で用意している例と言えます。
WebMCP・Web Bot Auth・構造化データ・llms.txt——4つは代替関係ではない
エージェント対応でよく並べられる4つの技術は、解決する問題がそれぞれ違います。
どれか1つを入れれば申し込みが通るようになる、という代替関係ではありません。
いま注目が集まっているのはWebMCPです。サイトが自分の機能を名前付きの「ツール」として登録し、エージェントがHTMLの構造を推測してクリックする代わりに関数として呼び出す仕組みで、GoogleとMicrosoftが共同で仕様を書いています。W3CのWeb Machine Learning Community Groupが2026年8月26日付のドラフト報告書を公開し、Chromeはオリジントライアルの段階にあります。ただし現時点では提案中の仕様であり、実装は実験的な位置づけです。既存の画面操作方式が置き換わったわけではなく、対応していないエージェントは引き続きHTMLを読んで操作します。段階的な上乗せとして捉えるのが実態に近い理解です。
| 技術 | 何を解決するか | 何を解決しないか | 2026年9月時点の状況 |
|---|---|---|---|
| WebMCP | サイトの機能をツールとして公開し、エージェントに呼ばせる | 未対応のエージェントには効かない | 提案中の仕様。Chromeでオリジントライアル |
| Web Bot Auth | アクセスしてきたエージェントの運用者を署名で識別する | 利用者本人の認証にはならない。通す保証もない | 2026年9月1日にIETFのワーキンググループ文書へ |
| 構造化データ（schema.org） | 対象と行為の意味を機械に伝える | 操作するためのインターフェースは提供しない | v30.0が2026年3月19日公開 |
| llms.txt | 読ませたいコンテンツの場所を案内する | フォーム送信や予約の取り決めは定義しない | 提案仕様のまま。導入率は限定的 |
表のとおり、構造化データとllms.txtは「読ませる」ための技術で、「動かせる」ようにするものではありません。予約に関する語彙としてschema.orgには Reservation や ReserveAction がありますが、これは予約という行為や対象を意味づけるための語彙であって、エージェントに送信機能を提供する規格ではありません。構造化データを入れれば申し込みが通るようになる、という理解は誤りです。構造化データそのものの書き方は「構造化データ（JSON-LD）とは？書き方の基本」で解説しています。
決済を伴う場合は別のレイヤーが乗る
支払いまでエージェントに任せる場合は、申し込みフォームとは別の仕組みが要ります。
OpenAIとStripeが共同開発したACP（Agentic Commerce Protocol）が決済フローの取り決めを担い、Googleが60社以上と策定したAP2（Agent Payments Protocol）が署名付きの認可を担います。両者は競合ではなく層が違います。無料相談や資料請求のように決済を伴わない申し込みでは、ここまでは必要ありません。
エージェントに発見される側の話は「AIエージェント対応サイトとは？ARDで変わる発見の仕組み」で、ページが機械にどこまで読めるかという前提は「AIエージェントの機械可読性とは」で扱っています。
どこまで自社で直せて、どこから依頼するか
診断で見つかった異常値は、修正する場所ごとに担当が変わります。工数より先に、誰が触る領域かを決めるほうが早く進みます。
| 直す場所 | 該当する異常値 | 誰が触るか |
|---|---|---|
| テーマ・テンプレートのHTML | 偽ボタン、ラベルなし、存在しないアンカー、閉じられないモーダル | 自社の担当者、または制作会社 |
| フォームプラグインの設定 | 入力欄の構造、必須項目、送信後の挙動 | 自社の担当者 |
| bot対策の設定 | スコアのしきい値、チャレンジの方式 | 方針を決めたうえで自社またはインフラ担当 |
| 予約・日程調整ツール側 | 遷移後の入力欄と送信の作り | ツール提供元へ問い合わせる |
| サーバー・WAF | アクセス制限、レート制限 | サーバー管理者 |
（アイダイム分析）当社はSEO・MEO・PPC・サイト制作・LLMOを一気通貫でつなぐ7ブリッジSEMの観点から、この対応をサイト制作の層とLLMOの層が交わる場所と位置づけています。構造を整える作業そのものは、検索エンジンにとっても生成AIにとっても読みやすいサイトづくりと方向が一致します。特別な施策を足すというより、すでにやるべきだった作業の優先度が上がった、という捉え方が近いはずです。
（自社検証）当社の海外SEO支援では、機械可読性を重視した構成で、対象キーワードにおいてタイ・台湾で2週間以内に1位を獲得した事例があります。取引の完遂とは文脈が異なりますが、機械が読みやすい構造を整えると施策が短期間で反映されやすいという傾向は、エージェント対応にも通じると考えています。
AIエージェント対応のよくある質問
本編で扱いきれなかった疑問を集めました。
Q. AIエージェント対応とLLMO対策は同じものですか。
A. 別のものです。LLMO対策は生成AIの回答に引用されることを狙う施策で、本記事が扱うのは引用された先で申し込みが完了するかという話です。引用されても申し込みが通らなければ成果になりません。
Q. llms.txt は置いたほうがいいですか。
A. 申し込みの完了という目的に限れば、優先度は高くありません。llms.txt は読ませたいコンテンツを案内する提案仕様で、フォームの送信を成立させるものではないためです。詳しくは「llms.txtは意味ないのか」で扱っています。
Q. 予約を外部ツールに任せている場合、自社側でできることはありますか。
A. あります。ツールへ渡すボタンが本物のリンク要素になっているか、リンク先が正しいか、遷移前のページで何を申し込むのかが読み取れるかは自社側の範囲です。ツール側の対応を待たずに、今日確認できます。
Q. auto browse は日本ではまだ使えないのに、いま対応する意味はありますか。
A. あります。8項目の多くはアクセシビリティ指針が以前から推奨してきた内容と重なり、人間の使いやすさと検索エンジンからの読みやすさを同時に改善します。日本語圏への展開時期は公表されていませんが、対応の中身が無駄になる性質のものではありません。
参考情報
- Google「エージェント フレンドリーなウェブサイトを構築する」（web.dev・日本語版）：https://web.dev/articles/ai-agent-site-ux?hl=ja
- Gemini in Chrome と auto browse の米国Android展開に関する報道（2026年8月18日）：https://9to5google.com/2026/08/18/gemini-chrome-android-us/
- W3C Web Machine Learning Community Group「Web Model Context Protocol」（Draft Community Group Report・2026年8月26日）：https://webmachinelearning.github.io/webmcp/
- IETF Web Bot Auth ワーキンググループ：https://datatracker.ietf.org/wg/webbotauth/about/
- schema.org「ReserveAction」：https://schema.org/ReserveAction
- 株式会社ぐるなび「AIエージェントが導く次世代飲食体験アプリ『UMAME!』」：https://corporate.gnavi.co.jp/release/2026/1xtgwlt37m/
