暗号化された録音の移行：AES 暗号化された過去の録音を合法的に復号し解放する方法

なぜ暗号化された録音は「取り戻せないデータ」になるのか

コンプライアンスとプライバシー要件を満たすため、コンタクトセンターや金融取引の録音は保存時に AES で暗号化するのが一般的です。それ自体は全く正しい判断です。問題が表面化するのは数年後です。プラットフォームが停止し、ベンダー保守が終了し、当時暗号化を設定した担当者は退職し、鍵ストアはサーバーと共に撤去される——録音ファイルはすべて残っているのに、誰も開けられません。台帳の上では録音を「保存済み」でも、実際に照会・監査・訴訟で求められたときに提出できなければ、保存していないのと同じです。

録音はどう暗号化されているか：代表的な三つの鍵モデル

第一は全体共通の静的鍵です。システム全体で一つ、あるいは少数の AES 鍵を用い、鍵は設定ファイル、データベース、または専用の鍵ストアに保管されます。第二はエンベロープ暗号化です。録音ごとにランダムな AES セッション鍵で暗号化し、そのセッション鍵をさらに RSA 鍵ペア（通常は証明書の形で配布）で包んでファイルと共に保存します。復号には秘密鍵でセッション鍵を取り出す工程が先に必要で、Genesys Interaction Recording などがこの方式です。第三は外部管理で、鍵は KMS や HSM に置かれ、プラットフォームはインターフェース経由で呼び出し、鍵自体はディスクに書かれません。三つのモデルは移行の難易度が全く異なるため、最初の一手は必ず「どれに該当するか」の判定です。

移行を止めるのはアルゴリズムではなく鍵の管理

AES は公開された標準であり、アルゴリズム自体が障害になったことはありません。プロジェクトを実際に止めるのは鍵の側の現実です。鍵がプラットフォームと共に退役し、当時の鍵ストアのバックアップが見つからない。証明書が失効している、あるいは秘密鍵のパスフレーズを誰も覚えていない。ライフサイクルの途中で鍵をローテーションしたため、時期ごとに異なる鍵が必要になる。鍵 ID が既に停止したインデックス DB に記録されている。HSM はベンダーに返却済み、もしくはゼロ化されている。したがって暗号化録音の移行案件を評価する際に最初に確認すべきは、録音が何テラバイトあるかではなく、**鍵の材料が現存し、全期間をカバーしているか**です。

一線を引く：当社が行うのは復号であって、解読ではありません

当社は、お客様の書面による承認と、お客様から提供される鍵の材料（鍵ストア、証明書と秘密鍵、KMS/HSM へのアクセス権など）を前提として、お客様ご自身の録音を復号します。暗号を回避または解読する作業は一切提供も受託もいたしません。それは違法であり、正しく実装された AES に対しては技術的にも現実的ではないからです。データと鍵を保有するのはお客様であり、当社が提供するのは、その両者を正しく突き合わせ、使える形式へ大量に復元するエンジニアリング能力です。

技術的に必ず対処すべき点

1. 暗号文の範囲を特定する：ファイル全体を暗号化する実装もあれば、音声ペイロードのみを暗号化しヘッダーとメタデータ領域を平文で残す実装もある。ここを誤ると最初の 1 バイトから破綻する。
2. IV / nonce を見つける：初期化ベクトルはファイルヘッダー、各セグメントの直前、あるいは鍵 ID と連番から導出される場合がある。
3. 圧縮と暗号化の順序を判定する：圧縮してから暗号化か、暗号化してから圧縮か。順序を取り違えると出力はノイズになる。
4. セグメント単位の暗号化に対応する：長時間通話はブロックごとに独立した IV で暗号化されることが多く、正しい順序でブロック単位に復元する必要がある。
5. 鍵 ID を対応付ける：どのファイルをどの鍵で暗号化したかはヘッダーやインデックス DB に記録されているのが通例で、特に鍵をローテーションした環境では確実な突き合わせが不可欠。
6. 復号結果を検証する：出力は妥当な音声ビットストリームであり、妥当な長さ・チャネル構成・波形にデコードできなければならない。「エラーが出なかった」ことは成功の証明にならない。

標準的な進め方

1. 鍵材料の棚卸し：鍵ストア／証明書／秘密鍵／KMS が利用可能か、録音の全期間をカバーしているかを確認する。
2. サンプル試験復号：実際の録音を少量取り、試聴可能な WAV までエンドツーエンドで復号し、鍵・コンテナ・コーデック・チャネル・メタデータがすべて正しいことを確認する。
3. 規模と方式の確定：総データ量、保管場所、オンプレミス実施の要否、納品形式を決める。
4. 一括復号と変換：復号 → コンテナ解体 → 正しいコーデックで標準 WAV へ変換 → 二チャネル分離と通話メタデータを保持。
5. 整合性検証：バッチごとにファイル数、長さ、チャネル数、サンプリングレートを照合し、検証レポートを作成する。
6. 納品と再保護：アーカイブを平文で保管するか再暗号化するかをお客様と決定する。

解放した後、再び暗号化すべきか

ほとんどのお客様の答えは「する。ただし方式を変えて」です。過去の録音が閉じ込められた原因は暗号化そのものではなく、鍵がいずれ寿命を迎える専有プラットフォームに縛られていたことにあります。移行後に推奨する形は、音声はオープン形式（WAV）で保管し、暗号化はベンダー非依存の方式に切り替えることです。ストレージ層の暗号化、あるいはお客様が管理する鍵によるエンベロープ暗号化を用い、鍵はお客様自身の KMS/HSM に保管し、監査可能な鍵のバックアップとローテーション手順を整えます。これによりコンプライアンスを満たしつつ、十年後に同じ問題を繰り返さずに済みます。全工程はお客様の構内で実施でき、録音データがネットワーク境界を出ることはありません。

始め方

まずはサンプルの試験復号から始めてください。元のプラットフォームとバージョン、判明していれば暗号化方式、鍵の材料が現在どこにあるかをお知らせいただき、匿名化可能なサンプルファイルと対応する鍵をご提供ください。数営業日以内に、試聴可能な復号結果と技術説明書をお返しします。プロジェクト全体の実現可能性を判断するうえで、最も速く最も確実な一歩です。