ビジネスアプリのデータ保持ポリシー：保持期間とワークフロー

保持ポリシーは実際にどんな問題を解決するか

保持ポリシーは、アプリが従うデータに関する明確なルールです：何を保持し、どれくらい保持し、どこに保管し、期限が来たらどうするか。目的は「全部削除する」ことではありません。業務を遂行し過去の出来事を説明できる情報は残し、不要になったものを取り除くことです。

計画がないと、三つの問題がすぐに現れます。ストレージが静かに増え続けて実際のコストになる。個人データのコピーが増えるほどプライバシーとセキュリティのリスクが上がる。古いレコードが現在のロジックと合わなくなったり、人が場当たり的に削除してダッシュボードが突然変わるとレポートが信頼できなくなる。

実用的な保持ポリシーは日々の運用、証拠、顧客保護のバランスを取ります：

• 運用：人が普段通り業務を遂行できること。
• 証拠：後で取引を説明できること。
• 顧客：個人データを必要以上に保持しないこと。

ほとんどのビジネスアプリは名前が違っても広く同じデータ領域を持ちます：ユーザープロフィール、トランザクション、監査トレイル、メッセージ、アップロードされたファイルなど。

ポリシーはルール、ワークフロー、ツールの組み合わせです。ルールは「サポートチケットを2年保持する」といった宣言かもしれません。ワークフローは実務でそれが何を意味するかを定義します：古いチケットをアーカイブ領域に移し、顧客のフィールドを匿名化し、発生したことを記録する。ツールはそれを繰り返し可能で監査可能にします。

AppMaster上でアプリを構築する場合、保持は一回限りのクリーンアップではなく製品の振る舞いとして扱ってください。スケジュールされた Business Processes は毎回同じ方法でデータをアーカイブ、削除、匿名化でき、レポートの一貫性が保たれ人々は数字を信用できます。

保持期間を決める前に明確にする制約

日付を決める前に、そもそもなぜデータを保持するのかを明確にしてください。保持の判断は通常、プライバシー法、顧客契約、監査や税務のルールによって形作られます。このステップを省くと、過剰に保持してリスクとコストが上がるか、後で必要になるものを削除してしまいます。

まず「必ず保持すべきもの」と「あると便利なもの」を分けます。必須保持には、誰がいつ何をしたかを証明するために必要な請求書、会計エントリ、監査ログが含まれることが多いです。あると便利なものは古いチャットの記録、詳細なクリック履歴、生のイベントログなどで、時折の分析にしか使わないことがあります。

要件は国や業界によっても変わります。医療提供者向けのサポートポータルは、B2Bの管理ツールとは全く別の制約があります。同じ企業内でも複数国にユーザーがいると、同じ記録タイプに異なる規則が適用されることがあります。

決定は平易な言葉で書き、オーナーを割り当ててください。「チケットは24か月保持する」だけでは不十分です。何が含まれるか、除外されるものは何か、期限終了時に何が起きるか（アーカイブ、匿名化、削除）を定義してください。製品や法令が変わったときに更新が滞らないように、人やチームを担当にしてください。

早い段階で承認を得ておきましょう。エンジニアリングが実装する前に法務は最小限の保持や削除義務を確認し、セキュリティはリスク、アクセス制御、ログを確認し、プロダクトはユーザーが何を見続ける必要があるかを確認し、財務は記録保持の要件を確認します。

例：請求記録は7年間保持し、チケットは2年間保持し、アカウント解約後はユーザープロフィールのフィールドを匿名化し集計メトリクスのみ保持する、など。AppMasterではこれらの文書化されたルールをスケジュールされたプロセスとロールベースのアクセスにマッピングでき、後で推測する手間が減ります。

データをタイプ、機微さ、保管先でマップする

チームが「2年保持」と決めても「それ」が何を指すかを知らなければポリシーは失敗します。持っているデータのシンプルなマップを作ってください。完璧を目指さず、サポート責任者と財務責任者が両方理解できるレベルを目標にします。

タイプと機微さで分類する

実用的な出発点のセット：

• 顧客データ：プロフィール、チケット、注文、メッセージ
• 従業員データ：人事記録、アクセスログ、デバイス情報
• 運用データ：ワークフロー、システムイベント、監査ログ
• 財務データ：請求書、支払い、税関連フィールド
• コンテンツとファイル：アップロード、エクスポート、添付ファイル

次に機微さを平易な用語でマークします：個人データ（氏名、メール）、財務（銀行情報、支払いトークン）、認証情報（パスワードハッシュ、APIキー）、規制対象データ（例えば医療情報）など。不確かな場合は「潜在的に機微」とラベルして確認するまで慎重に扱ってください。

保管場所と依存先をマップする

「どこにあるか」は通常メインDB以上のものを含みます。正確な保管先を記録してください：データベースのテーブル、ファイルストレージ、メール/SMSログ、分析ツール、データウェアハウスなど。また各データセットを誰がどのくらいの頻度で使うか（サポート、営業、財務、経営陣）を記載します。それにより削除を急ぎすぎると何が壊れるかが分かります。

役立つ習慣：各データセットの目的を一文で記録すること。例：「サポートチケットは紛争解決と応答時間傾向の追跡のために保持する。」

AppMasterで構築している場合、Data Designerのモデル、ファイル処理、有効化された統合を見直して、実際にデプロイされているものと在庫を整合させることができます。

マップができれば、保持は大きな推測ではなく一連の小さく明確な選択になります。

実務で従いやすい保持ウィンドウの決め方

ウィンドウは説明しやすく、適用しやすいものでなければ機能しません。多くのチームはデータの使われ方に合わせて「ホット（日常的に使用）」「ウォーム（時々使用）」「コールド（証明用に保持）」という単純な階層でうまくやっています。階層は抽象的なポリシーをルーティンに変えます。

一つのグローバルな数字ではなくカテゴリごとにウィンドウを設定してください。請求書や支払い記録は税務や監査のために長いコールド期間が必要なことが多い一方、サポートのチャットは価値が急速に失われます。

また「いつからカウントするか」を決めてください。「2年保持」は何を起点にするかを定義しないと意味がありません。カテゴリごとに作成日、最終顧客アクティビティ、チケットのクローズ日、アカウントの解約などのうち一つを選びます。トリガーがバラバラでルールがなければ保持はぶれていきます。

事前に例外も書いておき、チームがその場で即興しないようにします。一般的な例外は法的保留、チャージバック、不正調査です。例外は削除を一時停止すべきで、隠れたコピーにつながるべきではありません。

最終ルールは短く、テスト可能に保ちます：

• サポートチャット：最終メッセージから6か月後に匿名化。ただし法的保留中は除外。
• マーケティングリード：契約がない場合は最終アクティビティから12か月後に削除。
• カスタマーアカウント：解約から30日後に削除；請求書は7年間保持。
• セキュリティログ：ホットで90日、調査用に12か月コールド保持。
• legal_hold=true が付いた記録：クリアされるまで削除しない。

アーカイブ戦略：データを使えるまま安く保つ方法

アーカイブはバックアップではありません。バックアップは誤操作や障害後の復旧用です。アーカイブは意図的なもの：古いデータをホットテーブルから外してより安価なストレージに移しますが、監査や紛争、履歴確認のために必要に応じて利用可能なままにします。

多くのアプリは両方を必要とします。バックアップは頻繁で広範です。アーカイブは選択的で管理されたもので、通常は必要なものだけを取り出します。

安価だが検索可能なストレージを選ぶ

安価なストレージは、人々が必要なものを見つけられて初めて役に立ちます。多くのチームは、読み取り重視のクエリに最適化した別DBやスキーマを使ったり、ファイルにエクスポートして検索用のインデックステーブルを置いたりします。PostgreSQL（AppMasterも含む）を中心に設計している場合、アーカイブ用のスキーマや別データベースを用意して本番テーブルを高速に保ちながら許可されたレポーティングでアーカイブデータにアクセスできるようにすることが一般的です。

フォーマットを決める前に、あなたのビジネスで「検索可能」とは何を意味するかを定義してください。サポートはメールやチケットIDで検索する必要があるかもしれません。財務は月別の合計が必要かもしれません。監査は注文IDでの追跡が必要かもしれません。

何をアーカイブするか：完全レコードかサマリか

完全なレコードは詳細を保持しますがコストがかかりプライバシーリスクも増します。サマリ（月別合計、カウント、主要状態の変化）は安価でレポーティングには十分なことが多いです。

実用的なアプローチ：

• 監査で重要なオブジェクト（請求書、返金、アクセスログ）は完全レコードをアーカイブする。
• 高頻度イベント（クリック、ページビュー、センサーピング）はサマリをアーカイブする。
• ホットストレージには小さな参照スライス（通常直近30〜90日）を保持する。

事前にインデックスフィールドを計画してください。一般的には主キー、ユーザー／顧客ID、日付バケット（月）、地域、ステータスなどです。これがないとアーカイブは存在するだけで取り出しが難しくなります。

リストアルールも定義します：誰がリストアを要求できるか、誰が承認するか、リストア先、期待時間。リストアはリスク軽減のために意図的に遅くしても構いませんが、予測可能である必要があります。

削除 vs 匿名化：適切なアプローチの選択

保持ポリシーは通常、記録を削除するか個人情報を削るかという選択を迫ります。どちらも正しい場合がありますが、解決する問題は異なります。

ハード削除はレコードを物理的に取り除きます。法的・業務的に保持する理由が全くなく、存在すること自体がリスクになる（例えば敏感な内容を含む古いチャット）場合に適しています。

ソフトデリートは行を残して削除されたことを示す（多くは deleted_at タイムスタンプを使う）手法で、通常画面やAPIからは隠します。ソフトデリートはユーザーが復元を期待する場合や下流システムがまだ参照している可能性がある場合に有用です。欠点はソフトデリートされたデータは依然として存在し、ストレージを消費し、エクスポートで漏れる可能性があることです。

匿名化はイベントやトランザクション自体は保持しつつ、個人を特定できる情報を削除または置き換えます。正しく行えば再識別できない状態にできます。擬似匿名化（pseudonymization）は識別子（メールなど）をトークンに置き換え、別のマッピングで再識別可能にする方法で、不正調査には役立ちますが完全な匿名化とは異なります。

関連するデータに明確であることも重要です。削除したのに添付ファイル、サムネイル、キャッシュ、検索インデックス、分析のコピーを残してしまうと目的が果たせません。

また削除が実行された証拠も必要です。何が削除／匿名化されたか、いつ実行されたか、どのワークフローが実行したか、成功したかどうかを記録するシンプルな削除レシートを保持してください。AppMasterでは、Business Process がジョブ終了時に監査エントリを書くことでこれを実現できます。

個人データを除去しつつレポートの価値を保つ方法

記録を削除や匿名化すると、ダッシュボードが時系列で結合できなくなり壊れることがあります。何かを変更する前に、どの数字を月次で比較可能に保つ必要があるかを書き出してください。そうしないと後で「昨年のチャートがなぜ変わったのか」をデバッグすることになります。

まず長期的に正確である必要がある指標の短いリストを作ります：

• 日次・週次・月次の収益と返金
• プロダクト利用：アクティブユーザー、イベント数、機能の採用率
• SLA指標：応答時間、解決時間、稼働率
• ファネルとコンバージョン率
• サポート量：チケット数、カテゴリ、バックログの年齢

次にレポートに必要なものを残すように保存方法を再設計します。個人識別子に依存しない集計が最も安全です。すべての生データ行を永遠に保持する代わりに、日次合計、週次コホート、個人に戻せないカウントを保持します。例えば「カテゴリごとの日別作成チケット数」や「週ごとの中央値初回応答時間」を保持すれば、元のチケット本文を後で削除しても傾向は保てます。

身元を保持せずに安定した分析キーを保つ

時系列でグループ化する安定したキーが必要なレポートはあります。その場合は直接識別できない代理の分析キー（例えば分析用にのみ使うランダムUUID）を使い、保持ウィンドウ終了後は実際のユーザーIDへのマッピングを削除またはロックダウンします。

可能なら運用用テーブルとレポーティング用テーブルを分けてください。運用データは変わりやすく削除されます。レポーティングテーブルは追加のみのスナップショットや集計にします。

匿名化後に何が変わるかを定義する

匿名化には影響があります。チームが驚かないように、何が変わるかを文書化してください：

• 特定期間以降はユーザーレベルのドリルダウンができなくなることがある
• 属性が削除されると過去のセグメントが「不明」になる可能性がある
• メールや電話を削除すると重複排除の結果が変わることがある
• 一部の監査では非個人のタイムスタンプやIDがまだ必要になることがある

AppMasterで構築する場合、匿名化はワークフローとして扱ってください：まず集計を作成し、レポート出力を検証してからソースレコードのフィールドを匿名化します。

ステップバイステップ：ポリシーを実際のワークフローとして実装する

保持ポリシーはソフトウェアの通常の振る舞いになって初めて機能します。入力を定義し、アクションを定義し、結果を見える化して扱います。

一ページのマトリクスから始めましょう。各データタイプについて保持ウィンドウ、トリガー、その後の処理（保持、アーカイブ、削除、匿名化）を記録します。人が一分で説明できないものは守られません。

レコードが「いつの間にか消えた」状態にならないよう、明確なライフサイクル状態を追加します。多くのアプリは三つで足ります：active、archived、pending delete。状態はスプレッドシートではなくレコード自体に保存してください。

実装の実用的な手順：

1. 保持マトリクスを作り、プロダクト・法務・運用が確認できる場所に保存する。
2. ライフサイクルフィールド（ステータスや archived_at、delete_after のような日付）を追加し、画面とAPIがそれを尊重するようにする。
3. スケジュールジョブを実装する（一般的には日次）：一つはアーカイブ、もう一つは期限切れのものをパージまたは匿名化する。
4. 例外パスを追加する：誰が削除を一時停止できるか、どのくらいの期間、どの理由が記録されるか。
5. 本番に近いコピーでテストし、重要なレポート（カウント、合計、ファネル）を前後で比較する。

例：サポートチケットは90日アクティブ、その後18か月アーカイブ、最後に匿名化、のような流れ。ワークフローはチケットをアーカイブ済みにマークし、大きな添付を安価なストレージに移し、チケットIDとタイムスタンプは保持しつつ名前やメールを匿名化します。

AppMasterではライフサイクル状態をData Designerに持たせ、アーカイブ／パージロジックをスケジュールされた Business Processes として実行できます。目標は繰り返し実行されることと、監査しやすい明確なログです。

データ損失やレポート破損を招くよくあるミス

ほとんどの保持失敗は選んだウィンドウの問題ではなく、削除が誤ったテーブルに触れたり、関連ファイルを見逃したり、レポートが依存するキーを変えてしまうことが原因です。

よくあるシナリオ：サポートが「古いチケットを削除する」として添付ファイルを別テーブルやファイルストアに残してしまう。その後監査人が返金の裏付けを求めたとき、チケット本文は残っているがスクリーンショットがない、という事態になります。

他の落とし穴：

• メインのレコードは削除したがサイドテーブル（添付、コメント、監査ログ）を孤立させてしまう。
• 生イベントをパージしてしまい、財務やセキュリティが合計を照合できなくなる。
• ソフトデリートに頼り続けてデータベースが膨張し、削除済みデータがエクスポートに漏れる。
• 匿名化の際に識別子（user_idなど）を変更してダッシュボードや保存済みクエリの結合が壊れる。
• 例外や法的保留のオーナーがいないため、ルールが一貫して適用されない。

もう一つの頻繁な問題は、人物ベースのキーで構築されたレポートです。メールや名前を上書きするのは問題ないことが多いですが、内部のユーザーIDを置き換えると一人の履歴が複数に分裂し、月次アクティブユーザーやライフタイムバリューのレポートがずれてしまいます。

大抵のチームに効く二つの対策：まず、変わらない報告用キー（内部アカウントIDなど）を定義し、個人情報と分けて保持する。次に、削除を関連データ（ファイルやログを含む）を辿って完全に処理するワークフローとして実装することです。AppMasterではこれが、ユーザーやアカウントを起点に依存関係を集めて安全な順序で削除／匿名化する Business Process にうまく対応します。

最後に、法的保留を誰が一時停止できるか、そしてその一時停止をどう記録するかを決めてください。例外にオーナーがいなければポリシーは一貫して適用されません。

実行前のクイックチェック

削除やアーカイブのジョブを実行する前に現実チェックを行ってください。多くの失敗は誰がデータを所有しているか、コピーがどこにあるか、レポートがそれにどう依存しているかが不明なために起きます。

保持ポリシーには明確な責任とテスト可能な計画が必要であり、単なる文書だけでは不十分です。

実行前チェックリスト

• 各データセットにオーナー（変更を承認し質問に答えられる人）を割り当てる。
• 各データカテゴリに保持ウィンドウとトリガーを確認する（例：「チケットクローズから90日」や「最終ログインから2年」）。
• レコードが出現するすべての場所（DB、ファイルストレージ、エクスポート、ログ、分析コピー、バックアップ）で同じレコードを見つけられることを証明する。
• アーカイブが実用的であることを検証する：検索や結合に最小限のフィールド（ID、日付、ステータス）を保持し、何が削除されるかを文書化する。
• 証拠を出せること：何が削除または匿名化されたか、いつ実行されたか、どのルールに従ったか。

簡単な検証はドライランです：少人数分（例：ある顧客の古いケース一件）のバッチを取り、テスト環境でワークフローを実行して、主要なレポートを実行前後で比較します。

「証拠」はこうあるべき

個人データを再導入しない方法で証拠を保存します：

• ジョブ実行ログ（タイムスタンプ、ルール名、件数）
• 不変の監査テーブルに記録IDと実行アクション（削除か匿名化か）
• 法的保留の短い例外リスト
• 期待されるメトリクスが安定していることを示すレポートスナップショット

AppMaster上で構築する場合、これらのチェックはData Designerの保持フィールド、Business Process Editorのスケジュールジョブ、明確な監査出力にそのまま対応します。

例：レポートを維持するカスタマーポータルの保持プラン

サポートチケット、請求書と返金、生ログ（ログイン、ページビュー、API呼び出し）を保存するカスタマーポータルを想像してください。目的はストレージコストとリスクを下げつつ、請求、監査、傾向レポートを壊さないことです。

まず必須保持データと日常サポートでのみ使うデータを分離します。

単純な保持スケジュールの例：

• サポートチケット：クローズから18か月は全文保持
• 請求書と支払い記録：7年間保持
• 生ログ：30日保持
• セキュリティ監査イベント（管理者の変更、権限更新）：12か月保持

古いチケットはアーカイブするステップを追加します。すべてをメインテーブルに永遠に保存する代わりに、閉じたチケットで18か月より古いものはアーカイブ領域に移し、検索可能な小さなサマリ（チケットID、日付、製品領域、タグ、解決コード、最後のエージェントメモの抜粋）を保持します。これによりコンテキストを保ちつつ個人情報の多くを手放せます。

解約済みアカウントは傾向を残したい場合は削除より匿名化を選びます。氏名、メール、住所などの個人識別子をランダムトークンに置き換え、プラン種別や月次合計のような非識別フィールドは保持します。日次のアクティブユーザー数、月別のチケット数、月別収益のような集計は個人データを含まない別のレポーティングテーブルに保存します。

月次レポートは変化するかもしれませんが、計画すれば悪化は避けられます：

• チケットのボリューム傾向は本文ではなくタグや解決コードから得られるため維持される。
• 収益レポートは請求書を残すことで安定する。
• 長期の使用傾向は生ログではなく集計から得られる。
• コホートは個人識別からアカウントレベルのトークンに移行できる。

AppMasterでは、アーカイブと匿名化のステップをスケジュールされた Business Processes として実行できるため、ポリシーが毎回同じように実行されます。

次のステップ：ポリシーを反復可能な自動化にする

保持ポリシーは人が従えるものであり、システムが一貫して強制することで初めて機能します。まずはシンプルな保持マトリクスを作成してください：各データセット、オーナー、ウィンドウ、トリガー、次のアクション（アーカイブ、削除、匿名化）、そして承認サインオフ。法務、セキュリティ、財務、カスタマーチケットを扱うチームとレビューしてください。

一度にすべてを自動化しないでください。まずはサポートチケットやログインログのような一般的なデータセットひとつをエンドツーエンドで選び、ワークフローを実現し1週間実行してビジネスが期待するレポートと一致するか確認します。次に同じパターンを使って次のデータセットに広げてください。

自動化は観測可能に保ちます。基本的な監視は通常次をカバーします：

• ジョブ失敗（アーカイブやパージは実行され完了したか）
• アーカイブの増加（ストレージトレンドの変化）
• 削除のバックログ（対象になっているが処理されていない項目）
• レポートの乖離（保持実行後に主要指標が変化していないか）

ユーザ向けの対応も計画してください。ユーザーが何を要求できるか（エクスポート、削除、訂正）、誰が承認するか、システムが何をするかを決めます。サポートには短い内部スクリプトを用意します：どのデータが影響を受けるか、どのくらい時間がかかるか、削除後に何が回復不能か。

カスタムコードを書かずにこれを実装したい場合、AppMaster (appmaster.io) は保持の自動化に適した選択肢です。Data Designerでライフサイクルフィールドをモデル化し、スケジュールされたアーカイブや匿名化の Business Processes を監査ログ付きで実行できます。まずは一つのデータセットから始め、それを退屈なく信頼できるものにしてからアプリ全体にパターンを広げてください。