自社の SSP:Prebid Server や借りた SSP で足りるのはどんなときか、そして誰が作れるのか

SSP（サプライサイドプラットフォーム）は、パブリッシャーの広告枠を多くの買い手に同時に提示し、売れた分の代金をパブリッシャーに支払うソフトウェアだ。自社のサイトやアプリの広告枠だけを販売するパブリッシャーが、SSP を自ら作る必要はめったにない。既存の SSP を通じて販売し、オープンソースのプログラムである Prebid Server を使って、それらのあいだで自前のオークションを行うことができる。自社の SSP が理にかなうのは、ほかのパブリッシャーの広告枠を販売することが自社の事業である場合だ。その場合でも、取引量が増えて手数料が高くなりすぎるか、借りた SSP にはできないことをパブリッシャーが必要とするようになるまでは、借りた SSP で足りることがある。作るなら、コードを引き渡し、SSP を自社のドメインと社名のもとで立ち上げてくれる会社に依頼する。

SSP はパブリッシャーのために何をするのか

パブリッシャーのページやアプリは、埋めるべき広告枠が生じるたびに広告リクエストを送る。SSP はそのリクエストを、デマンドサイドプラットフォーム（DSP）、つまり広告主が広告枠を買うために使うソフトウェアに向けた入札リクエストに変える。そして入札を集め、落札者を選び、販売を記録する。あとでパブリッシャーに支払うためだ。パブリッシャーは SSP にルールも設定する。たとえば、受け入れる最低価格（フロアプライスと呼ばれる）や、拒否する広告の種類だ。

どのオークションにもデッドラインがある。デジタル広告の技術標準を定める非営利の団体である IAB Tech Lab は、入札リクエストの標準である OpenRTB を公開している。2026年10月23日に閲覧したバージョン2.6は、tmax というフィールドを「タイムアウトを避けるために、インターネットのレイテンシを含めて、エクスチェンジが入札の受信を許容する最大時間（ミリ秒）。」と定義している。それより遅く届いた入札は、入札がなかったものとして扱われる。

SSP はお金も扱う。表示された広告を数えて買い手に請求し、それから各パブリッシャーに取り分を支払う。その数が買い手の数と食い違えば、請求書を出す前に、誰かがその理由を突き止めなければならない。

パブリッシャーには Prebid Server で足りるのか

自社の広告枠だけを販売するパブリッシャーなら、自社のチームかホスティングプロバイダーが運用することを前提に、Prebid Server で足りることがある。Prebid Server はヘッダービディングのために作られている。ヘッダービディングでは、パブリッシャーは、自社のアドサーバーがどの広告を表示するかを決める前に、複数の SSP やアドエクスチェンジに同時に入札を求める。アドエクスチェンジは、SSP とほぼ同じように、広告枠のオークションを運営する。

同じ日に閲覧した Prebid.org の概要ページには、こうある:「Prebid Server は、サーバー間ヘッダービディングのためのオープンソースのソリューションである。」同じページによれば、「230以上のサーバーサイド入札アダプター」がある。入札アダプターとは、SSP やエクスチェンジといった入札の供給元につなぐ、すぐに使える接続のことだ。

同じページによれば、Prebid Server は受け取ったリクエストを一件ずつ確認し、プライバシーのルールを適用し、入札アダプターを呼び出す。アダプターが応答し終えるか、「タイムアウト期間が経過した」時点で、ウェブページやアプリなど、リクエストを送ってきた相手に応答を返す。

Prebid Server を使う場合、パブリッシャーは、取引のある SSP やエクスチェンジのあいだでオークションを行う。たいていは、DSP と自ら契約を結ぶことはない。各 SSP は引き続き、自らが販売した広告枠の代金をパブリッシャーに支払い、DSP との接続のほとんどは SSP の側に残る。

概要ページは、よくある二つのシナリオとして「技術に強いパブリッシャー」と「マネージドサービスプロバイダー:それ以外のすべての人に」を挙げている。そして、「オープンソースコミュニティが提供する設定ツールはない。」と述べている。さらに、Prebid Server の導入は「Prebid.js ほど簡単にはとてもいかない」とも注意している。Prebid.js は、訪問者のブラウザで動く Prebid のヘッダービディング用のコードだ。

同じ日に閲覧した GitHub 上の prebid-server のコードは、オープンソースライセンスである Apache License 2.0 のもとで公開されている。このライセンスでは、誰でもコードを使い、変更でき、事業に使うこともできる。パブリッシャーは、自社のサーバーで動かすことも、ホスティングしてくれるプロバイダーを使うこともできる。概要ページによれば、ホスティングを提供するプロバイダーは「保存済みリクエストを管理するツールも提供する」。

自社の SSP を作るべきなのはどんなときか

自社の SSP が向いているのは、ほかのパブリッシャーの広告枠を販売する事業だ。アドネットワーク、アプリのマネタイズを手がける会社、広告枠をまとめて販売するパブリッシャーのグループなどがその例である。こうした事業にとっては、オークションとその手数料こそがプロダクトであり、借りたソフトウェアでは、そのどちらにも変更を加えられる範囲が限られる。

借りた SSP がリクエストごと、または販売ごとに課金し、しかも取引量が増え続けているときも、作ることが理にかなう場合がある。三つ目の理由は、パブリッシャーが必要とするオークションのルールや広告フォーマットを、これまで試した借り物のプロダクトのどれもサポートしていないことだ。

SSP は、DSP がその入札リクエストを受け取ることに同意するまで、何の収益も生まない。そして、DSP との接続は、一つひとつが別々の連携、テスト、契約になる。作る前に、どの DSP が自社の SSP との接続に同意しているのか、そしてローンチ時にどのパブリッシャーが広告枠を持ち込むのかを書き出しておく。

SSP を借りると何が得られ、何がベンダーの手元に残るのか

借りるとは、ベンダーがソフトウェアを運用し、あなたは契約のもとでそれを使うということで、自社のブランドで使う場合もある。アドサーバーのベンダーである Epom は、SSP モジュールを、アドサーバーのプランへの追加オプションとして販売している。同じ日に閲覧した料金ページでは、プランは月250ドルからで、「SSP module」の価格は「1,000 ext.reqs あたり0.001ドル」となっている。このモジュールでは「カスタムの DSP エンドポイントを接続」できる。もう一つの追加オプションである月250ドルの「White-label solution」では、「デフォルトのものの代わりに、自社の名前、ロゴ、ドメインを使う」ことができる。

自社のブランドを付けていても、借りたプロダクトはベンダーのものだ。同じ日に閲覧した Epom Server の利用規約（Epom Server Terms and Conditions）は、こう定めている:「本契約は売買にあたらず、本ソフトウェアに関するいかなる所有権も移転するものではない。」同じ規約は、顧客が自らの「アカウントデータ」（Account Data）、つまりソフトウェアの利用から生じる利用情報とトラフィックのパターンを所有するとし、さらに「すべてのアカウントデータは、契約の不更新またはそれ以前の終了から三十（30）日以内に本ソフトウェアから消去される」としている。契約が終わる前に、データのエクスポートを計画しておく。

契約の書き方はベンダーによって違うので、価格を比べる前に所有権の条項を読む。リクエスト単位の価格は、ベンダーが何をリクエストとして数えるかで変わるが、Epom のページは「ext.reqs」を定義していない。その定義を書面で求め、パブリッシャーが自社の広告枠の販売者としてどのドメインを記載することになるのかも尋ねる。

誰が広告枠を販売しているのかを、買い手に示すのはどのファイルか

買い手は、入札する前に、広告枠の出どころを確かめる。パブリッシャーは、自社の広告枠の販売を認めたすべてのシステムを、自社のウェブサイト上の ads.txt というファイルに列挙する。アプリは、対になる app-ads.txt というファイルを使う。同じ日に閲覧した ads.txt 仕様のバージョン1.1は、各行の最初のフィールドを「ビッダーが接続する SSP、エクスチェンジ、ヘッダーラッパーなどのシステムの正規のドメイン名。」と定義している。

ads.txt の行の三つ目のフィールドは、パブリッシャーがそのシステムと直接取引しているかどうかを示す。仕様によれば、「DIRECT」は、パブリッシャーがその行に記されたアカウントを「直接管理している」ことを意味する。さらに、これは「パブリッシャーと広告システムとのあいだの直接のビジネス契約を意味することが多い」としている。

SSP は sellers.json というファイルを公開する。このファイルには、その SSP が広告枠を販売しているすべての販売者の名前が載る。2019年7月付けで、同じ日に閲覧した sellers.json 仕様のバージョン1.0には、こうある:「広告システムは、sellers.json ファイルを自らのルートドメインと、必要に応じて任意のサブドメインに掲載すべきである。」

このファイルには、すべての販売者を載せなければならない:「機密扱いの販売者であっても、すべての販売者を含めなければならない。」販売者 ID は、それぞれ一つの会社を表す。仕様の言葉では、「すべての seller_id は、その seller_id で取引されたインベントリの代金を受け取る単一の事業者だけに対応しなければならない。」

SSP のドメインは、入札リクエストにも現れることがある。OpenRTB 2.6 は、各入札リクエストに SupplyChain オブジェクトを入れることを推奨している。これは、広告枠の販売に関わり、その途中で支払いを受ける会社の一覧で、不完全であると示されることもある。その asi フィールドは、ads.txt の行の最初のフィールドと同じ言葉で定義されている。つまり、ビッダーが接続するシステムのドメインだ。

EU の人々に表示される広告枠については、考慮すべき枠組みがもう一つある。広告業界団体の IAB Europe は、Transparency and Consent Framework（TCF）を運営している。TCF は、同意をはじめとする一人ひとりのプライバシーに関する選択を、パブリッシャーのサイトやアプリからアドテク企業へと伝える仕組みだ。IAB Europe は TCF を「任意の標準」と呼んでいる。同じ日に閲覧したベンダー向けのページによれば、ベンダーは「アドサーバー、計測プロバイダー、広告代理店、DSP、SSP など」でありうる。同じページは、こうも付け加えている:「TCF に参加するには、ベンダーは登録しなければならない。」

SSP が完成したとき、自社は何を所有しておくべきか

上で挙げたファイルと登録には、どれもドメインか会社の名前が記される。次の項目がそれぞれ最終的に自社のものになっているかを確かめる:

• 自社の名義で登録された、パブリッシャーの ads.txt の行と asi フィールドに記載されるドメイン
• そのドメイン上の sellers.json ファイルと、そこに記載された販売者 ID
• 開発会社ではなく自社が署名した、各 DSP との契約
• 自社の SSP が TCF に参加する場合は、自社の名義での TCF のベンダー登録
• 自社の名義で開設したコードリポジトリ、ビルドスクリプト、クラウドアカウント
• ログとレポート、そしてそれらをエクスポートする、テスト済みの方法

あとから変えるのがたいてい最も難しいのは、ドメインだ。ドメインが変われば、すべてのパブリッシャーの ads.txt ファイルに新しい行が必要になる。パブリッシャーがその行を追加するまでは、ads.txt を確認する買い手が、自社の SSP を通じたその広告枠の販売を、認められていないものとして扱うおそれがある。

開発会社には、その会社自身のコードとサードパーティのコードのうち、自社の所有にならずに残る部分をすべて、部分ごとのライセンスとともに挙げてもらう。Prebid Server のように SSP の中に含まれるオープンソースのコードは、それ自体のライセンスを保つ。契約の文言全般については、専任チームの確かめ方とコードを自社のものにしておく方法についての記事が扱っている。

自社の SSP の構築を申し出る会社を、どう確かめるのか

どの AdTech 提供者にも当てはまる一般的な確認事項は、DSP やアドエクスチェンジを作るか、ライセンスするか、借りるかについての記事が挙げている。SSP を作る場合は、さらに次の六つの問いが加わる:

• そちらが構築した SSP やエクスチェンジのうち、いま稼働しているのはどれか。それを通じて買っている DSP はどこか
• そちらのシステムが送った入札リクエストで、SupplyChain オブジェクトが埋められているものを見せてもらえるか
• tmax を過ぎて届いた入札はどうなるのか。そして、遅れて届いた入札の数を、パブリッシャーはどうやって確認できるのか
• 誰かに請求する前に、そちらが数えた広告の表示数を、各 DSP の数とどう突き合わせるのか
• 新しいパブリッシャーを sellers.json に追加するのは誰で、その変更にはどれくらい時間がかかるのか
• 引き渡しの後も、そちらの所有のまま残るコンポーネントはどれか

SSP を運用したことのある会社なら、これらの問いの多くに、ファイル、ログ、レポートを見せて答えられる。秘密保持契約のために顧客の名前を明かせないなら、代わりにその顧客との通話を設定してもらうよう、その会社に頼む。

最も時間をかけるべきは、数え方についての質問だ。パブリッシャーへの支払いは SSP の数字にもとづくからである。二つの集計がどこでずれていくのかは、広告レポートがビッダーのログと合わない理由についての記事が説明している。

SSP を作るには、あるいは借りるには、いくらかかるのか

作る場合は、まず最初のバージョンにかかる一度きりの費用が発生する。オークション、パブリッシャーと DSP への接続、上で述べたファイル、レポート、そして支払いの仕組みだ。ローンチ後の運用費には、サーバー、ネットワークトラフィック、監視、オンコールの担当者、そして TCF の年間ベンダー料金のような料金が含まれる。

SSP のネットワークトラフィックは、広告リクエストの数だけでなく、DSP の数に応じても増える。SSP は広告リクエスト一件ごとに、入札に招くすべての DSP へ別々の入札リクエストを送るので、DSP が一つ増えるたびに、リクエスト、トラフィック、サーバーが増える。

借りる場合は、こうした費用の大半が、Epom のプラン料金や1,000「ext.reqs」あたりの価格のような、ベンダーへの料金に置き換わる。両方の選択肢を、2年後に見込む取引量で比べる。抜けるときの費用も計算に入れる。たとえば、ドメインがベンダーのものなら、すべてのパブリッシャーで ads.txt に新しい行を加えてもらう必要がある。

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

amBrain のサービス一覧には、次の一文がある:「amBrainは、パブリッシャー向けのサプライサイドプラットフォーム（SSP）を構築します。」AdTech の分野では、amBrain は DSP 開発、リアルタイムビディングのプラットフォーム、アドエクスチェンジのエンジニアリングにも取り組んでいる。RTBBidder は、amBrain がある顧客のために構築したデマンドサイドプラットフォームである。

amBrain は2019年からソフトウェアを作っている。働き方には三つの形態がある:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問をし、そこでいう再利用可能なコンポーネントがどれを指すのかも尋ねること。

この記事は事例紹介ではなく、顧客のための仕事についても述べていない。RTBBidder は amBrain が構築した DSP として名前を挙げているだけで、この記事はそれに関する数字も示さない。

Prebid.org、IAB Tech Lab、IAB Europe、Epom は、それぞれ自身のページからの例として登場するものであり、この記事は、amBrain とそれらのいずれかとのあいだに何らかの関係があるとは主張しない。amBrain の価格や期間も示さない。また、この記事は法的助言でもない。同意とデータに関するルールは国によって異なるので、弁護士に確認する。