Console

Settings

Sign out

Notifications

Alexa

Amazonアプリストア

Ring

AWS

ドキュメント

Support

My Cases

Console

Fire OSドキュメント

ホーム

開発

テスト

公開

収益化

ユーザーエンゲージメント

デバイスの仕様

リソース

EMBERのベストプラクティス

重要： カタログ統合を利用できるのは一部のパートナーに限られています。

このページでは、カタログ統合に関して、初期計画から継続的なメンテナンスに至るまでの推奨プラクティスを説明します。これらのガイドラインに従うと、よくある問題を回避し、コンテンツマッチングの精度を高め、カタログの健全性を保つことができます。

計画とセットアップ

このセクションでは、カタログ統合を成功させるための初期手順について説明します。

統合のタイムラインを理解する

カタログ統合には慎重な計画が必要です。初期セットアップに2～4週間を確保してください。

第1週 - AWSアカウントのセットアップ、S3バケットのプロビジョニング、IAMロールの構成。
第2週 - テストカタログの作成、検証、ステージング環境への最初の送信。
第3～4週 - エラーの解決、本番環境への展開、モニタリング。

専用リソースを割り当てる

カタログ統合のプロセスには、メタデータの変換、自動化スクリプトの作成、継続的なモニタリングが含まれます。チームが以下の作業に対応できるようにしてください。

コンテンツメタデータのエクスポートとEnhanced Metadata Bridge for Entertainment Resources（EMBER）形式への変換。
カタログの生成とアップロードを自動化するスクリプトの作成。
カタログの検証、デバイスでのテスト、統合レポートのモニタリング。
AWS CLIの構成、認証情報の管理、cronジョブの設定。

ステージング環境から始める

本番環境に送信する前に、必ずステージング環境で検証してください。大まかな手順は次のとおりです。

テストカタログをstaging/ディレクトリに送信します。
Amazonの担当者に依頼して、テストデバイスを許可リストに追加します。
デバイスでコンテンツが正しく表示されることを確認します。
本番環境に展開する前に、すべてのエラーと警告を修正します。

アップロード戦略

カタログをどのようにアップロードするかによって、処理速度、リスク、信頼性に影響が生じます。

完全なカタログの置き換えは控えめに使用する

カタログを完全に再構築するには、マニフェストファイルでtype="CATALOG_FULL"を使用します。この方法では、古いエンティティや参照されていないエンティティを削除できますが、カタログに含まれていないコンテンツはすべて削除されるため、リスクが高くなります。完全な置き換えはピーク以外の時間帯にスケジュールしてください。

定期的な変更にはインクリメンタル更新を使用する

毎日または毎週の更新には、マニフェストファイルでtype="CATALOG_UPDATE"を使用します。インクリメンタル更新では、変更されたエンティティ（新規、更新、削除）のみが更新の対象となり、変更のないコンテンツは保持されるため、処理が速く、リスクは低くなります。

カタログレベルのアクションを理解する

マニフェストレベルのtype（CATALOG_FULLとCATALOG_UPDATE）のほかに、各カタログ要素には、そのコンテンツがどのように処理されるかを制御するaction属性があります。

upsert（デフォルト）- 新しいエンティティを追加し、既存のエンティティを更新します。それ以外はすべて保持されます。インクリメンタル更新にはこれを使用します。
replace - カタログ内の既存のエンティティをすべて削除し、送信されたコンテンツで置き換えます。ファイルに含まれていないエンティティはすべて削除されるため、使用には注意が必要です。

カタログ全体を置き換えずに個々のエンティティを削除するには、upsert更新の中でDelete要素を使用します。階層型のコンテンツを削除するときは、親よりも先に子を削除します（シーズンの前にエピソード、シリーズの前にシーズン）。

削除時のバージョン管理動作と例を含む詳細なリファレンスについては、削除とカタログアクションを参照してください。

アップロードプロセスを自動化する

手動アップロードではミスが発生しやすいため、次の手順を実行する自動スクリプトを作成することをお勧めします。

コンテンツ管理システム（CMS）のデータベースからカタログを生成します。
XSDに照らして自動的に検証します。
ファイルを圧縮します。
IAMロールを引き受け、認証情報を更新します。
適切な順序でアップロードします。
cronジョブを通じてスケジュールします（毎日午前2時を推奨）。

既知の正常なカタログにロールバックする

カタログを送信した結果、コンテンツの欠落、リレーションシップの破損、メタデータの誤りなどのエラーが発生した場合は、最後に検証されたカタログとの完全な置き換えを送信することで、以前の正常な状態に戻すことができます。

カタログをロールバックするには、次の手順に従います。

アーカイブから、最後に検証されたカタログバージョンを特定します。
マニフェストファイルを更新して、type="CATALOG_FULL"を指定すると共にバージョン番号を大きくします。
アーカイブ内のカタログファイルをS3パスに送信します。
統合レポートをモニタリングして、ロールバックがエラーなく処理されたことを確認します。

ロールバックの信頼性を高めるには、次のプラクティスに従ってください。

カタログが正常に統合されたら、そのたびにカタログをアーカイブします。このとき、カタログのタイムスタンプとバージョン番号がわかるようにします。
アーカイブは一貫した場所に保存します。
再送信する前に、アーカイブ済みのカタログをXSDに照らして検証します。
必要時に回復できるように、直近3世代分の正常なカタログを保持しておきます。

ヒント： アップロードパイプラインの一部として、アーカイブの手順を自動化することをお勧めします。問題のない統合レポートを受け取ったら、送信したファイルをアーカイブの場所にコピーします。

モニタリングとメンテナンス

定期的なモニタリングにより、問題を早期に発見し、カタログの健全性を保つことができます。

統合レポートを毎日モニタリングする

統合レポートのEメールに登録し、次の作業を行います。

エラーの数が0であることを確認します。
警告を確認し、修正を計画します。
アイテムの数が想定どおりであることを確認します。
スキップされたアイテムを追跡します。

カタログ概要レポートを毎週確認する

日単位のカタログ概要レポートでは、カタログの健全性を包括的に把握できます。次の点を確認してください。

現在のすべてのエラーと警告
最適化のための推奨事項
コンテンツの品質指標
前週比のトレンド

アップロード頻度の要件を維持する

求められる最小要件は次のとおりです。

インクリメンタル更新： 少なくとも7日ごと。この要件が満たされない場合、コンテンツの順位が下がる可能性があります。
完全なカタログの更新： 少なくとも30日ごと。この要件が満たされない場合、カタログが停止される可能性があります。

推奨される頻度は次のとおりです。

毎日： 新しいリリース、配信状況の変更、スケジュールの更新
毎週： メタデータの修正、画像の更新
毎月： 完全な検証とクリーンアップ

ファイルの編成

カタログファイルの編成に一貫性を持たせると、送信内容の管理とデバッグを行いやすくなります。

大きいカタログを複数のファイルに分割する

単一の大きいXMLファイルを作成することは避けます。代わりに、カタログをタイプまたは更新頻度ごとに分割します。

カタログタイプ別：movies.xml、tv-shows.xml、schedules.xml
更新頻度別：daily-updates.xml、stable-content.xml

各圧縮ファイルは100MB未満に保ち、送信データの合計は圧縮した状態で10GB未満にしてください。

注：複数のファイルを使用してカタログを送信する場合は、各XMLファイルにDataCollectionsルート要素が含まれ、その中の要素が適切な親階層の下に編成されている必要があります。統合システムは、複数のファイルからコンテンツをマージします。

一貫性のあるファイル名を使用する

追跡用にファイル名にタイムスタンプを含めます。たとえば次のようにします。

catalog-movies-20260425-140000.xml.zst
catalog-schedules-20260425-140000.xml.zst
manifest-20260425-140000.manifest

一貫性のある名前を使用すると、誤って上書きされるのを防止できるほか、わかりやすい送信履歴が残り、必要に応じてロールバックすることが可能になります。

複数のカタログを論理的に編成する

同じタイプのカタログを複数使用する場合は、趣旨に沿って編成します。

ORIGINAL_CONTENT - オリジナル作品。
LICENSED_CONTENT - サードパーティからライセンスを受けたコンテンツ。
LOCAL_STATIONS - ローカル放送系列局。
EXTERNAL_STATIONS - TMSまたはGracenote Video Data（GVD）を通じて参照されるステーション。

IDの管理

コンテンツの追跡とカタログの相互参照には、一貫性のある永続的なIDが不可欠です。

永続的で意味のあるIDを使用する

IDは、作成後に変更することはできません。説明的で永続的な識別子を選択してください。

以下は良い例です。

id="MOVIE_AVENGERS_2024"
id="SERIES_FRIENDS"
id="NFL_2025_W01_SEA_SF"

以下は悪い例です。

id="Movie 123"（スペースが含まれている）
id="temp_id"（永続的でない）
id="12345"（説明的でない）

IDの命名規則を制定する

カタログの作成を始める前に、IDのパターンを文書化します。Amazonでは、次の表に示すパターンを推奨しています。

エンティティタイプ	パターン	例
映画	`MOVIE_{タイトル}_{年}`	`MOVIE_AVENGERS_2024`
TVシリーズ	`SERIES_{タイトル}`	`SERIES_FRIENDS`
TVシーズン	`{シリーズのID}_S{##}`	`SERIES_FRIENDS_S01`
TVエピソード	`{シーズンのID}_E{##}`	`SERIES_FRIENDS_S01_E01`
スポーツイベント	`{リーグ}_{シーズン}_{週}_{チーム}`	`NFL_2025_W01_SEA_SF`
ステーション	`{コールサイン}_{ネットワーク}_{地域}`	`KIRO_CBS_SEATTLE`

IDを再利用しない

コンテンツを削除したら、そのIDを永続的に廃止してください。別のコンテンツにIDを再利用しないでください。リメイクやリブートには新しいIDを作成します。IDのレジストリまたはデータベースを構築して維持することをお勧めします。

バージョン管理

バージョンを付けることで、システムがカタログのインクリメンタル更新をどのように処理するかを制御し、順序どおりでない上書きを防ぎます。

バージョン付けの戦略を選択する

一般的なバージョン付けの方法には、次の3つのアプローチがあります。

連番（シンプル）

<Movie id="MOVIE_123" version="1">   <!-- 初期バージョン -->
<Movie id="MOVIE_123" version="2">   <!-- 初回の更新 -->
<Movie id="MOVIE_123" version="3">   <!-- 2回目の更新 -->

タイムスタンプ（機械的）

<Movie id="MOVIE_123" version="1713622889">   <!-- Unixエポック -->
<Movie id="MOVIE_123" version="1713622950">   <!-- 61秒後 -->

ハイブリッド（判読可能ながら機械的）

<Movie id="MOVIE_123" version="20260425001">   <!-- 日付＋連番 -->
<Movie id="MOVIE_123" version="20260425002">

システムでバージョンを追跡する

次の方針に従って、エンティティごとにバージョン履歴を保持します。

各エンティティの現在のバージョンをデータベースに保存します。
更新のたびにバージョン番号を大きくします。
現在のバージョンと同じかそれ未満のバージョンは送信しないようにします。

コンテンツメタデータ

このセクションでは、コンテンツマッチングとユーザーエクスペリエンスに最も大きく影響する、メタデータフィールドに関する推奨プラクティスを示します。

タイトルと説明

コンテンツのタイトルが地域によって異なる場合は、地域固有のタイトルのバリエーションを提供します。

<Titles>
    <Title language="en" default="true">The Avengers</Title>
    <Title language="en" territories="GB">Marvel Avengers Assemble</Title>
    <Title language="es">Los Vengadores</Title>
    <Title language="fr">Les Vengeurs</Title>
</Titles>

興味をそそる説明とあらすじを記述してください。

Descriptions（50～200文字）：簡潔で魅力的な要約を記述します。
Synopses（200～500文字）：プロットの詳細を、重要な展開や結末を明かさずに記述します。
正しい文法とスペルを使用します。
マーケティング上の誇張表現は避けます。
プロットの主要な展開を明かさないようにします。

画像

次の要件を満たす高品質の画像を使用します。

最小解像度： HD（1920x1080）。
推奨：将来に備えて4K（3840x2160）。
最大ファイルサイズ： 10MB。
プロレベルの品質で、透かしやノイズなどがないこと。

EMBERの画像に記載されている、画像カテゴリーごとのガイドラインに従ってください。

Amazonの統合システムが画像を取得できるように、すべての画像URLが一般からアクセス可能であることを確認してください。

パブリックHTTPS URLを使用する必要があります。
有効なSSL証明書が必要です。
認証やヘッダーは不要です。
URLがHTTP 200を返すことをテストします。
画像は24時間いつでも取得できる必要があります。

外部ID

外部IDは主要なマッチングメカニズムとして機能します。利用可能なすべての外部IDを含めてください。

<ExternalIds>
    <ExternalId scheme="imdb">tt0076759</ExternalId>
    <ExternalId scheme="tms">MV123456789012</ExternalId>
    <ExternalId scheme="eidr">10.5240/XXXX</ExternalId>
    <ExternalId scheme="asin">B09ABC123</ExternalId>
</ExternalIds>

外部IDがない場合、コンテンツは次のような影響を受ける可能性があります。

既存のエントリと統合されずに重複して表示されます。
検索ランキングが低くなります。
サービス間のおすすめ機能の対象から外されます。

必ず標準のIDスキームを使用してください。サポートされているすべてのIDスキームの一覧については、外部IDを参照してください。

ジャンルとキーワード

可能であれば、EMBERのジャンルスキームを使用します。

<Genres>
    <!-- ember_genreスキームを優先 -->
    <Genre scheme="ember_genre">ember_genre_action</Genre>
    <Genre scheme="ember_genre">ember_genre_thriller</Genre>

    <!-- フォールバックとして自由形式を使用 -->
    <Genre language="en">action</Genre>
</Genres>

ジャンルは1つの番組あたり2～4個に制限します。ジャンルが多すぎると、分類の意味が薄れてしまいます。可能な場合はサブジャンルを使用してください。

シリーズ名、キャラクター名、俳優名、代替タイトル、一般的な検索語句に関連するキーワードを含めます。

<Keywords>
    <Keyword language="en">avengers</Keyword>
    <Keyword language="en">marvel</Keyword>
    <Keyword language="en">superhero</Keyword>
    <Keyword language="en">iron man</Keyword>
</Keywords>

キーワードを過剰に追加したり、無関係なキーワードを追加したりしないでください。「映画」、「ビデオ」、「視聴」のような一般的な語句は避けます。タイトルの語句を繰り返さないようにします。量よりも質を重視してください。

TVコンテンツの階層

TVコンテンツでは、シリーズ、シーズン、エピソード間に適切なリレーションシップを維持するために、特定の作成順序に従う必要があります。

エンティティを正しい順序で作成する

TVコンテンツは常に、 TVSeries、TVSeason、TVEpisodeの順に作成します。

<!-- 手順1： シリーズを作成する -->
<TVSeries id="SERIES_1" version="1">
    <Titles>...</Titles>
</TVSeries>

<!-- 手順2： シーズンを作成する（シリーズを参照する） -->
<TVSeason id="SERIES_1_S01" version="1">
    <Titles>...</Titles>
    <Relationships>
        <isSeasonOfSeries programRef="SERIES_1" seasonNum="1"/>
    </Relationships>
</TVSeason>

<!-- 手順3： エピソードを作成する（シーズンとシリーズを参照する） -->
<TVEpisode id="SERIES_1_S01E01" version="1">
    <Titles>...</Titles>
    <Relationships>
        <isEpisodeOfSeason programRef="SERIES_1_S01" episodeNum="1"/>
        <isEpisodeOfSeries programRef="SERIES_1" episodeNum="1"/>
    </Relationships>
</TVEpisode>

エピソードには2つのリレーションシップを含める

各TVEpisodeには、isEpisodeOfSeasonとisEpisodeOfSeriesの両方を含めます。これにより、柔軟なナビゲーションが可能になり、シリーズレベルとシーズンレベルの両方からの閲覧がサポートされます。

レーティングとコンテンツの妥当性

コンテンツレーティングは、ユーザーが視聴判断を下すうえで役立つ情報となります。コンテンツを配信する地域ごとに、その地域固有のレーティングを提供してください。

地域固有のレーティングを提供する

各地域に対応する適切なレーティングシステムと認定を含めてください。

<Ratings>
    <Rating system="MPAA" certification="PG-13" territories="US">
        <Descriptors>
            <Descriptor code="V">Violence and action sequences</Descriptor>
        </Descriptors>
    </Rating>
    <Rating system="BBFC" certification="12A" territories="GB"/>
    <Rating system="FSK" certification="FSK 12" territories="DE"/>
</Ratings>

記述子を使用して透明性を高める

保護者が十分な情報に基づいて判断できるように、理由コード（暴力描写にはV、不適切な言葉遣いにはL、性的コンテンツにはS）、明確な記述子テキスト、公式なレーティング制度の言語を含めてください。

ライブイベントとスケジュール

ライブイベントは、配信モデルに応じて以下の2つの方法で表すことができます。

アプリベースのライブストリーミングにはProgramAiringOffersを使用する

イベントがアプリで独占的にライブストリーミングされる場合は、ProgramAiringOffersを使用します。このモデルでは、ユーザーは（放送チャンネルではなく）アプリを通じてイベントにアクセスするため、Airing要素にstationRef属性はありません。

例として、アプリ限定のNFL試合の配信、サービス限定のコンサートのライブストリーム、ペイパービュー方式のボクシング試合、eスポーツトーナメント、ストリーミングサービスでの劇場公演の配信などがあります。

リニア放送にはScheduleCatalogを使用する

イベントがTVステーションまたはチャンネルで放送される場合は、ScheduleCatalogを使用します。このモデルでは、該当するステーションにチャンネルを合わせればだれでもイベントを視聴でき、Airing要素にはstationRef属性が含まれます。イベントは24時間の放送スケジュールに表示されます。

例として、CBSでのNFL試合の放送、NBCでのオリンピック放送、ABCでの授賞式の放送などがあります。

該当する場合は両方を使用する

多くのパートナーは、同じイベントをリニアTVとストリーミングアプリの両方で放送します。この場合、次のように設定します。

SportsEvent番組を1つ作成します。
リニア放送用に、ScheduleCatalogでその番組を参照します。
アプリでのストリーミング用に、ProgramAiringOffersでその番組を参照します。
参照ごとに別々のエンタイトルメント、ブラックアウトルール、品質レベルを設定できます。

ライブイベントをVODリプレイに再利用する

ライブイベントの終了後、同じ番組エンティティを使用してそのイベントをオンデマンドで提供できます。ライブからオンデマンドにシームレスに移行するには、同じカタログ更新でProgramAiringOffersとProgramOffersの両方を送信します。

イベント中（一定期間のライブストリーミング）

<ProgramAiringOffers id="AIRING_OFFER_CONCERT_2026" version="1" programRef="CONCERT_2026">
    <ProgramAiringOffer start="2026-06-15T20:00:00Z"
                        end="2026-06-15T23:00:00Z">
        <Airing id="AIRING_CONCERT_2026"
                startTime="2026-06-15T20:00:00Z"
                duration="PT3H"
                programRef="CONCERT_2026">
            <Live/>
            <New/>
        </Airing>
        <Entitlements>
            <Entitlement type="subscription"/>
        </Entitlements>
        <LaunchTargets>
            <LaunchTarget type="FIRETV">
                amzn://apps/watch?id=CONCERT_2026&amp;live=true
            </LaunchTarget>
        </LaunchTargets>
    </ProgramAiringOffer>
</ProgramAiringOffers>

イベント終了後（VODリプレイを無期限に提供）

<ProgramOffers id="OFFER_CONCERT_2026" version="1" programRef="CONCERT_2026">
    <ProgramOffer>
        <Entitlements>
            <Entitlement type="subscription"/>
        </Entitlements>
        <VideoResolutions>
            <VideoResolution>4K</VideoResolution>
        </VideoResolutions>
        <LaunchTargets>
            <LaunchTarget type="FIRETV">
                amzn://apps/watch?id=CONCERT_2026&amp;replay=true
            </LaunchTarget>
        </LaunchTargets>
    </ProgramOffer>
</ProgramOffers>

VODリプレイでは見逃し視聴が可能で、早戻し機能と一時停止機能を使用でき、時間的制約もありません。また、さまざまな価格帯を通じて収益化できるため、コンテンツの価値が広がります。

リニアカタログ

リニア放送コンテンツ（TVステーションや無料広告型テレビ（FAST）チャンネル）を配信する場合、Amazonでは、TMSまたはGracenoteのステーションIDを含むExternalStation参照を使用することをお勧めします。

完全な定義のStation要素は、ローカル作品やカスタムFASTチャンネルなど、外部システムでは利用できないオリジナルコンテンツがある場合にのみ使用します。Station要素を使用して完全な定義のステーションを作成するときは、該当するスケジュール、番組、オファー、ポリシーを含める必要があります。

外部ステーション参照を使用することには、次のようなメリットがあります。

番組メタデータが不要 - 既に外部システムに番組の詳細がすべて含まれています。
スケジュールの送信が不要 - TMSまたはGracenoteからスケジュールデータが提供されます。
自動更新 - 番組とスケジュールの変更は外部プロバイダーによって処理されます。
メンテナンスの軽減 - 開発者側で維持する必要があるのは、StationOffers（アクセスとエンタイトルメント）だけです。
迅速な統合 - ステーションIDとアクセスルールを送信すれば完了します。何千もの番組を送信する必要はありません。

開発者は以下を提供します。

TMS IDまたはGVD IDを含むExternalStation要素
StationOffers（エンタイトルメント、地理的制限）

以下は外部プロバイダーによって処理されます。

すべての番組メタデータ（タイトル、説明、画像）
完全な放送スケジュール（24時間、毎日更新）
番組のリレーションシップとシリーズの階層
レーティングとコンテンツアドバイザリー

EMBERカタログ統合の概要 - カタログ統合プロセスの概要
EMBER仕様の概要 - カタログタイプ、中核的な概念、データ型の説明を含むスキーマリファレンス
EMBERの例 - 一般的なカタログのシナリオに基づくXMLサンプル
すべてのEMBER要素 - すべての要素のディレクトリ

Last updated: 2026年5月28日