毎日投稿で低価値記事を出さない品質ゲート設計
AI自動化は、作った直後よりも、翌週に同じ仕組みを直すときに本当の価値が分かる。動いているように見えても、記事の量産、画像生成、WordPress投稿、検証ログのどこかが曖昧だと、すぐに「なぜこの設計にしたのか」が分からなくなる。
今回は、ブログ毎日投稿の自動化を題材に、1本だけ作る、画像を2枚そろえる、品質ゲートに落ちたら止める、WordPressに出せた時だけnoteへ流す、という設計を見直した。単に毎日投稿する仕組みではなく、低価値記事を増やさないための停止条件をどこに置くかが主題だ。
特に重要だったのは、入口を増やしすぎないことだった。複数のautomationやlaunchdが同じブログ投稿に触れると、二重投稿、古い在庫記事の混入、noteだけ先に出る事故が起きやすい。だから今回の設計では、ブログ日次投稿は1つのautomationに寄せ、prepare、画像生成、publish、note連携までを同じrun dirで追えるようにしている。
なぜ毎日投稿なのに止める条件を強くしたのか
毎日投稿を始めると、最初に考えたくなるのは「どうやって止めずに出すか」だ。しかし、AdSense審査中のブログでは、止めないことよりも、低価値に見える記事を増やさないことのほうが大事になる。
たとえば、本文が短い、既存記事とタイトルが近い、画像が足りない、会社情報や秘密情報が混じる、こうした状態で公開すると、後から直すより先にブログ全体の信頼を落とす。記事数を増やしているつもりが、審査にとっては逆効果になる可能性がある。
だから今回は、公開前に止める条件を明確にした。旧ブログlaunchdが動いている場合は二重投稿リスクで停止する。画像が2枚そろわない場合は停止する。WordPress認証で失敗したら停止する。既存記事と同一または近似タイトルなら停止する。品質ゲートに落ちたら停止する。
このルールは厳しいが、運用としては分かりやすい。公開できる時は迷わず出す。止まる時は、どの条件で止まったかをrun dirへ残す。これだけで、翌日の見直しや手動継続がかなり楽になる。
1本だけ作ることの意味
今回の自動化では、複数記事を作って選ぶ運用をやめている。候補整理はしても、本文生成は1本だけにする。これは、トークン節約だけが理由ではない。
複数記事を作ると、たしかにその場では良いものを選びやすい。しかし、毎日運用では、選ばなかった記事、使わなかった画像、途中の在庫が増えていく。すると、どれが公開済みで、どれが下書きで、どれが古い文脈のまま残っているのか分かりにくくなる。
1本だけ作ると、その日のrun dirがそのまま判断の単位になる。prepare_result.json を見れば、品質ゲートの結果が分かる。image_prompts.json を見れば、必要な画像が分かる。publish_result.json を見れば、WordPressとnoteの結果が分かる。失敗した日も、どこで止まったかが一箇所に残る。
これは小さな違いに見えるが、自動化を増やしていくほど効いてくる。後からログを追う時に、記事候補が5本、画像候補が10枚、noteキューが別管理、という状態になると、原因調査だけで時間を使う。毎日投稿は、派手な生成よりも、追跡しやすい単位を保つことが大事だ。
画像2枚を必須にした理由
このブログでは、記事ごとにサムネイルと本文内の要約画像を入れる方針にしている。サムネイルは一覧やSNSで入口になる。本文内画像は、記事の途中で作業全体を把握するための地図になる。
画像を1枚だけにすると、どうしてもサムネイル用途に寄る。見た目は整っても、本文中で読者が流れを掴む助けにはなりにくい。逆に本文内画像だけだと、一覧で記事を見つけた時の印象が弱くなる。だから2枚を標準にした。
ただし、画像はローカルで新規生成しない。画像生成はCodex画像生成またはGPT Web Pro拡張を使い、ローカル処理はコピー、リサイズ、圧縮、検証だけにする。これを分けないと、いつの間にかPILやCanvasでそれっぽい図を作り始めてしまい、画像生成の品質基準が崩れる。
今回の流れでは、image_prompts.json にthumbnailとsummaryを出し、2枚がそろった瞬間にpublishへ進む。画像が足りない日は投稿しない。ここを曖昧にしないことで、記事の見た目と本文の密度をセットで保てる。
WordPress成功後だけnoteへ流す
note連携は、ブログの成功後だけにした。理由は単純で、noteを別の記事生成フローにすると、同じテーマなのに本文がズレたり、ブログが止まった日にnoteだけ出たりするからだ。
今回の設計では、WordPress公開に成功した場合だけ、同じ本文を content/note_queue/ に1件保存する。そして、その同じキュー項目だけをnoteへ投稿する。サムネイルと本文画像も、ブログで使ったものを渡す。
この順番にすると、WordPressが止まった日はnoteも止まる。重複タイトルで止まった日も、品質ゲートで止まった日も、noteだけが先に出ることはない。ブログを正とし、noteは再利用先にする。これが一番事故が少ない。
また、note側では画像配置も大事になる。本文画像を最後にまとめて入れると、記事の流れとして不自然になる。本文側の <figure class="wp-block-image size-large"><img src="https://ichinose-taito.com/wp-content/uploads/2026/05/summary_codex-8.jpg" alt="記事内容の要約図" /><figcaption>この記事の流れ。Codex画像生成で作成。</figcaption></figure> の位置を尊重し、要約画像が自然に入るようにする必要がある。公開後に見た目を直すのではなく、キューの段階から画像の意味を保つほうがよい。
本文生成で分けた役割
今回の比較で分かったのは、構成を整える力と、実験ログの密度は別物だということだった。文章生成モデルに寄せると、導入や章立ては読みやすくなる。一方で、実測、失敗、数字、作業ログを材料として強く渡さないと、きれいだが薄い文章になりやすい。
だから、ローカル側の役割は本文を完成させることではなく、事実を濃くすることに寄せる。具体的には、何を試したか、どの数字を固定したか、どこで詰まったか、どう直したか、次に同じ作業をする人が何を真似できるかを短くまとめる。文章生成側には、その材料を使って読者に伝わる構成へ整えてもらう。
ここで大事なのは、ローカル下書きをそのまま公開本文として信じすぎないことだ。ローカル下書きは、作業者の目線では十分に見えても、読者から見ると前提が抜けていることがある。特にAI自動化の記事は、内部のファイル名やツール名だけで話を進めると、読者が置いていかれる。だから本文生成では、まず読者が期待する主題を置き、そのあとで具体的なログを差し込む。
逆に、文章生成へ全部任せると、文章は整うが現場の手触りが薄くなる。今回なら、入口を1つにした理由、画像不足で止める理由、重複投稿を避ける理由、タイトルと本文がズレた時の問題が薄まると、ただのきれいな解説になる。私が残したいのは、一般論ではなく、次に同じ作業をするときに迷わない実験ログだ。
実際のチェックリスト
同じ仕組みを作るなら、公開前に次の順番で確認すると失敗しにくい。
- タイトルが既存記事と重複していないか
- 冒頭3段落で、何を試した記事なのか分かるか
- 文字数が十分で、H2が5個以上あるか
- 実測値、失敗、原因、対処のいずれかが入っているか
- 読者が真似できる手順や判断基準があるか
- 画像がサムネイルと本文内要約の2枚そろっているか
- 秘密情報、会社情報、個人情報が混じっていないか
- 公開後にURL、H1、画像表示を確認できるか
このチェックは、厳しく見えるが、毎日投稿ではかなり効く。毎回の本文を人間が最初から最後まで精査できないなら、公開前に機械的な停止条件を置くしかない。特にAdSense審査中は、少しでも低価値に見える記事を増やすより、公開数を減らしてでも安定した記事だけ残すほうがよい。
私がこのチェックで重視しているのは、公開後に読み返しても説明責任を持てるかどうかだ。自動化の記事は、操作手順だけならすぐに書ける。しかし、なぜその手順を選んだのか、どの失敗を避けるためなのか、どの条件なら止めるべきなのかを書かないと、読者にとっては単なる作業メモで終わる。審査中は、この差を特に大きく見る。
画像は要約として使う
ブログ記事はテキストだけでも読める。ただ、このブログでは画像を単なる飾りにしない。サムネイルは記事の入口、本文内画像は作業の要約として使う。
今回なら、記事生成、画像生成、WordPress公開、公開後検証がどうつながるかを一枚にまとめる。読者が本文を全部読み返さなくても、何をどの順番で見ればいいか思い出せる状態にする。画像は見栄えより、理解を短くするための道具として扱う。
この考え方は、サムネイルにもそのまま当てはまる。タイトルだけを大きく見せるより、記事の中で扱う流れが一目で分かるほうが後から効く。画像を増やすより、1枚の要約図に情報を整理するほうが、毎日運用では続けやすい。
ただし、画像は本文の代わりにはならない。画像だけがきれいで本文が薄い記事は、読者にも検索エンジンにも弱い。画像は、本文で説明した手順や比較を補助するものとして使う。本文に読者価値があることが先で、その理解を助けるために画像を置く。
真似するならこうする
同じやり方を使うなら、まず作業の入口を1つ決める。次に、読むべき補助ファイルを2つか3つまでに絞る。そのうえで、本文にする前に次の5点を短く書き出す。
- 何を試したか
- なぜその設計にしたか
- どの数字を固定したか
- どこで失敗しやすいか
- 次の人が何を真似できるか
次に、本文の骨格を作る。おすすめは、導入、背景、失敗、手順、チェックリスト、まとめの順番だ。この形なら、読者は「なぜ必要か」から入り、「どうやるか」まで自然に追える。コードやコマンドを載せる場合も、いきなり貼るのではなく、何のための操作かを先に説明する。
最後に、タイトルと導入が同じ方向を向いているかを見る。ここがズレると、どれだけ具体的な作業ログが入っていても記事として弱くなる。公開直前にタイトルだけを見て、本文がその約束に答えているかを確認する。
ブログの定期的な更新と内容の充実により、読者との関係性を強化できる。
今回の修正方針は、読みやすい構成を本文の骨格に使い、ローカル下書きの実験ログを材料として残すことだ。これなら、読みやすさと実務の密度を両方残せる。
明日以降は、本文を作る前に「タイトルに対して本文が何を約束しているか」を先に固定する。そこから実測、失敗、数字を入れる。自動投稿であっても、記事の中心だけは毎回ずらさない。
公開前の確認もこの順番に変える。まずタイトルと冒頭3段落を見る。次にH2を眺めて、全部が同じ主題へ戻っているかを見る。最後に、読者が真似できる手順と、失敗やリスクへの対処が入っているかを見る。これで通るなら、記事としての最低限の骨格はある。そこに画像2枚とWordPress確認を足せば、毎日投稿として回せる。
今回のように数十字だけ足りない場合でも、止めた理由を残してから同じrun dirで補うと、判断の履歴が崩れない。自動化を雑に上書きせず、停止と継続の跡を分けて残せることも、毎日運用では大事な品質になる。