記事公開前の収益チェックを自動化する: Claude Codeで導線の取りこぼしを防ぐ

ある朝、アクセス解析を開いて固まりました。前日に公開した記事のPVは普段の3倍。なのに、無料PDFの登録は0件、教材のクリックも0件。「バズったのに1円も動いていない」状態です。

調べたら原因はしょうもないものでした。記事末尾の申し込みボタンのリンク先が、半年前に閉じた古い商品ページのまま。さらに英語版の記事は本文の途中から英語に切り替わっていて、海外からの読者はそこで離脱していました。本文はちゃんと書けていたのに、最後の数行で全部こぼしていたわけです。

それ以来、僕は「記事を書く作業」と「公開していい状態か確かめる作業」を完全に分けました。後者を毎回手でやると必ずサボるので、Claude Codeに型として持たせています。今日はその中身を、コピペできる形で全部出します。

この記事の要点

• PVが増えても申し込みが増えない原因の多くは、リンク切れ・古い商品ページ・英語のままの本文といった「公開前なら気づけたミス」です。
• 公開前に見る項目を9個に固定し、毎回同じ順番で確認すると取りこぼしが激減します。
• Claude Codeに任せるのは「ページを開いて項目を機械的に確認する」ところ。どのボタンを主役にするかは人が決めます。
• 申し込みボタンを1記事に1つへ絞るだけで、読者が迷わなくなり次の行動につながりやすくなります。
• 確認した内容をログに残すと、後から「何を根拠に公開したか」をたどれます。

公開前に見る9項目を決める

「ちゃんと確認して」では人もAIも何もしません。確認とは具体的な項目のリストです。僕が固定しているのは次の9つです。

#	確認項目	見るポイント
1	ページが開くか	サーバーが200を返すか（404や500でないか）
2	見出しが正しいか	ページ上部の大見出しが記事タイトルと一致しているか
3	URLの正規指定	正規URLの指定が、その記事自身のURLになっているか
4	アイキャッチ画像	画像が表示されるか（古い画像や画像なしでないか）
5	本文の言語	各言語版で、冒頭からその言語で書かれているか
6	無料PDFの案内	登録ボタンが存在し、リンク先が生きているか
7	教材リンク	リンク先が意図した商品ページか（別商品に飛ばないか）
8	相談ページへの導線	リンク先が相談ページになっているか
9	スマホ表示	横スクロールが出ていないか（はみ出しがないか）

ポイントは3番と7番です。正規URLの指定がトップページや別記事を指していると、検索エンジンがそちらを正として扱い、せっかくの記事が評価されません。リンク先の取り違えは、コピペで作った記事ほど起きます。

AIに任せる範囲と、人が決める範囲

ここを混ぜると事故ります。線引きをはっきりさせます。

Claude Codeに任せることは、機械的に判定できる確認です。ページを開く、見出しを読み取る、リンク先を取得する、画像が表示されるかを見る、スマホ幅でレイアウトを確認する。ここは人がやるとダルいし、ダルいと飛ばすので、AIに毎回やらせます。

人が決めることは、判断が要る部分です。今回の記事で主役にするボタンはどれか。本文の言い回しが自然か。古い商品を案内していないか。そして「この記事は本当に公開していいのか」という最終判断。ここをAIに丸投げすると、リンクは生きているけど中身がズレた記事が世に出ます。

迷ったときの基準はシンプルです。正解が一意に決まることはAI、好みや戦略が絡むことは人。リンクが200を返すかは一意に決まるのでAI。3つあるボタンのどれを目立たせるかは戦略なので人、です。

コピペで使う指示文の雛形

Claude Codeにそのまま貼れる指示文です。リポジトリ名と確認したいURLだけ自分のものに差し替えてください。

次のURLそれぞれについて、公開前チェックを実行してください。
ページが200で開くこと、大見出しが記事タイトルと一致すること、
正規URLの指定が同じ記事を指すこと、アイキャッチ画像が表示されること、
本文がその言語で書かれていること、無料PDFの登録ボタンが生きていること、
教材リンクが意図した商品ページに飛ぶこと、相談ページへのリンクが正しいこと、
スマホ幅で横スクロールが出ないことを確認します。

各URLについて1行で、合格した項目と落ちた項目を分けて報告してください。
「200で開いた」だけで合格にしないでください。落ちた項目があれば、
原因の見当と、どのファイルを直せばよいかも書いてください。

最後の2文が肝です。「200で開いた=OK」で止めると、いちばん多いリンク取り違えを見逃します。落ちた項目を必ず分けて報告させ、直す場所まで言わせると、そのまま修正に入れます。

コピペで動く判定スクリプト

確認結果をまとめて「公開していいか」を機械的に返す部分は、コードにしておくと毎回ブレません。Node.jsで動く最小版です。

// 公開前に必ず通したい9項目
const requiredChecks = [
  "ページが200で開く",
  "大見出しが記事タイトルと一致",
  "正規URLの指定が同じ記事を指す",
  "アイキャッチ画像が表示される",
  "本文がその言語で書かれている",
  "無料PDFの登録ボタンが生きている",
  "教材リンクが意図した商品ページ",
  "相談ページへのリンクが正しい",
  "スマホ幅で横スクロールなし",
];

// passed には合格した項目名の配列を渡す
function summarizeSmokeResult(passed) {
  const missing = requiredChecks.filter((check) => !passed.includes(check));
  return {
    ok: missing.length === 0,
    missing,
    nextAction: missing.length === 0 ? "公開してよい" : "修正してから再確認",
  };
}

// 動作例：教材リンクだけ落ちたケース
const passed = requiredChecks.filter((c) => c !== "教材リンクが意図した商品ページ");
const result = summarizeSmokeResult(passed);

console.log(result.ok ? "公開OK" : "公開NG");
console.log("落ちた項目:", result.missing);
console.log("次の行動:", result.nextAction);

このスクリプトを実行すると、公開NG と落ちた項目名、次にやることが表示されます。1項目でも欠けていれば ok は false になるので、「だいたいOK」で公開する事故が起きません。passed 配列を、先ほどの指示文でAIに確認させた結果で埋めるだけです。

実際に効いた3つの場面

1. 1日に複数本を公開する日 3本まとめて出す日は、確認が雑になりがちです。各記事を1本ずつスマホ幅で開き、見出し・本文冒頭・申し込みボタンの近くまでスクロールして見ます。英語以外の版で本文が英語のままなら、その時点で公開を止めます。雑になりやすい日ほど、固定リストが効きます。

2. 人気記事のボタンだけ差し替えるとき よく読まれている記事の末尾ボタンを1つ変えるだけでも、「関連する部品を探して直して」とだけ頼むのは広すぎます。先に、触ってよいファイル・触らないファイル・確認するURL・各リンク先を決めます。これだけで、作業後の確認が「なんとなく良さそう」から「この証拠なら公開できる」に変わります。

3. 多言語記事の品質確認 記事の設定上の言語指定が正しくても、本文が英語のままなら公開品質ではありません。各言語で大見出し・本文冒頭・ボタン付近を見て、その言語の読者が次に何をすればいいか分かるかを確認します。日本語読者なら、無料PDFの説明も教材への案内も相談への誘導も、日本語で自然に読めている必要があります。

ありがちな落とし穴と直し方

落とし穴1: ローカルでビルドが通っただけで「公開できた」と報告する 手元でビルドが成功しても、公開先のページが正しく表示されるとは限りません。直し方は、確認の対象を「ローカルのビルド結果」ではなく「公開URLの実物」にすること。AIにも「公開URLを開いて確認して」と明示します。

落とし穴2: 申し込みボタンを全部並べてしまう 無料PDF・教材A・教材B・相談を同じ大きさで並べると、読者はどれを押せばいいか分からず、結局どれも押しません。直し方は、1記事につき主役のボタンを1つに決め、残りは控えめな補助に回すこと。

落とし穴3: リンク先が別商品に飛ぶ 「無料PDF」と書いてあるのにクリックすると有料教材に飛ぶ、というのはコピペ記事で頻発します。直し方は、確認項目7のリンク先取得をAIに必ずやらせ、商品IDまで目視で照合すること。

落とし穴4: 戻し方を決めずに大きく直す 公開直前に広範囲を書き換えて、おかしくなっても元に戻せない、が最悪です。直し方は、1回の作業で「もし変なら元に戻す手順」を先に用意できる範囲に絞ること。戻し方が書けない作業は、その回には大きすぎます。

よくある質問

Q. PVは増えたのに申し込みが増えません。まず何を見ればいいですか。 A. 申し込みボタンのリンク先と、本文の言語をまず見てください。リンク先が古い商品ページのまま、または海外読者向けの版が英語になっていない、というのが二大原因です。公開前チェックの項目5・6・7に当たります。

Q. この確認は毎回必要ですか。面倒です。 A. 毎回必要です。だからこそ手でやらず、本記事の指示文をClaude Codeに渡して機械的にやらせます。面倒な確認ほど、人は忙しい日に飛ばします。飛ばした日に限って事故ります。

Q. ボタンを1つに絞ると、他の商品への入口が減りませんか。 A. 入口の数より、読者が迷わず1つ押せるかが大事です。複数並べると選べずに離脱します。主役を1つ決め、補助リンクは記事中に自然に1〜2本だけ置くのがちょうどいいバランスです。

Q. 正規URLの指定がなぜそんなに大事なのですか。 A. 検索エンジンは、正規URLとして指定されたページを「正」として評価します。ここが別記事やトップページを指していると、書いた記事ではなく別ページが評価され、検索順位もそちらに集まってしまいます。

Q. 確認ログは何のために残すのですか。 A. 後から「何を根拠に公開したか」をたどるためです。問題が起きたとき、本文・ボタン・リンク・相談導線のどこで落ちたかを切り分けやすくなります。残っていないと、次の運用でゼロから確認し直すことになります。

確認した内容を1枚に残す

公開後に短いメモを残しておくと、次回の確認が一気に楽になります。次のような形で十分です。

- 記事: claude-code-revenue-smoke-test
- 公開日: 2026-06-14
- 確認した証拠: 公開URL, 大見出し, 正規URL指定, アイキャッチ, 本文の言語, ボタンのリンク先
- 主役ボタン: 教材リンク（自走する読者向け）
- 次に見る数字: PV, PDF登録, 教材クリック, 相談ページ遷移

数字を見るときも、PVだけで判断しません。無料PDFの登録、教材のクリック、相談ページへの遷移を同じ日付で並べます。初心者向けの記事ならPDF登録が、設定や権限を扱う記事なら教材クリックが増えるはず、という仮説と突き合わせます。この習慣があると、毎日の投稿が「ただ出す作業」から「導線を少しずつ直す仕組み」に変わります。

このあたりの「機械に任せる確認」と「人が決める判断」の線引きは、収益チェック以外でも同じ考え方が使えます。非エンジニアがClaude Codeを使うときの全体像はClaude Codeを非エンジニアが使う方法に、毎日の作業を速くする小ワザはClaude Code 生産性アップのコツにまとめています。確認をAIに正しく頼むには指示文の精度が要るので、Claude Code プロンプト実践テクニックも合わせて読むと効きます。

なお、AIにファイルを読ませる・リンクを確認させるといった処理の前提になる仕組みは、公式のClaude Docsで確認できます。挙動が変わったと感じたら、まず一次情報を見るのが結局いちばん速いです。

実際に試した結果

この型を自分のサイトで2週間ほど回しました。確かめたかったのは「公開前の9項目チェックが、本当に取りこぼしを減らすのか」です。

結果、ページが200で開くことだけを見ていた頃には素通りしていた問題が、複数見つかりました。具体的には、別記事のアイキャッチを流用したまま公開しようとしていたケースが2本、申し込みボタンのリンク先が古い商品を指していたケースが1本、英語版の本文が途中から日本語のままだったケースが1本です。どれも「200で開く」だけなら合格扱いだったものです。

特に効いたのは、申し込みボタンを1記事1つに絞る運用でした。無料PDF・教材・相談を同じ重さで並べていた記事を、主役1つに整理し直したところ、ボタンのクリック率が目に見えて上がりました。読者は選択肢が少ないほうが動く、というのを数字で実感しました。

逆に分かったのは、この確認は手作業だと続かないということです。最初の数日は手でやっていましたが、忙しい日にあっさり飛ばしました。指示文とスクリプトの形にして毎回同じ手順で回すようにしてから、ようやく定着しました。

公開前の地味な確認を仕組みにしておく。これが、PVを収益につなげる一番安い保険でした。もし会社のブログ運用やチームでの公開フローに組み込みたいなら、研修・相談で実際の運用に合わせた型を一緒に設計できます。