AdFection：広告の承認と、端末で動くコードの隙間

1. 広告素材の承認から、実際に届くコードへ

Citizen Labは2026年10月15日、通信の順序と端末由来の検体から、Al JazeeraでのCandiru感染をDiscover-Techの広告へ結びつけたAdFection報告を公表した。45台以上は標的台数で、感染台数ではない。 [1]

このニュースが広告市場へ投げかける問いは、審査の対象を何にするかだ。広告主が提出した画像や文面が適切でも、その広告が呼び出すサービスから別のコードが届くなら、最初に承認したものだけでは利用者の体験を説明しきれない。広告枠は画面の一部として売られるが、品質を評価する範囲は画面に見える部分を越える。売買の単位と、技術上の作用が起こる単位にずれが生じる。

素材の承認を一度済ませるサービスと、配信後の変化まで確かめるサービスは、同じ保証を売っているわけではない。買い手が両者を同じ安全性として受け取れば、広い検証に費用をかける提供者ほど価格で不利になり得る。反対に、どの条件で何を確認するかが伝われば、継続的な検証は比較できる品質になる。SG Groupは、この保証範囲の違いを、広告仲介の競争条件として読む。

影響の入口は広告配信と、閲覧端末を守る仕事にある。今回の報告から世界の広告費が何％減るかを導くことはできない。取引先が検査範囲を見直し、広告枠の選び方やサービスの購入条件を変えるとき、初めて収入と支出への経路が具体化する。脅威の存在から業界全体の利益へ飛ぶより、品質を誰が確認し、その結果を誰が利用できるかを追う方が、企業間の違いを捉えられる。

2. 「同じ広告」を何と定義するか

広告を比較するとき、画像が同じか、同じ識別番号が付いているか、同じ相手から返ったかという複数の基準がある。説明用に、最初の画像を変えず、その表示後に返す内容だけを受信条件に合わせる仕組みを考える。この場合、素材の番号でまとめた一つの広告には、異なる動作が含まれ得る。素材を保存しておくことは有用でも、それだけで後続の応答まで固定したことにはならない。

同時に、コードが変わることだけを不正の証拠とするのも無理がある。表示する大きさや端末の機能に合わせる変更には、正当な用途がある。検査の仕事は変化を一律に禁じることではなく、認める変化の範囲を定め、その範囲を越えた動作を見つけることになる。画像の見え方を調整する変更と、追加の情報を外へ送る変更を、同じ更新という言葉でまとめると品質の比較が難しくなる。

売り手が一つの素材を大量に配信できる利点は、更新と最適化を効率よく行えることだ。その利点を残しながら検証するなら、変更できる部分と、再確認を要する部分を明確にする必要がある。たとえば、説明用の契約では、画像の寸法変更と外部サービスの追加を異なる変更区分にする。同じ承認番号を使い続けられるかを決める基準があれば、確認の費用をすべての小変更へ均等にかけずに済む。

広告文面の主張と承認記録を整理する解説は、誰がどの版を確認したかを残す考え方を補う。ただし、文面の根拠が正しいことと、配信時のコードが許容範囲に収まることは別の成果だ。広告主は両方を必要とする場合、それぞれの成果物と更新条件を購入仕様へ落とし込むことになる。文言を審査する部門の承認で、技術的な動作の検査も完了したと受け取られる設計では、責任の空白が残る。

3. 審査用の端末だけでは見えない応答

同日に公表したConfiantの調査は、端末の特徴を調べて後続コードを選ぶ仕組みを分析している。同社の観測期間は2026年4月1日～9月10日だった。解析した機能がすべての端末で使われたという意味ではなく、広告の実行環境にも制限される。組織のネットワークに広告が届いたという記録から、特定の職員への標的化や感染までを推定することもできない。 [2]

この仕組みを検査の側から考えると、一つの成功例より、異なる条件で返る応答の違いが重要になる。審査用端末に問題がなかったとしても、同じ広告の別の受信者へ同じ応答が返るという前提は残る。配信する側が受信条件を見分けられるなら、審査の回数を増やすだけでその前提を確かめることは難しい。何度も調べることと、違う範囲を調べることは同じではない。

説明用に、ある広告を一台の検査端末で百回読み込む場合と、異なる条件の十通りで十回ずつ読み込む場合を比べる。どちらも百回だが、後者は条件の違いを調べるための設計になる。前者にも、同じ条件で時間によって応答が変わるかを調べる価値はある。優劣を決めるのは総回数ではなく、検査で答えたい問いだ。端末差を調べたいのか、時点差を調べたいのかによって、必要な配分が変わる。

この比較は検出確率の推計ではない。選ばれた十通りが実際の受信者を代表する保証もなく、配信する側が検査環境を見抜く可能性もある。それでも、総回数だけを品質指標として販売すると、同じ範囲を繰り返す安い方法が有利になるという問題を示せる。発注者が条件の種類と選び方を求めれば、検査会社は回数の多さより、見えていない範囲を減らす能力で競争しやすくなる。

4. 表示回数を被害件数へ変換しない

図3は異なる取引段階を比べる。この二つは人数でも感染台数でもない。落札を入札で割ると約11.7％になるが、これは感染率を表さない。大きな分母を示す数字ほど、次の段階へ進んだ条件が何かを説明しなければ、被害の大きさを過大に伝えてしまう。 [1]

経営者が把握したい損失と、配信事業者が把握しやすい件数には距離がある。説明用に、一人が同じ広告を何度も受信する場合を考える。表示回数は増えても受信者は増えない。一つの端末を複数人で使うなら、端末数から人数への変換にも追加の情報が要る。広告配信の記録を、被害者への補償や端末調査の必要台数へ使う際には、同じ数え方をそのまま引き継げない。

一方、感染を確定できた件数だけに予算を合わせると、調べる力の弱さが小さな被害として見える可能性がある。詳しく調べた組織と、記録が残らなかった組織を同じ表で比較すれば、前者の方が危険だったように見えるかもしれない。観測できた範囲が違うからだ。検出件数を減らす目標だけを設けると、調査を減らすことでも達成できてしまう。防御投資の評価では、この逆向きの誘因を避けたい。

被害を調べる仕事には、配信、応答、実行、端末への影響という別々の証拠がある。手前の記録は後段の調査を優先する材料になっても、後段の結果を自動的に確定しない。発注する企業は、検査サービスがどの段階の証拠を返すかを確認する。広告枠を通った記録の提供と、端末で起きたことの調査を同じ価格で比べれば、必要な機能を購入できないまま、契約したという安心だけが残り得る。

5. 販売経路の正しさと、実行内容の正しさ

IAB Tech Labのads.txtは、媒体が広告枠を販売することを許可した会社を公に示す仕組みだ。sellers.jsonとSupplyChain objectは、販売・再販売に関わる相手をたどるための情報を補う。前者の公表ページは2026年9月14日、後者は10月7日の更新日を掲げている。これらの説明が対象にするのは販売の権限と経路であり、端末へ届くすべてのコードの動作検証ではない。 [3] [4]

この違いから、身元の確認は役に立たないという結論にはならない。説明用に、販売経路が不明なまま異常な応答を見つけた場合、誰へ配信停止を求めるかさえ定まらない。身元が分かれば、問い合わせ、調査、契約上の対応の入口を作れる。ただし、その入口があることを、各応答の安全性まで確かめた印として販売してはいけない。異なる役割の仕組みを組み合わせるからこそ、確認できる範囲を増やせる。

媒体が自分の名前で売られる枠を把握できても、広告の購入側が後から選ぶコードまで把握できるとは限らない。取引経路の図は「誰を通ったか」に答え、実行の検査は「何が動いたか」に答える。この二枚を重ねるには、対象の広告と応答を結べる識別情報が要る。会社名の一覧だけを詳しくしても、調べたい一回の応答へ結びつかなければ、実際の異常を誰が担当するかが残る。

Xandrの共同管理者判断を扱った記事では、誰が情報処理の目的や手段を決めるかが争点となった。ここでの問いは、広告が動く際に、承認した素材と応答をどう対応させるかである。契約の法人と技術上の接続先が同じとは限らないため、取引の説明と配信の検査を接続する仕事が生まれる。この接続を具体化できる提供者には、単に承認済みという印を渡す提供者と違う価値があり得る。

6. コードが動く場所を比べる

ウェブの同一オリジンポリシーは、別のオリジンにある文書間で資源へ干渉する範囲を制限する。オリジンは原則として方式、ホスト、ポートの組合せで決まる。MDNの説明では、別オリジンの埋め込みと読み取りの許可も同じではない。別サイトから取得したスクリプトが埋込みページの文脈で動く場合もあり、取得先の名前だけでは実行時の境界は決まらない。 [5]

したがって、同じコードを調べる場合でも、どこへ置いたかが結果を変え得る。説明用に、独立した枠で動かす場合と、媒体のページへ直接組み込む場合を考える。検査で前者だけを使い、実際の掲載で後者を使うなら、確認した条件と提供した条件がそろわない。動作が悪意を持つかを議論する前に、検査結果の適用先が違うという問題が生じる。素材の一致だけでは、この差を埋められない。

独立した枠を使えば、どんな攻撃も防げるという意味でもない。防御策を評価するには、どの操作を制限するのかと、どの操作がなお必要なのかを合わせる。広告が表示されるために必要な機能をすべて止めれば、危険を減らすと同時に販売するサービスも失う場合がある。媒体にとっての課題は、働かせる機能を具体的に絞り、その範囲で利用者に価値を届けられるかを調べることだ。

通信権限と暗号の設計を扱う解説は、誰と通信できるかと、通信をどう守るかという別の問いを理解する助けになる。今回も、通信が保護されていることだけで、返ってくるコードが許容できるとは言えない。確認する単位は、相手、実行の場所、許される動作の組合せになる。暗号化という一つの機能名を、安全性全体の代用品として評価すると、購入した対策と残る危険の対応を誤りやすい。

7. iframeの制限は、機能ごとに読む

iframeはページの中へ別の文書を埋め込む仕組みだ。MDNによれば、sandboxで制約を設定でき、allow属性によるPermissions Policyは、ヘッダーで与えた機能制約にさらに制約を重ねる。制限の名前だけで効果が決まるわけではなく、指定の組合せが重要になる。同一オリジンの内容へスクリプトと同一オリジン扱いをともに許す構成には、制限を外せる危険があるという警告もある。 [6]

事業の仕様として考えるなら、「隔離している」という短い説明より、何を許した枠かを問う方が役に立つ。説明用に、表示のための描画機能を認めても、親のページへの操作を認めない構成を考える。契約の確認項目は、隔離製品を購入したかという一つの質問から、広告ごとに同じ制約が使われるか、例外がどの枠へ残るかという問いへ進む。例外のある枠へ重要な閲覧が集中すれば、平均的な適用率は安心の尺度にならない。

機能の制限には、広告の測定や見え方への影響もあり得る。そこで、機能を戻して収益を保つ判断を行うなら、戻した機能と失う防御を対応させる必要がある。単に表示が直ったことを変更の成功とすると、検査側が前提にした境界が失われても気づきにくい。確認するのは障害の有無だけでなく、例外を加えた後も、もともと制限したかった操作が制限されているかだ。

端末での制約をサービスの品質へ結びつけるには、販売する広告枠の種類もそろえたい。通常の画面内広告と、画面へ特別な動きを加える広告を一つの安全性で示すと、広い機能を必要とする方の条件が見えなくなる。提供者が商品ごとに制約と例外を説明できれば、媒体は収入の機会と引き受ける動作を比較できる。すべてを一律に許すか止めるかという二択から、実際に選べる条件へ進められる。

8. Cookie保護の属性を取り違えない

MDNは、HttpOnlyがJavaScriptによる読み取りを禁止する一方、そのCookieがJavaScript起点のリクエストへ付くことまでは止めないと説明する。SecureはHTTPSで送る条件、SameSiteは別サイトとのリクエストで送る条件を扱う。同じ安全対策という名前でまとめると、読み取りを防ぎたい場面に、通信の条件だけを変える対策を当てはめてしまう。 [7]

この違いは、広告の実行環境を変更するときに重要になる。説明用に、ある情報を読み取れないことを検査した後で、広告の置き場所だけを変える場合を考える。読み取りの境界が変わるなら、以前の確認結果を引き継ぐには追加の説明が要る。Cookieの名前を変えることや送信の経路を暗号化することだけでは、その説明を代替できない。どの情報へどの仕組みで届くかを、変更前後で比べる必要がある。

ただし、読めるCookieがあったという事実だけで、すべてのアカウントが乗っ取られると結論するのも早い。Cookieが担う役割、有効期間、利用できる範囲などによって意味は変わる。広告の識別と、ログインの状態を表す情報を同じ被害金額へ換算することはできない。技術担当が得た情報を経営判断へ伝える際は、読み取れる項目の一覧から、業務上の機能と追加調査の必要範囲へつなぐことになる。

ここでは、対策を足した数より、残る経路を説明できるかが品質になる。複数の属性が付いていても同じ経路ばかりを守るなら、別の操作は残り得る。反対に、一つの設定でも、実際に問題となる読み取りを抑えられるなら意味がある。導入した製品名や設定数を積み上げて評価する方法では、守る対象との対応が見えない。防御の購入仕様には、製品の数より、確かめる操作と適用する場面を置く方がよい。

9. CSPで観測する段階と、止める段階

GoogleのPublisher Tag向け文書は、Content Security Policy（CSP）というリソースの読込みやスクリプトの実行を制約する仕組みを説明する。導入前のReport-Onlyは違反を報告するが、実行を止めない。同文書はstrict CSPと、広告を別ドメインのSafeFrameへ置く構成を案内し、一部の予約型広告ではその変更によって動作しなくなる可能性も示す。観測、制約、互換性の確認には、それぞれの段階がある。 [8]

事業者が試行期間を設けることには理由がある。停止する対象を知らずに強い制約を入れれば、必要な機能を失う可能性があるからだ。一方、報告だけの期間が長く続けば、制約を入れたという社内説明と実際の動作に差が生じる。進捗を示すなら、設定を置いた日だけでなく、どの対象で制約が有効になったかを示したい。観測した異常を、誰がどの条件で停止へ進めるかも運用費用の一部になる。

さらに、許可した相手が後から返す内容を変える場合、接続先の一覧を狭めるだけで十分かという問いが残る。許可する先を決める検査と、そこから返る内容を確かめる検査は補完的になる。前者は接続の広がりを抑え、後者は残した接続の動作を調べる。どちらかの実施件数を増やすだけで他方も済んだと考えると、取引先が想定した保証範囲と、実装された保証範囲がずれる。

媒体が費用を比べる単位も、設定を配るだけの場合と、誤った停止を見つけて調整する場合では異なる。前者は導入の作業量、後者は継続的な判断の作業量に左右される。導入費が安くても例外の調整が多ければ、運営に使う人員が増える可能性がある。逆に、提供する広告形式を限定して判断を減らせれば、機能の広さを競わないサービスにも事業上の余地が生まれる。

10. SG Groupの見方：観測の単位を買う

第一の分析は、検証サービスの単位を「一つの素材」から「素材と受信条件の組合せ」へ広げることだ。これは広告市場でその価格体系が既に普及しているという主張ではない。条件ごとに内容が変わる仕組みに対し、何を買えば確認範囲を増やせるかを考える提案である。確認した組合せと、結果を適用する組合せを対応させると、費用をかけた場所と残る空白を説明しやすくなる。

説明用に、広告を二種類、受信条件を三通り、時点を二つに分けると、比較する組合せは十二通りになる。各素材を一回ずつ見た二回の検査は、素材の種類をすべて含んでも、十二の組合せを覆わない。同じ条件の二回を追加しても、未観測の組合せは残る。この単純な掛け算は、実際の攻撃確率や全世界の端末の数を示さない。検査の網羅性を説明する際、何を分母に選んだかを可視化するための例だ。

網羅性を増やす方法にも複数ある。素材の種類を増やす方法、同じ素材を別の条件で調べる方法、一定時間後の変化を調べる方法だ。予算の配分は、残る疑問に合わせる必要がある。新しい素材が少ないのに素材数だけを増やす仕様を買えば、条件による応答差の検査には届きにくい。反対に、素材が頻繁に変わるのに一つの素材だけを細かく調べれば、新しい素材の動作が空白になる。

そのため、検査会社の比較表には、何件処理したかに加え、条件を選ぶ方法と更新する基準を置きたい。費用が高いサービスでも、同じ範囲の反復だけなら説明力は弱い。費用が低くても、対象を絞り、結果を適用する範囲を明確にできれば、限定した目的には有効かもしれない。品質を価格から独立して最大化する話ではなく、必要な疑問に答えるための観測をどの価格で買えるかという比較になる。

検証を広げる際には、観測用の情報をどこへ集めるかという別の費用もある。説明用に、端末を区別する番号をそのまま多数の検査会社へ渡す構成を考える。検査は増やせても、情報を扱う相手も増える。端末内で判定して必要な結果だけを伝える方法と、詳細な応答を中央へ集めて比べる方法では、見える範囲と管理する情報が異なる。発注者は、観測の広さだけでなく、その観測が新たに作る情報の集まりも購入仕様へ含める必要がある。

11. 異常が少ないサービスは、何を見ているか

第二の分析は、異常の少なさと、見逃しの少なさを同じ品質として売らないことだ。広告の配信を止めると、正当な取引まで失う場合があるため、誤った停止を減らす価値はある。しかし、異常を報告しないだけの仕組みでも、停止件数は少なくなる。媒体が欲しいのは単に仕事が増えないことではなく、必要な広告を残しながら不適切な動作を抑えることだ。この二つの成果を別に測れる購入仕様が求められる。

説明用に、同じ広告群を扱う二つの検査サービスを考える。一方は疑わしい応答を早く止め、もう一方は詳しい確認まで配信を続ける。前者は正当な配信を止める費用、後者は調べる間に露出が続く費用を持つ。この選択を一つの検出率へ押し込むと、停止までの時間と、間違いを戻す時間が隠れる。広告枠の一回の価格だけを見ても、継続する露出への対処条件は比較できない。

これを契約へ落とし込むなら、停止できる単位が重要になる。ある素材だけを止めるのか、接続先を止めるのか、広告枠全体を止めるのかで、正当な取引への影響が違う。細かく止められるほどよいと自動的には言えない。異常を結びつける識別情報が不足すれば、細かい単位で止めても別の経路が残る可能性があるからだ。停止の細かさと、同じ問題をまとめて把握する力を、対として評価する必要がある。

一つの配信事業者が手元で止めたことと、同じ相手の活動が他社でも止まったことは異なる。侵入基盤への法執行を扱う記事は、共通の基盤へ介入する別の方法を説明している。広告市場では、事業者が共有する情報が具体的な取引や応答へ結びつくほど、各社が同じ調査を繰り返す無駄を減らせる可能性がある。一方、停止情報の誤りが広く共有される費用もあるため、異議や再確認の経路が必要になる。

12. 広告を受け取る側の目的も異なる

第三の分析は、広告枠を売る媒体と、仕事用の端末で情報を読む組織の判断を分けることだ。媒体は広告を届けることで収入を得る場合があるが、閲覧する組織はその広告収入を受け取るとは限らない。両者が同じ通信から得る便益は異なる。したがって、広告を止める費用と受け入れる費用を比べるとき、誰の収支を見ているかを明らかにする必要がある。社会全体の費用を一社の損益へまとめることはできない。

閲覧側の組織が機能の少ない環境を選ぶことは、広告事業全体の技術が無価値だという判断ではない。仕事で必要な情報を得るため、余分な動作を減らすという用途別の選択である。逆に、媒体が広告の機能を残したいと考えることも、無制限に動かすべきという結論にはならない。同じページでも利用する仕事が違えば、受け入れる機能の範囲は変わる。市場は一つの品質水準へ揃うより、目的別に分かれる可能性がある。

こうした選択が広がるなら、広告主は、従来届いた相手へ同じ形式で届くかを検討することになる。媒体は広告の数量だけでなく、届けられる環境に合う形式を用意する必要があるかもしれない。これは支出が必ず消えるという予測ではない。機能の少ない広告、直接の掲載契約、広告以外の収入などへ選択が移る経路を考えるものだ。実際の移動を判断するには、購入条件と配信先の変化を観察する必要がある。

一方、安全な配信の条件を説明できる媒体が、かえって選ばれる可能性もある。広告主が意図しない動作を避け、掲載先との関係を保つ価値を評価するなら、単なる最安の枠とは違う比較が生まれる。ただし、その価値を価格へ反映できるかは、代替の枠と購入者の判断に左右される。サイバー防御需要から株主の現金までを読む記事と同様に、必要性の増加だけで特定企業の利益増加を確定させることはできない。

13. 公表の日と、観測した期間をそろえる

研究報告を受けて市場の変化を考える際には、調べた期間と、判断材料が公に加わる日を分ける。過去の配信を後から詳しく調べた結果は、現在のサービスを選び直す理由になり得るが、同じ動作が今この瞬間も続くことの証明とは限らない。過去の観測、現在の対応、残る経路を一枚の時系列へ押し込むと、対応後の状態まで過去の数字で説明してしまう。時点をそろえることが、収益の仮説を更新する前提になる。

当時の情報と現在の判断を区別する解説は、こうした比較の基礎になる。調査が詳しくなるほど、過去について分かることも変わる。経営側が以前の購入判断を評価するとき、後から知った材料だけで当時の選択を採点すれば、実際に改善すべき情報収集の工程を見失う。どの時点でどの資料が利用でき、何を約束した契約だったかへ戻すことで、次の更新条件を具体的に変えられる。

過去に配布したソフトを調べるGitLabの記事と、設定から実行へ進むWindowsの記事も、異なる時点の証拠を扱う。ただし、広告の受信条件ごとにコードが変わる問題では、同じ版を保持するだけでは足りない場合がある。素材の版と応答の時点を合わせ、どの受信条件を観測した結果かまで結ぶ必要がある。この追加の対応関係が、従来の版管理から広がる仕事であり、検査サービスの範囲を説明する鍵になる。

14. 三つの経路で、何を待つか

条件付きの第一の経路は、既存の検証サービスが、応答の違いを比較する機能を取り込み、媒体が広告形式を大きく変えずに使い続ける場合だ。ここで見るのは、新しい検査機能の発表だけではない。どの条件で使われ、停止する範囲がどのように変わったかという実績である。追加料金が発生しても、異常な配信の調査や例外処理が減れば、利用者側の総費用は同じ方向へ動くとは限らない。

第二の経路は、確認できる条件を限定した広告商品へ需要が移る場合だ。機能を減らしても目的の相手へ届くなら、広告主は詳しい検証を毎回買うより、単純な仕様を選ぶかもしれない。この見方を支持するのは、形式を絞った商品の購入や、媒体が提示する条件の変化だ。逆に、失う機能によって成果が大きく落ち、従来の形式へ戻るなら、この経路は弱まる。単純化の便益は、成果を保てることを条件にする。

第三の経路は、閲覧側の制限が強まり、配信の確認だけでは届かない環境が増える場合だ。媒体には収入を守るための別の形式や提供方法が必要になる可能性がある。ただし、確認できる品質を高めた媒体まで同じように不利になるとは限らない。ここで見るのは、広告を止める方針の発表に加え、どの閲覧用途へ適用され、どんな代替が認められたかだ。すべての端末を一つの反応としてまとめると、需要の移動先を見失う。

15. 次の比較は、保証の範囲から始まる

この見方への反証は、受信条件による動作差が、既存の検査と制約の組合せで十分に管理でき、追加の観測が判断をほとんど変えないという結果である。その場合、毎回より多くの条件を検査する費用は正当化しにくい。一方、同じ素材で結果が大きく分かれる実例が増え、従来の承認から外れる動作が続くなら、観測範囲を広げる必要性は強まる。必要性の強さは、検査回数の宣伝からではなく、比較可能な結果から判断する。

実損額、現在残る活動の全体像、追加検証の費用を誰がどの割合で負担するかは、この二つの研究報告だけからは決まらない。これらを判断する材料は、端末の調査結果、対応後の観測、実際の契約条件だ。会社が調査や対策を進める際、費用だけを削ると観測の空白を増やす場合があり、機能だけを増やすと確認の対象も増える。その交換条件が示されて初めて、サービスの価値を同じ物差しで比較できる。