DDEXフィード生成

DDEXフィード生成とは、リリースとそのメタデータを、ストリーミングサービスが自動的に取り込める標準XMLメッセージへと変換する処理のことです。フォーマットはDDEXのERN（Electronic Release Notification）で、タイトル、アーティスト、ISRC、アートワークの参照、音源リソース、配信地域、取引条件など、DSPがリリースを公開するために必要な情報をすべて格納します。このフィードを正しく生成できれば、手作業での再入力なしに音楽を届けられます。

DDEX（Digital Data Exchange）は、レーベル、ディストリビューター、DSP、出版社、著作権管理団体のあいだで使われるデジタル音楽流通のXMLメッセージ規格を定める標準化団体です（DDEX ERNドキュメント）。規格を実装するのにDDEX会員である必要はありません。手間がかかり、多くのレーベルが自前で抱えたくない部分は、有効なERNフィードを生成し、各DSPの要件が変わるたびに最新の状態へ保つことです。

このガイドでは、ERNメッセージに含まれる内容、フィード生成の手順、ERN 3.8.2と4.3の違い、そして生成を代行するプロバイダーの選び方を、LabelGridの位置づけも含めて解説します。

DDEX ERNフィードとは

ERNフィードは、1つのリリースと、それをどう提供すべきかを記述したXML文書です。中心となるメッセージはNewReleaseMessageで、DSPが必要とする3つの要素、つまり素材、リリース、条件をひとまとめにします。

• ResourceListには音源、動画、画像が入り、それぞれに識別子（トラックのISRC）と技術情報が付きます。
• ReleaseListはリリースそのものです。タイトル、表示アーティスト、レーベル名、UPC、ジャンル、リリース日が含まれます。
• DealListは商業条件を定めます。どの地域とプラットフォームに配信するか、リリースのタイミング、予約注文や事前保存（プリセーブ）の期間などです。

レコード会社やディストリビューターがこれらのメッセージをDSPに送ると、DSPはフィードを解析し、取引条件に従ってリリースを公開します（DDEX ERNドキュメント）。配信停止、メタデータの修正、新たな配信地域の追加も、それぞれ同じフォーマットの個別メッセージになります。必須フィールドを1つでも間違えるとDSPはフィード全体を拒否します。だからこそ、生成と同じくらい検証が重要なのです。

DDEXフィード生成の仕組み

フィード生成は、リリースデータからDSPがそのまま使えるERNパッケージを作り出します。一般的なパイプラインは次のように進みます。

1. メタデータを集める。リリースとトラックの各項目、参加者、識別子（ISRC、UPC）、配信地域、露骨な表現の有無などです。
2. 素材を参照づけする。各DSPの仕様に合わせてトランスコードした音源ファイルと、サイズ要件（通常は最小3000×3000px）を満たすアートワークをリソースとして添付します。
3. 検証する。送信前に、DDEXスキーマと配信先DSP独自のプロファイルに照らしてフィードをチェックします。著作権表記の欠落、不正なISRC、規定より小さいアートワークはここで検出されます。
4. ERN XMLを生成する。配信先に合わせた正しいバージョン（3.8.2または4.3）でNewReleaseMessageを組み立てます。
5. 配信する。パッケージを各DSPに送信し、受領確認を受け取ります。
6. 更新に対応する。修正、配信停止、新地域の追加は、同じリリースに紐づく後続メッセージとして送ります。

これが簡単ではない理由があります。2024年には、毎日およそ99,000曲もの新規トラックがストリーミングサービスに届けられました（Luminate 2024年版年末レポート）。この規模でXMLを手書きする人はいません。LabelGridはDDEXフィード生成を最初から最後まで担い、各DSPの最新プロファイルに合わせてERNを生成・検証し、主要なプラットフォームすべてへ配信します。レーベルやディストリビューターは、フィードエンジンを構築・保守するのではなく、リリースを送ることに集中できます。

ERN 3.8.2とERN 4.3：DSPはどちらを使うのか

現在、2世代のERNが実運用されています。ERN 3.8.2は依然として最も広く導入されており、ERN 4.3.xはDDEXが新規実装に推奨するバージョンです。両者に互換性はありません。フィードエンジンは、各DSPが求めるバージョンを使い分ける必要があります。

実務上のポイントはこうです。多くの中規模ディストリビューターがERN 3.8.2にとどまっているのは、DSPが今も受け入れており、ERN 3から4への移行が地域データモデル全体の再構築を意味するからです。一方で、Dolby AtmosのネイティブメタデータやPartyListによる重複排除といった新しい機能は、ERN 4.xにしか存在しません。使う価値のあるプロバイダーは両方に対応し、配信先ごとに適切なバージョンを選びます。LabelGridは配信とインポートの両方で、DDEX ERN 3.8.2、4.3.0、4.3.1、4.3.2に対応しています。

配信を正しく行うことの重要性は高まり続けています。2025年、ストリーミングは世界の録音音楽収益の69.6%に達し、有料サブスクリプション契約者は8億3,700万人になりました（IFPI Global Music Report 2026）。拒否されたフィードや不正なフィードは、いまや収益の大半が集まるチャネルでの露出を失うことを意味します。

DDEXフィード生成サービスで確認すべきポイント

自前で構築するのではなく、フィード生成を任せるプロバイダーを選ぶなら、見るべきはこのチェックリストです。

DDEXで音楽を配信する手順

1. 自社構築か外部利用かを決める。ERNエンジンを保守し、すべてのDSPプロファイル変更を追い続けるのは、終わりのない本格的なエンジニアリングです。ほとんどのレーベルやディストリビューターにとって、プロバイダーを使うのが理にかなった選択です。
2. バージョン対応を確認する。プロバイダーがERN 3.8.2と4.3.xの両方を生成し、各DSPに正しいバージョンを振り分けられるかを確かめます。
3. きれいなメタデータを用意する。正確なISRCとUPC、正しい著作権表記、仕様どおりのアートワーク。検証を通すのは、整った入力データです。
4. 配信前に検証する。スキーマとDSPごとのチェックにフィードを通します。指摘された点は、何かを送る前に直しておきます。
5. 配信して確認する。各DSPに送信し、受領確認を待ちます。どのプラットフォームがリリースを受け入れたかを追跡します。
6. カタログを保守する。修正、新地域、配信停止を後続メッセージとして送り、DSPの仕様変更時にはフィードに目を配ります。

LabelGridはこの流れに沿い、ERN 3.8.2、4.3.0、4.3.1、4.3.2をカバーする完全なDDEXフィード生成、配信前検証、音源のトランスコード、そして主要なDSPすべてへの配信を提供します。プログラムから運用したいチーム向けには、LabelGridのREST APIを通じて同じパイプラインを利用でき、サンドボックスと公開ドキュメントも揃っています。Spotify Preferred ProviderかつMerlin Network会員として、LabelGridはプラットフォームの要件が変わってもフィードを最新の状態に保ちます。

DDEXフィード生成：まとめ

DDEXフィード生成は、リリースを標準化されたERNメッセージ、つまりリソース、リリースデータ、取引条件を運ぶNewReleaseMessageへと変換し、DSPがそれを自動的に取り込みます。実運用中のバージョンは2つあります。最も広く導入されているERN 3.8.2と、推奨され、より軽量で空間オーディオに対応したERN 4.3.xです。優れたプロバイダーは両方に対応し、配信前に検証し、DSPの仕様変更を追跡します。自前のエンジン構築は継続的な保守の負担になります。ほぼすべての事業者にとって、生成・検証・配信を一手に引き受けるプロバイダーのほうが賢明な選択です。LabelGridはレーベルとディストリビューター向けにDDEX配信を担い、対応する4つのERNバージョンすべてで、APIアクセスと直接契約カタログ向けのSOBOにも対応します。