AEOからAXへ：AIエージェントが読めるサイトをつくる

AIの回答に会社名が出ても、料金が書かれていない。無料で試せるかを聞いたのに、「詳しくは公式サイトを確認してください」で終わる。ブランドの言及を数えるだけでは、こうした回答の不足を見落とします。

エージェントが購入検討を手伝う場面では、検索で候補を見つけた後に、サイトへアクセスして情報を確かめる工程があります。そこで公式情報を取得できるか、読めるか、必要な条件まで確認できるか。この利用体験を扱うのがAX、Agent Experienceです。

AEOの観測にAXの確認を加えると、「紹介されたか」から「顧客の質問に答える材料を渡せたか」まで追えるようになります。

ここではAEOを、AI回答で自社がどう紹介・参照されるかを改善する取り組みとして使います。AXは、エージェントが情報や機能を利用するときの体験です。両者は対象が重なりますが、調べる場所が違います。

料金ページへのリンクが引用されていても、内容が正しく読み取られたとは限りません。回答文と、エージェントが実際に取得した内容の両方を見る必要があります。

Finder、Elovic、Shalev、Yosefによる論文「AX is the New AEO」は、1,056社を対象に37,927回のエージェント実行を調べています。質問は料金、機能、導入方法の3種類。Claude系とGPT系のモデルを使う4つの実行環境で比較しています。

読み取りやすさの分類には、研究者側が開発したOraのaccessibilityスコアを使っています。0.65以上をagent-ready、0.50以下をnot agent-readyとし、中間帯は候補段階で除外しています。ブランドの知名度、モデルの事前知識、外部での言及などをそろえて比較した研究です。

以下の数値はこの研究の報告値であり、Orchestorによる測定や、自社サイトを改修した場合の効果予測ではありません。

明確な推薦は、2つのモデルによる評価がどちらも最高点だった回答を数えています。推薦の差は研究全体で約1.9倍と報告されていますが、割合は丸められているため、表示値の割り算と倍率は一致しない場合があります。

研究では、サイト上で行き止まりに遭遇した実行の約99%が、別の情報を使って回答を続けていました。アクセスを遮断しても、その会社についての回答が止まるとは限りません。

論文には、同じ「無料で何を試せるか」という質問に対する2つの経路が示されています。Twilioでは自社ドキュメントを取得し、HashiCorpではアクセスを拒否された後に外部検索へ進み、競合のブログを参照しました。これは収集時点の個別の実行例であり、両社の現在のサイト全体を評価するものではありません。

調査対象の実行環境では、学習済み知識に由来すると評価された回答部分は7〜10%でした。公式サイトを読めないときに増えたのは、主に別の検索・取得経路への依存です。これは、検索を使わない通常のチャットや、すべての質問について同じ割合になるという意味ではありません。

自社で確認するなら、最終回答の引用URLに加え、取得に失敗した公式URLを残します。外部ページが使われた理由が、情報不足なのか、アクセス失敗なのかを分けるためです。

同じ研究でも、どのモデルとツールを組み合わせるかで、明確な推薦の出やすさが変わります。

出典は原論文のFigure 5。モデルと検索手段などが同時に変わるため、この表からモデル単体の優劣は決められません。

自社の計測でも、サービスや実行環境を混ぜた合計だけを見ると、回答の変化をサイト改善の効果と取り違えるおそれがあります。同じ質問、同じ環境、同じ評価基準を保った比較を基本にします。

この研究の重要な観測は、間違った記述だけでなく、必要な事実の欠落です。正確さの評価には、131社について取得した公式情報を使い、2,499回答・31,127件の事実を採点しています。

求められた事実を1つも含まない回答は、後者で約3.7倍と報告されています。ここは前節のagent-ready／not agent-readyの比較ではなく、回答が何を根拠に作られたかによる比較です。グループを入れ替えて解釈しないことが大切です。

たとえば「無料プランで何人まで使えますか」という質問に、「無料プランがあります」とだけ答えた場合を考えます。無料プランの存在が正しくても、人数制限には答えていません。評価項目を「無料プランの有無」「人数」「利用量」「試用期間」に分ければ、この不足を記録できます。

導入方法にも注意が必要です。研究では、導入に関する正確さは根拠の違いによる単純比較でともに24%でした。読める状態を作るだけで、説明不足や情報の探しにくさまで解消するわけではありません。

取得が失敗すると、再試行、別ページの検索、情報の照合が増えます。研究では、自社情報を根拠にした回答1件あたりの費用が、not agent-readyの群で平均64%高くなりました。これは1回のツール呼び出しの費用や、Webサイト運営会社の支出を測った指標ではありません。

自社で同じ観点を調べるなら、失敗した実行も含む総費用を、条件を満たした回答数で割ります。安く終わっても質問に答えていない実行を、効率のよい成功として扱わないためです。

時間が短いだけで品質が高いとは判断しません。回答の充足度と並べて確認します。

AgentReadyの公開仕様は、発見、読み取り、操作という段階で対応を整理しています。すべてのサイトに操作用の仕組みが必要なわけではありません。まず、顧客が判断に使う公開情報への到達と読み取りを確認します。

料金、利用上限、導入手順を、それぞれ安定したURLにまとめます。関連するページからリンクし、サイトマップにも含めます。説明が複数ページに分かれる場合は、料金表から条件や例外へたどれるようにします。

公開ページが取得できない場合は、robots.txtだけでなく、CDNやボット対策による拒否も確認します。管理画面や顧客データへの認証は維持し、公開情報を届ける経路と区別して設定します。

ブラウザーで見えている料金表が、初期HTMLにも含まれるかを確認します。画像の中にしかない条件や、クリック後にしか取得できない重要情報がないかも調べます。

HTTP 200だけでは十分ではありません。返ってきた本文がログイン画面やアクセス確認画面なら、目的の情報は読めていません。HTTPステータスと本文の両方で判定します。

llms.txtや構造化データを用意する場合も、本文と条件をそろえます。入口を追加することと、料金や仕様が正確に伝わることは別の確認項目です。

情報の確認を越えて作業を任せるなら、API、MCP、CLI、WebMCPなど、利用する環境に合う入口を検討します。入力形式、認証、許可範囲、実行結果が分かることが必要です。

この研究は、購入や申し込みを自動実行させた場合の成功率を示してはいません。操作の設計は、読み取りの改善とは別に検証します。人が判断するUIとの接続については、WebMCPとMCP Appsの解説も参照できます。

結果を改善計画に使う際には、研究の範囲も確認します。

公開データも全件ではありません。再現用リポジトリには206ドメイン・7,412実行の層化サンプルと集計スクリプトがあり、サンプルからの再集計値と論文の値の差が説明されています。

そのため、「AEOは不要になった」と結論づけるより、露出の観測に公式情報の読み取り検証を加える使い方が妥当です。外部の言及や引用が有効かどうかは、それぞれの目的と計測条件で判断します。

まず、料金や無料枠など、商談前に繰り返し聞かれる質問を1つ選びます。次に、回答に必要な事実と、その根拠となる公式URLを記録します。

同じ質問を複数回実行し、取得したページ、アクセス失敗、引用、答えた事実、欠けた事実を記録します。欠落が見つかったら、まず本文に答えがあるかを確認し、次に取得経路を調べます。修正後も同じ条件で実行し、回答の不足が減ったかを見ます。

ブランド言及・引用・流入の計測とこの確認を組み合わせると、名前が出なかった問題と、名前は出たが判断材料が届かなかった問題を分けて改善できます。

研究数値と比較表は、Ido Finder、Assaf Elovic、Gad Shalev、Liad Yosefによる AX is the New AEO, arXiv:2609.34951v3（2026年10月6日版、CC BY 4.0）から、日本語で要約・再構成しました。確認手順と質問例は本記事の提案です。