【ITニュース解説】OpenProposal Ranks Briefs. The OpenRTB Bid Request Has No Proposal Handle.

今日のデジタル広告業界では、広告枠の売買がますます複雑になり、そのプロセスをコンピュータシステムで自動化する動きが活発に進んでいる。これまでは人間が広告主からの要望（ブリーフ）と広告媒体からの提案を比較・交渉していたが、大量の広告取引を効率的に行うためには、このプロセスをソフトウェアで処理する必要がある。

そこで、IAB Tech Labという組織が「OpenProposal」という新しい仕様案を発表した。これは、広告を販売する側（セラーエージェント）が持っている広告商品を、標準化された形式でコンピュータに理解できるように記述し、広告を購入する側（バイヤーエージェント）が、自分のキャンペーンの目的や要件（ブリーフ）に合致するかをソフトウェアで比較・評価できるようにするものだ。人間が何千もの提案書を読み比べるのは不可能だが、OpenProposalによってすべての販売者が同じルールで商品情報を提示すれば、ソフトウェアが効率的に最適な提案を選び出せるようになる。OpenProposalは、AdCOMやOpenDirectといった既存の広告取引システムと連携し、広告取引全体の流れをよりスムーズにするための「共通言語」として機能する。

OpenProposalが主に活躍するのは、広告取引の「計画段階」である。購入者側のシステムは「どの地域で、どれくらいの予算で、どのような形式の広告を」といった具体的な要望をブリーフとして定義し、販売者側のシステムはそれに合致する広告商品を構造化されたデータで返す。購入者側のシステムは、返ってきた提案を評価し、最適なものを選択する。しかし、ここで一つ重要な問題が浮上する。計画段階で「この広告商品を契約する」と合意された内容が、実際に広告が配信される「実行段階」で正しく引き継がれない可能性があるのだ。広告の実行段階では、通常、OpenRTB（Open Real-Time Bidding）という別のプロトコルが用いられ、広告枠のオークションが行われる。しかし、OpenRTBの入札リクエストには、計画段階でOpenProposalによってどの提案が選ばれたのかを示す情報（例えば、提案のIDなど）が含まれていないため、せっかく合意した詳細な情報が失われたり、誤って解釈されたりするリスクがある。

この情報の断絶が引き起こす具体的な問題として、コネクテッドTV（CTV）広告における「広告の長さ」の不一致が挙げられる。例えば、広告主のブリーフで「15秒と30秒の広告枠を希望する」と明確に指定され、OpenProposalを通じて販売者もその正確な長さの枠を提供すると合意したとする。しかし、実際のOpenRTBの入札リクエストを作成する際に、システムが古いテンプレートを使用していたり、設定ミスがあったりすると、「最低5秒、最大60秒」といった曖昧な範囲指定で広告の長さを送ってしまうことがある。OpenRTBの最新バージョン2.6では、rqddursというフィールドで「必須の広告秒数を正確に指定する」機能が導入されたが、これは従来のminduration（最小秒数）とmaxduration（最大秒数）とは同時に使えない排他的な設定だ。もし計画段階で正確な秒数が合意されたにもかかわらず、実行段階のOpenRTBリクエストで範囲指定が送られると、広告配信システムは合意内容とは異なる6秒や12秒、45秒といった長さの広告も受け入れてしまう。その結果、本来の契約（ブリーフ）に反する広告が配信され、例えば30秒の広告枠に29秒の広告が入ってしまい、わずかながら「無音の時間」が発生するといった問題が起こるのだ。

この問題を解決するためには、まずOpenRTBの入札リクエストを作成する際に、OpenProposalで合意された正確な情報を、可能な限り厳密に反映させることが不可欠だ。上記の例で言えば、曖昧なmindurationやmaxdurationではなく、正確な秒数をrqddursとして指定する必要がある。さらに重要なのは、作成された入札リクエストが正しいかどうかを検証するプロセスだ。rtblintのような検証ツールは、OpenRTBの仕様に沿ったJSON形式になっているかを技術的にチェックしてくれる。しかし、このツールは「OpenProposalで合意されたビジネス上の要件（ブリーフ）が、このJSONに正しく反映されているか」までは見てくれない。rtblintはあくまで、OpenRTBという通信プロトコルの「文法」が正しいかをチェックするものであり、ビジネス的な「意味」まで検証するわけではない。

そのため、システムを構築する際には、OpenProposalで合意した計画内容と、実際にOpenRTBを通じて送られる入札リクエストを「異なるが関連する契約」であると認識し、それぞれを独立して、かつ相互に照らし合わせて検証する仕組みが必要となる。具体的には、常に利用する広告取引プラットフォームのOpenRTBバージョンに合わせた検証を行い、例えば広告の配置を示すAdCOMのplcmtフィールドなどが、OpenProposalでスコアされた内容と一致しているかをクロスチェックすることが求められる。また、動画広告の場合、入札リクエストのJSON形式が正しくても、実際に配信される広告素材（VASTタグ）が仕様通りに機能するかは別問題だ。そのため、vastlintのようなツールを使って、VASTタグそのものの検証も行う必要がある。

OpenProposalは広告取引の自動化を大きく進める強力なツールだが、計画段階と実行段階のシステム連携における「情報の断絶」という根本的な課題を浮き彫りにしている。システムエンジニアとしては、データがシステム間でどのように流れ、どのように変換され、そしてどのように検証されるのかを深く理解し、情報の整合性を保つための堅牢なシステムを設計・実装することが、今後ますます重要になるだろう。