「自主対応」の二つの解釈 — DSA表6と、全VLOPが選んだ読み方

DSAの表6は、プラットフォームが「自主対応」で行ったコンテンツモデレーションの報告を求めている。この語は狭くも広くも読める——そして最初の調和化報告書で、狭い解釈のまま提出したVLOPは一つもなかった。

結論：表6の「自主対応」は二通りに読める。狭い解釈では、プラットフォームは自ら能動的に——自動的に——検知して措置したコンテンツのみを報告する。広い解釈では、加盟国命令や第16条通知によらずに自ら開始したすべてのコンテンツモデレーションを、人手・機械いずれの検知かを問わず報告する。両解釈は桁違いに異なりうる。最初の調和化報告期間（2025年下半期）において、狭い解釈で提出したVLOPは一つもなく、データで判別できるすべてのケースが広い解釈を示した——見出しの自主対応の数値はプロバイダ起点の利用規約エンフォースメントの全体であり、能動的／自動検知はその中の入れ子の内訳として現れるにすぎない（プラットフォームにより総数の0％〜約99％）。

• データ出典：Transparency Report API（transparency.kieranmaynard.com）のt6_own_initiative_tos、報告期間2025年下半期（2025-07-01 → 2025-12-31）——調和化テンプレート下で最初の期間。VLOPサービス24件／親プラットフォーム18社。
• 法的枠組み：欧州委員会実施規則(EU) 2024/2835、附属書シート6_own_initiative_TC（DSA第15条(1)(c)）。

---

1. テンプレートが実際に求めるもの（定義上の答え）

表6はカテゴリごとの単一の数値ではない。各カテゴリ行は二つの別個のカウント列を持ち、実施規則に逐語的に定義されている：

したがって表6の範囲は、検知方法によってではなく、除外（命令起点でも通知起点でもない）によって定義される。「自主対応」（F列）と「能動的／自動検知」（G列）は直交する：

• 自主対応＝措置を誰が開始したか（命令やユーザー通知ではなく、プラットフォーム自身）。
• 能動的検知＝コンテンツをどのように発見したか（もっぱら自動化された手段）。

プラットフォームは人手のレビューによって自主対応を行うこともでき（G列ではなくF列に計上）、G列はF列の部分集合にすぎない——APIのフィールド定義自体がこれを言い換えている：measures＝「自主対応モデレーション措置の件数」、automated＝「そのうち自動化された手段で講じられた件数」。

これが解釈の分岐点である。広く読めば、F列はすべての自主対応措置を（その指示——「措置の総件数」——のとおり）記載し、G列はそのうちどれだけが自動だったかを示すにすぎない。狭く読めば——「自主対応」を「能動的に捕捉したもの」の略と捉えれば——プラットフォームは自動検知の数値のみを報告することになる。F列の文言は広い解釈を指し示す。プラットフォームが実際にそれに従ったかは実証的な問いであり、以下で決着する。

---

2. VLOPが実際に報告した内容（実証的な答え）

2025年下半期のサービス別TOTAL行。F列＝自主対応措置、G列＝もっぱら自動検知。最終列は範囲の診断：14種類の制限タイプ列（削除、アクセス無効化、降格、年齢制限、ラベル付け、停止、終了…）の合計をF列で割ったもの。

サーフェスはスキーマの規則（「'All' はサーフェス横断の合計——サーフェス別行と合算しない」）に従って処理：サーフェス別に報告するGoogleのサービス（検索、マップ、Play、YouTube）はサーフェス横断で合算し、その他のサービスはサーフェス横断の 'All' 合計を単一で報告する。なお、Google検索のサーフェス別行（ドメイン・ホスト・URLレベル…）は厳密には加算可能な単位でない可能性があり、その合算値は目安である。

狭い解釈を排除する二つの事実

1. 全行でF列 ≥ G列。いずれのプラットフォームも自動検知の数値を自主対応の総数として報告していない。狭い解釈（表6＝能動的検知のみ）であればFはGに等しくなるはずだが、そうなることは決してない。
2. 制限タイプの内訳はG列ではなくF列と整合する（比率≈24サービス中23で1.00）。14の制限タイプ列は検知方法とは独立に措置単位で報告される。それらは自主対応の総数（F）に合算される。これは一部にはテンプレート上の算術である——制限列はFに合算されるよう設計されており、丁寧な提出者はいずれの解釈でも整合する——が、Fが切り詰められた数値ではなく一貫した措置カウントであることを確認でき、合算が合わない唯一の提出（Bing）を検出する。Fが実際に何を含むかの独立した証拠は、§4のSoR照合である。

これらは提出内容の面で狭い解釈を排除する。Fがプロバイダ起点の利用規約モデレーションの全体を含むことの積極的な確認は、§4の独立したSoR照合による。

自動化の割合は大きく異なる——そこが要点

G列は真の内訳であるため、F列に占めるその割合は範囲設定の産物ではなく、実際の行動シグナルである：

• 自動化優位（≈90〜99％）：Pinterest、XNXX、AliExpress、X、Google 検索／マップ／Play、YouTube——ほぼ全面的に自動検知だが、それでもFはGを上回る。
• 混合（〜60〜90％）：TikTok、Meta、Temu、Snap、LinkedIn、App Store。
• 人手検知が多い（F ≫ G）：Amazon 15.7％、Booking.com 7.3％、Zalando 22.3％、Pornhub 0.04％、SHEIN 0％。これらのプラットフォームは大きな自主対応総数を報告しているが、そのうちもっぱら自動検知だったものはごくわずか、あるいは皆無である——これはF列が人手／手動で検知された措置も数えているからこそ可能となる。これらは広い解釈の最も明瞭な事例であり——狭い解釈であれば、それらの表6の数値は報告値のごく一部にまで縮小するはずである。

同じ構造は違法コンテンツのシート（t5）でも成り立つ：measures ≥ automated が全体で成立する（例：Googleは自主対応の違法コンテンツ措置を27億件報告、SHEINはここでも automated ＝ 0 と報告）。

---

3. 留意点とデータ品質に関する注記

• 「措置」と「理由説明書」。表6は措置／アクションを数えており、それらは自主対応の利用規約に基づく理由説明書（SoR）を生む出来事である。両者はSoRを生む母集団だが、必ずしも1対1ではない（一つのSoRが複数の制限を束ねうるし、アカウント単位や明白な違法コンテンツに対する一部の措置は個別のSoRを生まないことがある）。「F＝自主対応の全体」という所見はいずれにせよ成立する。
• Bingは唯一の整合性の外れ値（制限合計 ÷ 措置 ＝ 0.92）：その提出には measures ＝ 7,220 でありながら制限列の合計が152（＝自動検知数）にとどまるエントリがある。これはBing自身の報告における内部的な不整合であり、異なる範囲設定の選択ではない。Microsoftの他サービス（LinkedIn）はきれいに整合する。
• null と 0 の区別。Googleの「Multi-Services」行やいくつかのGoogle検索サブサーフェスは、G列を 0 ではなくnull（未報告）としている。SHEINおよびGoogleのt5は明示的な0を報告している。「未報告」と「自動ゼロ」は区別して扱うこと。
• 軽微な過不足（TikTok 1.01、Snapchat 0.97、AliExpress 約1.003）は約1〜3％以内で、一つの措置が複数の制限タイプを伴うことと整合しており、結論を変えない。
• 比較可能性。数値は2025年下半期のVLOP提出のみ（report_tier = vlop）。同じ表の非VLOP提出者は異なる期間で報告しており、除外した。

---

4. 外部からの裏付け：DSA理由説明書データベース

透明性報告書は自己申告である。DSA透明性データベース（理由説明書）は独立した情報源であり、対象プラットフォームが行う各モデレーション決定は個別のSoRとして提出され、各SoRはsource_type（自主対応を含む）とautomated_detection（Yes/No）を別個のフィールドとして持つ。委員会自身のdsa-tdb再集計（dsa_tdb_metrics、同じ2025年下半期の期間）を用いて、これらの周辺分布は報告書の所見を外部から検証する。

全体（全プラットフォーム、2025年下半期）：二つの母集団は明らかに規模が異なる——

• source_type = Own-initiative：3,633,572,041件のSoR
• automated_detection = Yes：3,150,399,935 ・ No：527,615,482

自主対応は自動検知を約4.8億件上回り、5.28億件のSoRは非自動である。すなわち生の提出データにおいて「自主対応」は「能動的検知」より厳密に大きな集合であり——報告書の Col F ⊇ Col G が符号化する関係と同じである。

サービス別——表6の数値は自主対応と自動検知のどちらを追うか？報告書のFを、各サービスのSoR自主対応件数およびSoR自動検知件数と比較する：

裏付けとなる二つの結果：

1. 規模。整合が明瞭な例では、報告F ≈ SoR自主対応：Google Shopping 1.00×、Google Maps 0.98×、Amazon 1.03×、Instagram 1.05×、Facebook 0.93×、Pinterest 1.09×、Booking 1.18×。Fは自主対応のSoR母集団と整合し——その能動的検知の部分集合とは整合しない。
2. 判別。SoR自主対応と自動検知の母集団が20％超乖離する5サービス（判別が実際に可能なケース）では、5件中5件でFは自主対応に近い。最も明瞭なのはPinterest：F＝1.84億はSoR自主対応1.69億と一致し、SoR自動検知160万とは一致しない。Pinterestが表6を能動的検知に絞っていたなら約160万を報告するはずだが、1.84億を報告している。SHEIN、Pornhub、XVideos、Google Playも同じ判定。（残りのサービスは広い解釈と整合するが、二つのSoR母集団が近接しすぎており判別はできない。）

留意点（なぜこれが裏付けであって突合ではないか）：

• 二つのシステムは異なるものを数えている。報告書は措置／アクションを、データベースは理由説明書を数える。両者が正確に一致するとは期待されず、大きく乖離する例もある：Temu（報告7.68億 対 SoR 1.34億）、SHEIN（270万 対 9万）、Snapchat（1,130万 対 240万）、X（2,090万 対 わずか20万——XはSoRをほとんど提出していない）。これらは既知の報告書対データベースの差（計数単位、重複排除、タイミング、過少提出）であり、範囲設定には影響しない——範囲の検証はFがどのSoR母集団を追うかのみを問うており、これらのケースでも自主対応を追っている。
• G列 ≠ SoR automated_detection=Yes。報告書のG列はもっぱら自動化された手段だが、SoRのフラグはコンテンツ特定にいずれかの自動化された手段が用いられた場合を指す（部分自動を含む）。これが、AmazonやBookingで報告書の自動化割合がSoRの自動化割合を下回る理由である（Amazon 16％ 対 88％、Booking 7％ 対 95％）。Pinterestは逆（報告書99％「もっぱら自動」対 SoR 0.9％の自動検知）——これは二つのシステム間のPinterest自身の提出における内部的不整合であり、留意に値するがF列の範囲の問いには影響しない。
• これらは周辺分布の切り口である（集計にsource×automation×groundの結合はない）ため、検証は正確なセルではなく規模と分割に対して行う。

したがって独立したSoRデータは核心的な所見を裏付ける：表6の自主対応の数値は自主対応の全母集団であり、能動的／自動検知はそれとは別個の、概して小さな部分母集団である。

---

5. 範囲の境界：ユーザー報告は「自主対応」か？

F/Gの所見の下には、より根本的な問いがある：そもそも何が自主対応に当たるのか？その答えは明快ではなく、テンプレートの最も脆弱な継ぎ目である。

除外は狭い。F列が除外するのは二つの契機のみ——加盟国命令か、「第16条に規定する通知・行動メカニズムを通じて提出された通知」である。そして第16条のメカニズムは、その文言上、ユーザーが「違法コンテンツであると考える」コンテンツの通報のためのものであり——「あなたのコミュニティ規範に反する」という報告の経路ではない。したがってユーザー報告は三つに分かれる：

1. ユーザーが通知・行動メカニズムを通じて違法コンテンツを報告 → 第16条通知 → 表6の対象外（表4に属する）。
2. ユーザーが第16条の違法コンテンツメカニズムを通さずに利用規約／コミュニティ規範違反を報告 → 第16条通知ではない → F列の文言では除外されない。
3. 混合型の報告フロー → プラットフォームの分類次第。

カテゴリ2については、そうした報告を表6の内側に置く二つの文理的論拠がある：(i) 明示は他を排除する（expressio unius）——定義は除外として命令と第16条通知のみを列挙しており、それ以外は切り出されていない。(ii) 網羅的分類——DSA第15条(1)はすべてのモデレーションを命令（表3）、第16条通知（表4）、または自主対応（表5〜6）に振り分けており、非第16条の利用規約報告は前二者のいずれにも当てはまらない。反対解釈は経路ベース（報告ボタン経由の通知はすべて除外）で、「自主対応」の直感的な意味には合うが、運用上の定義が述べるところではない。委員会はこれを解決しておらず、研究者はこれを報告書間の調和化の乱れとして指摘している。

実証的には、VLOPは大半を包括的に処理している——ただし分類は著しく不統一である。SoRデータベースのby_source_typeのサービス別切り口（2025年下半期）を用いると：

これには二つの読み方がある：

• 「非第16条の利用規約報告」という特定の隙間は、VLOPにとっては小さい。これらのサービス全体でother-notificationは分類済みSoRの0.03％——大半のプラットフォームはほぼすべて（≥99％）を自主対応に含めており、既定で包括的な解釈を採っている。したがって大手プラットフォームの表6はユーザー申告の利用規約措置をすでに吸収しており、この曖昧さが見出しの数値を変えることはまれである。明瞭な例外はPornhub（その他の通報16.3％）で、その表6の数値は自主対応＋その他の通報を追っている（F ≈ OI+ON、比率1.00）——文理的解釈を明白に採っているプラットフォームである。
• しかし分類そのものが著しく不統一であり、これが真の比較可能性の問題である。「ユーザーが申告したか？」という同じ問いが、三通りの相容れない仕方で答えられている：大半のプラットフォームはほぼ100％を自主対応と分類し、Xは100％をその他の通報と分類し、Snapchat（72％）とXVideos（86％）は大半を第16条通知として振り分ける。まったく同じ実態の行動が、あるプラットフォームでは表6に、別のプラットフォームでは表4に入ることになる。曖昧さは消えず——source_typeの分類という一段上の層に移り、自主対応と通知の切り分けのクロスプラットフォーム比較可能性を損なう。

留意点：source_typeは各プラットフォームの自己分類であり、大半のVLOPでほぼすべてが「自主対応」であることは、真に自発的な検知というより分類上の慣行を一部反映している可能性がある。Xは表6の措置（2,090万）に比してSoRの提出が極めて少なく（20万）、その100％「通報」プロファイルは代表的ではない。周辺分布の切り口のみ。

---

6. 結論

表6の「自主対応」が狭くも広くも読めるところで、狭い解釈のまま提出したVLOPは一つもなく——独立データで検証できるすべての提出が広い解釈を示した。検知の軸（§1〜2）では、見出しの数値はプロバイダ起点の利用規約エンフォースメントの全体——人手・機械いずれの検知かを問わず——であり、能動的検知の部分集合ではない。自動検知は入れ子の内訳（G列）としてのみ開示され、プラットフォーム全体で総数の0〜99％を占める。そして制限タイプの内訳が（自動の内訳ではなく）自主対応の総数と整合することが、狭い解釈を排除する。より難しく、真に未確定の情報源の軸（§5）でも、大半のVLOPは同様に、ユーザー申告の利用規約措置を通知として扱うのではなく自主対応に含めている。

だがこれは実務上の収斂であって、明確な法的命令の収斂ではない。規則は検知方法については広い解釈を強制する（F列の「総件数」の指示）が、情報源の境界は開いたままにしており——そこではプラットフォームの分類が著しく分かれる（§5）。表6はそのように読むべきである：クロスプラットフォームの比較可能性が、テンプレートが完全には確定していない解釈的選択に依存する、広い自主対応の集計値として。

データ：t6_own_initiative_tos ／ t5_own_initiative_illegal、Transparency Report API、生成日2026-05-13、期間2025-07-01/2025-12-31。法令：規則(EU) 2024/2835、附属書シート5〜6、DSA第15条(1)(c)。