Amazon Developer

Console

as

Settings
Sign out
Notifications
Alexa
Amazonアプリストア
Ring
AWS
ドキュメント
Support
Contact Us
My Cases

Console

as

開発
テスト
公開
収益化
ユーザーエンゲージメント
デバイスの仕様
リソース

EMBERの例

EMBERの例

このページでは、Enhanced Metadata Bridge for Entertainment Resources（EMBER）形式を使用して、一般的な統合シナリオに対応する完全なカタログの例を提供します。ポリシーや番組からオファーまで、それぞれの例でカタログ全体の構造を詳しく示します。

例1： VODカタログ

この例では、映画やTVシリーズを含むストリーミングサービスのビデオオンデマンド（VOD）カタログを作成する方法を示します。コンテンツは、無料利用枠（広告あり）とプレミアム価格帯（4K、広告なし）を通じて提供されます。

VODカタログの大まかな作成手順は次のとおりです。

  1. ProgramCatalogで、映画やTVシリーズなどの番組要素を定義します。
  2. OfferCatalogで、番組のオファーを定義します。
  3. PolicyCatalogで、定期購入価格帯のエンタイトルメントポリシーを定義します。

VODにおける重要ポイント

  • 価格帯によって属性が異なる場合（たとえば、ビデオ解像度が異なる場合）は、価格帯ごとに個別のProgramOffersを作成します。
  • アプリ内のコンテンツへのディープリンクを提供するには、LaunchTargetを使用します。アプリでランチャーの統合が完了していて、Amazonとの間でディープリンクパターンが確立している場合は、LaunchTargetをスキップできます。その場合、Amazonはディープリンクパターンを使用し、カタログから取得した番組IDを適用して、アプリへのコンテンツ固有のディープリンクを作成します。
  • プレミアムレベルには通常、4K、HDR、Dolby Atmosが含まれます。
  • 必ず外部IDを含め、特にIMDbを参照します。

例2： ライブスポーツイベントカタログ

この例では、アプリでライブストリーミングされるNFL試合（Seattle Seahawks対San Francisco 49ers）のカタログを作成する方法を示します。この試合では、ホームチームのマーケットにブラックアウト制限があります。また、定期購入型のスポーツパッケージが必要です。

次の表は、アプリベースのライブストリーミングとリニア放送の違いをまとめたものです。

機能 アプリベースのライブストリーミング リニア放送
カタログ要素 ProgramCatalog内のSportsEvent
OfferCatalog内のProgramAiringOffers
PolicyCatalog内のRegionPolicyとEntitlementPolicy		 ProgramCatalog内のSportsEvent
ScheduleCatalog内のSchedule
StationCatalog内のStation
OfferCatalog内のStationOffers
PolicyCatalog内のRegionPolicyとEntitlementPolicy
アクセスモデル アプリ固有のエンタイトルメントが必要 ステーションにチャンネルを合わせればだれでも利用可能
提供状況 一定期間（開始から終了まで） 特定の時刻に特定のチャンネルで放送
例 アプリで独占配信されるNFL試合、コンサートのライブストリーム、ペイパービュー方式のイベント CBSのNFLの試合、地方系列局のニュース（例4を参照）

ライブイベントカタログの大まかな作成手順は次のとおりです。

  1. ProgramCatalogで、スポーツイベント番組またはイベントを定義します。
  2. OfferCatalogで、番組のオファーを定義します。
  3. PolicyCatalogで、ブラックアウト対象エリア用の地域ポリシーと、定期購入型スポーツパッケージ用のエンタイトルメントポリシーを定義します。

ライブスポーツにおける重要ポイント

チーム、リーグ、会場、キックオフ時刻など、詳細なスポーツメタデータを含めます。次のベストプラクティスに従ってください。

  • スポーツには公式連盟による名称を使用します。たとえば、「Football」ではなく「American Football」です。
  • homeTeam="true"を1つのチームにのみ設定します。
  • EventDateTimeは実際のキックオフ時刻に設定します。放送の開始時刻ではありません。
  • Venueには完全な住所を含めます。
  • アナウンサーや解説者を追加するには、Creditを使用します。

PolicyCatalogで郵便番号を設定して、ブラックアウトルールを実装します。オファーに複数のGeoRestriction要素が含まれている場合は、ANDロジックが使用されます。たとえば、この例のイベントはシアトルとサンフランシスコでブロックされます。

ライブからオンデマンドにシームレスに移行するには、同じカタログ更新でライブオファーとリプレイオファーの両方を送信します。

ライブイベントオファー：

  • ProgramAiringOffersを使用します（ProgramOffersではありません）。
  • start属性とend属性は、試合前から試合後までの提供期間を定義します。オファーにはこの期間内にのみアクセスできます。
  • 参照ではなく、完全なAiring要素を含めます。

VODリプレイオファー：

例3： 外部ステーションカタログ

この例では、ステーション定義を一から作成する代わりに、Gracenote Video Data（GVD）またはTribune Media Services（TMS）から外部ステーションのメタデータを参照する方法を示します。このアプローチは、複数のチャンネルを提供し、GracenoteのステーションIDを持つケーブルプロバイダーや衛星プロバイダーに最適です。

外部ステーションカタログの大まかな作成手順は次のとおりです。

  1. StationCatalogで、GVDまたはTMSからステーションを参照するExternalStationを定義します。
  2. OfferCatalogで、ステーションのオファーを定義します。
  3. PolicyCatalogで、地域ポリシーとエンタイトルメントポリシーを使用してサービスエリアと定期購入価格帯を定義します。

外部ステーションにおける重要ポイント

外部ステーションでは、GVDやTMSによって管理される専門的なメタデータを利用できます。ステーションの定義を自分で作成したり管理したりする必要はありません。これにより、すべてのサービスとデバイスで名前の一貫性が保たれます。

TitlesとImagesの内部ではデータをオーバーライドできます。ただし、可能な限り外部データを使用し、オーバーライドするのは必要時だけにしてください。オーバーライドする理由には、次のようなものがあります。

  • ロゴやタイトルスタイルなどのカスタムブランディング
  • マーケティングまたはプロモーションの目的
  • 外部データに存在しない言語へのローカリゼーション

その他のデータ（CallSign、Descriptions、Genresに含まれているデータなど）はオーバーライドできません。これらのメタデータは外部システムから継承され、外部プロバイダーがレコードを更新すると自動的に更新されます。

定期購入価格帯がある場合は、EntitlementPolicyを使用してパッケージレベルを定義し、StationOffersでそれらを参照します。

次の点に留意してください。

  • 外部ステーションを参照するには、Station要素ではなくExternalStationを使用する必要があります。
  • 最初の子要素はExternalIdにする必要があります（XSDの順序要件）。
  • ExternalStationでは、tmsとgvdのスキームのみがサポートされます。

例4： 完全なリニアステーションカタログ

この例では、シアトルにあるCBSの地方系列局（KIRO 7）を、24時間放送スケジュール、番組メタデータ、ステーションの情報、ローカルケーブルプロバイダー向けのチャンネルラインナップと統合する方法を示します。

リニアステーションカタログの大まかな作成手順は次のとおりです。

  1. 放送される番組を定義します。

    リニア放送ステーションで放送されるコンテンツのタイプは多岐にわたります。映画、TVシリーズとその階層関係、スポーツイベント、ローカル番組など、すべての番組タイプをカタログに含めます。

    一般的な番組タイプの詳細は次のとおりです。

    • Movie： TV放送で放映される劇場公開作品。
    • TVSeries/TVSeason/TVEpisode： ネットワークのゴールデンタイム番組とその階層関係。
    • SportsEvent： 地域のスポーツネットワークでのローカルチームの試合放送。
    • Other： ローカルニュース、インフォマーシャル（標準以外のカテゴリー）。

    サポートされる番組タイプに対応するすべての要素の一覧については、ProgramCatalogを参照してください。

  2. 毎日の放送スケジュールを作成します。

    Schedule要素を使用して、1日に放送されるすべての番組タイプを参照します。次のベストプラクティスに従ってください。

    • date属性をYYYY-MM-DD形式で含めます。
    • 時刻はすべてUTCタイムゾーンで表します。
    • リアルタイム放送の場合はLiveを使用し、初回放送または初公開の場合はNewを使用します。
    • 録画放送や再放送のコンテンツでは、Live要素とNew要素の両方を省略します。
    • 24時間全体をカバーして、未定義の時間帯や放送が重なる時間帯がないことを確認します。

  3. ステーションへのアクセスを定義します。

    StationOffers要素を作成して、ユーザーがステーションにアクセスする方法を定義します。

  4. ステーションを定義します。

    ブランディング、ネットワーク系列局、放送の詳細を含む、完全な定義のStation要素を作成します。

  5. ケーブルプロバイダー向けのチャンネルラインナップを作成します。

    LineupCatalogで、ステーションがケーブルプロバイダーのチャンネルラインナップにどのように表示されるかを定義します。

  6. 放送エリアのポリシーを定義します。

    PolicyCatalogで、郵便番号を使用して放送対象エリアを正確に定義します。

リニア放送における重要ポイント

  • ステーションを定義してから、そのステーションを参照するスケジュールを作成します。
  • スケジュールにはdate属性（YYYY-MM-DD形式）を指定し、放送日の24時間全体をカバーする必要があります。
  • 時刻はすべてUTC（Zタイムゾーン）で表す必要があります。
  • ラインナップ統合には、チャンネル番号とテクニカルトランスポートIDを含めます。
  • 郵便番号を使用して、地理的な対象範囲を正確に定義します。

Last updated: 2026年5月28日

フォローする

サポート対象デバイス

amazon_developer_logo

© 2010-2026, Amazon.com, Inc. or its affiliates. All Rights Reserved. 無断複写·転載を禁じます。

利用規約

Amazon開発者ブログ

お問い合わせ