ブログを毎日1本出し続ける公開前チェックリスト：誤字・文字化け・重複を止める

「今日のぶん、もう出した？」

そう聞かれて、夜23時に慌てて公開ボタンを押した記事。翌朝見たら、タイトルに「Cluade Code」と打ち間違えていました。しかも10言語ぜんぶに。AdSenseを意識して毎日更新しているサイトで、トップに並ぶ全記事が誤字。あれは本当に冷や汗をかきました。

僕はclaudecode-lab.comで、ほぼ毎日1本記事を出しています。やってみて分かったのは、毎日更新が止まる原因は「書くのが遅いから」じゃないということ。Claude Codeを使えば下書きは30分で出ます。止まるのは、その後の公開前チェックでいつも事故るからです。誤字、文字化け、動かないコード、同じネタの重複、1言語だけ古い本文。これを毎回ゼロから目視で探していたら、3日で心が折れます。

だから僕は、確認を「気合い」ではなく「決まった順番のチェックリストとスクリプト」に置き換えました。この記事は、その実物です。

この記事の要点

• 毎日更新が止まるのは執筆速度ではなく公開前チェックの属人化。順番を固定すれば続く。
• 確認は「人がやること」と「コマンドに任せること」に分ける。誤字・文字化け・コードフェンス閉じ忘れ・description超過は機械が一瞬で弾ける。
• 重複公開（同じネタ・二重投稿）は記憶じゃなく既存タイトル一覧との突き合わせで防ぐ。
• コピペで動く prepublish-check.mjs を1本置けば、Claude Codeが速く書いた後でも公開前に止めるべき箇所が一目で分かる。
• レビュー観点はレビュー運用チェックリスト、SEOは技術的SEOとAIOのハブへ。この記事は「毎日publishを回す運用」に徹する。

毎日更新で本当に壊れるのは「公開前の最終確認」

最初に正直な話を。僕が毎日更新でつまずいた失敗は、ほぼ全部「公開直前」に集中しています。

書くのは楽しいんです。ネタが決まれば、Claude Codeに段取りを渡して下書きを出させ、コード例を足し、表を整える。ここまでは勢いがある。問題は、出来上がった記事を「えいや」で公開する瞬間です。疲れている夜ほど、目視チェックは雑になる。そして事故る。

冒頭の「Cluade Code」誤字もそうですし、もっとひどいのは文字化けでした。Windowsで作業していて、PowerShell経由で生成したファイルがUTF-16で保存され、本文の日本語が全部「意味不明な漢字の羅列」みたいな化け方をしたまま公開されたんです。プレビューを開かずにデプロイしたので、半日気づきませんでした。

もう1つは重複公開。似たネタを別の日に2回書いてしまい、内部で食い合った。検索エンジンから見れば「どっちが本命？」状態です。

これらに共通するのは、どれも人間の記憶と目視に頼った瞬間に起きていること。だから対策はシンプルで、確認を「決まった手順」と「機械チェック」に逃がす。以下、僕が実際に回している順番でいきます。

1. ネタ選び：今日書くかは「気分」じゃなく一覧で決める

毎日更新で最初に事故るのは、実は公開前じゃなくてネタ選びです。弱いネタを書き始めると、いくら肉付けしても弱いまま。しかも気分で選ぶと、過去に書いたネタとかぶります。

僕は書き始める前に、必ず2つだけ見ます。

1. 既存記事のタイトル一覧（重複していないか）
2. 検索意図がある言葉か（自分の検索データで反応があるか）

特に1つ目の重複チェックは、記憶に頼ると確実に裏切られます。300本近くあると、半年前に何を書いたかなんて覚えていません。だから一覧を機械で出します。

cd site/src/content/blog
# 既存タイトルを全部書き出して、今日のネタと近いものが無いか目で確認する
grep -h '^title:' *.mdx | sort

この一覧を眺めて、今日のネタが既存とぶつかっていないかを見る。たったこれだけで、僕の二重投稿はほぼ消えました。ネタの強さの点数化までやりたい人は別記事に譲りますが、毎日続けるうえで効くのは派手なスコアリングより、この地味な突き合わせです。

差別化の角度もここで決めます。たとえば「Claude Codeでブログ」みたいな広いネタは食い合うので、僕はこの記事を「毎日publishを回す運用チェックリスト」に絞りました。レビュー観点や導線設計は別の柱に逃がす、と決めておくと、毎回ネタが綺麗に分かれます。

2. 執筆：ブリーフで仕事の範囲を固定する

ブリーフとは、書く前にClaude Codeへ渡す作業指示書のことです。「いい感じに書いて」だと、毎回ばらつきます。毎日続けるなら、出力を安定させるテンプレを1つ持っておくのが効きます。

僕が毎日使っている指示文は、だいたいこんな骨格です。

あなたはclaudecode-lab.comの記事編集者です。

slug: （今日のslug。既存と重複していないこと）
読者: Claude Codeで技術ブログを運用したい個人開発者と小さなチーム
角度: 「毎日publishを回す運用チェックリスト」に徹する（レビュー観点・SEOは別記事へ）
必須:
- 本文3800字以上、一人称「僕」の体験談で書く
- 実際に試した失敗（誤字・文字化け・重複公開など）を入れる
- コピペで動くコードを1つ以上（日本語コメント付き）
- 内部リンク2本以上、公式リンク1本以上
禁止:
- 「することができます」「が重要です」「様々な」などの言い回し
- 疑似コードだけで済ませる
- 公開確認なしで「完了」と言う

狙いは、自由作文をさせないこと。特に「失敗談」「動くコード」「リンク」を明示すると、薄いまとめで終わりにくくなります。文体の見本を1本決めて「これと同じトーンで」と渡すのも効きます。僕の場合はいつも同じ見本記事を指定して、AI感のある言い回しを最初から避けています。

3. 品質チェック：人がやることと、機械に任せることを分ける

ここが本題です。公開前の確認を「全部目視」でやると続きません。僕は次の表のように、はっきり線を引いています。

確認項目	誰がやる	理由
誤字・タイトルの打ち間違い	機械＋人	スペル癖は機械、文脈は人
文字化け（UTF-16混入など）	機械	目視では気づきにくい
コードフェンスの閉じ忘れ	機械	数えるだけ。人がやると見落とす
description 120字超過	機械	文字数は機械が正確
10言語そろっているか	機械	1言語抜けを目で探すのは無理
内部リンク・公式リンクの有無	機械	入れ忘れを検出
体験談の自然さ・AI感	人	ここだけは人間の仕事
コードが実際に動くか	人	実行して確かめる

ポイントは、機械で弾けるものに人間の集中力を使わないこと。誤字や文字化けやリンク切れを目視で探すのに疲れ果てて、肝心の「体験談が自然か」を見る余力が残らない――これが毎日更新で一番もったいない失敗です。

機械チェックは、次のスクリプトに任せます。

4. コピペで動く公開前チェックスクリプト

これが僕の実際の門番です。prepublish-check.mjs として site ディレクトリに保存し、node prepublish-check.mjs <slug> で実行します。対象slugが10言語そろっているか、updatedDate、description長、公式リンク、内部リンク、コードフェンスの閉じ忘れ、そして文字化けの兆候まで一気に見ます。依存パッケージは不要です。

import { existsSync, readFileSync } from "node:fs";
import path from "node:path";

const slug = process.argv[2];
if (!slug) {
  console.error("使い方: node prepublish-check.mjs <slug>");
  process.exit(1);
}

// 10言語ぶんのディレクトリと、期待するlang値
const locales = [
  ["blog", "ja"],
  ["blog-en", "en"],
  ["blog-zh", "zh"],
  ["blog-ko", "ko"],
  ["blog-es", "es"],
  ["blog-fr", "fr"],
  ["blog-de", "de"],
  ["blog-pt", "pt"],
  ["blog-hi", "hi"],
  ["blog-id", "id"],
];

// 信頼できる公式リンクが最低1つ入っているか確認するための候補
const officialHosts = [
  "support.google.com",
  "developers.cloudflare.com",
  "docs.astro.build",
];

const failures = [];

for (const [dir, lang] of locales) {
  const file = path.join("src", "content", dir, `${slug}.mdx`);
  if (!existsSync(file)) {
    failures.push(`${file}: この言語のファイルが無い`);
    continue;
  }

  // BOM付きUTF-16などで保存されると文字化けの温床になるので、まず先頭バイトを見る
  const raw = readFileSync(file);
  if (raw[0] === 0xff && raw[1] === 0xfe) failures.push(`${file}: UTF-16(LE)で保存されている。UTF-8で保存し直す`);
  if (raw[0] === 0xfe && raw[1] === 0xff) failures.push(`${file}: UTF-16(BE)で保存されている。UTF-8で保存し直す`);

  const source = raw.toString("utf8");

  // 文字化けの典型パターン（置換文字や、よくある化け列）を検出する
  if (source.includes("\uFFFD")) failures.push(`${file}: 文字化け(置換文字)が混ざっている`);
  if (/[\u7e3a\u7e67\u7e9d\u8509\u907f\u8523]/.test(source)) failures.push(`${file}: 日本語が文字化けしている可能性`);

  // frontmatterが取れるか
  const frontmatter = source.match(/^---\n([\s\S]*?)\n---/);
  if (!frontmatter) failures.push(`${file}: frontmatterが見つからない`);

  // descriptionは120字以内
  const description = source.match(/^description:\s*"([^"]+)"/m)?.[1] ?? "";
  if (description.length > 120) failures.push(`${file}: descriptionが${description.length}字（120字以内に）`);

  // 今日の更新日に揃っているか
  if (!/^updatedDate:\s*"2026-06-07"/m.test(source)) {
    failures.push(`${file}: updatedDateが2026-06-07ではない`);
  }

  // langが正しいか
  if (!new RegExp(`^lang:\\s*"${lang}"`, "m").test(source)) {
    failures.push(`${file}: langが${lang}になっていない`);
  }

  // コードフェンスが偶数か（閉じ忘れ検出）。バッククォート3つを文字列で組み立てる
  const fence = "`".repeat(3);
  if ((source.split(fence).length - 1) % 2 !== 0) {
    failures.push(`${file}: コードフェンスの閉じ忘れ`);
  }

  // /blog/ への内部リンクが1本以上あるか（localeプレフィックス許容）
  if (!/\]\(\/(?:[a-z]{2}\/)?blog\//.test(source)) {
    failures.push(`${file}: 内部リンク(/blog/)が無い`);
  }

  // 公式リンクが1本以上あるか
  if (!officialHosts.some((host) => source.includes(host))) {
    failures.push(`${file}: 公式リンク(https)が1本も無い`);
  }
}

if (failures.length) {
  console.error("公開NG:\n" + failures.join("\n"));
  process.exit(1);
}

console.log(`OK: ${slug} は公開前チェックを通過`);

このスクリプトのいいところは、exit(1) で落ちることです。CIや公開コマンドの手前に挟めば、チェックを通らない記事は物理的に公開できない。「あとで自分が確認すればいい」は忙しい夜に必ず破綻するので、機械に強制させます。

落とし穴を1つ。ビルドだけを信じないでください。Astroのビルドは構文エラーは見つけますが、「descriptionが長すぎる」「公式リンクがない」「1言語だけ古い」「日本語が化けている」までは、こちらで明示しない限り素通りします。だから僕はビルドとは別に、この門番を必ず通します。

5. 公開前の最終確認：プレビューだけは目で見る

機械チェックを通したら、最後に人間がやるべき2つだけ残ります。プレビューの目視と、コードの実行です。

毎日やる手順はこれだけに固定しています。

cd site
# 1. 機械チェック（落ちたらここで止まる）
node prepublish-check.mjs claude-code-daily-publishing-checklist
# 2. ローカルでプレビューを立ち上げる
npm.cmd run preview -- --host 127.0.0.1

プレビューが立ち上がったら、スマホ幅で記事URLを開きます。見るのは3つだけ。コードブロックが横にはみ出していないか、リンク先が404になっていないか、そして本文が化けていないか。冒頭の文字化け事故は、このプレビュー目視を省いた日に起きました。以来、どんなに眠くてもブラウザで1回は開く、を鉄の掟にしています。

公開URLが古いキャッシュで前の本文に見える、というのもありがちです。デプロイ後にもう一度、シークレットウィンドウで本番URLを開いて確認します。承認やデプロイ権限の線引きをどう運用するかは承認とsandboxの線引き運用術に寄せています。

6. 公開後の計測：その日は判断しない

公開はゴールじゃなくて、次のネタ選びの材料です。ただし毎日更新で一番やりがちな勇み足が、公開当日に数字を見て一喜一憂すること。新規記事はインデックスや順位の反映に時間がかかるので、初日に見ても何も分かりません。

僕はこう分けています。

• 当日: 「ちゃんと公開できたか」だけ確認（URL・表示・化けていないか）
• 1週間後: Google Search Consoleの検索パフォーマンスレポートで表示回数とCTRを見る
• 1か月後: 内部リンクやタイトルを直すか判断する

数字を見るのは大事ですが、毎日更新の文脈では「見すぎない」ことのほうが大事でした。当日の数字に振り回されると、肝心の翌日の1本に集中できません。AdSenseの前提を崩さないためにも、まずAdSenseのページ準備ガイドが言う「オリジナルで価値のある内容か」を自分の物差しに据えて、量より中身で続けます。記事から商品・研修・相談への導線をどう測るかはコンテンツ導線の監査にまとめてあります。

よくある質問

Q. 毎日更新は本当に必要？週3じゃダメ？ 頻度そのものより「続く仕組みがあるか」が大事だと思っています。僕が毎日にしているのは、間隔を空けると「今日はいいか」が増えて結局止まるから。ただし無理に薄い記事を量産するくらいなら、週3で中身を厚くするほうが、AdSense的にも検索的にも健全です。続けられるペースが正解です。

Q. ネタ切れはどう防いでる？ 過去記事の一覧を眺めて、書いた角度の「隣」を探します。たとえば公開チェックを書いたら、次はレビュー観点、その次はSEO、と柱を分けて隣へずらす。1テーマを複数記事に分けると、ネタが増えるうえに内部リンクのクラスタも自然に育ちます。

Q. 文字化けを根本から防ぐには？ ファイルは必ずUTF-8（BOMなし）で保存する、が大前提です。Windowsだと既定でUTF-16になるツールがあるので要注意。さらに上のスクリプトで先頭バイトと化け文字を検出して二重で止めます。生成直後にプレビューを開くのも効きます。

Q. Claude Codeに全部任せて公開まで自動化できる？ 下書き・コード・翻訳の生成は任せられますが、公開のゴーサインは僕が出します。プレビューの目視とコードの実行だけは人間に残すべきで、ここを自動化した日にだいたい事故ります。安全だと確認できた工程から少しずつ自動に格上げするのがコツです。

Q. 10言語そろえるのが重い。日本語だけ先に出すのはアリ？ アリですが、requireAllLocales を使っているなら一覧やルーティングが崩れることがあります。僕は「同時公開、ダメなら機械チェックで1言語抜けを検出して塞ぐ」運用です。1言語だけ古い本文が残るのが一番まずいので、そこだけは機械に見張らせます。

実際に試した結果

このチェックリストを回し始めてから、公開前の事故が目に見えて減りました。

一番効いたのは、誤字・文字化け・リンク切れ・コードフェンス閉じ忘れを prepublish-check.mjs に丸投げしたことです。これらを目視で探すのをやめたら、最後の人間レビューで「体験談が自然か」「コードが本当に動くか」だけに集中できるようになりました。冒頭の「Cluade Code」全言語誤字も、文字化け公開も、あれ以来ゼロです。

正直に言うと、今でも完璧じゃありません。眠い夜にプレビューを開くのをサボりかけて、ハッと思い出して開く、を繰り返しています。重複ネタも一度うっかり書きかけて、公開前のタイトル一覧チェックで気づいて角度を変えました。それでも、毎日同じ順番で――ネタ一覧→ブリーフ→機械チェック→プレビュー目視→公開→翌週に計測――を回すだけで、毎日1本が「気合い」じゃなく「作業」になりました。続けるコツは、賢く書くことより、転んでもケガしない手順を先に作っておくことだと、今は思っています。

まずは prepublish-check.mjs のような門番を1本、自分の公開コマンドの手前に置いてみてください。手順をまとめて持ち帰りたい人はプロダクト一覧、チームで運用ルールごと整えたい場合はClaude Code研修・導入相談が近道です。