みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 さて、7月28日（火）に東京・赤坂インターシティにて、「 AWS Bedrock LLM Day Japan 」が開催されます。Anthropic や OpenAI、OSS の最新モデルから、先日の AWS Summit New York での発表まで、生成 AI の最新動向を半日で体験いただけるイベントです。Amazon Bedrock を活用してビジネスにイノベーションを起こされているユーザーの事例セッションもご用意しています。生成 AI の最新情報のキャッチアップや、ビジネスへの活かし方に課題をお持ちのお客様にとって有用な機会ですので、ぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年7月6日週の主要なアップデート 7/6(月) Amazon SageMaker HyperPod が Disaggregated Prefill and Decode (DPD) に対応 Amazon SageMaker HyperPod が、LLM 推論の prefill フェーズと decode フェーズを分離して実行する Disaggregated Prefill and Decode (DPD) に対応しました。計算集約的な prefill とメモリ帯域集約的な decode をそれぞれ専用の GPU プールに割り当て、KV キャッシュを Elastic Fabric Adapter (EFA) 経由で転送します。これにより、トークンごとのレイテンシーが安定し、厳しいレイテンシー SLO のもとでもスループットを高められます。prefill / decode の容量を独立してスケールでき、インテリジェントルーターがリクエストを自動で最適配分するため、コストとパフォーマンスのバランスを取りやすくなります。EKS オーケストレーターと EFA 対応インスタンスを使用でき、SageMaker HyperPod が提供されている全リージョンでご利用いただけます。 Amazon Cognito がレート制限のセルフサービス設定に対応 Amazon Cognito が、API レート制限をセルフサービスで設定できる新しいプロビジョニング API に対応しました。コンソールまたは API から、アカウントレベルの上限までレート制限を自分で設定でき、変更は即座に反映されます。これまでサービスクォータ経由で必要だった手動の審査プロセスや待ち時間なしに、トラフィックパターンに応じてレート制限を柔軟に増減できます。急なトラフィック増加やキャンペーン時にも、事前のクォータ引き上げ申請を待たずに対応できるようになります。Amazon Cognito が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon CloudWatch Application Signals が Service Events を提供開始 Amazon CloudWatch Application Signals が、例外・レイテンシーのスナップショット、関数レベルのパフォーマンスデータ、デプロイイベントを自動収集する Service Events を提供開始しました。ADOT SDK や CloudWatch Observability EKS アドオンで計測しておくだけで、コードを変更することなくこれらのイベントを自動的にキャプチャできます。デプロイ後に新たに発生した例外を素早く特定できるため、リリース後の問題調査にかかる時間を短縮できます。オプションで関数呼び出しメトリクスを有効にすれば、さらに細かい可視化も可能です。Java / Python / JavaScript に対応し、すべての商用 AWS リージョンでご利用いただけます。 7/7(火) Amazon SageMaker Unified Studio が既存 MWAA 環境のインポートに対応 Amazon SageMaker Unified Studio が、既存の Amazon Managed Workflows for Apache Airflow (MWAA) 環境をプロジェクトにインポート・接続できるようになりました。Workflows ツールで「Add connection」を選択し、Airflow の設定を入力するだけで、運用中の環境をそのまま利用できます。DAG を再作成したり移行したりすることなく、分析や機械学習と同じインターフェースからワークフローを管理できる点が魅力です。Apache Airflow 3 以降では、ドラッグ＆ドロップエディタによるビジュアルオーサリングも利用できます。Amazon SageMaker Unified Studio が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon ECS Managed Instances が GPU の管理料金を最大 60% 引き下げ Amazon ECS Managed Instances が、GPU インスタンスの管理料金を引き下げました。G シリーズは 35%、P シリーズおよび AWS Trainium は 60% の値下げとなり、GPU ワークロードをよりコスト効率よく実行できます。ECS Managed Instances はインフラを AWS が完全管理し、GPU メトリクスの自動監視や、ハードウェア障害の自動検出・修復も備えています。CloudWatch Container Insights による可視化と障害時の自動復旧により、運用負担を抑えつつ稼働停止時間を最小化することが可能です。ECS Managed Instances が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon RDS for Oracle が Oracle Database 26ai のサポートを開始 Amazon RDS for Oracle が、最新の長期サポートリリースである Oracle Database 26ai のサポートを開始しました。自然言語から SQL を生成・実行する Select AI や、ベクトル埋め込みをデータベース内に格納してセマンティック検索を実現する Oracle AI Vector Search を利用でき、SQL 内で直接 RAG (Retrieval Augmented Generation) を構築しやすくなります。データをデータベース外に持ち出すことなく、Anthropic Claude や Amazon Nova、Meta Llama などの基盤モデルを活用した高度な分析が可能です。JSON Relational Duality Views や SQL Property Graphs といった新しいデータアクセス方法も加わり、開発者やビジネスユーザーの生産性向上につながります。すべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンでご利用いただけます。 7/8(水) Amazon Redshift の Graviton ベース RG インスタンスがトレーリングトラックで利用可能に Amazon Redshift の Graviton ベースの RG インスタンス（rg.xlarge、rg.4xlarge）が、安定性を重視するトレーリングトラック（P201）でも利用できるようになりました。RG インスタンスは RA3 インスタンスと比較して最大 2.4 倍高速なクエリ性能を提供し、vCPU あたりのコストを 30% 削減できます。本番環境の安定性を優先するお客様が、検証済みのトラック上でこの高いコストパフォーマンスを享受できます。AWS マネジメントコンソール、AWS CLI、AWS SDK から、新規クラスターの作成または既存クラスターのリサイズでご利用いただけます。 AWS Security Hub が Network Scanning を提供開始 AWS Security Hub が、環境内のリソースがインターネットから実際に到達可能かどうかを検出する Network Scanning を提供開始しました。セキュリティグループやルートテーブルの設定を評価するだけでなく、実際にプローブを行い、パブリック IP アドレスや仮想マシン、ロードバランサー、到達可能なポートと稼働中のサービスを特定して検出結果を生成します。設定ベースの検出を補完し、外部から実際にアクセスできるリスクを正確に把握できるため、攻撃対象領域の削減に役立ちます。AWS だけでなく Azure 環境も対象とし、Security Hub Essentials の契約であれば追加費用なしで、個別アカウントや組織全体で有効化できます。AWS Security Hub をサポートするすべての商用リージョンでご利用いただけます。 Amazon Aurora DSQL が変更データキャプチャ (CDC) の一般提供を開始 Amazon Aurora DSQL が、変更データキャプチャ (CDC) の一般提供を開始しました。insert / update / delete 操作の結果を変更イベントとして自動的にキャプチャし、Amazon Kinesis Data Streams に配信できます。これにより、マイクロサービス間のデータ同期や、AWS Lambda 関数のトリガー、Amazon S3・Amazon Redshift・Amazon OpenSearch Service へのデータ連携を、インフラを管理することなく実現できます。データベースワークロードへの影響を抑えた設計により、パフォーマンスに影響を与えずに変更データを取得できるのは実運用で効いてきます。Aurora DSQL が利用可能なすべての AWS リージョンでご利用いただけます。 7/9(木) Amazon SageMaker Feature Store が一括書き込みとレコード一覧の API を追加 Amazon SageMaker Feature Store が、複数レコードを単一リクエストで一括書き込みできる BatchWriteRecord と、フィーチャーグループ内のレコード識別子をページ単位で一覧表示できる ListRecords を追加しました。BatchWriteRecord は複数のフィーチャーグループにまたがる書き込みにも対応し、API 呼び出しを削減して、低レイテンシーで取り込みが可能になるほか、一部のレコードが失敗してもリクエスト全体は継続されます。ListRecords により、フィーチャーグループの内容を参照・監査・ライフサイクル管理でき、カスタムツールを構築する必要がなくなります。あわせて、オフラインストアのテーブル名・データベース名をカスタムで指定できるようになり、データカタログの整理も容易になりました。Amazon SageMaker Feature Store が利用可能なすべての AWS リージョンでご利用いただけます。 AWS Config が 191 個のマネージドルールを追加 AWS Config が、Amazon Bedrock、Amazon SageMaker、Amazon ECS、Amazon EKS、Amazon RDS、Amazon Redshift、Amazon S3、AWS CloudTrail など主要サービスに対応した 191 個のマネージドルールを追加しました。暗号化、ロギング、パブリックアクセス、ネットワークセキュリティ、データ保護といった設定を自動で評価でき、AI ワークロードからクラウドインフラまでガバナンスの適用範囲が広がります。ルールは個別に、またはコンフォーマンスパックとして一括でデプロイできるため、複数サービスにまたがるベストプラクティスの適用やコンプライアンス管理を効率化できます。 7/10(金) Amazon EC2 R8in / R8ib / R8idn / R8idb インスタンスが東京リージョンなどで利用可能に メモリ最適化インスタンスの Amazon EC2 R8in、R8ib、R8idn、R8idb が、アジアパシフィック（東京）およびヨーロッパ（フランクフルト、アイルランド）を含むリージョンで追加で利用可能になりました。第 6 世代 Intel Xeon Scalable プロセッサと第 6 世代 AWS Nitro カードを搭載し、前世代（R6in / R6idn）と比較して vCPU あたり最大 43% のコンピューティング性能向上を実現します。R8in / R8idn は最大 600 Gbps のネットワーク帯域幅を、R8ib / R8idb は最大 300 Gbps の EBS 帯域幅を提供し、リアルタイムのビッグデータ分析や分散キャッシュ、AI/ML クラスター、大規模商用データベースなど、メモリ集約型のワークロードに適しています。 AWS DMS Schema Conversion が AWS MCP Server による AI エージェント自動化に対応 AWS Database Migration Service (DMS) Schema Conversion が、AWS MCP Server を介した AI エージェント自動化に対応しました。Kiro、Claude Code、Cursor などの AI コーディングエージェントを接続することで、自然言語による指示から、プロジェクト作成、ソースメタデータの参照、スキーマ変換、評価レポートの生成、結果のエクスポートまで、マイグレーションのワークフロー全体を IDE から直接実行できます。ストアドプロシージャや関数、トリガーといったコードの変換も支援し、試行錯誤のループを削減できる点がうれしいポイントです。追加料金なしで、既存のすべての ソース/ターゲットエンジンの組み合わせでご利用いただけます。 AWS Organizations が新規組織にアカウント離脱防止のセキュリティコントロールをデフォルト適用 AWS Organizations が、コンソールから新規に組織を作成する際に、メンバーアカウントの組織からの離脱や自己クローズを防ぐサービスコントロールポリシー (SCP) を自動的に適用するようになりました。これにより、深いセキュリティ知識がなくても、初日から強固なガバナンスパターンを確立でき、初期構成が簡略化されます。適用される設定は必要に応じて自由にカスタマイズできます。現在では、米国東部（バージニア北部）、AWS GovCloud (US-East / US-West)、中国リージョンでご利用いただけます。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon Quick です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

はじめに こんにちは。データシステム部・MA推薦ブロックの住安（ @kosuke_sumiyasu ）です。 私たちのチームは、ZOZOTOWNのメール・LINE・プッシュ通知といったマーケティングオートメーション（MA）の推薦システムを開発・運用しています。目指しているのは、ユーザーひとりひとりに最適な配信を届けることです。 ZOZOTOWNで本番運用されている推薦モデルは、価格・ブランド・カテゴリ・カラーといった テーブル特徴量 のみを学習に用いていました。そのため、商品画像が持つ視覚情報（シルエット・質感・カラー・柄）を活用できていませんでした。「オーバーサイズシルエット」や「光沢感」「チェック柄」といった、人が画像から読み取れる「見た目の好み」を推薦に反映できていなかったのです。 下図は、四角い縁のメガネを好むユーザーを例に、画像から「見た目」を捉えることで目指した推薦の姿を示したものです。従来のモデルではカテゴリは「メガネ」で合っていても、丸縁やサングラスといった「見た目」の異なる商品が混ざってしまいます。一方、画像から「見た目」を捉えられれば、ユーザーが好みそうな四角い縁のメガネを中心に推薦できます。 そこで私たちは、 商品画像から視覚的特徴を捉えた画像特徴量を生成する仕組み を構築し、既存の推薦モデルに特徴量として組み込むことで、「見た目の好み」を捉えるマルチモーダル推薦システムを実現しました。実際に、この推薦モデルをあるメール配信施策に適用しました。A/Bテストの結果、メール経由サイト流入率（CTR）・メール経由購入率（CVR）・経由売上（メール経由で発生した売上）のすべてで有意な改善が得られました。しかもこの画像特徴量は特定の施策にとどまらず、全社のどの推薦・検索モデルからでも利用できる共通の基盤として提供しています。 本記事では、この取り組みの背景にある課題、画像特徴量を生成・提供する仕組み、そして推薦モデルへの特徴量の組み込みで工夫した点を中心に紹介します。マルチモーダルな特徴量を推薦に活かしたい方の参考になれば幸いです。 目次 はじめに 目次 背景・課題 前提となる推薦システム 課題1: 推薦モデルが「見た目」を捉えられていない 課題2: 画像Embeddingを全社で利用できる基盤がない アプローチの全体像 画像Embeddingを安定供給する仕組みの構築 差分更新によるコスト削減 モデル・バージョンを管理し、VIEWで全社へ提供する 推薦モデルのマルチモーダル化によるパーソナライズ精度向上 モデルの選定 事前学習済みモデルを使用した理由 Item Towerへの組み込み Gated Multimodal Unit（GMU）で画像の寄与度を動的に制御する 特徴量単位の Dropout（Feature/Modality Dropout）で特定特徴量への依存を抑える 定量評価（オフライン） 効果 「見た目の好み」の反映による主要指標の改善 全社共通の画像Embedding基盤の整備 まとめ 今後の展望 最後に 背景・課題 前提となる推薦システム ZOZOTOWNのMAにおけるパーソナライズされたアイテム推薦の一部では、 Two-Towerモデル を使用しています。これは、ユーザーを表現するUser Towerと商品を表現するItem Towerの2つのニューラルネットワークからなります。学習済みの各Towerを使うことで、ユーザーと商品の特徴量をそれぞれEmbeddingに変換できます。このEmbeddingは、特徴を捉えた数値ベクトルで、意味の近いものほどベクトルも近くなる性質を持ちます。両Towerの出力を同じ潜在空間上にマッピングするように学習することで、ユーザーとアイテムの近さをコサイン類似度で測れるようになります。推薦時は、任意のユーザーのEmbeddingと各商品のEmbeddingの類似度を計算し、類似度が高い商品から順に推薦します。 ZOZOでは、このEmbeddingを Embedding基盤 として一元管理し、どの部署からでも利用できるようにしています。私たちの 汎用推薦システム も、この基盤を使用して配信する商品を選定しています。 課題1: 推薦モデルが「見た目」を捉えられていない このItem Towerの特徴量は、価格・ブランド・カテゴリ・カラーなどの テーブル特徴量 のみでした。そのため、 ユーザーの視覚的な嗜好を推薦に反映できない という課題が残っていました。同じカテゴリ・ブランドの商品でも、ユーザーが好むシルエットや柄、質感はさまざまです。しかし従来の推薦モデルは見た目の情報を持たないため、「興味のあるカテゴリやブランドは合っているけれど、見た目の趣味は違う」という結果になりがちでした。例えば筆者は、結婚式用に無地のパステルカラーのネクタイを探していたのですが、柄物ばかりが推薦されてしまい、改善の余地を感じていました。 課題2: 画像Embeddingを全社で利用できる基盤がない 商品画像が持つ視覚情報を推薦に活かすには、それを数値ベクトルに変換した 画像Embedding として扱うのが有効です。しかし当時は、商品画像すべてを画像Embedding化する仕組みも、それを全社で共有する基盤も存在していませんでした。そのため、各チームが検索や推薦で画像特徴量を使いたくても、それぞれが独自に実装する必要があり、開発工数の増加や品質のばらつきが生じます。そこで本プロジェクトでは、 画像Embeddingを常に使える状態で組織に提供し続ける基盤 を構築し、それを推薦モデルに組み込むことで「見た目の好み」を捉えられるようにすることを目指しました。 アプローチの全体像 課題を解決するために、大きく2つに取り組みました。 画像Embeddingを安定供給する仕組みの構築 ：商品画像から視覚的特徴を表す画像Embeddingを日次バッチで生成し、BigQueryのVIEWで提供する。どの推薦・検索モデルからでも、常に最新の画像特徴量を利用できる 推薦モデルのマルチモーダル化によるパーソナライズ精度向上 ：その画像Embeddingを推薦モデルのアイテム特徴量として組み込み、「見た目の好み」を捉えてパーソナライズ精度を高める マルチモーダル推薦は、次の3つのパイプラインで実現しています。 パイプライン 役割 generate-image-embedding 商品画像から画像Embeddingを生成し、BigQueryへ保存する train-product-recommendation 画像Embeddingを特徴量に加えてTwo-Towerモデルを学習する generate-product-embedding 学習済みモデルでユーザー・商品のEmbeddingを生成する このうち、train-product-recommendationとgenerate-product-embeddingは、もともと運用している既存のパイプラインです。今回はそこに、画像Embeddingを生成するgenerate-image-embeddingを新たに追加しました。あわせて、train-product-recommendationのモデルアーキテクチャと入力特徴量を変更しています。 これらのパイプラインで生成したユーザー・商品のEmbeddingを使って、施策ごとに配信商品を選定します。 以降では、本記事の中心である「画像Embeddingを安定供給する仕組みの構築」と「推薦モデルのマルチモーダル化によるパーソナライズ精度向上」を詳しく紹介します。 画像Embeddingを安定供給する仕組みの構築 画像Embeddingの生成パイプラインは、 Agent Platform Pipelines（旧Vertex AI Pipelines） 上に実装し、日次バッチで実行しています。全体像は次のとおりです。 処理は大きく4ステップで構成されます。 Embedding化の対象とするアイテム集合を取得する 商品画像を取得し、Cloud Storage（以下GCS）へ保存する 事前学習済みの画像モデルで画像Embeddingを生成する 生成したEmbeddingをBigQueryへ保存し、VIEWとして提供する 画像Embeddingの生成（ステップ3）には、 Hugging Face で公開されている事前学習済みモデル（ SigLIP 2 ）をGPU上で利用しています。画像の保存先にはGCS、Embeddingの保存先にはBigQueryを使っています。なお、SigLIP 2を採用した理由は、のちほど「モデルの選定」で説明します。 この中で工夫した「差分更新によるコスト削減」と「全社への提供」を順に紹介します。 差分更新によるコスト削減 ZOZOTOWNで扱う商品画像は、サイト上でアクティブな商品に限っても数千万枚の規模にのぼります。これらをすべてEmbedding化すると計算コストが大きいため、各商品（商品×カラー）につき代表の1枚に絞ってEmbedding化しています。それでも対象は数百万枚あり、さらに新着商品を考えると、毎日およそ数十万枚を新たにEmbedding化する必要があります。 これらを毎日すべて計算し直すと、GCSからマシンへ画像を転送するオペレーション料金や、推論時間の増加に伴うマシン料金がかさみ、個々は小さくても積み重なると無視できないコストになります。そこで、すべての画像を毎日計算し直す 全件更新 ではなく、未処理分のみを計算する 差分更新 を採用しています。具体的には、次の2つのステップで「まだ処理していないものだけ」を対象にします。 画像の保存（ステップ2） ：すでにGCSへダウンロード済みの画像は除外し、未取得の商品画像のみを保存する Embedding生成（ステップ3） ：すでに計算済みのEmbeddingは除外し、未計算の商品画像のみを対象とする これにより、新着商品だけを処理すればよくなり、ダウンロードコストと計算コストを抑えられます。また、GCSはAgent Platform Pipelinesの実行リージョンと同じRegionalバケットを使うことで、リージョン間レプリケーション費用やエグレス料金も抑えています。 モデル・バージョンを管理し、VIEWで全社へ提供する 画像Embeddingを全社の共通資産として提供するうえで重要になるのが、 モデルとバージョンの管理 です。精度改善のためにモデルを差し替えたり、複数のモデル・バージョンをA/Bテストで並行させたりすることがあります。そのたびに、利用者が「いまどのモデル名・バージョンが最新で有効か」を追いかけてクエリを書き換えるのは負担が大きく、更新への追従漏れも起こる可能性があります。そこで、利用者がそれらを意識しなくても、常に最新の有効なEmbeddingを取得できる仕組みを用意しました。 具体的には、次の3つのテーブル・VIEWでモデルとバージョンを管理しています。 テーブル / VIEW 種別 役割 product_image_embedding_raw テーブル 生成したEmbeddingを、商品ID・モデル名・モデルバージョン・生成日とあわせて追記する。過去分も残すため、複数のモデル・バージョンが共存する model_manifest テーブル 提供対象とするモデル・バージョンにアクティブフラグを立てる product_image_embedding VIEW model_manifestのアクティブなバージョンに絞り、商品ID × モデル名ごとに最新のEmbeddingを返す product_image_embedding_rawテーブルを直接参照する場合は、利用者がクエリのたびにモデル名やバージョンをWHERE句で指定する必要があります。これをVIEWにまとめることで、利用者はproduct_image_embeddingのVIEWを参照するだけで、常にアクティブなモデル・バージョンの最新Embeddingを取得できます。一方でproduct_image_embedding_rawテーブルにはバージョンごとの履歴が残ります。そのため、モデルのA/BテストではTreatment用のVIEWを用意することで、特定バージョンを指定した検証にも対応できます。 この仕組みによって、追跡性と再現性を確保しつつ、A/Bテストにも対応できます。当初の施策にとどまらず、検索や他の推薦面でも安心して利用できる全社共通の資産として提供できるようになりました。 推薦モデルのマルチモーダル化によるパーソナライズ精度向上 画像特徴量を活かしてパーソナライズ精度を高めるために工夫した点を紹介します。工夫したポイントは2つあります。1つ目が「画像Embedding生成モデルの選定」、2つ目が「生成した画像Embeddingを推薦モデルに組み込む方法」です。特に後者が重要で、画像特徴量は単純に足すだけでは効果が薄く、シンプルな2つの工夫を加えることでモデルの精度を大きく改善できました。 モデルの選定 画像Embeddingの生成には、事前学習済みの SigLIP 2 を採用しています。SigLIP 2は、 CLIP から派生したモデルです。CLIP系のモデルは、画像を扱うImage Encoderと、説明テキストを扱うText Encoderの2つから構成されます。学習時は、対応する画像と説明テキストのペアは近づけ、対応しないペアは遠ざけます。こうした対比的な学習をcontrastive学習と呼び、これにより画像と言語が同じ空間で結びつきます。なお、CLIPがsoftmaxベースの損失を用いるのに対し、採用したSigLIP系はこれをsigmoid損失に置き換えている点が特徴です。 画像が言語の意味と対応づけて学習されるため、得られる画像Embeddingは「柄」「シルエット」「質感」といった視覚的特徴を捉えやすいと考えられます。 CLIP系のモデルの中でSigLIP 2を選んだのは、論文記載のとおり、ゼロショットの分類・検索タスクのベンチマークで良い結果が示されているためです。 事前学習済みモデルを使用した理由 ZOZOの商品画像でファインチューニングする選択肢もありましたが、今回は事前学習済みモデルをそのまま使う方針としました。理由は次の3点です。 テキスト側の教師データがない ：CLIP系の追加学習に必要な、画像とペアになる説明テキストを大規模に用意できていない まず有効性を検証したい ：画像特徴量が推薦に効くかは未検証のため、まずは低コストに効果を確かめたい 基盤モデルの進化が速い ：将来、高性能なモデルへ載せ替える余地を残したい Item Towerへの組み込み 画像Embeddingは、まずItem Towerの入力としてそのまま使えるように整えます。下図のように、画像EmbeddingをItem Towerの入力特徴量の1つ（image_embedding）として追加します。User Tower側は変更せず、Item Tower側にのみ画像特徴量を加えています。 使用した画像Embeddingは768次元です。これを価格やカラーといった他のテーブル特徴量とそのまま結合すると、画像だけで次元の大部分を占めてしまい、他の特徴量の影響が埋もれてしまいます。そこで、画像Embeddingを2層の多層パーセプトロン（768 → 256 → 128）で128次元に圧縮してから、他の特徴量と結合します。これにより、画像とテーブル特徴量の次元のバランスを取りつつ、画像から推薦に効く表現を学習できるようにしています。 ただし、この「圧縮してそのまま結合する」方法だけでは、期待したほどの精度改善が得られませんでした。そこで、さらなる精度改善に向けて次の2つの機構を導入しています。 Gated Multimodal Unit（GMU）で画像の寄与度を動的に制御する 次元を揃えて結合するだけでは、画像をどれだけ重視するかが全商品で一律になってしまいます。しかし本来、画像をどれだけ重視すべきかは商品によって異なります。例えば、Tシャツは柄が選択の決め手になるため画像を重視したい一方、靴下はカラーやブランドといったテーブル特徴量で十分なことが多いです。そこで、画像特徴量の寄与度だけをアイテムごとに動的に調整できるよう、 GMU を参考にしたゲート機構を導入しました。 論文の2モダリティ版GMUは2つのモダリティをゲート値で線形補間するため、片方を強調するともう片方が抑制されるトレードオフを持ちます。これに対して本実装は、 他の特徴量はそのままで、画像特徴量にのみsigmoidゲートを掛ける一方向型のゲート を採用しました。これは、2モダリティ版GMUからもう片方を抑制する項を取り除いた独自の変種で、アイテムごとに画像特徴量の重みづけだけを調整できます。これにより、カテゴリやブランドなどのアイテム情報から、その商品で画像特徴量をどれだけ重視するかを動的に決められます。 一方向型にした理由は、既存のテーブル特徴量（カテゴリ・価格など）は複数のA/Bテストで有効性が実証されており、その表現力をそのまま維持した状態で、画像特徴量を追加したかったためです。 特徴量単位の Dropout（Feature/Modality Dropout）で特定特徴量への依存を抑える もう1つの工夫が、学習のたび、入力の一部をランダムにマスクすることで、特定の特徴量への過度な依存を防ぐDropoutです。よく使われるDropoutは個々のニューロン単位でマスクしますが、今回は特徴量単位でマスクする Feature Dropout を行います。なかでも画像Embeddingは、モダリティ全体を1単位としてマスクし、これを特に Modality Dropout と呼びます。実際には、テーブル特徴量（価格・ブランド・カテゴリ・カラーなど）は各フィールドを、画像Embeddingはモダリティをまるごと1つの塊として、それぞれ独立かつランダムにマスクします。 なぜこれが効くのかを、カラーと画像Embeddingを例に説明します。カラーからもユーザーが好む大まかな色味は学習できますが、画像Embeddingを使えば、より詳細なカラーやシルエット、柄まで捉えられる可能性があります。しかし画像Embeddingは複雑で扱いが難しいため、モデルは学習しやすいカラーにばかり頼り、画像Embeddingを十分に活用しないことがあります。そこでカラーをマスクすると、モデルは画像Embeddingからも学ばざるを得なくなり、画像Embeddingの特徴が使われない状態を防げます。逆に、画像Embeddingに偏りすぎる場合も画像Embeddingをマスクすれば、カラーなどのテーブル特徴量から学べます。こうして、どちらか一方に偏らず、画像Embeddingも含めた幅広い手がかりをバランスよく使う、堅牢なモデルになります。 定量評価（オフライン） これらの工夫により、画像特徴量なしのベースラインと比べて、オフラインのRecall@100は段階的に改善しました。 構成 Recall@100（ベースライン比） ベースライン（画像特徴量なし） — ＋ 画像特徴量あり（単純結合のみ） +1.06% ＋ 画像特徴量あり（Feature/Modality Dropout） +11.3% ＋ 画像特徴量あり（Feature/Modality Dropout ＋ GMU） +12.0% 効果 「見た目の好み」の反映による主要指標の改善 構築したマルチモーダル推薦システムを、1配信あたり約700万人を対象とするメール配信施策のアイテム推薦ロジックに適用し、A/Bテストで効果を検証しました。Control（画像Embeddingなし）とTreatment（画像Embeddingあり）を比較し、CTR・CVRはz検定、経由売上はt検定を用いて有意水準5％で評価しました。 その結果、 CTR・CVR・経由売上のすべてで統計的に有意な改善 が確認され、TreatmentがControlを上回りました。以下はTreatmentのControlに対する相対改善率です。 指標 相対改善率 有意差 CTR（メール経由流入数 / 配信数） 約 9.9% あり（勝ち） CVR（メール経由購入数 / 配信数） 約 14.3% あり（勝ち） 経由売上（メール経由の受注金額 / 配信数） 約 10.3% あり（勝ち） ユーザーの「見た目の好み」を捉えた推薦が、実際の流入・購入・売上の改善に結びつくことを確認できました。この結果を受けて本番リリースを決定し、現在は本番環境で稼働しています。 全社共通の画像Embedding基盤の整備 共通基盤の構築により、画像Embeddingを使いたいチームは、生成パイプラインを自前で用意する必要がなく、VIEWを参照するだけで常に最新のEmbeddingを利用できます。これにより、検索や他の推薦面を担当するチームも、開発工数をかけずに効果検証を始められます。さらに、基盤側でモデルを改善すれば、利用側は追加対応なしでその精度向上を受けられます。モデルの差し替えやバージョン管理を基盤の内側に閉じ込めたことで、利用者は中身を意識せずに使い続けることができます。 まとめ 本記事では、商品画像の視覚情報を推薦に活かすマルチモーダル推薦システムの構築を紹介しました。事前学習済みモデルを活用し、少ない工数で画像特徴量を追加して、その有効性まで確かめられました。さらに、生成した画像特徴量を全社で利用できる資産として提供できたことも、大きな成果だと考えています。これにより、画像特徴量を試したい部署は、自分たちで実装しなくてもすぐに効果検証を始められます。そして「画像」という新しい特徴量の軸を手に入れたことで、ここを足がかりに推薦をさらに良くしていけるはずです。 今後の展望 画像Embeddingのさらなる活用と推薦の精度向上に向けて、次のような展開を考えています。 画像Embeddingの活用箇所の拡大 ：整備した共通基盤を活かし、検索・他推薦面へも展開する 画像ベースの候補生成への活用 ：閲覧・購入した商品と視覚的に似た商品を、推薦候補とする モデルの高度化 ：事前学習済みモデルから、ZOZOのデータでファインチューニングしたモデルへ置き換え、ファッションに特化した表現の獲得を目指す 画像の前処理の工夫 ：商品領域をバウンディングボックスで検出してクロップ（切り出し）し、周辺の背景ノイズを除いて視覚的特徴をより正確に捉える 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

2026年5月某日、生成AI利活用を推進する有志による「Hacking Fest 2026 Spring」が開催されました。Hacking Festとは？Hacking Festは、ゴールデンウィーク...