読者の代わりにブラウザが読む — エージェンティック・ブラウザがメディアに突きつける3つの断絶
検索が中間層になった、という話はもう共有されています。次に起きているのは、閲覧そのものが代行されるという変化です。
ChatGPT Atlas、Perplexity Comet、The Browser Company の Dia。いわゆるエージェンティック・ブラウザは、ユーザーの代わりにページを開き、読み、要約し、フォームを埋め、タスクを完了させます。読者がサイトに来ないのではなく、読者の代理人がサイトに来る。この違いが、メディアの事業構造にどう効くのかを整理します。
現時点の規模は小さい
先に規模感を確認しておきます。Digiday が2026年に報じた取材記事のなかで、あるパブリッシャーはこの脅威を「3%の問題」と表現しています。他の課題に比べれば管理可能だ、という認識です。ブラウザ市場全体では Chrome が世界でおよそ70%を占めており、専用のエージェンティック・ブラウザの利用者はまだ限られます。
ですから、今すぐ事業計画を書き換える話ではありません。ただし、準備を後回しにしてよい話でもない。理由は2つあります。
ひとつは、この機能が専用ブラウザに閉じないことです。Google は Chrome に Gemini の機能を組み込みつつあります。専用ブラウザの利用者数を追いかけているうちに、既存ブラウザの標準機能として同じことが起きる可能性があります。
もうひとつは、影響が「流入が減る」という単一の形では現れないことです。以下の3つの断絶は、別々のタイミングで、別々の部署に効いてきます。
断絶1：クリックの断絶
もっとも分かりやすい影響です。エージェントがページを読んで要約を返すなら、読者はページを開きません。検索結果での AI 要約と同じ構造が、ブラウザという最後の砦にまで及ぶということです。
Digiday の記事では、元パブリッシャーで現在は Alvarez and Marsal に所属する Amir Malik 氏が、AI はブラウザベースの Web 体験の衰退を加速させるものであり、消費者の行動は「目的地としてのサイト」から「プロンプトを起点とする経路」へ移ると述べています。
これは既存の議論の延長です。打ち手も既に整理されています。プラットフォーム経由に依存しない読者関係を作ること、要約されて終わらない体験を自社側に置くこと。キメラでもメディア事業の再設計などで扱ってきた論点です。
断絶2：計測の断絶
こちらのほうが、実務上やっかいです。
エージェントによるアクセスは、人間のアクセスと同じ経路で発生します。同じブラウザから、同じユーザーエージェントで、同じようにページを読み込む。従来のボット判定は、こうした「人間の代理として動くクライアント」を想定して作られていません。
結果として、次のような事態が起きます。
- ページビューは記録されるが、その先の行動が起きない
- 平均滞在時間やスクロール深度の分布が、静かに歪む
- 直帰率が上がった原因が、コンテンツの問題なのか、エージェント経由の増加なのか判別できない
計測が歪むことの本当の怖さは、数字が下がることではなく、下がった原因を誤診することです。編集がコンテンツの質を疑い、プロダクトが導線を疑い、実際にはトラフィックの構成が変わっただけ、ということが起こり得ます。
だからこそ、規模が小さい今のうちに、エージェント経由のアクセスを分類できる状態にしておく価値があります。3%のうちに分類の仕組みを作れば、それが10%になったときに慌てずに済みます。
断絶3：広告の断絶
3つ目は収益に直結します。Digiday の記事では、現在の広告システムが人間のトラフィックと AI のトラフィックを区別できない点が指摘されています。LLM に対して広告を配信しても意味がなく、Perplexity の Comet のように広告ブロック機能を内蔵しているブラウザもあります。
IAB Tech Lab の CEO である Anthony Katsur 氏は、エージェンティック・ブラウザを LLM にとってのデータの「トロイの木馬」と表現し、慎重に対応すべきで、これらのブラウザからのアクセスを拒否することも選択肢だと述べています。業界団体のトップが遮断を選択肢として挙げている、という点は記録しておく価値があります。
対処の動きも始まっています。同記事によれば、米欧の少なくとも6社のパブリッシャーが、IAB Tech Lab の Trusted Server の枠組みを試験導入しています。広告配信の処理をサーバーサイドへ移し、ブラウザ側でのブロックの影響を受けにくくする方向です。
ただし業界として統一されたプレイブックはまだない、というのが同記事の結論です。
日本のメディアが、いま準備できること
規模が小さい段階でやっておくと安いものから並べます。
- アクセスログにおけるエージェント判定の準備
まずは分類できる状態を作ることです。エージェンティック・ブラウザ由来のアクセスを、既存の「直接流入」に混ぜたままにしないこと。分類ができていれば、あとから遡って傾向を分析できます。
- 指標の異常を「原因不明」で放置しない運用
滞在時間や回遊率が説明のつかない動き方をしたとき、コンテンツ要因とトラフィック構成要因を切り分けて検証する手順を、あらかじめ決めておきます。これは分析体制の話であり、ツールを入れれば解決する話ではありません。
- 広告配信のサーバーサイド化の検討
すぐに移行する必要はありませんが、自社の広告配信がどこまでブラウザ側の処理に依存しているかは把握しておくべきです。依存度が高いほど、この変化に脆弱です。
- アクセス方針の意思決定を先に済ませる
エージェントのアクセスを許可するのか、条件付きにするのか、拒否するのか。これは技術の問題ではなく事業の判断です。AI クローラーの課金インフラの議論と地続きであり、同じ場で決めるべきです。
私見：問われているのは「代理人に何を見せるか」
エージェンティック・ブラウザを、流入を奪う敵として捉えるだけでは、判断を誤ると考えています。
読者の代理人がサイトに来るという構造は、裏返せば、代理人に対して何を提示するかを設計できるということでもあります。要約されて終わる記事しか置いていなければ、要約されて終わります。会員登録した人だけが使える機能、データベース、継続的な更新、コミュニティ。代理人が持ち帰れないものを自社側に置いているかどうかが、この局面での差になります。
「3%の問題」のうちに考えておく価値があるのは、遮断の設定より、この設計のほうだと思います。