SEOレポート自動化をAIで試す｜入力・引き継ぎ・修正の実例

毎週、Search ConsoleとGA4を開いて数字を転記し、「なぜ増減したのか」「次に何をするか」を書く。前回の提案を確認する前に、また新しいレポートを作っている。そんな仕事をAIに任せたいなら、数字を集める処理と、数字を読んで判断する担当を分けて作ると始めやすくなります。

最初からGoogle連携や定期配信を全部組む必要はありません。まずは同じ条件の2期間のデータを用意し、AIに一件の報告を作らせ、修正した判断を次の報告へ渡します。

この記事では、架空サイトの数値を使って実際にAIを動かし、初回・次回・データが欠けた回の出力を確かめました。計算は合っていても、改善提案には修正が必要でした。入力、AIの返答、訂正した理由を順に紹介します。

数値はすべて説明用の架空データです。AIの返答は実際の実行結果ですが、顧客の成果や無人の週次稼働を示す事例ではありません。

SEOレポートのどこを自動化したいかで、作るものが変わる

「自動化したい」の中身が、数字の転記なのか、考察なのか、改善の進行管理なのかで必要な仕組みは変わります。

今、減らしたい仕事	最初に用意するもの	AIへ任せる範囲
数字を転記して、同じグラフを作る	データ接続済みのダッシュボードや集計処理	無理にAIを挟まず、定型の集計から
増減の理由を調べ、次の確認を決める	期間を揃えた数値、記事・クエリの内訳、変更履歴	事実の整理、原因候補、確認手順の下書き
前回の判断を踏まえて報告を続ける	上の材料に加えて、修正済みの前回判断と未解決事項	前回の問いへの答え合わせ、判断の更新案

たとえばGoogleのレポートツールには、GA4へ接続してグラフやレポートを作る機能があります。まず数字を見る仕事を整えたいなら、こうした既存の仕組みから始められます。GoogleのGA4接続ガイド

自動収集から組みたい方は、Python・GSC/GA4 APIを使った構築記録や、n8nでAIコメント付きレポートを作る実例も参考になります。本記事は、その先の「何を渡すと、どんな判断が返り、どこを直す必要があるか」を扱います。

一回のAI分析から、引き継げるレポート担当へ

この記事でいう「AI社員」は、担当業務、使える資料、仕事の終わり、任せてよい操作、次回へ残す記録を決めたAIの仕組みです。役職名を付けるだけで社員になるわけではありません。

一回だけ「この数字を分析して」と頼む場合と、週次レポート担当を作る場合の違いは、次の回に何を渡せるかです。たとえば「主力記事の減少理由はまだ分からない。ページ別の表示回数を確認する」という判断を残せば、次回はその確認から始められます。

AI社員全体の用途や導入方法はAI社員とは、業務共通の設計手順はAI社員の作り方にまとめています。ここからは、週次SEOレポートという一つの仕事を組み立てます。

まず用意するのは、指示書・数値・前回判断の3つ

最初の試行では、ファイルまたは貼り付けた資料を読めるAIと、手元の入力データを使います。今回の実行環境はCodex CLI 0.144.1、モデルはgpt-5.5でした。Googleの実アカウントには接続せず、架空のJSONを与えています。

同じ考え方を別のAI環境で試す場合も、入力を読めることと、返答を保存して次回へ渡せることを先に確認してください。以下の日本語の指示書は、実験で確かめた条件を読者向けに整理した例です。実行時のプロンプトをそのまま転載したものではありません。

1. 任せる仕事と、勝手に進めない範囲を書く

次の指示書に対象サイトと報告期間を入れます。

あなたは、対象サイトの週次SEOレポート担当です。
目的：数字の変化を整理し、次に確認することを決める。

読む資料：
・同じ条件で集計した前週と当週のGSC/GA4データ
・ページ別・クエリ別の内訳（なければ未取得と扱う）
・前回の確認済み判断、未解決事項、変更履歴

守ること：
・最初に対象サイト、期間、フィルタ、取得状態を確認する。
・クリック数、表示回数、率の計算を確かめる。
・全体と記事別を分け、内訳が足りなければ原因を決めない。
・取得失敗や未入力を0に置き換えない。
・前回の判断も元データに照らす。誤りなら引き継がない。
・記事変更、公開、通知、設定変更は実行しない。

返すもの：
1. 確認した事実（期間、数値、比較条件）
2. 原因候補と、まだ分からないこと
3. 前回判断の確認結果
4. 次に確認すること（必要な資料と対象を具体的に）
5. 欠測と保留した判断

完了：返答を確認できる形で保存する。
GSCが取れなければSEO判断を保留し、必要な再取得を示す。

「改善案を10個出す」より、「主力記事の何を確認すれば、次の判断ができるか」を答える仕事にすると、報告後の行動を選びやすくなります。

2. 比較条件と、取得できなかったものも渡す

数字だけの表では、データが本当に同じサイト・期間・条件なのか分かりません。入力には次の項目を添えます。

材料	渡す内容	足りない場合の扱い
集計条件	対象サイト、開始日・終了日、国・デバイス・検索種別などのフィルタ	比較条件を確認してから分析
GSC全体	クリック、表示回数、CTR、平均掲載順位、取得状態	取得失敗なら検索成果の判断を保留
GSC内訳	ページ・クエリ別の数値、抽出条件、上位何行か	ない指標は推定で埋めない
GA4	セッション、チャネル、定義済みのキーイベント、計測範囲	定義不明の0を商談・売上ゼロと読まない
前回判断・変更履歴	確認したこと、未解決の問い、実施した変更と日付	実施不明の提案を、実施済みの施策と扱わない

なお、Search Console APIはすべての行の返却を保証していません。上位ページや上位クエリの合計を、そのままサイト全体の値に置き換えないようにします。Search Console APIの公式仕様

今回の架空入力は次の通りです。全体の平均掲載順位は3期間とも8、GA4のコンバージョン値は0ですが、イベント定義・計測範囲は未確認という条件を付けました。ページ別の表示回数・CTR・クエリ内訳は渡していません。

期間（2026年）	GSCクリック	表示回数	newsのクリック	guideのクリック	GA4セッション
8/24–8/30	100	2,500	70	30	130
8/31–9/6	80	2,400	45	35	120
9/7–9/13	90	2,700	40	50	140
9/14–9/20	未取得	未取得	未取得	未取得	150

実際の業務では、GA4の全セッションとGSCクリックは同じ母数ではありません。両者を割って一つの「SEO成果率」にするのではなく、検索での露出・クリックと、サイト内の行動を別々に確認します。

3. 一件返してもらい、確認した判断を残す

指示書と最初の2期間の入力を一緒に渡し、返答を保存します。続けて、元の数値と返答を照合します。最初は特に、期間、率、記事別と全体の区別を確認してください。

次回へ渡す判断メモは、たとえば次の形です。

確認対象：2026-08-31〜2026-09-06の報告
事実：全体クリックは100→80。newsは70→45、guideは30→35。
訂正：newsの表示回数がないので、newsのCTR低下は確認できない。
判断：全記事のタイトル変更は行わない。
次回：newsの表示回数・CTR・クエリ内訳を確認する。
実施した変更：なし。
記録の状態：編集段階で確認した判断。事業責任者の承認とは別。

元のAI報告を丸ごと「正解」として残すより、何を確認し、どこを訂正したかを残すことが大切です。今回も、その違いが2回目の出力に表れました。

初回：計算が合っていても、改善提案は直す必要があった

初回は8/24–8/30と8/31–9/6を比較しました。AIは、全体クリックが100から80へ20減り、変化率が−20%であることを報告しました。全体CTRも4.00%から約3.33%へ、約0.67ポイント低下しています。

記事別ではnewsが25クリック減り、guideが5クリック増えています。この入力では2ページの合計が全体と一致するため、全体の20クリック減を内訳で説明できます。

ところが、AIの「次に確認すること」には、次の表現が入りました。これは実出力の末尾の抜粋です。

メインページのCTR低下要因を検証する。

渡したのは、newsのクリック数だけです。表示回数がないので、newsのCTRが下がったかどうかは分かりません。全体CTRの低下をnewsへ移して読んでしまっています。

編集段階の最初の判断にも、この前提が残っていました。別のレビューで誤りを見つけ、「CTR低下の原因を探す」から「newsの表示回数・CTR・クエリ内訳を取得する」へ訂正しています。この確認・修正はCodexによる編集レビューで行い、記事著者が手作業で実測した事例としては扱っていません。

もしnewsの表示回数だけが減っていたなら、タイトルの訴求を直す前に検索需要や露出を調べる必要があります。クリック数の減少だけで、全記事のタイトル変更に進む理由はありません。

次回：全体が増えても、主力記事が回復したとは限らない

2回目は、初回の編集判断と、新しい期間の入力を渡しました。全体クリックは80から90へ増え、変化率は＋12.5%です。

一方でnewsは45から40へ減り、guideは35から50へ増えました。AIはこの違いを読み、全体の増加をnewsの改善成功としませんでした。次の確認も、newsのページ・クエリの内訳を優先する返答でした。

ただし、この回に渡したのは訂正前の判断メモです。AIはそのメモを参照し、前回判断を説明する文の中に「newsのCTR低下原因」という誤った前提を引き継ぎました。分析のほかの箇所では記事別CTRがないと書いていても、前回メモの引用には矛盾が残ったのです。

引き継ぎは便利ですが、誤りも引き継ぎます。2回目の報告と前回メモの両方を訂正し、その後の欠測ケースには訂正版を渡しました。

「覚えてくれるか」だけでなく、前回の判断が今の資料でも成り立つかを確認する仕事を指示書に入れておくと、点検する場所が明確になります。

データが欠けた回：0件で埋めず、判断を止められるか

最後は9/14–9/20のGSCが取得失敗になった入力です。GA4のセッション150だけは残しています。

確認できた最終出力では、AIはSEO判断を保留し、クリック差分・変化率・CTR差分をすべてnull、つまり算出できない値として返しました。GA4のセッション増を、検索流入やSEO改善の証拠にはしていません。

このケースも一度で終わったわけではありません。最初の試行では、分析後の完了処理の説明が最終返答に混ざり、SEOレポートとして受け取れませんでした。実行環境の記録処理が完了できるように調整し、再試行して上の出力を確認しています。

定期レポートにするなら、「分析が終わった」と「正しい形式の報告を保存・配信できた」を別々に確かめる必要があります。取得失敗を0に変えて報告を完成させると、「検索クリックが90から0へ減った」という、実際には確認していない話を作ってしまいます。

自社の仕組みでも、直接取得・保存済み・取得失敗を分けている

MyMarketerでは、GSCを直接取得する経路と、保存済みデータを参照する経路を分けています。未接続、保存データなし、古いデータ、条件に合うデータなしも区別する実装があります。直接取得と保存済み参照は、情報の時点や範囲が同じとは限りません。

自社SEOの運用側では、入力の対象・期間・形式を検査し、取得失敗をnullとして残す既存処理も使っています。今回はこの検査を架空入力で試したうえで、AIの返答を確認しました。製品のデータ取得、運用側の入力検査、今回のAI実験は別の確認であり、製品内で無人レポートが完成する実績としては紹介していません。

一件試せたら、定期運用へ足すものを決める

今回確かめたのは、用意した入力から報告を作ること、前回判断を参照すること、欠測時に保留することと、そこに残った修正点です。数週間にわたる無人稼働、実アカウントからの自動取得、通知先への配信、顧客の時間削減・売上改善は検証していません。

実務へ移すときは、次の順で接続範囲を増やします。

1. 実データで一件照合する。 同じ対象・期間・フィルタのGSC/GA4を用意し、管理画面の元データと報告が合うか確認します。AIへ渡してよいデータの範囲も決めます。
2. 保存する記録を決める。 入力の版、AI原文、訂正済み判断、変更履歴を分けます。担当者が承認したことと、AIが提案したことを混ぜません。
3. 自動取得を接続する。 データ取得には既存のAPIや連携を使い、対象・期間・取得状態の検査を挟みます。取得用の認証情報を、分析のプロンプトへ貼り付ける必要はありません。
4. 定期実行と失敗時の連絡を足す。 いつ実行し、どこへ保存し、何が起きたら誰に知らせるかを決めます。重複実行や配信失敗も試してから配信を任せます。
5. 改善の実行は別に決める。 レポート担当に記事編集や広告費変更まで任せる場合は、変更できる範囲と承認条件を追加します。分析ができたことだけで、その権限を渡しません。

費用を比べるときは、AIの契約・API利用料だけでなく、収集基盤、保存、定期実行、確認・修正にかかる負担も見ます。今回の実験から「無料で全自動」「外注費を何割削減」といった比較はできません。

最初の一件は、上の指示書と表を使って試せます。返答を読むときは「提案が多いか」より、元の数字に戻れるか、まだ分からないことを残せるか、次回に確かめる問いがあるかを見てください。

報告を実際の改善へつなぐ運用は、マーケティングPDCAの自動化を設計する方法で説明しています。

自社のデータ接続や確認体制まで整えたい方は、AIマーケティングチーム構築支援の無料診断で、任せる業務と導入範囲を相談できます。