前回の予告どおり、失敗を数えた話です。
AIエージェントと働いていると、ツールの実行失敗 — コマンドがブロックされた、編集が空振りした、タイムアウトした — が日々発生します。セッションログを解析するツール (cclens) がこの手の失敗を記録から全部拾ってくれるので、直近289セッションのツール実行失敗282件を数えました (分類は字面ベースの機械分類で、そこに人力の意味づけを重ねています)。
なぜ数えるかというと、体感は嘘をつくからです。「AIはよく失敗する」も「たいてい上手くいく」も、数えるまではどちらも出典のない体感です (この連作の1本目に書いた通り、出典のない体感は私の商売敵です)。
まず、全部の内訳
| 分類 |
件数 |
| コマンドが非ゼロ終了 (原因は雑多) |
88 |
| 分類不能 |
80 |
| 実行前のルール/ガードに止められた |
42 |
| タイムアウト |
20 |
| パスの推測ミス |
17 |
| 編集の前提条件不成立 (読まずに編集など) |
15 |
| ユーザーによる中断 |
9 |
| 引数の不正 |
4 |
| コマンドが存在しない |
4 |
| 一過性のインフラ起因 |
2 |
| 外部サービス連携のエラー |
1 |
数えて最初に分かるのは、6割 (88+80=168件) は「型に落ちない雑多な失敗」だということです。一回きりの打ち損じ、環境の不機嫌、二度と再現しないエラー。数える前は「失敗にはパターンがあるはずだ」と思っていましたが、実態はロングテールでした。パターン化できる失敗は少数派で、だからこそ価値があります。
型の最大勢力は、直してはいけない失敗だった
型として意味を持つ最大のカテゴリ (42件) は、実行前のガードに止められた記録です。中身は2種類あって、外部サービスへの投稿・git push・本番データベースへの書き込みを止める権限ガードと、過去の失敗から自分で仕込んだ矯正ルールです。
つまりこの42件は、事故ではなく安全装置が仕事をした音です。これを「失敗率を下げる」目標で潰しにいけば、安全装置の迂回を学習させることになりかねない。失敗カウントをKPIにすると、一番大事な失敗から先に消えていく — グッドハートの法則の教科書的な形が、AI運用の失敗ログにもそのまま当てはまります。ここは件数がいくら積まれても直しません。
直せる手癖は、型ごと仕組みで消す
残りの型は大半がこちら側の手癖で、1行の運用ルールに変換できました。タイムアウト (20件) は重い処理を最初からバックグラウンドに逃がす。パスの推測ミス (17件) は当てずっぽうをやめて先に一覧を取る。編集の空振り (15件) は、失敗したら推測で作り直さず必ず対象を読み直す。
ポイントは「同じ失敗を二度としない」ではなく「同じ型の失敗を、仕組みで消す」です。個々の失敗を反省しても、次の似た場面でまた踏みます。型として抽出してルール1行に固定する。なお、固定したルールで型が実際に減ったかどうかは、まだ再計測していません — ここは次に数えるときの宿題で、現時点では体感です (と、正直に書いておかないと本稿の主旨に反するので)。
それでも新型は来る
この分類を最初にやった数日後、さっそく台帳に無い型を踏みました。退避してから上書きする、という2段のシェル処理で、
backup_command 2>&1 | tail -5 && deploy_command
パイプラインの終了コードは最後のコマンド (tail) のものになるので、退避が死んでいても && は青信号を出します。結果、退避できていない現物を上書きして、検証環境の成果物を失いました。対策は set -o pipefail を先に宣言する、そもそも破壊的操作の前後を1本に連結せず、結果を確認してから次を実行する — 分かってしまえば教科書通りです。教科書は踏んだ後に読めるようになっています。この一件は「破壊的操作の連結」という新しい型として、運用ルールに追記しました。
台帳 — ここでは失敗の型と対策の一覧表のことです — は完成しません。数えることの価値は失敗の撲滅ではなくて、体感を出典に変えることと、直すべき失敗と直してはいけない失敗を区別することにあります。
失敗が全部ログに残るようになった
ところで、これをやっていて妙な感慨がありました。私は自分の30年の仕事の失敗を、こんなふうに数えたことは一度もありません。数えられなかったんです — 手作業の失敗はログに残らないので。
AIとの協働は、その副産物として仕事の操作がログに残る状況を、少なくとも私のエンジニア人生で初めて作りました。失敗が記録されるのは怖いことのようでいて、実は逆で、記録されて初めて改善が複利で効きます。反省は揮発しますが、台帳は揮発しない。
次回は、AIにどこまで任せてどこで止めるかの線引き — 「可逆性で自律度を決める」という運用契約の話を書く予定です。
(この連作は、AIエージェントを業務のレガシーシステム保守で半年ほど運用して溜まった実践則を、1本1則で書いていくものです)