2026-08-28 · code, life

自動投稿を組んだら同じ記事ばかり量産していた：AIパイプラインの「回っている」と「正しく回っている」を分ける定期監査設計

自動化の失敗は静かに、大量に起きる

私はブログ記事をAIで自動生成し、週3回（火木土 06:03 JST）に投稿するパイプラインを組んでいる。GitHub Actions + Anthropic API という構成で、テーマをローテーションしながら記事を生成→コミット→公開する仕組みだ。

動き始めたときは「これで発信が安定する」と思った。毎週決まった時間に記事が上がり、ストックが増えていく。しかし半年ほど経ったとき、ふとアーカイブを見返して気づいた。同じテーマの記事が十数週分、連続して並んでいた。

タイトルは微妙に違うが、切り口も結論も似通っている。読者から見れば「また同じ話か」と感じるレベルの重複だった。自動化は回っていた。だが正しく回ってはいなかった。

テーマ選定のインデックス初期化バグ

原因はテーマ選定のロジックにあった。記事生成スクリプトは、テーマのリストから順番に1つずつ取り出し、次回用にインデックスをファイルに保存する設計だった。ところがこのインデックスファイルの初期化処理が、毎回走っていた。

つまり「今回は3番目のテーマを使った。次は4番目」という状態を記録しても、次回の実行時には「1番目から」に戻っていた。結果として、リストの先頭テーマばかりが繰り返し選ばれ続けた。週3回 × 数ヶ月で、同一テーマが数十本量産されていた計算になる。

さらに悪いことに、このバグによる記事の中には実体験に基づかない内容も混入していた。AIはプロンプトに沿って文章を生成するが、私の事実台帳にない数字や制度名を「それらしく」埋めてしまうことがある。通常のローテーションなら各テーマは数週に1度しか回ってこないため、生成後の目視チェックで弾いていた。だが同一テーマが連続すると、私自身が「また同じか」と流し読みしてしまい、捏造部分の見落としが発生していた。

削除と再生成：事実台帳への立ち返り

気づいた時点で、私は次の手順を取った。

重複記事の特定：アーカイブから同一テーマが連続している区間をリストアップ
事実台帳との突合：各記事の内容を、著者事実台帳（私の実体験・実施済み事項をまとめたファイル）と照合
削除基準の設定：台帳にない事実を含む記事は即削除。台帳に沿っているが切り口が被る記事は、残す優先度を判断
再生成：削除した週の記事は、別テーマで生成し直す。このとき、インデックス初期化バグを修正済みのスクリプトを使う

結果として、十数本の記事を削除し、代わりに事実台帳に忠実な記事を再投稿した。読者から見れば「過去記事が差し替わった」程度の変化だが、私にとっては自動化の信頼を取り戻す作業だった。

自動化の品質を守る定期監査設計

この経験から、私は次の定期監査ルールを設けた。

1. 週次：生成記事の目視チェック

公開前に、生成された記事を1本ずつ読む。タイトル・リード文・見出し構成が事実台帳と矛盾していないかを確認する。時間にして1本あたり3分程度だが、この3分を省くと捏造が紛れ込む。

2. 月次：テーマ分布の確認

過去1ヶ月分の記事カテゴリ（biz / code / fi / life / side）をカウントし、偏りがないかをチェックする。特定カテゴリが連続している場合、スクリプトのローテーション設定を見直す。

3. 四半期：アーカイブ全体の再監査

公開済み記事を改めて読み直し、事実台帳との齟齬がないかを確認する。制度変更や自分の状況変化（例：資格取得・副業終了）により、過去記事が「当時は正しかったが今は誤り」になっている場合もあるため、この段階で修正または削除する。

自動化は「回っている」ことと「正しく回っている」ことが別だ。スクリプトがエラーを出さずに動いていても、出力の中身が狂っている可能性は常にある。監査する仕組みまでが自動化の一部だと、今は考えている。

まとめ

ブログ自動投稿のインデックス初期化バグにより、同一テーマの記事が十数週分量産されていた。加えて実体験に基づかない記事も混入し、削除と再生成で立て直した。

自動化の失敗は静かに起きる。エラーログに残らず、見た目は正常に動いている。だからこそ、週次・月次・四半期の定期監査を設計し、出力の中身を人間が確認する習慣が要る。

AI導入を考えている人へ。自動化は「回す」設計と「監査する」設計をセットで組むこと。そうしないと、私のように数ヶ月後に「実は壊れていた」と気づくことになる。

まとめて読む: AI活用・自動化

← ブログ一覧へ戻る