ブログ記事をAIで自動化した仕組みと、4日止まった話

このブログの記事は、AIが企画・下書き・図解・組版・投稿までの工程を回して作っています。人間が担うのは、公開の判断と、公開後のレビューです。この記事では、その工程の中身と、2026年8月5日から8日まで次に書く記事の企画が1本も立たなくなった停止の記録を、実測値ごと公開します。

先に断っておくと、これは成功談ではありません。設計上は1日2本まで出せる仕組みを組んだのに、実際には企画の在庫が尽きて止まりました。どこまで無人化できて、どこが壊れるのか。壊れた側まで含めて書きます。

このブログはAIが書いています。どこまでが自動で、どこからが人間か

定義をはっきりさせます。「AIが書いている」と言ったときに自動化されているのは工程であって、判断ではありません。2026年8月9日時点でこのブログには28本の記事が公開されていますが（サイトマップの実測値・タグページを除く）、ほぼ全数が同じ仕組みを通って出ています。

自動なのは工程、人間なのは判断

人間、つまり僕がやっているのは次の3つだけです。

• 公開後24時間以内に記事を読んでレビューする

• 判断が要る項目（新しい企画を採るか、方針を変えるか）に決裁を出す

• 事故が起きたら、それを機械のチェック項目に昇格させるかを決める

残りはすべて自動です。「実行は自動、責任は人間」が、この運用のいちばん上にある線引きです。 AIに記事を書かせること自体は難しくありません。難しいのは、書いたものを人間が見なくても外に出していい状態をどう作るかです。

この記事で開示しないこと

認証情報の保管方法やシステム内部のURLなど、守りの内側にあたる部分は書きません。公開する価値より、公開するリスクのほうが大きいからです。工程の細部はすでに別記事で書いているので、そちらに委譲します。

関連記事AI記事作成の品質管理——公開前に自動で守る機械ゲートの作り方AIに記事を書かせたいが品質が心配で任せきれない。その答えは人力チェックの強化ではなく、公開前に自動で合否を判定する機械ゲートです。僕のブログ全記事が通っている検査項目の実物と作り方5ステップを公開します。→

企画から公開まで。実際に走っている工程は何か

工程は6つです。

6つの工程と、それぞれの中身

工程を分けている理由はどこで壊れたかが分かるようにするためです。1つの大きな処理にまとめると、失敗したときに原因を特定できません。

機械が合否を出す場所、人間が見る場所

4つ目の機械ゲートが、この仕組みの心臓部です。見出しが3本以上あるか、本文が2,500字以上あるか、よくある質問か手順のブロックがあるか、自サイト内の関連記事へのリンクがあるか、画像が2枚以上ありすべて実際に表示できる状態か、タイトルと抜粋が規定の文字数に収まっているか、許可していない外部ドメインへのリンクが混ざっていないか。こうした項目を見ます。

ポイントは、これが「良い記事かどうか」を判定しているわけではないことです。判定しているのは「公開してよい形式かどうか」だけ。文章の良し悪しは機械には測れないので、そこは人間のレビューに回します。

この線引きをしないまま「AIに品質チェックさせる」と言い出すと、AIがAIの書いたものを採点して丸をつけるだけの循環になります。この運用でも、その自己採点方式は過去に一度導入して撤廃しました。

実測データが推測に勝る。GSC・GA4の数字は、企画段階で立てた仮説に優先する。

ゲートと評価基準の緩和・削除は禁止。没にした記録も消さない（没も学習データ）。

これは僕がこのブログ運用の原則として書き留めているものです。この記事の後半で、この原則が実際に試されます。

設計は「1日2本」。それでも8月5日から8日まで、企画は1本も立ちませんでした

ここから、うまくいかなかった話をします。この運用では記事の生成処理を1日2回、決まった時刻に自動で起動しています。1日の上限は2本なので、設計上の最大速度は週14本です。ところが2026年8月5日から8月8日までの4日間、新しい記事の企画が1本も立ちませんでした。

定義をはっきりさせます。この4日間、サイトの公開がゼロだったわけではありません。8月6日に1本公開しています。ただしそれは7月30日に立てた企画のうち実行されずに残っていた分を消化しただけで、この4日間に新しく立った企画はゼロでした。

止まった理由は技術的な故障ではありません。処理は毎回きちんと起動していました。起動して、在庫リストを見て、「未消化の在庫がゼロ」と記録して、何も作らずに終わる。これを7回繰り返しました。

僕がこの状態に気づいたとき、記録にはこう残っていました。「空の在庫へ1日2便の自動処理を撃ち続ける構成は、記録だけが増えて成果がゼロという消費形態にある」。止まったこと自体より、止まっていることが記録の中にしか存在せず、僕の手元まで届かなかったことのほうが問題でした。

なぜ止まったのか。蛇口は週最大14本、補充は週2本

原因は在庫管理です。出す側と足す側の容量が、最初から釣り合っていませんでした。

容量差は最初から埋まっていなかった

• 出す側（蛇口）: 1日2本、週最大14本

• 足す側（補充）: 週2本程度

この構造だと企画の在庫は必ず尽きます。尽きるまでの時間が長いか短いかの違いしかありません。自動化の設計で見落としがちなのは、処理速度ではなく原料の補充速度のほうです。

そして補充の担当は僕でした。自動処理側は新しいテーマを勝手に発明してはいけないルールにしていたからです。根拠のない思いつきで記事を量産すると、検索意図から外れた記事が増えるだけになります。このルール自体は間違っていなかったと思っています。間違っていたのは、「補充は人間がやる」と決めたのに、補充が滞ったときに人間へ届く経路を作っていなかったことです。

止まり方は静かだった

自動化は、壊れるときに派手なエラーを出すとは限りません。このケースではエラーが1度も出ていません。在庫がゼロなら何も作らずに終わるという設計どおりの動作で、その結果として4日間何も生まれませんでした。

エラーが出ない停止のほうが、エラーが出る停止より発見が遅れます。「異常が起きたら通知する」だけの監視ではこの種の停止は拾えません。拾うには「正常に何も起きていない状態が続いていること」を異常として扱う仕組みが要ります。

過去にどんな自動化を捨ててきたかは、別記事にまとめてあります。

関連記事AI自動化の失敗例。AIVESTが捨てた自動化と設計原則AI自動化の失敗例を、AIVESTの実運用記録からそのまま公開します。カバー画像の二重表示、設定ずれの2日連続停止、並列実行の残高枯渇、自己採点ゲートの撤廃。共通する3つの原因と、失敗を検査項目に変える設計原則まで解説します。→

数字は何を言っているか

数字はGoogle Search ConsoleとGA4から週1回自動取得して、計器ファイルに1行ずつ追記しています。2026年7月19日〜25日の週と、7月26日〜8月1日の週を並べます。

• 表示回数: 40 → 125

• クリック: 7 → 7

• セッション: 129 → 180

• 平均掲載順位: 20.5 → 39.0

ここで因果を断定しません。手元にあるのは2週分だけで、「記事を増やしたから順位が落ちた」とも「増やしたおかげで表示が増えた」とも言い切れません。確かなのは次の1点です。平均掲載順位は表示された全クエリの平均なので、新しい記事が50位から100位の低い順位で表示され始めると平均値は必ず悪化します。記事別の数字を見ても既存記事が急に落ちた動きは確認できていません。つまりこの悪化は既存記事の下落ではなく、新規記事の立ち上がりによる構造的なものと読むのが自然です。

もう1つ、はっきり分かることがあります。同じ週、助成金に関連する10種類の検索クエリで合計23回表示されていますが、掲載順位はすべて70位から100位で、クリックはゼロでした。需要は実在するのに順位が圏外にある。これは新しい記事を書く話ではなく、既存記事を直す話です。

計器そのものの作り方は別記事に書いています。

関連記事Claude CodeでGSC/GA4の週次レポートを自動化GSCとGA4の数字は、見に行く運用にした時点で続きません。このブログで毎週月曜9時に無人で走っている計測の仕組みを、取得から記録・改善提案まで運ぶ4ステップと、実際に出ている週次の数字ごと公開します。→

クリックの大半は指名検索から来ていた

もう1つ、正直に書いておきたい数字があります。2026年7月26日から8月1日の週、検索クエリ別に記録されたのは31クエリ・73表示・5クリックでした。そのうち4クリックが「aivest」という社名の指名検索で、平均掲載順位は2.1位。残る1クリックは記事タイトル由来のクエリでした。

（週の合計クリック数7とクエリ別の合計5は一致しません。Google Search Consoleが表示の少ないクエリをプライバシー保護のため内訳に出さない仕様によるもので、どちらかが誤りというわけではありません。）

記事を28本出した時点で、検索から人を連れてきているのはまだ社名検索が中心であり、狙って書いたキーワードでの獲得はこれからだということです。 これを隠して「AIでブログを自動化したら流入が伸びました」と書くこともできますが、それは嘘です。公開1か月弱でこうなるのは想定内ですが、想定内であることと成果が出ていることは別です。

止まってみて、変えなかったことと変えたこと

4日間の停止を受けて、僕が出した判断を書きます。

変えなかった3つ

1つ目。機械ゲートと評価基準は緩めませんでした。 「ゲートを緩めれば記事は出せる」という選択肢は一度も検討していません。止まった原因はゲートではなく在庫なので、緩めても在庫は増えません。動いていない原因と違う場所をいじるのは、いちばんやってはいけない対処です。

2つ目。公開後24時間以内の人間レビューは維持しました。 記事は人間の事前承認なしで公開できる設定ですが、公開後24時間以内に僕が読むことをセットにしています。事前承認を外すかわりに、事後レビューを外さない。この非対称が、自動公開を許容できる条件です。

3つ目。仮説を台帳に記帳する運用も変えていません。 記事を1本作るたびに台帳へ1行追加します。日付・スラッグ・当てにいく仮説・狙うキーワード・30日後のKPI目標。公開から28日経ったら実測値と突き合わせ、当たったか外れたかを記入します。没にした企画も削除せず理由をつけて残します。書いた記事の本数ではなく、検証できた仮説の本数が資産です。

変えた1つ

変えたのは補充のルールです。2026年8月8日に、企画の在庫が6本を下回ったら、自動処理側が実測データから新しいテーマを起案して在庫に追加してよいと改定しました。条件は4つ。起案には出所を必ず書く（Search Consoleの実測か社内の一次情報を根拠にする）。実測由来を優先し、思いつきでは起案しない。公開記事は従来どおり24時間以内の人間レビュー対象。ゲートと評価基準の緩和は引き続き禁止。

理屈はこうです。在庫ゼロで停止し続けるより、根拠つきの自動補充で継続するほうがマシ。ただし品質の防波堤は1ミリも動かさない。緩めるべきは入口の在庫ルールであって、出口の合否基準ではありません。

計測して、診断して、改善するという外側の構造そのものは、別記事で詳しく書いています。

関連記事ループエンジニアリングとは——AIが自分で改善を回す仕組みループエンジニアリングとは、AIに単発の作業ではなく“作る→測る→直す”の改善サイクルごと任せる設計手法です。プロンプト・ハーネスエンジニアリングとの違い、実際に回っている僕のブログの改善ループの実物と作り方を公開します。→

これからブログをAIで自動化する人が、先に決めておくべき3つは何か

自分の失敗から抽出すると、着手前に決めておくべきことは3つです。

1つ目は、蛇口の太さより補充の太さです。

「1日何本出せるか」を先に設計したくなりますが、実務で先に尽きるのは原料のほうです。週に何本のテーマを、誰が、何を根拠に足すのか。原料の補充が週2本なら、出力の設計も週2本に合わせるべきでした。

2つ目は、機械が合否を出せる基準を先に書くことです。

「品質を担保する」では動きません。文字数、見出しの数、リンクの有無、画像が実際に表示できるか。機械が合否を返せる形にまで落とせた項目だけが、自動化の対象になります。 落とせなかった項目はそのまま人間の仕事として残ります。この線引きを先にやると、「AIに任せられる範囲」が自動的に決まります。

3つ目は、人間ゲートをどこに置くかです。

この運用では公開後24時間に置きました。記事は修正も非公開化もできる、つまり可逆なので事後に置けます。取り返しがつかない作業、たとえば顧客へのメール送信や決済の実行なら、ゲートは事前に置くしかありません。可逆かどうかで、ゲートの位置が決まります。

3つ全部に共通するのが、止まったときに人間へ届く経路を用意しておくことです。僕の4日間の停止は、この経路が無かったせいで長引きました。

よくある質問

まとめ。止まったことまで書けるのが、実際に回している証拠です

• 企画・執筆・画像・機械ゲート・組版・投稿の6工程をAIが回し、人間は公開の判断と公開後24時間のレビューを担う

• 設計上は週14本まで出せるが企画の補充は週2本程度で、2026年8月5日から8日まで新しい企画が1本も立たなかった

• 原因は故障ではなく出力と補充の容量差。しかもエラーが出ない静かな停止だった

• 2026年7月26日から8月1日の週は表示125・クリック7・平均掲載順位39.0。記録された5クリックのうち4件は社名の指名検索

• 在庫の補充ルールは変えたが、機械ゲートと人間レビューは緩めていない

AIによるブログ自動化の記事は世の中にたくさんありますが、その多くは組んだところまでしか書いてありません。実際に回すと、原料が尽きます。静かに止まります。数字はすぐには伸びません。 そこまで書けるのは、実際に動かしている人だけです。

自社で組むなら、まず「どの業務をAIに任せてよいか」を決めるところからです。任せる範囲と人間ゲートの位置と止め方を先に決めるだけで、僕が踏んだ穴のいくつかは避けられます。

自社の運用設計を一緒に組み立てたい場合は、AI顧問サービスのお問い合わせからご相談ください。