RTBlint

RTBlint

OpenRTB リンター。 バージョン別の IAB Tech Lab 仕様スナップショットに照らして、2.0 から月次リリースの 2.6（現在は 2.6-202606）までの OpenRTB 2.x 入札リクエストと入札レスポンスを検証します。

ウェブサイトとプレイグラウンド：rtblint.org

チェック内容

• 不正な JSON とトップレベルの形状の誤り
• 必須フィールド。空でない配列が必須の場合も含みます
• バージョン別カタログにないオブジェクトやフィールド（ext サブツリーは制限されません）
• 型の不一致（文字列、整数、浮動小数点数、ブール値、オブジェクト、配列の各形式）
• AdCOM リストやベンダー範囲（500 件以上）を含む、文書化された列挙値
• バージョン間で非推奨、移動、削除されたフィールド、およびまだ利用できないフィールド
• セマンティックルール：site/app/dooh の排他性、imp におけるメディアタイプの存在、スキップ可能な動画の依存関係、duration の排他性、レスポンスにおける seatbid/nbr の存在など
• レスポンスのマークアップ整合性：bid.adm の内容と宣言された bid.mtype の整合性（ネイティブ JSON エンコード、VAST/DAAST のルート、二重エンコードされたペイロード）
• リクエストとレスポンスの相互検証：元のリクエストを指定すると、各入札の impid、mtype、adm マークアップ、dealid、シート、通貨を、リクエストで実際に提示された内容と照合します
• JSON の方言：仕様の JSON 型では imp.secure や regs.coppa などのフィールドは整数ですが、IAB OpenRTB protobuf スキーマではそのうち 28 個が bool と宣言されています。どちらのエンコードも、それぞれのトランスポートでは正しく、もう一方では誤りです。そのため、呼び出し元がどちらを意図したかを宣言します
• エクスチェンジプロファイルは、選択したベンダーとトラフィックの方向に応じて、公開されているリクエスト、レスポンス、ペアの制約を適用します。ソースで明示的に必須とされていない限り、オプションの拡張はオプションのままです。プロファイルには、Google Authorized Buyers、Prebid Server、Microsoft Monetize、Magnite DV+ xAPI、およびバイヤー、サプライヤー、SDK の各契約が含まれます。ソース、フィクスチャ、制限については、エクスチェンジプロファイルの根拠資料を参照してください
• OpenRTB が文字列または不透明な ext として扱う入れ子の仕様：Native Ads 1.2 マークアップ（imp.native.request とネイティブの bid.adm。必須アセットのペアリングを含む）、GPP ヘッダーと gpp_sid の整合性および TCF 2 の形状、課金 URL と損失通知 URL の ${AUCTION_*} マクロ、EID/SUA 構造、SKAdNetwork ext.skadn
• プライバシーシグナルの矛盾：regs.coppa / device.lmt / device.dnt / regs.gdpr と同じペイロード内の識別子、TCF Purpose 1 とデバイスストレージ ID、US Privacy の販売オプトアウトとハッシュ化された EID、メールアドレス形式の user.id / site.page、DSA Transparency フィールドの有無。検出結果はドキュメントの内容を説明するものであり、法的な結論を示すものではありません
• ARTF エンベロープと変更セット。変更の適用と、適用後の内容の再検証も含みます

各検出結果には、安定したルール ID、重大度、メッセージ、JSON パスが含まれます。

ARTF

IAB Tech LabのAgentic Real Time FrameworkであるARTFは、RTBRequestエンベロープに格納されたOpenRTBペイロードをエージェントに渡し、ミューテーション（オーケストレーターが1つずつ承認または拒否できる変更案）を受け取ります。適用後にオークションが引き続き有効かどうかをフレームワークが確認することはなく、ミューテーションは対象となるリクエストとの関係においてのみ意味を持ちます。

# The envelope, plus full OpenRTB validation of what it carries
rtblint validate --type artf-request rtb-request.json

# The mutation set against the auction it targets
rtblint validate --type artf-response --request rtb-request.json rtb-response.json

# Apply the mutations, revalidate, and report only what the mutations broke
rtblint validate --type artf-response --apply --request rtb-request.json rtb-response.json

3つの検証パスがあります。

• エンベロープ。 必須メンバー、実際に含まれるペイロードに対するlifecycle、オークション中の呼び出しとして妥当なtmax、originatorとapplicable_intentsの列挙値を確認し、含まれるビッドリクエストとビッドレスポンスをprotobuf JSONとして検証します。
• ミューテーション。 レスポンスIDが拡張ポイントのリクエストID（ビッドリクエストIDではありません）をエコーしていること、宣言された各インテントがapplicable_intentsに含まれていること、オペレーションとペイロードのoneofメンバーがインテントと一致していること、さらに各セマンティックパス（/imp/{id}、/imp/{id}/pmp/deals/{id}、/user/data/segment、/seatbid/{seat}/bid/{id}）がオークションに含まれる対象を参照していることを確認します。ADJUST_DEAL_MARGINについては、書き込み先となるOpenRTBフィールドが存在しないため、その旨を報告します。
• 適用後。 ミューテーションを適用して結果を再検証し、ミューテーションによって生じたOpenRTBの指摘事項を報告します。既存の指摘事項は除外します。エージェントが壊した箇所であり、受信時点ですでに壊れていた箇所ではありません。

ARTF v1.0のドキュメントと.protoでは、同じミューテーションに異なる語彙が使われています（activateSegmentsとvalue: {IDsPayload: ...}のラッパーに対して、ACTIVATE_SEGMENTSとトップレベルのoneofメンバー）。ドキュメントに従って記述されたペイロードは、未知のものとして退けられるのではなく、マッピングされてartf.mutation.legacy_spec_encodingとして報告されます。

対応サーフェス

サーフェス	パッケージ	状態
Rust CLI	rtblint	動作中
Rustライブラリ	rtblint-core	動作中
MCP サーバー	rtblint-mcp	動作中
Node（WASM）	npmのrtblint-core	動作中
GitHub Action	aleksUIX/rtblint	動作中
Python	PyPIのrtblint	未実装
Go	github.com/aleksUIX/rtblint/go	未実装

OpenRTB 3.0は、階層化されたエンベロープを通じて検証されます。つまり、トランスポートオブジェクト（Openrtb、Request、Item、Deal、Source、Response、Seatbid、Bid）と、item.spec（Placement）、bid.media（Ad）、request.contextの下にあるAdCOM 1.0ドメインオブジェクトを検証します。3.0バリデーターに送信された2.xペイロードには、単なる解析エラーではなく、移行診断が返されます。2.6-202204スナップショットには抽出済みのカタログがないため、ペイロードを黙って通すのではなく、非対応として報告されます。今後の予定についてはROADMAP.md、リリース履歴についてはCHANGELOG.mdをご覧ください。

CLI

cargo install rtblint

rtblint validate request.json
rtblint validate --type response response.json
rtblint validate --type response --request request.json response.json
rtblint validate --version 2.5 --format json request.json
rtblint validate --dialect proto-json grpc-bid-request.json
rtblint validate --profile google-ab google-bid-request.json
rtblint validate --profile prebid-server pbs-auction.json
rtblint validate --profile xandr xandr-bid-request.json
rtblint validate --profile magnite magnite-bid-request.json
rtblint validate --resolve --cache ./supply-cache request.json
rtblint validate --summary bids.ndjson
rtblint validate --batch --summary bids.ndjson
cat request.json | rtblint validate --stdin

--request は、バッチ検証を含むペア検証で、元となる入札リクエストを指定します。--dialect proto-json は protobuf JSON エンコーディングを選択します。--profile は、ベンダーの契約とトラフィックの方向を選択します。Xandr は入札者向け Microsoft Monetize トラフィックを検証し、Magnite は DV+ xAPI 拡張モデルを検証します。任意の seller、context、inventory の識別フィールドは、指定された場合に検証されます。アカウント固有の要件と実行時の受け入れ判定は、ペイロードの検証対象外です。--resolve --cache <dir> は、ローカルディレクトリにある sellers.json と ads.txt / app-ads.txt に照らして SupplyChain の各ホップを検証します。

<dir>/sellers/<asi>/sellers.json
<dir>/ads/<site.domain>/ads.txt
<dir>/app-ads/<app.bundle>/app-ads.txt

Protobuf JSON では、IAB スキーマでネイティブに定義されているオブジェクト形式もサポートされます。 imp.native.request_native（requestNative）と bid.adm_native （admNative）です。これらのネイティブ形式では、フラグにブール値を使用します。文字列形式の request と adm では、JSON エンコードされた Native Ads マークアップを引き続き使用します。oneof ごとに、いずれか 1 つの形式を指定してください。ネイティブアセットは引き続き検証され、必須リクエストアセットと照合されます。IAB protobuf スキーマを参照してください。

データの取得は行いません。キャッシュはご自身で用意してください。--batch は、ファイルまたは stdin から、1 行につき 1 つの JSON オブジェクトをリントします。--summary は、キャプチャしたストリームのルール頻度の合計を追加します（ヒストグラムのみを出力するには --summary bids.ndjson を指定します）。--type artf-request と --type artf-response については、ARTFを参照してください。

終了コード：0 は有効、1 は検証エラー、2 は使用方法または I/O エラーです。

GitHub Action

この Action はこのリポジトリにあります。CI で CLI の tarball をダウンロードできるよう、リリースタグを固定してください。

- uses: aleksUIX/[email protected]
  with:
    path: fixtures/bid-request.json
    spec-version: 2.6-202505

version は CLI のリリースを選択します（auto は Action 自身の v* タグに追従します）。spec-version は OpenRTB のスナップショットです。Linux と macOS のランナー、x86_64 と aarch64 に対応しています。

Node

import { validate, validateResponse, validateResponseAgainstRequest } from "rtblint-core";

const report = validate(JSON.stringify(bidRequest), "2.6-202505");
if (!report.valid) {
  for (const issue of report.issues) {
    console.log(`[${issue.severity}] ${issue.path}: ${issue.message} (${issue.id})`);
  }
}

// Cross-validate a response against the request it answers.
const paired = validateResponseAgainstRequest(
  JSON.stringify(bidResponse),
  JSON.stringify(bidRequest)
);

gRPC bidstream ペイロードと ARTF については、次のとおりです。

import {
  validateDialect,
  validateProfile,
  validateArtfRequest,
  validateArtfResponseApplied,
  protoBoolDivergences,
} from "rtblint-core";

validateDialect(JSON.stringify(bidRequest), "proto-json");
validateProfile(JSON.stringify(bidRequest), "google-ab");
validateProfile(JSON.stringify(bidRequest), "prebid-server");
validateArtfRequest(JSON.stringify(rtbRequest));

// { result, application }: what the mutations broke, and the payloads they produced
const { result, application } = validateArtfResponseApplied(
  JSON.stringify(rtbResponse),
  JSON.stringify(rtbRequest)
);

protoBoolDivergences(); // the 28 fields the two schemas type differently

MCP サーバー

インストール不要のホステッド Streamable HTTP：https://rtblint.org/mcp。Smithery の掲載ページ：aleksander/rtblint（vastlint と同じアカウントです）。ホステッドエンドポイントに送信されたペイロードは、ルールの改善に使用するため保存される場合があります（識別情報は削除されます）。rtblint.org/privacyを参照してください。stdio 経由でローカル実行する rtblint-mcp はペイロードを送信しません。

rtblint-mcp は stdio 経由の MCP にも対応しています。ツール：validate_bid_request、validate_bid_response（相互検証用に省略可能な bid_request を指定）、validate_artf_request、validate_artf_response（apply は変更を適用して再検証します）、list_openrtb_versions、get_adcp_capabilities。検証ツールでは、dialect と profile の引数を省略可能です。

ARTF ツールは、エージェントが自身の作業に対して呼び出すガードレールです。受け取ったエンベロープを確認し、提案しようとしている変更セットを確認してから、オーケストレーターに渡します。

{
  "mcpServers": {
    "rtblint": { "url": "https://rtblint.org/mcp" }
  }
}

ホステッドエンドポイントではなく、ローカルの stdio を使用する場合：

{
  "mcpServers": {
    "rtblint": { "command": "rtblint-mcp" }
  }
}

Rust ライブラリ

use rtblint_core::{validate_bid_request_for_version, OpenRtbVersion};

let result = validate_bid_request_for_version(OpenRtbVersion::V2_6_202505, payload);
for issue in &result.issues {
    println!("{} {} {:?}", issue.severity, issue.id, issue.path);
}

validate_bid_request_with_profile は、仕様に加えてエクスチェンジプロファイル（Profile::GoogleAuthorizedBuyers、Profile::PrebidServer）を適用します。validate_bid_request_with_dialect は、仕様の JSON と protobuf JSON のどちらを使用するかを選択します。

公開されているプロファイル ID：spec、google-ab、prebid-server、xandr、magnite、dv360、index-exchange、index-exchange-seller、unity、vungle、bidswitch、bidswitch-supplier、inmobi、inmobi-supplier、mobilefuse、mobilefuse-sdk、applovin-alx、commerce-grid、digital-turbine、sovrn、equativ、equativ-supplier、triplelift-supplier、adform-handler、yandex-sdk-bidding、pubmatic-openwrap、pubmatic-openwrap-ctv。方向に対応するプロファイルを選択してください。たとえば、buyer 5.7 には bidswitch、supplier 1.1 には bidswitch-supplier を使用します。

検証対象フィールド、サポートされる方向、明示されている未対応範囲については、プロファイルの対象範囲と根拠資料を参照してください。ペアでのレスポンス検証では、リクエストを参照コンテキストとして使用します。完全なレポートを得るには、リクエストを個別に検証してください。

JSON スキーマ

schemas/ には、追跡対象の各バージョンについて、両方のペイロードタイプを対象とする JSON Schema（draft 2020-12）が格納されています。バリデーターが使用するものと同じカタログから生成されています。IAB Tech Lab は 2.6 または 3.0 の JSON Schema を公開していないため、これらが毎月のスナップショットごとの機械可読な仕様となります。

https://rtblint.org/schemas/openrtb-2.6-202606-bid-request.schema.json
https://rtblint.org/schemas/openrtb-2.6-202606-bid-response.schema.json

スキーマは、構造、型、必須フィールド、文書化された値の集合、AdCOM の列挙型リストを網羅しています。一方、リンターが追加する内容、つまり非推奨および移動されたパス、バージョン固有の削除、意味上のルールは表現できません。スキーマに対する検証とリンティングは同じではありません。

カタログを変更した後は再生成してください（差分がある場合、CI は失敗します）。

cargo run -p rtblint-core --example export_json_schemas

ドキュメント

この README 以外の参考資料は、rtblint.org に掲載されています。

• 診断コードのリファレンス: 安定した各問題 ID と、その意味、重要な理由、修正方法を説明するページ
• バージョン別ルールカタログ: 各 OpenRTB リリースで追加、非推奨化、移動、削除された内容
• OpenRTB のバージョン: 追跡対象の各バージョン（2.0 から 3.0 まで）のページ
• OpenRTB でよくある間違いとCI での検証
• 入札リクエストの構造、入札レスポンスの構造、OpenRTB FAQ

仕様データと出典

バリデーターは、IAB Tech Lab の OpenRTB 仕様から抽出した構造化カタログ（オブジェクト名、フィールド名、型表記、列挙値の集合、セクションの引用）に基づいて動作します。カタログには仕様の文章は含まれていません。ダイアレクト表も同じ方法で、カタログと IAB OpenRTB protobuf スキーマで宣言されたフィールド型を比較して導出しています。RTBlint は IAB Tech Lab と提携しておらず、同組織からの承認も受けていません。出典表記については NOTICE を参照してください。

サプライチェーン

OpenSSF Scorecard は毎週実行され、公開スコアを掲載します。Dependabot は Cargo、npm、GitHub Actions を対象としています。CodeQL はプッシュおよび PR のたびに Rust と JavaScript をスキャンします。

3 つの cargo-fuzz ターゲット（validate、validate_response、validate_artf）は、CI のプッシュごとにそれぞれ 30 秒間実行されます。バリデーターは任意の入力に対してパニックを起こしてはなりません。

cargo +nightly fuzz run validate -- -max_total_time=60

ライセンス

Apache-2.0。LICENSE と NOTICE を参照してください。

研究

Sekowski, A. (2026). OpenRTB はどの程度機械検証可能か？リアルタイム広告を成立させるプロトコルの規範的内容の分類. プレプリント。 DOI: 10.13140/RG.2.2.27937.57448

Sekowski, A. (2026). クライアントサイドのヘッダービディングにおける OpenRTB ダイアレクトの測定. プレプリント。 DOI: 10.13140/RG.2.2.26572.78720

Sekowski, A. (2026). CTV 広告詐欺がなくならない理由：コネクテッド TV サプライチェーンの検証可能性分析. プレプリント。 ResearchGate。フィールド一覧はこのカタログから抽出しました。成果物：github.com/aleksUIX/ctv-verification-gap。