メルカリAdsが広告を届けるまでの仕組み

## はじめに こんにちは、Ads Serving チームでバックエンドエンジニアをしている@yanap です。 この記事は、[Mercari Advent Calendar 2025](https://engineering.mercari.com/blog/entry/20251126-mercari-advent-calendar-2025/)の14日目の記事です。 メルカリは 2025年10月時点で 月間 2,305 万人 のお客さまに利用されており、検索や閲覧などの操作に合わせて広告が表示される「メルカリAds」にも、毎日非常に多くの広告リクエスト（広告配信要求）が届きます。** 広告候補は用途ごとに多数存在し、その中から最適な広告を選び出す必要があります。 しかし、どれだけ処理が複雑であっても、広告は 数百ミリ秒以内 に返さなければ検索体験を損ねてしまいます。 大規模なトラフィックの中で高速に広告を選定する仕組みを成立させるのは、簡単ではありません。 お客さまがメルカリアプリで「トマト」と検索したその瞬間、裏側では広告配信のための小さな通信が静かに動き始めています。 その通信を受け取り、複数の内部サービスと連携しながら最適な広告を短時間で選定して返す仕組みを、Ads Serving チームが担当しています。 本記事では、この広告配信フローの全体像と、低レイテンシ（遅延時間）を維持するための工夫について紹介します。 ## 広告がどこに表示されるか まずは、メルカリAdsが実際にお客さまの目にどのように触れるのかを見てみましょう。この記事では、広告配信の仕組みそのものにスポットを当てていますが、こうした広告がメルカリアプリ内のどこに表示されるのかを具体的に知ることで、その仕組みをより身近に感じてもらえるかと思います。 メルカリAdsは、以下のような場所に表示される仕組みになっています。 ## 検索結果画面 お客さまが検索したキーワードに関連する広告が、検索結果リストの上部や一定間隔ごとに表示されます。 検索体験を邪魔しないよう、通常の商品リストと自然に馴染むようにデザインされています。 ![image](https://storage.googleapis.com/prd-engineering-asset/2025/12/c15e54e7-ad-request-page-5-274x300.png) ## 商品詳細ページ 「この商品を見ている人におすすめ」ブロック内に、関連性の高い広告が表示されます。 閲覧中の商品や検索履歴などをもとに、興味を持ちそうな商品を提示しています。 ![image](https://storage.googleapis.com/prd-engineering-asset/2025/12/b59303d2-ads3-135x300.png) メルカリアプリでは、このようにお客さまの操作や閲覧内容に合わせて、自然に広告が挿入されるように設計されています。 ## メルカリAdsの広告配信の仕組み ここからは、メルカリAdsで広告がどのように選ばれ、短時間で返却されているのかを紹介します。 まずは中核となる AdServer（広告配信サーバー）を軸に「広告が返ってくるまでの流れ」を見ていきます。 ![image](https://storage.googleapis.com/prd-engineering-asset/2025/12/6de2d37f-ad-request-page-4-2-300x134.png) - 広告リクエストの開始 検索操作やページ遷移などをきっかけに、広告を表示するための通信が AdServer に送信されます。 広告枠の位置、検索キーワード、閲覧中の商品情報など、表示に必要な情報がここに含まれます。 - AdServer の役割：最適な広告を選ぶ司令塔 AdServer は、広告配信フローにおける中心的な役割を担うサーバーです。 操作に応じて送られた広告リクエストを受け取り、「このお客さまには今どの広告を出すべきか？」を判断します。 そのために、AdServer は裏側にある複数のサービスに問い合わせて「広告候補」を収集します。 収集された候補は、ターゲティング条件・配信設定・予算状況などにもとづいてフィルタリングされ、最終的にユーザーに適した少数の広告が選ばれて返却されます。 - 表示位置に合わせた広告の返却 検索結果画面では、広告の位置や頻度は画面や文脈に応じて細かく制御されています。 選ばれた広告は、その時点の仕様に基づき、適切な位置としてクライアントに返されます。 ## 高速な広告配信を支える仕組み ここからは、メルカリ Ads の広告配信が「なぜこれだけ複雑なのに高速なのか」を紹介します。 広告リクエストが AdServer に届くと、最適な広告を選ぶために複数の内部サービスと連携して処理が進みます。 このように重い処理ですが、実際には多くの工夫によって数百ミリ秒で完了するように最適化されています。 数百ミリ秒、つまり 0.数秒です。まばたき 1 回分の時間ですね。 この短い時間で、多数のサービスが連携し、広告が選ばれて返却されます。 - 多数の広告候補生成ロジックを"並列"で動かす AdServer の裏側では、用途ごとに分かれた「広告候補生成サービス」が複数存在しています（この仕組みを社内では「Demand」と呼んでいます）。 なぜ複数のサービスに分かれているのでしょうか？ それは、広告を探す「手がかり」が状況によって異なるからです。 たとえば、以下のようにそれぞれの広告製品ごとに専用の候補生成ロジックが動いています。 - Product Ads（商品広告）： 広告主が商品データフィードを連携することで、多品目を効率的に広告配信できる製品 - システム側では、メルカリの商品データベースと連携して広告候補を探索 - Infeed Ads（インフィード広告）： 広告主が画像やテキストクリエイティブを入稿して配信する製品 - ユーザーのデモグラフィック情報を用いたターゲティング配信が可能 - システム側では、ML モデルを使って、ユーザーの興味に合った広告を推薦 - Shops Ads（メルカリ Shops 広告）： メルカリ Shops の店舗向けに特化した広告製品 - ショップ商品を効果的にプロモーション - C2C Ads（メルカリ C2C 広告）： メルカリの個人間取引（フリマ出品）を対象とした広告 これらのサービスは、AdServer のリクエストを受けてすべて並列に処理を開始し、広告候補を生成します。 そして異なる広告抽出ロジックを持った各 Demand を複数の microservice に分割し、AdServer から並列で呼び出すことで、短時間で大量の広告候補を抽出することを実現しています。 - 配信設定や予算チェックの最適化 広告配信では広告を出稿している広告主が、配信の上限予算や期間を設定できます。AdServer で広告を返却する前に、これらが有効かどうか確認する必要があります。 ここで重要なのが、データの性質による使い分けです。 配信設定（ON/OFF） → 頻繁には変わらないデータ → キャッシュ（一度取得した情報を保存）を使って高速化 予算残高 → 刻一刻と変化するデータ → 毎回リアルタイムで確認（ただし、タイムアウト時は柔軟に対応） つまり、「変化の速度」に応じて最適な取得方法を選んでいるわけです。 重い判断処理であっても、データの性質に応じて最適な取得方法を使い分けることで、レイテンシを最小限に抑えています。 - AI による最終的な並び替え レスポンスを返す直前には、AI によるスコアリングによって広告を「どの順序で表示するか」を最適化します。 ここでも軽量なモデルやキャッシュが利用され、処理の高速化が図られています。 - 表示に必要な情報の組み立て 最終的なレスポンスを返すために、広告として表示するタイトル・画像などの詳細情報を取得し、クライアントがそのまま描画できる形に整えます。 ここでもキャッシュの活用によって、追加の遅延を抑えています。 ## まとめ 本記事では、メルカリ Ads における広告配信の仕組みを紹介しました。 メルカリ Ads が高速に動作しているのは、次のような設計思想のもと、複数のサービスが連携しているためです。 - 用途別に分かれた複数の広告候補生成ロジックを並列で呼び出せる構造 - 重い処理を複数のサービスに分散し、AdServer が統合して返すアーキテクチャ - 配信設定・商品情報など、頻繁に参照されるデータはキャッシュ前提で高速化 - 予算情報はリアルタイム取得で正確性を保ちつつ、タイムアウト時は柔軟に対応 - AI スコアリングも軽量化・キャッシュにより遅延を抑制 これらの工夫により、検索結果が表示されるころには最適な広告が数百ミリ秒以内に返却されているという体験が実現されています。 日々の開発を通してこの仕組みを理解していく中で、システムの設計思想や高速化の工夫に触れられたのは貴重な経験でした。 今後もメルカリ Ads は進化を続けていくと思います。 この記事が、メルカリ Ads の仕組みに興味を持つきっかけになればうれしいです。 最後までお読みいただき、ありがとうございました。 明日の記事は @ogataka50 さんです。引き続きお楽しみください。

メルカリAdsが広告を届けるまでの仕組み

背景や根拠まで確認しますか？

調べる

選ぶ

サイト