LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

EU向けにサービスを出していて、利用者が何かを投稿できる、あるいは事業者が出品できる。そういう機能を持っているなら、EUデジタルサービス法（Digital Services Act、Regulation 2022/2065）の枠組みを一度見ておく価値があります*1。

マーケットプレイス、SNS、アプリストア、旅行の予約——対象になり得るサービスは幅広く、義務はそれぞれのサービスの役割・規模・影響に応じて調整される設計になっています。規模の小さい事業者には軽い要件が適用されます*1。

本記事では、EU市場向けサービスの企画・開発担当と、その改修を受託する立場に向けて、規則が求める機能を実装の観点から整理します。日本の枠組みとは別の要求が含まれるため、国内の情報流通プラットフォーム対処法への対応をすでに進めている企業も、追加で必要になる部分を確かめてください。制度の解釈が要る部分は最新の公式資料と法務の確認を経て進めてください。

義務は積み上がる——自社がどの層にいるか

この規則の構造を理解する鍵は、義務が層になっていることです。全部の事業者に同じ要求がかかるわけではありません*1。

いちばん下の層が、仲介サービス全般です。ここは要求が比較的軽く、規模の小さい事業者にはさらに軽い要件が適用される設計になっています*1。

次の層が、ホスティングやオンラインプラットフォームです。利用者が投稿したものを預かる、あるいは第三者が出品する場を提供する立場です。ここから、違法コンテンツの通知を受け付ける仕組み、苦情への対応、広告の表示、未成年者の保護といった要求が加わります*1。

最上層が、超大規模プラットフォームおよび超大規模検索エンジンです。EU域内で月間4,500万利用者を超える規模が基準として示されています*1。この層になると、広く生じるリスクを特定して分析することが求められ、監査も関わってきます*1。

日本企業の多くは、当てはまるとしても中間の層でしょう。EU向けにECサイトを運営している、EU利用者が投稿できる機能を持っている——そういうケースです。まずは自社がどの層に当たるのかを法務と確かめ、必要な要求の範囲を絞ることが出発点になります。

実装の成果物になる四つの部品

開発の側から見ると、求められているのは「投稿を削除する機能」ではありません。手続を成り立たせる部品です。四つに整理します。

この一覧で、日本の枠組みと比べていちばん違うのが「判断理由の説明」と「異議の受付」です。措置を取ったことを伝えるだけでなく、なぜそう判断したのかを示し、それに対して異議を出せる道を用意する——ここまでが一組になっています*1。

実装としては、判断の理由を項目化して持つ設計が要ります。どの規約に触れたのか、どの通知に基づくのか、自動の検知なのか人の判断なのか。自由記述の備考欄に書く運用では、定型の説明を出せません。

異議の受付も、単なる問い合わせ窓口では足りません。元の判断と、それに対する異議、そして再審査の結果——三つを別の記録として持ち、関連づける構造が必要です。申請・承認ワークフローの開発で扱うような、状態遷移を持つ設計がそのまま当てはまります。

広告と勧告システム——表示側に手が入る

コンテンツの扱いとは別に、表示の仕組みにも要求があります。ここは既存サービスの改修としては重くなりがちな部分です。

広告の表示です。広告は明確にラベル付けされ、誰が出しているのかがわかる形で示されることが求められます*1。自社サイトに広告枠を持っている場合、配信の側と表示の側の両方に手が入ります。

実務でつまずくのは、外部の配信サービスを使っている場合です。表示するクリエイティブが外から来るため、出し手の情報を自社の画面で示すには、配信側から情報を受け取る必要があります。連携の仕様を確かめる作業が先に立ちます。

勧告システムの選択肢です。利用者が、パーソナライズされていない一覧を選べるようにする——という考え方が示されています*1。おすすめ順だけでなく、新着順や評価順といった、個人の履歴に依らない並び方を選べるようにする、という要求です。

これは検索や一覧の実装に直接効いてきます。個人化のロジックが検索基盤の奥に組み込まれていると、切り離すのに手間がかかります。レコメンドの仕組みづくりで扱うような設計を持っているなら、個人化の有無を切り替えられる構造になっているかを確かめておきます。

未成年者の保護です。年齢に適さないコンテンツへのアクセスを制限する方向の要求が含まれます*1。年齢の確認をどう行うか、確認できない場合にどう扱うか。これは技術だけで決められない判断を含みます。年齢に応じた機能制限で扱うような設計の考え方が土台になります。

透明性報告——集計を先に設計する

透明性の報告も求められる要素です。超大規模なプラットフォームには、広く生じるリスクを特定して分析することが求められます*1。

報告を出すという要求は、システム側では「集計できるデータ構造を持っているか」という問いに変わります。ここでつまずく点を挙げます。

第一に、件数の定義です。通知の件数、措置の件数、異議の件数。同じ対象への複数の通知をどう数えるか。決めていないと、期ごとに数値の意味が変わります。

第二に、処理時間の測り方です。受付から措置までを測るのか、受付から通知までを測るのか。定義によって平均値が変わります。

第三に、判断の種別です。自動の検知によるものか、人の判断によるものか。通知に基づくものか、自主的な巡回によるものか。この区別を記録の段階で持っていないと、後から分けられません。

第四に、対象の区分です。どの国の利用者に関わるものか。EU向けの報告を出すには、EU域内の利用者を分けて数えられる必要があります。

これらは、あとから集計処理を作るのではなく、記録の項目を設計する段階で決めておく領域です。監査ログの考え方で扱うような、後から追える形での記録が土台になります。

日本の枠組みとの違いをどう扱うか

国内向けと欧州向けの両方でサービスを出している場合、二つの枠組みへの対応が必要になります。ここで判断が要るのは、仕組みを一つにするか分けるかです。

一つにまとめる利点です。通知の受付、台帳、記録の構造を共通化できれば、開発と運用の負担が下がります。担当者が覚えることも減ります。

分ける利点です。要求される項目や手続が違うため、共通化すると「どちらにも足りない」状態になりがちです。地域ごとに分けておけば、片方の要求が変わっても他方に影響しません。

実務としては、記録の土台を共通にして、地域ごとの要求を上に載せる形が現実的でしょう。通知・判断・異議という骨格は共通で、必要な項目や通知の文面、集計の切り口を地域ごとに持つ。この形にしておくと、将来ほかの地域の要求が加わったときにも足しやすくなります。

あわせて、EU域内の利用者を識別できるかという問題があります。地域ごとに要求が違うのに、どの利用者がどの地域なのかがわからなければ、適用を切り替えられません。既存のサービスでは、この識別が曖昧なことが珍しくありません。改修の初期に確かめておく点です。

また、EU向けにサービスを出す場合は個人データの扱いも関わります。同意管理の実装で扱うような論点と、この規則の要求は別のものですが、実装では同じ場所に手が入ることがあります。まとめて整理しておくと手戻りが減ります。

受託・委託で進めるときの要点

この種の改修を外部と進める場合の要点を挙げます。

第一に、適用範囲の判定を先に済ませることです。自社のサービスがどの層に当たるのか、どの機能が対象になるのか。ここが決まらないと要件が固まりません。法務や事業側の判断を待つ工程として、明示的に置いておきます。

第二に、記録の項目設計を最初の成果物にすることです。通知、判断、理由、異議、再審査。これらをどう持つかが決まれば、画面も集計も後から作れます。逆に画面から作り始めると、記録の構造が足りなくなります。

第三に、外部連携の確認を工程に入れることです。広告の配信サービス、外部の紛争解決の手続、検索や勧告の基盤。自社の外にある部分の仕様を確かめる作業は、思ったより時間がかかります。

第四に、運用の手順を並行して作ることです。仕組みだけあっても、誰がどの基準で判断するのかが決まっていなければ回りません。判断の基準づくりは事業側の仕事ですが、システムの設計と歩調を合わせる必要があります。

第五に、段階的に出す計画にすることです。通知の受付と記録を先に、集計と報告を後に。異議の受付をさらに後に。全部を一度に作るより、順に出すほうが確実です。

体制としては、コンテンツ運用の実務を理解している要員が入れるかが分かれ目になります。画面と項目だけを設計する体制では、現場が回らない仕組みになりがちです。運用側と設計側が同じ場で話せる形を作れるかを、委託先を選ぶ観点に入れておくとよいでしょう。

まとめ：EUデジタルサービス法への備えで押さえる3つの視点

EUデジタルサービス法（Regulation 2022/2065）は、仲介サービスに対する義務を役割・規模・影響に応じて段層に組み立てた規則です。押さえたい視点は三つです。第一に、義務は積み上がる構造になっており、規模の小さい事業者には軽い要件が適用されるいっぽう、EU域内で月間4,500万利用者を超える超大規模なプラットフォームや検索エンジンにはリスクの特定と分析、監査といった追加の要求が加わるため、自社がどの層に当たるのかを先に確かめる必要があること。第二に、実装で求められるのは削除の機能ではなく、通知の受付、判断理由の説明、異議の受付、広告の表示という手続の部品であり、とくに理由の説明と異議の受付は日本の枠組みより踏み込んだ要求になること。第三に、透明性の報告に備えるには、件数や処理時間の定義、判断の種別、対象の区分を記録の項目設計の段階で決めておく必要があることです。まずは自社サービスの適用範囲を法務と確かめ、記録の項目設計を最初の成果物として進めるのが堅実でしょう。

よくある質問

出典

1. *1　参考：European Commission「The Digital Services Act package」（https://digital-strategy.ec.europa.eu/en/policies/digital-services-act-package）。義務が役割・規模・影響に応じて調整される構造、超大規模プラットフォームの規模の基準、通知の仕組み・信頼できる報告者・苦情処理・広告の表示・リスク評価・勧告システムの選択肢・未成年者の保護に関する一次情報として（2026年8月確認）

Tweet