「AIに任せれば一発」と思ったら、SEO計測ツールを5回作り直すことになった話

はじめまして。私は東証プライム上場のIT企業で、システムエンジニアと営業企画を経てBtoBマーケティングを担当していました。現在はフリーランスとして、複数のBtoB企業のマーケティング戦略〜実行・改善までを支援しています。

支援先のひとつに、BtoBの人材サービス企業があります。そこで毎週、KPIレポートを手作業で作成していました。

作業の中身は、GA4で流入からCVページ参照、フォーム到達、CVまでのファネルをチャネル別に集計し、Google Search Consoleで検索順位やクリックを確認して、毎週その2つを突き合わせる。

地味に時間のかかる作業で、毎回1時間程度かかります。しかも手作業のため、私が動かなければレポートが出ません。

そこで、GA4とGoogle Search Console（以降、GSCと記載します）の画面の行き来そのものをAIに任せられないかと考えました。

普段から業務の自動化にはClaude Code（デスクトップアプリ）を使っていたため、そこからGA4とGSCを直接参照できればいい、という発想です。

接続は、Google Cloudでプロジェクトを作り、GA4 Data APIとSearch Console APIを有効化します。サービスアカウントを発行してJSON鍵を取得し、それをGA4とGSCに「閲覧者」として追加。

最後に、GA4とGSC用のMCPサーバーをClaude Codeに登録すれば、数字を取りに行ける状態になりました。

「ここまで準備できれば、残る作業は集計を任せるだけ」と、最初の指示を投げました。

最初に投げた指示は、たった一行です。

しかし、想定していたファネルとは異なるものが出力されました。原因は私の指示の出し方にあり、事前に決めきらないまま渡していた要素が、3つあったのです。

やっかいだったのは、問題が一度に表面化しないことでした。チャネルを直すと、URLの役割のズレが見える。URLの役割を直すと、今度は指標定義の曖昧さに気づく。修正しては再度指示を出す。この繰り返しを経て、5回目でようやく、狙いどおりのレポートになりました。

必要なのは、先に「何を測るのか」を決めることです。AIに依頼する前に、自分で「何を、どの条件で、どの式で測るのか」を定義しておく。前段で見つかった3つの抜けは、そのまま事前に決めるべき項目でもあります。

具体的には、次のように整理しました。

計測設計を先にまとめたうえで、AIへの指示を書き直しました。

改善後の指示では、一度で意図どおりのコードが返ってきました。作り直しも発生していません。これで週次レポートを一発で出力できるようになりました。

AIに任せるのは「どう作るか」までです。「何を測るか」と「なぜ測るか」は、人間が握る必要があります。

この一件を通じて、自分なりの線引きが明確になりました。AIは実装のスピードに優れています。コードを書く、集計する、整形する。こうした作業では、人間よりもはるかに速く動けます。

一方で、「この数字で何を判断したいのか」「どのURLをCVの起点と見るのか」は、業務の背景を理解している人間が決める領域です。

人間が What／Why を定義し、AIには How を実装指示として渡す。最終的に出力の質を左右したのは、自分がどこまで具体的に決めて、どこまで明確に渡せたかです。

また、信頼できる数字が毎週そろうようになり、施策前後で数字がどう動いたかを正確に追えるようになりました。その結果、クライアントの動き方が変わりました。

以前は、施策が効いたのかどうかの判断が、人の感覚頼みになっていました。いまは施策を打つ前に「何を狙い、どうなれば成功か、どの数字で判断するか」を決め、2週間後に見直すやり方に変わりました。

とりわけ大きかったのがリード獲得数の増加です。それまでWeb経由で問い合わせや資料請求につながる有効リードは、ほぼゼロの状態が長く続いていました。それが、この進め方に切り替えてから月9件（月の目標5件に対して180%）まで増えたのです。

いちばん大きな変化は、クライアントのPDCAが毎週回るようになったことです。

以前は、レポート作成に時間がかかり、検証まで手が回らないこともありました。いまは、ツールが毎週KPIレポートを自動でNotionにまとめてくれます。

レポートに入れている主な内容は、次のとおりです。

• チャネル別のファネル
• 流入 → CVページ参照 → フォーム到達 → CV
• フォーム到達率・通過率・コンバージョン率
• 検索順位の動き
• 今週どの数字が、どの施策で動いたかの読み

数字の集計だけでなく、AIが「どの施策が、どの数字に影響していそうか」まで下書きします。どこで離脱しているのか、どのページが伸びているのかが見えるため、以前よりも検証に時間を使えるようになりました。

たとえば、ある週のレポートで、AIはこう書いてきました。「サイトで来訪者ができる行動が"問い合わせ"しかない。関心はあるけれど、まだ相談まではしたくない人が、行き場をなくして離れている可能性が高い」。数字を並べるだけでなく、なぜ離れているのかの仮説まで下書きしてくるのです。

ただし、それを採用するかどうかは私が決めます。この仮説を受けて打ったのが、ポップアップのA/Bテストでした。「採用の課題を1分で診断する」案（A）と「資料をダウンロードする」案（B）を並べ、どちらが押されるかを比べます。結果はA案が2.16%、B案が0.55%で、クリック率に約4倍の差。「資料をどうぞ」と差し出すより、「あなたの悩み、これじゃないですか？」と問いかけるほうが響くとわかり、その後のページ改善にも活きる学びになりました。

実際に、数字を根拠に判断した施策から、次のような成果が出ています。

どの施策も、「なんとなく効いた気がする」で終わらせず、数字で確認してから判断できました。

AIが毎週、土台となる数字をそろえてくれる。だから自分は、仮説づくりと施策の判断に時間を使える。個人的には、この変化が最も大きいと感じています。

時短の効果も、もちろんあります。以前は1時間かけていたレポート作成が、いまは5分もかかりません。浮いた時間は、そのままPDCAに回しています。

最後に、同じ遠回りをしないための要点を残しておきます。AIに投げる前に、次の4つを埋めるだけです。ここまで決まっていれば、コードは数分で返ってきます。

ここまで決まっていれば、コードの実装はAIに任せられます。

AIは、指示した内容に沿って動きます。だからこそ、「何を測るのか」「なぜ測るのか」を決める仕事は、人間が担うべきタスクです。

5回の作り直しを通じて、AIに渡す前にどこまで設計できているかが、出力の質を決めると学びました。