ブログ毎日投稿を1本のオートメーションに絞った理由
私は今日、ブログ毎日投稿を1本のオートメーションに絞った理由 というテーマで、直近の作業を後から続けられる形に整理した。この記事では、毎日投稿を安定運用するための判断基準として、いま進んでいるAI自動化の作業を、次の作業でも迷わず再開するための実験ログだ。
今回試したのは、作業の入口を1つに絞り、何を見れば続きに入れるのかを明確にすることだった。使った道具はCodex automation、WordPress REST API、Ollama。数字として残した条件は1日1本、候補最大3件、画像最低2枚。参照元はcontent/mobile_outbox/collect_log.jsonl、content/mobile_outbox/collect_state.json、output/kdp_intelligence_dashboard.htmlに絞った。全文ログを投げるのではなく、記事テーマ、実際に起きたこと、数字、失敗、読者に渡す結論だけを本文の材料にした。
この運用メモで扱う範囲
今回の元ネタは次の出来事だった。
複数の自動化を乱立させず、1日1本の生成と投稿に絞る設計へ切り替えた。
最近の関連ファイル:
content/mobile_outbox/collect_log.jsonl collect_log.jsonl
content/mobile_outbox/collect_state.json collect_state.json
output/kdp_intelligence_dashboard.html kdp_intelligence_dashboard.html
scripts/notify/pycache/discord_notify.cpython-310.pyc discord_notify.cpython-310.pyc
scripts/notify/pycache/init.cpython-310.pyc init.cpython-310.pyc
output/kdp_daily_status.html kdp_daily_status.html
output/kdp_daily_status.json kdp_daily_status.json
scripts/dashboard/data_collectors/pycache/sns.cpython-314.pyc sns.cpython-314.pyc
scripts/dashboard/data_collectors/pycache/blog.cpython-314.pyc blog.cpython-314.pyc
scripts/dashboard/data
ここで重要なのは、新しい企画を大量に作ることではない。今ある作業を止めずに、次に見るべきファイル、判断基準、直す順番を残すことだ。AI自動化の運用では、作った本人だけが分かる状態が一番詰まりやすい。そこで、作業の範囲を小さく区切り、再開に必要な情報だけを前に出した。
入口を1つに絞った理由
最初に決めたのは、読むべき入口を増やさないことだった。作業ログ、ハンドオフ、個別メモ、生成物フォルダを全部並べると、情報量は多く見える。ただ、実際に再開する側から見ると、どこから読むべきか分からない。
今回は入口を1つに寄せ、補助情報をその下に置く形にした。これなら、次の次に作業する人は、まず運用メモを読み、必要な時だけ引き継ぎメモや対象ファイルへ進めばいい。使った情報を減らしたことで、作業の目的も見えやすくなった。
失敗しやすいところ
複数の自動化や在庫運用にすると、どれが動いているか分かりにくくなる。
もう一つのリスクは、記事のタイトルと本文の焦点がズレることだった。タイトルが運用メモの話なのに、本文がブログ運用全体の話へ寄ると、読者は途中で何を読んでいるのか分からなくなる。対策として、導入では必ず「何を試したか」と「なぜその設計にしたか」を先に書き、各見出しもタイトルのテーマへ戻るようにした。
本文生成で分けた役割
今回の比較で分かったのは、構成を整える力と、作業ログの密度は別物だということだった。GPT Web Proに寄せると、導入や章立ては読みやすくなる。一方で、実測、失敗、数字、作業ログを材料として強く渡さないと、きれいだが薄い文章になりやすい。
だから、ローカル側の役割は本文を完成させることではなく、事実を濃くすることに寄せる。具体的には、何を試したか、どのファイルを使ったか、数字はいくつか、どこで詰まりそうか、次の人が何を真似できるかを短くまとめる。GPT Web Pro側には、その材料を使って読者に伝わる構成へ整えてもらう。
ここで大事なのは、ローカル下書きをそのまま公開本文として信じすぎないことだ。ローカル下書きは、作業者の目線では十分に見えても、読者から見ると前提が抜けていることがある。特にAI自動化の記事は、内部のファイル名やツール名だけで話を進めると、読者が置いていかれる。だから本文生成では、まず読者が期待する主題を置き、そのあとで作業ログを差し込む。
逆に、GPT Web Proへ全部任せると、文章は整うが現場の手触りが薄くなる。今回なら、運用メモの目的、入口を1つにした理由、どのファイルを見れば再開できるか、タイトルと本文がズレた時の問題が薄まると、ただのきれいな解説になる。私が残したいのは、きれいな一般論ではなく、次に同じ作業をするときに迷わない実験ログだ。
画像は要約として使う
ブログ記事はテキストだけでも読める。ただ、このブログでは画像を単なる飾りにしない。サムネイルは記事の入口、本文内画像は作業の要約として使う。
今回なら、運用メモ、引き継ぎメモ、対象フォルダ、次の改善作業がどうつながるかを一枚にまとめる。読者が本文を全部読み返さなくても、何をどの順番で見ればいいか思い出せる状態にする。画像は見栄えより、再開手順を短くするための道具として扱う。
この考え方は、サムネイルにもそのまま当てはまる。タイトルだけを大きく見せるより、記事の中で扱う流れが一目で分かるほうが後から効く。今日の記事なら、運用メモ、ハンドオフ、作業対象、改善チェックという4つの要素が見えれば十分だ。画像を増やすより、1枚の要約図に情報を整理するほうが、毎日運用では続けやすい。
真似するならこうする
同じやり方を使うなら、まず作業の入口を1つ決める。次に、読むべき補助ファイルを2つか3つまでに絞る。そのうえで、本文にする前に次の5点を短く書き出す。
- 何を試したか
- なぜその設計にしたか
- どの数字を固定したか
- どこで失敗しやすいか
- 次の人が何を真似できるか
最後に、タイトルと導入が同じ方向を向いているかを見る。ここがズレると、どれだけ具体的な作業ログが入っていても記事として弱くなる。
個人のAI自動化ブログを、低コストで継続しやすい形に整理できる。
今回の修正方針は、GPT Web Proの構成力を本文の骨格に使い、ローカル下書きの実験ログを材料として残すことだ。これなら、読みやすさと実務の密度を両方残せる。
明日以降は、本文を作る前に「タイトルに対して本文が何を約束しているか」を先に固定する。そこから実測、失敗、数字を入れる。自動投稿であっても、記事の中心だけは毎回ずらさない。
公開前の確認もこの順番に変える。まずタイトルと冒頭3段落を見る。次にH2を眺めて、全部が同じ主題へ戻っているかを見る。最後に、読者が真似できる手順と、失敗やリスクへの対処が入っているかを見る。これで通るなら、記事としての最低限の骨格はある。そこに画像2枚とWordPress確認を足せば、毎日投稿として回せる。