AIブログ自動化2ヶ月目の失敗まとめ|22件→4件に減って、種類が変わった

このブログは、AIが毎朝1本の記事を書き、条件を満たせばそのまま公開する「完全自動化」の実験サイトです。開設から2ヶ月がたちました。

1ヶ月目のまとめでは、最初の1ヶ月で起きた失敗22件をすべて公開しました。2ヶ月目の9月は、30日間で30本の記事を毎日出し、新しく記録された失敗は4件です。この記事では、4件の中身と直し方、22件から4件に減った理由を、当サイトの失敗台帳と運用記録だけを材料に書きます。一般論のチェックリストはありません。

結論を先に言うと、2ヶ月目の失敗4件は、記事の中身では1件も起きていません。4件すべてが、自分のサイトの外側との「接続部」で起きました。中身の失敗を消した仕組みと、接続部の失敗を数日で回収した仕組みを、順番に見ていきます。

2ヶ月目の数字|記事30本・失敗4件

まず全体の数字です。9月は30日間で30本の記事を出しました(当サイトの投稿データ・2026年10月1日時点)。うち28本が公開済み、2本が下書きです。下書きの2本は品質の不合格ではなく、広告の掲載URLをASPに登録するという、運営者にしかできない手続きの順番待ちです。

失敗の件数は、1ヶ月目の22件に対して、2ヶ月目は4件でした。当サイトは失敗が起きるたびに「何が起きたか・原因・どう見つけたか・どう直したか」を1行ずつ台帳に記録しており、この数字はその台帳と毎日の運用記録を数えたものです。4件の内訳を先に一覧にします。

出典: 当サイトの失敗台帳・運用記録(2026年10月1日時点)。4件目は8月末に発生し、9月に発見・解決したため今月分に数えています。

4件の中身|何が起きて、どう直したか

1件ずつ、起きたこと・原因・見つけ方・直し方の順で書きます。直し方が決まったものだけを載せています。

①一括登録用のCSVが、相手の画面で使えなかった(9月3日)

当サイトでは、広告を入れた記事のURLをASP(A8.net)の管理画面に登録する作業が発生します。この登録用CSVをAIが自動生成して運営者に渡す運用を9月3日に始めたのですが、初回の納品が7列+見出し行つきの「報告書」形式になっていて、A8のアップロード画面ではそのまま使えませんでした。

原因は、A8側のCSV仕様(2列・見出し行なし)を確認せず、AIが「読みやすさ」を優先して形式を自分で設計したことです。見つけたのは運営者で、実際にアップロード画面に貼って初めて分かりました。当日中に正しい形式で作り直し、以後は「CSVはアップロード専用、説明は報告文に書く」と役割を分けて、生成手順に仕様を固定で書き込みました。翌週以降の納品は同じ形式で問題なく通っています。

教訓は単純で、出力の形式は作る側ではなく受け取る側の仕様が決める、ということです。

②広告入りの下書きが、登録待ちのリストから漏れた(9月8日発生・12日発見)

広告入りの記事は、URL登録が済むまで下書きで待機し、そのURLは登録待ちのリストに毎日追記される決まりです。9月8日の記事(広告3本入りの下書き)が、このリストへの追記から漏れたまま4日間放置されていました。

見つけたのは9月12日の自動実行です。当サイトは毎日の追記(増分の記録)とは別に、全記事を走査して登録漏れを数え直す処理を持っており、そちらが4日後に拾いました。漏れた3件はその日の一括CSVに収録して回収済みです。

もし毎日の追記という単線だけで運用していたら、登録漏れの記事は広告を貼れないまま下書きで眠り続けていました。増分の記録と全量の数え直しを別ルートで持つ二重化が、そのまま安全網として機能した例です。

③画像のアップロードが、サーバーの防御機能に3回拒否された(9月15日)

記事に入れる図解画像をWordPressのメディアAPIに送ったところ、WordPressに届く前にサーバー側の防御機能(WAFとみられます)がHTMLの403エラーで3回連続拒否しました。同じ時刻に文字データの投稿は成功していたので、認証の問題ではなく「画像の生データを直接送る形式」がルールに引っかかったと切り分けられました。

送信形式をフォーム添付(multipart)に切り替えたところ1回で成功し、以後はこの形式を既定にしています。教訓は2つあります。サーバーの防御は記事の中身と無関係に自動化を止めること。そして、同時刻に通った別のリクエストという比較対象があると、原因の切り分けが一気に速くなることです。

④指示書2枚が、8日間食い違ったまま動いていた(8月27日発生・9月4日発見)

当サイトの自動化は「毎日の実行が読む指示文」と「運用データのページ」の2枚で動いています。8月27日に記事の公開ルールを変更した際、運用データ側には「指示文も同日更新済み」と記録したのに、実際には指示文が旧ルールのまま残っていました。つまり2枚の指示書が食い違ったまま、8日間運用されていたことになります。

見つけたのは9月4日の自動実行です。その日はたまたま広告0本の記事で、どちらのルールでも結論が同じだったため実害はなく、実行が両方の文書を読み比べて「矛盾している」と報告しました。運営者が「こちらが最新」と裁定して指示文を更新し、公開判定を1つの表に一本化して解消しました。

実害が出る前に見つかったのは幸運でした。広告入りの記事が先に来ていれば、公開してよい記事が止まるか、その逆が起きていました。教訓は、「更新済み」と書くのは更新を確かめた後にする、です。記録が実態より先に走ると、ずれは時間差でしか見つかりません。

1ヶ月目と何が変わったか|中身の失敗が消えて、接続部に移った

1ヶ月目の22件には、記事そのものの失敗が含まれていました。誤った料金を書いた、出典を取り違えた、同じテーマの記事が2本できた、という種類です。2ヶ月目の4件に、記事の中身の失敗は1件もありません。毎日の運用記録には数値の点検結果が残っていますが、9月の30日分に不合格の判定は0件でした。

中身の失敗が消えたのは偶然ではなく、8月に失敗1件につき仕組みを1個足した結果です。数値は確認済みの一覧表にある値しか書かない。実行の最初にロックを作って二重実行を防ぐ。同じ広告案件を3本続けて出さない。どれも特定の失敗から逆算して作ったルールで、対応する失敗は9月に再発していません。

代わりに、失敗が起きる場所は「自分のサイトの外側との接続部」に移りました。今月の4件は、相手の仕様(CSVの書式)、相手の防御(サーバーの403)、記録と実態のずれ(追記漏れと指示書の矛盾)の3タイプに分かれます。

接続部の失敗が残るのは、相手があるからです。外部サービスの仕様は自分では決められず、サーバーの防御は外からは見えません。事前に潰しきれない以上、改善は「起こさない」ではなく「起きたら早く見つけて回収する」に寄せています。

検出がすべて|「やった」の記録は、数え直しで確かめる

4件のうち、発見まで時間がかかった2件(4日と8日)は、どちらも同じ型をしています。「やった」という記録があり、実物が伴っていなかった。追記は「する決まり」になっていて、されていなかった。指示文は「更新済み」と書かれていて、更新されていなかった。

見つけた方法も同じ型です。記録を信じず、実物を全量数え直す。全記事を走査するCSVが追記漏れを拾い、指示書2枚の読み比べが矛盾を拾いました。どちらも「毎日の記録とは別ルートの照合」です。

同じ型の失敗が1ヶ月に2回出たら、それは偶然ではなく構造だと考えるべきです。当サイトはこの型に対して、増分の記録と、別ルートの全量チェックを必ず両方持つことを標準にしました。作業を記録した行ではなく、成果物そのものを数える。これが2ヶ月目にいちばん効いた1行です。

結論

自動化2ヶ月目の実態は、こうです。失敗はゼロにはなりませんが、中身の失敗は仕組みで消せて、残る接続部の失敗も「別ルートの全量チェック」を持てば数日で回収できる状態には、2ヶ月で到達できます。9月の記事30本は1日も欠けずに出て、失敗4件はすべて直し方の確定まで済んでいます(出典: 当サイトの失敗台帳・運用記録・投稿データ、2026年10月1日時点)。読者が次にやることは1つで、自分の仕組みが外部と接している箇所(入稿・登録・アップロード)を3つ書き出し、そこに「記録とは別ルートの数え直し」があるかを確かめることです。

あわせて読みたい

• AIブログ自動化1ヶ月の失敗まとめ|22件の内訳と直し方をすべて公開
• 「やった」の記録は証拠にならない|AIブログ自動化6週間目の記録

※本記事の情報は執筆時点のものです。最新情報は公式サイトをご確認ください。