方法論

これは何か

これは公開された透明性レポートデータを独立して非公式に集約したものであり、いかなるプラットフォーム、企業、政府とも提携していません。2つのレポート群を1つのクエリ可能なスキーマにまとめています：

• EU DSA 透明性レポート
  プロバイダーがEUデジタルサービス法（DSA）に基づいて公開する定期的なコンテンツモデレーション統計です。これは、DSA第15条・第24条・第42条（それぞれ仲介サービス、オンラインプラットフォーム、超大規模プラットフォームに課される報告義務）が義務付ける定期的な透明性レポートであり、個別の理由説明書（Statements of Reasons）を扱う別個のリアルタイムなDSA透明性データベースとは異なります。提出者は共通の階層型EUテンプレートを使用し、各プロバイダーは自らの階層が求める報告セクションのみを記入します（本データセットでは、それらのセクションを内部的にt3〜t11として索引付けしています）。対象には、EU域内でのリーチを理由として欧州委員会が正式に指定した超大規模オンラインプラットフォームおよび検索エンジン（VLOP / VLOSE）が含まれ、これらはより頻繁かつ詳細に報告するほか、数十の小規模プラットフォームも対象となります。最新の件数および対象期間については、DSA レポートダッシュボードをご覧ください。
• Google 政府による削除要請
  国・製品・理由・レポート期間ごとに集計された、コンテンツ削除を求める政府からの要請件数に関する Google の報告です。これは DSA に基づく提出ではなく、Google が長年にわたり自主的に公表してきた透明性レポートです。Google の削除要請 ダッシュボードでご確認いただけます。

各プラットフォームが元となるレポートをどこで公開しているかは、レポートの掲載先ページにカタログ化されており、ソースファイルのアーカイブコピーへのリンクも掲載しています。

データの出所

すべての数値は、それを公表したプラットフォームまたは企業に由来します。これらは 各社が 報告した数値であり、報告された値を改変することなくそのまま再掲したものであって、本プロジェクトが算出した推計値ではありません。本プロジェクトの貢献は 集約と構造化 にあります。すなわち、個別に公表されたレポートを収集し、その表を抽出し、比較・検索できるよう一つのスキーマへ正規化することです。報告された値そのものは決して編集されません。変換はあくまで構造的なもの、つまり抽出、集計合計行のフラグ付け、複数言語にまたがるラベルの正規化、そして解析できない行の除外であり、以下で説明します。

レポートがクエリ可能になるまで

各ソースレポートの表は抽出され、API が読み取り専用（多層防御）で開き、読み取りはできても書き込みは決してできないインターフェースを通じてのみアクセスするデータベースに読み込まれます。これはスタースキーマとして構成されており、DSA レポートの表ごとに 1 つの数値テーブル（内部的に t3–t11 として索引付けされます）があり、その周囲を共有のルックアップテーブル（サービス、カテゴリ、セクション、指標、スコープ、サーフェス、報告期間）が囲んでいます。繰り返し現れるラベルは一度だけ保存されて番号で参照されるため、同じカテゴリ名やプラットフォーム名は 1 か所にのみ存在します。出来上がった各テーブルと、クエリ可能なすべてのフィールドはスキーマページでご覧いただけます。

9つのレポートテーブルは次のように対応します。t3 加盟国による命令 · t4 通知（信頼できる通報者を含む） · t5 / t6 自主的措置（違法コンテンツ / 利用規約） · t7 不服申立てと再犯 · t8 自動化手段の利用 · t9 人的リソース · t10 平均月間アクティブ利用者数 · t11 定性的な説明。

報告書がテンプレートに合わない場合

ほとんどのプラットフォームは11セクションの固定ワークブックを提出し、ローダーは各シートをその名前に含まれるセクション番号に従って配置します。一部はフォーマットの異形を提出します。基になるテンプレートの内容は同じですが、シートの名前が変更されていたり、番号が振り直されていたりします。これらは、各シートを正規のセクションに対応づけるプラットフォームごとの明示的な対応表によってマッピングされるため、数値は引き続き正しい報告書テーブルに収まります。LINE はテンプレートを5つの番号なしシートに集約しており（セクション 1・3・4・5・11 に対応）、一方 Discord は違法コンテンツに関する自主的措置、人的資源、アクティブ利用者のセクションを省略して残りの番号を振り直しているため、そのシートは名前で対応づけられます（たとえば「Own Initiative TC」は、セクション5ではなくセクション6、すなわち利用規約に関する自主的措置のテーブルです）。そもそも調和テンプレートではない文書は、無理に当てはめることはしません。対応づけると元データにない構造をでっち上げることになるためです。heise のフォーラム報告書はドイツ語の自由記述カテゴリを用いた第15条の短い自由形式の要約であり、WordPress.com は別種の報告書（DMCA・政府・IRU の各リクエスト）を公開しています。これらは t3–t11 に読み込まず、アーカイブ済みのソースファイルとして保管します。

二重計上の回避

DSA テンプレートでは、集計された合計行が、それが合算する内訳行のすぐ隣に配置されています（例えば、カテゴリ別の件数の隣に総計の「All the entries」カテゴリがあったり、是認/取消の結果の隣に「Total number」スコープがあったり、Core や Ads といったサーフェス別の行を合算する「All」サーフェスがあったりします）。そのような列に対して単純に SUM を行うと、各構成要素とそれ自身の合計の両方を数えてしまい、数値が水増しされます。ローダーはすべての集計行に is_total マーカーを付与し、それをフィルタ可能なディメンションとして公開するため、クエリは意図的に単一の粒度 — 合計のみ、または内訳のみ — を選択でき、合計をその構成要素と一緒に合算してしまうことは決してありません。ダッシュボードの主要な数値には報告された合計を使用し、内訳チャートには構成要素の行を使用しています。それでも数値に注意点が残る場合、API は warnings の注記を返し、ダッシュボードがそれを結果と並べて表示します。

言語をまたいで読む

VLOP以外のプラットフォームは、調和されたテンプレートをEUの公用語のいずれでも提出できるため、同じテンプレート行が異なるテキストとして届くことがあります（Decisions upheld / Décisions confirmées / Bestätigte Entscheidungen）。各行は表示用に元の言語のラベルを保持しつつ、言語に依存しない標準ラベル（正規キー）も付与されます。これは、同じ構造のレポートを英語の参照基準に揃え、曖昧なものはすべて除外する翻訳マップ（「クロスウォーク」）を通じて対応付けられます。クエリは正規キーで集計・絞り込みを行うことで、言語をまたいで同等のもの同士を比較でき、元のテキストも引き続き表示されます。ただし、カバー範囲はまだすべての言語で一様ではありません（既知の制限をご覧ください）。

クエリの方法

SQL インターフェースはありません。クエリは構造化されたリクエストです。テーブル名、フィールド・演算子・値の条件からなるブール型フィルター、そして任意のグループ化、集計、ソート、上限を指定します。サーバーはすべてのフィールドと演算子をそのテーブルの固定レジストリに照らして検証し、事前チェック済みの単一のデータベース照会（パラメータ化された SELECT）にコンパイルします。そこでは入力は常にデータとして扱われ、コマンドとして実行されることはありません。クエリには制限も設けられており、結果サイズの上限、リクエストサイズと複雑さの制限、キーごとのレート制限があるため、1 つのリクエストでサービスを使い果たすことはできません。テーブルをまたぐ「複合」クエリは、同じ検証済みの境界を通して、共有ディメンションで 2 つ以上のテーブルを結合します。自然言語の「Ask」ボックスは、有効になっている場合、入力した質問を（データセットのスキーマとともに）サードパーティの LLM（Anthropic の Claude）に送信して構造化クエリの下書きを作成し、それは他のクエリと同様に検証されてから実行されます。この LLM 呼び出しは、サービスが入力を自発的に外部へ送信する唯一の機会です。もう 1 つの外向きの経路はオプトインであり、あなたが指定するものです。クエリに付加する任意の callback_url で、あなた自身の結果をあなたが選んだ URL に届けます。DSA レポートダッシュボードでお試しいただくか、API リファレンスとプライバシーに関する説明をご覧ください。

再現性と引用

データベースは静的で読み取り専用のスナップショットです。各スナップショットには不変のデータセットバージョンが付与されます。これはその内容のフィンガープリントであり、データが変わるたびに変化します。ETag および X-Dataset-Version ヘッダーとして送信され、すべてのファクト行はその出典となる提出物の report_id を公開します。ある数値は、データセットバージョン、正確なクエリ、そしてそれが参照する report_id という 3 つの要素を合わせて固定されます。したがってこの 3 つをすべて引用すれば、行を再取得できます（バージョンと report_id だけでは出典の提出物を特定するのであって、特定の数値を特定するわけではありません）。ソートやページネーションを行う際、結果は常に完全に決定論的な順序で返ってくるため、保存した抽出はバイト単位で再現可能です。スナップショットのビルド日と対象期間は、各ダッシュボードの「Cite as」行とすべてのエクスポートのヘッダーに表示され、行の report_id はその出典となる提出物（プラットフォーム、期間、ティア）を特定します。VLOP 以外のプラットフォームについては、その提出物がどこで公開されているかがレポートの掲載先カタログにプラットフォームごとに一覧化されています。

帰属表示：数値は、それを報告したプラットフォームに帰属させてください。本サイトはアクセスのためのツールとしてのみ引用してください。

例：YouTube, EU DSA transparency report (H2 2025), accessed via the Transparency Report API — dataset version 7f3c1a2b9d04, report_id 42, retrieved 2026-06-26. ライブスナップショットの正確なデータセットバージョンと対象期間は、DSA レポートおよびGoogle の削除要請ダッシュボードの「Cite as」の行に表示されます。

既知の制限

• ライブではなくスナップショット
  数値はスナップショット作成時に利用可能だったレポートを反映しています。その後の修正や新たに提出されたレポートは、後続のスナップショット（新しいデータセットバージョン付き）にのみ反映されます。
• ソースの品質はさまざま
  プラットフォームによって、提出の厳密さやフォーマットには差があります。誤って解析されたゴミ行（ヘッダーセル、空欄、一部の抽出で混入した不要な値）は、推測で補うのではなく読み込み時に除外されます。これは、言語横断のクロスウォークが明確に対応付けられないテンプレート行についても同様です。除外された行の正確な件数やクロスウォークのカバー範囲はまだ公開されていないため、全体としての網羅性は定量化されていません。
• 一部のラベルは正規化されないまま
  ギリシャ語の抽出にはソースデータ上で列のずれがあるため、誤ったマッピングのリスクを冒すよりも、ほとんどのギリシャ語の指標/スコープのラベルは正しいが未マッピングのままにしています。カテゴリのラベルはまだ言語間でクロスウォークされていません。
• デモンストレーション用サービス
  これはポートフォリオ/デモ用のプロジェクトです。ソースに対しては正確ですが、公式な記録ではありません — 重要な事柄については必ずプラットフォーム自身が公開したレポート（レポートの掲載先からリンク）と照合してください。

ソースとコード

完全に公開レポートから構築されています。抽出、正規化、クロスウォーク、クエリレイヤーを含むパイプライン全体は、github.com/krMaynard/transparency-report-api でオープンソースとして公開されています。さっそく探索してみましょう：DSA レポート · Google の削除要請 · スキーマ。