- 公開日
AIの操作を取り消せるようにするには、操作ごとに「何を、どの状態まで戻せるか」を実行前に決めます。保存した文書の内容を旧版へ戻せても、すでに相手へ届いたメールや読まれた情報まで消せるとは限りません。元の状態へ戻す処理と、起きた影響を訂正・軽減する補償処理を分け、戻せない範囲と復旧に必要な承認も提示します。
「戻せる」の対象と範囲を決める
ロールバックは、変更を取り消して以前の状態へ戻すことを指します。ただし、データベース内の変更、文書の内容、外部サービスへの送信では、戻せる範囲が異なります。「失敗したら全部戻す」という一つの指示では、その境界が定まりません。
トランザクションは、複数の更新を一つの処理単位として扱う仕組みです。例えばPostgreSQL 18のTransactionsでは、確定前のトランザクション内でROLLBACKすると、その中で行った更新を取り消せます。これは当該トランザクションのデータベース変更についての説明です。別サービスへ送ったメールまで同時に取り消せることを意味しません。
文書を旧版へ戻す操作も、確定前の更新を破棄する処理とは区別します。一度保存した内容を別の更新で戻すなら、復元操作にも権限が必要です。他の人による追記があれば、旧版の内容で現在の文書を上書きすると、その追記も失うおそれがあります。
一方、補償処理は、すでに行った操作の影響へ対処する追加の操作です。訂正メールで誤った案内を改めることはできても、受信者が最初の案内を読んだ事実や、その情報をもとにした行動は残ります。MicrosoftのCompensating Transaction patternも、補償が必ず開始時の状態へ戻すとは限らず、並行して行われた変更を考慮する必要があると説明しています。
文書の書き戻しも、確定済みの変更へ追加の更新で対処する点では補償処理として設計できます。補償処理と原状復帰は排他的な分類ではなく、前者は対処の手段、後者はどこまで戻ったかという結果の評価です。
「原状復帰」と報告するなら、原状の範囲を限定します。「文書本文が保存済みの版7と一致した」は確認できますが、履歴、通知、閲覧者の手元のコピーも含めて元通りかどうかは別に確かめる必要があります。
実行前に、復元手段と残る影響を提示する
以下は、架空の社内説明会の案内を更新する設計例です。実際の文書編集やメール送信を行った結果ではありません。
元の依頼は「確定した日程表に合わせて案内文書を更新し、確認後に参加窓口へ送る」です。日程表の開始時刻は15時、案内文書D-12の版7は14時とします。担当者が日程表を原資料として確認し、AIが文書を版8へ更新する流れを考えます。文書ID、時刻、版番号は説明用の仮定です。
この架空サービスは、旧版の内容を取得でき、現在の版が指定した版と一致するときだけ更新できると仮定します。メールは1通で、承認済みの参加窓口1件へ本文のみを送ります。送信完了後の回収機能はない設定です。実際に採用するときは、利用サービスにこれらの機能と権限があるかを別に確認します。
| 操作 | この例で用意する復旧手段 | 復旧できない、または別確認になる範囲 |
|---|---|---|
| D-12の版7を版8へ更新 | 版7の内容を保存し、他の更新がないことを条件に復元する | 更新履歴、閲覧済みの内容、配布済みコピー |
| 更新後の文書を根拠にメールを送信 | 誤りがあれば、内容と宛先を確認して訂正連絡を送る | 最初のメール、読まれた情報、受信者がすでに行った対応 |
実行前には、少なくとも復元対象、戻すための資料、実行条件、期限、担当者を揃えます。D-12なら、版7の本文を読めること、復元時に現在版を照合できること、復元を行う担当者の権限が有効であることが条件です。版の保存期間が切れれば同じ方法では戻せないため、その期間もサービスの仕様と運用で確認します。
承認画面の説明は、例えば「本文は版7へ復元できます。ただし、他の編集が入った場合は差分確認が必要です。送信した案内は回収できず、訂正連絡が必要になります」とします。メールを送る承認だけで、将来の訂正連絡の宛先や内容も任意に決められる扱いにはしません。
旧版を残す運用には、保管容量、アクセス管理、差分の確認という負担があります。内容の機密性と復旧の必要期間に合わせて保管先と保持期間を決め、承認画面に表示する説明と実装が一致するようにします。
文書の復元は、現在の版を確認してから行う
版8への更新後、依頼者が「いったん案内の変更を取り消したい」と申し出たとします。メールはまだ送っていません。復元の承認対象をD-12と版7の内容に固定し、現在の文書を読み直します。
現在版が8で、別の編集がないなら、版8を条件に版7の内容を書き戻す設計にできます。このサービスでは書き戻しで新しい版9が作られると仮定します。完了後は版番号が7になったかではなく、版9の本文が保存していた版7の本文と一致するかを確認します。更新の履歴が残ることも、内容の復元と矛盾しません。
一方、別の担当者が会場を追記し、現在版が9になっていたら、自動の全文復元を止めます。版7をそのまま戻すと会場の追記も消えるためです。管理担当者が版7、AIの版8、現在版9の差分を見て、開始時刻だけを戻すか、変更全体を取り消すかを判断します。選んだ内容と現在版を確定して承認し直します。
読み直しの直後に別の編集が入ることもあります。確認時だけ一致していればよいのではなく、更新を受け付ける側で版条件を検査し、不一致なら拒否する構成が必要です。この条件を実装できない環境では、同じ自動復元を安全に行えるとみなさず、編集の調整と人による確認へ戻します。
復元完了の報告は「D-12の本文を版7の内容に戻し、新しい版9として保存されたことを確認しました。メールは未送信です」とします。保存結果や送信状態を照会できていなければ、その部分を未確認として残します。
実行中や結果不明の操作は、先に状態を確かめる
取り消したいという意思と、対象サービスで取消が成立したことは別です。復元も新たな外部操作なので、元の操作と復元操作の両方に識別子を付け、要求、対象、確認した結果を対応させます。識別子だけで重複防止や照会が実現するわけではなく、サービス側の対応が前提です。
| 状態 | 文書更新での対応 | メール送信での対応 |
|---|---|---|
| 実行前 | 旧版を取得し、更新と復元の権限・版条件を確認する | 宛先と本文を確認し、送信後に回収できないことを提示する |
| 実行中 | 追加更新を止め、元の更新が完了したか照会する | 同じメールの新規送信を抑止し、受付・処理状態を照会する |
| 成功を確認 | 更新後の版と本文を確認してから、必要な復元を判断する | 送信済みとして扱い、誤りがあれば訂正内容を準備する |
| 失敗を確認 | 変更が適用されていないと確認できれば、復元せず原因を調べる | 未送信と確認できれば、訂正メールを追加せず元の案を修正する |
| 結果不明 | 旧版を上書きせず、要求状態と現在文書を照合する | 未送信と決め付けず、再送も訂正の自動送信も保留する |
エラー応答があっても、変更や送信が起きたか不明なら「失敗を確認」には入れません。受付の確認だけなら受付として記録し、処理の完了や受信者への到達を補いません。
AWSのMaking retries safe with idempotent APIsでは、応答を受け取れない場合にも副作用が生じている可能性を扱っています。先の更新が遅れて完了する状態で復元を始めれば、その後に更新が再び適用されるおそれがあります。先の要求が完了・取消成立などの状態に確定し、もう動かないことを確かめるか、遅れて来た要求を適用しない仕組みが必要です。
再試行するときは、同じ要求の重複適用を防ぐ冪等性の仕様、同じ内容と識別子を使える条件、保持期限を確かめます。復元要求の応答が失われた場合も、別の復元要求をすぐ作りません。照会できず重複も防げないなら自動処理を止め、操作ID、対象、最後に確認できた状態、不明点を管理担当者へ渡します。
送信済みメールには、訂正と確認の工程を用意する
別の分岐として、15時の案内を送信した後、確定日程が14時へ変更されたとします。文書もメールも「15時から14時へ」という変更ですが、必要な処理は異なります。D-12の本文を14時へ直しただけでは、先に送った15時の案内は変わりません。
担当者は変更の原資料を確認し、先の送信先と送信内容を特定したうえで、「先ほど15時とご案内しましたが、開始時刻は14時に変更されました」という訂正案を作ります。宛先、本文、参照する元メールを承認者へ提示し、新しい送信として許可を得ます。元メールとの対応を残し、送信後はサービスから確認できる範囲で結果を調べます。
訂正を送っても、受信者が読んだか、予定を修正したかまでは自動的に確定しません。参加に影響するなら、担当者が確認を求めるかを判断します。回収機能のある別サービスでも、その適用条件と回収結果を確認し、「要求したから届いた情報も消えた」と報告しないことが必要です。
補償処理自体が失敗する場合もあります。MicrosoftのCompensating Transaction patternは、補償の進捗を記録し、失敗した箇所から再開できることや、人の介入が必要な場合を挙げています。訂正メールの送信が不明なら、元メールを取消済みにせず、「元メールは送信済み、訂正メールは結果確認待ち」と記録します。
復旧の終了条件は、操作ごとに置きます。文書なら「承認した復元内容との一致」、メールなら「承認した訂正の送信結果を確認し、残る未確認事項を担当者へ引き継いだこと」などです。戻せた対象、補償として行った操作、まだ残る影響を分けて報告すれば、担当者は追加の対応が必要かを判断できます。
破壊的操作の対象・承認・ドライラン・復元の確認は「破壊的操作の対象・承認・ドライラン・復元を確認する」で解説しています。
タイムアウトした外部操作を照会し、二重実行を避けて再試行する方法は「タイムアウトした外部操作を照会し、二重実行を避けて再試行する」で解説しています。
