「送信しました」の直後にDBを見たら0だった
社長とのやり取りの中で、ある顧客へのLINEの文面が決まった直後に、「返してないラインも返しておいてくれていいよ」と一言ありました。その1件とほかの未返信分、合わせて4名の顧客への返信を、AI秘書が担当のAIに任せました。10分あまりで「4名とも送信しました」という報告が返ってきたので、AI秘書は念のため社内のデータベースを開いて送信記録を確認しました。
ところが、実際に開いてみると様子がおかしいのです。「実際に送信した」ことを示すフラグは、4件とも0のまま。しかも複数の件は、日時の列が今日ではなく、下書きを作った日の古い日付のままでした。これでは「今送った」のか「昔の下書きがそのまま残っているだけ」なのか判断がつきません。「送った」という報告と、記録として残っているはずのデータが正面から食い違っていました。
API送信ログまで潜って確認する
ここで、報告をそのまま信じることはしませんでした。過去にも、AIの報告が処理の一部だけを見て「完了」と言ってしまう例があったからです(同じ日の別件でも、作業記録を保存しただけのコミットを「実装完了」と読み違えた事例が出ていました)。一方で「フラグが0だから未送信」と決めつけるのも早いと考え、もう一段掘って、LINEの送信APIを呼び出したときの記録(送信ログ)を確認しました。
ログには、4件それぞれについて実行時刻とAPIの応答コードが残っていました。4件とも応答は200(成功)。時刻もばらけておらず、その日の数分のあいだに立て続けに実行された記録でした。つまり、LINEへの送信は確かに実行され、LINE側に受け付けられていたということです(応答200は「受け付けた」という意味で、相手に届いたことまでは保証しません。実際にその日のうちに返信が届いた顧客もいました)。「送った」という報告は事実で、間違っていたのはDBのフラグ更新の方でした。
原因はシンプルでした。ボット本体から送る経路は、送信と同時に「実際に送信した」フラグもDBに立てる作りでした。ところが今回使った手動送信のスクリプト(LINEのAPIを直接呼び出すもの)は、送信に成功しても「処理済み」の印を付けるだけで、「実際に送信した」フラグと送信時刻を記録していなかったのです。送る経路が2つあり、このフラグを立てる処理が片方の経路にしか入っていなかったのです。
社長の一言から、送信ログで4件とも送信に成功していたと確かめるまで、およそ20分でした(食い違いに気づいてからの確認自体は数分です)。この間は「顧客に二重送信してしまうのでは」「実は届いていないのでは」という両方の可能性を潰す必要があり、確認が終わるまでは社長に「送りました」と報告しない判断をしています。
もう一つ、静かに止まっていた仕組み
同じ日には別の問題も見つかりました。顧客からのLINEの問い合わせをもとに返信の下書きを自動で作る仕組みが、5日と14時間にわたって起動のたびにエラーで即座に終了し、下書きが1件も作られていなかったのです。原因は、あるデータベースの構造変更(マイグレーション)を反映する処理が呼び出されないまま残っていたことでした。エラー自体はログに記録されていましたが、誰も見ていなければ気づかれず、仕組みは「動いているつもり」で5日間止まり続けていました。
この2つに共通するのは、どちらも「一見動いているように見える」状態で実は片方の役目を果たしていなかった点です。今回の教訓は3つにまとめています。
AIの検収は3つの軸で見る ①「送った」「完了した」という報告は、API応答やログなど動作の証拠と突き合わせて裏取りする。②DBのフラグのような「状態を表す記録」と、実際に起きた出来事は別物として扱い、片方だけを信じない。③自動化の仕組みは、起動直後に簡単な動作確認(スモークテスト)を組み込んでおかないと、エラーを吐きながら何日も静かに止まり続けることがある。
「動いていること」と「役目を果たしていること」は別です。2026年9月17日時点で、うちのAI秘書は、自分自身が出した報告についても、送信ログなどの記録と突き合わせて確かめるようにしています。気になる方はお気軽にご相談ください。