AIに「これ、もう実装済みですよね?」と判定させてみた
うちでは日々たくさんの改善タスクをAIに振っています。数が多いと「どれがもう終わっていて、どれがまだ手つかずか」の棚卸しが大変なので、AI自身に「このタスクは実装済みかどうか」を機械的に判定させる仕組みを作りました。
判定の中身はシンプルです。タスクの完成条件に書かれた識別子(関数名やファイル名)がコードベースに実在するか、対応するテストが緑か、コミットメッセージに関連する文言があるか——この3点が揃っていれば「実装済み・確度高」と判定する、というものでした。
一見、理にかなっているように見えます。実際に「実装済み・確度高」と出た6件を、念のため人の目(というか別のAIによる検収)で1件ずつ確認してみました。
6件中5件が、誤検知だった
結果は、6件のうち本当に実装済みだったのは1件だけでした。残り5件はすべて誤検知です。
誤検知の中身を見ると、共通するパターンがありました。
- ファイルは存在するが、中身は空の雛形のまま(パスが実在する=実装済み、ではない)
- ログには「成功」と出ているが、それは別の軽い処理が成功しただけで、肝心の機能は動いていない
- コミットメッセージにタスク名と似た単語が入っているが、実際の変更は別件のついでに触った1行だけ
つまり判定器は「それらしい状況証拠」だけを見て「実装済み」と判定していました。テストが緑であることも、ファイルが実在することも、コミット文言が一致することも、どれも完了の"周辺証拠"ではあっても、完了そのものの証拠ではなかったのです。
直したのは「答案の中身を見る」判定
修正の方向はひとつでした。完成条件に書かれている識別子を、実際にコード本文の中でgrepして、その識別子が本当に呼び出されている・実装されているかを見る2段階の判定に変えたのです。
- 完成条件で名指しされている具体的な識別子(関数名など)がコード内に実在するかを先に見る。部分一致(似た名前があるだけ)は確度を1段階下げる
- 名前だけでは判定しづらい抽象的な要件(「エラーハンドリングを追加」等)は、対象のコードファイル自体を人が読んで判断する対象として残し、機械だけでは高確度にしない
- ファイルパスやログの存在だけを根拠にしている場合は、確度を「低」止まりにする
この直しを入れて判定し直したところ、「確度高」と出ていた件数は約1割減りました。減った分はすべて、以前なら見逃していたはずの誤検知です。
「テストが緑」は「終わっている」の証拠にならない
今回の一番の教訓は、判定器を作るときに「間接的に完了と相関しそうな指標」を積み上げても、それだけでは完了の証明にはならないということでした。テストが緑であること、ファイルが存在すること、それらは完了していれば大抵伴う"結果"ではありますが、完了していなくても偶然揃ってしまうことがあります。
判定器は、タスクの答案(完成条件そのもの)を実際に照らし合わせて見る必要があります。人がレビューするときにやっていることと同じで、「それっぽい状況証拠」で済ませず、「言われたことが本当にそこにあるか」を1つずつ確認する。AIに判定を任せる場合も、この手間を省略すると誤検知を積み上げるだけになる、という実例でした。
自分たちのタスク管理だけでなく、AIに何らかの「完了判定」「合否判定」を任せる場面全般で同じ罠があると思います。
AIの「できました」「実装済みです」、そのまま信じていませんか
ラポ秘書サービスでは、AIの自己申告をそのまま鵜呑みにせず、実測・実データで裏取りしてから次の判断に進む運用を組み込んでいます。導入・運用の相談はいつでもどうぞ。
📞無料相談はこちら: 03-6876-7749