Google検索は、まずWebサイト全体をクロールしてインデックスを作成し、ユーザーの検索時に順位を比較します。一方、AIエージェントの動き方は異なります。質問を受け取ってから検索キーワードや取得するページを判断し、内容を読み込んだうえで、その場で回答を組み立てます。自社コンテンツが回答に採用されるかどうかを左右するのは、MCP、ツールコール、そしてエージェント検索がコンテンツへアクセスする仕組みの3点です。
この変化がもたらす影響は明確です。従来の検索順位であれば、8位のページにもクリックする人はいます。しかし、エージェント検索が一度に読むのは通常5〜10ページに限られ、その先まで順番に見てくれるわけではありません。読まれなかったページに次の機会はなく、引用にも入りません。問うべきことは「何位に表示されるか」から、「機械がその場で自社ページを取得し、内容を正確に理解できるか」へと変わっています。
エージェント検索：回答はその場で組み立てられる
Perplexity、ChatGPT search、Claude、GoogleのAIモデルは、基本的に似た方法で動作します。ユーザーから質問を受けると、エージェントはまず複数のサブクエリに分解し、それぞれを検索します。取得したリンク群から数ページを選んで実際に本文を読み、最後に、その内容を出典付きの回答へまとめます。重要なのは、読むタイミングです。数か月前のキャッシュされたインデックスではなく、その時点で取得した本文を読みます。昨日ページを更新したばかりでも、正しく取得され、明確に読み取れる状態なら、今日の回答に引用される可能性があります。反対に、検索順位がどれほど高くても、取得時に中身が空なら意味はありません。エージェントが読めないページは、存在しないも同然です。
MCP：AIと自社データをつなぐ共通コネクター
MCPはModel Context Protocolの略で、Anthropicが2024年末に公開したオープンプロトコルです。その後、OpenAIやGoogleなども順次対応しました。MCPが解決しようとしている課題はシンプルです。従来、AIアプリケーションを外部データソースへ接続するには、サービスごとに個別の連携機能を開発する必要があり、コストも保守負担も大きくなっていました。MCPは、この接続方法を標準化します。さまざまな機器を1つの規格でつなぐUSB-Cのような役割です。MCPサーバーを用意し、データや機能を標準形式で提供すれば、MCPに対応するどのエージェントからも接続・照会できるようになります。
ブランドにとって、MCPはこれまでになかった情報提供経路を開きます。商品カタログ、リアルタイムの価格、在庫、技術文書など、更新頻度が高く正確性を求められるデータをMCPサーバー経由で直接照会できるようにすれば、エージェントはWebページの記載内容を推測したり、3か月前の記事を引用したりせず、自社が管理する一次情報を参照できます。ユーザーがAIに「このソリューションは特定の機能に対応していますか」と尋ねたとき、何度も情報を経由させることなく、自社の管理データから直接回答できるようになります。
ツールコール：エージェントが実際にコンテンツを取りに行く動作
言語モデル自体が常にオンラインで情報を取得しているわけではなく、先週変更した価格を記憶しているわけでもありません。その不足を補うのがツールコールです。モデルは「このキーワード群を検索する」「このURLを取得する」といった構造化リクエストを出力し、外部システムに処理を依頼します。そして、返ってきた結果を取り込んで回答を作成します。検索、Webページのクロール、APIへの照会、MCPサーバーの読み取りは、いずれも裏側で実行されるツールコールです。つまり、自社コンテンツが回答に入るかどうかは、ツールが必要なときにその情報を取得し、正しく解析できるかにかかっています。HTML構造が複雑、主要コンテンツの表示にJavaScriptの読み込みが必要、重要な事実が画像にしか書かれていない――こうしたページは、ツールで取得すると中身が空になりがちです。
ブランドコンテンツを「呼び出せる」状態にする3つのレベル
AIの回答に採用されるには、コンテンツが3つのレベルを同時に満たす必要があります。多くのブランドは、人に見せるための第1段階にしか注力しておらず、残る2段階にはほとんど手を付けていません。
- クロール可能：重要なコンテンツはサーバー側でレンダリングし、JavaScriptの実行後に初めて表示される状態を避けます。セマンティックHTML、明確な見出し階層、リダイレクトを繰り返さない安定したURLを用意し、クローラーが一度で本文を取得できるようにします。
- 解析可能：価格、仕様、対象ユーザー、FAQなどの事実はプレーンテキストで記載し、Schema.orgの構造化マークアップ（FAQPage、HowTo、Product）を追加します。各段落の意味を機械が推測せずに理解できる状態にします。
- 接続可能：価格、在庫、ドキュメントなど、照会頻度が高くリアルタイム性を要する情報は、APIの公開や自社MCPサーバーの構築を検討します。ページの静的なスナップショットを取得させるのではなく、自社が管理する信頼できるデータをエージェントが直接参照できるようにします。
多くのブランドは、どこでつまずいているのか
よくある問題は、コンテンツの質ではなく、人の目だけを前提に設計されていることです。見た目は整っていても、取得すると実行前のJavaScriptしかない。主要な仕様はPDFやインタラクティブフォームの中に隠れている。サイト全体に構造化データがない。同じ質問への答えを見つけるには、公式サイトの3階層メニューを順に開かなければならない。エージェントは、何層もの画面を根気よくクリックしてはくれません。代わりに、要点を1段落で明快に説明している競合の記事を参照します。その結果、自社カテゴリーについての議論でありながら、自社のコンテンツ構造が原因で候補から外れてしまいます。現在AIが自社ブランドに言及しているか、どの情報源を引用しているかを把握するには、Brand Radarのような可視性トラッキングを使うことで、この差を定量化できます。
まずは回答に入っているかを確かめる
見えない課題は改善できません。取り組みを始める前に、3つの問いを確認してください。自社カテゴリーで最もよく聞かれる質問をPerplexityまたはChatGPTに入力したとき、回答に自社ブランドは登場するでしょうか。参照リンクは自社ページでしょうか、それとも第三者のページでしょうか。自社の最重要情報を機械は読み取れるでしょうか。1つでも答えが「いいえ」なら、エージェント検索における可視性に明確な課題があります。課題を体系的に洗い出し、改修の優先順位を付けたい場合は、30分のGEO診断（/contact）をご予約ください。AIの目に自社コンテンツがどう映っているかを一緒に確認します。
