プロンプトと背景
あるマルチテナントSaaSで、長期間非アクティブな顧客が多数存在しています。インフラコストとデータ管理義務は増加し続けています。プロダクト部門はテナントリソースを回収したいと考え、営業部門は顧客を誤って削除することを恐れ、法務部門は契約、監査、および削除リクエストへの準拠を求めています。オフボーディングを自動化すべきかどうかをどのように判断し、通知、エクスポート、保持、削除、リカバリ、および監査のフローをどのように設計しますか？
AWS SaaS Lensでは、テナントごとのリソースインベントリ、オフボーディング用ランブック、承認ワークフローを推奨しており、廃止措置の前にリカバリ用またはコンプライアンス用のコピーが必要になる場合があります。NIST SP 800-88 Rev. 2では、サニタイズを「特定の労力レベルにおいて対象データへのアクセスを実行不可能にすること」と定義しています。この記事は公開資料を統合したものであり、特定企業の面接質問であることを主張するものではありません。
面接官が見ているポイント
面接官は、あなたが「自動化」を単なる削除ボタンではなく、可逆的な状態遷移として捉えられているかを評価しています。優れた回答は、サスペンド（一時停止）、アーカイブ、論理削除、物理サニタイズを区別し、顧客への通知、エクスポート、リーガルホールド（法的保持）、契約条件、リソース回収、リカバリ期間、監査証跡を網羅します。不十分な回答は、クラウドアカウントのコスト削減についてしか言及しません。
最初に明確にすべき質問
- 非アクティブの定義は、ログイン、ビジネスイベント、契約ステータス、支払ステータスのいずれに基づいていますか？
- そのテナントには保持期間、削除リクエスト、規制上の義務、またはリーガルホールドが適用されていますか？
- 顧客はどのエクスポート形式、リカバリ期間、リカバリ後のサービスレベルを必要としていますか？
- どの共有リソース、バックアップ、ログ、インデックス、サードパーティ連携が影響を受けますか？
30秒で答える要約
「ログインの経過日数だけで削除することはありません。通知、書き込み制限、アーカイブ、削除保留、サニタイズ済みの状態を定義し、各遷移において通知、承認、エクスポート、冪等なレコード記録を実施します。契約、リーガルホールド、削除リクエストによって保持の境界を定義し、リカバリ期間によってコールドストレージのコストを決定します。非本番環境でリハーサルを行い、回収可能なコスト、誤オフボーディング率、リカバリ成功率、苦情件数を測定しながらコホートごとに展開します。曖昧な状態が存在する場合は、自動サニタイズを一時停止します。」
ステップごとの解決策
まずはアセットインベントリ（資産目録）から始めます。データベースパーティション、オブジェクトストレージ、インデックス、キュー、バックアップ、キー、ドメイン、外部連携などが対象です。各アセットには、テナントの所有権、保持ポリシー、削除の依存関係、検証方法を記録します。このインベントリがなければ、削除を証明することも、リソース回収によるメリットを見積もることもできません。
タイマー駆動型の削除ではなく、ステートマシンを使用します。通知ステートで連絡を送信し、サスペンドで新規書き込みをブロックしつつ読み取りは維持し、アーカイブで低コストストレージへデータを移動し、削除保留で承認と最終通知を待ち、サニタイズで依存関係の順序に従って削除し証跡を作成します。状態遷移は冪等であり、再試行可能で、手動で一時停止できなければなりません。
通知とエクスポートはプロダクトの価値そのものです。テナント管理者および請求先担当者に対し、日付、影響、エクスポートリンク、不服申し立ての窓口を記載して複数回通知します。エクスポートパッケージには、チェックサム、対象範囲、有効期限、暗号化の詳細を含めます。大規模なテナントには再開可能な非同期ジョブを使用し、1つのダウンロードによってオフボーディングのステートマシン全体がブロックされないようにします。
保持は契約とリスクに従います。リーガルホールド、未解決の紛争、規制上の保持義務、またはセキュリティ調査によってサニタイズがブロックされる場合があります。プライマリデータを削除してもデータが無期限に残存することがないよう、バックアップ、ログ、レプリカには独立した有効期限ルールが必要です。データを復元不可能にする必要がある場合は、メディアとリスクに適した方法を使用し、検証結果を記録します。データベースの行を削除するだけではメディアのサニタイズにはなりません。
リカバリには明確な境界が必要です。アーカイブとサスペンドは通常可逆ですが、物理サニタイズは不可逆です。現在のステータス、完了予定時間、リカバリ費用を明示します。リカバリ訓練では、1つのテーブルだけでなく、テナントのID、権限、インデックス、キー、Webhook、請求ステータスを確認します。リカバリ中はテナントを隔離し、古い認証情報や期限切れの設定が再アクティブ化されないようにします。
承認フローとガードレールを活用します。高価値テナント、最近アクティブだったテナント、保留対象、分類が曖昧なテナントは人間のレビューキューに送り、その他は自動進行を許可します。バッチ処理の上限、サーキットブレーカー、グローバルな一時停止スイッチを設定します。テスト環境でリハーサルを実施した後、テナントコホートごとにロールアウトします。監査ログには、トリガー、通知、承認者、アセットごとの結果、異常な再試行を記録します。
優れた回答例
私はまず、自動化する価値があるかどうかを検証します。メリットは測定可能なリソース回収と手動エラーの削減であり、リスクは誤オフボーディング、契約上のデータ保持違反、エクスポート失敗、リカバリ失敗です。プロダクトの状態としては、通知、書き込み制限、アーカイブ、削除保留、サニタイズ済みを定義し、テナントのアセットインベントリに基づいて進行させます。契約、リーガルホールド、削除リクエスト、調査によって保持期間を定義し、エクスポート完了、通知の確認、承認をサニタイズの前提条件とします。
自動化には、冪等なジョブ、バッチ上限、サーキットブレーカー、手動一時停止メカニズムを用います。本番環境外でリハーサルを行い、コホートごとにロールアウトします。測定指標には、回収コスト、誤オフボーディング率、リカバリ成功率、エクスポート失敗、サニタイズ証拠の完全性、苦情件数を含めます。アーカイブはリカバリ可能ですが、物理サニタイズは不可能です。リカバリ訓練では権限、インデックス、キー、Webhook、請求を対象とします。公開SLAには、所要時間、エクスポート形式、リカバリ期間、不可逆となるポイントを明記します。
よくある間違い
- 症状 → ログインの経過日数だけで削除する。失敗する理由 → 契約、支払い、連携、リーガルホールドのシグナルが無視される。修正方法 → 複数のシグナルと人間によるガードレールを使用する。
- 症状 → プライマリデータベースの行のみを削除する。失敗する理由 → バックアップ、インデックス、ログ、オブジェクトレプリカが残る可能性がある。修正方法 → アセットインベントリとアセットごとの証跡を維持する。
- 症状 → サニタイズ後に通知する。失敗する理由 → 顧客がエクスポートや不服申し立ての機会を失う。修正方法 → 通知、エクスポート、承認を必須の前提条件にする。
- 症状 → すべての削除がリカバリ可能であると約束する。失敗する理由 → アーカイブと物理サニタイズでは可逆性が異なる。修正方法 → リカバリ期間、コスト、不可逆となるポイントを明記する。
- 症状 → 1つのバッチでグローバルに一斉展開する。失敗する理由 → 小さなミスが複数テナントを巻き込むインシデントに発展する。修正方法 → リハーサルを行い、コホートに分け、バッチ上限を設け、緊急停止スイッチを用意する。
フォローアップ質問と回答
非アクティブなテナントをどのように定義しますか？
契約および支払いのステータス、管理者による確認、主要なビジネスイベント、最近のログイン、サポートチケットなど、複数のシグナルを組み合わせて使用します。ログインは1つのシグナルにすぎません。コンフリクトやデータ欠落がある場合は、自動サニタイズではなく人間のレビューに回します。
顧客が即時削除を要求しているにもかかわらず、契約上データ保持が必要な場合はどうしますか？
法務部門が、どのフィールドやコピーを、どのくらいの期間保持する必要があり、誰がアクセスできるかを特定する必要があります。リクエストを「即時削除可能」「保持制限付き」「期限切れ後に削除可能」のスコープに分割します。その根拠、スケジュール、不服申し立ての手段を説明し、決定事項を記録します。
テナントがサニタイズされたことをどのように証明しますか？
アセットインベントリをベースラインとして使用し、各リソースの操作、バージョン、時刻、検証、再試行を記録します。バックアップやサードパーティのコピーも個別に確認します。単一のデータベースクエリをエンドツーエンドの証拠として提示するのではなく、スコープと制限事項を明示します。
自動化が成功したかどうかをどのように測定しますか？
回収されたリソースの価値、処理時間、誤オフボーディング率、リカバリ成功率、エクスポート失敗、証拠の完全性、人間の介入、苦情を追跡します。コストが削減されても誤オフボーディングやリカバリ失敗が増加している場合は、展開を一時停止し、処理を人間のキューに戻します。