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

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

Claude APIの出力に事実と違う内容が混ざる現象(ハルシネーション)は、プロンプトの書き方である程度まで抑えられます。公式ガイドの基本策は3つです。①「わからない」と答えてよいと明示する。②長文では逐語引用を先に抜き出させる。③主張ごとに引用で裏取りする。

応用編には、思考過程の確認・Best-of-N・反復的な精緻化・外部知識の制限が並びます。この記事では基本の3つに、単独で実装しやすいBest-of-Nを加えた4パターンを、そのまま使えるプロンプト例つきで扱います。

公式ガイドは、ハルシネーションを「事実として誤っている、または与えた文脈と食い違っている出力」と説明しています。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-5",
    "max_tokens": 1024,
    "messages": [{
      "role": "user",
      "content": "M&Aアドバイザーとして、AcmeCoによるExampleCorp買収案のレポートを分析してください。財務予測・統合リスク・規制上の障壁に注目してください。もし判断材料が不足している、または不確実な箇所があれば断定せず『この点を確信を持って評価するには情報が不足しています』と述べてください。\n\n<report>{{REPORT}}</report>"
    }]
  }'

要点は、許可の文言と一緒に「答えられないときに返す一文」まで指定している点です。公式の例も「情報が足りなければこの一文を返す」という形で書かれています。固定の一文なら、応答にその文字列が含まれるかを後処理で調べるだけで、情報不足の回答を機械的に拾えます。

パターン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-5",
    "max_tokens": 2048,
    "messages": [{
      "role": "user",
      "content": "データ保護責任者として、この改訂版プライバシーポリシーがGDPRとCCPAに準拠しているか確認してください。\n<policy>{{POLICY}}</policy>\n\n1. GDPRとCCPAの準拠に最も関係するポリシー本文からの逐語引用を抽出してください。該当する引用が見つからない場合は『関連する引用が見つかりません』と述べてください。\n2. 抽出した引用を番号で参照しながら、これらの条項の準拠状況を分析してください。分析は抽出した引用のみを根拠にしてください。"
    }]
  }'

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

回答を書かせたあとに、回答内の主張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-5",
    "max_tokens": 2048,
    "messages": [{
      "role": "user",
      "content": "新製品AcmeSecurity Proのプレスリリース案を、この製品資料と市場レポートの情報のみを使って作成してください。\n<documents>{{DOCUMENTS}}</documents>\n\n作成後、プレスリリース内の主張を1つずつ見直し、各主張について文書内の直接引用で裏付けられるか確認してください。裏付けとなる引用が見つからない主張は削除し、削除した箇所には空の角括弧[]を残してください。"
    }]
  }'

パターン2が回答の前に足場を作るのに対し、パターン3は回答の後に主張を絞り込みます。文書が長くないタスクでも、生成後の検証だけを足す使い方ができます。

角括弧[]を残すのは、削除した箇所を人間のレビュアーが後から追跡できるようにするためです。痕跡なしに消すと、どこが削られたのか検証できません。角括弧が残ったまま公開や送信に回らないよう、後処理で検出する工程を挟んでおくと安全です。

引用の検証をAPI側に任せるCitations機能

パターン2・3は、引用をモデルの出力として書かせる方式です。同じ目的には、Messages APIのCitations機能という別の選択肢があります。文書にcitationsを有効にして渡すと、回答の主張ごとに引用箇所への参照が構造化データで返ります。

リクエストは、documentブロックにcitationsの有効化を書くだけです。

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-5",
    "max_tokens": 1024,
    "messages": [{
      "role": "user",
      "content": [
        {
          "type": "document",
          "source": {
            "type": "text",
            "media_type": "text/plain",
            "data": "草は緑色です。空は青色です。"
          },
          "title": "サンプル文書",
          "citations": {"enabled": true}
        },
        {"type": "text", "text": "草と空は何色ですか。"}
      ]
    }]
  }'

Anthropicの評価では、プロンプトだけで引用させる方式より、文書内で最も関連する引用を選ぶ確率が有意に高いとされています。入力トークンは、システムプロンプトの追加と文書の分割ぶん、わずかに増えます。プロンプトキャッシュ・トークンカウント・バッチ処理とは併用できます。

導入前に押さえておく制約が4つあります。

• 有効化は、1リクエスト内のすべての文書で揃える必要があります。一部だけ有効にはできません。
• 平文とPDFは文単位に分割され、引用できるのは文単位が最小です。細かさを変えたいときはカスタムコンテンツ形式の文書を使います。
• 引用できるのはテキストだけで、画像は対象外です。
• 構造化出力(output_config.format)と併用すると400エラーになります。

文書形式ごとの違いはCitationsの文書タイプ別ガイド、構造化出力との衝突はCitationsと構造化出力の関係で扱っています。

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

同じプロンプトをClaudeに複数回投げ、出力同士を比較する手法です。公式ガイドは、出力の間に食い違いがあれば、それがハルシネーションの兆候になりうると説明しています。他の3パターンが単発のプロンプト工夫であるのに対し、Best-of-Nは複数回の呼び出しを前提にした検証フローです。

コスト面では、同一プロンプトをN回呼ぶ分だけ、トークン課金がN倍になります。全リクエストに適用すると割に合わないため、法務・財務など誤りの許容度が低いタスクに絞るのが現実的です。N回の呼び出しは互いに独立しているので、並列に投げればレイテンシは1回分に近づくと考えられます。

比較の仕方にはいくつかあります。数値や固有名詞のような抽出項目なら、項目ごとに一致を機械的に見られます。要約のような自由文は、別の呼び出しで「これらの回答の食い違いを列挙してください」と頼む方法もあります。

応用編: 思考過程の確認と2つの追加策

公式ガイドの応用編には、Best-of-Nのほかに3つの手法が載っています。

• 思考過程の確認(Chain-of-thought verification): 回答が怪しいときに、思考ブロックの要約を読み、誤った論理や前提を探します。
• 反復的な精緻化: 出力を次のプロンプトの入力に渡し、「先ほどの各主張を検証し、根拠が薄ければ修正してください」と頼みます。
• 外部知識の制限: 「提供された文書の情報のみを使い、一般知識で補わないでください」と明示します。

反復的な精緻化は、パターン3の自己検証を2回の呼び出しに分けた形にも使えます。1回目の回答を2回目のプロンプトに埋め込み、各主張の根拠を検証させます。2回目の指示では、根拠の有無や数値の一致など、検証の観点を個別に指定できます。外部知識の制限は、パターン1〜3すべての前提になる一文と考えられます。文書に書かれていない内容を、学習済みの知識で補わせない指定にあたります。

思考過程の確認には、現行モデルで注意点があります。思考テキストを返すかどうかを決めるdisplayフィールドの既定値が、モデルで違うためです。

この記事の例で使っているclaude-sonnet-5-5は、omittedが既定の側です。omittedのときも思考ブロック自体は返り、thinkingフィールドが空になります。課金は変わりません。確認用に読みたいときは、displayをsummarizedにして明示的に有効化します。

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-5",
    "max_tokens": 4096,
    "thinking": {"type": "adaptive", "display": "summarized"},
    "messages": [{
      "role": "user",
      "content": "この売上データから前年比の増減要因を分析してください。\n<data>{{DATA}}</data>"
    }]
  }'

返る思考テキストは、生の思考過程そのものではなく要約です。論理の飛躍を探す手がかりとして読み、最終的な正誤判定は引用や外部データと突き合わせる、という役割分担になります。

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

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

公式ガイドは、これらの手法がハルシネーションを大幅に減らすものの、完全にはなくせないと明記しています。重要な情報は、特に重大な判断が絡む場面では必ず検証するよう求めています。

4パターンを重ねても、誤りがゼロになる保証は得られません。そのため、検証の工程を自動化しても、最後に人が目を通す出口は残しておきます。

したがって、医療・法務・財務のように誤りの代償が大きい領域では、Claudeの回答を「検証済みの一次情報」ではなく「検証を要する下書き」として扱う運用が前提になります。

パターン3で角括弧[]が多く出る場合は、与えた文書だけでは裏付けの取れない主張を、Claudeが書こうとしていたことになります。角括弧の出現数をタスクや文書種別ごとに記録しておけば、どの組み合わせで裏付け不足が起きやすいかを後から比べられます。

コードを読むエージェントやツール結果と組み合わせる場合

ツール呼び出しを挟む構成では、ツールの実行結果が不正確だと、プロンプト側の対策を入れても誤った前提で回答が組み立てられます。ツールが返したJSONやログも、パターン2・3の「文書」と同じ扱いにできます。結果をプロンプトに埋め込み、「ツール結果に含まれる値のみを使い、含まれない値は生成しないでください」と明示する書き方です。

コードを調べるエージェントでは、渡す文脈が文書ではなくコードベースになります。公式のプロンプトベストプラクティスには、この場面向けの指示例が載っています。

<investigate_before_answering>
Never speculate about code you have not opened. If the user references a specific file,
you MUST read the file before answering. Make sure to investigate and read relevant
files BEFORE answering questions about the codebase. Never make any claims about code
before investigating unless you are certain of the correct answer - give grounded and
hallucination-free answers.
</investigate_before_answering>

開いていないファイルについて推測しない、という一点に絞った指示です。パターン1の「わからないと言ってよい」を、コード調査の文脈に置き換えたものとして読めます。

まとめ

基本の3パターンは、情報不足を許す、引用で足場を作る、主張ごとに裏を取る、の順に厳しくなります。パターン1はほとんど無料なので全プロンプトに入れ、パターン2〜4はタスクの誤りの代償に応じて足す構成が組み立てやすい形です。引用を機械的に扱いたいときは、プロンプトでの引用とCitations機能のどちらが合うかを先に決めます。

Claudeを検索エンジンの代わりに使う場面でも、出典の見極めが必要になります。考え方はClaudeを検索エンジン代わりに使う方法で扱っています。ツール呼び出しを伴う実装でのツール定義の管理は、Claude APIツールのバージョン管理ガイドにまとめています。