LASSIC Media らしくメディア

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

自社のサービスに、利用者が書き込める場を持っている企業は少なくありません。商品のレビュー、会員同士の掲示板、質問と回答の場、写真の投稿。こうした機能は集客や利用の定着に役立ちますが、そこに書かれた内容をめぐって「消してほしい」という申出が届くこともあります。

その申出への向き合い方について、法律の枠組みが変わりました。プロバイダ責任制限法を改めた情報流通プラットフォーム対処法が、令和7年4月1日から施行されています*1。大規模な事業者には具体的な義務が課され、削除申出の受付方法の公表、申出の調査、申出者への通知、運用状況の公表が求められます*1。

本記事では、利用者投稿の機能を持つサービスの企画・開発担当と、その改修を受託する立場に向けて、法律が求める手続の流れ、システム側で足りなくなりやすい箇所、そして指定を受けていない事業者が備えておくべきことを整理します。制度の解釈が要る部分は最新の公式資料で確かめながら進めてください。

法律の位置づけ——「責任の限度」から「手続の義務」へ

従来のプロバイダ責任制限法は、名前のとおり「どこまで責任を負うか」を定める性格の法律でした。削除しなかった場合、あるいは削除した場合に、事業者がどこまで責任を問われるのか——その線引きが中心にありました。

今回の改正で加わったのは、手続そのものへの義務です。総務省の資料によれば、令和7年4月1日から施行され、大規模な事業者として指定された者には、削除申出の受付方法の公表、申出の内容の調査、そして申出者への通知が求められます*1。加えて、削除の取扱いや実施状況について、年次で公表することも求められます*1。

対象となるのは、大規模特定電気通信役務提供者として指定された事業者です。令和7年4月30日付で複数の大手事業者が指定され、その後も追加の指定が行われています*1。国内外の主要なサービスが並ぶ形です。

この構造は、日本の多くの企業にとって「自社は指定されていないから関係ない」で済む話にも見えます。ただ、次の二点は押さえておく価値があります。第一に、指定の基準は利用者の規模に関わるため、サービスが育てば対象になり得ること。第二に、指定を受けていなくても、削除申出への対応そのものは必要であり、法律が示す手続の型は実務の参考になることです。

求められる手続の流れ

手続を四つの段階に分けて見ていきます。それぞれ、システム側で用意すべきものが違います。

この一覧を見ると、必要なものが「削除の機能」ではないことがわかります。管理画面から投稿を消せるだけでは足りません。申出を受け取り、進捗を管理し、判断を記録し、期限内に通知して、後から集計できる——ワークフローとしての作りが要ります。

この性格は、社内の申請・承認の仕組みに近いものです。申請・承認ワークフローの開発で扱うような、状態遷移と期限、記録の設計がそのまま当てはまります。

システム側で足りなくなりやすい三点

既存のサービスに後から対応を足す場合、次の三点で詰まることが多くなります。

第一に、申出の管理です。問い合わせ窓口のメールアドレスで受け取り、担当者が受信箱で処理している——この形は珍しくありません。しかし、これでは件数を把握できず、期限も管理できず、集計もできません。申出を一件ずつ記録として持つ仕組みが要ります。

申出には、対象の投稿、申出者、申出の理由、受付日、担当者、判断、通知日といった項目が必要になります。これを台帳として持ち、状態で絞り込めるようにしておくと、運用が回るようになります。

第二に、投稿の同定です。「どの投稿についての申出か」を一意に指せる必要があります。投稿ごとに安定したURLや識別子を持っていないサービスでは、申出者が投稿を特定して伝えることも、担当者が探し当てることも手間になります。

ここは設計の初期から入れておきたい部分です。投稿一覧の何ページ目、という指し方しかできないと、時間が経つほど探せなくなります。投稿ごとの恒久的な識別子と、それを申出フォームで受け取る項目を用意しておきます。

第三に、措置の履歴です。削除を物理削除で行っていると、後から「何をどう扱ったか」を示せなくなります。申出があって削除したのか、規約違反として削除したのか、投稿者自身が消したのか——区別できる形で残す必要があります。

実務としては、表示から外す扱いと、データを消す扱いを分けるのが一般的です。表示上は見えなくなっても、記録としては残す。この設計にしておけば、集計も説明もできます。監査ログの考え方で扱うような、後から追える形での記録が土台になります。

なお、投稿者側への配慮も設計に含まれます。削除したことを投稿者に伝えるのか、異議を受け付けるのか。片方の申出だけを見て動く作りにすると、別のトラブルにつながります。

公表に向けた集計——定義を先に決める

運用状況の公表が求められる場合、集計の設計が実務の負担になります。ここでつまずくのは、計算そのものより定義の統一です。

何を一件と数えるかです。同じ投稿について複数の申出が来たら、何件と数えるのか。一つの申出で複数の投稿を指していたら、どう扱うのか。決めておかないと、担当者が変わるたびに数値が変わります。

処理期間の起点と終点です。受付日は申出が届いた日か、内容を確認した日か。完了日は判断した日か、通知した日か。定義によって平均の日数が変わります。

種別の分け方です。申出の理由をどう分類するか。分類の粒度が細かすぎると入力が続かず、粗すぎると意味のある数値になりません。運用しながら見直せる形にしておきたいところです。

前年との比較です。公表は毎年続くため、同じ定義で出せることが重要になります。定義を文書として残し、集計処理と紐づけておくと、数値の変動の理由を説明できます。

集計を後から作るのは大変です。台帳の項目を設計する段階で、「この項目から何を集計するか」を決めておくと、公表の時期に慌てずに済みます。

指定を受けていない事業者が備えておくこと

大規模な事業者として指定されていない企業でも、備えておく意味はあります。理由を三つ挙げます。

第一に、申出そのものは規模を問わず届くことです。小さなコミュニティ機能でも、書き込みをめぐる申出は起こります。窓口も手順もない状態で受け取ると、対応が場当たりになり、判断のばらつきも生じます。

第二に、サービスが育てば対象になり得ることです。利用者が増えてから台帳や識別子の仕組みを入れるのは、データが積み上がったあとでの改修になります。先に入れておけば、負担は軽くなります。

第三に、取引先や出資先からの要求です。プラットフォーム的な機能を持つサービスでは、運用の体制を問われることがあります。手順と記録が整っていることを示せる状態は、それ自体が説明の材料になります。

備えの規模は、機能の性格で決めます。レビュー機能だけなら、申出フォームと台帳、そして表示制御があれば足ります。利用者同士が交流する場を持つなら、投稿者への通知や異議の受付まで含めて考える必要があります。

あわせて確かめておきたいのが、個人情報の扱いです。申出には申出者の連絡先が含まれ、投稿には投稿者の情報が紐づきます。個人情報保護法の枠組みで扱うような観点で、保持する範囲と閲覧できる範囲を決めておきます。

顧客からの申し立てへ対応するという性格は、近年整備が進む別の領域とも重なります。顧客対応の記録と体制づくりで扱うような、記録を残して判断を支える設計の考え方は共通しています。

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

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

第一に、判断の主体を分けることです。削除するかどうかの判断は、法務や運用の領域です。開発側は「判断を記録し、期限を管理し、通知する仕組み」を作る役割に集中します。この分担が曖昧だと、仕様が決まりません。

第二に、既存の投稿データの状態を確かめることです。投稿に安定した識別子があるか、削除の履歴が残っているか、投稿者との紐づけが取れるか。ここが弱いと、改修の範囲が広がります。調査を独立した工程にする価値があります。

第三に、公表用の集計を要件に含めるかを決めることです。台帳を作るだけなら軽い改修で済みますが、集計と出力まで含めると設計が変わります。どこまでを今回の範囲にするかを最初に決めます。

第四に、運用の担い手と手順を並行して作ることです。仕組みだけあっても、誰がいつ見るのかが決まっていなければ期限を守れません。担当者向けの手順書を成果物に含めるかを、契約の段階で決めておきます。

第五に、外部サービスを使っている場合の切り分けです。レビュー機能やコミュニティ機能を外部のサービスで実現している場合、申出の受付や削除の操作がそのサービスの機能に依存します。自社で作る範囲と、サービス側に頼る範囲を先に整理します。

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

まとめ：情報流通プラットフォーム対処法への備えで押さえる3つの視点

プロバイダ責任制限法を改めた情報流通プラットフォーム対処法が令和7年4月1日から施行され、大規模な事業者として指定された者には削除申出の受付方法の公表、申出の調査、申出者への通知、運用状況の公表が求められます。押さえたい視点は三つです。第一に、この法律が求めているのは削除の機能ではなく手続であり、申出を受け取って進捗を管理し、判断を記録して期限内に通知し、後から集計できるワークフローとしての作りが要ること。第二に、既存サービスに後から足す場合、申出の管理がメールの受信箱で回っている、投稿を一意に指せる識別子がない、削除が物理削除で履歴が残らない——この三点で詰まりやすいこと。第三に、指定を受けていない事業者でも申出そのものは規模を問わず届くため、機能の性格に応じた備えを先に入れておくほうが後の負担が軽くなることです。まずは自社の投稿機能に安定した識別子があるかを確かめ、申出を記録として持つ台帳の設計から着手するのが堅実でしょう。

よくある質問

出典

1. *1　参考：総務省「違法・有害情報への対応（情報流通プラットフォーム対処法）」（https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/ihoyugai.html）。法律の位置づけ、施行日、大規模特定電気通信役務提供者の指定、削除申出への対応と公表の義務の一次情報として（2026年8月確認）

Tweet