AIでブログを自動投稿する仕組みを3日でやめた実録｜AIニュース自動収集で分かった、自動化してよい範囲
2026年9月2日、寝ている間にAIニュースを自動収集して記事にする仕組みを作りました。そして9月5日、3日でやめました。やめた最大の理由は、動かなかったからではありません。取りこぼしもひととおり起こしたうえで、それでも「毎晩見張るほどの発表は、毎晩は無かった」と分かったからです。
AIでブログを自動投稿する仕組みの話は、たいてい成功例として語られます。でも本当に役に立つのは、どこまで自動化してよくて、どこでやめるべきかの線引きのほうだと思っています。この記事では、3日で畳んだ実録と、畳んだあとも残して今も動いている3つの設計判断を、みやっち🧑💻の一次情報として書きます。
AIによるブログ自動化（自動投稿）とは: Claude Code・Codexのようなコーディングエージェントに、ネタの検知・記事の下書き・公開前チェック・公開までの工程を、決めたスケジュールで実行させる運用のこと。記事を量産する話ではなく、「何を書いてよいか・何が出たら止めるか」という判定ルールごとAIに渡す点が核心。当サイト（ai-crew-school.jp）では、毎朝7時にAIニュースを自動収集して記事化の可否を判定し、通ったものを毎朝8時に公開する体制が動いている。
きっかけ: 「日本語の解説はもう多い」で見送った日
2026年9月2日の朝まで、当サイトのAIニュースのチェックは朝7時に1回だけでした。その朝、仕組みはClaude Fable 5.1の発表を検知していたのに、「日本語の解説がすでに多い」という当時の判定ルールに従って記事化を見送りました。
みやっち🧑💻がその判定を覆して解説記事を午前中に公開しましたが、発表からは約8時間が経っていました。判定ルールが間違っていたのと、そもそも検知が遅かったのと、問題が2つ重なっていたわけです。
前者はその場でルールを直しました（主力ツールのニュースは、他媒体の本数に関係なく出す）。問題は後者です。発表が深夜に来ると分かっているなら、朝まで待つ必要はないのではないか——そう考えたのが出発点でした。
なぜ深夜2〜3時なのか: 体感を数字で確かめる
みやっち🧑💻の体感としては、以前から「OpenAIとAnthropicの発表は、だいたい日本時間の深夜2時か3時だ」と感じていました。ただ、体感のまま仕組みを作ると外します。そこで作る前に、公式発表の時刻を実際に数えました。
- Anthropic: 公式サイトに埋め込まれた公開時刻を2026年6〜9月の41件ぶん集計したところ、68%が日本時間の0時から6時に集中。最も多いのは米西海岸の午前10時＝日本時間の深夜2時ちょうどでした
- OpenAI: こちらは2026年9月に実測した範囲で、配信フィードの時刻表記が実際とずれている件が複数ありました（「10:00 GMT」と書かれていた4件は、独立したソースで裏を取るとどれも実際は10:00 太平洋時間でした）。そのまま数えると誤るので、主要な発表を1件ずつ、公式Xの投稿時刻・アーカイブサイトの初回取得時刻・報道時刻で照合しました
結果として、両社とも本命（新モデル・料金）の発表は米西海岸の午前10時＝日本時間の深夜2時が既定枠で、遅くとも午前4時45分までの窓に多くが収まると分かりました（この時差の等式は夏時間の期間の話で、冬時間に戻ると1時間ずれます）。Claude Fable 5は日本時間6月10日の午前2時、Claude Opus 5は7月25日の午前2時、Fable 5.1は9月2日の午前3時3分。体感は、Anthropicについては正しかったわけです。
ここは書き方を分けておきます。「深夜2〜3時」という感覚はみやっち🧑💻の観測ですが、41件の集計と1件ずつの裏取りをしたのはAIのほうです。体感を持ち込むのは人、それを数字にするのはAI、という分担でした。
作ったもの: 30分おきに見張って、そのまま出す
実測に基づいて、日本時間の0時から6時のあいだ、30分おきに両社の公式発表を見に行く仕組みを作りました。新着があれば公式発表そのものを読み込んで記事を下書きし、公開前のチェックを通ったものだけを公開する。人の承認は挟まない設計です。
作業は1日で終わりました。新しく書いたのは「新着を見つける部分」だけで、記事を書く工程も、公開前にチェックする工程も、公開する工程も、すでに毎朝8時の定常運用で動いていたものをそのまま呼んでいるからです（この定常運用の存在は前編にあたる記事で開示しています）。自動化は、ゼロから作るより既にある工程に検知の入口を1つ足すほうがはるかに速い、というのはこのとき実感しました。
3日で起きたこと
稼働は9月2日から9月5日まで。結果はこうです。
この仕組みが記事にしたのは1本だけ。OpenAIのGPT-6 Astraでした。しかも検知できたのが発表から約11時間後で（その記事を公開できたのはさらに約30分後）、「誰よりも早く」からはほど遠い。発火した残りの回は、新着なしの報告か、検知はしたけれど記事にしない種類——顧客事例や政策の発表——で終わりました。
11時間の遅れには、性質の違う原因が2つありました。
原因①: AIが人に質問して、そのまま止まった
深夜0時33分の回が、判断に迷って「日中もポーリングしてよいか」をみやっち🧑💻に質問し、そのまま8時間半返事を待ち続けました。スケジュール実行は、前の回がまだ動いている間は次を起動しません。結果、午前1時から6時半まで——その夜に走るはずだった14回のうち12回が、一度も発火しませんでした。
この仕組みには「ユーザーは不在なので、確認質問をせずに自走すること」と最初から書いてありました。それでも聞いてしまった。ここから学んだのは、この種の見張り役では、判断の質より実行の短さが優先するということです。迷ったら中止して報告するのが正しい止まり方で、聞いて待つのが最悪手。待っているあいだ、見張りそのものが止まるからです。対策として、手順書の冒頭に「質問しない・1回の実行は短く終える」を最優先の禁止事項として書き足しました。
原因②: 肝心のリリースが、見張っていた場所に載っていなかった
もう1つは設計の穴です。発表直後にこちらが取得したニュース配信には、肝心の本体告知が入っていませんでした。入っていたのは安全性の解説が1本と、顧客事例が2本。リリースそのものを機械で読める形で確実に拾えたのは、開発者向けの更新履歴だけでした。（いま同じ配信を開くと本体告知も並んでいます。こちらが取得したのがキャッシュ越しの古いコピーだった可能性が高く、実際このあとの対策のひとつは、キャッシュを避けて取りに行く処理でした。）
これを受けて、見に行く場所を2か所から4か所に増やしました。さらに、新しい記事が出ない形で起きる変化——たとえば「数日以内に提供予定」という一文が消えて一般提供が始まる、公開モデルの一覧に見慣れない名前が増える——を拾うために、ページの書き換えを見張る仕組みも足しました。読者にとっての本番は発表日ではなく自分が使えるようになった日で、それはニュース記事ではなく文書の1行が書き換わる形で来るからです。
やめた判断
9月4日には、日中の発表にも備えて24時間ポーリングに広げました。ただ、それは恒久的にやりたい形ではなかったので、2日後に設定を戻す予約タスクまで作る羽目になりました。見張りを厚くするほど、見張りを管理する手間が増えていく。
そして9月5日、やめました。判断の理由は一言でいうと「そんなに機能していない」です。3日強で記事化1本、それも11時間遅れ、残りは新着なしの報告。一方で運用の手間は増えていました。
ここが一番言いたいところなのですが、やめた原因は検知の頻度ではありませんでした。30分おきに見張れば30分で気づけるのは事実です。問題は、気づくべき発表が毎晩あるわけではなかったこと。頻度を上げても、拾うものが無ければ成果は増えません。自動化を設計するとき、つい「どれだけ速く回すか」を考えてしまいますが、先に確かめるべきはその頻度に見合う量のネタが本当に流れているかでした。
もうひとつ、やめやすかった理由があります。検知の入口を足しただけの作りだったので、外すのも入口を外すだけで済んだことです。記事を書く工程も公開する工程も共通のままなので、見張る場所を増やす仕事も、そのために書いたチェックの仕組みも、そっくり朝7時の側へ移せました。自動化は作るときより畳むときに差が出ます。あとで外せる形で足す、はこの3日で得た一番実用的な教訓かもしれません。
畳んだあとに残ったもの
いまは、朝7時にAIニュースを自動収集して記事化の可否を判定し、通ったものを朝8時に公開する体制に戻っています。30分おきに作った検知の仕組みは、そのまま7時の側が引き継いで毎日動いています。
そして、やめたのは「深夜に30分おきに見張る」という部分だけで、設計判断そのものは3つとも生き残りました。
① 拾う範囲と、出す範囲を分ける
検知するのは両社の全発表ですが、記事にするのは新モデル・新機能・料金やプランの変更・提供範囲・安全性に関わる発表だけです。顧客の導入事例・人事・政策関連は、検知しても記事にしません。公式の配信にはこうした話題がかなり混ざっています。OpenAIの配信で直近40件を数えたときは、製品・モデル・料金に当たるものは半分以下でした。
この線引きは、いま毎日ちゃんと仕事をしています。直近で言えば、9月10日は新着4件がすべて見送り、9月11日は新着12件がすべて見送り、9月12日も両社の新着3件をすべて見送りました（この日に公開した速報1本は、両社ではなく別の会社の発表です）。「出さない」という判断を毎日積み上げているのは、こちらの仕組みのほうです。全部を記事にすれば本数は増えますが、読者の少ない記事でブログ全体の密度が下がります。
② 全自動にしない部分を残す——3つのAIレビュー
公開の前に、執筆したAIとは別のレビュー役のAI（サブエージェント）が3つの観点で記事を検査します。出してはいけない情報が入っていないかの安全、モデル名・価格・仕様が公式情報と合っているかの事実、体験や数字に根拠があるかの一次情報。1つでも重大な指摘が残れば公開せずに止まり、みやっち🧑💻への報告に回ります。
実はこの記事自体が、その報告を受けて書き直したものです。最初の原稿は「深夜30分おきの仕組みが現在も動いている」と書いていました。9月5日に畳んだのに、9月2日に作った原稿がそのまま残っていたからです。3つのレビューが揃って「それは1週間前に廃止されている」と止め、書き直しの方向をみやっち🧑💻が決めて、いまの形になりました。何を「出してはいけない」とするかのルールを書くのは、やはり人の仕事です。
③ 当日検知・当日公開のみ——翌日へ持ち越さない
速報の価値は鮮度なので、当日に検知した発表だけを当日に出し、翌日への持ち越しはしません。これは「畳む判断」の予防線でもあります。持ち越しを許すと、出せなかったネタが在庫として溜まり、その在庫を管理する仕事が新しく生まれるからです。
あわせて、同じ発表を二重に記事化しないよう、一度処理した発表は記録して次からスキップする作りにしています。自動化は「動き続けること」より「変な動きをしないこと」のほうが難しく、止まる条件と重複を防ぐ仕組みを先に決めておくと壊れにくくなります。
非エンジニアが自動化するときの順序
この仕組みに専任の開発チームはいません。みやっち🧑💻が一人で作っています。全体をどう段階的に組み上げたかは前編に譲るとして、ここでは3日で畳んだ経験から言える、始める前に決めておくとよいことを4つ書きます。
- 先に「何本流れているか」を数える: 速さを上げる前に、拾うべきネタが実際にどれくらいの頻度で流れているかを数える。今回はここを飛ばして頻度から入りました
- 既にある工程に、入口だけ足す: 書く・チェックする・公開するの工程を使い回す形で足すと、作るのも畳むのも1日で済みます
- やめる条件を、作る前に書いておく: 「2週間で記事化が◯本に届かなければ畳む」のように数字で決めておくと、畳む判断が感情の問題になりません。今回そこまでは決めていなかったので、最後は「そんなに機能していない」という体感で判断しました
- 確認役のAIを立ててから、人の最終確認を外す: これは前編で書いた原則ですが、今回のように人が寝ているあいだに出す仕組みでは効き方がさらに大きくなります。順序が逆になると、事故がそのまま公開されます
やってみて思うのは、自動化でいちばん難しいのは作ることでも動かし続けることでもなく、やめることだということです。作ったものには愛着が湧きます。数字で見て畳めるように、始める前に基準を書いておくのがいいと思います。
「AIで記事を量産する」話とどう違うのか
真逆です。本数を増やすことに意味があるなら、この仕組みは畳まずに回し続けていたはずです。実際にやめた理由が「出すに値する発表が毎晩は無かった」である以上、増やしたかったのは本数ではありません。当サイトの自動化が増やしているのは、「公式発表という一次情報を読み、自分の実測とつなぎ、出してよいものだけを通す」という判断の回数です。
実際、この記事自体がその産物です。「深夜に30分おきに見張る仕組みを作りました」という成功譚は、書こうと思えば書けました。でも畳んだ事実を書かなければ、それは嘘になる。そして書いてみると、成功譚より「3日で畳んだ理由」のほうが、他では読めない情報になっています。書き手がAIになっても、AIの回答に引用されるのは一次情報のある記事だという競争のルールは変わりません。
よくある質問
AIが書いた記事を人の確認なしで公開して、問題は起きませんか？
リスクをゼロにはできません。当サイトでは、3つのAIレビューのどれかが重大な指摘を出せば公開せず止める設計にし、誤って公開した場合も数分で取り下げられる手順を用意しています。実際にこの記事が止まったように、ゲートは機能しています。それでも公開物の最終責任は運営者にあります。確認役のAIを立てる前に人の確認を外すことは、おすすめしません。
ブログの自動投稿ツールを買えば同じことができますか？
「決まった時刻に投稿する」だけなら汎用ツールでもできます。ただ、この仕組みの核心は投稿のタイミングではなく、「自分の事業では何を書いてよく、何が出たら止めるか」というルールごとAIに渡している点です。みやっち🧑💻が見てきた範囲の既製ツールには、その判定ルールを書き込む欄がありませんでした。手元では、Claude Code・Codexのようなコーディングエージェントへ手順書として渡す形で実現しています。定期実行そのもののやり方はClaude Codeのスケジュール実行の記事（Codex側はこちら）にまとめています。
3日でやめたということは、失敗だったのですか？
作ったこと自体は失敗だと思っていません。初日で形になり、途中で見張る場所を増やす手直しを挟んで、4日目には畳んでいます。確かめるのにかかったコストは、その4日ぶんです。「毎晩見張る価値があるか」は、作ってみないと分からなかったことでした。むしろ、判断の材料を4日で買えたと考えています。畳めなかった場合——たとえば作るのに1か月かけていたら、同じ結論に至っても畳む決断はずっと難しかったはずです。
自動化したあと、人の仕事は何が残るのですか？
判断の上流が残ります。何を対象にするか、どんな記事を良しとするか、何が出たら公開を止めるか、そしていつやめるか——このルールを言葉にして更新し続けるのが人の仕事で、発表を見張る目と記事を書く手はAIに移ります。今回で言えば、「そんなに機能していない」と判断して畳んだのは人の側でした。
深夜の見張り番も、レビュー役も、「これは出さない」という判断基準も、そして「もうやめる」という判断も、すべてみやっち🧑💻の事業のルールを言葉にしてAIに渡し、結果を数字で見て決めたものです。うまくいった部分だけでなく、畳んだ部分まで含めて自分の手元に残るのが、自分で作る自動化のいいところだと思っています。
AI Crewでは、Claude Code・Codexを使って、経営者・個人事業主・士業・会社員が自分専用の仕組みを自分の手で作れるようになるところまでを扱っています。自分で作れるようになると、動かしてみて畳むところまで自分で決められるようになる——みやっち🧑💻はそこが一番の利点だと思っています。まず無料セミナーでお会いしましょう。
