NewsletterCTA が5,620PVを受けても登録0件だった実記録 — 「書き換えた」は「反映された」じゃなかった

結論

「CTAのコピーを書き換えた」という記録は正しかったが、書き換えたのは共通コンポーネント（NewsletterCTA.tsx）ではなく、特定記事のMDX本文に1箇所埋め込んでいた記述だった。

結果として、masatoman.net 全体で機能する NewsletterCTA のコピーは変わっておらず、5,620PVを受けた期間中にメルマガ登録は0件のままだった。

「オファーが刺さらない」と判断していたが、実際は「刺さる/刺さらない以前に、新しいコピーが一切表示されていなかった」という逆転の事実が2026-07-02に発覚した。

---

この記事の前提

• masatoman.net をNext.js + Supabase + Vercelで運用中
• メルマガ登録CTA（<NewsletterCTA />）は共通コンポーネントとして全記事末尾に自動描画される設計
• 記事の執筆・改修タスクの一部をClaude Code（AI agent）に委任している
• コピーの書き換えは「CTAのオファー文を変える」という指示でAIに依頼した

---

読者のよくある詰まり（「それ俺だ」を作る）

AIにコンポーネントの修正を依頼すると、「変更しました」という応答が返ってくる。ファイルの差分を見ると確かに文字列が変わっている。「じゃあ反映されてるな」と思って次の作業に進む。

これが落とし穴だった。

「どのファイルを変えたか」を確認しないまま、出力された結果だけを見て「変更完了」と記録してしまう。特に、コンポーネントが複数箇所に存在する場合や、MDX本文内にインライン記述と共通コンポーネント呼び出しが混在している場合に起きやすい。

---

実際に起きたこと

コードを掘ると原因はすぐ判明した。

AIが変更したのは content/articles/some-article.mdx 内に直接書いていた1箇所のインラインCTA文字列だった。共通コンポーネント src/components/mdx/NewsletterCTA.tsx は一切変更されていなかった。

変更されていた箇所	変更されていなかった箇所
特定記事のMDX本文内のインライン記述	NewsletterCTA.tsx（全記事に適用される共通コンポーネント）

本番の全記事末尾に描画されているのは NewsletterCTA.tsx だ。そのファイルは変わっていない以上、サイト上のどのページでも旧コピーが表示され続けていた。

---

原因分析

直接原因: AIへの指示が「CTAのコピーを書き換えて」という曖昧な依頼だったため、AIはMDX本文内のインライン文字列を変更対象と解釈して処理した。共通コンポーネントのパスを明示しなかった。

構造的原因: 変更完了後に「どのファイルが変わったか」を検証するステップがなかった。Gitのdiffを見ていれば NewsletterCTA.tsx が変更リストに含まれていないことで即座に気づけた。

見落としの構造: AIは「書き換えた」と正直に報告している。問題は「何を書き換えたか」の確認がなかったことで、その盲点が数週間の機会損失を生んだ。

---

判断軸（読者が当てはめられる形）

「AIに任せた変更」には、変更後の実態確認をセットにする。

具体的には以下の順で確認する：

1. どのファイルが変わったか → git diff --name-only HEAD~1 で変更ファイル一覧を確認
2. 意図したファイルが含まれているか → 共通コンポーネントを変えたいなら、そのファイル名がdiffに含まれているか
3. 本番で目視確認する → Vercel Previewまたは本番URLで実際の表示を見る

今回の件で加えたルール：「共通コンポーネントの変更指示はファイルパスを必ず明示する（src/components/mdx/NewsletterCTA.tsx）」。AIは指示された範囲で作業するので、範囲を曖昧にすると最も近い解釈でファイルを選ぶ。それが意図と一致するかは人間が確認する責任がある。

---

今日やること（3つ以内）

1. 共通コンポーネント変更の指示には必ずファイルパスを明示する（src/components/ 配下のファイルは特に）
2. 変更後に git diff --name-only でどのファイルが変わったかを必ず確認する
3. CTAやフォームなど「表示して初めてわかる」箇所は本番またはPreviewで目視確認するステップをワークフローに組む

---