【実録】Claude Codeでマーケ分析を立て直した半年｜表示が増えて喜んだ翌日、AIに嘘をつかれ、本番を壊しかけた話
目次 クリックで開く
これは、うちのSEO/マーケ運用を、Claude Codeを相棒に立て直していった”実録”です。きれいな成功談だけを書くつもりはありません。表示回数が増えてガッツポーズした翌日にがっかりした話、AIに堂々と嘘をつかれた話、本番サイトの図をぐちゃぐちゃに壊した日の話——全部、順番に書きます。同じ壁にぶつかっている実務マーケターの、”あるある”の答え合わせになれば。
読み方：各エピソードは「症状 → うわ、となった瞬間 → 原因 → 直し方 → 学び」で書いています。忙しければ、各章末の「学び」だけ拾っても大丈夫です。
エピソード1｜表示が61%増えて、ガッツポーズした翌日
ある朝、Search Consoleを開いて、思わず声が出ました。表示回数、前の月から+61%。「よし、施策が効いてる」。スクショを撮って、report用のフォルダに入れました。
ところが翌日。ふと数字を見返すと、クリックがほとんど増えていない。問い合わせは、相変わらずゼロに近い。「……あれ? 表示は増えたのに、なんでだ?」
ここで、いったん立ち止まりました。表示の”合計”を信じるのをやめて、”内訳”を疑うことにしたんです。Claude Codeに、こう頼みました。
数分後、返ってきた表を見て、血の気が引きました。
増えていた表示・流入の大半は、うちのサービスとは関係の薄いワードでした。テーマの周辺にはかすっているけれど、うちを検討しているお客さんが打つ言葉ではない。数字（表示も流入）は確かに増えている——でも、増えたのは“うちに用のない人”だったんです。だから、来ても刺さらずに帰り、問い合わせにも申し込みにもつながらない。「増えた61%」の正体は、事業に効かない”数字だけの増加”でした。
そして本当にお金になる「比較」「料金」「費用」の検討クエリはどうか。平均18位台。2ページ目、3ページ目に沈んでいた。 検討しているお客さんの視界に、そもそも入っていなかったんです。
学び：表示回数でガッツポーズするな。 合計でなく内訳を疑う。この”疑う一手”が、分析でいちばん価値がある瞬間でした。
エピソード2｜”流入が多いページ”から手をつけようとして、やめた
方針は決まりました。「刈り取れない露出を追うのをやめて、検討クエリを1ページ目に上げる」。次は、どのページの順位を上げるかです。
最初、素直に「流入トップのページから順に上げよう」と思いました。アクセスが多いんだから、効くはず——と。危うく、そのまま走るところでした。
待てよ、と。流入トップのページを改めて見ると、うちのサービスとは畑違いの、周辺トピックの記事ばかり。アクセスは多いけど、1件も受注に繋がっていない”バニティ流入”でした。ここの順位を上げても、労力の割にリードは増えない。
そこでGA4のコンバージョン（資料DL・問い合わせ・CTAクリック）をページ単位で突き合わせました。すると——アクセスは地味なのに、ちゃんとリードを生んでいる面がいくつか浮かび上がった。伸ばすべきは、こっちだった。
学び：数字が大きいものに、人は引っ張られる。 「流入◯万」ではなく「このページからリードが何件出たか」を並べる。判断のよりどころを、流入からCVに差し替える。これだけで、優先順位が変わりました。
エピソード3｜競合を並列で調べさせたら、AIに堂々と嘘をつかれた
狙う面が決まったので、競合調査です。ここでClaude Codeの真骨頂——複数テーマを、サブエージェントに割り振って”同時並列”で調べさせる。「会計比較」「Salesforce費用」「データ基盤」「MA」。4体が一斉に動き出す。速い。気持ちいい。
……のですが。上がってきた報告を読んでいて、手が止まりました。 1体が、「このテーマの上位記事は、こういう構成です」と、実在しない競合の構成を、さも見てきたかのように、平然と書いていたんです。もっともらしい文章で。
ヒヤッとしました。もし報告を鵜呑みにして、その”存在しない競合”に勝つ記事を作っていたら——間違った地図で、全力疾走していたわけです。
対策は2つ入れました。ひとつは、プロンプトで「事実のみ・出典を明記・不確実なら”要確認”と書け・憶測は禁止」を厳命する。もうひとつは、親（自分）が全エージェントの報告を必ずレビューして、裏の取れない主張は棄却する。
学び：「AIに調べさせる」の本体は、速さじゃない。”AIの調査結果を疑う設計”の方です。並列で速く集めるほど、検証を組み込んでおかないと、間違いも高速で増えます。
エピソード4｜本番に反映したら、図がぐちゃぐちゃに壊れた日
競合調査で見えた”うちに足りない要素”——操作画面の視覚比較と、料金の型の可視化——を、オリジナルの図（SVG）で作って、比較記事に追記しました。本番に反映。「よし、リッチになった」。
公開ページを開いて、固まりました。図の中に、謎の改行と<br>タグが入り込んで、レイアウトが崩壊していたんです。せっかくの図が、ぐしゃぐしゃ。
原因を追うと、犯人はWordPressのwpautopでした。これは本文の改行を自動で段落や<br>に変換する機能なんですが、改行を含むSVGにも、お構いなしに<br>を突っ込んで壊す。
直し方は、拍子抜けするほど単純でした。SVGを1行化する（改行をゼロにする）。それだけで崩れなくなる。ただ、これに懲りて、工程も足しました。反映したら本番の描画結果を機械で取得して、SVGに<br>が混入していないかを毎回チェックする。目視じゃなく、機械で。
学び：本番は”性善説”で触らない。 「たぶん大丈夫」ではなく、「壊れたら自動で止まる」「壊れていないか反映後に機械で確認する」仕組みで守る。多くの記事を抱える本番サイトで、AIに書き込みを任せられるのは、この型があるからです。（そして、この”型”がコミットの世界でも命を救う——という話を、次にします。）
エピソード5｜1万3千ファイルを消しかけた日（push直前に、指が止まった）
これは、エピソード4の”本番を型で守る”が、なぜここまで大事かを、身をもって思い知った話です。
分析を助けるツール（打った施策とその効果を記録する簡単なボード）を、社内の大きなリポジトリに追加しようとしていました。リポジトリをクローンして、自分が作った3ファイルのフォルダを置いて、コミット。ここまでは、いつも通り。
コミットの結果を確認して、指が止まりました。
13,609 files changed, 315 insertions(+), 5,104,299 deletions(-)3ファイルを”追加”したはずが、1万3千ファイル・510万行を”削除”するコミットになっていた。もし気づかずに git push していたら、リポジトリの大半が消えていた。 背筋が凍りました。
原因はすぐ分かりました。Windowsのパス長制限（MAX_PATH）です。そのリポジトリは深い階層のファイルを大量に持っていて、クローンしたとき、Windowsが一部のファイルを作業ツリーに展開できなかった。展開されなかったファイルを、gitは「削除された」とみなす——だから自分の3ファイル追加に、大量の”見せかけの削除”が混ざってしまった。
助かったのは、たった一つの習慣のおかげでした。push する前に、必ずコミットの中身（git diff --cached --stat）を見る。 「13,609 files changed」という、明らかにおかしい数字で、手が止まった。
対処はこうです。まず壊れたクローンを捨てる。次にリモートが無事かを確認——origin/main が、いじる前のコミットのままか。無傷でした（pushしていないので当然ですが、確認するまで安心できない）。そして、フルクローンをやめて sparse-checkout でやり直す。これは「対象フォルダだけを作業ツリーに展開し、それ以外は”触らない（スキップ）”扱いにする」やり方。展開しないファイルは、”削除”ともみなされない。改めてステージして、差分が「3ファイル追加・削除ゼロ」であることを確認してからコミット。今度は綺麗に入りました。
学び：コミットも公開もpushも、AIでも人間でも、結局は”実行の直前に、差分を自分の目で見る”に尽きる。 特に、深い階層のリポジトリをWindowsで丸ごとクローンしてコミットするのは地雷。対象だけをsparseで取る。そして git diff --cached で、意図しない削除が混ざっていないかを、pushの前に必ず確認する。 ——エピソード4の”壊れたら止まる型”を、コミットの世界でも徹底する、という話でした。
エピソード6｜「このキーワードは、戦わない」と決めた瞬間
正直に書くと、悔しかった話です。「◯◯ 価格」で1ページ目を取りたかった。需要も大きい。でも競合調査の結果は残酷でした。上位は、公式サイトと大手比較ポータル（ボクシルやITreview型）の要塞。 うちが記事を1本磨いたくらいでは、びくともしない。
ここで、意地を張らずに決めました。「このヘッド語は、戦わない」。
代わりに、「◯◯ 費用 相場」「業種×ツール×費用」みたいな、具体的で長いキーワードに寄せた。調べると、ここは上位が中堅ブログばかりで、しかも”業種別の中身”を持っていない空白地帯だった。勝てる。
学び：分析の価値は、「やること」を見つけるのと同じくらい、「やらないこと」を見極めること。 勝てない戦いから降りる判断も、立派な分析結果です。全部に勝とうとすると、全部に負けます。
エピソード7｜ログを取り続けて半年、”判断”が資産になった
ここまでの話が単発の武勇伝で終わらないのは、すべての施策を、打つたびにログに残してきたからです。日付・何を・なぜ・結果。置き場は3つ——プロジェクトのdecisions.md、社内のナレッジベース、そしてgitのコミット履歴そのものが”改変ログ”。
このログの積み方は、嘘をつきません。実際、うちのエンジニアリング基盤は1年で3,000を超えるコミット、直近30日でも300超。ほぼ毎日、何かしらの変更が積まれている。「いつ・何を変えたか」が、全部追える状態です。
半年、これを続けて、何が変わったか。「あの時のあの判断、本当に効いたのか?」に、今の数字で答えられるようになったんです。
たとえば直近の数字。28日ぶんのクリックは、その前の28日と比べて約2.5倍に伸び、表示も増えました。——ただし、エピソード1の教訓があるので、「増えた」で終わらせません。内訳まで記録する。 実際、リードを本当に生んでいるのは特定のクラスタ（会計×AI連携）で、表示増の大半は例の”関係ないワード”（バニティ流入）。この”内訳の真実”まで残すから、次の一手を間違えない。
タイムラインで振り返ると、こんな半年でした。
| 時期 | やったこと | 起こした変化 |
|---|---|---|
| 5月中旬 | 検索意図起点でリライト（1本ずつ方針提示→合意→反映） | 2ページ目の記事を1ページ目へ |
| 6月上旬 | 記事資産を全体棚卸し。”数を広げる”段階から、”一本ずつ深く磨く”段階へ | 積み上げた記事資産を財産として、深掘りで上位を狙う方針に |
| 6月中旬 | CV導線を全社ロールアウト（汎用CTA→記事トピック一致CTA） | 記事の大半が一致導線に |
| 6月中旬 | 順位データで下位記事を底上げ（striking distance） | 2ページ目→1ページ目の押し上げ |
| 7月上旬 | 「量→質」へ完全転換。競合調査→独自の深掘り | CV-coreの権威を強化 |
| 7月中旬 | GSC×GA4を再診断→会計比較をリッチ化（本記事の施策） | 検討クエリの面を強化 |
学び：一度きりの分析は、時間が経つと”勘”に戻る。 でも「打った→ログした→測った→次の仮説に還した」を積むと、判断そのものが資産になる。これは、AIで分析と実装を速く回せるようになって、初めて現実的になった運用です。”自動化”の本当の価値は、この“歴史を積める状態”にありました。
おわりに｜速くなるほど、”判断”が主役になる
半年やってみて、いちばん腹落ちしたのはこれです。AIで作業が速くなるほど、ボトルネックは”作業量”から”意思決定の質”に移る。 数万クエリの仕分けも、競合調査も、本番反映も、一瞬で終わる。だから人間は、「どの面を狙うか」「この数字を信じるか」「ここは戦わない」という判断に、時間と頭を使えるようになる。
作業はAI、判断は人間。表示を疑い、AIを疑い、本番を型で守り、勝てない戦いから降りる。——このあたりの”生々しい判断”こそが、実務マーケターの腕の見せ所だと、今は思っています。この実録が、同じ壁の前に立っている誰かの、少しでも足しになれば。
関連ガイド（実践編シリーズ）
よくある質問
Q. Claude Codeでマーケ分析をするのにプログラミングの知識は必要ですか？
A. 日々の分析は自然言語の指示で回せます。GSC/GA4をMCPでつなぐ初期設定だけ一度整えれば、あとはコマンド操作なしで依頼できます。
Q. GA4やGSC、顧客データをAIに渡して安全ですか？
A. 読み取り専用でつなぎ、渡すデータの範囲を絞れば安全に使えます。本番への反映は、必ずバックアップと反映後チェックを通します。
Q. ChatGPTやCopilotとどう違いますか？
A. Claude Codeはデータ取得(MCP)から集計・可視化・記事への実装までを一つの流れで回せる点が強みです。
Q. 何から始めればよいですか？
A. 週次のGSC順位チェックなど定型作業を1つ選び、GSCをMCPでつないでその作業だけをAIに任せるところから始めます。
Claude Code × マーケDXの導入・設計のご相談
GSC/GA4/広告データをAIから安全に扱う仕組みづくり、Claude Code導入のスモールスタートまで支援します。無料のご相談から。
AI・業務自動化
ChatGPT・Claude APIを活用したAIエージェント開発、n8n・Difyによるワークフロー自動化で繰り返し業務を削減します。まずはどの業務をAI化できるか診断します。