AIエージェントが操作するサイト｜人以外の訪問者への備え

2026年5月の開発者向け発表で、Googleは、サイト側がAIエージェントに使わせたい操作をあらかじめ宣言する仕組みを提案し、自社ブラウザのバージョン149から試験提供を始めると案内しました。旅行予約や通販、確定申告や不動産の大手が試験に参加していることも同時に公表されています。その数日前、2026年5月13日には、GA4に対話型AIからの流入をまとめる区分が追加されました。自社サイトの改修を計画している立場から見ると、この二つは別々の話題に見えます。共通しているのは、サイトを訪れて操作していく相手に、人ではないものが混ざり始めたという事実のほうです。この記事では、エージェントがページをどう読み取って操作するのかを追い、フォーム・料金表・申込導線をどう直すか、そして自動化対策や計測とどう折り合いをつけるかを整理します。

いま、サイトを訪れているのは人だけではない

最初に、事実の並びを確認します。2026年5月、ブラウザの開発元から、サイト側が用意した機能をブラウザ内のエージェントに公開できる仕組みが提案されました。公開の単位は、ページの中で動く処理や入力フォームです。同じ発表では、開発者向けの検証ツールをエージェントからも使えるようにする取り組みが示され、そこでは通信の記録や、支援技術向けの内部構造にエージェントが直接アクセスできることが説明されています。人が画面を見て操作する前提が、ここで一段崩れています。

もう一方の動きが計測です。2026年5月13日、GA4に対話型AIからの流入をまとめる区分が追加されました。ただし、この区分が数えているのは対話型AIの回答からリンクをたどって来た人であって、エージェントの自律的な訪問ではありません。解説では、参照元の情報が落ちる経路があるため捕捉は六割から七割程度にとどまるとも指摘されています。数字が整い始めたように見えて、実際には見えていない訪問が別にあるという状態です。

ここで整理しておきたいのは、AIに関わる訪問が一種類ではないことです。学習や索引づくりのために巡回するもの、人の指示を受けて実際にページを操作するもの、AIの回答を読んだ人が自分で来るもの。この三つは目的も挙動も違います。本記事が扱うのは二つ目、つまり人の代わりにページを操作していく訪問者です。巡回を許すかどうかという議論とは、切り分けて考えてください。

エージェントはページをどう読み取っているのか

エージェントがページを理解するときに使う材料は、おおむね三つあります。ひとつめが、ブラウザが内部で組み立てる支援技術向けの情報構造です。これは、画面を読み上げるソフトなどが使うために、ページの要素と補助的な属性から作られるもので、どの部品がボタンで、どれが入力欄で、それぞれ何という名前なのかが整理された状態で並んでいます。ふたつめがページそのものの構造、みっつめが画面を写した画像です。

この構造を実際に利用する実装は、すでに複数あります。2026年4月に公開されたウェブ制作会社の解説では、ブラウザを自動で操作する複数の道具が、この情報構造を手がかりに動いていることが紹介されています。同じ解説では、エージェントがアクセシビリティの情報を十分に活かしきれていない現状を指摘した研究にも触れられています。仕組みは用意されているのに、読み取りの精度は場面によって大きくばらつくというのが現在地です。

三つめの材料である画面の写しは、構造から意味が取れなかったときの最後の手段として使われます。ただし画像から文字を読み取る処理は、時間も処理の費用もかかりますし、読み違えも起きます。料金や条件を画像の中の文字で示している箇所は、この最後の手段に頼らせることになります。画像に頼らせないことは、読み取りの正確さと速さの両方に効きます。図版そのものを減らす必要はなく、図版が伝えている内容を文字でも書いておけば十分です。

実務への含意は明快です。色や余白を調整して見やすくした工夫は、エージェントには一切届きません。逆に、読み上げソフトのために整えてきた項目名や見出しの階層は、そのまま効きます。支援技術のための整備が、そのままエージェント対応の土台になるという関係になっています。手を付ける順番に迷ったら、まず既存のアクセシビリティ対応の点検から入るのが近道です。

なぜ人向けに作り込んだ画面ほど読み違えられるのか

問題が起きやすいのは、意味を見た目だけで伝えている箇所です。赤い枠で囲んであるから注意書きだ、右上にあるから閉じるボタンだ、といった了解は、画面を見ている人にしか成立しません。構造の側に情報が書かれていなければ、エージェントにとってそれはただの部品です。見た目で伝わっている情報は、機械には伝わっていないと考えたほうが安全です。

具体的につまずきやすい形をいくつか挙げます。名前が「送信」や「詳しく」だけで、何を送るのか何の詳細なのかが分からないもの。同じ文言のリンクがページ内に何本もあるもの。料金や条件を画像の中の文字で示しているもの。スクロールするたびに中身が入れ替わり、いま何件目を見ているのか分からないもの。押した瞬間に画面全体を覆う案内が出て、元の操作に戻れなくなるもの。どれも人が使うぶんには問題になりませんが、機械にとっては手がかりが消えます。

さらに厄介なのが、画面を読み取って操作する方式そのものの脆さです。見た目の位置や並び順を手がかりにしている以上、デザインを少し変えただけで、それまで動いていた操作が止まります。自社の改修と、外から来るエージェントの動きが噛み合わなくなる。この不安定さを前提にすると、次に説明する「宣言する」という考え方の狙いが理解しやすくなります。

転機は、読み取らせるから宣言するへ

2026年5月に提案された仕組みの要点は、サイト側が使わせたい操作を、名前と説明と入力項目の三点セットで宣言することにあります。名前は何をする操作かを表す語にし、説明文にはどんなときに使うのかを書き、入力項目には必要な値の形式と必須かどうかを機械が読める形で定義します。エージェントは画面を推測せず、この一覧から使うものを選んで呼び出します。

解説で繰り返し強調されているのが名前の付け方です。「一番目のボタン」のような名前を付けると、エージェントは何をする操作か判断できず、結局呼ばれません。「配送料を調べる」「在庫を確認する」のように、動作と対象が分かる名前にする。名前と説明文が、そのまま外部から見た機能の説明書になります。社内向けの符丁で名前を付けてきた組織ほど、ここで手直しが必要になります。

同時に、制約もはっきりしています。宣言した操作が使えるのは、その操作を持つページを開いているあいだだけで、タブを閉じれば消えます。複数のサイトをまたいで情報を持ち回ることは、いまのところ想定されていません。標準化はまだ議論の途中で、提供も試験の段階です。いま全面的に作り込む対象ではなく、方向を理解して土台を整えておく対象だと位置づけるのが妥当でしょう。

宣言方式になっても、土台の作りは効き続ける

宣言方式が広がれば、構造を整える作業は不要になるのでしょうか。そうはなりません。宣言は、すでにあるページの機能に印を付ける作業だからです。印を付ける先の入力欄に項目名が結びついていなければ、宣言した操作も正しく動きません。土台が曖昧なまま宣言だけを足しても、誤作動の場所が変わるだけです。

また、宣言に対応していないエージェントは当面いなくなりません。読み取り型と宣言型は、しばらく並走します。したがって備えも二重になります。ひとつは、どんな読み取り方をされても意味が通る構造を用意すること。もうひとつは、対応する相手には、使わせたい操作を明示的に渡すこと。次の表に、二つの方式の違いを整理します。

	読み取り型（いまの主流）	宣言型（提案・試験中）
情報の取り方	支援技術向けの内部構造と画面の写しから推測する	サイトが公開した操作の一覧から選んで呼び出す
壊れやすさ	デザイン変更や表示の入れ替えで動かなくなる	宣言した操作を変えない限り安定する
サイト側でやること	項目名・見出し・状態の表示を構造に書く	操作の名前・説明・入力項目を定義する
いま着手する価値	高い。既存の改修でそのまま効く	限定的。方向の把握と設計の整理まで

表の使い方は、右の列を追いかけることではありません。左の列に書かれた作業は、今日から効いて、しかも人にも効きます。右の列は、標準が固まってから手を付けても遅くない領域です。この優先順位を社内で共有しておくと、新しい話題が出るたびに方針が揺れるのを防げます。

対策1：フォームを、機械が埋められる形にする

エージェントが最初に触るのは、たいていフォームです。ここで効くのは三点あります。第一に、入力欄と項目名が構造の上で結びついていること。画面上で左に文字が置いてあるだけでは、対応関係は伝わりません。第二に、必須かどうかと入力の形式が明示されていること。第三に、選択肢が独自の部品ではなく、標準的な仕組みで作られていることです。

見落とされがちなのが、失敗したときの返し方です。人であれば、赤くなった枠を見て自分で直します。エージェントは、何がどう間違っているかを文章で受け取れれば、自力で修正して再送できます。「入力に誤りがあります」だけでは直せません。「電話番号は数字のみで入力してください」のように、対象と条件を含んだ文にする。この書き換えは、人にとっても親切になります。

避けたい作りも並べておきます。画像を選ばせる確認、一定時間で無効になる入力画面、住所の自動補完を前提にして番地欄を隠す設計、送信ボタンを画像だけで作る設計。人の目と手を前提にした親切な仕掛けほど、機械の前では障害物になります。すべてを撤去する必要はありませんが、機械でも通れる代替の道を残しておくと、取りこぼしが減ります。

対策2：申し込みの導線で、途中の状態を見せる

複数の画面をまたぐ申し込みは、エージェントがもっとも迷う場所です。全体が何段階あるのか、いまどこにいるのか、前の画面に戻れるのか。この三つが構造から読み取れないと、同じ画面を往復したり、途中で止まったりします。進行状況を画面の飾りとしてではなく、読み取れる情報として置くことが要点になります。

確認画面の扱いも決めておきます。入力の確認と、最終的な送信を同じ操作にまとめてしまうと、エージェントが意図せず確定させる余地が生まれます。逆に、確認の段階で内容が一覧として読める形になっていれば、送信の前に人が目を通す運用を挟めます。取り返しのつく段階と、つかない段階を分けておく設計です。

途中で離脱した場合の再開も見直します。入力の途中で別のページに移ると最初からやり直しになる作りは、人にとっても不便ですが、エージェントにとっては致命的です。再開できる導線があるかどうかで、完了までたどり着く率が変わります。ここは既存の改善施策と目的が重なるため、エージェント対応を理由に予算を取りやすい部分でもあります。

対策3：料金表と条件は、同じ場所に置く

比較表と料金表は、エージェントが利用者に代わって読み、判断の材料として持ち帰る場所です。ここで起きやすい事故が、条件の欠落です。表の中に金額だけを書き、初期費用が別途かかることや、最低契約期間があること、表示が税抜であることを注釈記号で下に逃がしていると、金額だけが切り取られて伝わります。人であれば注釈に目を走らせますが、機械は表の行を単位として読みます。

対処は難しくありません。条件を、その金額と同じ行に書くことです。行が長くなるようであれば、列を足して条件の欄を設けます。表の見出しのセルが見出しとして作られているか、複数の行にまたがる結合セルで構造が崩れていないかも、あわせて点検します。表を画像として貼っている場合は、それだけで読み取りの対象から外れます。

さらに一段進めるなら、その表が何と何を、どの観点で比べたものかを、表の前後に文章で書いておくことです。表単体を切り出されたときにも、比較の前提が一緒に運ばれます。条件が本文から離れるほど、誤った理解のまま次の操作に進まれる危険が上がります。誤った条件で申し込みが完了してしまえば、対応する工数は自社側に返ってきます。

対策4：取り消せない操作には、人の承認を挟む

提案されている宣言方式では、支払いやデータの削除のように取り返しのつかない操作について、人の確認を必ず挟む設計が前提にされています。サイト側も同じ線引きを持っておくべきです。判断の基準は単純で、間違えたときに自社の手作業で元に戻せるかどうかです。戻せるものは自動で進んでよく、戻せないものは止める。

線引きは技術の話ではないので、情報システム部門だけでは決まりません。金額の発生、契約の成立、個人情報の登録、既存データの上書き。どこからを止めるのかは、事業側と法務を交えて決める必要があります。一度決めたら、その内容を文書に残してください。担当が替わったときに、なぜここで止めているのかを説明できる状態にしておきます。

もうひとつ、宣言方式の解説で懸念として挙げられているのが、ページに書かれた文字列が命令として読まれてしまう問題です。エージェントはページの内容を指示の一部として受け取るため、そこに指示めいた文章が混ざっていると、本来の依頼を離れた動きをする危険があります。自社サイトでこの入口になりやすいのは、口コミやコメントのように、社外の人が自由に文章を書き込める欄です。表示する前に処理を通す、宣言する操作の説明文には外部から書き換えられる値を混ぜない、といった手当てが要ります。

• 取り消せる操作と取り消せない操作を一覧にし、後者は必ず人の確認を挟む
• 宣言した操作の説明文には、社外の相手が読む前提で書ける内容だけを入れる
• 外部からの入力に含まれる指示めいた文言を、そのまま処理に渡さない設計にする
• 宣言方式は試験段階のため、対応しない場合でも通常の画面から操作できる道を残す

自動化対策とぶつかる：止めるか、見分けるか

ここまでの話と正面から衝突するのが、既存の自動化対策です。多くのサイトは、機械的なアクセスを弾く仕組みを入れています。判定に使われているのは、端末や通信の特徴、行動の癖、アクセスの間隔などの組み合わせです。ところが、利用者の指示で動くエージェントは本物のブラウザとして動くため、通常の訪問と見分けがつきにくいという問題があります。

この状況について、2026年6月の解説では、判定の軸を「人間かどうか」から「信頼できる相手かどうか」へ移すべきだという主張が紹介されています。具体案として挙がっているのが、エージェントが署名付きの身元情報を提示し、サイト側がその発行元と真正性を検証する方式です。まだ普及の途上ですが、一律に弾く運用の限界が見え始めていることは押さえておきたい点です。

実務としては、全部通すか全部止めるかの二択にしないことです。操作の種類で分けます。閲覧と検索は通す、フォームの送信は追加の確認を入れる、決済は人の操作を必須にする。次の表は、その分け方の出発点です。自社の事情に合わせて、行を足したり基準を厳しくしたりして使ってください。

操作の種類	エージェントに任せてよいか	サイト側の備え
情報の閲覧・検索・絞り込み	任せてよい	項目名と件数の表示を構造に書く
資料請求など、やり直しがきく申し込み	条件付きで任せてよい	確認画面を分け、誤りを文章で返す
有料の契約・決済	任せない	人の操作を必須にし、自動での確定を止める
登録情報の変更・削除	任せない	本人確認を挟み、変更前の内容を残す

この表を作る過程そのものに価値があります。どの操作なら外から呼ばれてよいかを社内で言語化した記録が残るからです。宣言方式に対応する日が来たとき、この一覧がそのまま設計の入力になります。逆に、この整理を飛ばして技術の対応から入ると、後で決めきれずに止まります。

計測が壊れる：数字の意味が変わる

エージェントの訪問が増えると、いま見ている数字の意味が静かに変わります。滞在時間は短くなり、直帰の判定は当てにならなくなり、ページの遷移は人の関心を表さなくなります。困るのは、どこからどこまでがエージェントの訪問なのかを、標準の機能では切り分けられないことです。エージェント型のブラウザは実物のブラウザとして動くため、通常の訪問と区別できないと指摘されています。

先に触れた対話型AIからの流入の区分も、あくまで人の流入を対象としたものです。しかもアプリや専用の画面から来た場合は参照元の情報が落ちやすく、捕捉は六割から七割程度にとどまると解説されています。見えていない訪問がある前提で、数字を読む習慣をつけておく必要があります。前年との比較を機械的に行うと、施策の評価を誤ります。

補い方は三つあります。ひとつは、問い合わせや資料請求の入口で、きっかけを尋ねる欄を設けること。ふたつめは、画面側の計測だけでなく、サーバー側に残る記録も併せて見ること。みっつめは、社内で報告する指標を、訪問の数から最後まで完了した件数と、その質に寄せることです。完了の数は、誰が操作したかにかかわらず意味を持ちます。

サーバー側の記録では、画面の計測に出ない特徴が拾えます。同じ順路を短い間隔でたどる訪問が増えていないか、入力の開始から送信までの時間が極端に短い申し込みが混ざっていないか。こうした偏りは、人の操作では起きにくい形です。数字を突き止めるためというより、いま自社に何が来ているのかを、月に一度ざっと眺めるための材料として持っておくと、判断が早くなります。

いま実務で着手すべきこと

方向が分かっても、明日から何をするかが決まらなければ動けません。ここまでの内容を、着手できる順に並べます。どれも新しい技術の導入を伴わず、既存の改修の枠内で進められるものにしてあります。上から順に片づけていけば、宣言方式が本格化したときにも慌てずに済みます。

この順番にしている理由は、前の段階が終わっていないと、次の段階の効果が出ないからです。構造が曖昧なままフォームの文言だけ直しても、そもそも入力欄が見つけてもらえません。全社で一斉に進める必要はなく、流入の多い導線から順に回すのが現実的です。

逆に、いま急がなくてよいこと

焦って手を出すと無駄になる領域もあります。まず、宣言方式そのものへの本格的な実装です。標準はまだ議論の途中で、提供も試験の段階です。仕様が動く可能性がある以上、いま作り込んだものが後で書き直しになる確率は低くありません。方向を理解して設計の整理まで進め、実装は仕様が固まってからで間に合います。

次に、エージェント専用のページを別に用意することです。人向けと機械向けで内容の異なるページを作ると、食い違いが生じたときに信頼を失いますし、保守も二重になります。エージェントが読むのは、人が見るのと同じページです。分けるのではなく、同じページの構造を良くするほうに手をかけてください。

最後に、対応をうたう外部の道具の導入です。この領域は動きが速く、半年前の説明が現在と食い違うことが普通に起きます。導入を検討するなら、自社の主要導線で実際に動くかを、契約の前に確かめること。デモ用の画面で動いたことは、自社サイトで動くことを意味しません。

やってしまいがちな進め方

最後に、良かれと思って行われる進め方のうち、後で効きにくいと分かるものを挙げておきます。どれも短期的には形が整って見えるのが厄介なところです。

• 見た目の改善で対応したつもりになる：色や配置はエージェントに届かず、構造は変わっていない
• すべての機械的なアクセスを一律に弾く：利用者の指示で動く訪問まで止まり、申し込みの機会を失う
• 専用ページを別に作る：人向けの内容とずれ、保守の手間が二重になる
• 訪問数の増減だけで効果を判断する：数え方が変わっただけの変動を、施策の成果と読み違える

共通しているのは、相手が何を読んでいるかを確かめずに手を打っている点です。検証ツールで内部構造を一度見れば、どこが伝わっていないかは十分に分かります。作業に入る前の三十分を、その確認に使ってください。判断の精度がはっきり変わります。

よくある質問

うちのサイトに、エージェントは実際に来ているのでしょうか

標準の解析だけでは正確には分かりません。利用者の指示で動くエージェントは通常のブラウザとして訪問するため、区別がつかないと指摘されています。手がかりになるのは、フォームの入力の速さや、画面の遷移の仕方に見られる偏りです。まずは、来ているかどうかを突き止めるより、来ても困らない構造にしておくほうが投資として確実です。

宣言方式に対応しないと、不利になりますか

いまの段階では、そこまで心配する必要はありません。提供は試験の段階で、対応していないサイトも従来どおり読み取られます。ただし、フォームや料金表の構造が曖昧なままだと、読み取り型の相手にも正しく伝わりません。対応の可否より、土台の点検を先に済ませておくほうが効きます。

社内で予算を通すには、どう説明すればよいですか

エージェント対応という言い方だけでは通りにくいので、二つの効果を並べて説明することをおすすめします。ひとつは、支援技術の利用者にも同じ改善が効くこと。もうひとつは、フォームの離脱や条件の誤解といった、いま起きている損失が減ることです。将来への備えと、現在の改善が重なる範囲から着手すると、稟議の説明が組み立てやすくなります。

まとめ

サイトを訪れて操作していく相手に、人ではないものが混ざり始めています。エージェントが読んでいるのは画面の見た目ではなく、支援技術向けの内部構造とページの構造です。だから、まず効くのは新しい記述の追加ではなく、既存の構造を機械にも読める状態に整えることでした。フォームの項目名と失敗時の文言、料金表の条件の置き場所、申し込み導線の途中の状態。この三つを直すだけで、読み取りの精度は上がります。あわせて、取り消せない操作には人の確認を挟むこと、自動化対策を一律の遮断にしないこと、訪問数ではなく完了件数で見ること。宣言方式そのものは試験の段階なので、実装は仕様が固まってからで間に合います。方向を理解したうえで、今日から効く土台の整備を先に進めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。