Claude Code検証レシート運用: AIの変更をビルド、公開URL、CTAまで確認する

なぜ検証レシートが必要なのか

Claude Codeに記事、LP、購入導線の修正を任せると、差分だけを見る限りはうまくいったように見えることがあります。けれども公開記事の品質で怖いのは、コードや本文が書き換わったことではなく、読者が実際に通る画面で壊れていることに気づかないまま公開してしまうことです。ローカルのビルド成功は重要ですが、それだけでは公開URL、CTA、フォーム送信後の遷移、スクリーンショット上の見た目までは保証しません。

そこで使うのが「検証レシート」です。検証レシートとは、AIに任せた変更について「何を変えたか」「どのコマンドで確認したか」「公開URLで何を見たか」「収益導線が残っているか」「残るリスクは何か」を短く残す作業メモです。領収書のようにあとから見返せるため、翌日の修正、レビュー、問い合わせ対応で迷いにくくなります。特にClaude Codeのように作業が速い道具ほど、完了報告をそのまま信じるのではなく、証拠を揃える習慣が効きます。

この記事は、ビルドエラー切り分け、レビュー運用チェックリスト、権限監査チェックリストと合わせて使うと効果的です。ビルドで止まったとき、レビュー観点を増やしたいとき、権限の広げすぎを避けたいときに、それぞれ役割が分かれます。

検証レシートのテンプレート

まずは下の形を、そのままPRコメント、作業ログ、Claude Codeへの最終確認プロンプトに貼り付けます。大事なのは、感想ではなく観測した事実を書くことです。「問題なさそう」ではなく、「npm.cmd run build が成功した」「公開URLのh1に期待文字列があった」「CTAのリンク先がGumroadの該当ページだった」という粒度にします。

Verification Receipt

Scope:
- changed files:
- user-facing behavior:
- out of scope:

Diff summary:
- what changed:
- why it changed:
- what should not change:

Proof commands:
- git status --short:
- git diff --stat:
- npm.cmd run build:

Public URL checks:
- article URL:
- expected h1:
- canonical:
- no fallback page:

Revenue and CTA checks:
- free PDF CTA:
- Gumroad product link:
- consultation link:
- thanks page or next step:

Screenshot checks:
- desktop screenshot:
- mobile screenshot:
- visible CTA:
- text overflow or broken layout:

Remaining risk:
- risk 1:
- risk 2:
- risk 3:

「out of scope」を入れておくと、Claude Codeが関係ないファイルまで直そうとする事故を減らせます。「what should not change」には、slug、canonical、CTA、商品リンク、著者名、公開日などを入れます。記事改善では本文を伸ばすことに集中していて、OGP画像や内部リンクを壊すことがあります。検証レシートは、そういう見落としを最後に拾うための足場です。

build、公開URL、CTA、スクショ確認の具体例

最初の確認はPowerShellで十分です。差分の量を見て、対象ファイルが意図通りかを確認し、サイトのビルドを通します。Windows環境ではnpm.cmdを使うと、シェルによる解決差を避けやすくなります。

git status --short
git diff --stat
cd site
npm.cmd run build

次に公開URLを確認します。HTTP 200だけでは不十分です。静的サイトでは、存在しないページでもトップページやfallback HTMLが返ることがあります。h1、期待する本文、CTA文言、商品導線を文字列として確認します。

const checks = [
  {
    url: "https://claudecode-lab.com/blog/claude-code-verification-receipt-workflow/",
    mustInclude: ["Claude Code検証レシート運用", "検証レシートのテンプレート", "Gumroad"],
  },
  {
    url: "https://claudecode-lab.com/en/products/",
    mustInclude: ["Claude Code", "Products"],
  },
  {
    url: "https://claudecode-lab.com/training/",
    mustInclude: ["相談"],
  },
];

for (const check of checks) {
  const res = await fetch(check.url, { redirect: "follow" });
  const html = await res.text();
  const missing = check.mustInclude.filter((text) => !html.includes(text));
  console.log(check.url, res.status, missing.length === 0 ? "ok" : `missing: ${missing.join(", ")}`);
}

最後にスクリーンショットを取ります。これは見た目の証拠です。文字列チェックで通っていても、スマホ幅でCTAが折れすぎていたり、ボタンが隠れていたり、翻訳文がカードからはみ出していたりします。Playwrightが入っているプロジェクトなら、次のようにデスクトップとモバイルを残します。

import { chromium } from "playwright";
import { mkdir } from "node:fs/promises";

const outDir = "tmp-verification/claude-code-verification-receipt-workflow";
await mkdir(outDir, { recursive: true });

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 1100 } });
await page.goto("https://claudecode-lab.com/blog/claude-code-verification-receipt-workflow/", {
  waitUntil: "networkidle",
});
await page.screenshot({ path: `${outDir}/desktop.png`, fullPage: true });

await page.setViewportSize({ width: 390, height: 1200 });
await page.screenshot({ path: `${outDir}/mobile.png`, fullPage: true });

await browser.close();
console.log(`screenshots saved to ${outDir}`);

スクショ確認では、上部のh1、最初の3行、記事中盤のコードブロック、末尾のCTAを見ます。記事が長くなったときほど、冒頭と末尾だけを見て安心しがちです。コードブロックが横スクロールで読めるか、表やリストの余白が壊れていないか、モバイルで内部リンクが詰まりすぎていないかを見ます。

実例1: 記事本文を増強したとき

薄い記事を伸ばす場合、検証レシートの主役は「文字数」ではありません。本文が増えた結果として、検索意図に答えているか、導入文で離脱されないか、見出しの階層が自然か、コード例が実際に動くかを確認します。たとえば今回のようなClaude Code運用記事なら、単に「検証しましょう」と書くだけでは弱いです。読者がコピーして使えるテンプレート、build確認、公開URL確認、CTA確認、スクショ確認まで揃って初めて実務記事になります。

このケースのレシートには、変更ファイル、追加した見出し、文字数の目安、内部リンク、外部リンク、コードブロックの種類を書きます。さらに、商品導線が不自然になっていないかも見ます。記事の最後でいきなり有料教材に飛ばすより、無料PDFで日次チェックを試し、Gumroad教材で型を増やし、チーム導入や収益導線が絡む場合は相談へ進む、という順序のほうが自然です。

実例2: CTAや商品リンクを変えたとき

CTAを変えたときは、クリック先の確認までが作業です。本文のボタン文言を直しても、リンク先が古い商品、英語ページ、404、別カテゴリのLPになっていれば成果は落ちます。検証レシートでは、CTAの表示文言、href、遷移先のタイトル、購入や登録の次ステップを残します。無料PDFなら、フォームの送信後ページやダウンロード案内まで確認対象にします。Gumroadなら、商品名、価格表示、説明文の先頭が意図と合っているかを見ます。

相談導線も同じです。読者が「自分のチームで運用したい」と感じた直後に相談ページへ行けるか、リンク文言が押し売りになっていないか、記事の文脈と合っているかを確認します。Claude Codeの運用記事では、教材だけではなく、現場の権限設計、レビュー基準、公開前チェックを一緒に決める相談ニーズが自然に出てきます。

実例3: 多言語記事を公開したとき

多言語記事では、英語版だけを見て安心すると失敗します。日本語では自然なCTAでも、韓国語やスペイン語では不自然に長くなり、モバイルで折れすぎることがあります。中国語やヒンディー語では、用語の説明が直訳すぎると読者が手順を誤解します。検証レシートには、各言語の冒頭、テンプレート、失敗例、教材への導線を確認したかを書きます。

特に「verification receipt」は、日本語では「検証レシート」として説明を添えれば伝わりますが、言語によっては「検証ログ」「証跡メモ」に近い表現を使うほうが自然です。翻訳で意味を揃えることと、現地語として読みやすくすることは別の作業です。スクショはこの差を見つけるためにも役立ちます。

よくある失敗例と避け方

一つ目の失敗は、HTTP 200を公開確認とみなすことです。ページが存在しなくても、fallback HTMLが返ってくるサイトはあります。必ずh1、slug、本文の固有語、canonicalを見ます。

二つ目の失敗は、ローカルビルドで止めることです。ビルドが通っても、デプロイが古いキャッシュを返す、公開先の環境変数だけ違う、画像パスだけ壊れる、ということはあります。公開URLの確認を別枠にします。

三つ目の失敗は、CTA確認を「リンクがある」で終えることです。リンクがあることと、読者が次に進めることは違います。ボタン文言、リンク先、遷移後の説明、購入や相談の入口まで見ます。

四つ目の失敗は、スクショを残さないことです。翌日に「本当にモバイルで見たか」を思い出せません。画像を残しておくと、レビュー担当者や未来の自分が同じ前提で会話できます。

五つ目の失敗は、Claude Codeに「問題ないか確認して」とだけ頼むことです。これでは確認範囲が曖昧です。テンプレートを渡し、項目ごとに証拠を返させます。

教材と相談への自然な導線

この検証レシート運用を最小で始めるなら、まずは無料のClaude Codeチートシートで、日次の確認コマンドと安全な頼み方を固めるのが現実的です。毎回の確認で同じ抜け漏れが出るなら、GumroadのプロンプトテンプレートやSetup Guideを使い、CLAUDE.md、hooks、権限設定、レビュー依頼文まで型にします。

チームで公開記事、LP、教材販売、相談フォームを扱うなら、個人の頑張りだけでは限界があります。誰が公開URLを見るか、どのCTAを収益導線として守るか、スクショをどこに保存するか、どの失敗を公開停止条件にするかを先に決めたほうが安全です。そうした設計まで含めたい場合は、相談で検証基準を一緒に作るのが向いています。

• 無料Claude Codeチートシート
• 50個のClaude Codeプロンプトテンプレート
• Claude Code Setup Guide
• 商品一覧
• 導入相談

この記事で紹介した内容を実際に試した結果

この記事では、差分確認、build、公開URL、CTA、スクショ確認を一つの検証レシートにまとめる形にしました。実際にこの形で作業すると、「ビルドは通ったが公開URLは未確認」「CTAは見たが相談リンクは見ていない」「スクショはデスクトップだけ」という抜けがすぐ見えるようになります。Claude Codeの速度を活かすには、速く書かせるだけでなく、速く証拠を残すことが重要です。検証レシートは、そのための軽い運用ルールです。