【ITニュース解説】Curated Deals Still Look Like Plain PMP Lines. OpenRTB Has No Curation Field.

プログラマティック広告の世界では、広告の表示機会（インプレッション）がリアルタイムで自動的に取引されている。この取引を円滑に進めるための共通の技術規約がOpenRTB（Open Real-Time Bidding）と呼ばれるものだ。OpenRTBは、広告枠を売りたい側（SSPと呼ばれるシステム）と買いたい側（DSPと呼ばれるシステム）が、どのような広告枠があり、いくらで買いたいかといった情報をJSON形式でやり取りするための標準的な「言葉」を提供している。

近年、「キュレーション済みディール」というものが注目を集めている。これは、単に広告枠を提供するだけでなく、特定のデータ（例えば、特定の年齢層や趣味を持つユーザー向け、特定のブランドを傷つける可能性のあるサイトは除外するなど）を付加し、価値を高めてパッケージ化した広告枠のことを指す。いわば、美術品を専門家が厳選・編集して提供する「キュレーション」と同じように、広告枠を高品質なものとして提供しようという試みだ。広告主は、より質の高い、あるいは狙ったターゲット層に確実に届く広告枠を求めて、このようなキュレーション済みディールを購入しようとする。

しかし、このキュレーション済みディールには、OpenRTBの現状の仕様において大きな課題がある。OpenRTBの入札リクエストにおいて、ディールに関する情報はimp.pmp.dealsというオブジェクトの中に記載される。ここには「ディールID」や「最低入札価格（bidfloor）」といった基本的な情報は含まれる。しかし、このディールが「キュレーション済み」であること自体を示すフィールドもなければ、キュレーター（厳選者）のID、彼らが受け取る手数料、さらにはこのパッケージがどのようなオーディエンスデータやインベントリフィルタリング（例えば、「特定の小売セグメントのみ」「不適切なコンテンツサイトは除外」といった条件）によって作られたのかを機械的に読み取れるような情報も含まれていない。

このため、DSP側から見ると、キュレーション済みディールも、パブリッシャー（広告媒体）が直接提供する一般的なプライベートオークションのディールも、OpenRTBのデータ上では同じ形に見えてしまうのだ。これでは、広告主が期待する「キュレーションされた付加価値」が本当に提供されているのか、OpenRTBのリクエストデータだけでは確認できないという問題が生じる。たとえオーディエンスセグメント情報がリクエストに含まれていても、それがキュレーターによるものなのか、あるいはパブリッシャーによる通常のデータなのかを明確に区別する手段もないのが現状だ。

この情報不足を解消するために、業界団体のIAB Tech Labは「Curationオブジェクト」というものを定義し、これを「Deal Sync API」という別の仕組みで提供している。Deal Sync APIは、SSPからDSPへ、ディールに関する静的なメタデータ（取引条件、対象となるインベントリの範囲、キュレーター手数料など）を、OpenRTBのリアルタイム入札ストリームとは別に、非同期でプッシュ（送信）するものだ。これは、取引の背景情報を提供するための重要な手段である。

しかし、このDeal Sync APIには重要な注意点がある。Deal Sync APIを通じて送られる情報は、OpenRTBのリアルタイム入札リクエストやレスポンスには含まれないと明記されている。さらに、Deal Syncで送られた条件が、実際にリアルタイムの入札トラフィックで保証されるわけではないともされている。

これはシステムエンジニアにとって、問題を二つの部分に分けることを意味する。一つは、Deal Syncで送られてくるディールのメタデータを適切に受け取り、保存し、レポートなどと比較して整合性を確認する作業だ。もう一つは、実際に広告枠が取引されるリアルタイムのOpenRTB入札リクエストを処理し、入札を決定する作業だ。Deal Syncの情報が正しく処理されたとしても、実際の入札オークションでは、ディールID以外のキュレーションに関する詳細情報がほとんどない状態で判断を下さなければならない状況が起こりうる。

では、OpenRTBの情報だけではキュレーションの中身が分からないとして、システムエンジニアは何もできないのかというと、そうではない。入札リクエストと、それに対する入札レスポンスをペアで検証することで、いくつかの重要な整合性を確認できる。これは、キュレーション済みディールに限らず、プログラマティック広告取引全般で非常に重要な作業だ。

例えば、「ディールIDの整合性」は必須である。広告主側（DSP）が提示した入札に含まれるディールIDが、SSPからのリクエストで提供されたディールIDと一致しない場合、その入札は無効となる。また、「適切な最低入札価格（bidfloor）」のチェックも重要だ。特定のディールには最低入札価格が設定されており、入札はこの価格を上回る必要がある。キュレーターが広告枠を再パッケージ化する際に、この最低入札価格が変更されることがあるため、最新の価格がリクエストに含まれているかを常に確認する必要がある。古い最低入札価格に基づいて入札してしまうと、予期せぬ収益の損失につながる可能性もある。

さらに、wseat（許可されたDSPのシートIDリスト）やwadomain（許可された広告主ドメインリスト）といった制限も検証できる。これらのリストにないDSPや広告主からの入札は拒否されるべきである。広告枠の供給経路を示す「サプライチェーン（schain）」情報も引き続き重要だ。キュレーターが介在しても、広告枠が誰から誰へ渡ってきたかの情報は追跡できるため、手数料の紛争や再販業者の認可状況などをデバッグする際には、このschain情報が参照点となる。

このような検証は、OpenRTBのリクエストとレスポンスを「ペア」で確認することで可能になる。rtblintのようなツールは、これらの整合性チェックを自動化し、OpenRTBの仕様に沿った形で検証するのに役立つ。リクエスト単体、レスポンス単体で有効に見えても、ペアで確認すると問題が露呈することがよくあるからだ。

結論として、Deal Sync APIはキュレーション済みディールの詳細なメタデータを提供する重要な情報源だが、これはあくまで「副次的な情報源」であり、リアルタイムの入札ストリームにおけるOpenRTBリクエストとレスポンスの検証を置き換えるものではない。システムエンジニアは、Deal Syncでキュレーターが「売ったもの」（取引条件や意図）と、OpenRTBのリアルタイムオークションで実際に「取引されるもの」（入札対象のインプレッション情報）との間に情報ギャップがあることを常に意識する必要がある。

キュレーションの詳細やその意図はDeal Syncに記されるかもしれないが、「請求可能な真実」、つまり実際に課金の対象となるのは、OpenRTBの入札リクエストに含まれるディールオブジェクトの情報である。この二つの情報を適切に管理し、照合することが、プログラマティック広告システムを構築・運用する上で不可欠な要素となる。特に、AIや自動エージェントがOpenRTBリクエストを生成するような将来のシステムでは、ディールIDの間違いや古い最低入札価格の適用といったエラーを防ぐためにも、このような厳密なリアルタイム検証がますます重要になってくるだろう。