「finalize 11件」を完了報告だと思い込んだ
2026年9月17日時点で、うちでは複数の作業をAIに割り振り、作業の進み具合を票に書き込み、保存のたびに履歴が残る仕組みを使っています。ある朝、その記録を見返すと、夜間に「finalize」という処理が11件走ったログが残っていました。文字どおり読めば「11件の作業を締めくくった」ように見えます。そこで「実装が11件終わったんだな」と判断し、内容を確認する検収作業をその前提で始めました。
ところが検収を進めるうちに違和感が出てきました。finalizeというのは実際には「作業記録をきちんと保存した」という処理であって、「中身の作業が完了した」という意味ではなかったのです。保存の処理と、作業そのものの完了は別物でした。この勘違いのまま検収を通さず、朝の報告に「11件終わった」と載せていたら、終わっていない作業を「終わった」と数えて次の予定を組んでしまうところでした。
中身を開いたら、実装の記録があったのは1件だけ
検収では、実際に対象へ回った9件の中身を1つずつ開いて確かめました。「作業内容が書かれた記録が残っているか」「実際に成果物が更新されているか」を見ていくと、「どの変更で実装したか」を書いた実装の記録が付いていたのは、そもそも1件だけでした(その1件も、外部サービスの不通で合格条件の一部が未達でした)。残りの8件は、この検収の材料だけでは「作業が完了した」と確認できる状態ではなかったのです。
検収の結果、実際に完了として片づけられたのも1件のみでした。しかもそれは「作業が完了したことを確認できた」からではなく、「そもそも起票の仕方を間違えていた案件を取り消した」という別の理由によるものでした。つまり「11件終わった」という最初の報告を額面どおり受け取っていたら、実際には完了の裏付けがない作業を完了扱いにしてしまうところだったということです。
さらに掘り下げると、夜間の担当AIに任せる予定だった票が1件も仕上がっていなかった理由は、担当の実力不足ではなく、次の3つに整理できました(その朝の検収で分かった範囲です。検収した9件のうち、ここまでに挙げていない残りの票は、こちらの判断待ち・まだ作業中・起票したばかりで未着手のものでした)。
- そもそも作業が割り振られていなかった: 振り分けの手前で条件に合わず、担当まで届いていなかった
- 実行ログ上は「合格」でも中身がゼロだった: 処理自体は動いたが、実質的な差分(変更内容)が存在しない空振りの実行だった
- 実行環境の制約で実際には動かせなかった: 作業の指示が、担当のAIが触れてよい作業場所の外にあるファイルを直すよう書かれていたため、着手する前に毎回はじかれていた(7回試して7回とも同じ所で止まった)
「合格」という文字だけを見て安心するのではなく、その合格が「本当に中身のある合格」なのか「形だけ通った合格」なのかを、実際のログと差分を開いて見分ける必要がある、という発見でした。
報告の文言でなく、成果物そのものを見る
この一件から実務の運用ルールを1つ変えました。「完了しました」「〇件終わりました」という報告を受け取ったときに、その言葉をそのまま数字として積み上げるのではなく、必ず成果物の中身(実際の変更点・実際のファイル)を開いて確認してから完了扱いにする、というルールです。地味な手間に見えますが、これを徹底するだけで「完了したはずが実は何も進んでいなかった」という手戻りを未然に防ぎやすくなります。
AIに作業を任せる場面が増えるほど、報告の文章はどんどん自然で、もっともらしくなっていきます。だからこそ「言葉」ではなく「成果物」を検収の基準に置くことが、任せる範囲を広げるための土台になると感じています。2026年9月17日時点で、うちのAI秘書自身の報告も、この基準で検収してから完了扱いにする決まりにしています。
AIの「完了しました」を鵜呑みにしない仕組み、一緒に作りませんか
ラポ秘書サービスでは、AIが出す進捗報告を成果物ベースで裏取りし、本当に終わっているものと終わっていないものを機械的に仕分ける運用を組んでいます。任せる作業が増えて「本当に終わってるか分からない」と感じ始めたら、一度ご相談ください。