Claude APIでハルシネーションを削減する4つの実装パターン

Claude APIでハルシネーションを削減する4つの実装パターン

Claude APIが生成する出力の事実誤認(ハルシネーション)は、プロンプト側の工夫でかなり抑え込めます。公式ガイドが挙げる基本策は、①「わからない」と言ってよいと明示する②長文の逐語引用でグラウンディングする③主張ごとに引用で裏取りする④Best-of-N比較で回答のブレを検出する、の4つです。以下、それぞれをそのまま使えるプロンプト例つきで見ていきます。

Claude自身が悪意を持って嘘をつくわけではありません。文脈が足りない・指示が曖昧なときに、もっともらしい補完で穴を埋めようとする挙動が原因です。だからこそ、対策の大半は「補完させない条件」をプロンプトに明記することに集約されます。

この挙動が特に問題になるのは、契約書のレビュー・財務レポートの分析・医療情報の要約のように、誤りの代償が大きいタスクです。逆に、文章の口調を整える・アイデアを出す・ラフな草稿を作るといった創作寄りのタスクでは、多少の補完はむしろ有用に働くこともあります。したがって4つのパターンをどこまで厳格に適用するかは、タスクが「事実の正確さが最優先か」「発想の幅が優先か」によって変わります。

パターン1: 「わからない」と言ってよいと明示する

最も効果が大きいのに見落とされがちな一手です。プロンプトに「不確実なら断定せず、わからないと答えてよい」という許可を明示的に書くだけで、根拠のない断定が大きく減ります。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 1024,
    "messages": [{
      "role": "user",
      "content": "M&Aアドバイザーとして、AcmeCoによるExampleCorp買収案のレポートを分析してください。財務予測・統合リスク・規制上の障壁に注目してください。もし判断材料が不足している、または不確実な箇所があれば断定せず『この点を確信を持って評価するには情報が不足しています』と述べてください。\n\n<report>{{REPORT}}</report>"
    }]
  }'

ポイントは「不確実なときの逃げ道」を用意すること自体ではなく、その逃げ道を使ってよいと事前に許可する文言を入れることです。許可がないと、Claudeは「役に立たなければ」という圧力から断定に寄りがちです。

パターン2: 20000トークンを超える文書は逐語引用でグラウンディングする

長文(20000トークン超)を要約・分析させるタスクでは、本題の回答を書かせる前に文書から一字一句そのままの引用を先に抽出させる工程を挟みます。抽出した引用が回答の足場になり、Claudeが自分の一般知識で穴埋めする余地を減らします。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 2048,
    "messages": [{
      "role": "user",
      "content": "データ保護責任者として、この改訂版プライバシーポリシーがGDPRとCCPAに準拠しているか確認してください。\n<policy>{{POLICY}}</policy>\n\n1. GDPRとCCPAの準拠に最も関係するポリシー本文からの逐語引用を抽出してください。該当する引用が見つからない場合は『関連する引用が見つかりません』と述べてください。\n2. 抽出した引用を番号で参照しながら、これらの条項の準拠状況を分析してください。分析は抽出した引用のみを根拠にしてください。"
    }]
  }'

「引用を先に抜き出させる → その引用だけを根拠に分析させる」という2段構成が肝です。1段だけ(引用抽出のみ、または分析のみ)にすると、2段目でClaudeが引用から逸れた一般論に流れやすくなります。

パターン3: 主張ごとに引用検証させ、根拠がなければ角括弧で削除する

回答を書かせたあとに、回答内の主張1つずつに対して裏付けとなる引用を文書内から探させ、見つからなければその主張自体を削除させる工程です。監査可能性(auditability)を回答の生成プロセスに組み込む発想で、事後チェックというより自己検証をプロンプトの一部にする点が特徴です。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 2048,
    "messages": [{
      "role": "user",
      "content": "新製品AcmeSecurity Proのプレスリリース案を、この製品資料と市場レポートの情報のみを使って作成してください。\n<documents>{{DOCUMENTS}}</documents>\n\n作成後、プレスリリース内の主張を1つずつ見直し、各主張について文書内の直接引用で裏付けられるか確認してください。裏付けとなる引用が見つからない主張は削除し、削除した箇所には空の角括弧[]を残してください。"
    }]
  }'

角括弧[]を残すのは、削除した箇所を人間のレビュアーが後から追跡できるようにするためです。痕跡を残さず消してしまうと、どこが削られたのか検証できなくなります。角括弧が本文中に残ったまま公開・送信されないよう、後処理でのチェックを1段挟む運用と組み合わせるのが実用上は安全です。

パターン4: Best-of-N比較で回答のブレを検出する

同じプロンプトをClaudeに複数回投げ、出力同士を比較する手法です。事実に基づく回答であれば試行間でおおむね一致するはずで、逆に試行ごとに内容がぶれる箇所はハルシネーションの疑いが強いと判断できます。他の3パターンが単発のプロンプト工夫であるのに対し、Best-of-Nは複数回の呼び出しを前提にした検証フローである点が異なります。

コスト面では、同一プロンプトをN回叩く分だけトークン課金が線形に増えます。全リクエストに適用するのではなく、法務・財務など誤りの許容度が低いタスクに絞って使うのが現実的です。試行回数Nを増やすほどブレの検出精度は上がりますが、コストとレイテンシも比例して増えるため、実運用ではN=3〜5程度から始めて、検出できたブレの量と追加コストを見比べながら調整するのが妥当な進め方です。

4つを組み合わせるとどう効くか

公式ガイドはこの4パターンに加えて、より発展的な手法も挙げています。

• Chain-of-thought検証: 最終回答をいきなり出させるのではなく、そこに至る推論過程を段階的に説明させます。回答自体は正しく見えても、途中の推論に飛躍や前提の取り違えがあれば、この過程を読むことで発見できます。
• 反復的な精緻化: Claudeが出した回答を次のプロンプトの入力として渡し、「先ほどの回答の各主張を再検証し、根拠が薄い箇所があれば修正してください」のように再検証・拡張を依頼します。1回の生成では拾いきれない矛盾を、2周目の生成で洗い出す発想です。
• 外部知識の制限: 「提供された文書に書かれている情報のみを使い、一般知識で補完しないでください」と明示的に指示します。学習データ由来の知識と、渡した文書の情報が混ざるのを防ぎます。

この3つは単体のプロンプトテクニックというより、パターン1〜4を実装した上でさらに一段厳しくしたいときの追加レイヤーという位置づけです。

実装コストと効果のバランスで言えば、パターン1(わからないと言ってよい)はコストがほぼゼロで効果が大きく、あらゆるプロンプトに常時入れて構いません。パターン2・3(引用によるグラウンディングと検証)は長文タスク・監査が必要なタスクに絞って追加し、パターン4とBest-of-N系は誤りの代償が特に大きいタスクの最終防衛線として使う、という優先順位が実装コストに見合います。

4パターンの使い分け早見表

表からも分かるとおり、コストと適用範囲はほぼ比例します。まずコストゼロのパターン1を全リクエストに入れ、リスクの高いタスクだけパターン2〜4を段階的に足していくのが、実装の手間に対して効果が見合う順番です。

この対策が効かないケースと限界

公式ガイドは、これらの技術が「ハルシネーションを大幅に減らすが、完全にはなくならない」と明記しています。プロンプト工夫は入力文脈に基づく事実誤認を減らす効果が中心で、Claudeの学習データ由来の誤った一般知識(例: 古い統計を最新の事実として語る)までは防ぎきれません。

したがって、意思決定に直結する重要な情報は、これらのパターンを実装した上でも人間による最終確認を外さないことが前提になります。特に医療・法務・財務など、誤りの代償が大きい領域では、Claudeの回答を「検証済みの一次情報」ではなく「検証を要する下書き」として扱う運用が現実的です。

運用に落とし込むなら、パターン3(主張ごとの引用検証)で角括弧[]が多く出るタスクほど、そもそも与えている文書の情報量が不足しているサインでもあります。角括弧の出現頻度をログとして蓄積しておけば、「どのタスク・どの文書種別でハルシネーションが起きやすいか」を後から棚卸しでき、プロンプト自体の改善にもつながります。

Agent SDKでツール呼び出しと組み合わせる場合の注意

Claude APIをAgent SDK経由でツール呼び出しと組み合わせて使う場合、ツールの実行結果自体が不正確であれば、いくらプロンプト側でハルシネーション対策をしてもClaudeは誤った前提で回答を組み立てます。パターン2・3の「文書からの逐語引用」は、ツールが返したJSONやログのような構造化データにも応用できます。ツール結果をそのままプロンプトに埋め込み、「ツール結果に含まれる値のみを使い、含まれない値は生成しないでください」と明示すれば、ツール呼び出しを挟む構成でも同じグラウンディングの発想を保てます。

まとめ

Claude APIのハルシネーション対策は、①「わからない」と言ってよい許可 ②20000トークン超の文書での逐語引用抽出 ③主張ごとの引用検証と角括弧削除 ④Best-of-N比較、の4パターンが基本形です。コストがかからないパターン1は常時適用し、残りはタスクのリスクに応じて追加する組み合わせ方が実装として無理がありません。プロンプト内で完結する対策である以上、system prompt の設計や応答言語の固定など他の運用設定と合わせて調整すると効果が安定します。

Claudeを検索エンジンの代わりに使う場面でも同様の注意が必要です。出典の確認方法はClaudeを検索エンジン代わりに使う方法で扱っています。ツール呼び出しを伴う実装では、ツール定義のバージョン管理も事実性の担保に関わるため、Claude APIツールのバージョン管理ガイドもあわせて確認すると設計の抜けを防げます。