SQLiteへ送信前予約を残す——タイムアウト後も同じ操作を二度送らない設計

清掃ボタンをもう一度押す前に

クラウドの保存領域が保持期限を超え、管理担当が清掃を依頼したとします。画面は待った後に時間切れを表示し、削除件数は戻りません。忙しい担当者には、もう一度ボタンを押せば片付くように見えます。しかし、相手が処理を受け取る前に通信が切れた場合と、削除した後の返事だけ届かなかった場合では、二回目の操作の意味が変わります。画面に結果がないことから、相手が何もしていないとは判断できません。

このような清掃を扱う保守基盤には、許された操作について、外部へ送る前に予約を保存し、結果が不明な操作を自動で繰り返さない設計があります。ここでいう予約は、成功したという記録ではありません。少なくともこの仕事から操作を試みる段階に入ったという記録です。不確かな返事を失敗へ単純に置き換えないことが、再実行の判断を変えます。

同じ清掃依頼が、相手へ届く前、相手で始まった後、返事を返した途中で止まる三条件を追います。何を保存すれば二重操作を防げるかだけでなく、慎重に止めた結果、本来必要な清掃も止まる場合を考えます。自動で繰り返さないことは安全策ですが、それだけで仕事が完了するわけではありません。保留した仕事を誰が何で判断するかまで必要です。

同じ仕事かどうかを、日付で決めない

まず清掃依頼の単位を決めます。例では一回の保持状況の確認に対して、決められた清掃操作を一度だけ依頼します。その依頼が夜に時間切れとなり、翌朝も返事がないとします。日付が変わったことを新しい仕事の根拠にすると、前夜の清掃が既に進んでいても、別の予約としてもう一度送れてしまいます。したがって同じ依頼と同じ操作の組を、日をまたいで区別できるように残します。

実装ではこの組に対する既存の予約があれば、再予約を認めません。当日の操作件数を数える制限もありますが、それとは役割が違います。件数制限は一日に何回まで操作を許すか、依頼ごとの予約は同じ操作を繰り返さないかを扱います。翌日の件数枠が空いていることは、前夜の結果不明の操作を再送してよい根拠にはなりません。この違いを守らないと、日付変更が二重実行を解禁する入口になります。

一方、毎日行う定期清掃まで永久に止めるわけではありません。新しい保持状況を確かめ、別の業務依頼として清掃が必要かを判断することと、昨日の同じ試行を再送することを区別します。ただし、既存の保留が対象領域へ影響している可能性は確認する必要があります。依頼を新しく作ればよいという機械的な解決ではなく、相手側で何が起きたかを把握したうえで次の仕事へ進む判断になります。

予約を先に残すと、未送信も保留になる

順序は、清掃の必要性を読む、許された操作の予約を確定する、既存の清掃処理へ依頼する、結果を記録する、となります。保持期限を超えていなければ、予約も外部操作も不要です。必要があり予約を確定できた場合だけ、決められた操作へ進みます。任意の削除処理をAIが自由に選ぶ構成ではなく、許された経路に対象を絞ることも、この設計の前提です。

予約を外部操作の後に残す方法は、成功結果だけが並んで分かりやすい反面、送信の直後に実行中のコンピューターが止まると、記録が残りません。翌朝には未実行に見えてしまいます。先に残す方法なら、その隙間を縮められます。ただし予約直後、送信前に落ちた場合も、後からは送ったか不明になることがあります。記録が成功を証明していない以上、予約の存在だけを清掃完了とは呼べません。

これは保守的な選択です。二重の操作を避ける代わりに、本当はまだ届いていない操作も保留にする可能性があります。対象の清掃が何度実行しても完全に同じ結果になるなら、再送を許す別の設計も考えられます。ただし、この経路では全ての失敗時の再送安全性まで保証されていません。操作の安全性を推定で決めず、不明な段階で止めて照会へ回すことを、この設計は優先しています。

予約台帳はSQLiteに保存され、ジョブIDと操作の組を主キーにします。他の操作が割り込まないよう、書き込み用の一括処理（トランザクション。SQLiteのBEGIN IMMEDIATE）を先に開始し、既存予約の確認と日次上限の判定、結果不明の予約の追加を同じトランザクションで行います。コミット後に外部操作へ進む順序が、同じ依頼を繰り返し送らない冪等性の境界です。相手側まで含む完全な一回実行の保証とは区別します。

届く前、届いた後、返事だけ失った後

一つ目は、予約した後、依頼が相手へ届く前に通信が止まる条件です。相手の受付記録に何もなく、対象の保持状況も変わっていないと確認できれば、未実行という判断材料になります。それでも送信側の時間切れだけでは未実行を確定できません。確認には相手側の記録が必要です。保存領域が変わっていないだけでは、受付済みで処理開始を待っている可能性が残ります。

二つ目は、相手が依頼を受け付けて清掃中に、送信側が時間切れになった条件です。このとき対象の数が途中で変わっていても、全て終わったとは限りません。再送より、相手が受け付けた処理の進行を照会する方が適します。例なら削除対象を選んだ記録、処理中かどうか、完了件数を確認します。この照会を運用へ加えるには、相手側の記録を取得する経路が必要です。保守基盤の予約処理だけでは、相手側の全記録を自動で取得できません。

三つ目は、相手では完了し、完了の返事だけ失った条件です。相手側の完了記録と、対象の清掃後の状態が依頼内容に対応すれば、再送せず結果を整理できます。ここで同じ操作を押し直すと、昨日の成果を得るために別の操作を加えることになります。三条件とも送信側には同じ時間切れが出得るため、画面のエラー名だけでは区別できません。違いを決めるのは相手側での受付、進行、完了に関する観測です。

例えば相手に受付番号が残り、清掃中と表示されるなら、数が変わっていない段階でも待機が選択肢になります。受付番号がなく、担当者の別操作で領域だけ減っているなら、今回の送信結果は依然不明です。対象が改善したことと、送信した依頼が完了したことを分けると、新しい保守依頼を作る前に照会すべき情報が分かります。

照会できない場合は、保留を仕事として扱う

外部サービスが詳しい受付記録を返さない場合、三条件を区別できないことがあります。清掃後の状態だけを見ても、今回の操作が変えたのか、別の担当が清掃したのかは分からないかもしれません。この場合に「おそらく未実行」として再送するのは、観測の不足を確定した判断へ置き換えています。実装は結果不明の予約を残して同じ操作を繰り返さず、実状態の確認が必要な結果として返す設計です。

保留のまま放置すれば容量の逼迫は解消しません。そのため、担当者が対象の保持状況、相手の稼働、他の清掃依頼の有無を調べ、確認できる範囲を整理します。追加調査が必要ならその担当と期限を決めます。復旧に急ぐ場合も、同じ依頼を無条件に再送する選択と、別の許された方法で容量を確保する選択の危険を比較し、権限を持つ人が判断する必要があります。

現実には、照会の手間が大きいため自動化の利点が薄れる操作もあります。その場合は予約方式を捨てるより、受取側に同じ依頼を重複して処理しない機能があるかを調べる方が建設的です。相手が受付番号や同一依頼への応答を返せるなら、より確かな再開方法を設計できます。ただし、予約の保存だけで受取側との照合は完結しません。導入候補のサービスごとに調査する項目として、区別しておくべきです。

通知にも、返事を失う場面がある

清掃とは別に、復帰したことを担当者へ通知する場面でも同じ問題が起こります。通知サービスへ送った後に時間切れになると、実際には届いているのに送信側は結果を知りません。画面に赤い印が出たからといって繰り返せば、受信者へ同じ復帰通知が何通も届きます。通知は削除操作ほど取り消し困難ではなくても、繰り返しは担当者の判断を乱し、どれが新しい出来事か分かりにくくします。

実装では、通知を送る前にも結果不明の印を保存し、その印がある通知は再送しません。復帰の事実と通知の配送を別に扱うため、通知の返事がなくても、確認済みの工程復帰まで取り消す必要はありません。例なら清掃が終わったと観測できたことと、管理担当へ連絡が届いたことの二つを分けて残します。相手から返事がないから清掃も失敗した、という連鎖を避ける構成です。

通知先への到達確認が必要なら、別の方法で担当者へ確認する運用を設けます。自動再送をしないという方針は、連絡を諦めることではありません。どの通知が結果不明かを担当者が追えること、受信済みか調べること、必要なら許可された別の連絡手段を選ぶことが後続の仕事になります。こうした例外時の連絡を、通常の成功通知と同じボタンで処理しようとすると、記録と実際の配送の対応が曖昧になります。

試験では、結果より呼び出した回数を見る

試験では、清掃処理が時間切れを返した後、同じ操作をもう一度頼んでも既存の予約として扱われ、外部操作の呼び出しが一回に保たれる条件を調べています。通知でも時間切れ後の印が残り、再送しない条件が定義されています。これらは模擬の応答を使う試験です。ここで述べる内容は、説明用に定めた設計と限られた条件での確認に基づきます。導入先の環境で同じ結果が得られるとは限りません。

結果不明を扱う設計の試験では、最終画面の文字だけでは不十分です。画面が保留になっていても、裏では二回送っていれば目的を満たしません。予約が保存される前後で処理を止め、外部へ何回渡ったかを数える必要があります。また、日付だけを進めて同じ依頼を再度入力し、翌日の操作枠が空いていても前の予約を越えて送られないかを確認します。失敗の条件を変えて、止める理由が保たれるかを見る試験です。

正常な条件も対にします。清掃が不要なら操作ゼロ回、必要で初回の予約が確定したら一回、既存の予約なら追加ゼロ回、という期待結果を先に置きます。全てを止めるだけの構成でも二重送信は防げるため、必要な初回操作を進められることが同じくらい重要です。試作では外部へ実際に削除を送らず、呼び出し回数と保存状態を観測できる環境で、この違いを確認するのが適切です。

導入前に、再送して困る操作を一つ選ぶ

最初に整理するのは、時間切れが起きやすい機能の一覧より、同じ操作を二度行うと困る理由です。清掃なら対象範囲の変化、通知なら重複連絡、別の業務なら発注や送信の二重化が問題になり得ます。操作の影響が違えば、結果不明のときに誰へ戻すかも変わります。この予約方式を別の外部操作へ使う場合も、許す経路と再送による影響を先に確認してください。

次に、送る前に残す記録、相手側で調べられる情報、判断できない場合の担当を一つの手順にします。「再実行禁止」だけを書いても、現場は期限に追われて別の入口から操作しがちです。対象の状態をどこで見られるか、受付の問い合わせ先はどこか、保留を解除する判断は誰が行うかが分かれば、再送以外の次の行動を選べます。外部サービスが返す情報の不足も、試作時に発見できます。

予約と保留の構造だけでは、本番の二重操作の発生率や保守時間への効果は判断できません。これらを評価するには、許した経路での操作履歴と、照会や保留の解消に掛かった時間を集める必要があります。あなたの運用ではまず一つの許された操作に限定し、返事だけ失った場合でも同じ依頼を重ねないかを試してください。そのうえで、保留になった仕事を実状態の確認から完了へ戻せることを、導入の条件に加えると判断が具体的になります。