DDEXフィード生成

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

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

DDEX（Digital Data Exchange）は2006年に設立された非営利の標準化団体で、デジタル音楽のサプライチェーンで使われるXMLメッセージ形式を定めています。レーベル、ディストリビューター、DSP、出版社、著作権管理団体はこの形式を使い、取引先ごとに個別の連携を作ることなく、リリース・権利・売上のデータを自動でやり取りしています（DDEXについて）。配信で特に重要なのがERN（Electronic Release Notification）です。新しいリリースと、その音源・アートワークへの参照、取引条件をまとめてDSPへ届けるメッセージです。

LabelGridはリリースをDDEX ERNメッセージとしてDSPへ納品しており、ERN 3.8.2、4.3.0、4.3.1、4.3.2に対応しています。LabelGridはDDEXの会員ではありません。規格の実装に会員資格は不要で、DDEXの無償の実装ライセンスを取得すれば誰でも実装できます（DDEX規格）。手間がかかり、多くのレーベルが自前で抱えたくない部分は、有効なERNフィードを生成し、各DSPの要件が変わるたびに最新の状態へ保つことです。

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

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

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

フィード生成は、リリースデータから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は今も2つの世代が使われています。DDEXは2025年3月1日にERN 3の全バージョンのサポートを終了しましたが、ERN 3.8.2は既存のDSP連携の中で使われ続けています。ERN 4.3.xは現行世代で、DDEXはその最新バージョンの実装を勧めています。両者に互換性はありません。フィードエンジンは、各DSPが求めるバージョンを使い分ける必要があります。

実務上のポイントはこうです。既存のERN 3連携が残り続けているのは、ERN 3から4への移行が地域データモデル全体の再構築を意味するからです。ERN 4ではDetailsByTerritoryブロックが廃止されています。没入型オーディオへの完全対応やPartyListによる重複排除といった新しい機能を使うには、ERN 4が必要です。使う価値のあるプロバイダーは両方に対応し、配信先ごとに適切なバージョンを選びます。LabelGridはDDEX ERN 3.8.2、4.3.0、4.3.1、4.3.2で配信します。自社のERN配信をLabelGridに取り込むDDEXインポートは、APIプランとCustom Distributionで利用できます。

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

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

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フィード生成は、リリースを標準化されたERNメッセージ、つまりリソース、リリースデータ、取引条件を運ぶNewReleaseMessageへと変換し、DSPがそれを自動的に取り込みます。今も使われているバージョンは2つあります。DDEXのサポートが2025年3月に終了した旧バージョンのERN 3.8.2と、より軽量で没入型オーディオに完全対応した現行のERN 4.3.xです。優れたプロバイダーは両方に対応し、配信前に検証し、DSPの仕様変更を追跡します。自前のエンジン構築は継続的な保守の負担になります。ほぼすべての事業者にとって、生成から検証、配信までフィードを一手に引き受けるプロバイダーのほうが賢明な選択です。LabelGridはレーベルとディストリビューター向けにDDEX配信を担い、対応する4つのERNバージョンすべてで、APIアクセスと直接契約カタログ向けのSOBOにも対応します。