AI Alchemy Lab始動:AIとの対話で学びを「資産」に変える実験場 AIとの対話を続けていると、毎日のように新しい気づきや発見がある。...
検索AIは「何を聞かれたか」で引用先を変える:4種類のクエリで試してみた
検索AIは「何を聞かれたか」によって引用するサイトの種類を劇的に変える。同じテーマでも問いの立て方次第で企業メディア・SNS・公式ドキュメントの比率が大きく変わることが、4パターンのクエリ実験で確認できた。
この記事でわかること
- Perplexityは4種類のクエリパターンで引用元ドメインの構成を大きく変える
- 「ペイン解決」クエリではSNSが約42%を占めるという予想外の結果が出た
- 目視観察の限界と、次回Python解析への接続
なぜ検索AIの引用先を観察しようと思ったのか
本記事はAI Alchemy Labの第2回レポートです。前回は「なぜClaude Codeを諦めてDifyを選んだのか」というツール選定の経緯をまとめた。
今回の出発点は、AIエージェントを構築する過程で浮かび上がった素朴な疑問です。「検索AIはそもそも、どのサイトをどんな基準で引用しているのか」。マーケターとして、SEO(検索エンジン最適化)の概念をAI時代のGEO(生成AI最適化)へアップデートする必要性を感じていた私は、まず手を動かして観察することにした。
検索AIにおける「引用」とは、AIが回答の根拠として提示するWebサイトのリンクのことです。いくら良いコンテンツを作っても、AIに無視されてしまえばマーケターとして意味がありません。運用フェーズに入る前に、まず「AIはどこから情報を取ってくるのか」という基礎的な観察から始めることにした。

実験の設計:4種類のクエリパターンを選んだ理由
実験の目的は、AIが回答を生成する際にどのような意図で引用元を選択しているか、その傾向をあぶり出すことだ。
マーケターが日常的に直面するクエリの種類を整理すると、大きく4つのパターンに分類できる。
引用元分類の定義
本実験では引用元を以下の5種別に分類している。
- 企業メディア:企業のオウンドメディア・テックブログ・マーケティング系ポータル
- SNS:X(旧Twitter)・LinkedIn・Reddit等のソーシャルプラットフォーム
- 公式ドキュメント:ツール開発元の公式サイト・APIリファレンス
- 技術者ブログ:QiitaやZennなど開発者向けプラットフォームの記事(SNSとは別枠)
- 個人ブログ:上記に分類されない個人発信のWebメディア
QiitaやZennはユーザー生成コンテンツという点ではSNSと性質が近いですが、本実験では「技術的な知見の共有を目的としたプラットフォーム」として別枠で扱う。
4つのクエリパターン
- 直接比較クエリ(パターンA):「AとBの違いや保守性の比較は?」
- ペイン解決クエリ(パターンB):「〜で挫折しやすいポイントや解決策は?」
- トレンド・事例クエリ(パターンC):「〜の導入背景や企業事例は?」
- 技術・保守性クエリ(パターンD):「〜の選ばれる理由やメリット・デメリットは?」
使用ツールと観察条件
使用ツールはPerplexityです。各パターンにつき1回ずつクエリを投げ、回答に含まれる引用元URLをドメイン種別に分類・集計した。なお今回は各1回の観察であるため、統計的な有意性は担保されていない。これは本実験の限界として後述する。
パターンA(直接比較):企業メディアが10件中7件を占めた
観察結果
直接比較クエリでは、10件の引用元のうち7件(70%)が企業メディアという結果になった。
- 企業メディア:7件(70%)
- SNS:1件(10%)
- 公式ドキュメント:1件(10%)
- 個人ブログ:1件(10%)
実際に投げたクエリ
実際に投げたクエリは「AIエージェントの運用において、LLM(Claude 3.5 Sonnetなど)を直接コーディングで制御・調整する手法と、Difyを活用してプロンプトやワークフローをオーケストレーションする手法では、実装後の保守性やマーケティング施策の変更への適応力にどのような違いが出ますか?」である。
考察
「比較」という文脈において、AIは企業が提示する客観的な仕様や構造化された比較データを優先して引用する傾向があった。個人の主観的な意見より、網羅性と正確性を重視しているのではないかという仮説が立てられる。
パターンB(ペイン解決):SNSが12件中5件に達した
観察結果
ペイン解決クエリでは、12件の引用元のうち5件(41.7%)がSNSという結果になった。
- 企業メディア:7件(58.3%)
- SNS:5件(41.7%)
- 公式ドキュメント:0件
- 技術者ブログ:0件
実際に投げたクエリ
実際に投げたクエリは「非エンジニアのマーケターがAIエージェントを自作しようとした際、プログラミングベースのAI開発ツール(Claude Codeなど)で挫折しやすいポイントや壁は何ですか?また、Difyを導入することで、その課題はどのように解消されますか?」である。この結果を見たとき、私は驚きを隠せなかった。他のパターンと比べてSNSの比率が突出していたからだ。
考察
「挫折」「壁」という感情ワードを含むクエリに対して、AIは公式ドキュメントではなくSNS上のリアルな体験談を多く引用していた。公式の「完璧なマニュアル」より、同じ失敗を乗り越えた先人の知恵が求められていると判断した可能性がある。GEOにおいて「共感」の要素が引用判断に影響する可能性を示唆する結果である。
パターンC(トレンド・事例):企業メディアが13件中12件を占めた
観察結果
トレンド・事例クエリでは、13件のうち12件(92.3%)が企業メディアという結果になった。
- 企業メディア:12件(92.3%)
- 個人ブログ:1件(7.7%)
- SNS・公式ドキュメント・技術者ブログ:0件
実際に投げたクエリ
実際に投げたクエリは「最近のBtoBマーケティング領域において、Difyなどのノーコードツールを使った自律型AIエージェントの導入が進んでいる背景を教えてください。また、従来のプログラミングベースの開発からDifyへ移行・活用している具体的な企業事例や、その乗り換え理由はありますか?」である。
考察
トレンドという文脈では、AIは「情報の鮮度」と「権威性」を持つ企業メディアを大半の引用元として選んでいた。個人がこの領域で引用されるためには、単なる意見や考察ではなく、独自の調査データや一次情報の提示が必要になると考えられる。
パターンD(技術・保守性):公式ドキュメントと技術者ブログが計78.6%
観察結果
技術・保守性クエリでは、14件の引用元のうち公式ドキュメントが7件(50%)、技術者ブログが4件(28.6%)を占め、合計で78.6%に達した。
- 公式ドキュメント:7件(50%)
- 技術者ブログ(Qiita・Zenn等):4件(28.6%)
- 企業メディア:3件(21.4%)
- SNS:0件
実際に投げたクエリ
実際に投げたクエリは「マーケティング業務を自動化するAIエージェントの開発において、Claude Codeのようなターミナルベースのコーディング型AIではなく、Difyのようなノーコード・ワークフロー構築ツールが選ばれる理由は何ですか?それぞれのメリット・デメリットを比較して教えてください。」である。
考察
技術的な文脈では、AIは「公式が正解、技術者コミュニティは補足」という明確な階層構造で引用元を選んでいる傾向があった。QiitaやZennが技術者ブログとして独立した存在感を示しており、SNSとは異なる引用ロジックが働いていると考えられる。
4パターンを比較してわかった「クエリの法則」
4回の観察結果を整理すると、以下の傾向が見えてくる。
|
クエリパターン |
主な引用元 |
上位占有率 |
AIが重視する指標(推測) |
|
直接比較 |
企業メディア |
70%(7/10件) |
客観的なスペック・構造化データ |
|
ペイン解決 |
SNS+企業メディア |
SNS42%(5/12件) |
感情への共感・リアルな体験談 |
|
トレンド・事例 |
企業メディア |
92%(12/13件) |
情報の鮮度・権威性 |
|
技術・保守性 |
公式ドキュメント+技術者ブログ |
計79%(11/14件) |
手順の正確さ・一次情報 |
キーワードよりも「問いの性質」が、AIの引用先を決定する可能性があります。「AI 活用」という同じキーワードでも、それが「比較」なのか「悩み」なのかによって、引用されるサイトの種類は大きく変わる。
この発見はコンテンツ作成者に何を意味するのか
今回の観察から暫定的に言えることは、「問いの設計がGEOの第一歩になりうる」ということだ。
ペイン解決を狙うなら感情に訴える失敗談を含める、技術系クエリを狙うなら公式に準じた正確な情報を提示する、といった方向性が見えてくる。ただしこれはあくまで4回の観察による仮説であり、確定的な結論ではない。
今回の実験の限界
今回の実験には以下の限界がある。
- サンプル数の少なさ:各パターン1回ずつの観察であり、統計的な有意性はない
- AIの変動性:検索AIの回答は時間帯・モデル更新・地域によって変化する
- テーマの偏り:今回はAI開発ツール(Dify・Claude)というBtoB技術領域のみの観察である
- 分類の主観性:ドメイン種別の分類に筆者の判断が入っており、客観的な基準ではない
次の実験へ:Pythonで引用構造を数値化する
目視・手動での観察には明確な限界があることがわかった。次回は、Pythonを用いて引用元URLのドメイン構造を自動抽出・データベース化し、より大規模な解析を試みる。「どのような構造のサイトが、どのようなクエリで引用されやすいのか」という問いに、コードの力で迫ることにする。