はじめに

24時間。

これが何の数字か、先に種明かしはしません。まずこの記事を書くまでの経緯から話させてください。

この技術記事シリーズ（Zenn・Qiita合わせてこれで20本を超えました）は、私が毎回手でエディタを開いて書いているわけではありません。テーマ選定・執筆・フォーマット整形・コミット・pushまでをAIエージェントに任せ、GitHub Actions経由でZennとQiitaに自動公開するパイプラインで運用しています。

これは手抜きのつもりでやっているわけではありません。拙著『AIエージェント設計論』の核はHarness Engineering（AIが安全に検証されながら動ける実行環境の設計）とLoop Engineering（失敗を検知して直すループの設計）です。だったら自分の記事公開作業そのものを、その思想の実験台にしてしまおうというのが最初からの狙いでした。理屈をブログに書くだけでなく、自分の見える範囲で毎日回してみないと、どこで壊れるかは分かりません。

そして先日、そのパイプラインは実際に2回壊れました。この記事は、その2つの失敗を隠さずに書く一次体験レポートです。

TL;DR

この記事シリーズはAIエージェントによる自動執筆・自動投稿パイプライン（GitHub Actions経由）で運用されている。これは書籍の思想を自分自身で検証するための、意図的な選択
失敗1：既存記事の確認が甘く、AIエージェントが「Loop Engineeringとは何か？」という既存記事とほぼ同一のタイトルで重複記事を新規作成・公開してしまった
失敗2：短時間に複数記事を連続投稿し、Qiita APIのレート制限に引っかかった。16時間空けても失敗し、さらに8時間待って合計約24時間後にようやく成功した
重複記事は人間（私）が手動で気づいて削除した。これは失敗というより、Human-in-the-loopの確認ポイントが実際に機能した証拠として書く
レート制限からの回復は、いわばRecovery Engineeringの実例。ただし今回の「16時間はダメで24時間なら成功した」というデータはサンプル数1件なので、確定的な結論としては扱えない
結論：AIに全部任せて放置していたから小さく済んだのではなく、意図的に人間の確認ポイントを残していたから被害が最小限で済んだ

背景：なぜ記事公開そのものをAIエージェントに任せているのか

「本を書いておいて、記事の運用は結局人間がやっているのでは説得力がない」——これが、このパイプラインを組んだ最初の動機でした。

Harness EngineeringとLoop Engineeringは、AIエージェントに任せる作業を「1回きりのタスク」ではなく「失敗を検知して直すループ」として設計する考え方です。だとしたら一番検証しやすいのは、自分が毎日触っている作業を実際にそのループに載せてみることだと考えました。テーマ選定、執筆、Zenn/Qiitaのフォーマットへの整形、git commit、pushまでをAIエージェントに任せ、pushをトリガーにGitHub Actionsが公開まで自動で走ります。

人間である私が担っているのは、次の3点だけです。

パイプラインの起動と、大まかな方向性の指示
公開後の記事一覧を、たまに自分の目で眺めて確認すること
明らかにおかしいと感じたときに、手で止める・消す・直すこと

この3点目が、今回の2つの事件で実際に効いた場所でした。

事件1：重複記事事件

このシリーズにはすでに「Loop Engineeringとは何か？AIエージェントを『失敗から改善するシステム』に変える方法」という記事があります。以前のセッションでAIエージェントが書き、Zenn・Qiita両方に公開済みでした。

ところがある回のセッションで、AIエージェントは既存記事の確認が甘いまま、同じテーマで新しい記事を書き始めました。できあがったタイトルは、既存記事とほぼ一字一句同じ——句読点のレベルでしか違わないものでした。中身も大筋で同じ内容の焼き直しに近く、AIエージェントはそれをQiitaに新規投稿として公開してしまいました。

Qiita上に同じテーマの記事が2本並ぶ状態になったのは、私が記事一覧をたまたま見返したときでした。タイトルが並んでいるのを見て、明らかにおかしいと気づき、後から作られた重複記事の方を手動で削除しました。

事件2：レート制限事件

もう1つは同じ時期に起きた、性質の違う失敗です。

複数の記事をまとめて仕上げたAIエージェントが、短い時間の中で連続してQiita APIに投稿リクエストを送りました。結果、Qiita側のレート制限に引っかかり、投稿が失敗しました。

その後の回復の経緯をそのまま書きます。

タイミング	試行	結果
T+0	連続投稿でレート制限発生	失敗
T+16時間	十分空けたつもりで再投稿	失敗
T+24時間（T+16時間からさらに8時間後）	再投稿	成功

16時間空けても失敗し、そこからさらに8時間待って、合計およそ24時間後にようやく成功しました。パイプライン側は失敗を検知して黙って止まっただけで、無理な連続リトライはしませんでした。ここも人間が状況を確認し、次に何時間空けて再投稿するかを判断しています。

この2つから学んだこと

2つの失敗は性質が違います。重複記事事件は「AIエージェントの確認不足」という設計側の穴で、レート制限事件は「外部APIの制約」という環境側の制約です。ただし、この2つに共通する学びが1つあります。

どちらも、パイプラインが自律的に「なかったこと」にできる失敗ではなかった、ということです。

もし人間の確認ポイントが一切なく、AIエージェントに「公開して、うまくいかなかったら勝手にリトライして」とだけ任せていたらどうなっていたか。重複記事はQiita上に残り続けていたはずです。AIエージェント自身には「これは既存記事の重複だ」と気づいて自主的に削除する動機も権限もありません。気づいて止めたのは、人間が記事一覧を自分の目で確認するという、意図的に残していたHuman-in-the-loopの確認ポイントでした。拙著の10章で扱っている考え方そのものです。

レート制限事件も同様です。パイプラインが「失敗したら少し待ってまた送る」という単純な自動リトライだけを積んでいたら、待ち時間の妥当性を判断せずに再試行を繰り返し、かえって状況を悪化させていたかもしれません。今回は人間が失敗ログを見て、待つ時間を判断してから再投稿しています。これはRecovery Engineering——失敗から回復する手順をあらかじめ設計しておくという考え方——の、小さいながらも実例になっています。

つまり今回の話は「AIに全部任せて放置していたら痛い目にあった」という話ではありません。意図的に人間の確認ポイントを残していたからこそ、被害が記事1本の重複と1日弱の遅延で済んだ、という話です。ループを完全自律にしなかったことが、今回はそのまま防波堤になりました。

自己批判：この記事について正直に言うと

レート制限のデータについて、正直に言っておきたいことがあります。「16時間では失敗し、24時間では成功した」という今回の観測は、試行がこの1回しかありません。境界がちょうど16時間と24時間の間のどこかにある、と確定的に言えるだけのサンプル数ではありません。Qiita側のレート制限の正確な仕様も公開されていないため、今回の待ち時間はあくまで「今回はこの間隔で成功した」という一次体験の記録であり、再現性を保証する数値ではありません。次に同じ失敗が起きたときに、また同じ間隔で成功するとは限らない、という前提で読んでください。

重複記事事件についても、AIエージェント側のログを詳細に遡って「なぜ既存記事の確認を怠ったのか」という根本原因までは、この記事の時点では特定できていません。確認手順そのものに具体的な改善を入れる前に、まずは事実として何が起きたかを記録する方を優先しました。

もう1つ。この記事自体もAIエージェントが下書きを書いています。つまりこの記事の執筆プロセスそのものが、内容と同じ構造——AIが書き、人間が事実関係を検分し、公開前に目を通す——をなぞっています。皮肉に見えるかもしれませんが、これは狙い通りです。パイプラインを止めずに、確認ポイントだけを機能させ続けることが、今回私がやりたかったことです。

今日から使えること

自動化パイプラインを組んでいる、あるいはこれから組もうとしている方向けに、今回の経験から言えることを3つにまとめます。

公開前チェックではなく、公開後チェックの場所を1つは残す。 今回の重複記事は「公開する前に確認する」仕組みではなく、「公開された結果を人間がたまに眺める」という緩い確認で見つかりました。厳密な事前承認フローを組む余裕がなくても、結果を定期的に目視する場所を1つ確保するだけで、被害は小さくできます。
失敗を検知したら、パイプラインは黙って止まる設計にしておく。 今回レート制限に引っかかったとき、パイプラインは無理なリトライをせず失敗として止まりました。これが自動で何度もリトライする設計だったら、状況はもっと分かりにくくなっていたはずです。
回復にかかった時間の数値は、再現性のない一次データとして扱う。 「何時間空ければ成功するか」のような数値は、次に同じことが起きたときの目安にはなっても、仕様として信頼するものではありません。1回の観測を法則のように語らないことが、次の失敗への備えになります。

拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』では、こうしたHuman-in-the-loopの設計やRecovery Engineeringを含め、AIエージェントを実務で運用するための考え方を全16章で体系立てて整理しています。