AI に見つかってから取引されるまで — 7 段階で用語を整理する

• 最終検証日：2026年8月13日
• Methodology バージョン：2026.08.49（訂正）
• 本文中の「2026.08.xx」：その訂正を行った判断基準の版の番号です。公開した版は書き換えず、訂正は新しい版として残しています
• 対象用語：SEO / AEO / GEO / LLMO / AIO / AIEO / AAO / ACO
• 位置づけ：SILVE の操作モデル。業界標準の分類ではありません

最初に断っておくこと

この記事で示す 7 段階は、SILVE が診断のために作った操作モデルです。

• 業界標準の分類ではありません
• プラットフォームの実装アーキテクチャでもありません
• 必ず 1 → 7 の順に進むという意味でもありません

引用されずに情報が回答へ使われることもあります。検索を介さずフィードから商品が取得されることもあります。エージェントがユーザーから直接 URL を渡されることもあります。経路はプラットフォームごとに違います。

そして 7 という数字に理論的な必然性はありません。「どこで詰まっているか」を切り分けるための粒度として選んだだけです。どうなったら段階を増減するのかは、記事の最後に書きます。

この前提を先に置くのは、この種のモデルが「業界の共通認識」として一人歩きしやすいからです。SILVE は 8 本の用語記事で、提唱者の枠組みが業界標準として流通してしまう例を繰り返し見てきました。自分たちのモデルにも同じ扱いをします。

なぜ一本道の年表にしないのか

AI 検索の世界では、ここ数年で大量の用語が生まれました。

SEO、AEO、GEO、LLMO、AIO、AIEO、AAO、ACO。

これらを、

SEO → AEO → GEO → LLMO → AIO → AIEO → AAO → ACO

という進化の一本道として並べたくなります。しかしこれは誤りです。

SILVE が 8 本の用語記事を一次資料まで遡って検証した結果、次が分かっています。

• AEO は生成 AI 以前から存在する。 提唱者側の canonical 資料が 3 ページで年を食い違えている
• LLMO の確認済み最古の用例は、GEO 原論文より約 1 か月早い（2023-10-12 と 2023-11-16）
• AIO は起源不明で、展開形が 3 つ競合している
• AIEO は、誰がいつ命名したのかを裏づける独立資料を確認できていない（用語を扱う第三者の記事やサービスは存在します。確認できていないのは命名の主体と時期です）
• AAO には範囲の違う 2 つの起源系統がある
• ACO は AAO の上位ではなく、コマース領域への縦割り。しかも主張されていた命名日は当時のアーカイブで反証された

つまり名称の歴史はツリー状に分岐しています。直線ではありません。

一方で、企業が直面する実務上の問題のほうは、比較的きれいに整理できます。だから SILVE は、用語ではなく段階を診断の中心に置きます。

混同してはいけない 2 つのパイプライン

先に紛らわしい点を潰しておきます。SILVE は別の場所で別のパイプラインについても書いています。

視点も粒度も違います。前者は機械の内部、後者は事業者から見た到達段階です。段階数が近いことに意味はありません。

7 段階

「AI 検索で上位になる」という一言では、この 7 つのどこの話なのかが分かりません。

なお学術側でも、GEO を単一のランキング問題として扱わない見方は共有されています。2026 年 7 月に公開された GEO 研究のレビュー（45 本を対象とした単著のプレプリント）は、GEO を確率的で部分的にしか観測できない多段階のパイプラインとして整理しています。

ただし 同レビューが SILVE のこの 7 段階を支持しているわけではありません。同レビューは abstract で 9 項目、図で 7 ノード、形式モデルで 4 関数という粒度の異なる 3 通りの分解を示しており、そのいずれも本記事の 7 段階とは切り方が違います。共有されているのは「単一のランキング問題ではない」という構えまでです。

1. 発見 — そもそも見つけられるか

このモデル上の最初の段階です。ただしすべての経路の起点ではありません — 商品フィードから直接取得される場合や、利用者がエージェントへ URL を渡す場合は、この段階を経由しません。それでも、ページが存在していても必要なシステムがアクセスできなければ、現在の情報源として使われる可能性は限られます。

Google は公式ガイドで、Google Search の生成 AI 機能が中核の検索ランキング・品質システムに根ざしていると述べ、生成 AI 機能に表示される前提として「ページがインデックスされ、スニペット付きで Google 検索に表示され得ること」を挙げています。

前提はそれだけではありません（2026.08.45 で追記）。 同じ Google の生成 AI 向け最適化ガイドは、Search の技術要件に加えて、サイトが Search Console で Search generative AI features に含まれている必要があるとしています。既定は「含める」で、除外すると生成 AI 機能でリンクされず grounding にも使われません（通常の検索結果と学習には影響しません。一部のサイトへの段階的な提供です）。

OpenAI では ChatGPT 検索向けのクローラとして OAI-SearchBot が定義されており、検索用の OAI-SearchBot と学習用の GPTBot は設定が独立しています。

「独立」は SILVE の要約ではなく OpenAI 自身の記述です。公式文書は each setting is independent of the others とし、その例として「検索結果に出るために OAI-SearchBot を許可しつつ、学習に使わせないために GPTBot を拒否する」を挙げています。

ここで重要なのは、Discovery Policy と Training Policy を分けることです。GPTBot を拒否していても OAI-SearchBot を許可していれば ChatGPT 検索には参加できます。基盤モデルの学習を拒否することは正当な知財ポリシーであり、それ自体を減点する根拠はありません。SILVE は 2026.08.1 でこの誤りを修正しました。

ただし「拒否すれば一切出なくなる」ではありません。 同じ文書は、OAI-SearchBot を拒否したサイトについて ChatGPT の検索の回答には表示されないが、リンクとしては表示され得ると述べています。掲載経路を塞ぐことは回答の中で情報源として使われる可能性を断つのであって、その名前が画面から消えることとは違います。

その経路も公開されています（2026.08.49 で確定）。 OpenAI の Publishers and Developers FAQ は、第三者の検索プロバイダから URL を得た場合や、他のページのクロールから URL を得た場合に、リンクとページの題名だけを表示することがあると説明し、それを望まないなら noindex メタタグを使うよう案内しています。

ここに既知のねじれがあります。 同じ文書は「メタタグを読むには、そのページのクロールが許可されている必要がある」とも書いています。robots.txt で塞ぐと、止めるための noindex を読ませられません。

主に関係する用語：SEO / AEO / GEO / LLMO

2. 取得 — 候補として取得されるか

発見可能であることと、実際に回答生成時に取得されることは別です。

Google は AI Overviews と AI Mode の両方について、1 つの質問から複数の関連検索を発行する クエリ fan-out を使う場合があると説明しています（この機能特定は 2025 年 12 月更新の別ページにあり、2026 年のガイド本体では機能を特定していません）。またガイド本体は RAG（retrieval-augmented generation、grounding とも呼ぶ）を、検索インデックスから関連する最新のページを取得する技術として明記しています。

つまり「東京で子どもと行ける雨の日スポット」という 1 つの質問でも、内部では別の観点の取得が並行して走り得ます。

Google は、誰でも書ける一般知識に基づく commodity content より、独自の洞察と深い経験を持つコンテンツを作るよう案内しています（ガイドは commodity content の例として「初めて家を買う人への 7 つのヒント」のような記事を挙げています）。

発見と取得は同じではありません。 インデックスされていることは発見側の条件で、特定の回答で情報源として取得されたことは取得側の結果です。同様に、OAI-SearchBot を許可していることは参加可能性であって、特定のプロンプトで取得されることを保証しません。

したがって SILVE は「クローラを許可している = AI 検索対策完了」とは評価しません。

主に関係する用語：SEO / GEO / AEO / LLMO

3. 利用 — 回答に使われるか

取得された情報が必ず回答へ使われるとは限りません。

ここは GEO 原論文が扱った領域でもあります。ただし注意が要ります。前述のレビューは、原論文などが示した効果について次を分けるべきだと指摘しています。

• すでに文脈へ入っている情報源の利用・引用を改善できるという証拠
• Web 全体から自然に発見・取得される確率を改善するという証拠

レビューの結論は前者に留まります。レビュー対象のコーパス内では、後者について安定した効果を示した手法は無かったとしています。これは「そうした手法が存在しない」という主張ではなく、レビューした範囲での結論です。

「AI に理解される」を分解する

LLMO や AIEO では「AI に理解される」という表現が頻繁に使われます。しかしこれは 1 つの魔法の指標ではありません。実務では観測可能な要素へ分解できます。

同じ企業名がページごとに違わないか。ブランド名と法人名の関係が明確か。運営主体が分かるか。著者が特定できるか。価格・対象者・制約が曖昧でないか。

SILVE は「AI Understanding Score」のような観測できない抽象値を作らず、Entity Clarity / Information Completeness / Source Transparency へ分けて評価します。

主に関係する用語：AEO / GEO / LLMO

4. 引用 — 情報源として表示されるか

利用と引用も同じではありません。生成 AI は、あるページから得た情報を回答へ反映していても、そのページを出典として明示しない場合があります。逆に引用が表示されても、そのページが回答へ大きく寄与しているとは限りません。

前述のレビューも、可視性を単一の量として扱わず、発見可能性・文脈内での露出・引用・顕出性・事実の吸収・忠実性・行動/経済的成果という複数の成分に分けたベクトルとして定義しています。同レビューは、業界が「可視性」という語で少なくとも 9 種類の異なる量を指していると指摘しています。

引用は最終ゴールではない

Web メディアにとって引用は重要です。しかし企業サイトでは、引用されるだけで売上につながるとは限りません。

「法人向け勤怠管理サービスには A 社、B 社、C 社があります」という回答で自社が情報源として引用されることと、「あなたの会社なら B 社が最適です」と推薦されることは違います。

主に関係する用語：AEO / GEO / LLMO

5. 推薦 — 候補として薦められるか

ここから、情報源として使われる段階から、選択肢として評価される段階へ変わります。

必要になるのは「何者なのか」だけではありません。AI が比較できるように、誰向けか、価格、強み、弱み、対応地域、機能、制約、適さないケースを具体的にする必要があります。

「誰に向かないか」を書く

推薦は広告コピーとは性質が違います。

「あらゆる企業に最適なサービスです」はコピーとしては使えても、比較材料としての情報量がありません。「10 名以下の企業には機能過多です。50〜500 名規模で複数拠点を持つ企業に向いています」は、AI にも人間にも判断材料を与えます。

ただしこれは「向いていない顧客を書けば AI 推薦率が上がる」という普遍的なランキング要因が証明されたという意味ではありません。SILVE はこれを Decision-useful Information Principle として扱い、効果が確認された施策とは区別します。

主に関係する用語：AIEO / AIO / LLMO / GEO

6. 選択 — AI が実際に選ぶ

推薦では「この 3 社がおすすめです」と AI が候補を示し、最終的に人間が選びます。選択では「この条件ならこれを選びます」とエージェント側の判断が強くなります。

2026 年現在、この変化はショッピング領域で具体化しています。OpenAI は 2026 年 3 月、ChatGPT の商品探索を拡張し、予算・好み・条件を会話で指定しながら商品を探索し、価格・レビュー・機能を並べて比較できる体験を公開しました。同時に Agentic Commerce Protocol を商品探索へ拡張しています。

ここでは Web ページだけでなく、商品、バリエーション、価格、在庫、機能、ユーザーの制約といった比較可能なデータが問題になります。

推薦リストに入る条件と、最終的に選ばれる条件は同じとは限りません。

主に関係する用語：AIEO / AAO / ACO

7. 行動 / 取引 — AI が実際に動けるか

ここで Web サイトは情報源ではなく、エージェントが使うインターフェースになります。

Google の 2026 年の公式ガイドは本体に「Explore agentic experiences」という節を持ち、AI エージェントを「予約や商品仕様の比較など、人の代わりにタスクを実行できる自律システム」と説明しています。さらにブラウザエージェントが、スクリーンショットなどの視覚的レンダリングの解析・DOM 構造の検査・アクセシビリティツリーの解釈を通じてサイトへアクセスし得るとしています。

ただしこれは一般的なブラウザエージェントの挙動の説明であって、Google 自身のエージェントがそうすると宣言したものではありません。また 3 つの経路は列挙であって優先順位ではありません。

つまり、人間には押せるボタンでも、エージェントにはボタンだと理解できない実装があり得ます。SILVE はこの領域を 2026.08.3 で診断に追加しました。

ここから先はコンテンツ SEO とは別の問題になる

エージェントが予約するなら、空き状況・日時・人数・キャンセル条件が要ります。EC なら商品 ID・バリエーション・価格・在庫・配送・返品・カート・決済が要ります。

文章を AI 向けに書き換えるだけでは解決しません。 Web デザイン、アクセシビリティ、商品データ、API、コマース基盤、業務オペレーションまで広がります。

2026 年の実際

Google は Universal Commerce Protocol を、AI Mode や Gemini からエージェント的な行動を可能にする標準として公開しました。「商品データは Merchant Center、取引は UCP」と二分はできません。 Google 自身の解説は UCP の capability として checkout のほかに product discovery（リアルタイムの在庫確認や価格）を挙げており、商品情報の取得もプロトコルの範囲に入ります。一方で Google の実装に参加する条件は有効な Merchant Center アカウントを持ち、チェックアウト対象の商品を提供していることであり、既存のフィードが不要になるわけでもありません。

正確には、Merchant Center のフィードが引き続き商品データの基盤であり、UCP がチェックアウトなどの取引機能とリアルタイムの商品情報の取得を標準化する、という関係です。

OpenAI も 2026 年 3 月に ACP を商品探索へ拡張しました。ただし同じ発表で、初期の Instant Checkout が販売者に十分な柔軟性を提供できていなかったとして、販売者自身のチェックアウトを使えるようにし、OpenAI 側は商品探索に注力すると述べています。

「エージェント型コマース = AI がすべて自律的に購入する世界」と単純化すべきではありません。

そして重要な公式記述があります。ACP を実装しても商品が自動的に AI エージェントへ掲載されるわけではありません。各プラットフォームが独自に参加方法を管理します。取引できること（Capability）と選ばれること（Visibility）は別問題です。

主に関係する用語：AAO / ACO

用語と段階の対応

この表は「その用語が主に捉えようとしている段階」であって、用語の定義ではありません。

用語の多くは定義が割れています。定義が割れている用語を 1 段階へ確定的に割り当てると、我々が用語レコードで意図的に開けておいた曖昧さを黙って閉じることになります。だから留保を併記します。

AIO のスコアを作らない理由も、このモデルなら説明できる

AIO は AI 環境全般の最適化を指す傘語として使えます。しかし範囲が広すぎるため、「AIO 対策はできていますか」と聞いても何を意味するのか分かりません。発見なのか、引用なのか、推薦なのか、エージェントの操作なのか。

だから SILVE は AIO Score を作りません。用語への準拠度ではなく、具体的な段階の準備状態を測るほうが説明できるからです。

用語ごとのスコアを大量に作らない理由

新しい名称が登場するたびに GEO Score、AEO Score、LLMO Score と数字を増やす誘惑があります。しかし同じ underlying signal が複数の名称に重複します。

crawlability は SEO / AEO / GEO / LLMO のすべてに関係します。entity clarity は LLMO / AIEO / AAO にまたがります。semantic HTML は検索・アクセシビリティ・エージェント操作の 3 つに関係します。

名称ごとにスコアを作ると、同じシグナルを何度も別名で採点することになります。SILVE はシグナルを 1 度だけ評価し、必要に応じて複数の段階へ写像します。

準備状態 ≠ 可視性（Visibility） ≠ 成果（Outcome）

段階とは直交する軸として、次の 3 つを分けます。

これを混ぜないことが重要な理由は、問題の場所がまったく違うからです。

• 技術スコアは高いが AI 回答に一度も出ない → 準備状態は高いが可視性が低い
• よく引用されるが流入が来ない → 可視性はあるが成果が低い
• ChatGPT で商品が推薦されるが、在庫データが古く購入できない → 選択の可視性 はあるが 取引の準備状態 が低い

1 つの「AI 対応度」だけでは、この 3 つを区別できません。

この 3 レイヤーをどう測るか、2026 年に各プラットフォームが何を公開したか、そして「増えた」と「増やした」をどう分けるかは、AI 検索の成果はどう測るか — 準備状態 / 可視性 / 成果を混ぜないで扱っています。

SILVE の診断は、いま 7 段階のどこを測っているか

ここが最も実務的な部分です。現在の診断項目（27 項目、配点対象 23 項目、実効重み 91）を 7 段階へ割り当てると、こうなります。

合計は実効重み 91 に一致します（35 + 27 + 13 + 4 + 0 + 0 + 12）。同じ項目を複数の段階に数えてはいません。 1 項目は 1 段階にだけ割り当てています。

つまり SILVE は現在、配点の 68%（91 のうち 62）を段階 1〜2 に置いており、段階 5 と 6 は 1 項目も測っていません。

これは欠陥ではなく現在地です。そして測っていないことを測っていないと書くのが、この表の目的です。「AI 対応度 38 点」という 1 つの数字では、この構造は絶対に見えません。

段階 5・6 を測るには、価格・対象者・制約・比較可能な属性といった推薦と選択のための情報を決定論的に検出する必要があります。確立していないのは「推薦されやすさ・選ばれやすさをサイト側から決定論的に評価する一般的な基準」です。 個別の仕様（商品フィードの必須項目、UCP や ACP の要件など）は公開されており、それらを満たしているかは検出できます。できないのは、それが推薦や選択の確率をどれだけ動かすかを公式仕様から導くことです。空欄を埋めるために根拠の薄い項目を足すことはしません。

どこまで対応する必要があるのか

全企業が AAO や ACO を今すぐ実装すべき、という話ではありません。

• ニュース・メディア — 発見 / 取得 / 利用 / 引用が重要。行動 / 取引は多くの場合そうではない
• BtoB SaaS — 引用に加えて推薦 / 選択が重要。トライアルや商談予約をエージェントが担うようになれば行動も
• EC — 原則として 7 段階すべて。特に商品識別・価格・在庫・バリエーション・チェックアウト
• 店舗・ホテル・飲食店 — 推薦と選択が非常に重要。予約エージェントが普及すれば Action Readiness も

判断基準は「自社の顧客導線のどこまで AI が仲介し始めているか」です。

改善は「どこで詰まっているか」から決める

「引用されない」という問題があっても、原因が引用の段階にあるとは限りません。

そもそもページが取得されていなければ取得の問題です。情報が曖昧で回答に使えないなら利用の問題です。実際には使われていて出典リンクだけ出ていない可能性もあります。

「引用を増やしたいので FAQ を追加する」のような短絡的な施策ではなく、パイプラインのどこで脱落しているかを見る必要があります。

新しい用語が出てきたら

これから「○○ Optimization」という言葉はまだ増えます。そのたびにゼロから対応を始める必要はありません。SILVE は次の手順で扱います。

1. 起源を確認する
2. 操作的定義を確認する
3. 7 段階のどこに対応するかを分類する
4. 新しい測定可能なシグナルが本当に存在するかを検証する
5. 既存シグナルの改名だけならスコアを追加しない
6. プラットフォーム公式仕様または十分な根拠がある場合のみ Methodology へ採用する

実例：AXO

執筆時点で AXO という略語が使われ始めています。ただし現時点では保留の扱いです。

確認できた範囲で、AXO は少なくとも 3 つの異なる対象を指しています。Web コンテンツ側の最適化を指す用法、AI エージェント自体の挙動の最適化を指す用法、そしてコンタクトセンター製品のカテゴリ名（Agentic Experience Orchestration）としての用法です。命名者は確認できていません。プラットフォーム公式文書での使用も、確認した範囲では見つかりませんでした（探索経路は限定的なので、存在しないという主張ではありません）。

さらに、Web 最適化を指す用法の定義は実質的に GEO の言い換えであり、AXO が固有の概念であるという根拠は確認できませんでした。

上の手順の 5 に該当する可能性が高い、というのが現時点の評価です。削除ではなく、この注記付きで保留します。

段階を増減する条件

7 段階は固定ではありません。次のいずれかが起きたら見直します。

• ある段階の中で、事業者の打ち手がはっきり 2 つに分かれると分かったとき（分割）
• 2 つの段階に対して、事業者の打ち手も観測方法も同一だと分かったとき（統合）
• どの段階にも入らない新しい到達段階がプラットフォーム公式仕様として現れたとき（追加）

用語が増えたことは段階を増やす理由になりません。 少なくとも今回検証した 8 用語では、その多くが既存の段階と重なっていました。用語一般についての主張ではありません。

まとめ

AI 検索最適化は、1 つの「AI 順位」を上げる作業ではありません。

SILVE は発見 → 取得 → 利用 → 引用 → 推薦 → 選択 → 行動 / 取引の 7 段階で整理します。このモデルから見ると、各用語が主に捉えようとしている領域が分かります。

• これは SILVE の操作モデルであって、業界標準でも実装アーキテクチャでもありません
• 用語の歴史は一本道ではなく、ツリー状に分岐しています
• 名称ごとに別々のスコアを作る必要はありません。同じシグナルの二重採点になります
• 準備状態と可視性と成果は別物です。同じスコアへ加算しません
• SILVE は現在、配点の 68% を段階 1〜2 に置いており、段階 5・6 は測っていません

新しい「○○ Optimization」が増えても、企業がゼロから対応を始める必要はありません。その言葉が 7 段階のどこについて、新しい根拠や新しいインターフェースを提示しているのかを確認すればよいのです。

名前が増えただけでは、測るべきものは増えません。変わるのは、AI がこのパイプラインのどこまでを担うようになるかです。新しいプロトコルやインターフェースが現れれば、測るべきものは増えます。 増える理由になるのはそちらであって、名前のほうではありません。

Framework Record

この記事の判断を、あとから検証できる形で記録したものです。本文の結論（Core Rules）と、SILVE が内部で持つ記録の項目、参照した一次資料が入っています。

Framework Name: AI Information-to-Action Pipeline Version: Methodology 2026.08.45 Status: SILVE Operational Model（業界標準ではない） Last Verified: 2026-08-13

Stages

1. 発見 — Can the system find it?
2. 取得 — Does the system retrieve it for the relevant task?
3. 利用 — Does the system use the information in its response?
4. 引用 — Does the system attribute or link to the source?
5. 推薦 — Does the system present it as a suitable option?
6. 選択 — Does the system choose it under the user's constraints?
7. 行動 / 取引 — Can the system successfully act or transact with it?

Measurement Layers

準備状態 — 観測可能なシグナルで参加準備を裏づけられるか（決定論的。診断の対象） 可視性 — 実際に参加が起きたか（非決定的な観測値） 成果 — 下流の事業成果が生まれたか（外部 Analytics）

Core Principle: 準備状態 ≠ 可視性 ≠ 成果

Current Coverage（2026-08-12）

段階 1: 35 / 段階 2: 27 / 段階 3: 13 / 段階 4: 4 / 段階 5: 0 / 段階 6: 0 / 段階 7: 12 （配点対象 23 項目、実効重み合計 91。合計は 91 に一致する。1 項目を複数の段階に数えていない）

Scoring Policy

用語ごとの独立スコアを原則として作らない。underlying signal を 1 度だけ評価し、必要に応じて複数の概念・段階へ写像する。

Revision Policy

段階の分割・統合・追加は、事業者の打ち手または観測方法が変わったときにのみ行う。用語の増加は段階を増やす理由にならない。