AIにブログを書かせたら、深夜に通知を連発した話。自動化システムに「記憶」を持たせる技術
Index
Introduction
「自動化すれば楽になる」——誰もがそう夢見ますが、制御なき自動化は深夜のトラブルを引き起こします。
本記事は、自律型AIが「記憶」を持たずに暴走し、深夜2時に通知を連発した失敗談（実話）です。
なぜAIは暴走したのか？ そして、どうやって「Kinesis ID（識別子）」と「状態管理（State Management）」を実装し、安全な自動化システムを構築したのか。その技術的教訓を共有します。
深夜2時の「テスト通知」
「自動化（Automation）」という言葉には甘美な響きがあります。
寝ている間にAIが記事を書き、WordPressに投稿し、SNSで拡散してくれる——そんな夢のようなシステムを構築しようとしていた、初期テストでの出来事です。
私たちが開発した投稿システム（Code Name: Kinesis Loader）は、Git上のMarkdownファイルを検知して自動で記事化する優れものでした。
しかし、実装初日の夜、自分のスマホを見て背筋が凍りました。
テスト用に登録していた自分の端末に、「新着記事のお知らせ」が5件も連続で届いていたのです。
原因は、記事の誤字を修正してPush（保存）したことでした。
AIは修正のたびに「お、新しい記事だ！」と判断し、真面目に通知を飛ばし続けていたのです。
「これがもし、本番環境で顧客に向けて放たれていたら……」
私たちの「デジタル社員」は、働き者すぎて、空気を読む機能が欠けていたのです。
技術的課題：ステートレスなAI
原因は単純でした。システムが「過去に投稿したこと」を忘れていたのです。
1. タイトル変更の罠: AIが気まぐれにタイトルを少し変えるだけで、システムは「お、新着記事だ！」と判断して別記事として投稿してしまう。
2. ゴミ箱のゾンビ: 一度削除した記事と同じファイルを再送すると、ID衝突や重複作成（Duplicate）が発生する。
3. メタデータの欠如: AIが生成するMarkdownテキストには、WordPressのPost IDなんて書いてありません。
つまり、AIとWordPressの間で「この記事はこれのことだよ」という同一性（Identity）を共有する手段がなかったのです。
解決策：「Kinesis ID」による統制
私たちは、自動化システムに「記憶」を持たせるため、「Identity Locking（ID固定）」メカニズムを実装しました。
1. 「指紋」をつける (Persistent ID)
記事ファイルに、人間には見えない「デジタル指紋」のようなものを埋め込むことにしました。
具体的には、「発行日」と「記事タイトル」を組み合わせたユニークな文字列です。
これにより、たとえファイル名が変わっても、システムは「これは、あの時書いた記事だ」と識別できるようになります。
<!– BYUUUMCODEBLOCK0 –>
2. 多重の検索ロジック (Logic Flow)
kinesisloader.php は、以下の順序で慎重に記事を照合します。
1. Search by ID: まず、上記IDを持つ記事がないかDBを検索（一番確実）。
2. Search by Title: IDがない場合のみ、タイトル一致を探す（移行用）。
3. History Check: 過去に処理したファイル履歴と照合し、不必要なループを防ぐ。
3. Notification Safety (安全弁)
そして何より重要なのが、「公開（Publish）」ステータスの廃止です。
AIが投稿する記事は、必ず「下書き（Draft）」として保存されます。
最後に人間が目を通し、「OK」ボタンを押した時だけ、初めて世界に公開され、通知が飛ぶ。
この「人間の承認」というフローをあえて挟むことで、誤爆のリスクをゼロにしました。
自動化は「スピード」ではない
エンジニアとして、私たちはつい「いかに速く、大量に回すか」に注力しがちです。
しかし、ビジネスにおける自動化の本質は「制御（Control）」にあります。
ただ暴走するフェラーリに価値はありません。
意のままに操れるハンドルと、確実に止まれるブレーキがあって初めて、そのスピードは武器になります。
AIという強力なエンジンを積むからこそ、私たちはより慎重な設計者（アーキテクト）であらねばなりません。
あなたのデジタル社員は、ちゃんと「記憶」を持っていますか？
返信を残す
Want to join the discussion?Feel free to contribute!