2026.09.12 / Agent Memories

トラブル対応で効くAI記憶のフィードバック｜続きから動ける運用設計

AIメモリーが関係する障害では、「なぜ間違えたのか」を聞くだけでは再発防止につながりません。古い方針を思い出した、別の利用者情報を参照した、正しい記憶を検索できなかったなど、同じ誤回答でも原因の経路は異なります。インシデント後のフィードバックは、感想ではなく、観測可能な事実を復旧と改善へ変換する仕組みです。

この記事では、発見者の声、システム記録、担当者の判断を混ぜずに集め、応急処置、原因分析、恒久対策へ接続する方法を示します。責任追及のための面談ではなく、次回の早期検知と安全な復旧を可能にするための振り返りです。

最初の報告では解釈より現象を集める

受付フォームの冒頭は「何が表示されたか」「期待した結果は何か」「いつ、どの操作で起きたか」にします。「AIが壊れた」「記憶が汚染された」は仮説であり、現象ではありません。スクリーンショットや回答文がある場合も、個人情報を必要以上に複製せず、閲覧制限された証跡への参照を残します。

利用者には、問題報告のために秘密情報を再入力しないよう案内します。再現に必要なID、時刻、操作順だけで調査を開始できるよう、製品側の監査情報を整備します。

フィードバックを五種類へ分類する

誤保存：最初から間違った内容を長期化した
誤取得：別人、期限切れ、無関係な記憶を検索した
誤利用：取得は正しいが現在の指示より優先した
訂正失敗：修正・削除後も旧内容が使われた
説明不足：利用者が保存や利用を認識できなかった

最初から原因を一つに固定せず、複数分類を許します。分類不能は「その他」ではなく「未確認」とし、追加で必要な証跡を指定します。

タイムラインは三つの時計で作る

利用者が操作した時刻、システムが記録した時刻、担当者が認識した時刻を分けます。タイムゾーンも明記します。通知遅延や端末時計のずれがあるため、一つの時刻へ無理に統一すると原因を誤ります。

タイムラインには、記憶の生成、更新、検索、回答への利用、訂正、再利用の出来事を並べます。何も起きなかった区間も重要です。たとえば削除要求後に索引更新が走らなかった事実が、再発の直接原因かもしれません。

応急処置へのフィードバックは効果と副作用を分ける

問題の記憶を隔離して誤回答が止まったとしても、必要な顧客情報まで検索できなくなれば副作用があります。応急処置ごとに「止めた被害」「新たに使えなくなった機能」「手動で代替した作業」「元へ戻す条件」を記録します。

広い全停止は一見安全ですが、未返信や未処理を増やします。進行中の漏えい、重大な顧客被害、不可逆な破壊に関係する範囲は止め、それ以外は読み取り専用や正本の手動参照へ切り替えます。

原因分析では人の判断を欠陥名にしない

「担当者が確認しなかった」で終えると、同じ条件で別の人も失敗します。確認画面がなかった、期限切れが表示されなかった、正本へのリンクが切れていた、権限が広すぎたなど、判断を難しくした仕組みを特定します。人の選択も事実として扱いますが、再発防止は環境と手順まで掘ります。

仮説には確認方法を付けます。「検索索引の遅延が原因かもしれない」なら、本文更新時刻、索引時刻、次の検索結果を比較します。確認できなかった仮説を確定原因として記憶へ残さないことが重要です。

改善項目は検知・予防・復旧へ割り当てる

検知には期限切れ利用の警告、別ユーザー参照の監視、削除後の再検索テストを置きます。予防には保存前確認、出典必須化、アクセス分離を置きます。復旧には隔離、直前正常版への復元、滞留処理の回収を置きます。一つの対策ですべてを解決しようとしません。

各項目には担当、期限、完了条件、戻し方を持たせます。「注意する」「監視を強化する」は完了条件になりません。再現テストが失敗し、正常利用が壊れていないことまで確認できる形にします。

振り返りを閉じる前の実物確認

修正コードが入っただけでは閉じません。問題になった記憶が使われないこと、正しい記憶は使えること、訂正・削除が反映されることを実際の画面で確かめます。障害中に滞留した問い合わせや処理があるなら、重複なく回収します。

次の自然な実行でも同じ失敗が起きないかを見ます。公開、送信、請求など外部影響がある処理は、結果不明のまま再実行せず、外部側の状態を先に確認します。

一次資料が支える記録方法

OpenClawのMemory overviewは、長期要点と日次の詳細を別の層へ保存する考え方を示しています。インシデントの詳細を日次記録へ置き、再利用する確定事項だけを長期要点へ昇格する設計に応用できます。W3C PROV-Oは、問題の記憶、生成活動、関与した主体の関係を追跡する語彙を提供します。

NIST AI Risk Management Frameworkは、リスクの統治、把握、測定、管理を循環させる枠組みです。ここで基準にするのは2023年のAI RMF 1.0で、特定の障害報告様式を義務付けるものではありません。NISTはAI RMF 1.0を改訂中と案内しているため、改訂版の内容を1.0へ遡って混ぜず、採用版を記録します。

よくある質問

利用者の苦情はすべてインシデントとして扱いますか？

重大度は影響範囲、継続性、権利や顧客への影響で判断します。ただし小さな違和感も、同型が増えているなら早期検知の材料として記録します。

原因が分からないまま復旧してもよいですか？

被害を止める応急復旧は先行できます。確認済み原因と未確認仮説を分け、恒久対策の調査を別に続けます。仮説だけで広い変更は行いません。

振り返りには誰を参加させるべきですか？

検知した人、復旧した人、製品担当に加え、影響を受けた利用者の視点を代弁できる担当を含めます。個人情報は必要最小限にし、責任追及の場にしません。