デジタルアウトオブホームのスクリーンネットワークのプログラマティック販売：DOOH の SSP を通じて売るか、ホワイトレーベルのスタックを使うか、自社で作るか

プログラマティック販売とは、ソフトウェアが自社の広告枠を売ることだ。枠が生じるたびに、広告主の買い付けシステムが、自動のオークションでその枠に入札する。デジタルアウトオブホーム（DOOH）のネットワークは、ショッピングモール、駅、ジム、オフィスといった場所にスクリーンを持っている。そうしたネットワークは、多くのネットワークのスクリーンを買い手に提示する DOOH のサプライサイドプラットフォーム（SSP）を通じて、スクリーンをプログラマティックに販売できる。また、ベンダーのソフトウェアを自社のブランドで運用すること（ホワイトレーベルのスタック）も、自社のプラットフォームを作ることもできる。どれを選ぶかは、販売のどこまでを自社で制御したいのか、そして誰が毎日その技術を運用するのかで決まる。

スクリーンネットワークがプログラマティックに販売すると、何が変わるのか

一部の買い手が、自社の営業チームを通じてキャンペーンを予約する代わりに、ソフトウェアを通じて1回ごとの放映に入札し始める。直接販売では、その営業チームが、日程、スクリーン、価格を広告主と取り決める。そのあと誰かが、コンテンツ管理システム（CMS）、つまり各スクリーンで何をいつ流すかを決めるソフトウェアに広告を登録する。

プログラマティックの入札は、デマンドサイドプラットフォーム（DSP）、つまり広告主や広告代理店が広告を買うために使うシステムから届く。買い手と売り手のシステムは、たいてい、共通のメッセージ形式である OpenRTB でその入札をやり取りする。デジタル広告の技術標準を定める IAB Tech Lab が OpenRTB を管理しており、2022年11月に OpenRTB 2.6 にスクリーンへの対応を加えた。

この記事は、その仕様と、それに対する IAB Tech Lab の実装ノートにもとづいている。また、施設の種類を共通の一覧にまとめた OpenOOH の施設タクソノミーと、アウトオブホームの計測についての Media Rating Council（MRC）の基準も用いている。出典はすべて2026年11月4日に閲覧した。

まず見るべきは、CMS やプレーヤー、つまり各スクリーンを動かす機器やソフトウェアだ。ループとは、決まった長さのコンテンツと広告の並びで、何度も繰り返し流れるものだ。自社のスクリーンでループを流しているなら、その枠の一部をプログラマティック用に空けておかなければならない。プレーヤーは、その枠に入れる広告を取得し、何が流れたかを報告しなければならない。広告が届かなかったときには、代わりに映すものが必要になる。

オークションは、放映よりずっと前に行われることがある。IAB Tech Lab の実装ノートによれば、ほとんどのスクリーンはモバイル回線で接続しており、モバイル回線は混雑する時間帯に途切れることがある。そのため、広告を前もって取得しておくスクリーンネットワークもある。実装ノートにはこうある：「業界で現在受け入れられている、『入札の確定』から『表示』までのリードタイムは、最大で1〜2時間になることがある。」

スクリーンでの1回の放映は、どうやって多くのインプレッションになるのか

入札リクエスト、つまり DSP に入札を求めるメッセージは、一件ごとに、その放映が何インプレッションに相当するかを示す。ウェブサイトでは、インプレッションとは、一つの広告が一人に表示されることだ。IAB Tech Lab の実装ノートによれば、スクリーンでの放映は「表示されている広告の近くにいる全員が視認できる」。

その数字がインプレッション乗数（impression multiplier）、つまり放映1回ごとに数えられるオーディエンスである。OpenRTB 2.6 はこれを「このアイテムが購入された場合に、発生したとみなされる課金対象イベントの数量。」と定義している。平たく言えば、買い手が代金を払う対象である。

乗数は1を下回ることもあり、夜間の人通りの少ないスクリーンならそうなりうる。実装ノートによれば、「端数のある値（例：広告の表示1回あたり0.32インプレッション）はよくある」。さらに、この数字は時間帯によって変わることも、「リアルタイムのセンサーデータ」から得られることもあるとしている。

価格は引き続き CPM、つまり1,000インプレッションあたりの価格で表す。実装ノートは、市場価格ではなく計算の例として、こう示している：CPM 2.50ドルの入札が30.3インプレッションに相当する放映を落札すれば、請求額は0.07575ドルになる。実装ノートはまた、小数を掛けることは「『買い手側』と『売り手側』が小数点以下を切り捨てるときに、食い違いにつながることがある」と警告している。最初のキャンペーンの前に、端数の扱いを SSP と買い手のそれぞれと取り決めておく。

オーディエンスの数字は、どこから来るのか

入札リクエストでは、その数字を誰が提供したのかも示せる。IAB Tech Lab の AdCOM 仕様は、三つの出所を挙げている：計測ベンダー、パブリッシャー（自社）、エクスチェンジ（SSP）である。

買い手は、その数字が何を測っているのかを尋ねてくる。MRC は、メディアの計測を監査し、認定する米国の業界団体である。MRC のアウトオブホーム計測の基準（2025年12月の最終版）は、ある場所の通行量から、広告を見た可能性が高いオーディエンスまでを、はしごのような段階に分けて定めている。段を上がるごとに条件が加わり、基準は「総インプレッション（Gross Impressions）は、潜在的なオーディエンスの推定値として最も高いものを表す」と述べている。

広告が放映されたことを、どう証明するのか

放映証明（proof of play）とは、スクリーンのプレーヤーが残すログで、どの広告が、どのスクリーンで、いつ放映されたかを示すものだ。MRC の基準はこう述べている：「総インプレッション（Gross Impressions）やオーディエンスの推定値（Audience estimates）の報告を裏付けるには、放映証明（PoP）の強力な証拠がなければならない」。

デジタルスクリーンについては、基準は、導入前にテストされ、「定期的に監視される」ことを条件に、プレーヤーの動作を記録する技術を認めている。基準は、放映ログなど、広告が放映されたことを示す売り手側の証明も扱っている。その中身については、「広告キャンペーンの開始前に、買い手と売り手が合意しておくべきである」としている。

OpenRTB には、インプレッションを課金できることを買い手に伝えるメッセージである課金通知がある。別のメッセージである落札通知は、入札が勝ったことしか伝えない。IAB Tech Lab の実装ノートは、この二つを分けておき、「クリエイティブがスクリーン上に表示され、インプレッションが課金対象になった」ときに課金通知を送ることを強く勧めている。クリエイティブとは、広告ファイルそのもののことだ。

自社のスクリーンをプログラマティックに販売する三つの方法とは何か

• DOOH の SSP を通じて売る。自社の CMS やプレーヤーを SSP に接続し、スクリーンとオーディエンスの数字を登録する。SSP はそれらを取引のある DSP に提示し、オークションを運営し、手数料を差し引いた残りを自社に支払う。
• ホワイトレーベルのスタックを使う。ベンダーが、自らのアドサーバーと、DSP に向けて販売するソフトウェアを、自社にライセンス提供する。アドサーバーとは、どの広告を流すかを選び、それを数えるシステムである。プラットフォームには自社のブランドが付き、コードの保守はベンダーが行う。
• 自社で作る。自社のチーム、または依頼した会社が、アドサーバー、DSP との接続、レポートを作る。コードとその中のすべてのルールは自社のものになり、運用も自社で行う。

道は組み合わせることもできる：たとえば、直接販売のキャンペーンには自社のアドサーバーを使い、余った放映枠は SSP を通じて売る。

DOOH の SSP を通じた販売で足りるのはどんなときか

次の大半が当てはまるなら、SSP を使う：

• 技術にお金をかける前に、プログラマティックの買い手が自社のスクリーンにお金を払うかどうかを見極めたい
• 自社の CMS やプレーヤーがすでにその SSP と連携しているか、SSP が接続を手伝ってくれる
• プログラマティックで埋めるのは、営業チームが売らない枠である
• 広告プラットフォームを昼も夜も運用するエンジニアがいない

難点は主導権である。買い手は、SSP のマーケットプレイスで、ほかのネットワークと並んだ自社のスクリーンを見つけることになり、価格とディールは、その SSP のソフトウェアが許すやり方でしか扱えない。

ホワイトレーベルのスタックが理にかなうのはどんなときか

次のような場合は、これを使う：

• 広告代理店には、マーケットプレイスではなく、自社のブランドと営業チームから買ってほしい
• 価格、ディール、そしてどの広告をどの施設で流してよいかについて、独自のルールを持ちたい
• キャンペーンを運用するチームは用意できるが、広告のソフトウェアを書いて運用するチームは用意できない

コードは借り物である。新しい機能はベンダーのスケジュールで届き、ライセンス料は取引量に応じて増えることがある。離れる場合は、スクリーン、ディール、買い手のアカウントを、ほかの場所で設定し直さなければならないかもしれない。

自社でプラットフォームを作る価値があるのはどんなときか

自社で作ることが報われるのは、次のような場合である：

• プログラマティックが収益の大きな割合を占めていて、手数料が、自社のシステムを運用するチームに払う費用を上回っている
• 駅で電車の時刻に合わせて変わる広告のように、話をしたベンダーでは対応できないルールが、自社のスクリーンに必要である
• ほかのネットワークのスクリーンも販売していて、プラットフォームが自社の売り物の一部になっている
• 自社のスクリーンがある施設のオーディエンスデータを、自社のシステムの中にとどめておかなければならない

この道では、DSP の買い手が自社のスクリーンを目にできるようになる前に、たいてい DSP ごとに、自社のプラットフォームとの接続に同意してもらい、自社の入札リクエストをテストしてもらう必要がある。システムを監視し、買い手とレポートを突き合わせて精算する人も必要だ。OpenRTB も変わり続けている：IAB Tech Lab は、スクリーンへの対応を加えてから、バージョン2.6に対して7回の更新をリリースしている。自社のチームにこの仕事を担う人がいないなら、SSP かホワイトレーベルのスタックから始める。

どの道を選んでも、自社のチームに残る仕事は何か

次のことは、自社のチームが決め、維持していく：

• スクリーンと施設のデータ：スクリーンごとの ID、所在地、サイズ、稼働時間、施設の種類。施設タクソノミーとは、施設の種類を共通の一覧にまとめたもので、これがあれば、ジムがどの買い手にとっても同じものを指すようになる。OpenRTB 2.6 は、リクエストが別のものを指定しない限り、OpenOOH Venue Taxonomy を前提とする。このタクソノミーは、「Retail」（小売）、その下の「Retail / Malls」（小売／ショッピングモール）のように、施設を階層に分けている。
• オーディエンスの推定値とその出所：自社の数字が MRC のはしごのどの段を測っているのか、誰が測ったのか、どれくらいの頻度で変わるのか
• クリエイティブの承認とコンテンツのルール：IAB Tech Lab の実装ノートによれば、大規模な商業ネットワークの広告は、場合によっては施設の貸主によるものも含めて、「手作業で事前に承認される必要がある」。実装ノートは、不適切な広告が一つでも「公共の場で1,000人単位の人々に」表示されれば、ネットワークの「広告を配信するための契約／許可」が危うくなると警告している。施設のオーナーごとに、何が許されているのかを書面の一覧にしておく。
• 放映ログと照合：放映証明のログは、SSP が集めている場合でも、自社でも保管しておく。スクリーンがオフラインになることもあれば、小数の丸め方が食い違うこともあるので、毎月、誰かが自社のログを各買い手のレポートと突き合わせなければならない。
• フロアプライスと直接取引：フロアプライスとは、受け入れる最低の入札額のことで、入札そのものと同じく CPM で設定する。プライベートマーケットプレイスのディールとは、招待した買い手だけが参加できるオークションのことだ。入札リクエストは、ディール ID と呼ばれるコードでそれを示す。直接販売のキャンペーンとプログラマティックの入札が同じ枠を求めたときに、どちらを優先するかを決めておく。

SSP やホワイトレーベルのベンダーと契約する前に、何を確認すべきか

• 自社が登録するスクリーンの一覧、施設のデータ、オーディエンスの数字は誰のものか。それらはいつでもエクスポートできるのか
• 各入札リクエストには誰のオーディエンスの数字が入り、その出所はどう示されるのか
• それぞれの販売額のうち、どれだけをそちらが取るのか。自社のレポートには、総額と純額の両方が表示されるのか
• いまどの DSP が接続されていて、そのうち直近3か月に DOOH の放映を買ったのはどれか
• 直接販売のキャンペーンを続けながら、同時にほかの SSP も使えるのか
• 各クリエイティブを承認するのは誰か。一つの施設に限って広告をブロックできるのか
• 離れるときはどうなるのか。通知期間はどれくらいで、どのディール、アカウント、ログ、レポートを持ち出せるのか

コード、データ、買い手との関係は誰のものか

SSP は、自らのプラットフォームと、DSP との契約を所有している。スクリーンとオーディエンスのデータは自社のものであり続けるべきで、契約にもそう書いておくべきだ。SSP の中で設定したディールは、移るときに持っていけないことがある。

ホワイトレーベルのベンダーはコードを所有するが、ブランドは自社のものである。買い手のアカウントと DSP との接続が、自社の名義なのか、ベンダーの名義なのかを確かめる。

自社で作れば、ソースコードを所有でき、それを変更するためにどのチームでも雇える。開発会社には、自らが保持する部分と、それらを自社が使えるライセンスを、契約の中で名指ししてもらう。

どれを選んでも、自社のデータは自社のスクリーンを販売するためにだけ使ってよいこと、そしてログとレポートはいつでもエクスポートできることを、書面にしておく。

自社のスクリーンプラットフォームの構築を任せる会社に何を聞くべきか

• プラットフォームは自社の CMS とプレーヤーにどう接続し、広告が間に合わなかったときには何が流れるのか
• 各入札リクエストは、スクリーンの所在地、施設の種類、放映1回あたりのオーディエンス、そしてその数字の出所を、どうやって伝えるのか
• 放映証明はどう記録され、買い手のレポートとどう突き合わされるのか
• 買い手は、IAB Tech Lab の実装ノートが DOOH について「強く推奨される」としている標準である Ad Management API を通じて、クリエイティブを承認に回すのか
• フロアプライスとプライベートマーケットプレイスのディールは、スクリーン、施設、時間帯ごとに、どう設定されるのか
• どの DSP から接続し、それらとの交渉は誰が担うのか
• いま稼働しているシステムで、これが動いているところを見せてもらえるか

amBrain はどこに位置づけられるか

このブログを発行しているのは amBrain である。amBrain 自身の説明のうち三つは、ネットワークが三つ目の道で構築するシステムを表している。一つはこうだ：「amBrainは、パブリッシャー向けのサプライサイドプラットフォーム（SSP）を構築します。」もう一つはこうだ：「amBrainはアドサーバーを構築します：ターゲティング、フリークエンシーキャップ、レポーティング。」三つ目はこうだ：「amBrain はアドテク向けのイベント分析パイプラインを構築する。インプレッションとクリックのイベントの収集、処理、レポーティングである。」四つ目は買い手の側のもので、こうある：「RTBBidder、クライアント向けに構築したデマンドサイドプラットフォーム。」

amBrain は2019年からソフトウェアを作っている。顧客との仕事の進め方については、こう述べている:「三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。」所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」署名の前に、そのコンポーネントを名前で列挙した一覧を求めること。

この記事は事例紹介ではない。RTBBidder の名前を挙げていることを除けば、顧客のための仕事については述べていない。amBrain がいずれかの顧客のために DOOH のプラットフォームを構築したとも、スクリーンネットワークを SSP に接続したとも、オーディエンスを計測したとも述べていない。amBrain の価格や期間も示さない。IAB Tech Lab、OpenOOH のタクソノミー、MRC からの引用は、それぞれが公開している文書によるものであり、この記事は、amBrain とそれらのいずれかとのあいだに何らかの関係があるとは主張しない。

この記事は法的助言でもない。SSP、ベンダー、施設との契約は、署名する前に弁護士に読んでもらう。オーディエンスの数をカメラやその他のセンサーで得ているなら、それにプライバシー法がどう適用されるかを尋ねる。amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問をすること。