【実録】Claude Codeでマーケ分析を立て直した半年｜表示が増えて喜んだ翌日、AIに嘘をつかれ、本番を壊しかけた話

これは、うちのSEO/マーケ運用を、Claude Codeを相棒に立て直していった”実録”です。きれいな成功談だけを書くつもりはありません。表示回数が増えてガッツポーズした翌日にがっかりした話、AIに堂々と嘘をつかれた話、本番サイトの図をぐちゃぐちゃに壊した日の話——全部、順番に書きます。同じ壁にぶつかっている実務マーケターの、”あるある”の答え合わせになれば。

読み方：各エピソードは「症状 → うわ、となった瞬間 → 原因 → 直し方 → 学び」で書いています。忙しければ、各章末の「学び」だけ拾っても大丈夫です。

——本題の”実録”に入る前に、まず全体像です。私たちは、集客から商談・提案、そして社内ナレッジの蓄積までを、Claudeと各種ツールでひとつながりに回しています（下図）。この記事は、その中でも「マーケティング分析」を立て直していった部分の、失敗も含めた記録です。個々の実践編（提案・要件定義、スキル化、定例レポート、セキュリティ…）は、全体像のハブ記事にまとめています。

エピソード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連携）で、表示増の大半は例の”関係ないワード”（バニティ流入）。この”内訳の真実”まで残すから、次の一手を間違えない。

タイムラインで振り返ると、こんな半年でした。

学び：一度きりの分析は、時間が経つと”勘”に戻る。 でも「打った→ログした→測った→次の仮説に還した」を積むと、判断そのものが資産になる。これは、AIで分析と実装を速く回せるようになって、初めて現実的になった運用です。”自動化”の本当の価値は、この“歴史を積める状態”にありました。

おわりに｜速くなるほど、”判断”が主役になる

半年やってみて、いちばん腹落ちしたのはこれです。AIで作業が速くなるほど、ボトルネックは”作業量”から”意思決定の質”に移る。 数万クエリの仕分けも、競合調査も、本番反映も、一瞬で終わる。だから人間は、「どの面を狙うか」「この数字を信じるか」「ここは戦わない」という判断に、時間と頭を使えるようになる。

作業はAI、判断は人間。表示を疑い、AIを疑い、本番を型で守り、勝てない戦いから降りる。——このあたりの”生々しい判断”こそが、実務マーケターの腕の見せ所だと、今は思っています。この実録が、同じ壁の前に立っている誰かの、少しでも足しになれば。

関連ガイド（実践編シリーズ）

• 実践編②：提案資料と要件定義もAIで回す
• AI認証・データ連携のセキュリティレビュー
• 定例資料の自動化

よくある質問