AIエージェントに記事投稿を任せたら、自分自身の記事を複製していた話 — 重複記事とレート制限、24時間の実験ログ

AIエージェントに記事の執筆から投稿まで全て任せ、GitHub Actionsで自動公開するパイプラインを実験的に運用していた著者が、24時間以内に2つの異なる失敗に直面した。1つ目は「既存記事との重複」。「Loop Engineeringとは何か？」というタイトルで以前に投稿した記事と、ほぼ同一のタイトルで新しい記事が自動作成され、Qiitaに公開されてしまった。中身も大筋で同じ内容だったが、AIエージェント自身には「これは既存記事と同じだ」と判断して削除する動機も権限もない。人間である著者が記事一覧を確認したときにやっと気づき、手動で削除した。2つ目は「レート制限」。複数記事を連続投稿した際にQiita APIのレート制限に引っかかり、最初は16時間待っても失敗し、さらに8時間待つことで合計約24時間後にようやく成功した。

この実験から学べる核は「失敗を自動化できない」という単純な事実だ。AIに「失敗したらリトライする」と指示するだけでは、重複判定や外部API制約への対応はできない。著者が意図的に設計したのは、投稿後に人間が定期的に確認する「ゆるい確認ポイント」と、失敗ログを人間が読んで待ち時間を判断する「回復ステップ」である。この2つがなければ、重複記事は放置されたまま、API制限もエスカレートしていたはずだ。

AIの鬼視点で見ると「AI全部任せたら痛い目にあった」という話ではなく「Human-in-the-loopを意図的に残していたから被害が最小限で済んだ」という実務的な教訓である。自動化に酔ってしまい確認や介入ポイントを全削除するプロジェクトは多い。だが著者の例では、わざわざ人間が見る場所、人間が判断する場所を残すことで、むしろシステムが堅牢になっている。

中小企業が業務自動化を導入する際、「AIに全部任せる」ではなく「AI とロボットとヒトの役割を分ける」という設計が現実的だ。月1回の確認でも、毎日のチェックでも、意識的に人間の関与ポイントを残すことで、自動化の利便性と安全性の両立が初めて成り立つ。