オウンドサイトを運営していて、毎週月曜の午前中に同じ作業をしていることに気づいた。
Google Search Consoleを開き、先月の検索クエリデータを手動でエクスポートする。GA4を開き、流入上位50件のランディングページをCSVにエクスポートする。Excelで2つの表を結合する——GSCの表示回数・クリック数とGA4のセッション・コンバージョンをURLで照合する。その後、手作業で色を付ける。流入が減ったものは赤、コンバージョン率が平均未満のものは黄色。
一連の作業にかかる時間は約1時間半。終わったらグループに共有し、クライアントから「受け取りました」と返信が来る。
この作業を3年間、毎週続けていた。
そんな先月、技術系の友人が私の画面をちらっと見て、胸に刺さる一言を言った。「これ、APIをつなぐだけの話じゃない？なんで毎週手作業でやってるの？」
私は一瞬固まった。彼の言うとおりだった。GSCとGA4にAPIがあることを知らなかったわけではない。「スクリプトを書いてAPIを呼ぶ」と考えるたびに、頭に浮かぶのは一つの大規模な開発プロジェクトだった。Pythonを書き、認証を処理し、ページネーションに対応し、フィールドをマッピングし、フロントエンドを作る……これらを合わせれば確かに時間を節約できるが、始めるためのハードルが高すぎて、ずっと手をつけられずにいた。
転機は何だったのか？Codexだった。
一、まずCodexとは何か——そして、なぜChatGPTではないのか
AIによるコーディングと聞くと、多くの人がまず「ChatGPTにスクリプトを書いてもらおう」と考える。私も試したことがある。ChatGPTがコードを書き、エディタに貼り付け、環境を整え、依存関係をインストールし、エラーを実行して、エラー内容を貼り返して修正してもらい、また実行し、またエラーになる……これを7、8回繰り返すと、データを手動で取得するより疲れる。
Codexの位置づけはまったく違う。ターミナル上で直接動くプログラミングAgentであり、独立したサンドボックス環境を持っている。ファイルの読み書き、パッケージのインストール、コマンドの実行、エラー処理までできるため、最初から最後までコードをコピー＆ペーストする必要がない。自然言語で指示すれば、自分で計画し、書き、実行し、修正してくれる。
例えば、私が与えた指示は次の一文だった。
「GSCの直近28日間の検索クエリデータをエクスポートし、GA4のランディングページデータとURLで結合して、流入減少幅が大きい上位20ページの表を作って」
Codexは自分で次の作業を完了した。
•現在の環境にGoogle API用のPythonライブラリがあるか確認し、なければ自分でインストール•GSCとGA4の認証ファイルのパスを読み取り、OAuthを処理•GSC APIを呼び出して検索クエリとページ単位のデータを取得し、ページネーションを自動処理•GA4 Data APIを呼び出してランディングページ単位のセッションとコンバージョンを取得•URLをクリーニング（パラメータを削除、末尾のスラッシュを削除、wwwの有無を統一）•URLで突合して結合し、各ページの表示回数・クリック数・コンバージョンのファネルを計算•流入減少幅の順に並べたMarkdown表を出力
私は横で画面を見ていただけで、Codexがすべて実行した。途中でGA4 APIの日付形式に一度エラーが出たが、エラーメッセージを読み、自分で修正して再実行し、正常に動作した。
🔴 AIコーディングツールの違いは「コードを書けるかどうか」ではない——どれも書ける。重要なのは「自力で動かし切れるかどうか」だ。
二、CodexでGSC+GA4のデータ連携を完成させる手順
ここからは、実際の操作順に沿って、この仕組みをどう構築したかを振り返る。理論ではなく、すべてターミナルで実際に実行した手順だ。
1. 準備：Google Cloudの認証
これは避けて通れない。GSCとGA4のAPIは、どちらもGoogle CloudのOAuthまたはService Account認証を利用する。AIを使うかどうかに関係なく、この段階は手動で行う必要がある。
私が行った作業：
•Google Cloud Consoleでプロジェクトを作成し、Search Console APIとGoogle Analytics Data APIを有効化•Service Accountを作成し、JSONキーファイルをローカルにダウンロード•GSCでこのService Accountのメールアドレスを「制限付きユーザー」（完全な権限）として追加•GA4の管理画面でこのメールアドレスを「データ閲覧者」として追加
この段階ではCodexは役に立たない——認証と権限付与は人間と画面のやり取りが必要な手順であり、Googleの認証ページを代わりに操作することはできない。ただし、後続の手順は認証ファイルのパスさえ正しければ、すべてスムーズに連携できる。
⚠️ API自動化が最初につまずく場所の多くは、コードではなく権限だ。Googleの権限システムはロシアのマトリョーシカのようなものだ——GSCに1つの入口、GA4に別の入口、さらにGoogle Cloudにも入口があり、3つの入口の権限は互いに連携していない。この段階を焦らず終えれば、後はスムーズに進む。
2. 最初のSkill：GSCの検索クエリデータを取得
Codexの使い方はこうだ。一連のタスクを再利用可能なSkill（スキルファイル）としてまとめ、~/.codex/skills/ ディレクトリに置く。同じSkillを呼び出すたびに、同じロジックで実行される。
まず、最もシンプルなバージョンを作った。GSCの検索クエリ単位のデータだけを取得するものだ。
このSkillでは、どのAPIを使うか、どのディメンションを取得するか、どの形式で出力するかの3点をCodexに指示した。1回実行すると約40秒で、クリック数、表示回数、CTR、平均掲載順位を含む検索クエリ上位100件の一覧が出力された。
その結果を先月手動でエクスポートしたCSVと照合すると、データは完全に一致していた。そのとき、「手作業の時代は終わった」と感じた。
ただし、完全に正確だったわけではない。GSC APIには落とし穴がある。デフォルトでは1000行しか返さず、それを超える場合はページを切り替える必要がある。初回の実行時、私のサイトには1か月で3400件以上のクエリがあった。Codexは自分で返却行数が合わないことに気づき、ページネーションのロジックを追加して再実行した。2回目にはすべて取得できた。
自分で発見し、自分で修正する。ChatGPTにスクリプトを書いてもらうのとは、まったく違う体験だった。
3. 2つ目のSkill：GA4を接続
GSCの取得が終わった後、GA4のランディングページデータも取得するよう指示した。
こちらは難易度が一段上がった。GA4のData APIでは、自分で「データリクエストボディ」を作成する必要がある。取得するディメンション（landingPage）、指標（sessions、conversions、eventCount）、期間、フィルタ条件を定義しなければならない。リクエストボディのJSON構造はGSCとまったく異なり、さらにGA4のレスポンスに含まれるフィールド名は eventName_xxx のような長い形式なので、自分で解析する必要がある。
CodexがGA4 APIを読み書きする様子は印象的だった。機械的に指示どおりAPIを呼ぶのではなく、呼び出す前にSchemaの探索を行った。GA4 Metadata APIを呼び出し、そのプロパティにどのようなディメンションや指標があり、フィールド名がどう構成されているのかをすべて確認してから、リクエストボディを構築した。
💡 この「まず現場を理解してから動く」というやり方は、実際に新しいAPIへ接続するときの人間の仕事の進め方そのものだ。AIはそれを自動化した。
2つのSkillを実行し終えると、2つの表が手元にできた。
•GSC検索クエリ単位：キーワード、ページURL、クリック数、表示回数、CTR、平均掲載順位•GA4ランディングページ単位：ページURL、セッション、コンバージョン、平均エンゲージメント時間
次は結合だ。
4. 結合——2つの表から優先順位付きのTodoへ
2つの表の結合は簡単そうに聞こえる。URLとURLを対応させて、つなげれば終わりだ。しかし実際には、無数の細かな落とし穴がある。
私はまず、2つの表のサンプルデータを自分で「見て」確認するようCodexに指示した。すると、GSCのページURLには https:// のプレフィックスが付いている一方、GA4のランディングページパスには /blog/seo-guide としか書かれていないことがわかった。GSCのURL末尾には ?utm_source=google のようなクエリパラメータがあるが、GA4ではすでに削除されている。GSCにはデータがあるのにGA4にはないページもあれば、その逆もある。
Codexはこうした差異を自分でデータクリーニングした。プレフィックス、パラメータ、アンカーを削除し、末尾のスラッシュを統一してから、突合・結合を行った。
結合後に出力されたのは、冷たいピボットテーブルではなく、問題の種類ごとに優先度を付けた診断結果だった。
優先度｜ページの特徴｜診断の方向性
🔴 P0｜表示回数が30%以上減少、掲載順位がtop5からtop10圏外へ低下｜順位喪失——被リンクとコンテンツの鮮度を確認
🟡 P1｜表示回数が多くCTRが低い（CTRが平均より50%低い）｜タイトルの訴求力不足——TitleとMetaを改善
🟡 P1｜クリック数が多くコンバージョンが低い（コンバージョン率が平均より40%低い）｜ランディングページの転換力不足——ページ内容とCTAを確認
🟢 P2｜掲載順位8-20位で検索ボリュームが多い｜あと一歩——内部リンクとコンテンツを強化
📊 2つの孤立したレポートを、深刻度順に並んだTodoへ変える——これが「データ連携」の意味だ。データを見るためではなく、何をすべきかを知るためにある。
三、この過程で実際にぶつかった落とし穴
Skillを書いて動かし終えた後から振り返ると、すべてが「自然な流れ」に見える。しかし当時は、実際に何度も行き詰まった。
落とし穴その1：GA4の指標名は直感的ではない
GA4 APIでは、セッション数は sessions ではなく sessions と呼ばれる。コンバージョン数は conversions ではなく eventCount だが、コンバージョンとしてマークしたイベントに限られる。平均エンゲージメント時間は avgTimeOnPage ではなく userEngagementDuration で、さらに自分でセッション数で割る必要がある。
これらはドキュメントを読めば理解できる。問題は、一つひとつ調べるのに1〜2時間かかることだ。Codexが節約してくれたのは、まさにこの時間だった。APIリクエストを構築する前に、GA4のMetadataインターフェースを自分で呼び出し、そのプロパティで利用可能なすべての指標の名前、種類、説明を取得し、「セッション数が欲しい」という意味に対応するフィールドを英語の意味から照合した。
落とし穴その2：GSC APIの割り当て制限
GSC APIの1日あたりの割り当ては、GSCを手動操作する場合と同じく上限がある。初回はページネーションを積極的にしすぎて、20ページを同時に呼び出したところ、直接レート制限にかかった。CodexはHTTP 429を受け取ると数秒待って再試行し、2回目はページネーションの速度を毎秒2ページまで下げたため、安定して動作した。
この経験から気づいたのは、AIがどれだけ賢くても、呼び出すのは人間が作ったAPIだということだ。APIのレート制限、データ形式、フィールド名といった面倒な作業は代わりに処理してくれるが、どこに落とし穴があるかは知っておく必要がある。
落とし穴その3：Codexは時々、過剰に設計する
あるとき、「データをページタイプごとにグループ分けして」と指示した。私の意図は、URLパスの /blog/ や /product/ のようなプレフィックスで分類することだった。しかしCodexは、各ページのHTML構造を読み取り、ページタイプを抽出するものだと理解した。実際にそれを実行し、requestsライブラリで各ページのHTMLをクロールし、metaタグとschemaマークアップを分析して分類した。
動作はしたが、4分近くかかった。私が本当に欲しかったのは、URLパスのプレフィックスで条件分けするだけだった。
⚠️ AIと協働するとき、問題の粒度が効率を左右する。具体的に伝えるほど、速く実行してくれる。曖昧に伝えると、最も複雑な方法で「理解」しようとする——しかも、遠回りしていることを必ずしも教えてくれない。
四、「再利用可能」にする方法——一度きりのスクリプトではなく
一度動かすだけなら簡単だ。毎週実行でき、別のサイトでも使える「データ連携」にすることにこそ価値がある。
CodexのSkill機能でパッケージ化する
CodexはSkillファイルに対応している。~/.codex/skills/ ディレクトリに置くMarkdown形式の指示ファイルだ。本質的には、非常に正確に書かれた操作マニュアルである。CodexはこのSkillを呼び出すたびに、同じSOPを最初から実行するため、「前回一時的に変更した内容を元に戻し忘れる」といった問題も起きない。
GSC+GA4のデータ取得→クリーニング→結合→診断→出力という流れを、3つの独立したSkillに分割した。
Skill｜役割｜出力
seo-gsc-pull｜GSCの検索クエリ+ページ単位のデータを取得し、自動でページネーション｜2つのCSV：gsc_queries.csv、gsc_pages.csv
seo-ga4-pull｜GA4のランディングページ+コンバージョンデータを取得し、指標を自動照合｜ga4_landing.csv
seo-data-merge｜3つの表を結合し、URLをクリーニングして診断順に出力｜Markdown診断レポート+結合後のCSV
3つに分けるメリットは、GSCで問題が起きたらGSC部分だけを実行し、GA4の割り当てが足りなければGA4部分だけを実行できるため、互いにブロックされないことだ。さらに、クライアントごとにサイトが異なっても、前2つのSkillはデータソースが変わる一方、3つ目のSkill（結合・診断）は再利用できる。サイトURLのパラメータを1つ変更するだけでよい。
1行のコマンドで全フローを実行
3つのSkillに分割した後、Codexで「オーケストレーションSkill」を作成した。
/seo-weekly-report site=example.comCodexはこの指示を見ると、GSCのデータ取得、GA4のデータ取得、統合診断という3つのSkillを順番に実行し、最後にターミナル上へP0/P1/P2の優先度順に並べたページ単位の診断レポートを出力する。全体で実行すると、約2分強で完了する。
💡 「自動化」とは、壊れないスクリプトを1本書くことではない。繰り返し行う必要のある作業を、ひと言で起動でき、データの変化にも対応できるフローに変えることだ。
五、この仕組みを作ってから、実際に起きた変化
大げさではなく、月曜の午前中が完全に変わった。
以前：
•40分かけてGSCとGA4のデータを手作業でエクスポート、整形、統合する•Excelで20分かけて色を付け、優先順位を整理する•20分かけて「今週のSEOサマリー」を書き、グループに送る•クライアントから「確認しました、お疲れさま」と返信が来る
現在：
•月曜に出社したら、ターミナルで /seo-weekly-report と1行入力する•2分後には、診断レポートが reports/ ディレクトリに生成されている•コピーしてWeChatに貼り、2行ほどコメントを加えて送る
しかし同時に——面白いことも起きた。以前は「長い時間をかけて」レポートを送っていたので、クライアントは多くの作業をしたと感じてくれた。今では2分で結果を出せるため、逆に「こんなに早いなんて、本当にちゃんと見たの？」と思うクライアントもいる。
笑えるだろうか。でも、これが現実の人間心理だ。
だから今は、戦略を調整している。レポート生成後、P0のページをいくつか選び、15分かけて1ページずつ実際に開いて確認し、レポートに「人による確認コメント」を1行追加する。この15分は無駄ではない——「誰かが本当に見た」とクライアントに感じてもらうためだ。AIが吐き出した機械的なレポートではなく。
🔴 AIが代わりにやってくれるのは、面倒な作業だ。しかし、あなたの判断、経験、そしてもう一度確認する姿勢——これらは自動化されない部分だ。そしてまさに、クライアントが最も重視する部分でもある。
六、この仕組みを作りたい人への、現実的なアドバイス
あなたもCodexで自分のSEOデータの一連の流れを構築したいなら、以下は私が実際のお金（と時間）をかけて得た教訓だ。
① 最初から完璧を目指さない。まずはGSCだけを動かす。
Skillは1つだけ。直近28日間の検索クエリデータを取得し、CSVとして出力する。これが動けば、すでに「完全自動の順位トラッキング」能力を手にしている。ゼロから形にするまでにかかったのは30分——その大半はGoogle Cloudの権限設定だった。最初のSkillが動けば、心理的な壁はなくなる。
② 認証ファイルをきちんと管理する——ここが一連の仕組みの「急所」だ。
Google CloudのService Account JSONキーファイルが一度漏洩すると、第三者があなたのGSCとGA4を読み書きできてしまう。このファイルをGitリポジトリに置いてはいけない。環境変数でパスを参照し、CodexのSkillでは `${GSC_CREDENTIALS_PATH}` のように参照する。ハードコードは避けること。
③ Codexのログに各ステップの所要時間を出力させる。
Skillに「各操作の後に所要時間を記録してください」と1文追加する。格好をつけるためではなく、どこがボトルネックなのかを把握するためだ——GSC APIの取得が遅いのか、GA4のページ分割が多いのか、それともURLのクリーニング処理が複雑なのか。分かって初めて、的を絞って最適化できる。
④ 複数サイトで再利用する前に、新旧サイトのGA4プロパティ構造が一致していることを確認する。
同じSkillでも、Aクライアントでは正常に動くのに、Bクライアントではエラーになる——80%は、2つのGA4プロパティでカスタムディメンションとイベント名が異なることが原因だ。新しいサイトで初めて実行するときは、まずCodexにGA4 Metadataを1回取得させ、構造を確認しよう。
📊 私の実績データ：1クライアント分のフロー全体をゼロから構築するのに約45分（Googleの権限設定を含む）。その後の毎週の実行時間は約2分。
GitHubには、そのまま持ってきて改修できるオープンソースのCodex SEO Skillがいくつかある——owensky-devは seo-gsc-ga4-analyst を作っており、AminForouは mcp-gsc というMCPサーバーを公開している。ゼロから車輪を発明する必要はない。既存のSkillを1つ持ってきて実行し、どのような出力になるかを確認してから、自分の要件に合わせて改修すればいい。ゼロから書くより10倍速い。
もちろん、既存のSkillが取得する出力が、必ずしも自分の要件に完全に合うとは限らない。たとえばowensky-devのSkillはデフォルトで90日間のデータを取得する——私は28日間のウィンドウで分析するのが習慣だ。この程度の変更なら、Skillファイル内のパラメータを1つ変更するだけでよい。Codexは変更内容を読み取り、そのとおりに実行してくれる。
全体——1つのアイデアから安定稼働する状態まで——にかかったのは、午後2回分ほどだった。1回目の午後は権限とAPI連携に、2回目の午後はSkillの作成と出力形式の調整に費やした。その後は毎週、この仕組みがその2回分の午後を取り戻してくれている。
先週、海外向けサイトを運営する同業者に「何のツールでデータを見ているの？」と聞かれた。
私はCodexだと答えた。
彼は高いのかと聞いた。
私は、先週あなたがExcelに費やした時間より高くはないと答えた。
彼は数秒黙った。そしてこう言った——「じゃあ、そのSkillを1つ送ってくれないか」