AIエージェントのロールバック計画：ユーザーの信頼を失う前に誤ったアクションを取り消す
信頼できるAIエージェントは、完璧である必要はありません。停止する方法、間違いを説明する方法、そして復旧する方法を知っている必要があります。
エージェントが誤ったCRMフィールドを更新したり、重複した支払いを送信したりした場合、単なる再試行では被害を修復できません。実際のインシデントに直面する前に、ロールバック計画を用意しておく必要があります。
エージェントがチャットから実務へと移行するにつれ、それらは状態（state）を変化させるようになります。これにより、ロールバックは単なるバックエンドのタスクではなく、製品としての機能となります。
よくある失敗パターン：
- エージェントが誤ったレコードIDを使用する。
- 再試行によってアクションが2回繰り返される。
- モデルの切り替えによりツールの動作が変わる。
- ワークフローが古いメモリで再開される。
- 一連の処理が途中で止まり、データに不整合が生じる。
復旧レイヤーの構築方法：
アクション・レジャー（Action Ledger）を使用する ログだけに頼らないでください。すべての状態変化を記録するレジャー（台帳）を作成します。すべてのツール呼び出しは、実行の前後でエントリを作成する必要があります。これが復旧のための「信頼できる唯一の情報源（source of truth）」となります。
アクションを分類する すべてのアクションが同じではありません。
- 読み取り専用：ロールバックは不要。
- 内部更新：スナップショットから前の値を復元する。
- 外部の取り消し可能アクション：イベントを削除するか、ステータスを更新する。
- 外部の取り消し不能アクション：真の「元に戻す（undo）」の代わりに「補償（compensation）」を使用します。メールや支払いは「送信を取り消す」ことができません。訂正を送るか、返金を行う必要があります。
冪等性（Idempotency）を強制する モデルは冪等性を強制しません。ツールのランタイムが強制する必要があります。冪等性キー（idempotency keys）を使用して、エージェントがタスクを再試行しても、重複した副作用が発生しないようにします。
Sagaパターンを使用する 長いワークフローでは、すべての順方向のアクションに対して補償アクションが必要です。
- タスクを作成する場合？ 補償は、それを削除またはキャンセルすることです。
- フィールドを更新する場合？ 補償は、古い値を復元することです。
- メールを送信する場合？ 補償は、訂正を送ることです。
チェックポイントを実装する クラッシュした後にモデルに「どこまで進んでいたか考えて」と頼むのはやめましょう。チェックポイントを使用して、現在の状態、完了したアクション、保留中のタスクを保存します。システムはチェックポイントをロードして作業を再開できるようにすべきです。
復旧キューを構築する 検証ステップが失敗したときは、タスクを復旧キューに移動します。これにより、タスクの再開、補償、または終了が可能になります。リスクの高いエラーについては、必ず人間の承認を求めてください。
信頼は、目に見える形での復旧を通じて築かれます。エージェントが間違いを犯したときは、曖昧な言葉を使わないでください。何が変わり、なぜそれが起こり、どのように修正したのかをユーザーに正確に伝えます。
最初のインシデントが発生する前に、ロールバック計画を構築してください。
Optional learning community: https://t.me/GyaanSetuAi