録音メタデータの抽出とマッピング:検索できる状態にする
録音移行で最も多い失敗は音声が出せないことではなく、出したのに特定の一件を見つけられないことです。検索に必要な項目は音声ファイルではなくプラットフォームのデータベース側にあります。一緒に書き出すべき項目、対応関係の固定、時刻の扱い、そして検索できる出力の形を整理します。
更新日
移行を止めるのは、たいてい音声ではない
録音移行のプロジェクトが途中で止まるとき、原因が音声そのものであることはめったにありません。独自コンテナは解析でき、コーデックも判別でき、WAV も一括で書き出され、数十万件のファイルが新しいアーカイブに整然と並びます。そこへコンプライアンス部門から「何年何月何日、どのオペレーターが、どの番号と話した一件を出してほしい」と依頼が来て、誰も応じられない。ある一件を特定できるかどうかを決める項目は、ほとんど音声ファイルの中にはなく、元プラットフォームのデータベース側にあるからです。通話開始時刻、オペレーター ID、発信番号、着信番号、通話方向(着信か発信か)、通話時間、そして業務システムと通話を結びつける取引番号。これらが欠けた書き出しは、再生できるだけで検索はできません。再生できるだけの価値はほぼゼロです。三十万件を一件ずつ聴く人はいません。
対応関係の壊れ方は二通り:切れるか、ずれるか
音声とメタデータの対応は通常、元データベースの中で保存先を指す列によって成立しています。通話レコードごとに録音ファイルのパス、ファイル名、あるいは内部 ID を持っている、という形です。弱点は、この対応がファイル自身の属性ではなく外部の取り決めにすぎない点にあります。書き出しの途中でファイル名を変える、日付ごとのフォルダに並べ替える、複数バッチを一つのフラットなディレクトリにまとめて名前が衝突する。それだけで対応は切れます。切れた後に復元しようとすると、音声側に残るわずかな物理的特徴、つまり長さ、ファイルサイズ、更新時刻から推測するほかありません。数十万件の中には同じ秒に始まり同じ長さで終わる通話が大量にあり、そのような推測の結果を規制当局への提出に使える人はいません。対応関係は書き出しの最初の一歩で固定すべきもので、最後に組み立て直すものではありません。もう一つの壊れ方はもっと静かです。対応は切れていないのに、時刻そのものが誤っている場合です。プラットフォームのデータベースが何を格納しているかは、導入ごとに確認する必要があります。タイムゾーンの表示なしにサーバーのローカル時刻を持つもの、UTC を持つもの、テーブルによって両者が混在するもの。オフセットがなければその列は曖昧で、タイムゾーンをまたぐ検索では実際の通話から数時間ずれ、夏時間の切り替え日には一時間が重複したり丸ごと欠けたりします。安全なやり方は、三つを同時に書き出すことです。変換後の UTC タイムスタンプ、元の値をそのまま、そしてその元の値が属するタイムゾーンとオフセット。三つそろっていれば、後から食い違いが出ても追跡できます。変換結果だけを残すと、誤りは永久に見えなくなります。
検索できる書き出しとはどういうものか
- メタデータを付属物ではなく主索引として扱う:元データベースの通話レコード一件を一行とし、各行に特定の音声ファイルへの相対パスを持たせ、その列は全量の中で一意であること。
- 時刻は三列に分ける:UTC タイムスタンプ、元の値をそのまま、そして所属するタイムゾーンまたはオフセット。「時刻」という一列だけでは足りません。
- 項目名と値の対応づけを明示的に文書化する。通話方向はあるシステムでは 1 と 2、別のシステムでは I と O かもしれず、オペレーター ID が二つのテーブルで別体系になっていることもあります。この対応はスクリプトの中だけでなく文書に残すべきものです。
- そのまま取り込める構造化形式(CSV、JSONL、Parquet など)を選び、人手で管理する表計算ファイルにしない。数十万行は表計算ソフトの行数上限を超えますし、主キー制約もかけられません。
- 書き出した直後に双方向の突き合わせを行う:すべてのメタデータ行が対応するファイルに解決でき、すべてのファイルが対応する行に解決できること。どちらの差集合も空であることを記録に残します。
- 元データベースの件数、実際に書き出した件数、欠けた件数、そして欠けが集中している時期を検証レポートに書く。そのレポートこそが「検索できる」ことの証明です。
上海万椿のアプローチ
当社はコールセンターの過去録音の解析と移行を長年手がけており、メタデータを音声のおまけとして扱うことはありません。音声と同格の納品物として、検索に必要な項目一式を元プラットフォームのデータベースから抽出し、解析済みの音声と一件ずつ対応づけて固定し、時刻項目は上記の三列の考え方で書き出します。成果物は検索システムにそのまま取り込める構造化された一覧であり、元データベースと一件ずつ突き合わせた検証レポートを添えて納品します。目指すところは常に同じです。過去録音を特定ベンダーから切り離し、恒久的にオンラインで、いつでも取り出せて、検索も分析もできる状態にすることです。