自社の DSP・SSP にコネクテッド TV を：何が変わり、何を自社で作るべきか

コネクテッド TV（CTV）の広告とは、インターネットにつながったテレビで再生される動画広告で、たいていはストリーミングアプリの中の、複数の広告からなるブレークの中で流れる。ウェブやアプリのバナー向けに作られた DSP や SSP がこれを扱うには、四つの点を変える必要がある。入札リクエストは、一つの広告枠ではなく、広告ブレーク全体を記述する。広告は VAST レスポンス、つまり動画ファイルの場所を示す XML ドキュメントとして届く。多くのテレビアプリはブラウザーのように広告をリクエストしたりトラッキングしたりできないので、スティッチングサービスが広告をストリームに挿し込む。するとそのサービスが、テレビに代わって広告リクエストを送り、多くの場合はトラッキングの呼び出しも送るので、デバイスの識別とインプレッションの数え方を変えなければならない。広告ブレークへの入札と VAST への対応は、自社のプラットフォームに組み込む価値がある。スティッチングは、パブリッシャー、またはその仕事のために作られたサービスが担うものである。

コネクテッド TV の広告は何が違うのか

ウェブサイトでは、広告リクエストはたいてい一つの枠に一つの広告を求め、ブラウザーがその広告を読み込んでインプレッションを報告する。テレビでは、視聴者はストリーミングアプリで番組を見ていて、広告は通常のテレビ放送と同じようにブレークの中で流れる。入札プロトコル OpenRTB を管理する団体である IAB Tech Lab は、こうしたブレークを広告ポッド（ad pod）と呼んでいる。「動画または音声のコンテンツのストリームの中で連続して再生される」一つ以上の広告のことだ。

IAB Tech Lab の OpenRTB 2.6 仕様は、バージョン2.6を「CTV 取引向けに広告ポッドを導入する」バージョンだと説明している。この記事は、その仕様と、それに対する IAB Tech Lab の実装ノートにもとづいている。どちらも、この記事のほかの出典と同じく2026年11月2日に閲覧した。

広告ブレークは、入札リクエストの中でどう届くのか

OpenRTB 2.6 では、ブレークは入札リクエストの中の一つ以上のインプレッションオブジェクトとして届き、同じ podid を共有するインプレッションオブジェクトは同じブレークに属する。実装ノートは、三種類のブレークを説明している：

• 構造化（structured）：売り手が枠の数、順番、それぞれの長さを事前に決め、枠ごとに独立したインプレッションオブジェクトになる
• 動的（dynamic）：売り手は合計の長さと広告の最大数を決めるが、広告の数や各広告の長さは決めない。ブレーク全体が一つのインプレッションオブジェクトとして届くこともある
• ハイブリッド（hybrid）：ブレークの一部が固定で、一部が動的

ほとんどのバナー向けプラットフォームは、次のフィールドを読む必要がこれまで一度もなかった：

• poddur は動的ブレークの中で広告主が埋めてよい合計秒数、maxseq はそのブレークに入れられる広告の最大数
• rqddurs は、正確な広告の長さのリスト。仕様によれば、これはライブ TV 向けのもので、ライブ TV では「広告の長さが正確でないと、望ましくない『放送の空白』が生じてしまう」
• slotinpod は売り手が最初または最後の枠を保証できるかどうか、podseq は番組の中でのブレークの位置を示す
• mincpmpersec は、ブレークの動的な部分に適用される、広告時間1秒あたりのフロアプライス

各入札は、dur フィールドで自らの広告の長さを示す。実装ノートはまた、買い手は「最終的なポッドの構成は売り手が行うものと想定すべきである」としている。一つのブレークに複数の入札を送った場合、売り手はそのうち何件を使ってもよく（一件も使わないことも、すべてを使うこともある）、ほかの買い手の広告と組み合わせることもある。

すべての入札に、広告主のドメイン（adomain）とクリエイティブの ID（crid）を付けて送る。仕様は、この二つを「広告の品質チェックやパブリッシャーの制限の適用のために」使われる属性の中に挙げている。

DSP にとって、広告ブレークは入札のロジックを変える。バナーのビッダーは、一度に一つのインプレッションに値段を付ける。CTV のビッダーは、自らの広告のうちどれがブレークの残り時間に収まるかを選び、それらに1秒あたりの値段を付けなければならない。しかも、そのうちどれを売り手が残すかは制御できない。

VAST レスポンスには何が含まれていなければならないのか

動画広告は VAST で配信される。IAB Tech Lab は VAST を「デジタル動画プレーヤーに広告を配信するための汎用的な XML スキーマ」と説明している。2024年7月に最終更新された同団体の VAST のページは、2022年12月の VAST 4.3 を最新バージョンとして挙げている。GitHub にある IAB Tech Lab の VAST 4.x のリポジトリには VAST 4.4 もあり、そこにあるメンテナーの注記は、2026年7月22日にリリースされたと説明している。VAST 4.4 は、ポーズ広告やスクリーンセーバー広告のような CTV のフォーマットを加えている。以下の引用は VAST 4.3 からのものである。

2024年7月には、IAB Tech Lab は CTV 補遺も公表した。VAST 4 のクリエイティブ ID とメザニンファイルを、それより古い VAST 2 と 3 に持ち込むものである。補遺は、これらの古いバージョンが「今日でもなお市場の大半を占めている」と述べている。

テレビで最も重要になるのは、VAST の次の二つの部分である：

• メザニンファイル。パブリッシャーのシステムが画面ごとの版を作るもとになる「未加工の高品質な動画ファイル」である。VAST 4.3 は、メザニンファイルは「広告をスティッチする実装では必須である」とし、メザニンファイルのないレスポンスはスティッチングサービスに拒否されることがあると述べている
• UniversalAdId。システムからシステムへと渡ってもクリエイティブに付いたままの識別子である。VAST 4.3 は、番組の中で再生される種類の広告であるリニア広告にこれを必須とし、補遺はこれを拡張として VAST 2 と 3 に加えている。スティッチングサービスは、あるクリエイティブをすでに変換したかどうかを見分けるのにこれを使う

VAST 4.3 が説明するスティッチングの流れでは、サービスがまだ一度も見たことのないクリエイティブは、再生できるようになる前に変換しなければならないので、そのブレークでは代わりに別の広告が流れる。VAST 4.3 は、メザニンファイルの最初のダウンロードには「数時間かかることがある」と指摘している。AWS も、広告をストリームにスティッチする同社のクラウドサービス MediaTailor について、同じルールを説明している：「広告がまだコンテンツに合わせてトランスコードされていない場合、MediaTailor はその挿入をスキップする」。そしてその広告は、次のリクエストに向けて準備される。

そのため、新しいクリエイティブは、スティッチングサービスごとに最初の再生の機会を逃すことがある。VAST 4.3 は、何らかの形で変更されたクリエイティブには新しい識別子を付けるべきだとしている。クリエイティブそのものが変わっていないあいだは識別子を変えないこと。そうすれば、各スティッチングサービスが変換するのは一度だけで済む。

VAST 4.3 は、検証コードには Open Measurement（OMID）を推奨し、「VPAID を使用しないよう強く」勧めている。VPAID は、動画広告の中でコードを実行する古い方法である。インタラクティブ広告については、VPAID に代わるものとして SIMID を挙げている。VAST 4.3 はインタラクティブなコードを動画ファイルから切り離しており、そのため、スティッチングサービスと連携するプレーヤーは、コードを実行できない場合でも動画は再生できる。テレビ向けのクリエイティブはすべて、ただの動画としても機能するようにしておくこと。

サーバーが広告をストリームにスティッチすると、何が変わるのか

多くのテレビアプリは、ブラウザーのように広告をリクエストしたりトラッキングしたりできない。VAST 4.3 は、その代わりとなる方法を説明している。サーバーサイド広告挿入（SSAI）、または広告スティッチングと呼ばれるものだ。アプリはスティッチングサービスにストリームを求め、サービスはアドサーバーに広告を求め、広告はコンテンツにスティッチされる。こうして視聴者は「一つの連続したストリーム」を受け取る。

OpenRTB 2.6 は、スティッチングとトラッキングのどれだけがサーバー上で行われるかを示すために、インプレッションオブジェクトに ssai フィールドを加えている。その値は「すべてクライアントサイド」から「すべてサーバーサイド」まである。中間のケースでは、動画はサーバー上でスティッチされ、トラッキングピクセルはデバイスが発火させる。既定値の0は状態が不明であることを意味するので、このフィールドのないリクエストからは、どちらとも判断できない。

広告リクエストとトラッキングの呼び出しがサーバーから届くと、多くの視聴者が一つの IP アドレスを共有しているように見える。VAST 4.3 はこう警告している：「トラッキング情報を受け取っているアドサーバーにとって、そのレポートは無効トラフィックに似て見える。」VAST 4.3 によれば、スティッチングのプロバイダーは、トラッキングリクエストとともに、デバイスの IP アドレスと user agent を X-Device-IP と X-Device-User-Agent という二つのヘッダーで送らなければならず、これらの値は元の広告リクエストの値と一致していなければならない。

自社のプラットフォームにとって、これは次のことを意味する：

• トラフィックがスティッチングサービスを経由して届く場合は、デバイスの情報をこれらのヘッダーと入札リクエストから取る。その場合、自社に接続してくる IP アドレスはスティッチングサービスのものなので、デバイスの IP アドレスとして使わないこと
• X-Device ヘッダーなしで届くサーバーサイドのトラフィックについては、売り手に問い合わせる
• 売り手がパブリッシャーの app-ads.txt ファイルに載っていることを確認する。IAB Tech Lab の仕様は、ads.txt を「コネクテッドテレビのアプリストア」のアプリにまで広げている
• フリークエンシーキャップとオーディエンスは、デバイス ID にもとづいて設定する。VAST 4.3 は、スティッチングサービスは「Cookie にアクセスできない」と指摘している。OpenRTB 2.6 では、ifa フィールドが、デバイスのオペレーティングシステムから得られることが想定された広告 ID を運び、lmt フィールドが、トラッキングを制限しなければならない場合を示す

インプレッションはどう数えられ、どう課金されるのか

OpenRTB の実装ノートは、課金対象イベントを数える方法を比較している。音声と動画については、VAST のインプレッションイベントを推奨している。バナーではうまく機能する課金通知の URL（burl）は、「音声・動画には推奨されない」。

実装ノートはまた、支出目標、フリークエンシーキャップ、ペーシングがオークションと課金通知のあいだの遅延に左右されるため、ビッダーはその遅延を追跡するよう勧めている。妥当な遅延をまとめたその表では、サーバーサイドでスティッチされる音声・動画の行に「非常に長い、または不明」とある。

exp フィールドを使って、売り手はリクエストの中で、オークションからインプレッションまでに何秒経過してよいかを示し、買い手は入札の中で、何秒まで待つつもりかを示す。どちらの値も目安にすぎない。実装ノートはビッダーに対し、自らの入札の exp より後に届いた課金通知は課金されないと思い込まないよう警告している。それはエクスチェンジとの契約で決まる事柄だからである。

サーバーサイドのスティッチングによって、カウントのルールが変わったわけではない。VAST 4.3 は、Media Rating Council（MRC）とともに策定された IAB の計測ガイドラインを引用している：「計測ガイドラインは、広告のカウントにクライアント起点の方式を用いることを求めている」。同じ箇所は、サーバー上でのカウントも「クライアントサイドのイベントと計測用アセットにもとづいて開始される限り」認めている。一方、サーバーが独自に開始するカウントは認めていない。それは「実際に広告を見るユーザーから最も遠い」からである。サーバーが広告をスティッチする場合に、どのイベントでインプレッションのカウントが始まるのかを、売り手ごとに尋ねる。

何を自社で作り、何をすでにパートナーが担っているのか

CTV の仕組みの中には、パブリッシャー、またはパブリッシャー向けに作られたサービスが担う部分がある。スティッチングそのものがその一つだ。たとえば MediaTailor は、視聴者の情報を広告決定サーバーに送り、選ばれた広告をアドサーバーのレスポンスで受け取り、それをストリームにスティッチする。動画ファイルを各パブリッシャーのフォーマットに変換することも、同じ仕事の一部である。

一方、プラットフォームの稼ぎを左右する部分もあり、そうした部分は自社で作る価値がある：

• DSP の場合：どの広告がブレークに収まるかを選び、1秒あたりの値段を付けること
• DSP の場合：課金通知が遅れて届くときに、予算をペーシングすること
• DSP の場合：メザニンファイルと、クリエイティブが変わったときにだけ変わるクリエイティブ ID を付けて、クリエイティブを配信すること。ID は VAST 4 の UniversalAdId 要素、または補遺による VAST 2 と 3 向けの拡張に入れる
• SSP の場合：複数の買い手の入札から各ブレークを組み立て、どの広告主が登場してよいかについてのパブリッシャーのルールを適用すること
• SSP の場合：ポッドのフィールドと ssai の値を、すべての買い手に渡すこと
• 両方の場合：X-Device ヘッダーからデバイスの情報を読み取り、サーバーサイドの無効トラフィックをフィルタリングすること
• 両方の場合：買い手と監査人が受け入れる方法で、インプレッションを数えること

自社の広告主が CTV を求めているかどうかを試したいだけの DSP なら、すでに CTV を販売している SSP 一社か二社から始め、まずは構造化ブレークに入札すればよい。それらの SSP には、CTV 在庫のうちどれだけが動的ブレークとして届くのかを尋ねる。実装ノートは、可能な場合は動的ポッドを提供するよう売り手に勧めているからだ。広告の長さが厳密に決まっているライブ TV は、最初のキャンペーンで広告主がそれを求めていることがわかるまで後回しにできる。

CTV が収益の中で継続的な割合を占めるようになったら、上のリストにあるものをすべて自社で作る。テレビのパブリッシャーと独自に取引を結ぶ場合や、パートナーのブレークの扱い方が、自社の入札のどれが流れるかを決め続けている場合も同じである。

CTV を自社プラットフォームに追加する会社に何を聞くべきか

• システムは OpenRTB 2.6 のどのポッドフィールドを読み、動的ブレークの広告をどう選ぶのか
• システムは入札に1秒あたりの値段をどう付け、mincpmpersec を守るのか
• 自社のクリエイティブはどの VAST バージョンを使い、メザニンファイルはどこから用意するのか
• 自社のクリエイティブには、登録済みの UniversalAdId が付くのか、それとも既定値の「unknown」なのか
• システムはサーバーサイドのトラフィックをどう扱い、デバイスの IP アドレスと user agent をどこから取るのか
• 売り手ごとに、インプレッションはどう数えられるのか
• 課金通知が大幅に遅れて届くとき、ペーシングの正確さをどう保つのか
• 最初にどのパートナーとテストし、どの機能を後回しにできるのか

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

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

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

この記事は事例紹介ではない。RTBBidder の名前を挙げていることを除けば、顧客のための仕事については述べていない：amBrain がいずれかのプラットフォームにコネクテッド TV を追加したとは述べておらず、RTBBidder に関する数字も、amBrain の価格や期間も示さない。IAB Tech Lab と AWS は、それぞれ自身の文書から引用しており、この記事は、amBrain とそのどちらかとのあいだに何らかの関係があるとは主張しない。amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問をすること。