DXは「入れて終わり」にした瞬間に失敗する ― 自動化が15記事を”誤爆”した朝

DXやAI活用の話になると、どうしても「何を入れるか」に関心が集中します。どのツールがいい、どのAIが賢い、と。でも現場でいちばん事故るのは、導入した後の運用です。今日は成功事例ではなく、自分がやらかした失敗の話をします。同じ立場の中小企業には、成功談より役に立つはずなので。

朝、起きたら15記事が”誤爆”していた

やっていたのは、こういう自動化です。米国経済ニュースをRSSで取ってきて、5本を抜き出し、それぞれ本文を取得して、まとめて1本の記事にしてブログへ自動投稿する——朝7時をトリガーにセットした、よくある「情報収集＋発信の自動化」です。

ところが、ある朝いざ動かしてみたら、まとめて1本のはずが、15記事が個別に投稿されていた。想定の完全に外側の結果です。落ち着いて見ると、どうやら朝7時のトリガーが3回発火していたらしい。5本 × 3回 = 15本。しかも「5本を1本にまとめる」処理も効かず、バラバラに出てしまっていた。

自動化は、動いているときは何も言いません。壊れ方も静かで、しかも派手なんです。手作業なら「あれ、多いな」と途中で気づける。自動化は気づく人がいないまま、最後までやり切ってしまう。

自動化が15記事を誤爆。5本まとめて1記事のはずが、バラバラに15本。 — 5本まとめて1記事のはずが、トリガーの多重発火でバラバラに15本。

犯人は「賢いAI」じゃなくて、地味なデータベースの遅延だった

原因を追っていくと、意外なところに行き着きました。AIの精度でも、プロンプトでもない。裏で使っていたデータベース（記事をためておくための Supabase・無料プラン）への書き込みが、前日から異常に遅くなっていたんです。

書き込みが遅い → 処理が終わったのか判定できない → 待ちきれずにループや再実行が絡む。この「遅延」が、多重発火と誤爆の引き金を引いた、というのが今のところの見立てです。

ここが、DXのいちばん見落とされる急所だと思っています。華やかなAI部分ではなく、その足元の地味なインフラ（DB・保存・待ち時間）で事故は起きる。「賢いかどうか」ではなく「詰まったときにどう振る舞うか」。運用とは、結局そこの設計です。

犯人はAIじゃない。事故は足元のインフラで起きる。 — 水面上の華やかなAIではなく、水面下の地味な配管（DB・保存・待ち時間）で事故は起きる。

「全部ためる」を疑う ― 富豪的な設計は無料枠で破綻する

もう一つ、根っこにあった問題は設計思想でした。

取ってきた記事を、片っ端からデータベースにためる構成にしていた。でも無料プランの容量は、DBが500MB、ストレージが1GB。スクレイピングして貯め続ければ、いつか必ず頭を打ちます。そして容量が逼迫すると、書き込みはさらに遅くなる。遅延 → 誤爆の悪循環の、そもそもの上流です。

そこで立ち止まって考え直しました。「そもそも、全部を永続保存する必要があるのか？」——ニュースをまとめて投稿するだけなら、その場の一時的なメモリに持っておけば十分で、恒久的なデータベースは要らないかもしれない。

これは中小企業のDXでよくやる失敗と、まったく同じ形です。「とりあえず全部データを貯めよう」「立派な基盤を先に作ろう」。気持ちは分かりますが、たいていの業務は、そんな重い器を必要としていない。器が重いほど、運用コストと事故率が上がる。目的に対して、いちばん軽い構成は何か——ここを最初に削る勇気が、定着の分かれ目になります。