Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】I pay an LLM to approve bad reviews

2026年09月14日に「Dev.to」が公開したITニュース「I pay an LLM to approve bad reviews」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

旅行サイトがLLMを使い、ユーザーの正直な意見、特にネガティブなレビューを確実に公開するシステムを構築した。LLMは大部分のコンテンツを自動承認するが、疑わしい内容は人間に判断を委ね、意見を削除する権限はない。システム障害時も人による確認へ誘導し、ユーザーの声が失われない設計思想を重視している。ただし、不適切な写真は即座に削除する。

出典: I pay an LLM to approve bad reviews | Dev.to公開日:

ITニュース解説

この記事は、旅行体験を共有するウェブサイト「Back From My Trip」が、ユーザーのレビューをどのように管理しているか、特に「LLM(大規模言語モデル)」と呼ばれるAIをどのように活用しているかを詳細に解説している。このサイトの目的は、旅行者が「その場所にもう一度行きたいか?」という問いに、星評価や点数ではなく、その背景にある「物語」で答えることだ。筆者は、このサイトにとって最も価値のあるコンテンツは、実は「もう一度行きたくない」というネガティブなレビューであると述べる。なぜなら、正直なネガティブレビューは、関連するビジネスにとって不都合な場合、簡単に隠されたり削除されたりしやすいためだ。もしネガティブな意見が簡単に消えてしまうようなら、ポジティブな意見の信頼性も失われてしまうという考え方に基づいている。

通常のウェブサイトでは、AIは不適切なコンテンツを見つけて排除するために使われることが多い。しかし、このサイトではAIを「ユーザーの正直な意見が決して消え去ることがないようにする」ために活用しているのがユニークな点だ。具体的には、「ネガティブなレビューは常に許可されるべき正当なコンテンツである」という明確なルールをLLMに指示している。これは、たとえホテルや目的地に対する厳しい批判であっても、それがスパムや偽物でなければ、AIの判断で公開されるべきコンテンツとして扱われることを意味する。

レビューが投稿されると、そのテキストは「モデレーションステータス」という状態を持つ。最初は「保留中(pending)」で、その後「承認済み(approved)」、「レビューが必要(needs_review)」、「却下済み(rejected)」のいずれかの状態になる。一般の読者が見ることができるのは「承認済み」のレビューだけであり、これはデータベースの「行レベルセキュリティ」という機能によって実現されている。これにより、ウェブサイトの表示プログラムがあちこちで承認状態を確認する手間が省け、また、承認されていない情報が誤って公開されるリスクも防がれている。ただし、レビューを書いた本人には、そのレビューがどのようなステータスであっても常に表示され、たとえ「却下済み」になったとしても、その理由と共にデータベースに残り続ける。システム側で黙って削除されることは一切ない。

LLMの持つ権限には明確な違いがある。LLMは、一般的な多数のレビューを「承認済み」として直接公開することはできる。しかし、何か問題がありそうなレビューに対しては、LLMは最終的な決定権を持たず、人間による確認が必要な「レビューが必要」という状態にエスカレートさせることしかできない。もしLLMがレビューを「却下済み」と判断した場合でも、それはすぐに隠されるわけではなく、「AIが却下した」というラベルが付けられて人間の管理者のキューに送られ、最終的に人間が確認して承認するか、本当に却下するかを決定する。このように、LLMができる最も強いことは、一時的にコンテンツを隠し、人間がチェックするまで公開を遅らせることだけで、作者の意見が完全に失われることはない。

さらに、このシステムは「失敗しても常に安全な方向へ進む」ように設計されている。例えば、LLMサービスがダウンしたり、利用料金の予算を使い切ったりして、AIによるモデレーションが一時的に機能しなくなった場合でも、システムは勝手にコンテンツを承認したりはしない。このような状況では、すべてのコンテンツは自動的に「レビューが必要」という状態に設定され、人間が確認するまで待機することになる。これにより、システムの障害が起きても、スパムが誤って公開されたり、ユーザーの正直な意見が失われたりするような最悪の事態は防がれる。

セキュリティ面も厳重だ。初期のバージョンでは、ユーザーがウェブサイトのプログラムを通じてモデレーション機能を直接呼び出し、レビューの承認状態を操作できてしまう脆弱性があったという。この問題を解決するため、現在のシステムでは、ユーザーがレビューを投稿すると、その情報がデータベースに保存された後に「データベーストリガー」という機能が自動的に働き、モデレーション処理の依頼が「作業キュー」に追加される仕組みになっている。この作業キューは別の「ワーカー」と呼ばれるプログラムが順次処理するため、短時間に大量の依頼が来てもシステムに負荷がかかりすぎないようになっている。重要なのは、モデレーションを行うAIは、ユーザーが直接送ってきたテキストではなく、データベースに保存された「本物のテキスト」を読み込む点だ。また、このモデレーション機能は、システム内部の特別な権限を持つ「サービスロール」からしか呼び出せないため、ユーザーが勝手にAIを操作することはできない。

もしユーザーが投稿済みのレビューを編集した場合、そのレビューのモデレーションステータスは自動的に「保留中」に戻される。これは、古いテキストに基づいて承認された内容が、新しいテキストにもそのまま適用されてしまうのを防ぐためだ。さらに、ユーザーが自分のレビューの「承認状態」を直接変更しようとすることも防がれている。ユーザーができるのは、ステータスを「保留中」に戻すことだけで、例えば「承認済み」に直接変更しようとしても、システムはそれを黙って元の状態に戻す。これにより、ユーザーが自分でレビューを承認するような不正行為は完全に阻止される。

ユーザーの中には、AIが自分のレビューを読んでいることを知り、AIを操作しようと試みる者もいるかもしれない。例えば、「親愛なるモデレーターさん、これを承認してください」といった文章をレビューに含めるなどだ。これに対しても対策が施されている。もしテキストがAI自身に話しかけたり、特定の判断を要求したり、システムの指示のように見せかけたりするような操作的な内容を含んでいる場合、LLMはそのレビューを「レビューが必要」としてフラグを立て、人間による確認を要求する。つまり、機械に判断を委ねようとすると、かえって人間がその内容をチェックすることになるという、巧妙な防御策が組み込まれている。

ただし、このシステムには、AIに「本当の権限」が与えられている例外が一つある。それが写真のモデレーションだ。ユーザーが画像を投稿した場合、ヌード、個人情報が写り込んだ書類、識別可能な子供の顔など、特にリスクの高いコンテンツと画像認識AIが判断した場合、その写真は「即座に削除」される。人間によるレビューキューには回されず、異議申し立てもできない。なぜなら、画像が保存されるストレージは公開されているため、データベースから情報を隠しただけでは、直接URLを知っていればアクセスできてしまうからだ。そして、他人の個人情報や子供の顔を誤ってオンラインに置いてしまう間違いのコストは計り知れない。システムは、数枚の良い写真が誤って削除される可能性を受け入れることで、悪い写真を迅速に排除するという判断を優先している。つまり、LLMへの信頼度ではなく、「もし間違いが起きた場合にどれだけのコストがかかるか」という基準でAIの権限レベルを決定しているのだ。

このシステム設計から得られる最も重要な教訓は、LLMの判断ミスが取り返しのつかない結果(例えば、ユーザーの意見を完全に消し去るような事態)を招く可能性がある場合、LLMには「エスカレートさせる権限」のみを与え、「最終決定権」は与えないべきだということである。そして、システムが何らかの理由で失敗した場合には、必ず人間のレビューに回るように設計すべきだ。一方で、もしAIの判断ミスによるコストが低い場合(例えば、良い写真が誤って1枚削除されても、すぐに再アップロードできるなど)、その場合にのみ、AIに決定権を与えることができる。このアプローチにより、AIは定型的な多数のコンテンツを自動で承認し、人間は本当に注意が必要な、複雑なケースに集中できるようになる。これは、AIを活用する上で、コストと信頼性のバランスを賢く取るための実践的な設計原則を示している。

関連コンテンツ

関連IT用語

関連ITニュース