偽のレビューはもはや評判だけの問題ではない。現在では米国、英国、欧州連合において法律上の問題でもあり、レビューを掲載するプラットフォームは何億件もの単位でこれらを削除している。ブランド、マーケットプレイス、トラスト&セーフティチームにとって、ここで実務上の問いが生じる。誰かが苦情を申し立てた1件の出品だけでなく、何千もの商品にわたってレビュー詐欺をどう見つけるのか、という問いだ。
このガイドでは、問題の規模、キャンペーンと一般顧客を実際に区別するシグナル、最も有用な3つのシグナルについてテスト済みのコード、そしてレビューデータを責任を持って収集する方法を扱う。
要点
- 規模は大きい。Googleは2025年にMaps上でポリシー違反のレビューを2億9200万件以上ブロックまたは削除し、Amazonは2023年に2億5000万件以上の疑わしい偽レビューを阻止したと述べている。
- レビューを読むことは機能しない。ある著名な研究では、偽のホテルレビューを見分ける人間の判定者の精度はほぼ偶然に近く、53%から62%の正答率だった一方、訓練されたクラシファイアは約90%に達した。
- 組織的なキャンペーンは行動上の痕跡を残す。数日間に集中するレビューのバースト、ほぼ同一の文言、他に履歴のないレビュアーなどだ。
- シグナルを組み合わせる。今回のテストでは、文言の類似性単独ではノイズが多かった一方、バーストと重複文言または1件のみのレビューアカウントを組み合わせると、植え込んだ偽レビューをすべて検出し、誤検知は最大でも3件だった。
- フラグは人間によるレビューのための手がかりとして扱い、レビュアーのデータは仮名化し、調査結果に基づいて行動する前に法的立場を確認すること。
問題の規模
プラットフォーム自身の透明性データが規模感を示している。
| プラットフォーム | 数値 | 期間 |
|---|---|---|
| Google Maps | ポリシー違反のレビュー2億9200万件以上をブロックまたは削除、偽のビジネスプロフィール1300万件以上を削除 | 2025年 |
| Amazon | 疑わしい偽レビュー2億5000万件以上を阻止 | 2023年 |
| Tripadvisor | 提出された3110万件のレビューのうち270万件が不正、不正の54%は事業者による自己宣伝、214,000件のAI生成レビューを削除 | 2024年 |
これらは発見されたレビューにすぎない。またこれらは、詐欺の大半がどのようなものかも示している。Tripadvisorでは、不正の半数以上が事業者本人または関係者によるレビューの水増しであり、手の込んだ欺瞞ではなかった。
ルールは変わった
現在、主要な3つの市場が偽レビューを明示的に禁止している。
- 米国。 2024年10月から施行されている、消費者レビューおよび推薦に関する連邦取引委員会(FTC)の規則は、偽レビュー、肯定的または否定的レビューの購入、開示なしのインサイダーレビュー、独立しているかのように見せかけた企業運営のレビューサイト、レビューの抑圧を禁止しており、同委員会が民事制裁金を求めることを可能にしている。
- 英国。 2025年4月6日以降、偽レビューの投稿または委託、インセンティブ付きレビューの隠蔽、誤解を招く形でのレビューの公開は禁止された行為であり、レビューを公開する事業者は偽レビューを防止・削除するための合理的な措置を講じなければならない。規制当局は世界全体の売上高の最大10%の制裁金を科すことができる。
- 欧州連合。 2022年5月以降、レビューを表示する事業者は、レビューが実際に製品を使用または購入した顧客によるものであることをどのように確認しているか、また確認しているかどうかを明示しなければならず、偽レビューの投稿または委託は禁止されている。
マーケットプレイスやレビュー公開者にとって、これにより検出はあれば望ましいものからコンプライアンスの一部へと変わる。ブランドにとっては、競合他社がレビューを購入した場合に行動を起こす手段が生まれる。これは一般的な情報であり、法的助言ではない。自社の状況については弁護士に相談されたい。
レビューを読むことが機能しない理由
この問題に関する最もよく知られた学術研究、コーネル大学のOtt、Choi、Cardie、Hancockによるものは、800件のホテルレビューのセットを構築した。400件は本物で、400件は欺くために書かれたものだった。3人の人間の判定者がこれらを分類した。その精度は53.1%、56.9%、61.9%であり、3人のうち2人については、当て推量との差は統計的に有意ではなかった。3人とも、レビューを本物だと信じる傾向があった。単語のパターンで訓練されたクラシファイアは89.8%に達した。
これには2つの含意がある。手作業での抜き取り検査は大半の偽物を見逃す。そしてテキストのみによる検出は、2011年当時よりも今の方が難しい。モデルは要求に応じて多様で自然な文章のレビューを書くことができ、これがTripadvisorが現在AI生成レビューを独自のカテゴリーとして報告している理由だ。より有効性が持続するシグナルは行動に基づくもの、すなわちレビューがいつ届くか、誰が書くか、そして互いにどれほど似ているかだ。
有効性が持続するシグナル
| シグナル | 何を検出するか | 弱点 |
|---|---|---|
| バースト | 通常は1日2件程度の商品に対し、数日間で何十件ものレビューが集中する | セール、発売、報道後の正当な急増 |
| ほぼ重複する文言 | 単語を少し入れ替えたテンプレート化されたレビュー | 本物のレビューに共通する言い回し、多様なAI生成テキスト |
| 1件のみのレビューアカウント | 単一のキャンペーンのために作成されたレビュアー | 新規の正当な顧客 |
| 評価の分布形状 | 詳細の乏しい5つ星レビューが突然連続する | 実際に優れている商品 |
| 商品間の重複 | 同じレビュアーたちが1つの販売者の複数商品に登場する | ロイヤルカスタマー |
| 市場間の差異 | ある国の店舗ページで商品の評価が著しく異なる | 現地版やサービスの実際の違い |
単独で信頼できるシグナルはない。バーストは成功した発売の結果かもしれず、似た文言はよくある言い回しかもしれない。キャンペーンは複数のシグナルを同時に示す傾向があり、これが組み合わせることを効果的にする理由だ。
コード
以下のモジュールはこれらのシグナルのうち3つと、それらを組み合わせる1つの方法を実装している。外部ライブラリは不要だ。レビュアー名は分析前にソルト付きハッシュに置き換えられる。レビューは個人データであり、分析には名前そのものは決して必要ないためだ。
import hashlib
import re
from collections import Counter, defaultdict
from statistics import median
def pseudonymise(author, salt):
"""Replace a reviewer's name with a stable token, so analysis never needs the name itself."""
return hashlib.sha256((salt + author).encode()).hexdigest()[:12]
def review_bursts(reviews, k=6.0, min_count=5):
"""Flag days whose review count is far above the product's typical day, using a robust baseline."""
daily = Counter(r["date"] for r in reviews)
counts = list(daily.values())
base = median(counts)
spread = median(abs(c - base) for c in counts) or 1
flagged = []
for day, n in sorted(daily.items()):
if n >= min_count and n > base + k * spread:
day_reviews = [r for r in reviews if r["date"] == day]
five_star = sum(r["rating"] == 5 for r in day_reviews) / n
flagged.append({"date": day, "reviews": n, "baseline": base, "five_star_share": round(five_star, 2)})
return flagged
def shingles(text, size=5):
text = re.sub(r"\s+", " ", text.lower()).strip()
return {text[i:i + size] for i in range(max(1, len(text) - size + 1))}
def near_duplicates(reviews, threshold=0.5):
"""Pairs of reviews by different reviewers whose wording overlaps heavily (Jaccard on 5-character shingles)."""
sets = [shingles(r["text"]) for r in reviews]
pairs = []
for i in range(len(reviews)):
for j in range(i + 1, len(reviews)):
if reviews[i]["reviewer"] == reviews[j]["reviewer"]:
continue
overlap = len(sets[i] & sets[j]) / len(sets[i] | sets[j])
if overlap >= threshold:
pairs.append((reviews[i]["id"], reviews[j]["id"], round(overlap, 2)))
return pairs
def one_review_accounts(reviews, history):
"""Share of reviewers in this set who have reviewed nothing else; history maps reviewer to their total reviews."""
reviewers = {r["reviewer"] for r in reviews}
return sum(history.get(x, 1) == 1 for x in reviewers) / len(reviewers)
def suspicious_reviews(reviews, history, threshold=0.5):
"""Combine the signals: a review is suspicious when it sits in a burst and either duplicates
other wording or comes from a one-review account."""
burst_days = {b["date"] for b in review_bursts(reviews)}
duplicated = defaultdict(int)
for a, b, _ in near_duplicates(reviews, threshold):
duplicated[a] += 1
duplicated[b] += 1
return [r["id"] for r in reviews
if r["date"] in burst_days and (duplicated[r["id"]] or history.get(r["reviewer"], 1) == 1)]バースト検出器は、平均と標準偏差ではなく中央値と中央絶対偏差を使用する。これにより、バースト自体がそれを測定する基準値を押し上げてしまうことがない。near_duplicates内のペア比較は単一商品のレビューには適しているが、カタログ全体にわたる場合は、まず商品または販売者ごとにレビューをグループ化するか、局所性鋭敏型ハッシュを使用すること。
性能
答えがあらかじめわかっている構築済みデータセットでこのコードをテストした。1つの商品について6か月分の自然なレビュー、1日数件のペースで現実的な評価と多様な文言を持つ256件から285件、さらにそこに新規アカウントによる40件のテンプレート化された5つ星レビューからなる、3日間にわたるキャンペーンを植え込んだ。6種類の異なる乱数シードで実行した。
| チェック項目 | 6回の実行における結果 |
|---|---|
| バースト検出で見つかったキャンペーン日 | 毎回3日すべて。基準値2件に対し1日13件から16件 |
| 組み合わせルールで検出された植え込みレビュー | 毎回40件中40件 |
| 組み合わせルールで誤って検出された本物のレビュー | 0件から3件 |
| 文言の類似性のみによる、本物のレビューを含む重複ペア | 27件から42件 |
| 他にレビューを持たないレビュアー | キャンペーン当日は81%から100%、全体では27%から31% |
最後の2行が重要だ。文言の類似性単独では、本物の顧客を含む数十組のペアにフラグが立った。本物のレビューはありふれた言い回しを共有するからだ。バーストと組み合わせて初めて精度が得られた。これが踏襲すべきパターンだ。1つのシグナルに候補を挙げさせ、別のシグナルに確認させる。
構築されたテストは現実世界ではない。実際のキャンペーンは数週間にわたってレビューを分散させ、文章を変え、使用前にアカウントを熟成させる。実運用ではより低い再現率を見込み、すでに確認済みの事例で閾値を調整し、すべてのフラグを判定としてではなく人間によるレビュー担当者への手がかりとして扱うこと。
レビューデータの収集
検出には、日付、評価、履歴を把握できる十分なレビュアーの文脈を伴ったレビューが必要だ。収集にあたって重要な点がいくつかある。
- 複数市場にわたって収集する。 同じ商品でも、国ごとの店舗ページでは異なるレビューが表示されることが多く、キャンペーンはしばしば特定の1市場を狙っている。各国内から各店舗ページを収集することで、現地の買い物客が実際に目にするものがわかる。これは顧客レビューの監視で使われているのと同じアプローチだ。
- 履歴を保持する。 バーストや1件のみのレビューアカウントは時間をかけてしか測定できないため、スケジュールに従って収集し、収集したものを保持すること。
- 個人データを最小化する。 可能な限り、名前ではなく仮名化されたレビュアートークンを保存し、分析で使うフィールドのみを保持し、保持期間を設定すること。詳しくはレジデンシャルプロキシとGDPRを参照のこと。
- ルールの範囲内にとどまる。 公開されているレビューページを控えめなペースで収集し、各サイトの利用規約を尊重し、ログインの背後にあるものには手を出さないこと。
レビュー詐欺が単独で発生することはまれだ。レビューを購入する販売者はしばしば出品ページを乗っ取り、あるいは偽造品を販売し、レビューテキストはますます他のAI生成コンテンツと同じ精査を必要としている。多数のソースにわたってこれを実行するチームにとって、より広範なワークフローは当社の大規模コンテンツモデレーションページで説明されている。
結論
偽レビューはありふれたものであり、現在では最大の市場で明示的に違法とされており、読むことでは見抜きにくい。キャンペーンを見破る手がかりとなるのは行動だ。短期間に多すぎるレビュー、互いに似すぎている文言、他に履歴のないアカウント。
時間をかけ複数市場にわたってレビューを収集し、執筆者を仮名化し、互いに確認し合うようシグナルを組み合わせ、誰かが行動を起こす前にフラグが立てられたものを人間に送ること。
出典および参考文献
- Google、New ways we’re protecting businesses on Maps、2025年のデータ。
- Amazon、How Amazon maintains a trusted review experience。
- Tripadvisor、2025 Transparency Report。
- Federal Trade Commission、final rule banning fake reviews and testimonials、2024年8月。
- Ott、Choi、Cardie、Hancock、Finding Deceptive Opinion Spam by Any Stretch of the Imagination、ACL 2011。
- 構築済みテストデータセットおよびコード、Shifterによる、2026年10月2日。