EUの通知・削除義務、欧州に拠点がなくても御社のディレクトリに及ぶ

望んでもいないのに適用されるルール

EU域外の運営者の多くは、EUのプラットフォーム規制に関する見出しを目にしても、自社が欧州に拠点を持たないことを確認して読み飛ばしてしまう。しかし、この直感はデジタルサービス法(DSA)という特定の法律に関しては誤りであり、EU当局からの通知でその理由を思い知らされる前に、正確に理解しておく価値がある。

この規則自体の適用範囲を定める条文は、企業がどこで設立されたかを問わない。提供者の所在地にかかわらず、EU域内の人々に提供されるサービスであれば適用される、それだけの話だ。その結びつきが要件を満たすほど実質的かどうかを判断する基準は定義条文に置かれている。すなわち、サービス利用者のうち相当数が一つ以上の加盟国に、その国の人口に対して一定の割合で存在すること、あるいは、加盟国の言語や通貨を使用する、その国からの注文を受け付ける、その国をターゲットにした現地広告を展開するといったシグナルによって、事業者がその市場を狙っていると示されることのいずれかである。ドイツやフランスからの広告主や訪問者を受け入れ、ユーロで価格表示を行い、ドイツ語版やフランス語版のサイトを運営しているディレクトリは、境界事例などではない。まさにこの基準の内側に収まる。

これは実際の執行が伴わない理論上のリスクではない。2026年は、規制当局が警告書の送付にとどまらず、本稿が扱うまさにこの種の違法コンテンツ対応をめぐって、プラットフォームに対する正式な手続きの開始や情報提供要求へと踏み込んだ年であり、その流れは今後さらに監視を強める方向にある。この法律が適用されるのに、運営者がEU進出の野心を持っている必要はない。法律が問うているのは野心の有無ではなく、利用者が現にどこにいるかだけである。

朗報であり、本稿の本当の論点でもあるのは、実際に課される義務の範囲が「EUのプラットフォーム規制」という言葉から想像されるよりもはるかに狭いということだ。デジタルサービス法が壮大に聞こえる部分の大半は、利用者数が数千万人規模のプラットフォームを念頭に書かれている。小規模なクラシファイド運営者が負う義務は短く具体的なリストにすぎず、そのリストを正確に把握しておけば、誰にも求められていないコンプライアンス体制を何か月もかけて過剰構築する事態を避けられる。

通知・対応の仕組みが実際に満たすべき要件

第16条が定める中核的義務は、一つの仕組みを備えることだ。登録ユーザーに限らず誰でも、サイト上の特定のコンテンツを違法だと通報できる、アクセスしやすく使いやすい手段である。通報は完全に電子的な方法で受け付けなければならず、判断者が実際に必要とする情報、すなわちそのコンテンツがなぜ違法とされるのかの明確な説明、その正確な所在地(説明文ではなくURL)、通報者の連絡先、そして誠実に申告している旨の陳述を確実に取得できる設計でなければならない。クリック3回先に埋もれていて一般的な問い合わせしか受け付けない問い合わせフォームでは、この基準を満たさない。

通報が届くと、二つのことが求められる。第一に、通報者が連絡先を提供していた場合、運営者は不当な遅滞なく受領確認を送らなければならない。第二に、運営者は判断を下し、その判断内容と理由を平易な言葉で通報者に伝え、あわせてその判断に異議を申し立てる手段も示さなければならない。この第二の部分が第17条の理由説明義務であり、単なる任意の事務手続きではない。適切に提出された通報は、法的には、そのコンテンツについて運営者が現実に認識していたとみなされる根拠となり、この認識の有無こそが、当該コンテンツが違法であるにもかかわらず掲載され続けた場合の責任を左右する決定的な要素となる。

これが実務上意味するのは、「削除した」ということと「記録として理由を通報者に伝えた」ということは、同じ義務ではないという点だ。通報された掲載を黙って削除し、通報者に一切返信しない運営者は、法律が求める仕事の半分しか果たしていない。残りの半分こそ、後になってその判断が疑問視された際に事業を実際に守ってくれる部分である。理由を明記した判断の記録があってこそ、運営者が恣意的にではなく注意深く行動したことを示す証拠となるからだ。

これらを実現するのに新しいスタッフや外部ベンダーから購入する新しいソフトウェアは必要ない。必須の4項目を備えた構造化フォーム、通報ごとにタイムスタンプ付きの判断と定型返信を記録できる共有受信箱や簡易チケット管理、そして毎日それを確認する担当者がいれば、1日に何千件もの掲載を処理していない段階のディレクトリにとって法的な最低ラインは満たせる。避けるべき失敗は、これを事業が大きくなってから対応すればよい将来の課題として扱うことだ。この義務は、規模の大小を問わず、サイトにEU利用者が一人でも存在した時点で発生する。

小規模であることが免除する部分と、免除しない部分

デジタルサービス法は小規模事業者に対して実質的な緩和措置を設けており、その緩和がどこから始まりどこで終わるのかを正確に把握しておく価値がある。どちらの方向に読み違えても代償が生じるからだ。第19条は、EU法が他の場面でも用いているのと同じ定義に基づき、零細企業または小規模企業に該当するオンラインプラットフォーム提供者を適用除外としている。小規模企業とは従業員50人未満で、年間売上高または貸借対照表の総額が1000万ユーロを超えない企業を指し、零細企業とは従業員10人未満で、いずれかの数値が200万ユーロを超えない企業を指す。この種のプラットフォーム上で運営されているディレクトリの大半は、あらためて確認するまでもなくこの要件を満たす。

しかし、この適用除外はその条文自体によって、規則の特定のブロック、すなわち大規模オンラインプラットフォーム向けに書かれた追加義務を定めた章に範囲が限定されている。具体的には、運営者自身のモデレーション判断に対する苦情を処理する社内システム、裁判外紛争解決手段へのアクセス、「信頼できる通報者」向けの優先処理チャネル、広告および運営しているレコメンドシステムに関する透明性報告書の公表などである。これらを何も整備していない小規模ディレクトリは、あえて整備する必要はない。

この適用除外が及ばないのが、通知・対応の仕組みそのもの、およびそれに付随する理由説明義務である。これらは規則のもっと前の部分、あらゆるホスティングサービス提供者を対象とした章に置かれており、小規模企業向け適用除外の条文はそこに一切言及していない。これは抜け穴でも強引な解釈でもなく、適用除外条文自体がその条文の置かれた章の中に限定して書かれているという、単純な条文構造の問題である。従業員10人の事業者と利用者5000万人のプラットフォームは、法律の他のほぼすべての部分が規模に応じて段階的に適用されるにもかかわらず、通知・対応の仕組みについてはまったく同じ義務を負う。

運営者にとっての実務的な読み方はこうなる。社内苦情処理システムは不要、裁判外紛争解決パネルも不要、誰も求めていない広告透明性報告書の公表も不要であり、防御的にこれらの構築に1週間を費やす必要はない。その1週間は代わりに、実際の通知の仕組みが第16条の定めるとおりに機能しているかを確認することに充てるべきだ。この法律の中で、事業の規模を一切問わない唯一の部分がここだからである。

そもそも御社は「オンラインマーケットプレイス」なのか。答えによって負う義務が変わる

同じ規則の中には、「オンラインマーケットプレイス」だけを対象とした、もう一つ別の義務群が存在し、そこには実質的な負担が伴う。プラットフォームを通じて販売する事業者顧客全員について本人確認情報と連絡先情報を確認・保有すること、いわゆるKnow Your Business Customer(取引先事業者確認)である。もしこれがEコマース型マーケットプレイスと同じようにクラシファイドディレクトリにも適用されるなら、掲載の真正性を保つためにサイトがすでに実施している本人確認に加えて、有料広告主全員を事業体として本人確認しなければならないことになる。

実は、この規則は「オンラインマーケットプレイス」という用語自体を定義していない。この追加義務は、特定の機能的な記述、すなわち「消費者が事業者と遠隔契約を締結できるようにするプラットフォーム」、つまりプラットフォーム自体が実際の取引を仲介すること、典型的にはプラットフォーム内の決済機能を通じて行われることに結びついている。この点に関する法律専門家の解説は一致している。プラットフォーム自体が購入手続きを実行せず、事業者が見込み客と単に接点を持つだけのプラットフォームは、たとえ両者がそのプラットフォーム上で出会ったのだとしても、この記述の対象外だというものだ。

広告を掲載し、訪問者が広告主に連絡を取れるようにするだけで、実際の手配や広告対象サービスの対価の支払いはすべてプラットフォームの外で行われるクラシファイドディレクトリは、専門家の解説がマーケットプレイス固有ルールの対象外としているパターンに合致する。このディレクトリは、利用者の求めに応じてコンテンツを保存し公に表示している以上、規則上の「オンラインプラットフォーム」には該当し、その規模のオンラインプラットフォームが負うべき義務は負う。しかし、それに加えて取引先事業者確認義務を負う、より狭い「マーケットプレイス」カテゴリーには、おそらく該当しない可能性が高い。

これは有力な裏付けのある解釈であり、この論点について法律事務所の解説の中に反対の見解は見当たらないが、あくまで一つの解釈であって確定した判例ではない。この境界線自体がまだ裁判で争われたことがないためだ。広告対象サービスについてプラットフォーム内での予約や決済に近い仕組みを備えているサイトの運営者は、この結論をそのまま自社に当てはめられると考えるべきではない。そうした設計こそが、まさにディレクトリを再びマーケットプレイス側に押し戻す事実関係だからだ。広告掲載のみで取引はプラットフォーム外という通常型のディレクトリであれば、この解釈を自動的に当てはめるのではなく、弁護士に自社サイトについて個別に確認してもらう価値はある。しかし、現時点で最も妥当な解釈のもとでは適用されない義務に備えて、先回りして取引先事業者確認のインフラを構築する価値はない。

実際に構築すべきもの、その優先順位

まず取りかかるべきは通知の仕組みそのものだ。規模を問わずすべての運営者が負う唯一の義務だからである。目に見えるリンクから到達できるフォームを構築、あるいは既存のものを点検し、コンテンツの所在地、違法とされる理由、通報者の連絡先、誠実に申告している旨の陳述を確実に取得できるようにする。そして、すべての通報を、1週間放置されかねない一般的なサポート受信箱ではなく、毎日確認される場所に振り分ける。

最初の実際の通報が届いてからではなく、届く前に、二つの短い返信テンプレートを用意しておく。一つは受領確認用、もう一つは判断内容とその理由を平易な言葉で伝え、通報者が異議を唱えたい場合にどこへ行けばよいかを示すものだ。どちらも通報到着から1日以内に送れる状態にしておくべきである。「不当な遅滞なく」というのが運営者の対応を評価する基準になるからだ。

すべての通報とその結果について、簡単な記録、たとえばスプレッドシートでよいので残しておく。日付、通報対象、判断内容、返信を送った日時である。これは規制当局や裁判所に対し、判断が恣意的ではなく迅速かつ注意深く一貫していたことを示す記録となる。同時に、半年後に運営者自身が、このプロセスが実際に守られているかを確認するための資料にもなる。

社内苦情処理システム、裁判外紛争解決パネル、広告透明性報告書といった大がかりな仕組みは、弁護士が事業の規模がそれらを義務づける閾値を超えたと確認するまでは構築しないこと。これらの整備には人員の時間という実質的なコストがかかる一方、早期に構築しても、小規模事業者がすでに得ている以上の法的な保護が追加で得られるわけではない。

最後に、これを独立した別のプロジェクトとしてではなく、大半のアダルトディレクトリがすでに組み込んでいる年齢確認や本人確認の義務を含む、既存の対応の積み重ねの一層として位置づけること。通知・対応の仕組みは、運営者側の他のチェックが見落としたコンテンツを訪問者が報告してくる窓口であり、二つの仕組みは、同じ人物が、報告が届いたその日のうちに両方を突き合わせて確認して初めて、正しく機能する。