Claude Codeの作業完了を証拠で残す検証チェックリスト

金曜の夜、僕はClaude Codeに「記事を1本書いて公開まで通しといて」と頼んで寝ました。翌朝ログを見たら「完了しました。記事を公開しました」と自信たっぷりに書いてある。安心して公開URLを開いたら、表示されていたのは前の記事のタイトルでした。

ビルドは通っていた。URLも200を返していた。でも、h1タグは別のページのまま。差分の確認をAIに任せきりにして、僕は「動いた」という言葉だけを信じていたんです。

このとき気づいたのは、つまずいているのはClaude Codeの賢さではなく、僕の「作業の閉じ方」だということでした。AIに任せる範囲を広げるほど、終わったあとに「本当に何が確かめられたのか」を自分の手元に残さないと、嘘の完了報告に毎回ひっかかります。

この記事では、その「証拠を残す型」を、コピペできるコードと一緒に紹介します。

この記事の要点

• AIの「できました」を信じない。ビルド・公開URL・h1・導線まで、機械で確かめた証拠だけを完了の根拠にする。
• 編集を始める前に「今回の作業で何を確かめるか」を一文で決め、検証コマンドも先に決めておく。
• 公開後は毎回同じ順番（h1 → canonical → 本文冒頭 → 導線）で目視する。順番を固定すると見落としが減る。
• 証拠（スクショ・URL・次に見る数字）を一行のメモに残すと、翌日の自分や自動運用が同じ判断をやり直さずに済む。
• 完璧な記事を一度で出すより、翌日に検証できる記事を出すほうが、運用としては強い。

なぜ「できました」だけだと事故るのか

Claude Codeは作業の途中経過を文章で要約してくれます。これがやっかいで、要約は本当にうまくいったときも、うまくいかなかったときも、だいたい同じ顔で返ってきます。

ビルドが通ったというのは「構文が壊れていない」だけの証拠です。公開URLが200を返すのも「サーバーが何かを返した」だけ。その何かが、今回作ったはずの記事かどうかは、別の話なんですね。

僕の金曜の事故も、ビルドと200は両方クリアしていました。崩れていたのは、URLとページの中身が一致しているか、という一点だけ。ここを誰も見ていなかった。

だから完了の判断は、AIの言葉ではなく、自分が決めた確認項目を一つずつ潰した結果に置きます。確認の進め方の土台が不安なら、先にClaude Codeの始め方で基本の流れをそろえておくと、この記事の手順が入りやすくなります。

15分で回す検証ループ

毎回ばらばらの手順で確認すると、忙しい日に必ずどこかを飛ばします。順番を固定して、頭を使わずに回せる形にします。

1. 今回の作業で「何が確かめられれば完了か」を一文で書く。例:「この slug の記事が、正しいh1で公開URLに出ていること」。
2. 編集を始める前に、確認に使うコマンド（ビルドや差分表示）を決めておく。終わってから探さない。
3. 変更したら、差分 → ビルド → 公開URLの順に見る。途中で気が変わってもこの順番は崩さない。
4. 公開URLでh1・canonical・本文の冒頭・導線が、想定どおり並んでいるかを目で見る。
5. 残ったリスクと「次にやる最小の一手」を一行だけメモに残す。

ここで大事なのは、AIに任せる範囲と、人が決める範囲を最初に切り分けることです。

工程	AIに任せてよい	人が判断する
ネタ選び	既存タイトルを読んで候補を出す	最終的にどれを書くか
執筆	本文・コード・見出しの草稿	嘘や古い情報が混じっていないか
検証	ビルド実行・差分の要約	公開URLの中身が正しいかの最終確認
公開	公開コマンドの実行	削除・本番反映など戻せない操作の承認

戻せない操作だけは、最初は全部「人に聞く」に倒しておく。安全だと分かった操作から、あとで自動に格上げします。この線引きの考え方は権限管理ガイドで詳しく整理しています。

コピペで使える依頼文の雛形

検証を毎回ゼロから言葉にすると、その日の気分で抜けが出ます。Claude Codeに渡す依頼文を型にしておくと、確認項目が安定します。

この記事を公開しました。完了報告の前に、次を確かめて結果を表で返してください。
- ビルドは成功したか（コマンドと終了コードも書く）
- 公開URLのh1が、今回のslugの記事タイトルと一致しているか
- canonicalが同じslugを指しているか
- 本文冒頭が、前の記事やトップページの使い回しになっていないか
- 導線（無料PDF・教材・相談）が読者の状況に合った順番で並んでいるか
確認できなかった項目は「未確認」と正直に書いてください。推測で「OK」と書かない。

最後の一文が効きます。「推測でOKと書かない」と明示しないと、AIは確認していない項目まで、なんとなく良い顔で「問題なし」と返してきます。依頼文の組み立て方そのものを底上げしたいなら、プロンプト設計の応用も合わせて読んでみてください。

コピペで動く検証スクリプト

ここが今日の本体です。公開URLを取りに行って、h1が想定のタイトルかどうかを機械的に判定します。Node.js（18以上）だけで動きます。AIの「できました」ではなく、このスクリプトの判定を完了の根拠にします。

// verify-publish.mjs
// 使い方: node verify-publish.mjs <公開URL> "<期待するh1タイトル>"
// 例: node verify-publish.mjs https://claudecode-lab.com/ja/blog/foo/ "記事タイトル"

const [url, expectedH1] = process.argv.slice(2);

if (!url || !expectedH1) {
  console.error("URLと期待するh1タイトルの2つを渡してください。");
  process.exit(2);
}

// 公開ページを取得する
const res = await fetch(url, { redirect: "follow" });
const html = await res.text();

// h1とcanonicalをざっくり抜き出す（厳密なパーサは不要）
const h1 = (html.match(/<h1[^>]*>(.*?)<\/h1>/is)?.[1] ?? "")
  .replace(/<[^>]+>/g, "")
  .trim();
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]+href=["']([^"']+)["']/i)?.[1] ?? "";

// 一つずつ確認項目を潰す
const checks = {
  http200: res.status === 200,
  h1一致: h1 === expectedH1,
  canonical一致: canonical.includes(new URL(url).pathname),
};

console.table(checks);

const allOk = Object.values(checks).every(Boolean);
if (!allOk) {
  console.error("未確認または不一致の項目があります。公開はまだ完了扱いにしない。");
  console.error(`取得したh1: ${h1 || "（空）"}`);
  process.exit(1);
}

console.log("証拠そろいました。完了扱いにしてよいです。");

実行はこれだけです。

node verify-publish.mjs https://claudecode-lab.com/ja/blog/foo/ "記事タイトル"

h1一致 が false なら、まさに僕の金曜の事故と同じ状態です。URLは生きているのに中身が違う。終了コードが0でないかぎり、公開は「完了」と呼ばない。これをルールにするだけで、嘘の完了報告が手前で止まります。

こんな場面で効く

1. 記事の公開作業 HTTP 200だけを成功と勘違いしがちな場面です。上のスクリプトでh1とcanonicalが同じslugを指すか確かめれば、前の記事の使い回しや、トップページへのフォールバックを公開前に弾けます。

2. 導線（CTA）の差し替え 無料PDFや教材へのボタンを動かしたら、スクショと「次に見る数字」を同じメモ行に残します。あとで「あの変更で登録は増えたのか」を、記憶ではなく記録で追えるようになります。

3. 設定や権限の変更 CLAUDE.mdや権限の設定を変えたときこそ、変更前後で同じ検証コマンドを通します。設定の書き方に不安が残るなら、CLAUDE.mdの書き方を先に整えておくと、検証の前提がそろいます。

落とし穴と、その直し方

正直に書くと、僕はこの型に落ち着くまで何度も同じ穴に落ちました。

ひとつ目は、一度の作業で全部を直そうとして、確認できないほど大きな差分を作ること。40ファイル動いた差分は、人もAIも読み切れません。直し方は単純で、一回の作業で確かめることを一文に絞る。確かめきれない大きさになったら、作業を分割します。

ふたつ目は、ローカルのビルドが通った時点で完了扱いにすること。ローカルで動くことと、公開URLに正しく出ることは別です。直し方は、上のスクリプトを公開後に必ず一回通すこと。これを手順に組み込むまでは、僕も何度も中身違いを公開しました。

みっつ目は、導線を増やすだけで、読者がどこへ進めばいいか説明しないこと。ボタンを3つ並べても、選べなければ意味がありません。直し方は、読者の状況（まだ操作が不安／繰り返し作業で疲れている／チーム導入を考えている）ごとに、どの導線が合うかを本文で一言添えることです。

よくある質問

Q. ビルドが通れば、それで完了でいいのでは？ ビルドは構文が壊れていない証拠でしかありません。公開URLの中身が今回の記事かどうかは別問題です。h1とcanonicalまで見て初めて完了です。

Q. 検証スクリプトは毎回手で動かすんですか？ 最初は手で十分です。手順が安定してきたら、公開コマンドの直後に自動で走らせる形に育てます。終了コードが0でなければ公開を止める、という運用にすると事故が減ります。

Q. AIに検証も全部任せてはダメですか？ 読む・要約する作業は任せていいです。ただし「公開URLの中身が正しいか」の最終判断と、戻せない操作の承認は人が持ちます。ここを渡すと、嘘の完了報告を止める人がいなくなります。

Q. 非エンジニアでもこのチェックは回せますか？ 回せます。スクリプトはコピペで動きますし、目視の手順は順番を覚えるだけです。コマンドそのものが不安なら、非エンジニア向けの解説から入ると無理がありません。

Q. メモは何を残せば十分ですか？ 「今回確かめたこと」「残ったリスク」「次の最小の一手」の3つで足ります。長い議事録は不要です。翌日の自分が同じ判断をやり直さない、それだけが目的です。

実際に試した結果

金曜の中身違い公開のあと、僕は完了の基準を「AIが何と言ったか」から「スクリプトの終了コードが0か」に切り替えました。

実際に verify-publish.mjs を10本ほどの公開に通してみたところ、2本で h1一致 が false を返しました。どちらも200は返していて、ぱっと見では気づけないやつです。スクリプトがなければ、また使い回しのページを公開していました。

目視の順番を固定したのも効きました。h1 → canonical → 本文冒頭 → 導線、といつも同じ順で見るようにしたら、「あれ、ここ前も飛ばしたな」という見落としがほぼ消えました。判断を頭の中でやらず、手順に外出しした分だけ、夜の確認が軽くなった実感があります。

賢いAIを探すより、転んでも気づける仕組みを先に置く。遠回りに見えて、これが一番早いというのが今の結論です。

この検証の型をチームの標準にしたい、あるいは自社の公開フローに組み込みたいという段階なら、研修・相談で一緒に設計します。Claude Codeの公式ドキュメントはAnthropicのドキュメントで確認できます。