はじめに 世の中には5Gなどのモバイル規格やTV放送、ETCなど電波を用いて無線で様々な情報を伝送する規格が存在します。過去の記事（Wi-Fi編、プライベートLTE編）では主に利用者が無線局免許を取得する必要なく電波発射が可能な無線規格を使ってみた結果をご紹介しています。ただし、無線局免許が無い利用を前提で策定された無線規格であるWi-FiやプライベートLTE（sXGP）の利用条件には制約が多く存在します。 一方で、5Gなどのモバイル規格は元々無線局免許を取得して電波を優先的に利用できる前提の無線規格のため、電波を有効利用できる様々な技術が取り込まれています。その中でも今回記事で取り

2025 年 12 月 1 日 – 12 月 5 日にラスベガスで開催された AWS re:Invent 2025 では、メディア＆エンターテインメント領域における最新の AWS 活用事例が多数紹介されました。また、2025 年 11 月 19 日 – 11 月 21 日に幕張メッセで開催された Inter BEE 2025 では、Global AI x Cloud Pavilion にて Create、Connect、Captivate の 3 つのテーマによる展示を、また DX x IP Pavilion では複数局を集約した統合クラウドマスターの展示等を行いました。 本振り返りセミナーでは、上記 2 つのイベントのハイライトを、メディア＆エンターテインメント業界のお客様向けにご紹介しました。また、AWS Black Belt Online Seminar 上でも本セミナーの 資料を公開 しています。 re:Invent & Inter BEE 2025 re:Cap メディア & エンターテインメント業界編 [ 資料 ] re:Invent 2025 re:Cap メディア＆エンターテインメント業界編 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 小南 英司 re:Invent 2025 のセッションから、メディア＆エンターテインメント業界に関連する事例を、コンテンツ制作、メディアサプライチェーン、Direct-to-Consumer、スポーツの 4 分野に分けて紹介しました。 コンテンツ制作では、Amazon MGM Studios が Amazon S3 と Amazon FSx でストレージを統合し、 Amazon EC2 上にリモート編集環境を構築することで、数週間かかっていたメディア転送時間を大幅に短縮しました。これにより処理時間の 50% 短縮と 5,000 マイル離れた遠隔地からの 1 秒未満の遅延での編集を実現しました。また、Angry Birds を制作する Rovio は、 Amazon SageMaker AI  に独自アートスタイルを学習させました。 Amazon Bedrock で全社員が使える AI ツールを構築し、背景制作時間を 80% 削減、アーティストが反復作業から解放され、クリエイティブな業務に集中できる環境を手に入れました。 メディアサプライチェーンでは、Netflix が Amazon S3 Storage Lens と Apache Iceberg を組み合わせることで、2 エクサバイト超のデータを対象にストレージ増加の早期検知とコストの完全可視化を実現し、消されず残されたままとなったアセットや設定ミスによる不要データの特定が可能になりました。ブンデスリーガは Amazon Nova を活用することで、試合終了後数分以内のレポート自動配信と動画の多言語ローカライズを実現し、制作時間を 75〜90% 削減しながらパーソナライズドコンテンツを 5 倍に増加させることができました。 Direct-to-Consumer では、Amazon Prime Video が Amazon Managed Service for Apache Flink でリアルタイムストリーム処理基盤を構築し、NASCAR 中継において燃料戦略を 5 秒以内に可視化する業界初のシステムを 8 週間で立ち上げました。5 億 3,400 万インプレッションという大規模なメディア露出を獲得しています。またマルチエージェントシステムと Amazon Bedrock を組み合わせることで、アートワーク品質評価を数日から 1 時間未満に短縮し、1,800 万人同時視聴のライブ配信でもリアルタイムの品質監視も可能にしています。Olympics.com は Amazon OpenSearch Service と RAG を活用することで 160 億エンゲージメントの処理と 100〜200 ミリ秒でのコンテンツ自動生成を実現し、マイナー競技のロングテールコンテンツを自動配信できる体制を構築しました。 スポーツでは、NBA が Amazon EKS と Apache Flink でリアルタイム処理基盤を構築することで、14 年分のテラバイト級追跡データを統合し 50 ミリ秒の遅延で統計配信を実現しました。これにより従来定量化が困難だった選手の注目度を数値化した「プレイヤーグラビティ」と呼ばれる新指標が生まれ、すでに放送で活用されています。 マルチエージェントによる制作自動化、未活用コンテンツの価値最大化、低遅延リアルタイム体験の 3 つが re:Invent 2025 のメディア＆エンターテインメント業界におけるトレンドでした。 Inter BEE 2025 re:Cap アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 金目 健二 Inter BEE 2025 の Global AI x Cloud Pavilion AWS ブースでは、Create、Connect、Captivate の 3 テーマで展示を行いました。Create では、 Amazon DCV や Amazon EC2 G6e インスタンス、 Amazon FSx for NetApp ONTAP を組み合わせたクラウドスタジオ環境や、ComfyUI、Griptape Nodes を使った生成 AI 制作ワークフローを実演しました。クラウド上に制作環境を構築することで、物理的なワークステーションに縛られず、必要な時に必要なリソースを確保して制作を進められることが可能となります。Connect では、 MediaLake による自然言語によるコンテンツ検索が可能になることで、クリエイターが必要な素材を探す時間を大幅に削減し、編集作業そのものに集中できる環境を紹介しました。また Amazon Bedrock や Amazon Nova を活用した記事制作支援ツールにより、文字起こしから多言語翻訳、SNS 動画生成までを一貫して行うことが可能となり、記事公開までの時間短縮と言語展開のコスト削減が可能となることを示しました。Captivate では、 Amazon Transcribe と Amazon Bedrock による 4 言語同時字幕翻訳や多言語ライブグラフィックスの生成により、自社コンテンツの IP を海外展開しマネタイズの幅を広げられることを紹介しました。GitHub リポジトリで公開されており、すぐにご利用いただくことが可能です。 出展者セミナーには 3 社にご登壇いただきました。株式会社毎日放送には、スポーツ中継で過去のシーンを即座に探し出して再生するクラウドリプレイシステムを紹介いただきました。従来、3 時間超の試合映像から手動でシーンを探す作業にはベテランの経験と膨大な時間が必要でしたが、AWS マネージドサービスと生成 AI を活用することで、クラウドに保存された映像から必要なシーンをわずか 10 秒で送出準備できる仕組みを内製開発しました。株式会社 TBS テレビは、生放送やイベント配信が一方通行になりがちで視聴者の参加感が不足するという課題を解決するために、 Amazon Interactive Video Service (Amazon IVS) と Amazon Nova を活用した双方向型配信プラットフォーム「 Kustamie 」を開発しました。0.3 秒の超低遅延配信と最大 12 視点のマルチアングル配信に加え、不適切な発言を 1.6 秒で検知するチャットモデレーションにより、安心安全でインタラクティブなライブ配信環境を実現しています。株式会社 IMAGICA GROUP のエンターテインメントメディアサービスは、制作需要の波に対応するリソース確保や設備資産に縛られない運用を目指し、Amazon DCV や Amazon FSx、 AWS Deadline Cloud でポストプロダクションの編集環境をクラウドに移行しました。編集開始までのリードタイムを大幅に削減可能で、オンプレミスとの単純なコスト比較ではなく、機器投資や保守運用、バックアップなどの隠れたコストも含めて総合的に判断することが重要であるとの考え方も共有されました。 DX x IP Pavilion では、AWS 上に集約型マスターを構築することで、番組編成に従ったインフラの自動オーケストレーションと AI による集約監視を実現し、従量課金を活かして信号送出がないタイミングでのコスト削減が可能となることや、監視業務の効率化を両立できることを、国内の放送機器ソリューションを組み合わせて示しました。 おわりに 本ブログでは、メディア＆エンターテインメント業界のお客様向けに開催された re:Invent 2025 & Inter BEE 2025 振り返りセミナーの内容を紹介しました。セミナーにご参加いただいた皆さま、ご参加いただきましてありがとうございました。メディアチームでは、業界の皆様に役立つ情報を、引き続きセミナーやブログで発信してまいります。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

.table-of-contents > li > ul > li > ul { display: none; } はじめに こんにちは。データシステム部・MA推薦ブロックの伊藤（ @rabbit_x86 ）です。私たちのチームでは、メール配信などのマーケティングオートメーション（MA）に関する推薦システムを開発・運用しています。 従来、ZOZOTOWNのMA施策における推薦システムでは、 開発リードタイムと推薦精度のトレードオフ が課題でした。この課題を解決するため、ユーザーとアイテムをベクトルで表現したEmbeddingとBigQuery Vector Searchを活用し、施策を横断して利用可能な 汎用推薦システム を開発しました。本システムにより、開発リードタイムを 約1/3 に短縮し、A/Bテストで 配信当たりのMA経由流入数・購入数の改善 を達成しました。 本記事では、このシステムの設計思想・アーキテクチャ・構築時の技術的な課題と工夫、そして実際の事例を紹介します。 目次 はじめに 目次 背景と課題 従来の推薦アプローチとそのトレードオフ 機械学習ベースの開発リードタイム ルールベースによる推薦の限界 システム要件 アプローチ 前提知識：EmbeddingとEmbedding基盤 汎用推薦システム 全体構成 1. セグメント抽出 2. Embedding取得 3. Vector Index作成 4. Vector Search 5. スコアブースト・フィルタリング 6. 評価・バリデーション 技術的な課題と工夫 Vector Indexの非同期構築への対処 Vector Searchのスロット消費問題 運用事例 開発リードタイムの短縮 推薦精度の向上 まとめ 今後の展望 最後に 背景と課題 従来の推薦アプローチとそのトレードオフ MA施策では、対象ユーザー（ユーザーセグメント）と対象アイテム（アイテムセグメント）を施策ごとに定義し、パーソナライズされた商品を提供しています。その推薦システムは、「ルールベース」と「機械学習ベース」の2つのアプローチで構築されています。ルールベースは閲覧したカテゴリの商品を推薦するなど、行動ログに基づくルールでスコアリングするアプローチです。機械学習ベースは行動ログを活用しつつ、モデルが学習した潜在的な嗜好をもとに推薦するアプローチです。 これらのアプローチには精度と開発リードタイムのトレードオフが存在し、ルールベースは 高速だが推薦精度が低く 、機械学習ベースは 精度が高い一方で開発リードタイムが長い という課題がありました。 ルールベース 機械学習ベース ロジック 閲覧履歴・お気に入りなどの行動ログに基づくヒューリスティクス 専用の推薦モデルが学習した潜在的な嗜好に基づくスコアリング 開発リードタイム 短い 長い 精度 低い 高い 機械学習ベースの開発リードタイム 機械学習ベースの推薦にはモデルを実装する必要があり、施策ごとに以下の一連の開発工程を繰り返します。 工程 所要期間 探索的データ分析 約2週間 モデルの設計・実装 約3週間 パイプラインの設計・実装 約2週間 実験・評価・チューニング 約3週間 この結果、 1施策あたり約10週間の開発リードタイム が必要となり、仮説検証のサイクルが遅くなっていました。 ルールベースによる推薦の限界 一方、ルールベースのロジックでは、閲覧履歴やお気に入りブランドなど、ユーザーの顕在的な嗜好に基づく推薦が中心です。たとえば、「ブランドAを閲覧したユーザーにブランドAの値下げ商品を推薦する」といったルールなどです。こうしたルールは設計が容易な反面、ユーザーが触れた商品のみを推薦し、ユーザーの潜在的な嗜好を考慮した推薦ができないという課題がありました。 システム要件 そこで、 高速なモデル構築と高い推薦精度を両立 する仕組みが必要でした。 要件をまとめると以下のとおりです。 要件 詳細 高速な推薦システム構築 推薦システムを短期間で構築できること 高い推薦精度 ユーザーの潜在的な嗜好を捉えた推薦ができること アプローチ 上記の要件を満たすため、社内のEmbedding基盤とBigQuery Vector Searchを活用した汎用推薦システムを開発しました。 前提知識：EmbeddingとEmbedding基盤 Embeddingとは、データを固定長のベクトルとして表現する手法です。社内のEmbedding基盤では、ユーザーの行動履歴をもとにTwo-Towerモデルを使い、ユーザーとアイテムの類似度が意味を持つように共通の次元数の埋め込み空間へそれぞれエンコードします。ベクトル間のコサイン類似度を計算することで、ユーザーの潜在的な嗜好に近いアイテムを特定できます。 Embedding基盤については、推薦基盤ブロックで執筆した以下の記事で詳しく紹介しています。 techblog.zozo.com 汎用推薦システム 本システムは1つのモデルで複数の施策に対応できる汎用的な仕組みです。セグメントを定義してEmbeddingを抽出し、BigQuery Vector Searchで類似度を計算することで、パーソナライズされた推薦結果を生成します。従来必要だった 特徴量作成やモデル学習が不要 になるため、開発リードタイムを短縮できます。 さらに、Embeddingを利用することで、ルールベースでは捉えられなかったユーザーの潜在的な嗜好を反映した 高い推薦精度 を実現します。施策の目的に応じて関連スコアの調整やフィルタリングなどの後処理も適用でき、細かなチューニングにも対応できます。 全体構成 本システムは、社内のMLパイプライン基盤であるVertex AI Pipelinesで実行されます。 パイプラインの主要ステップを以下の表にまとめます。 ステップ 処理内容 実行環境 1. セグメント抽出 ユーザーセグメント・アイテムセグメントをSQLで抽出 BigQuery 2. Embedding取得 セグメントに対応するEmbeddingをEmbedding基盤から取得 BigQuery 3. Vector Index作成 アイテムEmbeddingにTREE_AHインデックスを作成し、完了まで待機 BigQuery 4. Vector Search ユーザーEmbedding × アイテムEmbeddingの関連スコアを算出 BigQuery 5. スコアブースト・フィルタリング 関連スコアのブースト・ペナルティによるリランキング BigQuery 6. 評価・バリデーション 定量評価（Vertex AI Experiments）、ポリシーチェック BigQuery / Vertex AI 1. セグメント抽出 施策ごとに定義されたSQLクエリで、対象ユーザーと対象アイテムを抽出します。たとえば、「過去30日以内にアクティブなユーザー」や「特定カテゴリの新着アイテム」などです。このSQLを差し替えるだけで、さまざまな施策へ対応できる設計です。 2. Embedding取得 Embedding基盤から、抽出したユーザー・アイテムに対応するEmbeddingを取得します。 3. Vector Index作成 Vector Searchの高速化のため、アイテムEmbeddingテーブルへ CREATE VECTOR INDEX でインデックスを作成します。本システムでは大規模バッチ向けの TREE_AH （GoogleのScaNNアルゴリズムベース）を採用しています。Vector Indexの構築にまつわる課題と対処法は、後述の「技術的な課題と工夫」で説明します。 4. Vector Search BigQueryの VECTOR_SEARCH 関数を用いてユーザーEmbeddingとアイテムEmbeddingのコサイン類似度を計算し、ユーザーごとに関連スコアの高い上位N件のアイテムを取得します。 -- Vector Searchの実行例（簡略化） SELECT query.member_id, base.product_id, distance FROM VECTOR_SEARCH( ( SELECT * FROM candidate_embeddings), -- アイテムEmbedding ' embedding ' , ( SELECT * FROM query_embeddings), -- ユーザーEmbedding ' embedding ' , top_k => 100 , distance_type => ' COSINE ' ) 5. スコアブースト・フィルタリング Vector Searchで得られた関連スコアは、そのままでは施策の目的に最適化されていません。そこで、ブーストやペナルティによるリランキングとフィルタリングを行い、最終的な推薦結果を生成します。 生成された推薦結果はBigQueryのテーブルに保存され、MAの配信システムがこのテーブルを読み込むことで連携します。 6. 評価・バリデーション パイプラインの最終ステップとして、推薦結果の品質を評価・検証します。 評価種別 内容 記録先 定量評価 NDCG、Precision、Recall等の指標を記録 Vertex AI Experiments ポリシーチェック 推薦結果がセグメント条件を満たすか、1ユーザーあたりの推薦数が閾値以上かなどを検証 BigQuery 技術的な課題と工夫 Vector Indexの非同期構築への対処 BigQueryのVector Indexは 非同期で構築 されるため、実行直後にはインデックスが利用可能になりません。インデックスが未完成の状態でVector Searchを実行すると、ブルートフォース（全件スキャン）で計算するため、実行時間とスロット消費が膨大になります。 この問題に対処するのが、全体構成図における Index完了待ち のコンポーネントです。以下のクエリで INFORMATION_SCHEMA.VECTOR_INDEXES の coverage_percentage を定期的にポーリングし、インデックス構築の完了を確認しています。 SELECT table_name, coverage_percentage FROM `{project_id}.{dataset_id}`.INFORMATION_SCHEMA.VECTOR_INDEXES WHERE table_name IN UNNEST(@expected_tables) coverage_percentage が100％に達した後、Vector Searchステップへ進むことでブルートフォース計算を回避しています。 Vector Searchのスロット消費問題 もう1つの大きな課題は、 共有スロット の大量消費による他ジョブへの影響 でした。Vector Searchはユーザーとアイテムの全組み合わせに対してコサイン類似度を計算するため、1回の実行で大量のスロットを占有します。 社内ではBigQueryのジョブを共通の容量ベースプロジェクトで実行しています。そのため、Vector SearchがBigQueryの共有スロットを圧迫すると自チームの実行時間の増大やSLO超過だけでなく、他チームのクエリ遅延・タイムアウトを引き起こすリスクがありました。 また、今回のケースではBigQueryのスキャン量が少ないという特徴がありました。そこで、 オンデマンド課金用の専用プロジェクト を用意してVector Searchのみをそのプロジェクトで実行するようにしました。オンデマンド課金はスキャン量に対して課金されるため、コストを抑えつつ共有スロットへの影響を回避し、十分な計算リソースを確保できました。 運用事例 上記の汎用推薦システムを実際のMA施策に適用し、開発スピードと推薦精度の両面で効果を検証しました。 開発リードタイムの短縮 施策ごとに約10週間かかっていた推薦システムの構築が 約3週間 で完了し、 約1/3 に短縮されました。以下の表に、従来と汎用推薦システムの工程比較を示します。 工程 従来 汎用推薦システム 探索的データ分析 約2週間 不要（Embedding基盤を利用） モデルの設計・実装 約3週間 不要（Embedding基盤を利用） パイプラインの設計・実装 約2週間 約1週間（セグメント設定と既存パイプラインの利用） 実験・評価・チューニング 約3週間 約2週間（後処理によるチューニング） Embeddingを活用することで、探索的データ分析やモデルの設計・実装が不要になりました。また、パイプラインの設計・実装についても、セグメント抽出用のSQLを変更するだけで新しい施策に対応できるため、短期間で実装できるようになりました。さらに、実験・評価・チューニングではモデルのパラメータの調整が不要であり、過去の評価コンポーネントや実験の仕組みも再利用できるため、後処理のチューニングへ集中できるようになりました。 推薦精度の向上 従来のルールベースの推薦（Control）と汎用推薦システム（Treatment）のA/Bテストを実施し、以下の結果を得ました。 指標 有意差の有無 配信当たりのMA経由流入数 有意差ありの勝ち 配信当たりのMA経由購入数 有意差ありの勝ち 配信当たりのMA経由受注額 有意差なしの勝ち 主要KPIである配信当たりのMA経由流入数・購入数で統計的に有意な改善を確認したため、汎用推薦システムの本番導入に至りました。 まとめ 本記事では、ZOZOTOWNのMA施策向けに構築した汎用推薦システムについて紹介しました。 本システムは、EmbeddingとBigQuery Vector Searchを活用し、施策を横断して利用できる汎用的な推薦システムです。従来必要だった特徴量作成やモデル学習が不要になることで開発スピードを向上させつつ、Embeddingによりユーザーの潜在的な嗜好を反映した高い推薦精度を実現しています。 実際のMA施策への適用では、開発リードタイムを約10週間から約3週間に短縮しました。さらに、A/Bテストでは配信当たりのMA経由流入数・購入数の改善を確認し、本番導入に至っています。 今後の展望 今後は以下の取り組みを予定しています。 Rerankerの導入 : 現在のスコアブースト・フィルタリングはルールベースで煩雑なため、機械学習ベースのRerankerを導入し、MA施策に最適化されたチューニングを実現する セグメント設定の効率化 : セグメント定義をviewなどで共通管理し、パイプラインごとの再実装をなくす 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com