
1. はじめに
プラットフォーム開発本部 ユーザーレビューグループの松井です。
本稿では生成AIを活用したユーザーレビューの承認システムの開発から、高い判定精度の達成[1]、そして最終的に人手を介さずレビュー承認業務の自動化を開始した取り組みを紹介いたします。[2]
現在、生成AIは文章要約やコード補完など、人の判断を補助する用途が主流となっています。
生成AIの回答誤りが許容される分野の導入は増加してますが、回答誤りが許容しにくい業務を主導するケースは極めて稀です。特に大規模のプラットフォームでは、判断ミスがブランドや事業に重大な影響を及ぼす可能性があるため導入に慎重な傾向があります。(2025年1月現在)
このような状況下で、弊社4000万人の会員が利用するプラットフォームで「レビュー承認業務」の生成AIによる自動化を開始しました。[3]
「生成AIには回答誤りがある」という一般的な認識から、本取り組みに懐疑的な意見も予想されます。そこでこの取り組みについて、技術的な側面から運用まで、幅広く解説します。
2. 背景と課題
DMMでは、年間数十万件のレビューが投稿されており、その数は年々増加傾向にあります。その中には以下のような不適切な内容を含むレビューが一定数存在します。
- 誹謗中傷:作品や出演者を不当に批判する文章
- 苦情:サービスや運営に対する不満を表明する文章
- 文言不明:意味不明な文章
- 購入非推奨:他のユーザーに商品を購入しないよう勧める文章
これらはコンテンツの売上にも大きく影響があるため、不適切レビューの削除が必要です。現状、レビュー公開の判断を目視で行っているため、オペレーターの工数を大幅に消費するようになりました。(月150時間〜)

特に自然言語によるレビュー公開の判断は、文脈や表現のわずかな違いで適切・不適切の判断が大きく変わる[4]ことから、慎重な判断が求められる作業でした。
従来から機械学習(ML)による効率化を試みましたが、複雑な文章において対応できず、適用範囲は非常に限定的でした。
そこで生成AIを活用し、レビューの承認業務を効率化することとなりました。 この実現に向けては、生成AI導入の実現可能性を検証するところからスタートしました。
3. 生成AI導入のメリット
レビュー承認業務の生成AI導入により、メリットは以下です。
- オペレーターの工数削減: 目視チェック作業の大部分が削減可能に
- サービスレベルの向上: 最大1週間の待ちの時間[5]が、リアルタイム公開に
- 一貫した判定基準: 生成AIの判定により承認基準の統一化が可能
- 将来的な拡張性: 投稿数が増加しても安定運用の継続が可能
4. 自動化までのPhase
レビューの承認は以下の段階を経て自動化に至りました。 各Phaseは当初から決定していたのではなく、試行錯誤を繰り返し、現在の状態に至りました。
- Ph1. 生成AI導入の準備 (PoC)
- Ph2. 人の判断を支援するシステムの構築
- Ph3. 判定精度の向上対応
- Ph4. 自動化戦略
- Ph5. 自動化システムの構築
- Ph6. 自動化の開始
Ph1. 生成AI導入の準備 (PoC)
生成AI導入に向けて、まず業務分析と技術調査を実施しました。この過程で、規約違反の判断基準を明確化し、最適な技術構成を決定しました。
また生成AIを用いたPoCでは、人と生成AIで判断の一致率が約60%という結果が得られました。精度面では課題が残るものの、技術検証を通じて将来性を確認できたため、これら手法を採用しました。
業務分析
- 過去のレビューを分析し、規約違反の種類と発生頻度を定量化
- オペレーターへのヒアリングを通じて、判断基準と判断頻度を把握

技術調査
- 下記理由から、「生成AIによるプロンプトエンジニアリング」が最適と判断
- 柔軟性:生成AIは人に近い形で複雑な自然言語の解釈が可能
- 説明可能性:生成AIは判断根拠を人が理解しやすい形で示すことが可能
- 即応性:MLと異なり、中間パラメータの解釈なしで直接指示が可能
- 主要モデル(OpenAIやClaude等)の評価やRAGなどの技術検証も実施
プロンプト例

Ph2. 人の判断を支援するシステムの構築
PoCの結果を元に「人の判断を支援するシステム」を構築しました。
これは生成AIを活用しつつも最終的な判断は人が行う、現在主流の運用形態の一つです。効率的な運用が可能ですが、生成AIの活用はまだ途上のため判断の最終責任は「人」が担います。
また後述する承認ワークフローにより人と生成AIで判断の一致率は約95%となりました。[6]
システム概要
- 生成AIがレビューを分析し、その結果を管理画面に表示
- オペレーターは生成AIの分析結果を参考に承認の判断を実施

システム構成
- 基盤:Amazon Bedrockを中心に構築(既存のAWS環境との連携を考慮)
- 言語モデル:Claude 3.5を採用(高性能かつ精度の高い判断支援を実現)
- 処理フロー:レビュー投稿後、自動的に承認ワークフローを起動し、判定

承認ワークフロー
- AWS Step Functionsを使用して承認ワークフローを構築
- 承認ワークフローは複雑な判断プロセスを分解、誤判断を抑制する効果がある
- 第一ステップ:キーワード検出により明確な違反を検出
- 第二ステップ:文脈を判定し、文章の詳細をチェック
- 各ステップの結果を次に引き継ぐ、Prompt Chain方式

これらの取り組みはAWS公式記事でも紹介されました。[7]
Ph3. 判定精度の向上対応
自動化の実現には、更なる高精度が要求されることから、約6カ月間に及ぶ継続的な改善を実施しました。
以下3つの指標を注視しながら精度向上に取り組んできた結果、人と生成AIで判断の一致率は約99%となり、自動化への重要な足掛かりを築くことができました。
各指標の定義
- 一致率:人と生成AIで判断が一致した割合(不適切、適切なレビューも含む)
- NG検出率:不適切なレビューを正確に生成AIが識別できた割合
- NG精度:不適切と生成AIが判定したレビューのうち、実際に不適切だった割合
判定精度の推移
- 人と生成AIの一致率(不適切・適切を含む)は、99%に到達
- 自動化にもっとも重要な指標であるNG検出率も99%に到達
- NG精度については、人の判断への過剰適合を防止するため、一定の水準を維持
改善事例
| 差異分析 | 週次でオペレーターとミーティングを行い、生成AIと人の判断の差異を分析
|
|---|---|
| 事例データベース |
差異分析の結果を基に、判断基準を明確化した事例データベースを作成
|
| ニュアンスの学習 |
「誹謗中傷」などの曖昧な概念は、人によって感じ方が異なり、プロンプトから正確に判断させることは困難。そのため微妙なニュアンスを理解させる必要がある
|
| オフライン検証 | プロンプト変更の効果を事前に検証するツールを開発 過去のレビューを一括検証し、事前に修正影響を把握。リスクを最小化 |
| 判定区分の新設 | 判定結果にOK/NG以外の「UK(Unknown)」を新設[9] 生成AIが判断しにくいレビューをUKに分類し、誤判定のリスクを大幅に低減 |
| 判断不明ケースの明確化 | 情報不足により生成AIが判断できないレビューを明確化し、誤判断を抑制
|
Ph4. 自動化戦略
生成AIの高精度化を達成後、次の課題は自動化戦略の策定でした。一致率99%という高精度を実現したものの1%の差異が自動化への障壁となっていました。[10]
この微細な差異の完全な解消が現実的でないと判断し、新たなアプローチを採用しました。具体的には「生成AIと人の判断の完全一致領域を特定し、そこから段階的に自動化を進める」というものです。
この実現のため「AIスコア」という新しい指標を導入しました。
「AIスコア」は、レビューの問題度合いを0から1の数値で表し、その値に応じて区分を設定したものです。低いほどレビューは適切、高いほど問題があることを示します。そのスコアとレビューに関する分析の結果、以下が判明しました。
分析結果
- AIスコアが0.15以下のレビューは、人と100%一致(直近1カ月)
- この領域には良質のレビューが集中
- 全体の約70%のレビューがこの条件に該当
この結果を基に、次の自動化戦略を策定しました。
- AIスコアが0.15以下のレビューは自動的に承認
- AIスコアが0.15を超えるレビュー(全体の約30%)は、人が承認[11]
この戦略により安全性を確保しつつ大幅な自動化が可能となりました。[12]
次のステップでは、この戦略を実装するためのシステム構築に着手します。
Ph5. 自動化システムの構築
Ph2の承認支援システムを拡張し、自動化機能を作成します。 以下の3つの施策を実施することで、頻繁な更新や改善にも対応しつつ、高い信頼性と柔軟性を持つシステムを構築できました。
a.環境分離対策
- システムを2環境に分離
- 承認支援環境:生成AIの判断を参考に人が承認する従来環境。調整が可能
- 自動化環境:十分に検証した生成AIによる自動承認環境。リスクを最小化 [13]
b.自動承認モジュールの開発
- 生成AIが下した判断を、データベースに反映するモジュールを開発
- この対応により自動的にレビューの承認が可能 [14]
c.段階的デプロイメント
- 安全に継続的な改善を可能にするデプロイメントを確立
- GitHubフローによる各環境の安全性を担保
- 新機能を承認支援環境にデプロイ(α版)
- オンライン環境における十分な検証期間の確保
- 問題がないことを確認後、自動化環境にデプロイ(β版)
Ph6. 自動化の開始
判定精度と環境を整えたタイミングで、PoCを兼ねて一部のレビューを自動化することに決まりました。[15]
下記追加策も同時に進行し、公開後の安全性も確保しています。
- 自動承認チェック機能: 自動承認されたレビューを人が定期確認できる機能
- レビュー報告機能: 不適切なレビューをユーザーが管理者に通知できる機能
詳細な自動化の成果については、後日、別途ブログで紹介させていただきます。
5. 総括
成果
本プロジェクトによりレビュー承認業務の自動化の仕組みを実現しました。特筆すべき点として、AIスコア0.15以下の領域(全体の7割)では人との判断が100%一致しました。(直近1カ月)
実現ポイント
自動化の成功には、以下が重要です。
段階的アプローチ:自動化を一気に進めるのではなく、PoCから始まり、人の判断を支援するシステムの構築、精度向上、自動化戦略の策定という段階を踏むことで、着実に目標を達成します。
人とAIの協調:生成AIの判断が難しいケースやリスクの高い領域では人に判断を委譲します。AIスコア、UK判定の導入などが該当します。
信頼性の確保:公開リスクを最小限に抑えるため環境分離、段階的デプロイ、自動承認チェック機能等の対策が有効です。
継続的な改善:判定精度の向上にはオペレーターとの継続的なヒアリングと分析、プロンプトの調整が必要です。
結び
本プロジェクトでは、大規模システムにおける重要な判断でも、生成AIによる自動化が可能であることを示しました。これは生成AIの可能性を示す重要な一歩となります。
一方で「生成AIの判断にも誤りがある」という懸念も理解できます。しかし人の判断もまた完璧ではありません。生成AIの急激な進歩を踏まえると、人とAIの役割を明確にしつつ、ポテンシャルを引き出すことが重要になってきます。
また先日AWS re:Invent 2024に参加し、レポートを記載しました。
2025年、生成AIは意思決定や物理層連携(産業ロボットの統合)が予定されています。この発展に伴い、本対応が目指した信頼性と精度の向上が極めて重要になってきます。
今後レビュー承認の適用範囲を拡大し、さらなる自動化を目指す予定です。
この取り組みが生成AI活用の先駆事例となり、イノベーションにつながれば幸いです。
あとがき
このプロジェクトは、チームリーダー(BE)兼 テックリードの松井とプロダクトオーナーの室木の2名で短期間かつ限られたリソースの中で進めました。
新技術を追いかけることも、実績ある技術に固執することもせず、まずは目の前の課題である「レビュー承認の自動化」という目標に向き合いました。必要以上に複雑にせず、かつ必要な革新性は取り入れる。限られた人数でも成果を出すための鍵だったのかもしれません。
また振り返ると、私の多様な技術領域での過去の経験が、このプロジェクトの成功に不可欠でした。これらが全て融合できたからこそ実用的で精度の高いシステムを短期間で構築できました。
このプロジェクトは、そんなエンジニアのキャリアの奥深さを教えてくれました。
求人とお問いわせ
ユーザーレビューグループでは、生成AIを活用した開発や、大規模プラットフォームを開発しています。興味のある方は以下よりご応募ください。
また求人詳細や本記事に関するお問い合わせは下記のレビューに関する問い合わせからご連絡ください。
補足
- [1]:判定精度とは人と生成AIの判断の一致した度合いを指します。
- [2]:承認自動化にあたり、Anthropic社のユースケースに基づく適切なコンテンツモデレーションを実施し、AWSとの協力により信頼性を確保し実施しています。
- [3]:生成AIによる承認誤りが発生した場合、公開すべきではないレビューが公開される為、慎重な判断が必要です。
- [4]:自然言語の判断が難しい事例として左記に記載されている3.2をご確認ください。判断が難しい事例
- [5]:オペレーターの稼働状況により、最大1週間の待ち時間が生じていました。
- [6]:システム構築当初の精度は95%でした。後述するPh3以降で99%まで精度を上げています。
- [7]:https://aws.amazon.com/jp/builders-flash/202411/genai-review-approval-system/
- [8]:https://arxiv.org/html/2404.11018v3
- [9]:UKが発生する割合は全体の1割程度としています。
- [10]:残りのレビューは、人の判断もばらつきが大きい部分です。
- [11]:将来的にはこの範囲も自動化対象として拡大する見込みです。
- [12]:当初から安全なレビューの自動化に着手することはできませんでした。その理由として、安全なレビューの定義が確立されていなかったことと、誤判定のリスクを抑えながら段階的に精度を向上させる必要があったためです。
- [13]:STG環境でも簡易検証は可能ですが本番環境においても充分な検証を実施する必要性から自動化環境を作成してます。
- [14]:生成AIのエージェントによる柔軟な判断の実装を検討しましたが、 レビュー承認作業は、処理の流れが明確で尚且つ重要な判断を要することからシンプルな制御方式としてます。
- [15]:まずPoCとして自動化を実施し、その知見を今後取り入れる予定です。