これまで検索は、必要な時に開く場所だった。
知りたい言葉を入力し、並んだリンクから一つを選ぶ。発信側は検索順位を上げ、タイトルと説明文でクリックしてもらうことを競ってきた。
その前提が、もう一段変わろうとしている。
2026年5月、GoogleはSearchに「情報エージェント」を導入すると発表した。利用者が条件を渡すと、エージェントがバックグラウンドで24時間動き、ブログ、ニュース、SNS、金融・買い物・スポーツなどの新しい情報を監視する。条件に合う変化が起きれば、複数の情報源をまとめた更新を届け、場合によっては次の行動まで支援する。
検索は、リンクを探す場所から、変化を見張って知らせる存在になり始めた。
便利になるのは間違いない。しかし、情報を発信する側から見ると、これは検索画面の変更以上の意味を持つ。
人がページを選ぶ前にAIが情報源を選び、要約し、更新を監視する時代に、発信側は何を作るべきなのか。
検索の主語が、人からエージェントへ移る
従来の検索では、利用者が毎回クエリを入力した。たとえば「新しいスマートグラス」「気になる製品の価格」「特定分野のニュース」を、その都度探しに行く。
情報エージェントでは、この反復を機械が引き受ける。Googleの説明では、希望する条件を一度伝えれば、エージェントが継続的に情報を調べ、該当する変化を見つけた時に通知する。
ここで変わるのは、検索の頻度だけではない。
従来は、人が検索結果に並んだタイトル、媒体名、説明文を見比べて、読むページを選んでいた。エージェント型の検索では、その前段でAIが複数のページを取得し、関連性を判断し、内容を合成する。
最初の読者が、人ではなく機械になる場面が増える。
もちろん、最後まで人がページを開かなくなるわけではない。GoogleもOpenAIも、生成回答から元の情報源へ移動できるリンクを用意している。ただ、リンクを開く前に答えの大部分が届く場面は増える。
発信側は「検索結果で目立つか」だけでなく、情報源として選ばれ、正しく引用され、更新時に再確認されるかを考える必要が出てくる。
可視性の単位は、クリックだけではなくなった
この変化を、最も端的に示しているのがBing Webmaster Toolsだ。
Microsoftは2026年2月、AI Performanceを公開プレビューとして追加した。Microsoft CopilotやBingの生成回答などで、自分のサイトのどのURLが引用され、どのような問いの根拠として使われたかを確認できる。
従来のWeb運営で中心だったのは、表示回数、順位、クリック率、流入数だった。そこに「AI回答の中で何回参照されたか」という新しい観測値が加わった。
Microsoftが推奨している内容も興味深い。明確な見出し、表やFAQ、具体例、データと出典、情報の鮮度、文章・画像・動画の一貫性。特別なAI用の呪文ではなく、人にも機械にも意味を取り違えにくい情報設計である。
クリックは今後も重要だ。商品を買う、問い合わせる、実際の画面を見る、筆者の考えを深く読むには、元のページが必要になる。
ただし、クリックだけを見ていると、コンテンツが回答の根拠として使われているのか、別のサイトの説明に置き換えられているのかが分からない。可視性の単位が一つ増えた、と考える方が正確だ。
引用されれば勝ち、でもない
では、AIにたくさん引用されれば、それで成功なのだろうか。
ここも単純ではない。
Google AI Overviewsを対象にした2026年の大規模測定研究では、19カテゴリ、5万件を超えるクエリを40日間追跡し、生成回答を約9万8千の主張へ分解して調べている。その結果、引用されたページで支えられていない主張が11.0％あったと報告された。
これは査読前のプレプリントであり、調査期間、クエリ集合、主張の分解・判定方法に依存する。すべてのAI検索にそのまま当てはめるべき数字ではない。
それでも、重要な問題を示している。
リンクが付いていることと、そのリンクが文章の根拠になっていることは同じではない。
情報源として選ばれても、文脈が削られることがある。条件付きの結論が断定へ変わることもある。複数の情報源が合成され、どの媒体の判断だったかが見えにくくなることもある。
だから発信側に必要なのは、AIへ取り込まれやすくする工夫だけではない。誤読されにくく、引用箇所から元の文脈へ戻りやすい正本を作ることだ。
これからのオウンドメディアは、二層で作る
AI検索時代の発信基盤は、二つの層に分けると考えやすい。
第一層──引用可能な一次情報層
機械がページを発見し、意味を読み取り、現在の状態を確認し、出所へ戻れるための層だ。
一つの意図に対して、一つの正規URLを持つ
記事の題名、著者、公開日、更新日を明示する
重要な主張の近くに、一次資料へのリンクを置く
事実、推論、意見、未確認事項を分ける
更新・訂正した内容を追えるようにする
サイトマップと更新通知を正しく運用する
検索、生成回答への入力、学習の許諾方針を決める
ここでは派手さより、明確さと追跡可能性が重要になる。
第二層──直接関係を持つための層
AIの回答画面を経由しなくても、読者と繋がり続けるための層だ。
RSS
ニュースレターや通知
YouTube、音声、ショート動画
筆者、シリーズ、カテゴリーのアーカイブ
一目で分かるビジュアルと編集上の声
第一層だけでは、機械に理解されやすい資料庫にはなっても、読者が戻りたい場所にはならない。第二層だけでは、魅力的でも検索やAIが現在の正本を見つけにくい。
AIが引用できる正本と、読者が直接戻ってこられる関係。これからのオウンドメディアには両方が要る。
機械に伝わるための、七つの実装
構造化、更新、通知、canonical、根拠、利用条件、観測を一つの配信基盤にする。
1．Article構造化データを持つ
Googleは、記事ページへArticleまたはNewsArticleの構造化データを追加することで、題名、画像、日付、著者などをより明確に理解できると説明している。
これは掲載を保証する裏技ではない。しかし「誰が書いた、いつの、どの記事か」をページの見た目だけでなく機械可読な形でも示せる。
2．更新日時を、正直に扱う
公開日時と更新日時は別物だ。
Bingは、サイトマップのlastmodへ実際の変更日時を入れるよう求めている。サイトマップを生成した時刻で全ページを更新扱いにすると、鮮度の信号は信用されなくなる。
軽微な自動保存で記事の更新日を動かさず、内容が変わった時だけ更新する。これは表示上の作法ではなく、情報基盤の信頼性に関わる。
3．追加・更新・削除を通知する
サイトマップはサイト全体を伝え、IndexNowは個別URLの追加、更新、削除を検索エンジンへ素早く知らせる。
AIが継続監視するなら、古い説明をいつまでも参照されない仕組みが重要になる。公開する機能だけでなく、訂正が伝わる機能までがメディア基盤だ。
4．正規URLを一つにする
同じ内容が、PC版、印刷版、キャンペーン版、転載版として複数のURLに存在すると、どれが現在の正本か分かりにくくなる。
canonical、リダイレクト、一貫したメタデータを使い、引用してほしいページを明確にする。
5．主張と根拠を近づける
記事末尾に参考リンクをまとめるだけでなく、重要な主張の近くから一次資料へ戻れるようにする。条件や例外も同じ場所に置く。
これはAI向けというより、読者が自分で確かめられる記事を作るという基本だ。その基本が、結果として機械の誤読も減らす。
6．crawlerと利用条件を分けて考える
OpenAIは、ChatGPT検索の要約やスニペットへ含めるには、OAI-SearchBotをブロックしないよう案内している。
一方でCloudflareは、検索インデックスへの利用、生成回答への入力、モデル学習を、同じものとして扱わないContent Signals Policyを提案している。
「すべて許す」か「すべて閉じる」かではなく、検索には出したい、生成回答への利用は条件を決めたい、学習には使わせたくない、といった意思を分けて考える必要がある。
ただし、Content Signalsは利用条件の表明であり、それ自体が強制的にスクレイピングを止める技術ではない。必要ならWAFやBot Managementなどの制御と組み合わせる。
7．AI経由の可視性を計測する
ChatGPT経由のリンクには追跡用のUTMが付き、Bing Webmaster Toolsでは生成回答の引用を確認できる。
検索流入が減った、増えた、という総量だけでは判断しない。どの記事が引用されたか。どの問いで参照されたか。そこから実際に読者が来たか。直接購読へ繋がったか。観測点を分ける。
RSSは、なぜ今も古くならないのか
RSSは、AI検索で引用されるための魔法の仕組みではない。
それでも、これからの発信基盤に必要だと思う。
理由は単純で、読者が一度購読すれば、その後の関係を検索順位やAIの選択に毎回委ねなくていいからだ。
さらにRSSは、記事の題名、URL、公開日時、更新、概要、カテゴリーを、再利用しやすい形で配れる。読者向けのRSSリーダーだけでなく、社内の監視、動画化の入口、ニュース収集、通知ワークフローにも使える。
AIエージェントが強くなるほど、すべてを一社のエージェントに委ねるのではなく、自分で選んだ情報源を直接受け取る経路の価値も上がる。
「AIに食わせるための記事」を作らない
ここまで読むと、AIに引用されるために、短い答えを大量に並べ、構造化データを増やせばよいように見えるかもしれない。
それでは順序が逆になる。
必要なのは、AIに食わせるための記事ではない。
人が読んで理解でき、根拠を確かめられ、後から更新できる正本を作る。その正本が機械にも誤読されにくいよう、構造と信号を整える。
Article構造化データも、正確な更新日時も、引用リンクも、訂正履歴も、本来はそのためにある。
検索エンジンの仕様は変わる。AIモデルも入れ替わる。特定の表示枠を狙う小技は、いずれ効かなくなる。
しかし、誰が、いつ、何を根拠に書き、何が変わったかが分かる記事は残る。
発信局は、ページ工場ではなく一次情報基盤になる
AIが情報を集め、要約し、形式を変える時代に、発信組織が同じことを安く速く繰り返しても差は生まれにくい。
発信側が持つべきなのは、継続的に更新される一次情報と、そこから導いた編集判断と、直接戻ってきてもらう関係だ。
記事を正本にする。そこから音声、動画、RSS、SNSへ展開する。更新や訂正は正本へ戻し、各形式へ伝える。AIには探索、整理、形式変換を任せても、何を正しい状態とするかは発信側が持つ。
EDIFORCEの発信局も、この設計で作りたい。
クリックされる記事を否定するのではない。検索にも、AIにも、人にも届く。ただし、どの入口から来ても、最後に同じ根拠と同じ編集判断へ戻れるようにする。
検索がエージェントになるほど、発信側には二つのものが必要になる。引用され、更新を追える一次情報の正本と、AIを介さず読者と繋がれる直接の配信経路だ。
