政治コミュニティにAIファクトチェック機能を組み込む中で経験した試行錯誤

こんにちは。
約6か月前、法案をわかりやすく見て意見を残せる市民参加サービス「オフン」を紹介した開発者です。

今回、コミュニティ内のフェイクニュースや不毛な議論を減らすために AIファクトチェック 機能を導入しました。その過程での悩みや技術的な試行錯誤を共有したいと思います。

最初は非常にシンプルにアプローチしました。対象テキストを渡して、「この文章が事実かどうか検証して」とプロンプトを書いたのです。しかし実際にサービスへ載せてみると、予想外の問題が次々に出てきました。

単なる個人の「意見」まで事実であるかのようにファクトチェックしようとし、根拠がないのにもっともらしい結論を出してしまいました。さらに、ファクトチェックが終わった後に投稿者が本文を編集してしまうと、結果の整合性が取れないという困った状況も起きました。

結局、初期の構造はすべて捨て、現在はパイプラインをかなり作り直して、以下のように運用しています。

1. 検証対象の切り分け（意見 vs 事実）

文章全体を一度に検証するのではなく、客観的に検証可能な「事実主張」だけを先に抽出するようにしました。「この政策は最悪だ」のような価値判断は無視し、「この法案は税金を20%引き上げる」のような文だけを対象にする、というやり方です。
正確に文脈を把握するため、対象テキストだけを見るのではなく、元の投稿、親コメント、さらには添付画像までマルチモーダルにまとめて AIにコンテキストを提供しています。

2. 「わからない」と答えさせる

特に気を使った部分の一つです。LLM特有のハルシネーションを防ぐため、クロスチェックできる信頼性の高い根拠が不足していたり、確認が不可能だったりする事案については、無理に結論を出さず「不明」「判断保留」と応答するよう、プロンプトを強く制御しました。

3. 原文スナップショットの保存と透明な出典提示

投稿者が文章を編集してしまう問題を防ぐため、ファクトチェックを依頼した時点の原文データ（スナップショット）をそのまま保存します。他のユーザーが結果を見る際に、「どの時点のどのテキスト/画像を基準に検証したのか」「どの出典を参照したのか」を透明に確認できるようにしました。

4. トラフィックとリソースの処理

このように文脈をすべて集めて検証するプロセスは重いため、ユーザーの待機キュー管理が必要でした。そこでリクエストはすべて Redis Cluster + BullMQ を活用して非同期キューに投入し、バックグラウンドワーカーで順次処理しています。
コストと速度を考慮して Gemini 3.5 Flash をメインモデルとして使いつつ、エラー率が高くなったり複雑な推論に失敗したりした場合は Gemini 3.1 Pro にフォールバックさせる構成を適用しました。
（無分別なリクエストを防ぐため、1日1回は無料提供し、その後はアプリ内ポイントを差し引く制限も設けました。）

まだ取り組んでいる課題

自分なりに防御ロジックを組みましたが、依然として難しいケースは多くあります。統計の基準時点が異なる場合、政治家特有の比喩や解釈が介在する発言、あるいは巧妙に事実と虚偽が混ざった長文は、まだ完全に処理するのが難しいですね。

オフンアプリで直接テストできます。
もしこのような検証ロジックでハルシネーションをよりうまく抑えるプロンプトのノウハウや、ユーザーが曖昧な結果をより受け入れやすくするUX/UIのアイデアがあれば、気軽にアドバイスをお願いします。長文を読んでいただき、ありがとうございました！

Google Play: https://play.google.com/store/apps/details?id=kr.uhheung.app
App Store: https://apps.apple.com/kr/app/%EC%96%B4%ED%9D%A5/id6751951353