現場主導のAIデータ保持期間と削除手順の実務ルール

現場が定めるべきAIデータ保持期間と削除手順の実務ルール

よくある迷いは「全データを一律で◯日保持する」と数値だけ決めてしまい、現場で復元できず手戻りが発生する点です。結果として顧客対応が遅れ、法務や監査対応の追加工数が発生します。本稿は現場で即使える分類表、判定テンプレ、監査ログサンプル、定期削除ジョブの実行例、運用ランブックのチェックリストを提供します。

一律ルールが招く失敗と対策

問題点の提示

一律の日数ルールだけでは現場対応が回りません。重要なのは「誰が・いつ・どの画面で何を参照するか」を起点に、業務シナリオとデータ種別を掛け合わせた最小単位で保持区分を定義することです。

具体的な失敗例

• カスタマーサポートが返金で過去請求PDFを参照したい場面で、PDFが削除済みだと説明資料の再生成に数時間〜数営業日の手戻りが発生する。
• 方針に「90日」とだけ書いて削除手順や証跡が未整備だと、監査時に削除した事実を証明できず追加レポートが必要になる。

最小単位で決める：業務シナリオ×データ種別

まず下の5項目を分類表の初期行として会議に持ち込み、各行で「復元要否／再生成可否／即時参照頻度」を明記してから保持日数を決めます。

業務シナリオ	データ種別	保持区分案	理由／要件	担当
カスタマーサポート：返金対応	請求PDF（派生成果物）	限定保存（短期）	再生成困難・即時参照が頻繁	サポート
会計監査対応	トランザクション原データ	長期保存（法令準拠）	監査説明に必須	経理
PoC検証	サンプル会話ログ	短期保存＋匿名化	再現性確認のみ、学習利用は限定	PoCリーダー
モデル運用	学習済みモデル／学習データ	限定保存（説明責任）	説明性要件・監査証跡必須	MLチーム
システム保守	バックアップログ	ログのみ保存	復旧用、顧客提供不要	情シス

実務的な順序：1) 分類表を作る → 2) 各行で「復元要否／再生成可否／参照頻度」を判定 → 3) A/B/Cの初期割当で決定。これで不要な手戻りを防ぎます。

判断軸を整理する — 現場で使う3つのチェックポイント

判断は以下の3軸で行います。テンプレに落とし込み、会議で即断できるようにしてください。

• データ種別：原データ／加工データ／派生成果物（PDF等）／学習済モデル。派生成果物は必ず「再生成可否（完全/部分/不可）」を評価。
• 業務必要性（問い合わせ頻度の数値閾値）：高＝月5件以上、中＝月1〜4件、低＝年1件以下。即時参照性の有無も評価。
• 削除実行性と監査性：自動削除の可否、手動承認の閾値（例：対象件数>1000は事前承認）、監査ログの必須フィールドを定義。

会議で使う即断テンプレ（1行例）：「頻度=中→B（限定保存: 30日）→削除=自動（夜間バッチ、100件超で保留）→承認者=事業部マネージャ」。

場面別の保持区分と削除手順

問い合わせ対応（実務フロー）

• 1) チケット発行 → チケットIDを必ず付与（例：CS-2026-0001）
• 2) 再生成可否判定（原データ・テンプレ有無・バージョンを確認）
• 3) 再生成不可なら既存ファイルを検索・提供（アクセスログを残す）
• 4) 削除はチケットに「承認者」「削除予定日」「バックアップ参照ID」を記録して実行

帳票／PDFの取り扱い

再生成可能／時間がかかる／再生成不可の3分類を採用。再生成困難は短期限定保存（例：90日）＋アクセス制限。限定保存は必ず承認チケットと紐付ける。

PoCフェーズの扱い

基本は短期保存＋匿名化。外部クラウドを使う場合は「エクスポート性」「削除APIの有無」「ベンダー削除証明の取得可否」を事前確認し、プロジェクト終了時に削除証跡を残します。PoC段階では、ChatGPTやClaude Codeのようなツールをログ要約や差分確認に使うこともあるため、ログ出力形式や保持要件を事前に決めておくと運用が楽になります。

承認フローと意思決定会議の設計

保持区分は現場の意思決定会議で決め、実行可能な承認フローを短く回す仕組みを作ります。会議は決定と承認履歴を残すことを目的に短時間で終えるのが望ましいです。

• 会議の最小アジェンダ：目的→対象行紹介→推奨保持区分→削除実行案→監査証跡案→承認者リスト
• A/B/C閾値例：A＝高頻度（月5件以上）または再生成不可、B＝中頻度（1〜4件）で再生成時間が許容、C＝低頻度（年1以下）で再生成容易
• 承認フロー例：事業部→情シス（自動化可否）→法務／情報セキュリティ→ワークフロー承認（承認ログ保存）

運用ランブックと監査証跡

運用は「定期削除ジョブ＋手動削除手順＋監査証跡保存」の三本柱で設計し、誤削除時の復旧手順をランブックに必ず入れます。

ランブックに入れるべき項目

• 削除ジョブ定義：スケジュール例（夜間バッチ: cron 0 3 * * *）、対象条件（分類表の行ID）、例外リスト
• 差分プレビュー手順：ステージングで差分抽出→差分一覧をチケットに添付→管理者承認→本番実行
• 手動削除チェックリスト（チケット必須項目）：チケットID、対象識別子、承認者ID、実行者ID、バックアップスナップショットID、削除理由

監査証跡サンプルJSON（テンプレ）：

{
  "ticket_id": "CS-2026-0001",
  "target_id": "invoice:INV-2026-0001",
  "action": "delete",
  "executor_id": "svc-delete-batch",
  "approver_id": "mgr-support-01",
  "timestamp": "2026-03-01T03:00:00Z",
  "backup_snapshot_id": "snap-20260301-0300",
  "vendor_deletion_proof": null
}

SQLベースの差分抽出サンプル：

SELECT id FROM generated_files WHERE category='invoice_pdf' AND created_at < now() - interval '90 days' AND exception_flag = false;

巻き戻し手順（概要）：1) 影響範囲特定 2) バックアップからの復元順序と担当 3) 影響顧客への通知テンプレと担当 4) 事後レビューとジョブ修正。

導入判断と小さく始める手順

導入は問い合わせ頻度と復元コストを基準にスコープを定め、請求・帳票など顧客対応で頻繁に参照される領域から着手すると手戻りが少ないです。

1. Step 0：最小5項目の分類表を作る（本稿サンプルをコピー）
2. Step 1：意思決定会議を開催（固定アジェンダ、1時間以内で合意）
3. Step 2：優先領域で1カ月の試行運用（差分プレビューと承認を必須化）
4. Step 3：ランブックを整備してスケールアウト

見送る条件：自動化コストが便益を上回る領域、法務で明確に保持が求められる場合、外部ベンダーが削除証明を提供できない場合などは再検討します。

今すぐやるべき3つ

1. 業務シナリオ×データ種別の分類表を作る（最小5項目）
2. 最初の意思決定会議でA/B/C判定と承認者を決める（会議テンプレを使用）
3. 小範囲で削除ジョブをテストし、監査証跡とランブックを整備してから拡大する

締めの一言：数値だけで線を引かず、まず現場で「その数値で実務が回るか（再生成・証跡・復旧）」を確かめ、会議で合意してランブックに落とし込んでから実行してください。