はじめに：対象と目的
PoCが止まったり、現場で再現できず対応遅延や監査指摘につながるのは、運用上の一律論（「全部短期削除」「ベンダー推奨そのまま」など）に起因することが多いです。本稿はプロジェクトリード、SRE／運用担当、内部統制・監査担当、問い合わせ対応リーダー向けに、会議で即答できる判断基準と場面別テンプレ（反対意見へ返す短い根拠文言つき）を提示します。
結論：3軸で黒白化し、場面別テンプレを用意する
判断は「リスク（機密性・法令・訴訟）」「業務価値（再現頻度×影響）」「権限（誰が参照・復元を許可するか）」の3軸で判定し、代表業務ごとに「初期保持日数（短期30–90日／中期90–365日／長期≥1年または法令準拠）＋必須メタ＋承認者」をテンプレ化します。こうすることでPoC停滞・再現不能・監査指摘の多くを防げます。
よくある誤解：短期削除万能説と長期保存万能説
全削除も全保存も誤りです。重要なのは「何が再現できなければ事業・監査で致命か」を最初に明文化して線を引くこと。短期削除は漏洩リスクを下げますが問い合わせ再現や監査対応力を落とします。長期保存は証跡性を高めますが、検索負荷・誤参照・運用コストを増やします。
- 出発点：会議で「再現できなければ失敗となる具体事象」を列挙する（例：SLA未達で補償が発生する、監査で出力条件の提示が必須になる等）
- 短期目安：再現頻度が月1回未満でPIIを含まない業務→30〜90日
- 長期目安：訴訟・法令保存義務・週1回以上の再現ニーズがある業務→1年以上（法令優先）
判断軸を実務で使える形にする
現場で即答できるチェックリストに落とし込み、いずれか1つでも “高” に該当すれば長期候補とする一行ルールを採用します。判定ルールは単純に：1項目でも高→長期、全て低→短期、混在→中期。
- リスク（高/中/低）— PIIの有無、法令保存義務、訴訟可能性
- 業務価値（高/中/低）— 再現頻度と再現失敗時の影響
- 権限・運用負荷（高/中/低）— 参照者数、復元承認の可否、検索コスト
会議で使える短縮チェック例：
- 問い合わせチャット（user_id, 会話ID, 入力時刻, チケット番号）— 再現頻度が月1回以上なら業務価値＝高→初期：90日（重要SLAなら1年）
- 帳票出力（出力時のクエリ条件、画面遷移、バージョン）— 監査対象なら法令優先で≥1年。出力条件をメタで保存しない限り出力自体の長期保存は避ける
- インシデントログ（タイムライン、関与アカウント）— フォレンジック前提で隔離領域へ移動、初期60日保持
場面別テンプレ（会議で宣言できる即決案）
代表場面ごとに「初期保持日数＋必須メタ＋承認者」を固定したテンプレを用意すると会議で即決できます。以下はそのまま提示できる例です。
問い合わせテンプレ（例）
- 初期保存：90日（頻度が月1回以上、またはSLAで重要な場合は1年）
- 承認：現場リーダー（プロダクトオーナー）＋SRE。法務は例外介入
- 必須メタ：user_id、会話ID、入力時刻、関連チケット番号、SLAタグ
- 検索要件：会話IDで完全再現。PIIは表示時にマスキング、復元は2名承認かつ承認ログ必須
- 反論ワンライナー（法務向け）：SLA違反→補償リスクがあるため、代表業務の再現閾値を満たす期間は暫定的に確保します
- 決定線：問い合わせが月1回以上発生する業務は90日以上を初期とする
画面確認・PDF／帳票テンプレ（例）
- 初期保存：1年（監査や法令で延長）
- 承認：SREまたはアプリ運用リーダー＋情報統制（監査対象は法務を入れる）
- 必須メタ：出力時のクエリ条件、画面遷移パス、出力フォーマット、生成バージョン
- 運用留意：出力条件が保存できない場合は、出力そのものの長期保存を避け、データと条件をセットで保持する
- 反論ワンライナー（監査向け）：まずテンプレ通り1年で運用し、監査で必要な追加項目のみ延長します
- 決定線：出力条件が保存できないなら出力の長期保存はしない
監査テンプレ（例）
- 初期保存：中長期（例：3年、法令準拠）
- アクセス制限：監査チーム限定のアーカイブ領域、参照は監査申請をログ化
- 必須メタ：誰がいつ何を検索・復元したか（監査証跡）
- 反論ワンライナー（現場のコスト反論へ）：監査要求は最小証跡（出力条件・承認履歴・復元ログ）を優先し、無関係データは削減します
- 決定線：監査チームと合意した最小証跡を満たさない保存案は受け入れない
インシデント対応テンプレ（例）
- 保存方式：発生時に即時で隔離領域へ移し、60日保持（フォレンジック完了後に長期化/削除を判断）
- 承認：セキュリティリード＋法務（重大インシデントは経営報告）
- 必須証跡：タイムライン、関与アカウント、復元手順のログ
- 運用要件：復元は必ず2名体制で承認ログを残す。隔離領域は監査可能なログを持つこと
- 反論ワンライナー（迅速復元要求へ）：フォレンジック完了までは隔離を維持し、即時復元は原則2名承認です
- 決定線：調査完了までの短期隔離は例外としない
承認フローとPoC適用の初期チェックリスト
承認は段階化（PoC暫定→本番暫定→最終）し、PoC段階で必須チェックを完了させる運用にしてください。PoCキックオフ時に現場リーダーが暫定を宣言し、1ヶ月以内に指定チェックを完了することを合意してから作業を始めます。
承認段階（会議でそのまま提示可）
- PoC暫定承認：現場リーダー＋SRE（テンプレ適用で60〜90日試験）
- 本番暫定承認：情報統制チーム＋法務（運用負荷とリスクを評価）
- 最終承認：経営（コスト影響やポリシー整合が必要な場合）
PoC適用チェックリスト（会議でそのまま使う）
- 代表業務3件を選定（例：問い合わせ、帳票出力、監査証跡）
- テンプレを当てはめる（初期日数、承認者、必須メタ項目）
- 検索・復元機能を1ヶ月試験で確認（代表クエリの応答時間、照合率、PIIマスキングの検証）
- 復元は必ず承認ログを残す（誰が、いつ、何のために復元したか）
- 監査向けダイジェスト（必須メタと復元ログのサンプル）を監査チームに提出
見送る条件：承認が得られない、検索・復元機能がPoCで確認できない、または復元が誤参照・漏洩リスクを増大させる場合は拡張を見送る。見送りの論拠はテンプレ化した短文で必ず記録します。
ベンダー（ChatGPT／Claude Code等）に関する扱い方
プロバイダ側のメタ情報や復元機能は判定材料です。企業側で短期削除をしても、プロバイダ側に痕跡が残ることがあります。契約時に保持期間・アクセス制限・削除仕様を確認し、テンプレに「プロバイダ保持の可視性」を注記してください。会議での短文：ベンダー保持が残るなら、短期削除だけでは保全要件を満たさない可能性があります。
まとめと実行手順（そのまま実行可）
導入判断は「リスク・業務価値・権限」の3軸チェックリストと場面別テンプレで行い、代表業務3件について暫定日数を即決してください。小さく始める手順：1) 代表業務3件を選定、2) 各テンプレでPoC暫定（60〜90日等）を実施、3) 1ヶ月試験で検索・復元と承認ログを確認して本番暫定へ進めます。保存・削除は二択ではなく、「何を再現できなければ失敗か」を基準に線を引く設計です。
よくある質問
Q: 保持期間の具体的な日数はどう決めればよいですか？
A: チェックリストで高/中/低を判定し、目安を適用します。短期：30〜90日（PIIなし、再現頻度低）、中期：90〜365日（問い合わせや帳票再現）、長期：1年以上〜法令準拠（監査や訴訟リスク）。PoCで1ヶ月試験して最終日数を確定してください。
Q: ベンダー（ChatGPTやClaude Code等）が保有するメタデータはどう扱うべきですか？
A: プロバイダ保持は判定材料です。契約で保持期間・アクセス制限・削除仕様を明確にし、テンプレに「プロバイダ保持の可視性」を入れて会議で共有してください。短期削除だけで要件が満たせない可能性があります。
Q: 監査で要求される最低限の証跡は何ですか？
A: 最低限は「出力条件（いつ、誰が、どの条件で出力したか）」「承認履歴」「検索・復元の操作ログ（誰が何を見たか）」です。監査テンプレで中長期保存し、アクセスは監査チームに限定してください。
コメント