競争環境を分けるアーキテクチャの違い

すべてのAI検索プラットフォームが同じ構造で動いているわけではありません。市場で優位に立つには、それぞれのプラットフォームがどのような思想で設計されているのかを理解する必要があります。

Google：検索基盤に統合された検索拡張型AI

GoogleのAIによる概要とAIモードは、検索バーに追加された別アプリではありません。既存の検索基盤に組み込まれた検索拡張型のレイヤーであり、長年磨かれてきたインフラにGeminiが統合されています。

Googleに送られた検索クエリは、5つの処理段階を通ります。

1. クエリ理解：意味解析によってキーワードの一致を超え、ブランドや場所といったエンティティを特定します。同時に、その質問がAIによる回答に適しているかも判断されます。


2. 質問の分解と同時並行探索（Fan Out）：1つの質問を複数のサブクエリに分解し、価格比較やレビュー、仕様など、ユーザーがまだ聞いていない内容まで同時に探索します。


3. 複数ソースからの情報取得：数十億のWebページ、知識グラフ、動画字幕などを横断し、各サブクエリに最適な情報の断片、チャンク（Chunk）を取得します。


4. 集約とフィルタリング：重複を排除し、経験・専門性・権威性・信頼性を基準に情報を絞り込みます。要約に組み込みやすいチャンクが優先されます。


5. 大規模言語モデルによる統合：Geminiが検証された情報を受け取り、それらを自然で一貫した文章にまとめ上げます。

AIによる概要は検索を起点とした検索拡張生成として機能し、引用を付けながら検索結果ページ上で直接回答を提示します。AIモードはより対話的な体験で、次に必要となる情報まで先回りして提示します。

Googleにおいては、信頼性と引用実績が重要であり、情報密度の高いコンテンツが優先されます。

ChatGPT：ライブ取得によるリアルタイム統合

Googleが巨大なWebインデックスを保持しているのに対し、ChatGPTはライブ取得（Live Fetch）の思想で動いています。モデル自体は静的なデータで学習されていますが、現代のWeb全体を内部に保持しているわけではありません。

ユーザーが質問を入力すると、ChatGPTは複数の検索クエリを生成し、それらを外部インデックスに送信します。主にBingですが、Googleや独自ソースも含まれます。その後、有望なURLの候補を取得し、それらのページ本文をリアルタイムで取得します。

この構造では、回答に含まれるかどうかは、「その瞬間に取得できるかどうか」に依存します。

以下のような取得の阻害要因がある場合、ChatGPTの視点では存在しないのと同じ状態になります。

• robots.txtによる制限：OAI-SearchBotをブロックしている場合、引用されません。


• JavaScriptによる非表示：クライアントサイドレンダリングによって後から表示される情報は取得されない可能性があります。


• 表示速度の遅さ：応答が遅い場合、取得処理がタイムアウトします。


• 意味の不透明さ：見出しや本文が曖昧であったり、画像に依存している場合、必要なテキストが抽出できません。

ChatGPTで勝つためには、技術的に透明なサイト構造が必要です。軽量で解析しやすいHTMLで、重要な情報を明確に提示することが求められます。このパイプラインでは、最も速く、最も明快な情報のチャンクが引用されます。

Microsoft Copilot：従来検索と生成AIの統合モデル

Microsoft Copilotは、従来の検索エンジンに生成AIを組み合わせた構造であり、Bingのランキング基盤の上に構築されています。

そのため、従来のSEOシグナルは依然として重要です。検索結果で上位に入らなければ、回答の根拠となる情報群に含まれることはありません。

Copilotの特徴は、Microsoft 365との統合にあります。Word、Excel、Teamsの中で利用されるため、商品データがそのまま業務の文脈に取り込まれる可能性があります。

たとえば、購買担当者がExcel上で複数の商品を比較するような指示を出すと、商品データがそのまま表として整理されることがあります。

Copilotで勝つためには、表やリストに変換しやすい構造が重要です。仕様情報が文章の中に埋もれている場合、引用されにくくなります。

Perplexity AI：引用を前提とした発見エンジン

Perplexityは、検索エンジンとして始まり、その後に大規模言語モデルを組み込んだ発見エンジンです。

特徴は、生成されるほぼすべての文章に引用が付く点です。情報源が明示されることが前提となっています。

そのため、特定のテーマにおいて、最も権威性の高い情報源であることが重要になります。引用されること自体が前提となるプラットフォームです。

回答生成の共通基盤：大規模言語モデル

ここまで見てきたように、各プラットフォームの構造は異なりますが、その中心には大規模言語モデルがあります。

大規模言語モデルは、単語（トークン）の関係性に基づく統計的な確率構造を学習した予測エンジンです。データベースのように事実を保持しているわけではありません。

顧客が商品について質問すると、モデルは事前学習によって取り込まれたデータをもとに答えを組み立てます。

このとき、事前学習データが古い場合、最新の情報が反映されないというリスクがあります。新しい商品や最近の店舗情報が含まれていない場合、古い情報に基づく推測や、もっともらしい誤った内容が生成されることがあります。

最新情報を接続する仕組み：検索拡張生成

この課題を補うのが、検索拡張生成（Retrieval-Augmented Generation、RAG）です。RAGは、大規模言語モデルとWebサイト上の最新情報をつなぐ役割を果たします。

大規模言語モデルを試験を受ける学生にたとえると、RAGがない場合は記憶だけに頼る状態です。RAGがある場合は、教科書を持ち込める試験のような状態になります。

1. 情報の取得：ユーザーの質問に対して、インデックスとしてのWebサイトから、関連性の高い意味単位の情報であるチャンクを探します。


2. 情報の補強：取得したチャンクをコンテキストとしてモデルに渡します。


3. 生成：モデルは、その事実のみに基づいて回答を生成します。

この構造においては、関連性設計が重要になります。Webサイトの内容が分かりにくかったり、AIにとって読み取りにくい構造である場合、必要な情報が取得されません。

次回予告

主要なプラットフォームに自社ブランドを信頼できる情報源として選んでもらうためには、自分たちをナレッジアーキテクトとして捉える必要があります。次回の記事では、GoogleのAIによる概要のアーキテクチャと処理フローをさらに詳しく見ていきます。

著者：プロフィール

Pavel Zaslavsky（パベル・ザスラフスキー）

イスラエル工科大学（Technion）MBAプログラムにて、eコマース分野を教える講師。 現在は、LISUTO Israel のゼネラルマネージャーとしても、EC向けグローバルコンテンツAIの開発および事業統括を担っている。eBayおよびShopping.comにて、グローバル規模のカタログオペレーション構築を主導した実務経験を持ち、大学教育と現場実装の両面からオンラインリテールの進化とAI活用を研究・実践している。
20年以上にわたり、ECプラットフォーム、商品検索、商品カタログ管理、コンテンツ最適化といった領域において、実務と研究の双方に携わってきた。現在は、日本とイスラエルの共同スタートアップであるLISUTO株式会社のイスラエル拠点責任者（General Manager）としても、EC事業者向けコンテンツAIソリューションの企画・開発・グローバル展開を統括している。これまでにeBayにてグローバルカタログオペレーションの創設者兼責任者を務め、世界各国のマーケットプレイスを横断する商品データ基盤を構築。 また、Shopping.com（eBayグループ）では、ヨーロッパ全域のカタログオペレーションを立ち上げ、運用モデルを確立した。その後も複数の大手EC多国籍企業においてアドバイザーとして参画し、商品データ設計、検索品質改善、業務オペレーションの高度化を支援。 大学教育と実務の両面から、オンラインリテールにおけるAI活用とEC運営の進化を発信している。

LISUTOおよびAIタッガーについて

LISUTO株式会社は、EC事業者向けに商品コンテンツを最適化するグローバルAIソリューションを提供する、日本・イスラエル発のスタートアップです。主力ソリューションである「AIタッガー」は、商品データを自動解析し、検索、レコメンド、業務効率の改善に直結する高品質なタグ情報を生成するコンテンツAIです。大学で教えられているeコマース理論と、グローバルECの現場で培われた実務知見を融合した設計により、人手依存や表記揺れといった商品データ運用の構造的課題を解消し、EC運用の再現性とスケーラビリティを高め、継続的な改善を可能にしています。楽天市場、Yahoo!ショッピングなど、複数のECプラットフォームに対応しており、商品点数やカテゴリ規模を問わず導入できます。

■関連資料
AIが変えるECの未来を解く AI検索と構造化データへの対応戦略 2025
【AIタッガー】SEO×AI検索時代の“見つかる力”を最大化