ユーザーレビューサービスにおける通報機能の段階的導入

はじめに

こんにちは。プラットフォーム開発本部 第一開発部 ユーザーレビューグループの富澤です。
DMMのユーザーレビューサービスを支えるバックエンドチームで、システムの開発・運用を担当しています。

本稿では、ユーザーレビューサービスにおける通報機能の段階的導入についてご紹介します。
不適切なレビューにいち早く気づくための仕組みとして、PoCから本格運用まで段階的に機能を拡張していった取り組みです。

背景と課題

背景

DMMのユーザーレビューサービスでは、現在レビューの承認制を採用しており、ガイドラインに基づいて運営側が内容を確認したうえで公開しています。

ただし、「何を不適切と判断するか」については、運営側ですべてを事前に定義することが難しいという課題がありました。
レビューはユーザーの主観的な体験や表現に基づくものであり、文脈や受け取り方によって評価が分かれるケースも少なくありません。

そのため、承認制を採用している状況下でも、ユーザーの視点では不適切と感じられるレビューについて、指摘や問い合わせが年間で数十件程度発生していました。

従来の対応と限界

当時は専用の通報機能が存在しておらず、これらの指摘は主にお問い合わせフォームを通じて寄せられていました。

運営側では、投稿時点のガイドラインに基づき個別に内容を確認し、掲載継続または削除といった判断をしていました。

一方で、運用を続ける中で、判断そのものではなく、判断の前提となる運用プロセスにいくつか制約があることを認識するようになりました。

• ガイドラインは随時アップデートされるが、新たに追加・変更されたルールに基づいて、過去に掲載されたすべてのレビューを再審査する仕組みは存在していなかった
• その結果、現在の基準では不適切と判断される可能性のあるレビューが、掲載されたままとなるケースが発生し得た
• また、ユーザーからの指摘を受けて初めて再確認することで、運営側でも再審査の必要性に気づくケースがあり、問題の検知が事後的になりやすい構造になっていた

このように、管理者による判断はガイドラインに沿っておこなわれていたものの、判断するためのきっかけや再確認の導線が十分ではなく、結果として対応の遅れにつながる可能性のある状態でした。

課題の整理

まとめると、課題は単なるシステム不足ではなく、以下の3点に集約されます。

• 不適切さの判断を運営だけで完結させることの限界
• ユーザー視点を適切に取り込む仕組みの不足
• 早期に気づき、対応につなげるための導線の欠如

そこで、ユーザーの視点を補助線として取り入れつつ、運営が一貫した基準で判断できる仕組みとして、通報機能の導入を検討することにしました。

以下は、通報機能の全体像を示すデザイン案の図です（Phase1・Phase2の説明でも同じ図を参照しています）。掲載している画像はDMM.comサービスにおけるイメージです。

対応方針：Phase分けによる段階的導入

通報機能の導入にあたり、一度にすべての機能を実装するのではなく、Phase分けをして段階的に機能を拡張していく方針を採用しました。
これにより、ユーザーの需要を確認しながら、実装側の負担を最小限に抑えつつ進められると考えたからです。

Phase分けの全体像

通報機能の導入は、以下の2つのPhaseに分けて進めました。

Phase1：通報の登録 - 通報ボタンの作成 - 通報情報の登録APIの実装

Phase2：管理画面にて通報の管理 - 通報情報取得APIの実装 - 通報情報からレビューの更新機能の実装

以下は、DMM.comサービスにおける管理画面のイメージです。

Phase1:通報の登録(PoC)

Phase1では、通報を登録できる機能の作成に絞り、PoCとしていち早くリリースすることを重点におきました。

実装の進め方

1. 設計ドキュメント（Design Doc）を作成しチーム内でレビュー

   • 必要なAPIの洗い出しを行った
   • 通報情報のデータ構造を定義

2. 通報ボタンの作成

   • フロントエンドチームと連携し、レビュー画面に通報ボタンを追加

3. 通報情報の登録APIの実装

   • 通報されたレビューのID、通報理由、通報者の情報を保存するAPIを実装

Phase1の特徴

Phase1では、通報内容の確認や、不適切な利用が疑われるケースへの対応は、当初は人力で行っていました。
これは、まずはユーザーが実際に通報機能を使用するかどうかを確認し、需要があることを検証してから次のPhaseに進むためです。

Phase2：管理画面での通報管理

Phase1のリリースを通じて、通報機能に一定の利用があることを確認できたため、管理画面の機能も本格的に実装することになりました。

実装の進め方

1. プロダクトマネージャーが画面デザインを用意

   • 管理画面のUIデザインをプロダクトマネージャーが作成

2. 必要なAPIの洗い出し

   • 画面デザインに合わせて必要なAPIを洗い出し
   • 通報情報の取得、通報情報からレビューの更新など

3. フロントエンドチームとの連携

   • 管理画面のフロントはフロントエンドチームに依頼
   • APIの作成に取り掛かった

Phase2で実装した機能

• 通報情報取得API

  • 管理画面で通報一覧を表示するためのAPI
  • 通報の状態（未対応、対応中、対応済み）でフィルタリング可能

• 通報情報からレビューの更新機能

  • 通報されたレビューを確認し、削除や非表示などの対応をする機能

実装時に気をつけたこと

通報機能を導入する際に、他のチームでも導入しやすいように資料を作成しました。

導入支援資料の作成

以下のような情報をまとめた資料を作成し、導入コストを下げることを意識しました。

• どのAPIを使用するのか

  • 通報機能で使用するAPIの一覧とエンドポイント
  • 各APIの役割と使用方法

• どのようなリクエストが必要なのか

  • 各APIのリクエストパラメータの定義
  • リクエスト例とレスポンス例

• どのような画面設計・デザインが必要か

  • 通報ボタンの配置やデザインガイドライン
  • 管理画面のUIデザイン

この資料により、導入するためのコストを下げることができました。

プロジェクト全体の効果と今後の課題

データ分析から見えた効果

通報機能の導入後、通報データを分析した結果、通報行動には非常に偏りがあることを確認できました。

通報機能導入以降の約半年間で、通報総数は9万件にのぼりましたが、
実際に通報したユーザーは 200人 未満で、
そのうち わずか10%程度の利用者が全通報の約8割を占めている 状況でした。

さらに、通報内容の審査結果を確認すると、審査対象となった通報のうち 約9割以上が「対応不要（掲載継続）」と判断されており、大量通報するユーザーほど、通報の妥当性（成功率）が著しく低いという明確な傾向を確認できました。

このことから、下記のような構造的な課題がデータ上で裏付けられました。

• 通報量の増加 ≠ レビュー品質の改善
• 少数のユーザーによる大量通報が、運営側の審査負荷を大きく押し上げている

見えてきた課題

一方で、今回の分析を通じて、以下の課題も明確になっています。

• 当初は人力で対応していましたが、一定の条件に該当するユーザーに対して通報機能の利用制限が必要
• 手動対応では対応が後手に回りやすい
• 明確な基準がない状態では、運営判断が属人的になりやすい

今後に向けた方針

これらの課題を踏まえ、今後は以下の方向で改善を進めていく予定です。

• 通報件数と通報の妥当性（成功率）を組み合わせた客観的な指標による段階的な制御
• まずはユーザー体験への影響が小さい形で運営負荷を下げ、必要に応じて制限を強化する Phase分けの対応
• 効果を測定しながら、閾値やルールを定期的に見直せる仕組みの構築

これにより、健全なユーザーの正当な通報体験を守りつつ、運営負荷を継続的に抑えられる通報機能を目指していきます。

まとめ

今回の取り組みでは、PoCとして早期にリリースし、実際の利用状況から次の改善フェーズにつなげることができました。

得られた知見

1. まずは小さく始めることでユーザーへの需要があるかを確認してから進められた

   • 実装側にとって負担が最小限で済んだ
   • ユーザーの反応を見ながら次のステップを決められた

2. Phase分けすることで、どこで何をするか明確になり、フロントエンドチームとの連携もより取りやすくなった

   • 各Phaseで実装する機能が明確になり、スコープが限定された
   • フロントエンドチームとの連携がスムーズに進んだ

3. 導入支援資料を作成することで、他のチームでも導入しやすくなった

   • 導入コストを下げることができた
   • 標準化された導入プロセスを確立できた