Claude Codeで毎日1本公開するための高品質記事チェックリスト

毎日公開で壊れるのは「書く速さ」ではなく「公開前の確認」

Claude Codeを使うと、記事の下書き、コード例、翻訳、表の整形まで一気に進みます。だからこそ危ないのは、量産できる気分になって薄い記事を続けてしまうことです。ClaudeCodeLabでは、AdSenseの安全性と読者の信頼を守るため、1日1本の高品質記事に絞り、公開前に検索意図、実装確認、多言語、スマホ表示、収益導線まで見ます。

ここでいう「コンテンツ運用」は、記事を書くだけではありません。検索データを見てテーマを選び、Claude Codeに渡す依頼文を作り、MDXのfrontmatterを確認し、コードブロックを実行できる形にし、10言語の自然さを確認し、公開後にSearch ConsoleとCloudflare Analyticsを見直す一連の流れです。初心者向けに言うと、記事を「思いつき」ではなく「小さな製造ライン」として扱うことです。

公式情報は、検索流入を見るならGoogle Search Consoleの検索パフォーマンスレポート、広告品質の前提ならAdSenseのページ準備ガイド、実アクセスの確認ならCloudflare Web Analytics、MDX管理ならAstro Content CollectionsとAstro MDXを参照します。内部リンクとしては、計測設計はClaude Codeでアナリティクス実装、CMS設計はClaude CodeでブログCMSを作る、公開権限はClaude Codeのapprovalとsandboxガイドが近いテーマです。

1. テーマ選びは「書きたいこと」よりデータで決める

毎日公開で最初に失敗するのは、テーマが弱い記事を先に書き始めることです。Claude Codeは文章を増やせますが、検索意図が弱いテーマを強いテーマには変えられません。Search Consoleで表示回数があるのに順位やCTRが弱いクエリ、Cloudflare Analyticsで読まれているカテゴリ、既存商品の相談につながるテーマを点数化します。

次のCSVをtopic-candidates.csvとして保存します。数字は例なので、自分のSearch Console、Cloudflare Analytics、商品導線の感覚で置き換えてください。

topic,impressions,ctr,position,business_fit,original_experience,code_depth
Claude Code daily publishing checklist,900,0.018,18,5,5,4
Claude Code prompt examples,2400,0.031,9,3,2,2
Claude Code AdSense workflow,500,0.012,22,5,4,3
Astro MDX frontmatter QA,650,0.021,14,4,5,5

次のスクリプトをscore-topics.mjsとして保存し、node score-topics.mjsで実行します。依存パッケージは不要です。

import { readFileSync } from "node:fs";

const rows = readFileSync("topic-candidates.csv", "utf8")
  .trim()
  .split(/\r?\n/)
  .map((line) => line.split(","));

const [header, ...data] = rows;
const index = Object.fromEntries(header.map((name, i) => [name, i]));

const scored = data.map((row) => {
  const impressions = Number(row[index.impressions]);
  const ctr = Number(row[index.ctr]);
  const position = Number(row[index.position]);
  const businessFit = Number(row[index.business_fit]);
  const originalExperience = Number(row[index.original_experience]);
  const codeDepth = Number(row[index.code_depth]);

  const opportunity = Math.log10(impressions + 1) * (1 - ctr) * Math.max(1, 30 - position);
  const quality = businessFit * 2 + originalExperience * 2 + codeDepth;
  const score = Math.round(opportunity + quality * 10);

  return { topic: row[index.topic], score, ctr, position };
});

scored
  .sort((a, b) => b.score - a.score)
  .forEach((item, rank) => {
    console.log(`${rank + 1}. ${item.topic} - score ${item.score} (CTR ${item.ctr}, pos ${item.position})`);
  });

この点数は絶対値ではなく、優先順位を決めるための道具です。実例として、ClaudeCodeLabなら次の3種類を優先します。1つ目はSearch Consoleで表示はあるのに伸びない記事の改善、2つ目は相談や研修につながる運用記事、3つ目はコード例を十分に出せる実装記事です。単なる「Claude Codeとは」より、「Claude CodeでAstro MDXの公開前チェックを自動化する」のほうが、検索意図も実務価値も強くなります。

2. ブリーフでClaude Codeの仕事範囲を固定する

ブリーフとは、記事を書く前に渡す作業指示書です。初心者は「いい感じの記事を書いて」と頼みがちですが、それでは説明が浅くなり、CTAも外れます。Claude Codeには、読者、検索キーワード、実例、コード、失敗例、内部リンク、外部リンク、禁止事項をまとめて渡します。

あなたはClaudeCodeLabの記事編集者です。

slug: claude-code-daily-publishing-checklist
読者: Claude Codeで技術ブログを運用したい個人開発者と小さなチーム
検索意図: 毎日公開したいが、AdSense品質、多言語、コード例、デプロイ確認を崩したくない
必須:
- 4000字以上の日本語 canonical を書く
- 3つ以上のユースケースを入れる
- 初出の専門用語を平易に説明する
- CSV + Node.js のテーマ採点例を入れる
- MDX/frontmatterのprepublishチェック例を入れる
- 失敗例と回避策を具体的に書く
- 公式ドキュメントと内部リンクを入れる
- 無料PDF、商品、研修・相談へのCTAを自然に入れる
禁止:
- 疑似コードだけで済ませる
- 翻訳を短い要約にする
- 公開確認なしで「完了」と言う

このプロンプトの狙いは、Claude Codeに自由作文をさせないことです。特に「実例」「失敗例」「公式リンク」「実行できるコード」を明示すると、記事が薄いまとめで終わりにくくなります。

3. MDXとfrontmatterは公開前に機械チェックする

frontmatterは記事先頭のメタデータです。タイトル、description、日付、タグ、アイキャッチ画像、言語などをサイトに伝える設定欄だと考えてください。ここが壊れると、本文が良くても一覧、OGP、関連記事、多言語ルーティングが崩れます。

次のスクリプトをprepublish-check.mjsとしてsiteディレクトリに保存し、node prepublish-check.mjs claude-code-daily-publishing-checklistで実行します。対象slugが10言語に存在するか、updatedDate、description長、公式リンク、内部リンク、コードフェンスの閉じ忘れを確認します。

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

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

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"],
];

const requiredExternal = [
  "support.google.com/webmasters",
  "support.google.com/adsense",
  "developers.cloudflare.com/web-analytics",
  "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}: missing locale file`);
    continue;
  }

  const source = readFileSync(file, "utf8");
  const frontmatter = source.match(/^---\n([\s\S]*?)\n---/);
  if (!frontmatter) failures.push(`${file}: frontmatter missing`);

  const description = source.match(/^description:\s*"([^"]+)"/m)?.[1] ?? "";
  if (description.length > 120) failures.push(`${file}: description is ${description.length} chars`);
  if (!new RegExp(`^updatedDate:\\s*"2026-06-02"`, "m").test(source)) {
    failures.push(`${file}: updatedDate must be 2026-06-02`);
  }
  if (!new RegExp(`^lang:\\s*"${lang}"`, "m").test(source)) {
    failures.push(`${file}: lang should be ${lang}`);
  }
  if ((source.match(new RegExp("`{3}", "g")) ?? []).length % 2 !== 0) {
    failures.push(`${file}: unclosed code fence`);
  }
  if (!/\]\(\/(?:[a-z]{2}\/)?blog\//.test(source)) {
    failures.push(`${file}: internal blog link missing`);
  }
  for (const host of requiredExternal) {
    if (!source.includes(host)) failures.push(`${file}: missing official link ${host}`);
  }
}

if (failures.length) {
  console.error(failures.join("\n"));
  process.exit(1);
}

console.log(`OK: ${slug} passed localized prepublish checks`);

落とし穴は、ビルドだけを信じることです。Astroのビルドは構文エラーを見つけますが、「descriptionが長すぎる」「公式リンクがない」「1言語だけ古い本文」までは、サイト側で明示しない限り守ってくれません。

4. コード例は「読める」だけでなく「コピペで動く」まで確認する

AdSense向けの記事品質では、独自性と実用性が重要です。Claude Code記事で差別化しやすいのは、実際に動くコード、失敗ログ、修正前後の比較です。疑似コードだけの記事は、読者にも検索エンジンにも「どこかで見た説明」に見えやすくなります。

公開前に見るポイントは4つです。

• コードブロックにファイル名または保存場所が書かれているか
• node、npm、npxなど実行コマンドがあるか
• 環境変数や前提ディレクトリが説明されているか
• エラー時に何を直すかが書かれているか

たとえばscore-topics.mjsは依存なしで動くので初心者向きです。一方、Playwrightはインストールが必要です。記事内では「実行できるが前提がある」ことを明記します。

cd site
npm.cmd i -D @playwright/test
npx.cmd playwright install chromium
npx.cmd playwright test tests/publish-mobile.spec.ts

import { expect, test } from "@playwright/test";

const urls = [
  "/blog/claude-code-daily-publishing-checklist/",
  "/en/blog/claude-code-daily-publishing-checklist/",
];

for (const url of urls) {
  test(`${url} has no mobile horizontal overflow`, async ({ page }) => {
    await page.setViewportSize({ width: 390, height: 844 });
    await page.goto(`http://localhost:4321${url}`);
    const overflow = await page.evaluate(() => document.documentElement.scrollWidth > window.innerWidth);
    await expect(page.locator("h1")).toBeVisible();
    expect(overflow).toBe(false);
  });
}

このチェックは、コードブロックが横にはみ出す、CTAボタンが重なる、翻訳後の長い単語でレイアウトが崩れる、といった失敗を見つけるためのものです。

5. 多言語化は「翻訳済み」ではなく「その国の読者に自然」で判断する

10言語すべてを公開する場合、単に同じ段落を機械翻訳するだけでは弱いです。日本語では「無料PDF」「研修・相談」が自然でも、英語ではfree cheatsheet、products、consultationの順番が伝わりやすいことがあります。スペイン語やポルトガル語では、英語のproductsページへ送る理由を一言添えたほうが親切です。

確認する項目は次のとおりです。

• タイトルにその言語の検索語が入っているか
• descriptionが120文字以内で魅力があるか
• 専門用語の初出説明が残っているか
• コード例が翻訳で壊れていないか
• 内部リンクのlocale prefixが正しいか
• CTAが押し売りでなく本文の次の行動になっているか

失敗例として多いのは、日本語だけ更新して英語や中国語が古いまま残るケースです。もう1つは、翻訳時にfrontmatterの引用符やタグ配列が壊れるケースです。今回のようなMDX記事では、本文より先にメタデータが壊れるとサイト全体のビルドに影響します。

6. デプロイ前チェックは短く、毎回同じ順番にする

毎日公開では、チェックリストが長すぎると守られません。最低限の順番は、ビルド、prepublish、モバイル、公開URL、計測イベントです。

cd site
node prepublish-check.mjs claude-code-daily-publishing-checklist
ASTRO_TELEMETRY_DISABLED=1 npm.cmd run build
npm.cmd run preview -- --host 127.0.0.1

プレビューを立ち上げたら、スマホ幅で記事URLとCTA先を見ます。デプロイコマンドはプロジェクトごとに違いますが、Cloudflare Pagesなら次のような形です。

npx.cmd wrangler pages deploy dist --project-name claudecode-lab --branch master

ここでの落とし穴は、distができた時点で終わった気になることです。公開URLが古い、キャッシュで前の本文が見える、CTAが404になる、1言語だけ新しい日付なのに本文が旧版、という失敗はローカルビルドだけでは見つかりません。

7. 公開後はSearch ConsoleとCloudflare Analyticsで学習する

公開はゴールではなく、次のテーマ選びの材料です。Search Consoleでは、表示回数、CTR、平均掲載順位、クエリを見ます。Cloudflare Analyticsでは、ページビュー、国、参照元、時間帯を見ます。数字を見るときは、1日で判断しないことが重要です。新規記事はインデックスや順位の反映に時間がかかるため、初日は「公開できたか」、1週間後に「検索意図に合ったか」、1か月後に「内部リンクやCTAを直すか」を見ます。

ユースケースは3つあります。

• 個人開発者: 1日1本のペースを守りながら、無料PDF登録につながるテーマを増やす
• 小さなチーム: Claude Codeの導入記事を増やし、研修・相談の問い合わせにつなげる
• 技術メディア: MDX、翻訳、コード検証を標準化し、執筆者が増えても品質を保つ

ここで必要なのは派手な自動化ではありません。毎日1本の記事ごとに、テーマ選定、ブリーフ、コード確認、翻訳確認、モバイル確認、公開後学習を同じ順番で回すことです。

収益導線は読者の段階に合わせる

初心者には、まず無料チートシートでClaude Codeの基本コマンドと確認観点を持ち帰ってもらいます。実装テンプレートや運用チェックリストをまとめて使いたい読者にはプロダクト一覧が自然です。チームで導入ルール、レビュー体制、AdSenseを意識した記事運用まで整えたい場合は、Claude Code研修・導入相談で実際のリポジトリを前提に設計できます。

この記事で紹介した内容を実際に試した結果、テーマ採点CSVを先に作るだけで「今日は何を書くか」に悩む時間がかなり減りました。さらにprepublish-check.mjsで10言語、description、公式リンク、コードフェンスを確認すると、Claude Codeが速く書いた後でも公開前に止めるべき箇所が明確になります。最後の人間レビューでは、数字では拾えない体験談、失敗例、CTAの自然さだけに集中できました。