はじめに
AI技術開発部の菊地です。最近、Deep Researchをはじめとする推論モデルを使って、企業調査や業界調査をすることがあるのですが、その能力の向上には驚かされるばかりです。
一方で実務としてはハルシネーションや論理の飛躍、または文章の拙さが散見され、出力結果をそのまま使うには不安を感じることが少なくありません。
一般に企業調査・業界調査において、「やや古い情報」（時系列的な考察）は、あくまで正確かつ重要な関連情報に相互引用されていることが多く、複数の文書からのクロスチェックは非常に難しくなります。
たとえば「GO株式会社について教えてください」という指示文を与えてみると、ほとんどが正確な情報ですが、やはりサービス情報がやや古かったり、特定の情報だけを大きく扱ったりしています。いくら半自動化といっても、どこの部分が間違っているのかわからないのでは意味がありません。
そこで本稿では、特定の調査テーマに依存した対症療法的なアプローチではなく、「GO株式会社について教えてください。その際には以下の品質向上モジュールを用いてください。」といった使い方のできる汎用的な追加モジュールを作る試みを行いました。
ここでは代表的な手法を5つ紹介します。
1. FActScore：最小単位の事実による正誤判定
映像生成のように「正解」が主観に委ねられるタスクとは異なり、Deep Researchを実務に用いる最初の動機としては、生成AIを「高度な検索・集計エンジン」として利用したいというケースが多いと思います。
ただ我々は暗に「正確」かつ「重要」な検索結果を期待しているわけで、それを判断する「自律的な調査エージェント」をいかに丁寧に作り上げるかというのが重要となります。
たとえば正確性においては、「抽出漏れ（False Negative）」や「抽出間違い（False Positive）」といったコンフュージョンマトリックスの枠組みが品質保証の指標として使われます。
ここではそのような例として、FActScore (Factual Accuracy in Storage Score) を紹介します。
FActScoreとは、収集した文章が単体で正しくとも、それらの組み合わせ（因果関係の取り違えなど）によって生じるハルシネーションを、このコンフュージョンマトリックスの検証プロセスによって棄却する手法です。
一方でこのように徹底的に間違いを排除しようとする試みは、あまりに保守的で情報の網羅性を損なうリスクがあります。そこで人間が後工程で見直しをすることを前提として、重要度・信頼度を付与して、なるべく多くの情報を出力させたいわけですが、LLMにとってはそのような連続値的な「スコアリング」は非常に苦手とするタスクです。
そこで重要度・信頼度を得る場合には、LLMの得意なパターン認識、すなわちTier 1（必須検証項目）からTier 3（許容される情報）に分類するTier分類のタスクとして実装します。この階層化により、コンフュージョンマトリックスとの相性が良くなり、精度の高い正誤判定が可能となります。
参考文献 Min S et al. (2023) “FActScore: Fine-grained atomic evaluation of factual precision in long form text generation”, Empirical Methods in Natural Language Processing (EMNLP), arXiv:2305.14251.
2. Citation-Aware Self-Correction：ソース引用の自己最適化
LLMには「外部に記述された内容」の真偽や重要性を分析する機能だけでなく、「自分が記述したレポート」の真偽や重要性を分析する「自己修正」（Self-Correction）」や「自己監査」（Self-Audit）という能力があります。いわば自律的に校正を進めていく仕組みです。
上に述べたFActScoreが「記述内容の真偽」を確認するものであるのに対し、Citation-Aware Self-Correction は、「文章とソース（根拠）」の関係性が最適であるかを評価・改善の対象とします。
これは生成された「文章とソース」というペアを確定事実として扱うのではなく、さらに「より良い文章とソースの組み合わせ」を模索するプロセスです。
具体的には、ソースの確定を受けてより適切な表現へ文章を再構築する、あるいは現在のソースよりもさらに信頼性や専門性の高い一次資料に差し替えられないかを検証するといったステップを挟みます。この手法の利点は、調査のテーマが何であれ、システム側で機械的に「根拠の質」を追求できる汎用性にあります。
参考文献 Lin L et al. (2023) “Just ask one more time! Self-agreement improves reasoning of language models in (almost) all scenarios”, Findings of the Association for Computational Linguistics (ACL), arXiv:2311.08154
3. LLM-as-a-Judge：多角的指標による統合的品質監査
局所的な事実や引用の検証という文章の要素を検証するアプローチに対し、「生成されたレポート自体」を評価するアプローチにLLM-as-a-Judgeというものがあります。
高度なリサーチにおいては、一次ソースに基づく情報と、不足する情報を補うための推論を正確に分けることが不可欠です。この境界が曖昧なままでは、レポートの生成段階において全体の正しさが歪められる可能性があります。
LLM-as-a-Judgeは、事実の真正性、論理的整合性、網羅性、中立性、戦略的示唆といった複数の観点からレポートを総合的に評価します。
特に生成結果を評価するモデル自身の品質を高めていくことで、より客観的な評価が可能になるという特徴があります。
引用文献 Zheng L et al. (2023) “Judging LLM-as-a-Judge with MT-Bench and chatbot arena”, Neural Information Processing Systems (NeurIPS), arXiv:2306.05685.
4. Creator-Critic：敵対的ロール設定による自己検閲の高度化
生成精度を極限まで高めるためのもう一つのアプローチとして、Deep Researchのプロセスに「対立的な二重ロール」を導入する Creator-Critic 法があります。
通常、システムプロンプトで役割を与える手法は一般的ですが、本手法はGAN（敵対的生成ネットワーク）の概念を利用し、「生成者（Creator）」と「批判者（Critic）」という対立する人格を明示的に衝突させることで、自己検閲によるフィルタリングを発生させます。
具体的には、「あなたはAIのプロとしてビジネス報告書を作成せよ」という指示に対し、「私はビジネスのプロとして、あなたの調査結果を批判的に検証し、論理的矛盾や根拠の薄いハルシネーションを徹底的に排除する」という対立的な役割を与えます。
この手法はモデル内部（あるいはエージェント間）で「自己対話」を発生させ、生成者が書いた文章を批判者が「それは本当に事実か？」と問い直すプロセスを繰り返すことで、推論で行間を埋める傾向を抑える効果があります。
参考文献 Du Y et al. (2024) "Improving factuality and reasoning in language models through multiagent debate", Intl Conf Machine Learning (ICML), arXiv:2305.14325.
5. Python実行による決定論的な制約と形式の遵守
最後に、レポートの品質を左右する「形式的な完全性」について触れます。
LLMは本質的に確率論的なモデルということもあって、文字数や要素数のカウントといった計測を伴う指示を苦手とします。たとえば「500字前後でまとめよ」という指示が、「500字らしく見える文章」や「正しくない情報で500字を満たした文章」の生成に終わることがあります。
この課題を解決するためには、「500字前後（len計測）でまとめよ」といったPythonコードで命令する書き方があります。これはLLMによる曖昧な確率的な推論で解決せず、Pythonによる決定論的な実行に移譲させることを意味します。
LLMはプロンプト内のlenという単語から、決定論的な実行が必要と自律的に判断し、その結果を生成します。
これにより、「指定した項目数が足りない」「文字数が大幅に超過している」といった形式的なハルシネーションを物理的に封じ込めることができます。
参考文献 Google Cloud - Vertex AI "Use Code Execution" （※色々と公式HPを探して情報が見当たりませんでしたが、Geminiアプリでの実行も可能です。）
6. まとめ：ハルシネーションを抑制するための追加モジュール
一般的な調査タスクにおいてハルシネーションを排除する事例について紹介しました。
ハルシネーションを完全に排除することは、様々な困難がありますが、今回紹介したような検証・自己修正・監査のモジュールを重層的に組み合わせることで、特定の調査対象に依存しない、汎用性の高いモジュールを目指した結果をまとめました。
以下に、これまでの要素を統合した「汎用調査プロンプト・モジュール」の構成例を示します。
【実践例】ハルシネーション抑制用・汎用システムプロンプト
# 調査タスク
[ここに調査テーマを入力]
## 【最上位のルール：ハルシネーション抑制モジュール】
本タスクでは、LLM特有のハルシネーションを構造的に排除するため、以下の5つの検証プロセスを「Chain-of-Thought（思考の連鎖）」の中に組み込んで実行せよ。
1. **事実の最小単位化と階層評価 (FActScore-based Tiering)**:
- 生成された文章を、それ以上分解できない最小の「事実（Atomic Facts）」の集合に解体せよ。
- 各事実を以下の3層で分類し、Tier1に疑義がある場合はその事実を含む段落全体を破棄・再構築せよ。
- Tier 1: 根拠が明示的な中核事実
- Tier 2: 複数の根拠から推論可能な事実
- Tier 3: 補足的な背景情報
2. **引用に基づく自己修正 (Citation-Aware Self-Correction)**:
- 「1つの主張に対して必ず1つのソース」をマッピングせよ。
- 生成した文章と引用元ソースを照合し、文脈の飛躍や拡大解釈がないか自己修正せよ。より信頼性の高い一次資料がある場合は、引用を差し替えよ。
3. **審判員としての自己評価 (LLM-as-a-Judge)**:
- 最終回答の出力前に、あなた自身とは異なる「独立した監査官」の視点をシミュレートせよ。
- 真正性・論理的整合性・中立性を5段階で評価し、平均4.5未満の場合はボトルネックとなっている箇所を特定し、再生成せよ。
4. **敵対的プロンプティングによる検閲 (Creator-Critic Debate)**:
- 内部で「Creator(生成者)」と「Critic(批判者)」の2つのロールを演じ分けよ。
- Criticは「その推論はバイアスではないか？」「ソースの解釈が強引ではないか？」と徹底的に反論し、両者の合意が得られた内容のみを採用せよ。
5. **Python実行による決定論的バリデーション**:
- 文字数カウント（len）、数値の大小比較、表データの集計（pandas）等の処理は、LLMの確率的推論に頼らず、必ずPythonコードを実行して確定値を算出した上で記述に反映せよ。
## 【出力形式】
- 調査結果レポート
- 引用文献リスト（URLまたは資料名）
- 監査ログ
- FActScoreに基づく事実分解の例
- 検証に用いたPythonコードと実行結果
- Criticからの修正指摘内容とそれに対する改善策
