提出先ごとに書式が違う楽曲メタ情報を、一元管理から始める
結論から書きます。楽曲のメタ情報を提出先ごとにエクセルで作り分けていると、いつか必ず版がずれます。しかも、ずれたことに気づくのは提出したあとです。解決策は作り分けをやめることではなく、マスターを1つに固定し、提出先ごとの書式は「出力」として生成することです。作り分けは残ります。手作業でなくなるだけです。
同じ楽曲なのに、提出先ごとに求められるものが違う
音源を1本リリースするだけでも、情報の提出先は複数にまたがります。
| 提出先 | 求められるもの | 形式 |
|---|---|---|
| 配信ストア／アグリゲーター | 配信に必要な楽曲情報 | 各社の取り込み形式 |
| 日本レコード協会 | ISRC（レコーディングを識別する国際標準コード）の申請 | 申請用のフォーマット |
| JASRAC | 著作権にかかわる作品の届出 | 登録用のフォーマット |
| 社内・レーベル内 | 制作情報や権利情報の記録 | 自社の台帳 |
それぞれが独立した形式を持ち、それぞれが更新されます。「どれが最新か」を人間が覚えている状態が、いちばん危険です。
「コピペで作り分ける」が破綻する理由
提出先ごとにエクセルを持つ運用は、最初はうまくいきます。破綻するのは修正が入ったときです。
- アーティスト表記を1か所直したが、他のファイルに反映されていない
- どのファイルが最新かが分からず、担当者ごとに違うファイルを使っている
- 提出先が項目を追加したとき、どのファイルを直せばよいか特定できない
- 退職・異動で、ファイルの意味を知っている人がいなくなる
共通しているのは、同じ情報が複数の場所にあることです。これは注意力では解決しません。情報の置き場所を1つにするしかありません。
手順1 — マスターの項目を、識別子を軸に決める
まず、どの識別子を軸にするかを決めます。録音（音源）を一意に識別するのはISRCですが、ISRCが採番される前の段階でも情報は動き始めます。そのため実務では、自社の管理番号を必ず持ち、そこにISRCや各提出先のIDを紐づける形にします。
そのうえで、マスターに持つ項目を決めます。ポイントは「いま必要な項目」だけで始めることです。将来必要になりそうな項目まで最初に設計すると、埋まらない列が並び、「どこまで入力すればいいのか」が分からない台帳になります。
手順2 — 提出先ごとの出力パターンを定義する
マスターが1つあれば、提出先ごとのファイルはそこからの出力として作れます。重要なのは、この出力定義を人ではなく仕組みが持つことです。「Aさんが作っているマクロ」は、Aさんがいなくなった時点で失われます。
Music Manager は、マスターとなるメタ情報を一元管理し、提出先ごとの形式で出力します。出力できるのは、レーベル向けのコピー用データ、JASRAC 登録用CSV、日本レコード協会の ISRC 申請用CSV、iTunes プロデューサー登録用データ、アグリゲーター取り込み用データです。出力形式は CSV / TSV から選択できます（xml形式は未対応）。詳しくはメタ情報・楽曲データ管理をご覧ください。
手順3 — 入力を、情報を持っている人に寄せる
メタ情報の入力を自社の担当者に集中させると、そこが恒久的なボトルネックになります。情報を持っているのは権利者側であることが多いので、入力自体を権利者に寄せ、自社は確認に回るのが構造的に軽くなります。
Music Manager では、権利者が入力フォームからメタ情報を登録し、自社担当者が確認します。一部は自動チェックがかかります。入力フォームの項目定義は管理画面から自社でカスタマイズでき、録音スタジオ名やエンジニア名といった拡張項目も追加できます。
海外配信と多言語
海外市場に出す場合、同じ楽曲でも言語ごとに表記が必要になります。ここで言語別のエクセルをもう1枚作ると、版ずれの問題が言語の数だけ増えます。多言語のメタ情報も同じマスターの中で持つことが前提です。
気をつけたいこと
項目は必ず増えます。配信ストアの要求も、業界の慣行も変わります。だからマスターを設計するときに問うべきなのは「いま必要な項目が入るか」ではなく、「項目を増やすときに、開発を待たずに自社でできるか」です。ここを確認せずに導入すると、項目1つ増やすのに見積もりと待ち時間が発生します。
もう一つは出力形式の確認です。提出先がxmlを求めているのにCSV/TSVしか出せない、といった食い違いは導入前に必ず洗い出してください。現在の提出先すべてについて、実際のファイルを1本ずつ出せるかを試すのが確実です。