順位計測レポートのAI設計｜任せる範囲と人が見る3つの観点

「先月の順位レポート、AIに作らせておいて」。そう言われてデータを渡し、きれいなグラフが返ってくる。ここまでは、もう珍しい光景ではなくなりました。

問題はその次です。返ってきた資料に「順位が落ちています」と書かれていたとき、それをそのまま社内へ回してよいのか。落ちたように見えているだけなのか。分かれ目はAIの賢さではなく、渡す前にどんな前提を確かめたかにあります。

この記事では、Search Consoleの公式仕様のうち、AIが読み違えやすい前提を先に並べます。そのうえで、任せてよい工程と、人が抱えたままにする工程の線を引きます。新しいツールを増やす記事ではなく、渡し方を変えるための記事です。

本記事で参照した公式仕様は、2026-08-08に公式ヘルプとリファレンスを開いて確認したものです。答える役として鈴木さん、聞き手として若葉さんと高梨課長に登場してもらいます。

01順位計測レポートのAI設計は、SEOの現場で何から決めればいいんですか？

若葉さん

若葉さんの発言

順位計測レポートって、もう全部AIに作ってもらってもいいんでしょうか。

鈴木さん

鈴木さんの発言

作る工程は任せられます。ただ、その前に「渡す数字がどういう性質のものか」を人が確かめる工程だけは残ります。そこを設計と呼んでいます。

結論から書きます。順位計測レポートづくりでAIに任せられるのは、データの取得・整形・グラフ化という作業工程です。任せてはいけないのは、データの土台に関する前提の確認です。

なぜ前提の確認だけが残るのでしょうか。Search Consoleの検索パフォーマンスデータには、まれなクエリの除外や、集計上の内部制限があるからです（出典: Google（Search Console ヘルプ））。手元に届いた数字は、起きたことの全部ではありません。

ここを飛ばすと何が起きるか。そろっていないものを、そろっていると思って読むことになります。足りない部分は、グラフの上ではへこみとして現れます。そのへこみを「順位が落ちた」と読んでしまう。これが、この分野でいちばんよく見る事故です。

AIはこの前提を自分から疑いません。渡された表を、渡されたとおりに読みます。だから設計の第一歩は、プロンプトの言い回しではなく、どのデータに、どんな注記を添えて渡すかを決めることになります。

02順位計測レポートで使うデータは、SEO担当が何を見ておくものなんですか？

順位計測レポートの元データは、Search Consoleの検索パフォーマンスレポートです。既定では過去3か月分のクリック数とインプレッション数が表示されます（出典: Google（Search Console ヘルプ））。指標は4つあります。

言葉として難しいものはありません。だからこそ、定義を書かずにAIへ渡してしまいがちです。ところが「平均掲載順位」は、最上位のものを平均した値という定義を持っています。1つのページが複数の言葉で拾われているとき、この定義を知らないまま読むと、実感と数字がずれます。

高梨課長

高梨課長の発言

指標の定義まで、いちいち指示文に書くんですか。工数が増えませんか。

鈴木さん

鈴木さんの発言

一度書けば、そのまま使い回せます。むしろ定義を書かないと、出てきた文章を毎回人が疑う羽目になるので、そちらのほうが高くつきます。

既定の期間についても同じことが言えます。過去3か月という初期状態のまま画面を眺めていると、「昨年と比べてどうか」という問いには答えられません。期間を動かすのは人の判断です。ここをAIに丸投げすると、画面の初期値がそのまま結論の前提になります。

03指標と集計の単位がそろっていないと、AI活用の順位計測レポートはどう狂うんですか？

データをグループ化する軸のことをディメンションと呼びます。画面の上では6件のタブから選べます（出典: Google（Search Console ヘルプ））。

• クエリ
• ページ
• 国
• デバイス
• 検索での見え方
• 日付

ここに落とし穴があります。集計方法はディメンションによって異なります。クエリ・国・デバイス・日付は、プロパティ単位で集計されます（出典: Google（Search Console ヘルプ））。一方、ページや検索での見え方は、ページ単位で集計されます。

同じ画面から出した2つの表でも、数え方の物差しが違う。 この違いを知らずに単純に突き合わせると、合計値が一致せず「データがおかしい」という誤解が生まれます。おかしいのはデータではなく、足し合わせ方のほうです。

AIに「この2つの表を統合して」と頼むと、素直に統合します。物差しが違うことは、表の見た目からは分かりません。だから人が、どの軸とどの軸を並べてよいかを先に決めておきます。

04検索タイプを書かないと、生成AIは順位計測レポートをどう取り違えるんですか？

もう1つ見落としやすいのが検索タイプです。レポートはウェブ・画像・動画・ニュースという検索タイプでフィルタできます（出典: Google（Search Console ヘルプ））。

指示文に検索タイプを書かないと、既定のウェブ検索だけの数値を「サイト全体の数値」として扱ってしまう恐れがあります。画像検索や動画検索からの流入が多いサイトでは、ここが致命傷になります。手元の数字は正しいのに、指している範囲が違うからです。

生成AIに要約させるときも同じです。要約は「渡された表の中」でしか行われません。画像検索のタブを開いていないことは、渡された表からは読み取れません。範囲の宣言は、人が言葉にして添えるしかない情報です。

05順位計測レポートの取得と整形は、どこまでAI活用に任せていいんですか？

ここからは、任せてよい側の話です。Search Console API（Search Analytics: query）を使うと、順位計測レポートの取得を自動化できます（出典: Google Search Central）。リクエストの主なパラメータは次のとおりです。

{
  "startDate": "2026-07-01",
  "endDate": "2026-07-31",
  "dimensions": ["query", "page", "date"],
  "rowLimit": 5000,
  "dataState": "final"
}

このAPIでグループ化に使えるディメンションは7件です（出典: Google Search Central）。内訳はcountry・device・page・query・searchAppearance・date・hourです。画面のタブより1つ多く、時間帯という軸を持っている点が違います。

任せてよい作業を、具体的に並べます。

• 期間の指定（startDate・endDateは必須）
• グループ化するディメンションの選択
• クエリ・ページ・国・デバイスでの絞り込み（フィルタ）
• 取得件数（rowLimit）とページ送り（startRow）の指定
• クリック数降順（日付グループ化時は日付昇順）での並び替え
• 取得結果をシートやダッシュボードへ流し込む整形作業
• 週次・月次といった定期取得のスケジューリング
• 前週・前月との単純な差分計算

ここまでの8項目は、仕様が明文化されており、機械的に再現できる作業です。手順が文章になっているものは、任せてよい。 これがいちばん分かりやすい線引きです。

高梨課長

高梨課長の発言

差分計算まで任せていいんですね。そこは判断が要るのかと思っていました。

鈴木さん

鈴木さんの発言

引き算そのものは作業です。判断が要るのは、その差を何のせいにするかという段階からです。

任せられないのは、この先の「データの意味」を読み解く部分です。差が出たという事実と、差が出た理由は別の話です。境目はここに引きます。

06AIが古いパラメータを出してきたとき、SEO担当は何を見ればいいんですか？

仕様そのものが変わることもあります。Search Console APIのリファレンスには、FAQのリッチリザルトが検索結果に表示されなくなる予定が明記されています（出典: Google Search Central）。同時に、APIの検索での見え方（searchAppearance）でのFAQサポート自体も終了が予告されています。

ここが、AIに任せる設計でいちばん静かに壊れるところです。AIは過去の学習データをもとに、すでに役目を終えたパラメータ名を提案してくることがあります。書き方としては自然で、動くように見える。けれど、その項目は消える予定になっている。

若葉さん

若葉さんの発言

それって、エラーが出ないから気づけないということですか。

鈴木さん

鈴木さんの発言

そうです。だから実装の前に、公式リファレンスの最新版を人が開き直す工程は省けません。ここは自動化の対象外だと決めておくほうが安全です。

AIの知識には、「いつ時点のものか」という賞味期限があります。 これは能力の問題ではなく、学習という仕組みの性質です。仕様が動く領域では、一次情報を開く担当を人に固定します。

07順位計測レポートのAI設計で、SEOのデータ欠落はどこに現れるんですか？

ここから、人が確かめる観点を1つずつ見ていきます。1つ目は、データの欠落と匿名化です。

Search Consoleのパフォーマンスデータは、ユーザーのプライバシー保護のため、一部のクエリを表示しません。実行回数が非常に少ないクエリや、個人情報・機密情報を含むクエリは記録されないことがあります（出典: Google（Search Console ヘルプ））。

さらに注意が必要なのは、匿名化されたクエリだけが除外されるわけではない点です。内部的な制限により、保存されるデータ行は上位のものに限られます（出典: Google（Search Console ヘルプ））。表には最大1,000件までしか表示されず、それ以上を見るにはSearch Console APIの利用が必要です。APIのrowLimitも1件から25,000件までという上限付きです（出典: Google Search Central）。

つまり、グラフ全体の合計とクエリ別表の合計が一致しないのは、多くの場合バグではなく仕様です。AIがこの仕様を知らずにレポートを作ると、「ロングテールのクエリまで全部そろっている」という誤った前提でグラフを描いてしまいます。

人が確かめるのは2点です。表示件数が上限に達していないか。除外されたクエリがどの程度の規模か。 この2点を注記として添えれば、同じデータでも読み方が変わります。

08順位計測レポートは、SEOの数字としていつまで遡れるんですか？

2つ目の観点は、期間の扱いです。

Search Consoleのデータは16か月分が保持されます。アナリティクスと連携した場合も、表示されるのは最大16か月分です（出典: Google（アナリティクス ヘルプ））。年をまたぐ前年同月比の順位計測レポートを作る場合、この保持期間の上限を超えていないか確認が要ります。

Search Consoleに収集されたデータは、収集から48時間後に利用可能になります（出典: Google（アナリティクス ヘルプ））。直近数日のデータは暫定値であり、後から変動する可能性があります。締め切りの都合で直近まで含めたくなりますが、そこは確定値を待つ判断のほうが安全です。

09期間とタイムゾーンのズレは、SEOの数字にどう効いてくるんですか？

日付の基準にも注意点があります。検索パフォーマンスレポートは、日ごとのデータをカリフォルニア州の現地時間で記録しています（出典: Google（Search Console ヘルプ））。Google アナリティクス（GA4）は自社のローカルタイムゾーンでデータを表示するため、同じ「1日」の区切りが両者でずれます。

Search Console APIの日付パラメータも、太平洋時間（UTC-7または8）を基準に指定する仕様です（出典: Google Search Central）。日本時間との時差を踏まえずにAPIへ日付を渡すと、意図した日と1日ずれたデータを取得してしまいます。

若葉さん

若葉さんの発言

時計が3つあるようなものですね。

鈴木さん

鈴木さんの発言

そのとおりです。時計が3つある部屋で待ち合わせをするなら、どの時計で話しているかを先に言う。それと同じことをレポートでもやります。

AIに日次データの突き合わせを指示すると、この時差は無視されます。日付という列が同じ形をしているからです。形がそろっていることと、意味がそろっていることは別だと、人が知っている必要があります。

10順位計測レポートの原因分析を、生成AIに一問一答で任せてよいんですか？

3つ目の観点は、変動要因の重なりです。

順位の変動要因は、多くの場合1つではありません。季節性・Googleのアルゴリズム変更・自社の施策が、同じ週に重なって現れることがあります。AIに「順位が下がった原因」を一問一答で答えさせると、この重なりを1つの原因に単純化しがちです。

なぜ単純化されるのか。問いの形が、答えの形を決めているからです。「原因は何ですか」と1つ尋ねれば、返ってくるのは1つです。問いを「重なっている可能性のある要因を並べてください」に変えるだけでも、出力の質は変わります。

アルゴリズム変更の有無は、公式のステータスダッシュボードで確認できます。ダッシュボードの読み方そのものは、更新の追い方を扱った記事で開始日と所要期間の見方を解説しています。順位変動の時期とアップデートの実施時期が重なっているかどうかは、原因を1つに断定する前の最初の確認事項です。

自社施策の影響を切り分けるには、施策の実施日を記録した台帳とレポートを突き合わせる工程が要ります。この突き合わせは、施策日の一覧というAIが知らない社内情報を人が渡さない限り、AIだけでは実行できません。

高梨課長

高梨課長の発言

つまり、台帳を作っていない会社は、そもそも切り分けができないということですか。

鈴木さん

鈴木さんの発言

厳しい言い方になりますが、そうなります。逆に言えば、いつ何をしたかを1行ずつ書き残すだけで、AIに渡せる材料が一気に増えます。

11自動チェックに合格した図解が崩れていた話は、AI活用に何を教えていますか？

本誌自身の制作記録にも、同じ構造の教訓があります。

図解の自動検査は、フォントサイズ・文字数・図形数・縦横比を検査します。しかし、図形どうしの重なりは検査対象に入っていません。全項目に合格した図解が2枚ありました。それでも画像化して目視すると、図形とラベルの重なりが見つかり、座標を修正した記録が残っています（自社実測・2026-08-08確認）。

ここから引ける教訓は1つです。自動チェックの合格は、そのチェックが定義した範囲の中でだけ正しい。 合格は「問題が無い」の証明ではなく、「検査した項目には問題が無い」の証明です。

順位計測レポートの自動チェックにも、同じ構造の死角があり得ます。数字の欠損チェックに合格しても、その数字がどの範囲のものかは検査されていないかもしれません。人が確認する観点を、機械チェックの項目だけに委ねないことが重要です。

12順位計測レポートでつまずくのは、SEO現場のどこですか？

実務でよく見かける誤解を整理します。

並べてみると、共通点が見えます。どれもきれいに出てきた数字を、そのまま信じたところでつまずいています。

順位計測レポートの信頼性は、AIの出力精度だけでなく、渡す前提データの正しさに左右されます。仕様の確認を省いた自動化は、見た目のきれいなレポートほど誤りに気づきにくくなります。整った資料は、それだけで正しそうに見えてしまうからです。

13順位計測レポートのAI設計を、SEOチームでどう定着させますか？

最後に、チームで回すための形にします。設計は、人の記憶ではなくチェックリストに置いておきます。

• 検索パフォーマンスレポートの4つの指標（クリック数・インプレッション数・CTR・平均掲載順位）の定義をAIへの指示に明記した
• クエリ別・ページ別など、ディメンションごとに集計方法が異なることを確認した
• 表示件数がUI・APIそれぞれの上限に達していないか確認した（前セクション参照）
• まれなクエリや機密性の高いクエリが除外され得る前提を、レポートの注記に含めた
• Search ConsoleとGA4のタイムゾーンの違い（カリフォルニア時間とローカル時間）を確認した
• APIへ渡す日付パラメータが太平洋時間基準であることを確認した
• データ保持期間の上限を超える期間比較をしていないか確認した（前セクション参照）
• 直近数日のデータが暫定値である前提で、確定値が出るまで待ってから確定レポートを作成した
• 順位変動があった週に、アルゴリズム更新の実施記録と自社施策の実施記録を突き合わせた
• AIが出した一問一答的な結論を、人が複数要因の重なりを疑って再確認した

このリストは、誰か1人の頭の中にあるうちは設計ではありません。指示文のテンプレートと同じ場所に置いて、レポートを出すたびに開く。 そこまでやって、はじめて仕組みになります。

高梨課長

高梨課長の発言

リストが長いと、結局読まれなくなりませんか。

鈴木さん

鈴木さんの発言

なので、上から順に全部を毎回やる必要はありません。定義・上限・時計の3か所だけを固定の入口にして、残りは気になったときに開く。それでも事故はかなり減ります。

14よくある質問

15まとめ｜今日やる3つのこと