Supply Chain Objectとは？広告取引の経路を可視化する仕組み
広告取引の透明性向上とその課題
デジタル広告の取引は複数の仲介業者（リセラー）を経由することが多く、広告主が実際にどの経路で広告を購入しているのか把握するのが難しくなっています。この不透明性が広告詐欺（アドフラウド）や不要な手数料の増加を招く要因となっており、広告業界では取引の透明性を確保するための仕組みが求められてきました。
この課題を解決するため、IAB Tech Labはads.txtに続き、sellers.json、Supply Chain Objectといった技術仕様を策定しました。これらの仕組みはそれぞれ異なる役割を持ちながらも相互に補完し合い、広告取引の透明性を確保するために重要な役割を果たします。本記事では、その中でもSupply Chain Objectに焦点を当て、その仕組みや設定方法について詳しく解説します。
Supply Chain Objectとは？
Supply Chain Object（SChain）は、広告リクエスト内に販売経路を明示するJSONオブジェクトです。広告主が広告を配信する際に、どのSSP（Supply-Side Platform）や広告ネットワークを経由しているのかを確認できるようにすることで、不透明な取引を排除し、より透明性の高い広告取引を実現します。
目的
- 広告リクエストの中で実際に経由した販売経路を明らかにすることで、広告主が取引の透明性をリアルタイムで確認できるようにする。
- 各販売者が正当な手順で取引に関与しているかをDSP（Demand-Side Platform）が検証できるようにし、不正な仲介や不透明な経路を排除できるようにする。
ads.txt、sellers.json、Supply Chain Objectの関係
| 仕組み | 役割 | 設置場所 |
|---|---|---|
| ads.txt | メディア（パブリッシャー）が正規の販売事業者(SSP/アドネットワーク)をリスト化 | メディアサイトのルートディレクトリ |
| sellers.json | SSPが自身の販売者情報（メディア/仲介業者/リセラー）を公開 | SSPのサーバー |
| Supply Chain Object | 広告リクエスト内に実際の取引経路を記録 | 広告リクエスト |
Supply Chain Objectは、ads.txtやsellers.jsonと連携して、広告の販売経路をより詳細に把握できるようにする役割を果たします。
上記の図は、SSP1、SSP2を経由してDSPにリクエストが送られる構図を示しています。
- ads.txt（メディア側）
- メディアのルートディレクトリに設置
- 正規の販売事業者（SSP1・SSP2）を明示
- DSPがメディアのads.txtを確認し、なりすまし等の不正な広告リクエストを排除
- sellers.json（SSP側）
- 各SSPが自身のsellers.jsonを公開
- DSPがsellers.jsonをチェックし、広告リクエストに含まれる経路が信頼できるものであるかを検証
- Supply Chain Object（広告リクエスト内）
- 広告リクエスト内に、各SSPを経由した販売経路を記録
- DSPは販売経路を確認し、途中で不正な業者が関与していないかを検証
Supply Chain Objectの仕組み
Supply Chain Objectは、広告リクエスト内に含まれるJSONオブジェクトとして提供されます。具体的には、以下のようなフォーマットで記述されます。
{
“schain”: {
“ver”: “1.0”,
“complete”: 1,
“nodes”: [
{
“asi”: “ssp-example.com”,
“sid”: “12345”,
“hp”: 1
},
{
“asi”: “reseller-example.com”,
“sid”: “67890”,
“hp”: 0
}
]
}
}
この例では、広告リクエストに2つのノードが含まれています。
- 最初のノード（ssp-example.com）は、広告枠を最初に販売したSSPです。hp: 1 は、この事業者が広告枠の所有者と直接の関係を持っていることを意味します。
- 2つ目のノード（reseller-example.com）は、SSPから広告枠を仕入れて再販売している仲介業者（リセラー）で、hp: 0 は間接関係であることを示します。
主要なフィールド
- ver（バージョン）：Supply Chain Objectのバージョン（現在は1.0）
- complete（完了フラグ）：1（完全な取引経路を示す）または0（部分的な情報）
- nodes（取引経路）：各ノードごとに以下の情報を含む
- asi（広告取引を行うSSPやネットワークのドメイン）
- sid（SSP/アドネットワーク/仲介業者（リセラー）のID）
- hp（SSP/アドネットワーク/仲介業者（リセラー）がメディアと直接取引しているかのフラグ：1=直接、0=仲介）
動作の流れ
- 広告リクエストの送信
- SSPが広告リクエストを受け取ると、SSPは初期のSupply Chain Objectを生成します。
- SSPの情報追加
- SSPがリクエストを受け取ると、自社の情報（asi, sid, hp）をnodesに追加。
- 仲介業者（リセラー）の情報追加
- さらに、仲介業者（リセラー）がいる場合は、その業者がリクエストを受けるたびにnodesに自身の情報を追加。
- DSPが最終チェック
- 最終的にDSPが受け取るSupply Chain Objectは、広告リクエストが経由したすべてのSSP/アドネットワーク/仲介業者（リセラー）を含む数珠つなぎのような構造となる。
Supply Chain Objectの活用で何が変わる？
Supply Chain Objectは単なる技術仕様ではなく、実際の広告取引の質を高めるための実用的なツールでもあります。
たとえば、広告主が「信頼できる販売経路でのみ広告を配信したい」と考える場合、Supply Chain Objectがあることで、リクエスト経路をフィルタリングし、不審な仲介業者（リセラー）を排除することが可能になります。これにより、ブランド毀損や不正な表示のリスクを大幅に下げることができます。
また、SSP側でも自身がどのような経路で広告を提供しているかを正確に示すことで、透明性を重視する広告主やエージェンシーからの信頼を得やすくなります。
Supply Chain Objectの設定方法
通常はSSPがSupply Chain Objectを設定しますが、Prebid.jsを使用している場合、Supply Chain Objectを利用するにはSupply Chain Moduleを有効にする必要があります。
SSPや広告販売事業者が対応する場合
Open Bidding（Google）や Amazon TAM 、Prebid.jsのWrapper事業者、タグ実装など、メディアが外部に任せている場合は、SSP側や事業者側でSupply Chain Objectを付与しているため、メディアでの対応は不要です。
Prebid.jsを外部メディアに提供している場合
自社がPrebid Wrapperを開発・提供しており、他社メディアのヘッダー入札を代行している場合は、自社が広告取引の起点（＝販売者）となるため、Supply Chain Objectを生成する必要があります。
この場合、自社が「お金の流れに関与する事業者」として、sellers.jsonの公開と、Prebid.js上でのSupply Chain Object設定が求められます。
まとめ
Supply Chain Objectは、広告取引の経路を可視化し、不正な取引を排除するための重要な仕組みです。ads.txtやsellers.jsonと連携することで、広告取引の透明性をさらに向上させることができます。
- ads.txt：メディア側が広告枠を販売できる正規の販売パートナーを明示
- sellers.json：SSP側が、自社と取引のあるメディアや仲介事業者の情報を公開
- Supply Chain Object：広告リクエスト内に実際の取引経路を記録
Prebid.jsを利用する場合、Wrapper事業者が対応し、メディアが直接設定する必要はありません。また、Google Open BiddingやAmazon TAMなどのSSPを利用する場合は、GoogleやAmazon側が対応するため、メディアでの設定は不要です。
Supply Chain Objectを適切に実装することで、広告主・SSP・広告プラットフォームの信頼性を向上させ、安全で健全な広告取引を実現しましょう。
