Search Consoleのパフォーマンスレポートには、長いあいだ「ウェブ」という1つの検索タイプしかありませんでした。それが「ウェブ：テキストベース」と「ウェブ：マルチモーダル」の2つに分かれました。Google は2026年9月に検索セントラルのブログで発表し、パフォーマンスレポートと生成AI機能レポートの両方にこの切り替えが入っています。
増えたのは数字そのものではなく、切り分け方です。これまで「ウェブ」の中に混ざっていた、カメラや画像から始まった検索の表示とクリックを、別のまとまりとして取り出せるようになりました。言い方を変えると、分かれる前の「ウェブ」の数字は2種類の合算でした。期間を比べるときに、この前提が変わったことを知らないままだと、増減の原因を取り違えます。
そして、切り出せるようになった側には検索語のデータがありません。入力が画像なので、キーワードの一覧が出てこないのです。この記事では、Google のヘルプと公式ドキュメントの記載だけを使って、何が分かれたのか、何が取れないのか、API との間に何の差が残っているのか、そして素材を持っているサイト側が先に何を決めておくべきかを順に整理します。記載が見当たらなかった項目は、推測で埋めずに最後の節へ残しました。
分かれたのは「検索タイプ」の1行
変わったのは、レポートの上にある「検索タイプ」のフィルタです。ヘルプに載っている説明を、該当する分だけ並べます。
| 検索タイプ | ヘルプが説明している範囲 |
|---|---|
| ウェブ：テキストベース | 標準の Google 検索バーに入力されたテキストのクエリから来た検索トラフィック |
| ウェブ：マルチモーダル | 画像を使って検索したとき（スマートフォンのカメラなど）の検索トラフィック。Google レンズ、Android の Circle to Search、アップロードした画像、Chrome の画像検索から始まったものが含まれる |
| 画像 | Google 画像検索のタブに表示された結果 |
| 動画 | Google 動画検索のタブに表示された結果 |
| ニュース | Google ニュースのタブと、ニュースの検索結果に表示されたもの |
ここで押さえておきたいのは、「画像」と「ウェブ：マルチモーダル」は別のまとまりだということです。「画像」は Google 画像検索のタブに出た結果で、「ウェブ：マルチモーダル」は画像を手がかりに始まったウェブ検索の結果です。レンズで商品を写して出てきた結果からサイトへ来た読者は、後者に入ります。画像検索の数字だけを見ていても、その動きは見えません。
もう一つ、入口の性質が違う点も実務では効いてきます。テキストベースの検索は、読者が言葉にできた状態から始まります。マルチモーダルの検索は、言葉にできていない状態から始まります。目の前にある商品や看板、送られてきた写真を、そのままカメラや画像で投げているわけです。検索語が無いのは、データの不備ではなく、入口の性質そのものです。
画像から始まった検索には、検索語が無い
いちばん大きな制約は、次元の側にあります。
ヘルプの次元の説明には、マルチモーダルの検索はほとんどが画像を使っているため、テキストのクエリのデータが取れないこと、その結果としてこの検索タイプを選ぶとクエリの次元が使えなくなることが書かれています。つまり、「どの言葉で見つかったか」の一覧が出ません。残るのは、ページ、国、デバイス、日付といった軸です。
これは、ふだんのSEOの進め方をそのまま持ち込めないという意味になります。検索語を見て、そこから見出しや本文を直し、また検索語を見る、という回し方ができません。代わりに、どのページが画像経由で見つかっているのかを見て、そのページに写っているもの、置いてある画像、周辺の文章を点検する、という順序になります。入口が画像である以上、手当ての対象も画像とその周辺になります。
それから、合算の扱いです。レポートの画面で検索タイプを切り替えられるようになったことと、過去にさかのぼって2種類が分かれて見えることは、別の話です。前者はヘルプに書かれていますが、後者について確認できる記載はありませんでした。どこまで遡って比較できるかは、実際に自分のプロパティで期間を動かして確かめるのが確実です。
前の期間との比較を人に説明するときは、「どちらの検索タイプの数字か」を先に書くだけで、議論の半分が減ります。Search Console の数字と自社の解析ツールの数字が合わない理由についてはSearch ConsoleとGA4の使い分けでも扱っていますが、今回の分岐は、Search Console の内側で前提が変わった例です。
生成AI機能レポート側にも、同じ分岐が入った
検索タイプの分岐は、生成AI機能レポートにも入っています。ここは取れるものがさらに限られているので、混ぜないように整理しておきます。
ヘルプによれば、生成AI機能レポート（検索）が持っているのは表示の指標だけです。クリック、掲載順位、CTR、検索語はありません。対象として挙がっているのは AI Overviews と AI モードで、Search Labs の実験は含まれないと明記されています。次元はページ、国、日付、デバイスで、表の行数の上限は通常のパフォーマンスレポートと同じだと説明されています。
この面で検索タイプをマルチモーダルに切り替えると、画像から始まった検索のAI面での表示が見えます。ただし、見えるのは表示だけです。クリックが取れない面の数字を、成果の増減として読まないでください。表示が増えたことと、読者がサイトへ来たことは別の事実で、このレポートは前者しか持っていません。
AI面での見え方そのものについては、Google の公式ドキュメントが、AI Overviews や AI モードに出るための追加の要件や特別な最適化は必要ないと書いています。この点はAI Overviews（AIによる概要）とSEOでも扱いました。今回のレポートの分岐は、出るための条件が変わったという話ではなく、見えるようになった数字の切り分けが変わったという話です。ここを混ぜると、画像の手当てをAI面の対策として説明してしまうことになります。
APIは、まだ分かれていない
実務でつまずきやすいのが、画面と API の差です。
Search Console API のリファレンスで、検索タイプを指定する type に挙がっている値は discover、googleNews、news、image、video、web です。確認日の時点で、テキストベースとマルチモーダルを分ける値は記載がありませんでした。web は検索の「すべて」のタブに絞る既定値として説明されています。
これが何を意味するかというと、画面とエクスポートでは分けられるのに、API を前提に組んだ自動レポートでは分けられないということです。社内のダッシュボードを API で作っている場合、そのダッシュボードの「ウェブ」は合算のままです。画面で見た数字と突き合わせると、合わないように見えます。壊れているのではなく、分岐がまだ API 側に無いだけです。
やっておくべきことは単純で、ダッシュボードの説明に「この数字は合算である」と書き足しておくことです。ついでに、画像経由の内訳を見たいときは画面からエクスポートする、という手順も同じ場所に残しておきます。あとで誰かが数字の不一致を見つけたときに、調査が1往復で終わります。
なお、Search Console が測れる範囲は、ここ1年ほどで何度か広がっています。SNSや動画の投稿を対象にしたプラットフォームプロパティもその流れで、測れる面が増えるたびに「どの面の数字か」を書き添える必要が出てきます。
素材を持っているサイト側が、先に決めておくこと
ここから先は、公表されている内容から言える範囲での実務の話です。効果を約束できる手順ではありません。順序だけが決められます。
1つ目は、検索タイプを固定して記録することです。画面の設定は見る人ごとに変わります。レポートを共有するときは、どの検索タイプで見た数字かを本文に書きます。合算の増減だけを見て施策を決めないための、いちばん安い予防策です。
2つ目は、画像から見つかっているページを特定して、そのページの画像を点検することです。検索語が出ないぶん、見る対象はページになります。公式の画像SEOのドキュメントは、画像を関連する文章の近くに置くこと、ページの内容や画像のタイトル・キャプションから主題を読み取っていること、意味のある代替テキストを書くこと、短く説明的なファイル名を使うこと、見つかっていない画像は画像サイトマップで伝えられること、srcset や picture で複数の大きさを用意すること、鮮明な画像のほうが読者に好まれることなどを挙げています。カメラから始まる検索の入口は画像なので、手当ての対象も同じ場所になります。
3つ目は、面ごとの期待値を分けて持つことです。生成AI機能レポートは表示だけ、マルチモーダルは検索語なし、API は合算のまま。この3つの制約は、どれも「取れない」という事実であって、工夫で埋められるものではありません。取れないものを埋めようとして推測の数字を足すより、取れる軸で判断する範囲を決めておくほうが早く、あとから説明もできます。
確認できなかったこと
記載が見当たらなかった項目を残します。まず、マルチモーダルの内訳です。レンズ、Circle to Search、画像のアップロード、Chrome の画像検索のどれから来たのかを分けて見る方法は、確認できた記載の中にありませんでした。入口ごとの構成比は分かりません。
次に、過去のデータの扱いです。分岐が入る前の期間について、どこまで遡って2種類が分かれて見えるのかは確認できませんでした。ここは自分のプロパティで期間を動かして確かめる範囲です。
最後に、API の対応予定です。type の一覧に分岐が加わる時期について、リファレンスに記載はありませんでした。したがって、現時点で自動化できるのは合算の取得までで、内訳は画面とエクスポートから取る前提で設計するのが安全です。
全体を1行でまとめると、見えるようになったのは入口の違いで、分からないままなのは言葉のほうです。検索語を見て直す作業の外側に、画像から見つかる経路が別の数字として現れた、という段階だと読むのが正確です。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。
あわせて読みたい
Search ConsoleでSNSと動画の検索流入が見えるようになった意味 GoogleはSearch Consoleのプラットフォームプロパティを全世界へ展開しました。TikTokやInstagramの投稿が検索でどう見られているかを測れる仕組みと、実務での使い道を整理します。
AI生成かを誰でも照合できる。SynthID Detector世界公開の読み方 GoogleがSynthID Detectorを英語で世界公開しました。透かしで何が言えて何が言えないのか、面ごとに違う条件と、素材を受け取る側の手順を一次情報から整理します。
GoogleがタグとTag Managerを統合。ノーコードのイベント計測も始まる Googleがタグ関連の変更を公開しました。Google tagがTag Managerのコンテナとして扱われる件と、コードを書かずに購入コンバージョンを設定できる視覚的タグ設定について、ヘルプの記載の範囲で整理します。