ほとんどのチームには、すでに Google の順位レポートがあります。Search Console の「検索パフォーマンス」タブをクリック数で並べ替え、スクリーンショットを撮ってスライドに貼ったものです。そこには順位が写っています。何が変わったのか、なぜ変わったのか、誰が何をすべきなのかは写っていません。
このワークフローは、それを一度の作業で解決します。クエリのセットを決め、Codex にレポートの契約を文章で渡し、あとは毎週同じ形のレポートを出させるだけです。最初の構築に約 90 分。以降の実行は 10 分未満です。
ワークフロー全体。生の書き出しを入れ、決まった形のレポートを一つ出し、最後に人が一度判断する。
完成するもの
対象読者: サイトのレポート作成を担当し、すでに Search Console へのアクセスがある方。開発者である必要はありませんが、Codex が読める場所にファイルを置ける必要があります。
完成時に手元にあるもの: 保存されたレポートテンプレート、Codex が毎回従う指示ファイル、そして実際の 1 週間分のレポート 1 本です。
前提条件: 確認済みの Search Console プロパティ、本当に気にしている 20〜50 件のクエリ一覧、プロジェクトフォルダにアクセスできる Codex、そして上級版を試すなら自社サイトのリポジトリへの読み取り権限です。
完了の定義: SEO をやっていない人にレポートを渡して、その人が「見るべきクエリはこの 3 つで、理由はこうだ」と言える状態。
所要時間: 最初の構築に約 90 分、以降は 1 回 10 分未満。
「検索パフォーマンス」レポートが順位レポートでない理由
Search Console が返すのは 4 つの列です。クリック数、表示回数、CTR、平均掲載順位。これは計測表であって、順位レポートではありません。順位レポートは別の問いに答える必要があり、2026 年のシグナルはその隔たりを以前より広げています。
2026 年 9 月 9 日に公開された Zyppy の専門家調査は、131 名の実務者から 13,665 件のデータ点を集めました。クリックと行動のシグナルは 29.4%、ブランドのシグナルは 27.0%、テクニカル SEO の健全性は 17.5% でした。テクニカル健全性より上位に来た 3 つのシグナルのうち 2 つは、掲載順位の列には見えません。これらの数字が何を変えるかについては別の実践ガイドで扱っていますが、レポート作成に関して言えばこうです。順位だけを載せたレポートは、いちばん動かなかったシグナルについて報告していることになります。
そこが Codex の埋める隙間です。Google が何かを変えた理由を教えてはくれません。ただ、その変化をあなたが説明できる程度に一貫した形で証拠を組み上げてくれます。
始める前の 4 つの決定
何かを書く前に決めてください。あとから変えるとレポートを作り直すことになります。
- クエリのセット。 20〜50 件を、ビジネスの考え方に合う 2〜3 のバケットに分けます。「プロダクト」「比較」「サポート」のほうが「高ボリューム / 中ボリューム / 低ボリューム」より役に立ちます。
- 比較する期間。 直近 28 日とその前の 28 日を比べます。短いとノイズが多く、長いと探している変化が隠れます。
- しきい値。 報告に値する変化を決めます。5 順位以上動いたクエリ、あるいはクリックが横ばいなのに表示回数が 30% 以上動いたクエリ、あたりが無難な初期値です。
- 保存場所。 フォルダは一つ、命名規則も一つ。
reports/ranking/YYYY-MM-DD.mdと、生の書き出しを置くdata/サブフォルダ。Codex には一貫した書き込み先が必要です。
ステップ 1: 生データを書き出す
Search Console を開き、プロパティを選び、「検索パフォーマンス」へ進みます。期間を 56 日に設定すると、1 回の書き出しから 28 日対 28 日の比較ができます。あとは「エクスポート」ボタンで「クエリ」タブの CSV を落とします。
「ページ」でも同じことをし、モバイルとデスクトップの内訳を報告する予定なら「デバイス」でも行います。
期待される出力: data/ に 3 つの CSV ファイル。ファイル名に書き出し日を入れます。
品質チェック: 「クエリ」の CSV を開き、データの先頭行が「anonymous」という語を含むクエリでないことを確認します。Search Console は件数の少ないクエリを伏せるので、そのままだとレポートに名前のない変動として現れます。
うまくいかないとき: 書き出しが途中で切れているなら、期間が行数上限に対して広すぎます。28 日ずつに分けて書き出し、連結は Codex に任せてください。
ステップ 2: レポートの契約を書く
このワークフローが 3 週目以降も生き残るかを決めるのがこのステップです。契約は Codex が毎回読むファイルに置きます。プロジェクト直下の AGENTS.md、あるいはレポートフォルダ内の専用の指示ファイルです。
契約に必要なのは次の 5 つだけで、それ以外は要りません。
契約の項目 | 書く内容 | なぜ重要か |
|---|---|---|
入力 | ファイルの正確なパスと期間のルール | エージェントが期間を勝手に作るのを止める |
しきい値 | あなたの基準を数値で | 表を意思決定に変える |
出力の形 | 3 つのセクションをこの順で | 30 週目を 1 週目と比べられるようにする |
確度のルール | データが説明できないときにどう書くか | 自信満々の出まかせを防ぐ |
境界 | エージェントがやってはいけないこと | 信頼できるまで読み取り専用に |
実際に動く版はこんな形です。
## 順位レポートの契約
入力: data/queries-*.csv, data/pages-*.csv
期間: 直近 28 日とその前の 28 日。両方の日付をレポートのヘッダーに明記する。
報告するのは次の 3 つだけ:
1. 動いたクエリ: 5 順位以上動いたもの、クリックが横ばいで表示回数が
30% 以上増えたもの、またはトップ 10 から外れたもの。
2. 推定される説明: ファイル内のデータだけを使う。ファイルで説明できなければ
「このデータでは説明できない」と書く。
3. 来週の確認: フラグの立ったクエリごとに 1 行、確認すべきページや
クエリを名指しする。
データ上で指し示せない原因は書かない。サイト変更を提案しない。
reports/ranking/ の外のファイルは一切編集しない。期待される出力: 指示ファイル 1 つ。コミットするか、データの隣に保存します。
品質チェック: 契約を音読してください。どの行も、手を入れずに別のサイトに当てはまるなら、何も縛れないほど曖昧です。
うまくいかないとき: Codex がセクションを増やし続けるなら、出力の形が具体的でありません。3 つの見出しを、そのまま使いたい文言で指定してください。
レポートの構成。使用したファイルを並べたフッターは、レビューする人がいちばん信頼する部分であり、ほとんどのテンプレートが省いている部分でもあります。
ステップ 3: 最初のレポートを生成する
Codex にフォルダを指定し、契約に沿ってレポートを 1 本作るよう頼みます。チャットの返答ではなくファイルを求めてください。そうすればレビューも差分の確認もできます。
最初の実行で、自分のデータが実際どんな形をしているかが分かります。2〜3 回の修正は見込んでおいてください。これは普通のことですし、ワークフロー全体でいちばん安上がりな部分でもあります。
期待される出力: reports/ranking/YYYY-MM-DD.md。ヘッダー、3 つのセクション、使用したファイルを並べたフッターが付きます。
品質チェック: フラグの立ったクエリを 2 つ選び、Search Console で数字を手で確認します。一致すればパイプラインは健全です。一致しなければ、そこで止めてデータのステップを直してください。壊れた入力を土台に分析をデバッグしてはいけません。
うまくいかないとき: 最も多い失敗は、書き出しと契約の日付のずれです。毎回ヘッダーに両方の日付を固定してください。2 日のずれが、横ばいの月を崩壊に見せかけるのを防げます。
僕が最初に作った版は、ほとんど何も動いていない週に 11 件の「動いたクエリ」を報告しました。契約は問題なく、書き出しのほうが問題でした。30 日分のファイルを 28 日の窓と比べたことで、2 日分の欠損がサイト全体の崩壊に見えたのです。いまの契約は 2 つの期間が一致しなければ実行を拒否しますし、あの失敗は再発していません。
ステップ 4: エージェントに書けない一行を足す
どのレポートにも、人の文章が一段落入ります。先週なにを出し、変え、壊したかです。
これは飾りではありません。自分のリリースをアルゴリズム更新のせいにするエージェントを捕まえる、いちばん速い方法です。レポートが「プロダクトページ群が下落した」と言い、あなたのメモが「火曜にテンプレートを変えた」と言っていれば、説明の候補は即座に絞られます。
期待される出力: レポート冒頭に 2〜3 文、人が書きます。
品質チェック: メモと変動セクションが矛盾していたら、その矛盾がレポートでいちばん価値のある一行です。丸めずに残しておいてください。
ステップ 5: 送る前に検証する
レポートを手放す前に、次の 3 つを確認します。
- 日付。 両方の期間がヘッダーに書かれ、書き出しと一致しているか。
- スポットチェック 2 件。 フラグの立ったクエリ 2 つを手で確認したか。
- 矛盾チェック 1 件。 主張した説明が、末尾のファイル一覧にないデータを参照していないか。
3 つとも通れば、共有して安全です。これはあなたの判断の下書きであって、判断の代わりではありません。
慣れてきたら使う上級ルート
まず 4 週間、手作業で回してください。同じ種類の間違いを 2 度直してから、はじめて自動化します。
そのうえでの拡張は段階的に進めます。
- 実行をスケジュールする。 週次の定時実行にすれば、ノート PC を開く前にレポートができています。人の書く段落を必須項目にして、それが無いレポートは出せないようにしてください。
- スナップショットをバージョン管理に置く。 実行のたびに 1 コミットになります。2 週間分の差分は、どちらのレポートより速く読めます。
- 2 つ目のプロパティを足す。 競合やブランドのクエリは、本体に混ぜず、同じ契約の別レポートにします。
- 外部シグナルを 1 つ足す。 ブランド検索やシェア・オブ・アンサーの確認を入れると、2026 年調査のブランドシグナルが理論ではなく計測可能になります。
自動化しないほうがよいもの: 提案のステップです。エージェントがサイト変更を提案し始めた瞬間、あなたはレポートから公開へ移っており、レビューの負担は節約できた時間より速く増えます。
トラブルシューティング
症状 | 考えられる原因 | 対処 |
|---|---|---|
どのクエリも下落して見える | 書き出し間の期間のずれ | 契約とヘッダーの両方に期間を固定する |
レポートが空になる | あなたのトラフィック量に対してしきい値が厳しすぎる | 順位のしきい値を緩める前に、表示回数のしきい値を下げる |
毎週同じ 5 クエリしか出ない | クエリのセットが狭すぎる | ロングテールと比較系のクエリをバケットに足す |
説明のつかない変動がある | 低ボリュームのクエリでは普通のこと | 「このデータでは説明できない」という出力のまま先へ進む |
数字が Search Console と合わない | 書き出しのプロパティかフィルタの不一致 | 毎回同じプロパティと同じフィルタで書き出す |
ワークフローを維持する
1 四半期を越えて役に立ち続けるには、3 つの習慣を保ちます。
クエリのセットは四半期ごとに見直す。 昨年の優先事項を追いかけているレポートは、順位レポートではなく歴史の授業です。
Search Console が変わったら契約を読み直す。 Google は「検索パフォーマンス」の画面と書き出しのフィールドを定期的に更新します。フィールドが消えたら、その日のうちに契約を直してください。
古いレポートを残す。 今四半期のレポートを昨年の同じ四半期と比べることが、本当の下落と季節性を安く見分ける唯一の方法です。
よくある質問(FAQ)
Codex でないとだめですか? いいえ。ファイルを読み、スケジュールで動き、レビューできる形で出力を書けるエージェントなら何でも動きます。サイトがすでにリポジトリにあるなら Codex は好適です。レポートが差分の取れるコミットになるからです。
無料のツールだけでできますか? できます。ワークフロー全体が無料の Search Console データとエージェントだけで動きます。有料の順位トラッカーが要るのは、競合の順位や自分のプロパティでは見えない順位が欲しいときだけです。
Search Console の「検索パフォーマンス」レポートと何が違うのですか? あちらは表を見せます。このワークフローは判断を出します。どのクエリがしきい値を越えたか、データが説明できることとできないこと、来週なにを調べるか。加えて記録が残りますが、画面のほうには残りません。
サイトのトラフィックがごく少ない場合は? 表示回数のしきい値を下げ、直近 28 日ではなく昨年の同じ 28 日と比べてください。低トラフィックのサイトは、前週比より前年同期比のほうがシグナルが多く取れます。
AI Overview や AI 引用をレポートに入れるべきですか? 入れたければ、専用の契約を持つ独立したセクションとして足してください。順位レポートには混ぜないこと。情報源も計測方法も違い、混ぜるとどちらも読みにくくなります。
執筆: Leo Harrington、Auspia にて 500 件以上の経営層向けレポートを手がける SEO アナリティクス・トランスレーター。専門外の人でも行動に移せるレポートへ検索データを変える方法を書いています。
