AI連携が途中で止まった。再実行でメールや請求が二重にならない設計

AI連携が途中で止まった場合、まずは処理IDと実行済み記録を確認し、外部システムとの照合結果を人が承認することで、メールや請求書が二重に送られるリスクを回避できます。最初のステップは、システムが残したログとデータベースの状態を見える化し、担当者が「再実行しても安全か」を判断できる情報を揃えることです。

AI連携が止まったときの原因把握

処理IDが記録されているか確認

処理IDは、各ワークフローの開始時に生成され、データベースやログに必ず残すべき識別子です。まずは、対象のジョブが正常にIDを付与できたかを確認します。IDが欠落していると、再実行時に同一処理と判別できず二重送信の原因になります。

担当者は、データベースの"process_id"テーブルやジョブ管理画面で、対象ジョブのID有無をチェックし、欠けている場合は手動で付与できるか検討します。

次に、IDが正しく保存されているかをシステムログと照合します。ログに"ID:xxxx"と記録されていれば、以降のステップで使用できる根拠ができます。担当者は、"IDの有無を確認した結果、欠落があれば…"といった形で、開発担当に質問し、対策を共有します。

外部システムの実行ログを照合

AI連携は内部処理だけでなく、メール配信サービスや請求システムといった外部APIを呼び出すことが多いです。再実行前に、外部側で実際に処理が完了したかをログで確認します。たとえば、メール配信サービスの送信履歴や請求システムの発行履歴を検索し、対象の処理IDやタイムスタンプが記録されているかを照合します。

照合結果が「未送信」なら再送信が必要ですが、「送信済み」なら再実行時に二重送信しないようフラグを立てるだけで済みます。担当者は、外部サービスの管理画面やAPIログを確認し、結果を社内の実行記録と突き合わせて、再開の可否を判断材料にします。

途中停止のパターンを分類

AI連携が止まる原因は大きく三つに分けられます。①システムエラー（例：タイムアウト、例外）②外部サービスの障害（例：APIエラー）③データ不整合（例：必須項目欠落）。それぞれのパターンごとに原因と対策を整理しておくと、次回同様の障害が起きたときに迅速に対応できます。

担当者は、過去の障害事例を一覧にし、エラーメッセージや発生時刻、影響範囲を記録します。分類ができれば、再実行時に「このパターンは既に確認済み」かどうかをチェックリストに組み込め、無駄な手戻りを防げます。

二重送信を防ぐ設計の基本

冪等性（べきとうせい）を組み込む

冪等性とは、同じリクエストを何度実行しても結果が変わらない設計思想です。メール送信や請求書発行のAPIに対しては、リクエストに一意のトークン（例：リトライID）を付与し、受信側で同トークンの重複を検知したら処理をスキップさせます。これにより、再実行しても二重送信が起きません。

実装例としては、メール配信サービスの「idempotency-key」ヘッダーや、請求システムの「transaction_id」パラメータを利用します。担当者は、利用中の外部サービスがこの機能を提供しているかをドキュメントで確認し、社内のAPIラッパーに組み込むよう依頼します。

実行済みフラグの管理方法

内部でも「処理が完了した」ことを示すフラグをデータベースに残すことで、再実行時に二重送信を防げます。フラグは「メール送信完了」「請求書発行済」など、業務単位で分けて管理します。フラグ更新はトランザクション内で行い、外部API呼び出しが成功した後に確定させます。

担当者は、フラグの状態を確認できる簡易画面やレポートを用意し、再実行前に「完了フラグが立っていないか」を確認する手順をマニュアル化します。これにより、担当者の見落としのリスクを低減できます。

メール・請求の送信制御フロー

安全な送信制御は、①リクエスト受付、②ID付与、③外部API呼び出し、④結果判定、⑤フラグ更新、⑥完了通知の順で構成します。途中でエラーが起きた場合は、ステップ3までの情報を保持し、ステップ4以降は再実行しないようにします。

具体的には、メール送信が失敗したら「送信失敗」ステータスを残し、再実行時はステータスが「未送信」のものだけを対象にします。請求書も同様に「発行済」か「未発行」かで分岐させ、二重発行を防止します。担当者は、このフロー図を社内共有し、開発チームに実装依頼を行います。

再実行手順と人の承認ポイント

再開前に担当者が確認すべき項目

再実行を行う前に、担当者は次のチェックリストを確認します。（1）処理IDが正しく記録されているか、（2）外部サービスの実行ログで「未送信」または「未発行」か、（3）冪等キーが未使用か、（4）フラグが未完了か、（5）エラーメッセージの内容と原因分析が完了しているか。

このチェックは、社内のスプレッドシートやタスク管理ツールにテンプレートとして用意し、チェック項目ごとに担当者がコメントを残す形で実施します。全項目がクリアされたら、次の承認ステップへ進みます。

承認プロセスの設計例

承認は、部門長または業務オーナーが行うシンプルなフローが望ましいです。具体例としては、①担当者がチェックリストを完了し、②承認依頼をメールまたは社内チャットで送信、③承認者が「承認」または「却下」の返信を行う、④承認が得られたら自動化ツールが再実行ジョブをキックする、という流れです。

承認者は、チェックリストの内容と外部ログのスクリーンショットを確認し、二重送信リスクが残っていないことを確認します。承認が得られない場合は、担当者が原因を再調査し、再度依頼します。このプロセスを文書化しておくと、監査対応にも役立ちます。

承認後の安全な再実行手順

承認が下りたら、再実行ジョブは以下の手順で実行します。（1）処理IDと冪等キーを再取得、（2）外部API呼び出し前に「未送信」フラグを再確認、（3）API呼び出し実行、（4）成功応答が返ったらフラグを「完了」に更新、（5）完了通知を担当者へ自動送信。

再実行は、ジョブスケジューラやRPAツールで自動化するとヒューマンエラーのリスクを低減できますが、可能であれば「承認済み」フラグが立っていることをトリガー条件に組み込みます。担当者は、実行後にログとフラグが期待通りに更新されたかを最終確認し、問題がないことを確認した上で作業完了とします。

運用でのチェックリストと改善

定期的なログレビューの実施

AI連携の安定稼働を保つため、週次または月次でログレビューを実施します。レビュー項目は、①処理IDの未使用件数、②冪等キーの重複件数、③外部APIエラーレート、④二重送信フラグの発生有無です。担当者は、レビュー結果をレポートにまとめ、上長へ報告します。

問題が見つかった場合は、原因を特定し、再発防止策としてフラグ更新ロジックや冪等キー生成方法を改善します。定期レビューは、リスクを早期に発見し、二重送信事故を未然に防ぐ重要な運用活動です。

二重送信リスクの評価指標

リスク評価は、以下の指標で行います。（1）二重送信発生件数／全送信件数、（2）再実行時のエラーレート、（3）承認プロセスの遅延時間。これらを数値化し、閾値を設定しておくと、指標が超過した際にアラートを出す仕組みが作れます。

担当者は、指標をダッシュボードに可視化し、経営層と共有します。閾値超過時は、即時改善タスクを発行し、原因究明と対策実装を優先します。数値でリスクを把握することで、投資判断やプロセス改善の根拠が得られます。

失敗時の報告と次回対策

障害が発生したら、まずは「インシデント報告書」を作成し、発生時刻、影響範囲、原因、対応策、再発防止策を記載します。報告書は社内Wikiやプロジェクト管理ツールに保存し、関係者全員が閲覧できるようにします。

次回同様の障害が起きないよう、報告書の「次回対策」欄に具体的な改善アクション（例：冪等キーの生成ロジック修正、承認フローの自動化）を記入し、担当者に期限を設定して実行させます。継続的に改善を行うことで、二重送信リスクを低減し、業務の信頼性を高められます。