- はじめに——「引用される」の次に来たのは「操作される」だった
- なぜ今か——エージェンティックブラウザ由来の流入は「桁」で増えている
- AXとは何か——AEO・GEO・アクセシビリティ・エージェンティックコマースとの違い
- エージェントは、あなたのサイトを”クライアント”として叩く
- 設計①：操作可能性（Operability）——「押せる・入れられる・辿れる」を保証する
- 設計②：DOM安定性——セレクタが壊れない”インターフェース契約”を結ぶ
- 設計③：エージェント認証（Agent Auth）——正規エージェントを”見分けて通す”
- 設計④：行動導線（AX導線）——摩擦をゼロに近づけて完遂させる
- AXの計測——「操作されたか」をどう可視化するか
- AX最適化チェックリスト
- よくある質問（Q&A）
- まとめ——サイトを「読ませる」だけでなく「操作させられる」状態にする
- 参考リンク
はじめに——「引用される」の次に来たのは「操作される」だった
これまで当サイトのAEO（Answer Engine Optimization）関連記事では、「AIに引用・推薦される」ための最適化——原子化された事実の設計、被引用データポイントの作り込み、商品フィードの機械可読化——を中心に扱ってきました。しかし2026年、流入構造そのものが一段深いレイヤーへ移りつつあります。それは、AIが記事を読んで引用する段階から、AIが実際にサイトを開いて・比較して・手続きまで完了する段階への移行です。
引き金になったのが、エージェンティックブラウザの登場です。Perplexityの「Comet」が2025年7月9日に、OpenAIの「ChatGPT Atlas」が2025年10月21日に公開され、address barに自然言語で指示するだけで、ブラウザ側の「Agent Mode（エージェントモード）」が人間に代わってサイトを操作するようになりました。ユーザーは「一番コスパの良いプランを比較して申し込んでおいて」と頼むだけ。実際にフォームを埋め、ボタンを押し、手続きを進めるのはエージェントです。
ここで新しく問われるのが、「あなたのサイトは、人間ではなくエージェントに操作されることを前提に作られているか？」という視点です。本記事では、これをAX（Agent Experience／エージェント体験）最適化と呼び、操作可能性・DOM安定性・エージェント認証・行動導線という4つの設計軸で、”操作の摩擦をゼロに近づける”実装の考え方を整理します。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで、長年「機械が機械を叩く」トラフィックの設計と異常検知に携わってきました。本記事の核心は、その「クライアント（機械）から見て叩きやすいインターフェースをどう設計するか」というNOC/インフラ的な発想が、そのままAX最適化に転用できるという点にあります。エージェントは、あなたのサイトを”UI”ではなく”API”のように扱う新しいクライアントだからです。
なぜ今か——エージェンティックブラウザ由来の流入は「桁」で増えている
AXを「まだ先の話」と片づけられない理由は、トラフィックの実データに表れています。セキュリティ企業HUMAN Securityの観測では、AIエージェント／エージェンティックブラウザ由来のリクエストは、2025年7月比で＋6,900%という急増を示しました。さらにEC領域では、ブラックフライデーからサイバーマンデーの5日間で、エージェントによるトラフィックが直前の5日間比で＋144.7%に達しています。AIエージェントのトラフィック全体も、2025年7月から9月にかけて3倍以上に増えました。
| 指標 | 観測値 | 意味 |
|---|---|---|
| エージェント／エージェンティックブラウザ由来リクエスト | 2025年7月比 ＋6,900% | 流入経路として無視できない規模に |
| AIエージェントの総トラフィック | 2025年7〜9月で 3倍以上 | Comet・ChatGPT Agentの本格展開が起点 |
| EC向けエージェントトラフィック | ブラックフライデー〜サイバーマンデーで ＋144.7% | 「買う」行為そのものがエージェント化 |
出典：HUMAN Security（2025年）。値は観測ベースであり、サイトや期間により変動します。
重要なのは、この流入が従来の「読まれる（引用）」ではなく「操作される（実行）」性質を持つことです。エージェントは記事を要約するだけでなく、フォームを埋め、カートに入れ、申込ボタンを押します。つまり、コンバージョンの直前工程が、人間の目と手からエージェントの解析と操作に置き換わり始めているということです。ここで操作に失敗すれば、どれだけ引用されても成果に結びつきません。
AXとは何か——AEO・GEO・アクセシビリティ・エージェンティックコマースとの違い
AXは、既存の最適化概念と重なりつつも、狙う”瞬間”が異なります。混同すると打ち手を間違えるため、まず座標を整理します。
| 概念 | 最適化する瞬間 | 相手 | ゴール |
|---|---|---|---|
| AEO | AIが回答を生成する時 | 回答エンジン | 引用・推薦される |
| GEO | AIが知識を学習・組込む時 | 生成エンジン | 知識として組み込まれる |
| Webアクセシビリティ | 支援技術がページを読む時 | スクリーンリーダー等 | 誰でも認識・操作できる |
| エージェンティックコマース | エージェントが決済する時 | 決済プロトコル(ACP/UCP/AP2) | 決済を成立させる |
| AX（本記事） | エージェントがサイトを操作する時 | エージェンティックブラウザ | 操作を摩擦なく完遂させる |
AXは「引用（AEO）」と「決済（エージェンティックコマース）」の”あいだ”——実際にサイトを開いて操作する工程を対象にする。
誤解しやすいのは、Webアクセシビリティとの関係です。アクセシビリティ対応（適切な見出し構造、ラベル付け、代替テキスト）はAXの強力な土台になります。スクリーンリーダーが読めるページは、エージェントも解析しやすいからです。ただしAXはそこで止まりません。アクセシビリティは「認識・操作できる」を保証しますが、AXが目指すのは「エージェントが迷わず・壊れず・最短で完遂できる」という一段上の状態です。決済プロトコル対応（エージェンティックコマース）が”支払いの規格”を扱うのに対し、AXはその手前の”サイト上の操作そのもの”の摩擦を扱います。
エージェントは、あなたのサイトを”クライアント”として叩く
AX設計の出発点は、発想の転換です。人間の訪問者は、多少レイアウトが崩れても、ボタンが見つからなくても、文脈から推測して操作を続けられます。しかしエージェントは、DOM（ページの構造）を解析し、要素を特定し、クリックや入力という操作を”プログラム的に”実行します。これは、人間のユーザーというよりAPIを叩くクライアントの振る舞いに近いものです。
ネットワーク／インフラの世界では、機械が機械を叩くインターフェースには鉄則があります。「予測可能で、安定していて、状態が明確であること」です。エンドポイントの構造が呼ぶたびに変わったり、同じ操作を2回叩くと二重に処理されたり、エラー時に何が起きたか分からなかったりするAPIは、クライアント側の実装を壊します。AXが向き合う課題は、これと構造的に同じです。エージェントにとっての”エンドポイント”はDOM要素であり、”叩きやすさ”は操作可能性とDOM安定性で決まります。
この視点に立つと、AX最適化は次の4つの設計軸に分解できます。以降で1つずつ掘り下げます。
設計①：操作可能性（Operability）——「押せる・入れられる・辿れる」を保証する
第一の軸は、エージェントが要素を確実に特定し、操作できることです。人間なら「なんとなく分かる」導線でも、エージェントには構造として明示されている必要があります。
- 意味のあるアクセシブルネーム： ボタンやリンクに、見た目のアイコンだけでなく機械可読なラベル（
aria-label、明示的なテキスト）を持たせる。「＞」だけのボタンではなく「次へ進む」と分かる名前を付ける。 - ネイティブなインタラクティブ要素： クリック対象は
<button>や<a>といった本来の要素で作る。<div>にJSでクリックを載せた”擬似ボタン”は、エージェントが操作対象と認識しづらい。 - フォームの明示的な関連付け： 入力欄は
<label for>で紐づけ、種別（メール・電話・郵便番号）をtypeやautocomplete属性で明示する。エージェントが「この欄に何を入れるべきか」を推測ではなく構造から判断できる。 - 状態の可視化： 「送信中」「完了」「エラー」といった状態を、視覚だけでなくDOM上の属性（
aria-live、disabled、エラーメッセージ要素）で表現する。エージェントは次の一手を状態から判断する。
要は、「見れば分かる」を「構造で分かる」に翻訳する作業です。これはアクセシビリティ対応とほぼ同じ実装で達成でき、人間のユーザー体験も同時に良くなります。
設計②：DOM安定性——セレクタが壊れない”インターフェース契約”を結ぶ
第二の軸は、エージェントが頼りにするDOM構造の安定性です。APIでいえば「破壊的変更をしない」に相当します。エージェントは要素をセレクタ（構造上の目印）で特定するため、リリースのたびにクラス名やDOM階層が変わると、前回動いた操作が今回は壊れます。
- 安定した識別子を用意する： 自動生成されて毎回変わるクラス名（例：
css-1a2b3c）に依存させない。重要な操作要素には、変更しにくい安定属性（例：data-testidや意味のあるid）を意図的に付与する。 - 重要導線のDOMを”契約”として扱う： 申込・検索・カートなどコンバージョンに直結する要素は、デザイン刷新でも構造を安易に変えない。変えるならAPIのバージョニングと同じ慎重さで扱う。
- 過度な動的レンダリングを避ける： 主要コンテンツや操作要素がクライアント側JSの完了を待たないと現れない設計は、エージェントの取りこぼしを生む。重要要素はできるだけ初期HTMLに含める（サーバーサイドレンダリング／段階的な描画）。
- 予期せぬ割り込みを減らす： 操作の途中で差し込まれるモーダル、Cookie同意の全画面オーバーレイ、突然のレイアウトシフトは、人間にもエージェントにも”操作の割り込み”になる。導線上では最小化する。
NOCの視点で言えば、これはインターフェースの後方互換性を守るという運用規律そのものです。「見た目のリニューアル」が「機械から見た破壊的変更」になっていないか——AX時代は、この観点をリリース前チェックに加える必要があります。
設計③：エージェント認証（Agent Auth）——正規エージェントを”見分けて通す”
第三の軸は、来訪するエージェントを識別し、正規のものを適切に通す設計です。これまでボット対策は「弾く」ことが中心でした。しかしAX時代は、正規のエージェント（ユーザーの代理として来ている）を誤って弾かないことが、機会損失を防ぐ鍵になります。一方で、なりすましや悪意あるボットは従来どおり止める必要があり、この両立が論点です。
- 正規エージェントの識別： エージェントの本人確認には、HTTPメッセージ署名（RFC 9421）を用いるWeb Bot Authのような暗号的検証が広がりつつある。「正規か偽装か」を署名で判別し、正規のみを通す設計が現実解になる。
- CAPTCHAへの過度な依存を見直す： ユーザーが意図して送り込んだ正規エージェントの前に画像CAPTCHAを立てると、操作が完遂できず離脱する。正規エージェントには署名ベースの検証で代替し、疑わしい相手にのみ強い検証をかける段階設計にする。
- エージェント別のレート制御： 「弾く／通す」の二択ではなく、主体（署名・エージェント種別）ごとにレートやアクセス範囲を制御する。正規エージェントには必要な導線を開き、異常な振る舞いには絞る。
- ログイン導線の機械親和性： 認証が必要なサービスでは、多要素認証やパスキーの設計が、代理エージェントの操作を過度に阻害しないかを検証する（本人の関与が必要な部分と、代理で進めてよい部分を分ける）。
これは、NOCで言う「正規トラフィックのホワイトリスト運用」と「異常検知」の組み合わせと同じ構図です。詳しい実装は当サイトの「AIエージェントの本人確認（Web Bot Auth）」の回もあわせてご覧ください。
設計④：行動導線（AX導線）——摩擦をゼロに近づけて完遂させる
第四の軸は、エージェントが目的を最短で完遂できる導線設計です。操作可能でDOMが安定していても、導線が長く・分岐が多く・状態が曖昧だと、途中で失敗します。ここは”操作の摩擦ゼロ化”の中核です。
- タスク完了までのステップを短く： 申込・購入・予約といった主要タスクは、クリック数と入力項目を最小化する。人間の離脱率を下げる設計は、そのままエージェントの完遂率を上げる。
- 各ステップの状態を明示： 「今どの段階か」「次に何が必要か」「完了したか」を構造として返す。エージェントは状態を読んで次の操作を決めるため、曖昧な状態遷移は失敗の温床になる。
- 冪等性（べきとうせい）を意識する： 送信ボタンの二度押しやリトライで二重注文・二重申込が起きない設計にする。機械クライアントはリトライするのが前提——インフラのAPI設計と同じ配慮が要る。
- エラーを”次の一手が分かる形”で返す： 「エラーが発生しました」だけでは、エージェントは回復できない。「郵便番号の形式が不正」など、何を直せばよいかを構造化して返す。
- 機械可読な補助情報： 在庫・価格・配送可否・営業時間などの重要情報は、構造化データ（Schema.org）でも提供し、エージェントが画面解析に頼らず正確に取得できるようにする。
AXの計測——「操作されたか」をどう可視化するか
AXは「やって終わり」ではなく、うまくいっているかを観測して改善する対象です。従来のアクセス解析はエージェントを人間として誤集計しがちなので、計測側の設計も見直します。
| 観点 | 見るべき指標 | 狙い |
|---|---|---|
| 流入の識別 | エージェント／ブラウザ別のトラフィック分離 | 人間とエージェントを混ぜて集計しない |
| 操作の完遂 | エージェント経由のタスク完了率・離脱ステップ | どこで操作が壊れているかを特定 |
| DOM安定性 | リリース後のエージェント失敗率の変化 | “見た目のリニューアル”が破壊的変更になっていないか |
| 認証の通過 | 正規エージェントの誤ブロック率 | 機会損失（弾きすぎ）を検知 |
| 成果への寄与 | エージェント経由の申込・購入のアトリビューション | AX投資のROIを可視化 |
従来のCVR計測に「エージェント経由」という軸を1本足すのが第一歩。
AX最適化チェックリスト
| 軸 | チェック項目 |
|---|---|
| 操作可能性 | 操作要素にネイティブ要素と機械可読なラベルを付けているか |
| 操作可能性 | フォーム入力にlabel・type・autocompleteを明示しているか |
| DOM安定性 | 重要導線に安定した識別子（data-testid等）があるか |
| DOM安定性 | リニューアルで重要要素の構造を破壊していないか |
| DOM安定性 | 主要コンテンツが初期HTMLに含まれ、割り込み(モーダル等)が最小か |
| エージェント認証 | 正規エージェントを署名等で識別し、誤って弾いていないか |
| エージェント認証 | CAPTCHAが正規エージェントの完遂を阻害していないか |
| 行動導線 | 主要タスクのステップ・入力を最小化しているか |
| 行動導線 | 状態・エラーを構造化して返し、冪等性を確保しているか |
| 行動導線 | 在庫・価格等を構造化データでも提供しているか |
| 計測 | エージェント経由の完遂率・失敗ステップを分離集計しているか |
よくある質問（Q&A）
Q1. AXは、AEO対策ができていれば自動的に達成できますか？
いいえ。AEOは「AIに引用・推薦される」ための最適化で、対象はコンテンツの中身です。AXは「エージェントが実際にサイトを開いて操作を完遂できる」ための最適化で、対象はDOM構造・操作要素・導線です。引用されても、いざエージェントが操作しようとしてボタンを特定できなければ成果になりません。AEOとAXは補完関係にあり、両方が必要です。
Q2. Webアクセシビリティ対応をしていれば、AXは十分ですか？
アクセシビリティは強力な土台になりますが、十分ではありません。適切な見出し・ラベル・代替テキストはエージェントの解析を助けます。しかしAXはさらに、DOMの安定性（リリースで壊れない）、正規エージェントの認証、冪等性を持つ導線設計といった、”機械クライアント特有”の配慮を求めます。アクセシビリティ＝認識・操作できる、AX＝迷わず・壊れず・最短で完遂できる、と捉えると差が明確です。
Q3. エージェントは弾くべきですか、通すべきですか？
「一律に弾く／通す」ではなく、見分けて扱うのが正解です。ユーザーの代理として来る正規エージェントを誤って弾くと、そのまま機会損失になります。一方でなりすまし・悪意あるボットは止める必要があります。Web Bot Auth（RFC 9421のHTTPメッセージ署名）のような暗号的検証で「正規か偽装か」を判別し、正規は通し、疑わしい相手にのみ強い検証をかける段階設計が現実解です。
Q4. サイトを頻繁にリニューアルしています。何に気をつければよいですか？
「見た目のリニューアル」が「機械から見た破壊的変更」になっていないかを確認してください。デザイン刷新でクラス名やDOM階層が変わると、エージェントが前回特定できた要素を見失います。申込・カート・検索などコンバージョン直結の要素には安定した識別子を付け、APIのバージョニングと同じ慎重さで扱うこと。リリース後にエージェント経由の失敗率が上がっていないかを計測するのも有効です。
Q5. まず何から着手すればコスパが良いですか？
最初の一手は、コンバージョンに直結する主要導線（申込・購入・問い合わせ）に絞った対応です。具体的には、その導線の操作要素をネイティブ要素＋機械可読ラベルにし、安定した識別子を付け、状態とエラーを構造化して返す。この3点だけでも、エージェントの完遂率は大きく変わります。全ページを一度に対応しようとせず、成果に効く導線から着手するのが費用対効果の観点で有利です。
まとめ——サイトを「読ませる」だけでなく「操作させられる」状態にする
AEO・GEOの議論は、長らく「AIにどう引用・推薦されるか」に集中してきました。しかしComet・ChatGPT Atlasの登場で、流入は「読まれる」から「操作される」へと重心を移しています。エージェント由来リクエストが2025年7月比＋6,900%という規模に達した今、サイトは「人間が読む場所」であると同時に「エージェントが操作する場所」として設計される必要があります。要点は4つです。
1. 操作可能性を構造で保証する。 「見れば分かる」を「構造で分かる」に翻訳し、ネイティブ要素と機械可読ラベルでエージェントが確実に操作できるようにします。
2. DOMを”インターフェース契約”として守る。 見た目のリニューアルが機械から見た破壊的変更にならないよう、重要導線の構造を安定させます。
3. 正規エージェントを見分けて通す。 一律に弾くのではなく、署名ベースの検証で正規と偽装を判別し、機会損失を防ぎます。
4. 摩擦ゼロの導線で完遂させる。 ステップの最小化、状態の明示、冪等性、構造化されたエラーで、エージェントが最短で目的を達成できるようにします。
「引用される（AEO）」の先に、「操作される（AX）」がある——そしてその先に「決済まで任される（エージェンティックコマース）」が続きます。この一連の流れのうち、”サイト上の操作の摩擦”を担うのがAXです。エージェントという新しいクライアントを、APIを叩くクライアントと同じ規律で迎える。これが、AIブラウザ時代に成果を取りこぼさないための基本姿勢です。
参考リンク
- OpenAI「Introducing ChatGPT Atlas」（2025年10月）
- HUMAN Security「Examining AI Agent Traffic: Powering the Shift to Agentic Commerce」
- HUMAN Security「ChatGPT Atlas vs Perplexity Comet: How Agentic Browsers Work」
- Wikipedia「ChatGPT Atlas」
- W3C「WCAG（Webアクセシビリティ・ガイドライン）」
免責事項： 本記事は2026年8月時点の公開情報に基づく一般的な情報提供であり、特定の製品・構成・サイトにおける効果や安全性を保証するものではありません。エージェンティックブラウザの仕様や各種プロトコル・ガイドラインは更新が速いため、実装にあたっては自社環境・利用規約・関連法令に照らして検討し、最新情報は各公式ソースでご確認ください。統計値は観測ベースであり、サイトや期間によって変動します。
コメント