自動推論チェックで回答を書き換えてハルシネーションを抑えるチャットボットのリファレンス実装

本ブログは 2026 年 2 月 9 日に公開された AWS Blog “Automated Reasoning checks rewriting chatbot reference implementation” を翻訳したものです。

本日 (2026 年 2 月 9 日)、新しいオープンソースのサンプルチャットボットを公開します。このサンプルでは、自動推論チェック (Automated Reasoning checks) のフィードバックを使って、生成されたコンテンツを反復的に改善し、確認のための質問を行い、回答の正しさを証明する方法を紹介します。

このチャットボットは、回答の妥当性について数学的に検証可能な説明を含む監査ログを生成します。さらに、裏側で動く反復的な書き換えプロセスを開発者が確認できるユーザーインターフェイスも備えています。Amazon Bedrock Guardrails の自動推論チェックは、論理的な演繹によってある記述が正しいことを自動的に示す仕組みです。大規模言語モデル (LLM) のように正確性を推測したり予測したりするのではなく、数学的な証明によってポリシーへの準拠を検証します。このブログ記事では、自動推論チェックを使った書き換えチャットボットの実装アーキテクチャを詳しく解説します。

自動推論チェックで高める正確性と透明性

LLM は、説得力があるように見えて事実に反する内容を含む応答を生成することがあります。これはハルシネーションと呼ばれる現象です。自動推論チェックは、ユーザーの質問と LLM が生成した回答を検証し、書き換えフィードバックを返します。このフィードバックは、自動推論ポリシー (Automated Reasoning policy) にエンコードされたグラウンドトゥルースの知識に基づいて、あいまいな記述、範囲が広すぎる断定、事実に反する主張を指摘します。

回答をユーザーに提示する前に、自動推論チェックで反復的に改善するチャットボットは、正確性の向上に役立ちます。あいまいさの余地を残さず、「はい/いいえ」形式の質問に明確に答える正確な記述ができるようになるからです。また、透明性の向上にも役立ちます。記述が正しい理由を数学的に検証可能な証明として示せるため、規制のある環境でも生成 AI アプリケーションを監査可能かつ説明可能にできます。

メリットを確認したところで、これをご自身のアプリケーションでどのように実装するかを見ていきましょう。

チャットボットのリファレンス実装

このチャットボットは Flask アプリケーションで、質問の送信と回答のステータス確認を行う API を公開しています。システムの内部動作がわかるように、これらの API では各イテレーションのステータス、自動推論チェックからのフィードバック、LLM に送信した書き換えプロンプトも取得できます。

フロントエンドの NodeJS アプリケーションでは、回答生成に使う Amazon Bedrock の LLM を設定し、検証に使う自動推論ポリシーを選択し、回答を修正するイテレーションの最大回数を指定できます。ユーザーインターフェイスでチャットスレッドを選択すると右側にデバッグパネルが開き、コンテンツに対する各イテレーションと検証出力が表示されます。

図 1 – デバッグパネル付きのチャットインターフェイス

自動推論チェックが応答を妥当と判定すると、その妥当性についての検証可能な説明が表示されます。

図 2 – 自動推論チェックによる妥当性の証明

反復的な書き換えループの仕組み

このオープンソースのリファレンス実装は、自動推論チェックからのフィードバックを反復的に処理して応答を書き換えることで、チャットボットの回答を自動的に改善するのに役立ちます。チャットボットの質問と回答 (Q&A) の検証を要求すると、自動推論チェックは検出結果 (finding) のリストを返します。各検出結果は、入力された Q&A の中で特定された、独立した論理的な記述を表します。例えば「S3 ストレージの料金はいくらですか? 米国東部 (バージニア北部) では、S3 の料金は最初の 50 TB について 0.023 USD/GB です。アジアパシフィック (シドニー) では、S3 の料金は最初の 50 TB について 0.025 USD/GB です」という Q&A の場合、自動推論チェックは 2 つの検出結果を生成します。1 つは us-east-1 における S3 の料金が 0.023 USD であることを検証するもの、もう 1 つは ap-southeast-2 に関するものです。

Q&A の検出結果を解析するとき、自動推論チェックは入力を、事実に関する前提 (premise) のリストと、それらの前提に基づく主張 (claim) に分けます。前提には、「私はバージニアの S3 ユーザーです」のようにユーザーの質問に含まれる事実の記述や、「us-east-1 に送信されるリクエストについては…」のように回答内で示された仮定が該当します。主張は、検証対象となる記述です。前の段落の S3 料金の例では、リージョンが前提、価格が主張になります。

各検出結果には、検証結果 (VALID、INVALID、SATISFIABLE、TRANSLATION_AMBIGUOUS、IMPOSSIBLE) と、回答を VALID にするために必要なフィードバックが含まれます。フィードバックの内容は検証結果によって変わります。例えば、あいまいな検出結果には入力テキストの 2 つの解釈が含まれ、充足可能な検出結果には、主張が真になる場合と偽になる場合をそれぞれ示す 2 つのシナリオが含まれます。想定される検出結果の種類は API ドキュメントでご確認いただけます。

訳注: 2026 年 9 月現在、検証結果には、本文で挙げられている 5 種類に加えて NO_TRANSLATIONS と TOO_COMPLEX があり、全 7 種類が定義されています。最新の一覧は、Amazon Bedrock ユーザーガイドの「自動推論チェックの概念」を参照してください。

ここまでの背景を踏まえて、リファレンス実装の仕組みを詳しく見ていきましょう。

初回の応答と検証

ユーザーが UI から質問を送信すると、アプリケーションはまず設定された Amazon Bedrock の LLM を呼び出して回答を生成し、次に ApplyGuardrail API を呼び出して Q&A を検証します。

アプリケーションは ApplyGuardrail 応答に含まれる自動推論チェックの出力を使ってループに入ります。各イテレーションでは、自動推論チェックのフィードバックを確認し、そのフィードバックに基づいて LLM に回答の書き換えを依頼するといったアクションを実行し、その後 ApplyGuardrail を呼び出して更新後のコンテンツを再検証します。

書き換えループ (システムの中核)

初回の検証が終わると、システムは自動推論チェックの出力から次のステップを決定します。まず検出結果を、最も重要なものが先頭になるように優先度順に並べ替えます。優先度は TRANSLATION_AMBIGUOUS、IMPOSSIBLE、INVALID、SATISFIABLE、VALID の順です。次に、最も優先度の高い検出結果を選び、以下のロジックで対処します。VALID はこの並びの最後にあるため、システムは他の検出結果に対処した後にのみ、内容を VALID として受け入れます。

• TRANSLATION_AMBIGUOUS の検出結果では、自動推論チェックが入力テキストの 2 つの解釈を返します。SATISFIABLE の検出結果では、主張を証明するシナリオと反証するシナリオの 2 つを返します。アプリケーションはこのフィードバックを使い、あいまいさを解消するために回答の書き換えを試みるか、不足している情報を集めるためにユーザーへ追加の質問を行うかの判断を LLM に依頼します。例えば SATISFIABLE のフィードバックでは、0.023 USD という料金はリージョンが米国東部 (バージニア北部) の場合にのみ妥当だと示されることがあります。LLM はこの情報を使って、アプリケーションのリージョンをたずねることができます。LLM が追加の質問を行うと判断した場合、ループは一時停止してユーザーの回答を待ちます。その後、LLM は明確になった情報に基づいて回答を再生成し、ループが再開されます。
• IMPOSSIBLE の検出結果では、自動推論チェックが前提 (入力コンテンツ内で受け入れられた事実) と矛盾するルールのリストを返します。アプリケーションはこのフィードバックを使い、論理的な矛盾を避けるように回答を書き換えることを LLM に依頼します。
• INVALID の検出結果では、自動推論チェックが該当するルールを返します。これらは、前提とポリシールールに基づいて主張を無効と判断する根拠になった、自動推論ポリシー内のルールです。アプリケーションはこのフィードバックを使い、ルールと整合するように回答を書き換えることを LLM に依頼します。
• VALID の検出結果では、アプリケーションはループを終了し、回答をユーザーに返します。

回答を書き換えるたびに、システムは Q&A を検証のために ApplyGuardrail API へ送信します。ループの次のイテレーションは、この呼び出しのフィードバックから始まります。各イテレーションは検出結果とプロンプトを完全なコンテキストとともにスレッドのデータ構造に保存し、システムが最終的な回答に至った過程の監査証跡を作成します。

自動推論チェックによる書き換えチャットボットの始め方

このリファレンス実装を試すには、最初のステップとして自動推論ポリシーを作成します。

1. AWS マネジメントコンソールで Amazon Bedrock に移動します。このとき、米国または欧州のサポートされているリージョンのいずれかを選択します。
2. 左側のナビゲーションから、Automated Reasoning ページを開きます。このページは Build カテゴリにあります。
3. [ポリシーを作成] ボタンのドロップダウンメニューから、[サンプルポリシーを作成] を選択します。
4. ポリシーの名前を入力し、ページ下部の [ポリシーを作成] を選択します。

ポリシーを作成したら、リファレンス実装をダウンロードして実行できます。

5. Amazon Bedrock のサンプルリポジトリをクローンします。
6. README ファイルの手順に従って、依存関係をインストールし、フロントエンドをビルドして、アプリケーションを起動します。
7. お好みのブラウザで http://localhost:8080 にアクセスし、テストを開始します。
   訳注: 2026 年 9 月現在、自動推論チェックがサポートする言語は英語のため、テストでは英語で質問を入力してください。最新の対応状況は、Amazon Bedrock ユーザーガイドの「Amazon Bedrock ガードレールの自動推論チェックとは」を参照してください。

バックエンド実装の詳細

この実装を本番環境向けに応用する予定の方に向けて、以下ではバックエンドアーキテクチャの主要コンポーネントを説明します。これらのコンポーネントは、リポジトリの backend ディレクトリにあります。

• ThreadManager: 会話のライフサイクル管理をオーケストレーションします。会話スレッドの作成、取得、ステータス追跡を担い、書き換えプロセス全体で適切な状態を維持します。ThreadManager はロックを使ってスレッドセーフな操作を実装しており、複数の操作が同じ会話を同時に変更しようとしたときの競合状態を防ぐのに役立ちます。また、ユーザー入力を待っているスレッドを追跡し、設定可能なタイムアウトを超えた古いスレッドを特定できます。
• ThreadProcessor: ステートマシンパターンで書き換えループを処理し、明確で保守しやすい制御フローを実現します。プロセッサは GENERATE_INITIAL、VALIDATE、CHECK_QUESTIONS、HANDLE_RESULT、REWRITING_LOOP といったフェーズ間の状態遷移を管理し、各段階を通じて会話を正しく進行させます。
• ValidationService: Amazon Bedrock Guardrails と統合します。LLM が生成した各応答を受け取り、ApplyGuardrail API を使って検証のために送信します。AWS との通信を担い、一時的な障害に対してエクスポネンシャルバックオフによる再試行ロジックを管理し、検証結果を解析して、構造化された検出結果に変換します。
• LLMResponseParser: 書き換えループ中の LLM の意図を解釈します。システムが無効な応答の修正を LLM に依頼すると、モデルは書き換えを試みる (REWRITE)、確認のための質問を行う (ASK_QUESTIONS)、前提の矛盾によりタスクが実行不可能だと宣言する (IMPOSSIBLE) のいずれかを判断する必要があります。パーサーは LLM の応答から DECISION:、ANSWER:、QUESTION: といった特定のマーカーを探し、自然言語の出力から構造化された情報を抽出します。Markdown 形式も適切に処理し、質問数の上限 (最大 5 件) を適用します。
• AuditLogger: 構造化された JSON ログを専用の監査ログファイルに書き込み、2 種類の主要なイベントを記録します。1 つは応答が検証に合格したときの VALID_RESPONSE、もう 1 つはシステムが設定された再試行回数を使い切ったときの MAX_ITERATIONS_REACHED です。各監査エントリには、タイムスタンプ、スレッド ID、プロンプト、応答、モデル ID、検証の検出結果が記録されます。さらに、確認のためのイテレーションから Q&A のやり取りを抽出して記録します。その際、ユーザーが質問に回答したかスキップしたかも含めます。

これらのコンポーネントを組み合わせることで、LLM の柔軟性と数学的検証の厳密さを兼ね備えた、信頼できる AI アプリケーションの堅牢な基盤を構築しやすくなります。

自動推論チェックを本番環境で実装する際の詳しいガイダンスは次のとおりです。

• ワークショップ: Generative AI Reliability with Automated Reasoning checks
• 技術ブログ: Minimize generative AI hallucinations with Amazon Bedrock Automated Reasoning checks
  訳注: 上記の記事はプレビュー期間中 (2025 年 4 月) に公開されたものです。一般提供開始後の機能に基づいた手順は、日本語版ブログの「Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1」を参照してください。
• ユースケースブログ: Build verifiable explainability into financial services workflows with Automated Reasoning checks for Amazon Bedrock Guardrails
• ドキュメント: Amazon Bedrock Guardrails ユーザーガイド

著者について

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。