業務が終わったファイルを「アーカイブ」に移せば、必要なときに取り出せるのでしょうか。バックアップを毎日保存していれば、法律や契約で求められる記録も適切に管理できているのでしょうか。答えは、どちらも一概には言えません。
アーカイブは長期的な参照、バックアップは障害時の復元を主な目的とする仕組みです。保存期間の判断や削除の義務は、さらに別の問題です。BtoBマーケティング、営業、情報システム部門が使うデータを例に、これらの役割を区別し、実務の判断を整理します。
アーカイブとは何か――長期保管だけでは足りない
アーカイブは、日常的にはアクセスしなくなった情報を、後で参照する目的に合わせて保管する考え方です。単にファイルを低コストな保存先へ移すだけでは、将来その記録を利用できるとは限りません。ファイルの意味が分かる名前、作成時期、担当部署、改訂履歴、アクセス権限、取り出す手順も必要になる場合があります。
米国国立公文書館（NARA）は記録管理のスケジュールで、永久保存する記録と、一定期間後に廃棄する記録を分けています。これは米国の行政機関の制度を説明した例であり、日本の民間企業にそのまま適用する保存年限ではありません。記録の目的に合わせて保存・廃棄を設計するという考え方の参考になります。
たとえば以前の展示会のLP、承認済みパンフレット、KPIの定義や施策の意思決定記録は、翌年の担当者が参照できる形で残す価値があるかもしれません。とはいえ、問い合わせフォームから得た個人データを同じ理由で無期限に残せるという意味ではありません。
バックアップとの違い――参照するためか、戻すためか
| 目的 | 問い | 例 |
|---|---|---|
| アーカイブ | あとから必要な情報を探せるか | 過去の施策資料と判断記録 |
| バックアップ | 失ったデータを安全に戻せるか | CRMの障害復旧用コピー |
| 保持・記録管理 | 何をどれだけ保有するか | 保存期間とアクセス権の設定 |
| 削除・廃棄 | 不要になった情報をどう処理するか | 保有理由がなくなったデータの見直し |
バックアップで重視するのは、障害・誤操作・破損があった後に、業務をどの時点まで、どのくらいの時間で回復できるかです。アーカイブが存在しても、システム設定や最新のCRMデータまで安全に戻せるとは限りません。逆にバックアップに古いファイルが残っていても、担当者が何を残すべきかを判断した記録管理の代わりにはなりません。
NISTの2026年「OT Backup Quick Start Guide」は、産業用のOTシステムにおける定期的なバックアップと復旧テスト、変更管理への組み込みを重視しています。対象はOTであり、これをBtoBマーケティングへの一律の義務と扱うものではありませんが、バックアップは取得できたかだけでなく、復旧できたかが重要という実務的な教訓があります。
クラウドの例：S3 Glacierの3つの取り出し方
AWSの公式ドキュメントによれば、S3 GlacierにはInstant Retrieval、Flexible Retrieval、Deep Archiveなど、アクセスの頻度や取り出し方が異なるストレージクラスがあります。名称が似ていても、すべてが即時取得できるわけではありません。
- Instant Retrieval：低頻度アクセス向けながら、データの読み出しを即時に行えるストレージクラス。
- Flexible Retrieval：長期保管と、復元のための待機を前提とするアーカイブストレージクラス。
- Deep Archive：さらに低頻度に参照する長期保管向けで、復元に時間がかかるストレージクラス。
AWSのアーカイブストレージの説明では、Flexible RetrievalとDeep Archiveのデータを利用するには復元リクエストを行い、一時コピーが利用可能になるのを待つ必要があるとしています。一時コピーの保持期間が切れると再取得が必要です。
クラウドの選定では単価だけでなく、取り出しに許される時間、保管の最低期間、復元時の料金、操作権限、リージョン、障害対策を確認します。最新の料金・取得時間は契約条件によって変わり得るため、導入時に公式情報で確認してください。
アーカイブは「永久に置いてよい」という意味ではない
資料に長期的な価値があっても、すべての情報を無期限に保持する合理性があるとは限りません。特に顧客の連絡先、ヒアリング記録、録音、行動履歴では、利用目的、契約、法令、権限、削除依頼等を確認する必要があります。
Microsoft PurviewのData Lifecycle Managementは、必要なコンテンツを保持し、不要なコンテンツを削除するための製品機能を説明しています。これはMicrosoft 365の技術的な仕組みであって、日本の個人情報保護法における具体的な保存年限を定める資料ではありません。
「配信停止」「通常利用の終了」「保管期限の満了」「バックアップからの消去」は別々の運用です。記録をアーカイブへ移すだけで個人情報の取扱いの課題が解決するわけではありません。必要な部署と相談し、情報の種類ごとに処理方法を設計します。
業務で使える保存前チェックリスト
- 目的：後日の参照か、障害復旧か、証跡の保存か。
- 対象：企画書・制作物・設定・個人データを区別したか。
- 責任者：保存・閲覧・削除を判断する担当は誰か。
- 期間：なぜ、その期間の保存が必要か。いつ再評価するか。
- 検索：資料のID、作成日、版、意味を将来の担当者が追えるか。
- 取り出し：必要なときのアクセス方法・費用・所要時間は何か。
- 復元：バックアップから業務を戻す検証を行ったか。
- 終了：廃棄・例外の承認や履歴をどこに残すか。
これは本サイトが複数の公式資料から学べる観点を整理した編集上のチェックリストです。全業種に適用される法令上の要件や、特定ベンダーの公式標準ではありません。
架空例：展示会が終わったBtoBチーム
以下は説明用の架空例です。半年後に展示会を振り返ろうとしたところ、LPの画像だけが残り、出稿した資料の版とCV定義が分からなくなっていたとします。一方、リード情報はCRMと別ツールに重複して残っています。
このとき、LP、配布資料、キャンペーンID、成果指標の定義、振り返りをセットでアーカイブする案が考えられます。CRMやMAの業務データについては、障害時に復旧できるよう別途バックアップを設計し、復元テストを行います。リードの個人情報については利用目的と保持条件を再評価し、必要な配信除外や廃棄の方法を選びます。
「すべてクラウドにあるから安心」とせず、残したい記録、復旧したい状態、使わなくなった情報を分けることが、最初の改善です。
WordPress・MA・CRMで気をつけたいポイント
WordPressサイトでは、記事本文だけでなく、画像やその他のメディア、プラグイン・テーマ設定、URLやリダイレクト設定などの復旧可能性を考えます。CMSのエクスポートだけで実際のサイト全体を復元できるかは、構成とバックアップ方法次第です。復旧手順は安全な環境で確認します。
マーケティングツールの終了時の実務はBtoBマーケティングツールを減らす前に、キャンペーン終了時のLP・フォーム・計測・個人データの扱いはBtoBキャンペーンの終わらせ方で詳しく解説しています。
顧客インタビューの録音や文字起こしについては調査記録の保管・再利用、CRMの情報の鮮度・配信除外の管理についてはBtoB顧客データの鮮度管理を参照してください。
よくある誤解を整理する
- 「低価格な保管先に移せばすぐに読める」――一部のアーカイブクラスでは復元に待ち時間が必要です。
- 「バックアップしたから記録の管理は完成」――文書の意味、必要期間、権限管理は別途設計します。
- 「古いファイルは全部削除」――保持義務や事業上の必要性を確認した上で処理します。
- 「アーカイブへ移せば削除依頼にも対応できる」――場所を変えることと、適切に削除・利用制限することは違います。
まとめ：長く残すものと、復旧するものを分ける
アーカイブを設計する際には、後から参照する価値と、必要な検索性・アクセス権を考えます。バックアップを設計する際には、実際の業務をどの条件で復旧するかを考えます。そして保持と削除の判断は、別途、法令や契約、利用目的に照らして行います。
何を残すか、いつまで残すか、誰が取り出せるか、失ったときに戻せるか。四つの問いに答えられる状態が、データを本当の資産にする土台です。
確認資料と適用範囲
- NARA「Records Schedule」：米国行政機関の記録の保持・廃棄。
- AWS公式「S3 Glacierストレージクラス」：保存クラスと取り出し方法。
- AWS公式「アーカイブストレージ」：復元リクエストと一時コピー。
- NIST「OT Backup Quick Start Guide」（2026年）：産業用システムでの復元試験。
- Microsoft Learn「Data Lifecycle Management」：保持・削除の考え方。
それぞれ米国の行政記録、AWSの製品仕様、OTの復旧、Microsoft 365の機能という異なる対象についての資料です。本記事の例とチェックリストはBtoB業務への編集上の応用であり、日本の法律の統一的な解釈ではありません。