← ブログ

集計レポートから個別の決定へ:DSA透明性データベースを追加する

EU DSA VLOP データ エンジニアリング
クエリ可能になったEU DSA透明性データベース

VLOPダッシュボードはこれまで、EUデジタルサービス法(DSA)の集計された透明性レポート——プラットフォームが6か月間にカテゴリ別に受け取った通知の件数と、対処したコンテンツの件数を報告する定期的な提出物——を扱ってきました。これはDSAが持つ2つの透明性メカニズムのうちの1つです。今回のアップデートでは、もう1つのメカニズムを追加します。これはまったく性質の異なるもので、理由説明書(Statements of Reasons)のDSA透明性データベースです。

理由説明書とは何か

DSA第17条のもとでは、対象となるプラットフォームがコンテンツを制限する——削除する、アクセスを無効化する、表示を抑制する、年齢制限をかける、収益化を停止する——たびに、その決定を説明する「理由説明書」を影響を受けたユーザーに提供しなければなりません。そして、そのコピーを、個人情報を取り除いたうえで、欧州委員会が運営する公開の透明性データベースに提出しなければなりません。

集計レポートは、あるプラットフォームが報告期間中に何をしたと述べているかを示します。透明性データベースは個別の決定そのもの——モデレーションアクション1件につき1行、発生時点で提出され、カテゴリ、法的根拠、自動的に検知されたかどうか、決定が自動化されていたかどうか、どの制限が適用されたかといった構造化されたフィールドを備えています。EU全域のコンテンツモデレーションについて、リアルタイムで決定レベルの記録に最も近いものです。

それはまた膨大です。プラットフォームは月に数十億件規模の説明書を提出しています。全履歴のダンプは約4テラバイトあり、日々増え続けています。

4テラバイトをダッシュボードに載せることはできない

そこで興味深いエンジニアリング上の問いは、4テラバイトの日次CSVダンプから、背後に分析用ウェアハウスを置くことなくインタラクティブなクエリインターフェースに収まるものへと、どうやって到達するかでした。

その答えは、委員会自身のツールにありました。データベースとあわせて、DSAチームはオープンソースのPythonツールボックスdsa-tdbを公開しており、これは日次ダンプをダウンロードして検証し、そして——決定的に重要なことに——事前計算された月次集計を公開します。生の説明書の代わりに、プラットフォーム・日・カテゴリ・決定根拠・自動化・制限タイプの細かい組み合わせごとに、件数付きで1行を取得できます。それは生の奔流ではなく、1か月あたり約7メガバイトのgzip圧縮CSVです。

そこから先は再集計の問題です。日次集計を月単位にまとめ上げ、いくつかの1次元の切り口——総説明書数、カテゴリ別、決定根拠別、自動化別、制限タイプ別——に折りたたみ、件数上位60プラットフォームを残します。これらは全説明書の約99.97%を占めます。結果として得られるのは整然としたロングフォーマットのテーブルで、およそ24,500行、約2メガバイトのJSONであり、2023年9月から現在までをカバーします。これは他のすべてのデータセットと同じ読み取り専用のSQLiteデータベースにベンダリングされ、通常のクエリ可能なテーブルとなって、サイトの他の部分と同じ構造化されたノーSQLのクエリインターフェースから到達できるようになります。

その形はどう見えるか

まず気づくのは、その量がいかに偏っているかということです。あるプラットフォーム——Google Shopping——がデータベース内の全説明書の大多数を占めており、月に数億件に達し、そのほとんどはマーケットプレイスの対象外として削除された商品リスティングです。TikTok、Facebook、Pinterest、Amazon、AliExpressが残りの大部分を構成します。少数のマーケットプレイスと大規模なソーシャルプラットフォームが支配的であり、何百もの小規模提出者からなるロングテールは誤差の範囲です。

それを超えると、決定レベルのフィールドによって、集計レポートがきれいには見せてくれないものが見えてきます。法律のもとで違法として制限されたコンテンツと、プラットフォーム独自の規約に適合しないとして制限されたコンテンツの内訳(圧倒的に後者)、完全に自動的に下された決定と人間が関与した決定の割合、そしてその月の決定が実際にどのDSA説明書カテゴリを挙げているか。/dsa-dbページは、月次総数、時系列での上位プラットフォーム、カテゴリの構成、そして違法か規約かという根拠をグラフ化し、その下にプラットフォーム別のテーブルを配置しています。

同じ注意点が、より鋭く

集計レポートの限界について書いたことはすべてここでも当てはまり、さらにいくつかの新しい点が現れます。カテゴリ定義は依然として各プラットフォーム独自のものなので、プラットフォーム横断のカテゴリ比較は、一貫したものではなく、プラットフォームが定義した構成概念同士の比較です。データは依然として自己申告であり、監査もされていません。

そして集計にはそれ自体の落とし穴があり、クエリインターフェースはそれについて警告します。単一次元の切り口はそれぞれ同じ説明書の集合を分割しているため、カテゴリの内訳を合計するとそのプラットフォームの総数に戻ります——つまり、内訳を総数と一緒に合計すると二重計上になります。制限タイプの切り口はマルチセレクトです。1つの決定がコンテンツの削除とアカウントの無効化の両方を行うことがあるためで、それらの行はまったく総数に合計されません。そして、少数のマーケットプレイスが量をあまりに大きく支配しているため、ほとんどのプラットフォーム横断の合計は、実際にはただGoogle Shoppingを測っているだけになります。実用的なルールは、インターフェースが促してくるものと同じです——何かを集計する前に、セクションを固定し、たいていはプラットフォームも固定することです。

同じ法律への2つのレンズ

両方のデータセットを1か所に持つことで私が気に入っているのは、それらが異なる問いに答えるという点です。集計レポートは、あるプラットフォームが期間中に何をしたかを、そのプラットフォーム独自のカテゴリでまとめた自身の要約であり、公開前に法務・ポリシーチームによってレビューされています。透明性データベースは、個別の決定の生のストリームであり、すべての者に対して同じように構造化され、継続的に提出されます。どちらも他方の代わりにはならず、両者の間の食い違いこそがしばしば興味深い部分です。それらを同じクエリインターフェースの背後で並べて置くこと、それが要点です。

esc