発端:2026年9月8日朝の報告で「完了」だった作業が、昼にはまだ手つかずだった
2026年9月8日の朝、AI秘書の作業役(ワーカー)の1つから「完了」の報告が上がりました。報告には2件の作業名が並んでいて、そのうち1件は、通知の送り先を切り替える小さな改修です。難しい作業ではありません。
数時間後、別のワーカーが作業一覧から次の仕事としてこの改修を選び、状態を確認すると、その作業はまだ「未着手」のままだったのです。送り先を切り替えるコードの変更も、実装した記録も、どこにも残っていませんでした。昼の時点では朝の報告を「クローズ済み」と読んでいたので、報告と実物が食い違って見えました。
対応:「本当に直っていたのか」を実物で1件ずつ突き合わせた
最初に浮かんだ疑いは、記録の巻き戻り(何らかの理由で完了記録が消えた)でした。しかし、記録を管理する仕組みのログを遡って確認すると、この作業の記録が変わったのは、朝の「登録」と、昼にそのワーカーが行った「着手」「完了」の3回だけで、巻き戻った形跡はありません。朝の時点では、そもそも完了処理が行われていなかったのです。そして記録の時刻を見ると、2件とも朝の「完了」報告の直前に登録されたばかりでした。朝の「完了」は登録が済んだという意味だった可能性が高く、昼にそれを「クローズ済み」と読み違えたのは受け取る側でした。
念のため、同じ報告に並んでいたもう1件も同じ手順で照合しました。こちらも朝の時点では実装がありませんでした。その後、昼前に入った実装が別の作業の変更とひとまとめに記録されていて、完了処理だけが抜けていました。照合係は最初この記録を見落とし、「こちらも実装がない」と判定していました。仕組み全体が暴走していた形跡はなく、確認できたズレは朝の1つの報告に並んだ2件でした。
ズレの範囲を確かめるのと並行して、対処も決めました。「完了しました」という報告そのものを信じるのではなく、報告の裏付けとなる実物を機械的に要求する形に変えることにしたのです。
結果:完了報告に3種類の証拠を義務化した
見直し後の運用では、ある作業を「完了」として報告する前に、次の3つがすべて揃っていることを確認するルールにしました。
- 記録を確定させた処理の証跡(完了処理そのものが実行された記録)
- 実際にコードやファイルへ加えた変更の記録(何をどう直したかの実体)
- 作業記録が、保存先のすべてで同じ状態になっているかの機械チェックの結果
この3つのうち、どれか1つでも欠けている場合は「完了」と書かず、実物を確かめ直す、というのが9月8日に決めたルールです。作業役には以前から証拠つきの報告を求めていましたが、受け取る側が報告の文面をそのまま記録できてしまっていたことが、今回のズレを生んだ構造でした。
このルールを決めたのと同じ昼の検収では、完了と報告された別の4件についても3点を確かめ、4件とも証拠が揃っていることを確認しました。一方で、先ほどのもう1件のように、確かめる側が読み違えることもあります。そのため最後は、対象ファイルの変更履歴そのものを見て判定することにしました。
まとめ:「言った」ではなく「残っている」で完了を判断する
今回の一件から得た教訓は次の3つです。
- 完了報告は、報告そのものではなく、報告を裏付ける実物(処理記録・変更内容・機械チェック)を確認してから信じる
- 異常を見つけたら疑わしい対象1件だけで済ませず、同種の周辺作業も同じ手順で洗い直す
- 証拠を求める仕組み自体が誤ることもあるため、一次証拠(実際のログやコード)への突き合わせを最後まで省略しない
AI秘書が処理する作業の量が増えるほど、「言った」ことと「実際に起きた」ことの間にズレが生まれる余地も増えます。うちでは2026年9月8日以降、完了報告を自己申告ではなく、機械的に確認できる証拠の有無で判断しています。9月中旬には、完了の処理を作業した本人ではなく別の確認役が行う形に改めました。2026年10月26日時点でも、この形で運用しながら確認の型の見直しを続けています。
「完了しました」の裏付け、実際に取れていますか
ラポルタ社内のAI秘書運用では、9月8日以降、AIが行った作業の完了報告を鵜呑みにせず、処理記録・変更内容・機械チェックを照合してから完了扱いにしています(2026年10月26日時点)。こうした運用の工夫も含めて、ラポ秘書の導入をご相談ください。
LINEでのご相談: https://line.me/R/ti/p/@488bnqbu(LINE ID @488bnqbu)
内装工事の対応範囲はサービスページ、ご相談の流れはお問い合わせフォームもご覧ください。
※内容は社内運用記録に基づいています。顧客名・案件名・現場情報は掲載していません。