AIが書く記事の自動公開を、毎時から朝と夕方の枠に作り直した

記事を AI が書いて自動で公開する関連メディア「Chronicle AI」の公開の仕組みを、2026年10月7日に作り直しました。それまでは毎時起動して、時期が来たトピックを出せるだけ出す作りでした。今は、朝7時にニュースを1本、夕方18時に連載・スマートホーム・レビューから1本を出す「枠」の形です。記事は人の確認を通さずに公開していて、公開を決めるのは AI の採点、機械の検査、ビルドの確認です。同じ日の朝には、人の編集判断を組み合わせているとしていた About の文も、実際の作り方に書き直しました。warp-studio.com からは利用の案内をしていません。本数を増やす話ではなく、本数と失敗に上限を付けた記録です。

毎時動いて、出せるだけ出していた

生成は、クラウドの定時実行で7時から23時まで毎時、1日17回起動していました。生成した記事と画像は GitHub のリポジトリの公開用のブランチに送られ、そのたびにサイトが自動でビルドされて公開されます。

1回の起動では、時期が来たトピック（技術ニュースや連載など、記事の種類ごとの設定）を上から試し、公開できた本数が1回の上限に達したら止めていました。公開できなかったトピックは数えないので、失敗すると同じ回のうちに次のトピックへ進みました。1日の上限はありませんでした。

並び順は「予定より一番遅れているもの」が先頭でした。5月23日を最後に公開できていない AI ツールの活用記事と、6月1日を最後に出ていないスマートリングの比較記事は、遅れが数千時間になり、毎回、真っ先に試されていました。

毎日型のニュースは前回の公開から12時間で再び対象になり、全部成功すると、全体で1日約4.4本になる計算でした。実際は検査で落ちることが多く、10月2日から6日の5日間で15本です。

失敗の跡が残り続けた

9月は、生成のジョブがメモリ不足で毎回落ち、公開は0本でした。同じ記事を1日に34回ほど作り直していました。

失敗した試行でも、画像は作っていました。画像を作るのは AI の採点に通った後、機械の検査の前で、検査で落ちても画像は残ります。リポジトリに送る処理は画像のフォルダを丸ごと追加するので、使われない画像もそのまま公開用のブランチに入りました。10月7日の朝の時点で、10月1日以降の画像135枚のうち102枚は、どの記事・下書きからも使われていません。全期間では384枚・44.8MB が未使用でした。

10月の技術ニュースと AI ツールの活用記事は、見出しの重複の検査で何度も落ちていました。記事を書かせるニュースの指示（プロンプト）は「何が変わったか」「技術的背景または提供形態」「開発者・利用者への実務影響」「まだ不明な点・次に見るべき点」の4つを必ず書かせ、モデルはこれをそのまま見出しにします。検査は、同じトピックの直近3本と、8文字以上の見出しが2件以上重なると不合格にします。指示が書かせた決まった見出しを、検査が重複と数えていました。

ニュースのトピックが失敗したときに休ませる仕組みはありましたが、休む時間は失敗の理由に含まれる英語の語で決めていました。理由は日本語で書かれていたため、どの語にも当たらず、休みは0分のまま毎時やり直していました。

個人で AI のコーディング支援を使って作るようになってから、まず動かすことを急ぎ、上限を決めるのを後回しにしていたと思います。今回の作り直しは、その後回しの分を片付ける作業でした。

本数を1にするだけでは偏った

本数を減らす方法を、手元のシミュレーションで比べました。10月7日から28日分を、すべての試行が成功し、新しいトピックは加わらないと仮定して数えています。ニュース以降の列は28日間の本数です。

1回に公開する本数を絞っても、毎時起動する限り本数は変わりませんでした。1日1本の上限を足しても、朝一番に時期が来ているのは毎日型の技術ニュースか曜日を過ぎた連載だけで、28本のうち19本が技術ニュース、スマートホームとレビューは0本でした。

最初の設計案は、トピックに「レーン」（ニュース・連載・スマートホーム・レビュー）を付けて割合で1日1本を選ぶ形で、出ない日がありました。採用したのは朝と夕方で枠を分ける案で、試算では28日で40本、週10本、0本の日はありません。採用の行は、AI ツールの活用記事を対象から外して数えています。

私の頭にあったのは、1日1〜2本くらいで、朝はニュース、夕方は連載がある日だけ、という形でした。1日1本に減らす案には、減らしすぎではないか、この量のサイトを読みに来る人がいるのか、と気になりました。話し合って「ブログくらいの規模」と割り切り、10月7日に、ニュースは毎朝1本、夕方は連載などを1日おきに出す形に決めました。

朝と夕方の枠にした

決めた形の細かい決まりは、次のとおりです。

• 朝7時に、ニュースを毎日1本出す
• 夕方18時に、連載・スマートホーム・レビューから1本出す。時期が来ているトピックがある日だけで、前の夕方の公開から2日あけ（月曜に出したら次は水曜以降）、直近7日で4本まで
• 9時・11時と20時・22時の起動は、その枠のやり直し用。1つの枠で1本までで、公開できたら残りの起動は何もしない
• 試行は1つの枠で1日3回まで。1回の起動で試すのは1トピックだけ
• 上限に達した回、枠の外の回、候補が無い回は、ファイルを何も書かずに終わる

設定は1つの JSON ファイルにまとめ、数字を書き換えれば次の起動から効くようにしました。夕方の枠の部分です。

{
  "id": "evening",
  "label": "夕方",
  "start_hour": 17,
  "end_hour": 24,
  "lanes": ["series", "smarthome", "review"],
  "max_per_day": 1,
  "max_per_7_days": 4,
  "max_attempts_per_day": 3,
  "min_gap_days": 2
}

17〜24時が夕方の枠で、18・20・22時の起動がここに入ります。

ファイルを何も書かなければ、リポジトリへの送信もビルドも起きません。そのため上限の判定は、設定のファイルを書き換えるほかの処理より前に置き、何もしない回は約90秒で終わる見込みです（切り替えた後、10月21日から23日の何もしない回は、ジョブの記録で31〜53秒でした）。公開済みの本数は、記録用のファイルが壊れても数え間違えないよう、リポジトリにある記事の公開日時で数えます。

AI ツールの活用記事は、5月から1本も出ておらず朝の枠を取ってしまうため、対象から外しました。切り替える前の記事も直近7日の数に入るので、夕方の最初の公開は10月11日になる計算でした。

失敗は段階で分け、画像は検査の後に

失敗の扱いは、理由の文字ではなく、どの段階で落ちたかで決めます。

止めたトピックは、人が記録を消すまで選びません。公開できたら、続いた回数は0に戻します。

切り替える前に別の AI に頼んだコードレビューでは、検索の一時的な失敗まで内容の失敗に数えると、数日の障害でニュースのトピックがまとめて止まり得る、と指摘されました。この分け方に直してから切り替えています。

画像は、機械の検査に通ってから作ります。画像の後の最終確認で落ちたら、その回の画像を消します。さらにリポジトリに送る前に、どの記事からも参照されていない新しい画像は入れない安全網を置きました。

見出しの重複の検査は、ニュースに限り、決まった型の語だけでできた見出しを数から外しました。「NVIDIA Blackwellの技術的背景と提供形態」のように具体語を含む見出しは、今までどおり数えます。公開済みのニュース58本で数え直すと、直近3本と見出しが1件以上重なる記事は14本から3本になりました。

切り替えた日に起きたこと

本体のコードは、10月7日19時41分に公開用のブランチに入れました。切り替えは、あとでクラウドの設定で行う段取りです。

その前後、18時から22時の毎時の実行は全部失敗していました。もとからの問題で、生成し直した AI ツールの活用記事が、出典元のサイトの数が監査の基準に足りず、公開前の最後の監査で止まっていました。毎時、同じトピックが同じ理由で落ちていました。

このとき、ジョブのログには失敗の件数しか出ておらず、何で落ちたのかがすぐには分かりませんでした。20時24分の修正で、落ちた理由をログに出すようにしました。

23時の回は別の理由で落ちました。新しいコードが検査に落ちた原稿を下書きとして保存したところ、記事の冒頭の設定の欄（front matter）に題名が無く、公開日時も日付として読めない値で、サイトのビルドが失敗したのです。ビルドが落ちると、ほかの記事も公開できません。下書きは公開しないプレビュー用なので、読めない項目は代わりの値で埋める形に検査を緩め、23時32分に直しました。

その1分後の23時33分に、クラウドの設定を切り替えました。新しい仕組みを有効にする設定値をほかの値を消さずに足し、起動を7・9・11・18・20・22時の1日6回にしています。

切り替えた後の16日間

最初の朝の枠は10月8日7時の回です。10月23日までの16日間で、公開は20本（朝13本・夕方7本）でした。1日あたり1.25本で、すべての試行が成功する前提の試算（同じ16日間で23本）より3本少なく、その3本は朝の枠で出せなかった3日の分です。0本の日は12日の1日だけでした。夕方の枠は試算どおり11日に始まり、23日まで1日おきに出ました。

朝の枠で出せなかったのは11日から13日です。11日と13日は、記事はできたのに、公開の直前に動く最後の監査で「本文が短い」と落ちていました。元になる記事が2本しかないニュースは、書く側が長さの下限を1,600字に下げるのに、監査は元の2,100字で見ていたためです（本文は2,007字・2,057字など）。この食い違いは4月からあり、元になる記事が少なく短めの記事になった日だけ表に出ます。両日とも、7時・9時・11時の3回が同じ食い違いで落ちています。13日17時41分に、書く側と監査が同じ計算で下限を決めるように直しました。

12日は別の失敗で、朝のニュースは出せませんでした。この原因はその日のうちに直しています。

7日の休みに入ったトピックは2つです。技術ニュースは、18日から20日に見出し（H2）の数が足りないという理由で3回続けて落ち、7日休みに入りました。見出しの数を、AI に書き直させるループを抜けた後にしか数えておらず、足りなくても書き直しに戻らなかったためです。20日に、ループの中で数えて足りなければ書き直しに戻す形に変え、休みだけを解いて、続いた失敗の回数は残しました。そのあと21日と23日に公開しています。スマートリングの比較記事は、11日と13日に直近の記事との見出しの重なりで落ち、23日には書き直しに2回戻しても見出しの数が足りないままで落ちました。3回続いたので、23日の時点で30日までの7日の休みに入りました。ほかのトピックが公開できても、このトピックの続いた回数は0に戻りません。

これから

使われていない画像は、10月23日の時点で410枚・46.8MB です。10月7日の朝の384枚から増えた26枚は、切り替える前の7日の昼の回の画像22枚と、あとで消えた下書きが使っていた画像4枚です。ファイル名に入っている作成時刻で見ると、どれも10月7日までに作られたもので、10月8日以降に作られた画像で使われていないものはありません。検査の後に画像を作る順番と、送る前の安全網は働いています。古い画像の片付けは、10月23日の時点ではまだしていません。消すのは公開用のブランチの画像なので、範囲を月で決めて、一覧で確かめてから消す予定です。

公開前に置いた機械の検査は、AI が書いた記事の誤りと公開前の機械の検査についての制作ノートに書いています。記事を書くモデルの替え方は、モデルを比べてから替える決まりについての制作ノートにまとめました。制作の記録は過去の制作の一覧の Chronicle AI の項目にあります。