現況:「実装済み候補」13件を機械が並べてきた
うちでは日々のタスク(票)をAIに管理させています。ある夜、新しく着手できるタスクが尽きたタイミングで、タスク管理の仕組みが「これはもう実装済みなので、確認だけしてクローズしてよい」という候補を13件並べてきました。作業を探す手間が省けて助かる、はずの場面です。
対応:実コードと突き合わせたら、正しかったのは0件だった
念のため、13件それぞれについて「完成条件に書かれている内容が、実際のコードやログに本当に存在するか」を1件ずつ確認しました。結果は、13件のうち完成条件をそのまま満たしていたのは0件。1件は部分的な実装のみで機能自体は未完了、残る9件は判定の仕組み自体に問題がある「構造的な誤検知」でした。
誤検知の中身を分けると、大きく3つのパターンがありました。
1つ目は、無関係な変更を「関連する実装」と取り違えるパターンです。タスクの内容とは無関係な、たまたま近いタイミングの別のコミットを、変更履歴の一部一致だけで「このタスクの実装コミットだ」と判定していました。
2つ目は、ファイルの存在を機能の完成と混同するパターンです。関連するツールのファイルパスが存在することは確認していましたが、そのツールが実際にタスクの要件どおりに動くかどうかまでは見ていませんでした。「ファイルがある」ことと「機能が動く」ことは別物です。
3つ目が、もっとも見落としやすいものでした。タスク自体のメモ欄に「確認した結果、未実装でした」と過去に自己申告されているのに、その申告が判定に反映されず候補リストに残り続けていたのです。判定の仕組みが、目の前のコードだけを見て、そのタスクに紐づく過去のやり取りを読んでいなかったために起きていました。
結果:「実装済み」の判定に、証拠のレベルを持たせた
この3パターンをふまえて、判定の仕組みを直しました。コミット履歴の一致だけで済ませず、完成条件に書かれている固有の識別子が実コード側に本当に存在するかを検索して確認する層と、タスクのメモ欄に「未実装」といった自己申告が残っていないかを確認する層を追加しました。あわせて、部分一致だけで判定していた箇所は確度を格下げし、証拠が弱い候補は「確度高」ではなく「要確認」に落とすようにしています。
見つけた問題そのものはその場で修正し、判定精度は改善しましたが、それ以上に効いたのは「額面通りに信じずに1件ずつ確認する」という運用を崩さなかったことでした。もし13件をそのまま機械的にクローズしていたら、未完了のタスクが「完了済み」として記録に残り、後になって発覚する形になっていたはずです。
まとめ:AIの完了報告は、証拠のレベルで扱う
AIにタスク管理や進捗確認を任せる場面は増えていますが、「実装済みです」という報告そのものは、どこまでの根拠に基づいているかを確かめるまで完了の証拠にはなりません。ファイルの存在、コミット履歴の一致、テストが通ったこと——これらはどれも手がかりの一つであって、完成条件そのものを満たしている証拠とは限らないからです。
社内でAIに業務の進捗管理を任せる際は、①関係ない変更を関連実装と取り違えていないか、②ファイルの存在だけで機能の完成を判断していないか、③過去のメモや自己申告が判定に反映されているか、の3点を機械的にでもチェックする仕組みを持つと、こうした見落としをかなり防げます。
AI活用の「確認の仕組み」も一緒に整えませんか ラポルタでは、日々の業務にAI秘書「ラポ秘書」を組み込みながら、AIに任せた作業をどう検証するかという運用そのものも試行錯誤しています。AI活用を進めたいけれど「本当に大丈夫か」が気になる方は、お気軽にご相談ください。 ラポ秘書に無料で相談する