Claude CodeでGSC/GA4の週次レポートを自動化

Claude CodeでGSC/GA4の週次レポートを自動化するとは、検索とアクセスの数字を自分で見に行くのをやめ、毎週決まった時刻に数字が勝手に取得され、1行の記録としてたまり、そこから次の打ち手の提案まで出てくる状態を作ることです。作業を速くするのではなく、レポートを作る仕事そのものを消します。

この記事は、GSC（Google Search Console／検索での表示回数や順位が見える無料ツール）とGA4（Googleのアクセス解析ツール）を毎週チェックしようとして続かなかった経営者・AI実践中級者に向けて、全体像4ステップ・準備・壊れない設計を実物ごと公開します。いま読んでいただいているこのブログ自体が、毎週月曜9時に無人で計測が走っている実例です。

Claude CodeでGSC/GA4の週次レポートを自動化するとは？月曜9時に数字が出そろう状態のこと

ここで言う自動化は「レポート作成の時短」ではありません。月曜の朝、パソコンを開いた時点で先週の数字がすでに手元にある状態を指します。人間に残る仕事は、出そろった数字を読んで判断することだけです。

自動化される仕事は4つあります。

• 取得: GSCとGA4から先週7日分の数字を取りに行く

• 記録: 取った数字を、決まった形式で1週1行だけ書き足す

• 診断: たまった記録を読んで、リライト候補や新規テーマの候補を出す

• 補充: 出た候補を、次に書く記事の在庫リストに足す

「レポート自動化」で想像されるのは1つ目と2つ目でしょう。ただ、数字を集めるところで止めた自動化は、結局また人間が見に行く運用に戻ります。Claude Code（ターミナル上で動く対話型のAIエージェント。日本語の指示でスクリプト作成から実行設定までこなす）を使う理由もそこで、取得から提案までを一続きに組めるかが分かれ目です。

なぜ計測レポートは手作業だと続かないのか

「毎週月曜に数字を見る」と決めて3週目までに崩れた経験がある人は多いはずです。意志の問題ではなく、構造的な欠陥が2つあります。

締切のない30分は、忙しい週から順に飛ばされる

手作業の週次レポートは、GSCで期間を先週に合わせ、表示・クリック・平均掲載順位を控え、GA4でセッションとユーザーを控え、ページ別の内訳も見て、転記して前週と比べる工程の束です。合計30分前後。しかもこの作業は、やらなくても今週は誰も困りません。飛ばした週の数字は、あとから同じ形では取り戻せません。

「見た」で終わって、次の一手に変わらない

手作業で数字を見ると、たいてい「表示が少し増えた」で終わります。先週の数字が同じ形式で残っていないので比較ができず、比較ができないので判断基準も育ちません。続かない本当の理由は、記録が残らない形で見ているからです。 数字を見る運用ではなく、数字がたまる運用に変える。ここが出発点です。

週次レポート自動化の全体像。取得・記録・診断・次の一手の4ステップ

僕が実際に組んでいる構成をそのままステップに落とします。難しいのは「毎週同じ形で1行残す」の一点だけです。

経営的に効くのは3番と4番です。1番2番だけなら「自動で集まる数字」で終わりますが、3番4番が入ると「今週どの記事に手を入れるか」の会議が要らなくなります。

GSCとGA4を自動取得する準備。何を渡せば動くのか

準備は一度きり、10分ほどです。渡すものは3つだけ。

• GSCのプロパティ: 自社サイトが登録済みであること。登録形式（ドメイン単位かURL単位か）だけ確認しておく

• GA4のプロパティID: 管理画面のプロパティ設定にある数値のID。Gから始まる測定IDを渡す取り違えが定番のエラー原因です

• プログラムから読むための閲覧権限: 人間のアカウントとは別に、プログラム用のアカウントを1つ作り、両方に読み取り専用で追加する

3つ目がいちばん重要です。ポイントは読み取り専用にすること。計測の仕組みに書き込み権限を渡す理由は1つもありません。なお、認証情報そのものの取り扱いは各社のセキュリティ方針に関わるため、この記事では扱いません。

実物公開。本ブログが毎週1行だけ記録している数字

このブログの計測は毎週月曜9時に無人で走り、記録ファイルに1行を書き足します。2026年7月27日の実行で追記された行がこれです（一部項目は省略）。

{"date":"2026-07-27","week_start":"2026-07-19","week_end":"2026-07-25","published_total":21,"sessions_7d":129,"users_7d":70,"pageviews_7d":335,"gsc_impressions_7d":40,"gsc_clicks_7d":7,"gsc_avg_position":20.5,"note":"auto(pull_metrics)"}

7月19日から25日の週で、検索の表示回数40・クリック7・平均掲載順位20.5、アクセス側はセッション129・ユーザー70・ページビュー335。前の週（7月12日〜18日）は表示もクリックもセッションもすべて0でした。つまり、このサイトの数字はいま立ち上がったばかりのゼロ近傍です。

ゼロに近い数字でも、記録が残ることに価値がある

表示40は、SEOの成果として語れる数字ではありません。それでも公開するのは、この1行が「先週と比較できる形で残っている」からです。前週の0も記録されているので、増減を事実として読めます。

計器の粗さも書いておきます。この行の公開本数はサイトマップのURLをそのまま数えているだけで、タグページなども混ざります。完璧な計器を設計してから始めるより、粗くても毎週同じ基準で残るほうが先です。

記事別の数字はここまで細かく残る

同じ実行で、記事ごとの内訳も別ファイルに追記されます。この週に検索表示が付いたのは3記事だけでした。

• 非エンジニア向けAI研修の記事: 表示8・クリック1・平均掲載順位25.1

• Claude Codeの業務効率化の記事: 表示4・クリック0・平均掲載順位19.2

• サイト最初のあいさつ記事: 表示3・クリック0・平均掲載順位6.3

この粒度なら判断が具体的になります。クリックを取っているのは研修の記事だけなので研修まわりを厚くする根拠になり、掲載順位19.2の記事は「あと少しで1ページ目」の帯なのでリライト監視に置ける。合計や平均だけでは、この2つは出てきません。

毎週月曜9時に無人で走らせる方法と、失敗に気づく仕組み

予約実行に載せるのは10分の作業

Macなら標準の予約実行の仕組み（launchd）、サーバー上ならcronで、曜日と時刻を指定するだけです。設定ファイルの書式もClaude Codeに日本語で頼めば書き出してくれます。僕のブログの計測は毎週月曜9時0分。大事なのは人間がその数字を見る時間帯の直前に置くことです。夜中に走らせて午後に見る運用だと、失敗に気づくのが遅れます。

「静かに止まっている」を防ぐ

無人運用でいちばん怖いのは、エラーで止まることではなく、止まったまま誰も気づかないことです。僕の環境では実行結果がログに残り、7月27日の実物はこの行でした。

OK: kpi.jsonl追記 2026-07-19〜2026-07-25 imp=40 clicks=7 sessions=129

読むべきは1点だけ。その週の追記行があるかどうかです。無ければその週の計測は失敗しています。手の込んだ監視を作る前に、「成功したら1行、失敗したら理由が残る」だけで十分に実用的です。無人化のリスク設計そのものはAI自動化のリスク設計で別途整理しています。

数字が壊れないための設計。同じ週を二度書かないとは？

自動で追記していく記録は、放っておくと必ず壊れます。壊し方は決まっていて、対策も3つで足ります。

同じ週を二度書かない

いちばん多い事故が重複追記です。動作確認でもう一度実行しただけで同じ週の行が2本になり、合計が狂います。対策は単純で、書き込む前に「その週の行がすでにあるか」を確認し、あればスキップします。僕のログにも実物が残っています。

SKIP: week_start=2026-07-12 は追記済み

同じ週を二度書かない。この一点だけで、再実行が怖くなくなります。 怖くなくなると動作確認を気軽にできるようになり、結果として仕組みが育ちます。

失敗しても行そのものは消さない、確定した期間だけ取る

APIが応答しなかった週に行を書かずに終わらせるのは最悪の設計です。あとから「ゼロだった」のか「取得に失敗した」のかが区別できません。僕の設計では失敗した項目は空のまま、備考欄に理由を書いた行を必ず残します。記録の役目は、良い数字を残すことではなく、その週に何が起きたかを残すことです。

3つ目は、GSCの数字は直近2日ぶんが後から更新される点。昨日までを含めると翌週に取り直したとき数字が変わるので、2日前を終端にした7日間で固定します。地味ですが、比較可能な記録には決定的です。

数字を改善提案まで運ぶ「外側ループ」の作り方

ここまでで「数字が勝手にたまる」は完成しました。最後は、その数字を次の一手に変える工程です。公開後の実測から打ち手を決めるサイクルを、僕は外側ループと呼んでいます。

関連記事ループエンジニアリングとは——AIが自分で改善を回す仕組みループエンジニアリングとは、AIに単発の作業ではなく“作る→測る→直す”の改善サイクルごと任せる設計手法です。プロンプト・ハーネスエンジニアリングとの違い、実際に回っている僕のブログの改善ループの実物と作り方を公開します。→

取得の42分後に、診断が動く

僕のブログでは月曜9時0分に計測が走り、9時42分に週次の診断ランが走ります。診断ランは記録と記事別の数字を読み、前週比を出し、改善候補に優先度を付け、次に書くテーマの在庫を補充します。

7月27日の診断はこう判定しました。表示が付いた3記事以外は公開から日が浅いので「異常ではなく蓄積待ち」。全体のクリック率は7÷40で17.5%と高く見えるが、母数40では読めないので成果指標にしない。セッション129に対し検索クリックは7なので、流入の大半はまだ検索以外である。この「読めない」と言い切る判定が入っているかどうかが、自動レポートの質を分けます。

提案までで止める、を仕組みに書く

外側ループを作るとき、僕が診断ランの指示書の冒頭に固定している原則があります。

公開物の変更はしない（リライト・タイトル変更の実行は人間の承認後。提案までが仕事）

自動化するのは判断そのものではなく、判断材料が机の上に乗るまで。実際7月27日の診断も「今週はリライトに着手しない。全記事が公開28日未経過で判定材料が足りない」と結論し、何も変更せず終わっています。

想定外の効果もありました。診断ランが、自分の読んでいる計器の欠落を指摘してきたことです。「資料ダウンロード数の列が空欄なのは蓄積不足ではなく計器の欠落。取得の仕組みが存在しない」という指摘で、手作業のレポートでは出てこない気づきでした。記事の材料を集めるリサーチ側も、同じ思想の別ループで回しています。

関連記事Claude Codeに毎朝のリサーチを任せる仕組みの作り方毎朝9時にClaude Codeが追跡リストを巡回し、「今日の動き」を1枚に合成して通知する——2026年6月から無人で回り続けている僕の実運用をもとに、リサーチ自動化を組む5ステップと続けるための設計を解説します。→

自動化する前に決めておくこと。見る指標・権限・人間が判断する場所

見る指標を先に絞る。 GSCとGA4は数百の指標が取れますが、僕が記録しているのは表示・クリック・平均掲載順位・セッション・ユーザー・ページビューの6つだけです。

判断ルールを先に言葉にする。 「掲載順位8位から20位で表示が多い記事はリライト」「表示が多いのにクリックが少ない記事はタイトル改善」のように、数字がどうなったら何をするかを決めておきます。ルールがあるからこそ、今週は該当なしと言い切れます。

Claude Codeのレポート自動化でよくある質問

まとめ。レポートは作るものではなく、たまるものにする

• 週次レポート自動化とは、月曜の朝に先週の数字がすでに手元にある状態のこと。手作業が続かないのは意志ではなく、記録が残らない形で見ているから

• 全体像は取得・記録・診断・次の一手の4ステップ。集めるところで止めず、改善提案までを仕組みに載せる

• 壊れない設計は3点。同じ週を二度書かない、失敗しても行を残す、後から動く数字は確定してから取る

• 決めるのは、見る指標・読み取り専用の権限・人間が承認する場所

このブログの数字は表示40・クリック7という立ち上がりの段階です。それでも毎週月曜、僕が何もしなくても数字は記録され、診断が回り、次のテーマが補充されています。計測は数字が育ってから始めるものではなく、育つ前に勝手にたまる形にしておくものです。