自動化が「止まる」のと「詰まる」のは別の問題

AIエージェントのエラー処理を設計するとき、最初に分けて考えるべきことが2つあります。ひとつは「止まる」こと、もうひとつは「詰まる」ことです。この2つは原因も対処法もまったく別物ですが、同じ「エラー」として一括りにされがちです。

「止まる」のは外部要因が原因です。連携している外部サービスの仕様が変わった、認証の有効期限が切れた、といったケースが典型で、処理そのものが動かなくなります。動かなくなれば、当然すぐに気づけます。外部依存が原因で自動化が止まる仕組みと、その監視の置き方は自動化が止まる原因と対策｜外部依存を棚卸しし気づく設計にするで扱っています。

詰まりは「正常終了」の顔をしている

一方「詰まる」のは内部要因です。AIエージェントが作った成果物が、自分たちで決めた検品基準を満たしていない場合に起こります。厄介なのは、このときも処理自体は毎日動き続け、ログには「正常終了」と記録されることです。

止まるエラーは、システムが自分から「動きません」と教えてくれます。詰まるエラーは、システムは何も教えてくれません。基準を満たさなかった1件がどこかに置き去りにされたまま、それ以外の処理は何事もなく回り続けます。

落ちた1件を飛ばす運用が、なぜ静かに壊れるのか

詰まりに対処する方法として、実際によく選ばれるのが「その1件だけ飛ばして、次の処理に進む」というやり方です。一見合理的に見えます。1件の不良のために全体を止める必要はない、という発想です。

しかしこの設計には、見えにくい代償があります。基準を満たさなかった1件は、列から静かに姿を消します。後続の処理は滞りなく流れ続け、ログの見た目は健全なままです。

問題は、その1件が「世に出ないまま、誰にも直されない」ことです。飛ばすという選択は、不良品そのものを消しているわけではありません。不良品を直す機会を、構造ごと消しているのです。

  • 飛ばした1件は処理の列に戻らないため、人の目に触れる機会そのものが失われます。
  • 処理全体の「成功件数」だけを見ていると、飛ばした件数が増えていても異常だと判断できません。
  • 同じ種類の不良が繰り返し起きていても、毎回飛ばされるだけなので根本原因に気づけません。

ただし、飛ばす設計がいつでも間違っているわけではありません。線引きの基準は「その1件が消えても、後から作り直せば同じ状態に戻せるか」です。再取得すれば済む一時的なデータのように、使い捨てで積み上がらない処理であれば、飛ばして次に進んでも失うものはありません。

一方で、記事・商品ページ・帳票のように、1件ずつが積み上がって成果物になる処理では話が違います。その1件が出なければ、そこは欠番のまま埋まりません。自分が回している処理は、消えても作り直せば足りるものか、それとも積み上がっていく成果物の1コマなのか。まずそこを自問してみてください。

relmea が note 記事の下書きを自動で作っている工程でも、以前は同じ設計を採っていました。検品で項目が落ちた行は公開せず、次の行へ進む、という扱いです。動作としては安全に見えますが、結果として落ちた行は誰も直さないまま溜まっていきました。

エラー処理の4段設計：直す・再検品する・理由を残す・見張りが鳴らす

この反省を踏まえて、現在は「飛ばす」代わりに4段階の処理を挟むようにしています。順に見ていきます。

1. 直す

検品で項目が落ちた行のうち、直せる種類の不良だと判定できるものは、まず自動で直します。すべての不良を機械的に直せるわけではないので、ここでは「直せる」と判断できたものだけを対象にします。

2. 再検品する

直したあとは、もう一度同じ検品基準にかけます。直したつもりで実は直っていない、というケースを取りこぼさないためです。検品の基準そのものをどう作るかは、AIエージェントの成果物品質を守る検証設計の考え方で扱っています。

ここで大事なのは、再検品を1回だけに限定していることです。直しては検品、直しては検品と無限に繰り返させると、いつまでも結論が出ないまま、その1件が列に居座り続けます。1回で通らなければそれ以上は自動で粘らない、という線引きです。

3. 直せない理由を残す

直しても再検品を通らない、あるいはそもそも直せない種類の不良だった場合は、公開の操作はしません。そのかわり、何が落ちたのか・どう直せばよさそうかを、台帳に理由として書き残します。

これによって、飛ばして終わりではなく「あとで人が見れば再開できる状態」が残ります。理由が残っていること自体が、次のアクションの入口になります。

4. 見張りが鳴らす

理由を書き残しても、それを毎日確認する仕組みがなければ、結局は放置されて忘れられます。relmea の運用では、毎日動く見張りの処理が、残った理由を翌日以降も鳴らし続けるようにしています。

1回だけ通知して終わりにしないのは、忙しい日に見逃しても翌日また目に入るようにするためです。放置すれば静かに消えるという詰まりの弱点を、ここで潰しています。

どこまで自動で直させ、どこから人に渡すか

4段設計のなかで最も判断が難しいのは、最初の「直す」の範囲です。どこまでを自動で直してよく、どこからは人に渡すべきなのか、という線引きが必要になります。

ひとつの目安は、直せる不良かどうかを機械的に判定できるかどうかです。形式が決まっている項目の欠落など、正解がひとつに定まる不良は自動で直しやすい領域です。逆に、良し悪しの判断に幅がある不良は、自動で直すと「直したつもり」のまま質を落とす危険があります。

  • 決められた形式の項目が抜けている場合（必須の入力欄が空欄のまま出力されている、など）は、規定の形式に沿って埋め直せるため自動で直してよい側です。
  • 文字数の上限・下限が決まっている項目が超過・不足している場合は、規定の範囲に収まるよう調整すれば正解が一意に決まります。
  • 必須の付帯情報（出典表記やリンク先など）が付け忘れられている場合は、決められた形式で付け直せば済みます。
  • 書かれている内容そのものの是非（言ってよいことかどうか）は、正解が一意に決まらないため人の判断に渡します。
  • 事実関係が怪しい記述は、機械的な整形では正しさを保証できないため人が確認する側に回します。
  • 言い回しの適切さやトーンの是非は、読み手の受け取り方に依存するため、自動では断定しません。

人に渡す判断をどこに置くかという設計は、AIエージェントの運用全体に関わる論点です。この線引きの考え方はAIエージェントに任せて人は見守るだけ｜業務設計3パターンで扱っています。無理にすべてを自動化しようとせず、直せない種類の不良は最初から人に渡す前提で設計しておくことが、結果的に自動化を長く安定して回すことにつながります。

詰まりに気づくための観測の置き方

ここまでの設計を機能させる前提になるのが、「詰まりが起きていること自体に気づける」観測の置き方です。止まるエラーと違って、詰まりは自分から教えてくれません。

見るべきは成功件数ではありません。件数だけを見ていると、詰まりが起きていても健全に見えてしまいます。

  • 理由が残ったまま何日経っているか（滞留日数）。書かれた直後はよくても、動かずに残り続けているなら放置のサインです。
  • 同じ理由が繰り返し出ていないか（再発の型）。同じ種類の不良が何度も残るなら、直す側の仕組みに穴がある可能性があります。
  • 列の先頭がずっと同じものになっていないか。先頭が動かないままなら、その1件が後続を塞いでいる状態だと分かります。

relmea の運用でしているのは、理由を書き残す場所（台帳）と、それを毎日確認する見張りの処理をセットで持つことです。台帳だけがあっても誰も見なければ意味がなく、見張りだけがあっても書き残す場所がなければ何を鳴らせばよいか分かりません。

「止まる」対策として外部依存の監視を置くのと同じように、「詰まる」対策にも専用の観測が要ります。この2つは似ているようで別の監視対象であり、両方を意識して初めて、無人運転の自動化は静かに壊れなくなります。

AIエージェントのエラー処理は、動かなくなることへの備えだけでは足りません。動き続けているのに成果物が積み上がらない「詰まり」への備えを、直す・再検品する・理由を残す・見張りが鳴らすの4段で設計しておくことが、無人運転を長く回すための土台になります。