こんにちは。買い物リストを書いたメモを家に置いてきて、店で記憶力テストが始まります。ADHD社長です。
Qiita版は実装の判定条件に寄せます。
今回は、自作AIアシスタントの運用で一番怖かった「静かな失敗」の話をします。エラーで止まる失敗はまだいいんです。音もなく成功した顔をして、実は何も起きていない失敗が一番怖い。自動化の信頼を落とすのはだいたいこっちでした。
成功の顔をした失敗は、どう起きるか
定型処理を夜間に回していると、朝の報告に「完了」と書いてあるのに、実物がどこにもない、ということが起きます。
原因を掘ると、だいたい同じ構造でした。処理自体は最後まで走ったように見える。でも、途中の保存先が想定と違う、終了ステータスを誰も見ていない、結果の置き場所が固定されていない。プログラムの世界で言う「終了コードは0だが成果物がない」状態です。人間が手でやれば気づく違和感を、自動化は素通りします。
ここで大事なのは、賢さの問題として扱わないことです。モデルを替えても直りません。失敗を検知する仕組みが先にないのが原因でした。
先に作るべきは、処理ではなく検知だった
順番を逆にしました。本処理より先に、結果の記録と終了状態の判定を作る。
具体的には、処理ごとに開始と終了と成否を1か所に記録する、成果物が置かれる場所を固定する、想定した成果物が無ければ成功として報告しない、という3点を先に固定しました。いわゆる fail-closed の考え方で、確認できないものは「未確認」と言う。完了と言い切るのは、実物で裏が取れた分だけです。
実装で効いたのは、状態を文字列ではなく構造で持つことでした。成功、失敗、未確認を列挙型で分け、報告側は成功以外を成功の言葉で包まない。この当たり前が、運用の事故を一番減らしました。
記録の粒度は「次に掘れるか」で決める
ログを全部残せばいい、でもありません。残しすぎると誰も読まない。
僕の基準は「翌朝、その記録だけで原因の当たりが付けられるか」です。いつ、何を、どの入力で、どう終わったか。この4点があれば大抵の静かな失敗は掘れます。逆に、画面のスクリーンショットだけ山ほどあっても、状態が分からなければ役に立ちません。
試した手と結果を記録して、通った手を手順化する。この蓄積が、次の自動化の土台になります。記録は面倒な付属品じゃなくて、自動化本体の一部なんだと思います。
人間の確認をどこに残すか
全部を自動で閉じないことも、検知の一部です。
金額や日程のように、間違えた時の影響が大きい判断は、最後の確認を人間に残す。逆に、記録と集計のような可逆な処理は自動で閉じる。この線引きを先に決めておくと、静かな失敗が起きても被害の範囲が限定されます。
自動化の目的は「人間をゼロにすること」じゃないんですよね。人間が見るべき場所を、少なく、鋭くすることだと思っています。
まとめと次の一手
静かな失敗への対策は地味です。記録する、状態で判定する、実物で確認する、影響の大きい確認だけ人間に残す。派手な技術は出てきません。
でも、この地味な土台があるかどうかで、夜間に任せられる仕事の範囲が全然変わります。次は、複数タスクを並行させた時の状態の束ね方を書く予定です。
ちなみに今日は、開発に集中していたら昼を食べ損ねました。検知の仕組みは、ご飯には効きません。
検知はテストより先に、運用の言葉で書く
補足として、検知の条件はコードより先に日本語で書くようにしています。「成果物が所定の場所にあり、件数が想定範囲で、終了状態が成功であること」。この3行を先に固定してから実装すると、判定のブレが減ります。仕様を言葉で書けない処理は、だいたい運用でも曖昧になります。言葉で書く、構造で持つ、実物で確かめる。この順番が今の標準形です。