レビュー監視の目視時間を67.7%削減、ZOZOの生成AI一次判定フロー

アイテムレビューは、利用者が商品を選ぶときの参考情報として機能します。その一方で、商品不良や配送に関する書き込みはガイドライン上レビューの対象外と定められており、以前は担当者が投稿を一から目視で確認し、対象外の内容が混ざっていないかを探していました。この全件確認が現場の重い負担になっていた、というのが出発点です。

編集部の見立てでは、困りごとの正体は投稿件数の多さそのものではなく、「大半は問題のない投稿だと分かっているのに、ごく一部の例外を見つけるために全部に目を通さざるを得ない」という構造にありました。一件ごとの判断自体は難しくありません。難しいのは、どこに紛れているか分からない少数を取りこぼさないために、確認範囲を絞れないことのほうです。負担の中身が「判断の難しさ」ではなく「探す範囲の広さ」だったからこそ、範囲を狭める道具が効いたのではないでしょうか。

効いたのは、AIに削除まで任せず、「違反の可能性が高い」ものだけを人に手渡す形に役割を切り分けた設計です。LLMには判定が揺れる不確実性がつきまとうという前提を最初から運用に織り込み、最終的な線引きは担当者の目視に残しました。この切り分けにより、AIの精度が完璧でなくても仕組みを動かし始められます。判定を誤っても人の確認が受け止める構造になっているため、導入のハードルそのものが下がったと考えられます。

判定の対象を、汎用的な不適切表現ではなく自社のガイドラインという固有の基準に据えた点も見逃せません。商品不良や配送への言及は、一般的な意味で問題のある文章ではなく、このサービスの文脈においてのみレビューの対象外と位置づけられるものです。表現そのものではなく文章が何について書かれているかを読み取る必要があり、自然文の意図をつかむLLMの性質と噛み合っています。基準を細かく作り込むには外部ツールへの当てはめより自社開発のほうが動かしやすく、その選択が判定内容と一貫していました。

社内ニーズを起点にツールを内製し続ける進め方も、この事例を支える土台になっています。問い合わせ対応bot、記事タイトル＆目次ジェネレーターといった複数のツールが同じやり方で生まれており、レビューパトロールもその流れの中にあります。大がかりな一発の導入で全社を変えるのではなく、現場が困っている単位でAIの使いどころを切り出していく積み重ねが、実際に使われる道具を生む近道になっていると読み取れます。

2024年4月の運用開始から4か月間で、ガイドライン違反のチェックに費やす業務時間は67.7%削減され、担当者が目視した件数も68.5%減っています。手を動かす量が減っただけでなく、確認すべき対象が絞られたことに意味があります。違反レビューが効率よく取り除かれることで、レビュー機能が購入の判断により役立つ情報源へ改善されていくことが期待されている段階です。なお全社的なAI活用としては、エンジニア向けに導入したGitHub Copilotについて約9割のエンジニアが生産性の向上を実感しています。