生成AIの正確性を99%まで上げられる秘密：AWSの自動推論を実際に触ってみた

参照：「AWS Introduces Automated Reasoning Checks」[1]

この記事は KINTOテクノロジーズ Advent Calendar 2025 の3日目の記事です🎅🎄
 0. はじめにKINTOテクノロジーズのCloud Infrastructure G(CIG)でInfrastructure Architectを担当している劉(YOU)です。
2024年12月、AWSは生成AIの数学的証明と論理的推論を実現することができる自動推論をre:inventで発表しました。当時はAWS Bedrock Guardrailsの機能として自動推論チェックという名称で紹介されており、今年の8月にUS・EUの一部地域で一般公開されています。
このアプローチは、結果に確率を割り当てることで不確実性に対処する確率的推論方法とは根本的に異なります。実際、自動推論チェック[2]は最大99%の検証精度を提供し、AIのハルシネーションを検出する上で証明可能な保証を提供すると同時に、モデルの出力が複数の解釈に開放されているときに曖昧さの検出を支援します。
AWSが提供している自動推論を簡単にお伝えしますと、
自動推論チェックは、基礎モデル（FM）によって生成されたコンテンツのドメイン知識に対する正確性を検証するのに役立ちます。これは、AIのハルシネーションによる事実の誤りを防ぐのに役立ちます。このポリシーは、数学的論理と正式な検証技術を使用して精度を検証し、AI応答が正確性をチェックするための決定的なルールとパラメータを提供します。
上記の通り生成AIのハルシネーションの定量的な判断・持続的な追跡・応答の向上・更なる改善を果たすために

構成されています。このようなアプローチによって、不確実性に頼る確率的推論方法とは根本的に異なり、結果に確率を割り当てします。それがタイトルにも記載した通り最大99%の検証精度を提供し、AIのハルシネーションを検出する上で証明可能な保証を提供すると同時に、モデルの出力が複数の解釈に開放されている時に曖昧さの検出を支援します。
自動推論自体はAWSが起案したことではなく、数理論理学を起源とする一分野です。それを利用し、ソフトウェア開発の検証技術を使い始めたことが元々の自動推論であって、その方法論を生成AI向けのサービスとして提供しています。
自動推論という概念についてもっと知りたい方はこちらの文書を参考にして下さい。
自動推論
What is Automated Reasoning?
自動推論はBedrock Guardrailsと連携しているサービスなので、Bedrock Guardrailsを理解していると分かりやすい部分があります。本記事では自動推論の機能の全体像について解説するため、Bedrock Guardrailsについての説明は省略しますのでご了承ください。

Bedrock Guardrailsにご興味のある方やもっと詳細を知りたい方は別記事を作成しているのでぜひご覧下さい。
AWS Bedrock Guardrailsの導入取り組み:前編-生成AIセキュリティの必要性 ：生成AIのガードレールの必要性
TECH BOOK By KINTO Technologies Vol.01：KINTOテクノロジーズ 執筆部 ：AWSでBedrock Guardrailsの実装方法
 1. 本記事の対象読者・注意点・目的筆者は当初、自動推論は名前だけ見て生成AIのハルシネーションを簡単に防げる自動化サービスかなと考えました。しかし、手軽に触れる自動化とは距離が遠く、かなりレベルが高く感じたので、自動推論が必要な具体的な状況や注意点を先に説明します。
 対象読者LLM レスポンスのハルシネーションを厳密に検出・追跡・応答の向上・改善したい方
高いガバナンスや誤りが許されないコンプライアンス要件がある生成AIの実装をしている方
複雑なルールや要件のある生成AIアプリケーションを開発している方
AWS中心の「責任ある生成AI」の実現を目指している方
 注意点本記事では英語環境での検証結果をもとに解説しています。今後、日本語対応が行われた際には挙動や仕様に変更が生じる可能性があります。
自動推論はユーザー側に提供されたテキスト・ドキュメントと関連する内容のみを分析し、検出する仕組みになっています。それ故、あくまでもハルシネーション・正確性を検証するサービスであって、自動的に制限・処理を行ったりしません。公式文書でも、既存のBedrock Guardrailsフィルタと一緒に使うことをお勧めしています。
Amazon Bedrock Guardrailsの自動推論チェックは、プロンプトインジェクション攻撃から保護しません。これらのチェックは、あなたが送信した内容を正確に検証します。悪意のあるコンテンツや操作されたコンテンツが入力として提供された場合、検証はそのコンテンツに対してそのまま実行されます（不適切な入力・出力）。プロンプトインジェクション攻撃を検出してブロックするには、コンテンツフィルタと自動推論チェックを組み合わせて使用します。

自動推論は、自動推論ポリシーに関連するテキストのみを分析し、検出します。残りのコンテンツは無視され、回答がトピックから外れているかどうかを開発者に伝えることはできません。トピックから外れた応答を検出する必要がある場合は、トピックポリシーなどの他のガードレールコンポーネントを使用します。
後述する内容ですが、自動推論はテキスト・ドキュメントを元に基本的なポリシーを自動生成してくれます。しかし、この自動生成されたポリシーを検討してテストする必要があります。入力したコンテキストの要件と自動推論の構造に対する理解の両方が必要ですので下記リンクの制限事項とベストプラクティスをご参照ください。
制約事項と考慮事項
ベストプラクティス
 目的前述の「注意点」で取り上げた「自動推論の構造に対する理解」をメインに話したいと思います。それで、本記事としては大きな枠を理解することから下記の三つを知って頂ければと思います。
自動推論がどんなパーツを持っていて、どうやって機能するかを知る
自動推論をどんなフローで検証するかを知る
自動推論をどういう時に活用できるかを知る（こちらはガードレールの知識が要りますので、別記事で話します）
 2. 全体像自動推論の全体像をざっくりと表しますと、下の図のようになっています。
手順としては、
自動推論でテキスト・ドキュメントを入れると、自動で「ポリシー」が作成される
ポリシーは入力した情報を基にタイプ・変数・ルールの「定義」が自動生成される

a. 追加のテキストやドキュメントを取り込み、ポリシーの定義を拡張できる

b. 生成されたタイプ・変数・ルールを要件に合わせて編集し、整合性を確保する
ポリシーを検証するために「テスト」を作成する

a. 手動で作成：QnA ペアを形式で仮定のインタラクションを入力

b. 自動で作成：既存のルールを確認できるシナリオが自動で生成される
検証結果を確認して意図している結果が出るかを確認

a. テスト実行結果で期待される結果と実際の結果が一致するかを確認

b. 一致していない場合、5に戻る
一致していない原因を把握して定義の中で間違っている場所に「注釈」を付ける

a. テスト実行結果の中で、原因を推測することができる情報が提示される

b. 注釈を付けられる場所はタイプ、変数, ルールになっていて、主に自然言語になっている説明を修正したら、そこに合わせて修正されるようになっている
注釈適用をしたらそこに合わせた内容で修正案が出て、正しければ変更を受け入れる
3から6を繰り返してテキスト・ドキュメントの内容を守るためのポリシーを完成する
完成されたポリシーをガードレールに紐付ける
既存のガードレールがあるか、新しく作成する必要がある
LLMアプリケーションの入力・応答をガードレールに渡し、自動推論チェックの結果を活用する

a. 成功した場合、ユーザー側に結果をそのまま返す

b. 失敗した場合、自動推論チェックの結果を利用してLLMアプリケーションから再作成を要求する

c. （オプション）自動推論チェックの結果をログとして保存し、ポリシーの見直しを続ける
全体をまとめると、自動推論は「ポリシー」として作成されて「定義」→「テスト」→「注釈」を重ねながら完成することになります。完成されたポリシーをAWS Bedrock Guardrailに紐付けて、LLMの応答にガードレールを適用したら自動推論チェックを遂行します。その後の処理は開発者の意思によって異なりますが、LLMが正しい応答を出しているのかを定量的に判断ができるようになります。
自動推論を導入することで、悪性のものを遮断する既存のガードレールと並行しながら、ハルシネーションを無くす戦略を立てることが可能になります。そして、外部情報を参照するRAGとMCPを付けた生成AIの正確性を検証することもできるし、間違ったLLMの応答・開発者が制御できない誤りの入力を検知して修正できるのは非常に魅力的です。
次は、AWSから提供しているサンプルを利用して上記の手順を沿い実際に「ポリシー」の作成から「定義」「テスト」「注釈」の三つを中心に解説します。
 3. ポリシー
基本的に自動推論も他のAWSリソースと同じく、コンソール・CLI・SDKで操作することができます。
CloudFormation は現在サポートされていません。CloudFormation のサポートは間もなく開始されます。
コンソール上で自動推論のポリシーの作成は簡単に実施できます。
名前
説明（オプション）
ソース（ドキュメント・テキスト）
ソースの説明
上記の内容を記入して「ポリシー作成」ボタンを押すと、自動でポリシーの中身を作成してくれます。筆者はAWSのサンプルで準備された医療に関するPDFのファイルを使いましたが、5〜10分くらいでポリシーが生成されました。入れた文書の長さによって定義が作られる時間は変わると思います。

作られたポリシーを確認すると、次のような画面が出ます
 4. 定義ここで注目する所は、下にある定義(Definitions)です。このオーバービューの画面から定義の画面に遷移しますと、ルールと変数およびタイプが定義されていることが確認できます。
 タイプ
AWS側から事前に定義されているタイプ以外にも、ユーザーから提供された文書の中にタイプとして分類する項目があれば自動生成されます。タイプを持って変数を作り、ルールを正しく定義することが自動推論の基本になっています。各項目を説明すると、
名前：タイプを定義する名称、変数で使われるキー
説明：自動推論が判断できるようにする内容を記述
値(Values)：区分される個別の値を記入
問題(Issues)：タイプで起こっている問題を表す
注釈：適用前の修正内容を表示する
アクション：更新、削除、リバート、三つの動作ができる
タイプは変数で使われていない場合、画像のように使用されてないタイプ(Unused type)として警告が出ます。この時にはこのタイプを利用して変数を定義するか、削除するかをユーザー側で判断して扱うことができます。タイプは使われていなくても動作することに影響はないのですぐに解決しなくても大丈夫です。
ここでは、どこかで使用されているRiskCategoryを基準にこの後の説明を続けます。
名前：RiskCategory（リスクカテゴリ）
説明：30日間の再入院の推定リスクを示す、総リスクスコアに基づいて患者に割り当てられたリスクカテゴリ
値：LOW_RISK, INTERMEDIATE_RISK, HIGH_RISK (低リスク、中リスク、高リスク)
 変数変数は、自然言語を正式なロジックに変換するときに値を割り当てることができる自動推論ポリシーの概念を表します。ポリシールールは、これらの変数の有効または無効な値に対する制約を定義します。
変数は60個が定義されてますが、RiskCategoryを検索したらこのタイプが使われていた変数が確認できます。
名前：riskCategory
カスタム変数タイプ：RiskCategory
説明：総リスクスコアに基づいて患者に割り当てられたリスクカテゴリ
自動推論は自然言語から形式ロジックへ翻訳するので、その精度は変数の記述品質に大きく依存します。そのため、ベストプラクティスにも「包括的な変数の説明を記述する」が記載されています。包括的な変数の説明がなければ、自動推論は、入力された自然言語を正式な論理表現に変換できないため、NO_DATAを返す可能性がありますのでご注意ください。
 ルールルールは、Automated Reasoning がソースドキュメントから抽出するロジックです。
自動推論のロジックはSMT-LIBで作成されました。充足可能性モジュロ理論（SMT）は一次式の充足可能性をチェックする方法を研究する領域で、その一環としてSMT-LIBというSMT利用者の共通入力言語と出力言語が開発されています。自動推論ではルールの説明を変えるだけで式を修正してくれますが、SMT-LIB様式で修正することもできるので参考にしてください。
riskCategoryが使われているルールは21個で、主にriskCategory＋他の変数条件でシナリオが作られています。
一番上にあるルールを解説しますと、examplePatientという変数が下記の定義を持っているので
名前：examplePatient
カスタム変数タイプ：Boolean
説明：これが特定の特徴を持つガイダンスからの患者の例であるかどうか
if examplePatient is true, then riskCategory is equal to HIGH_RISK

→ 特定の特徴を持つガイダンスがある患者の例で当てはまったらリスクカテゴリが高リスクである
というシナリオを表現しているルールになります。では、このルールをテストしてみましょう。
 5. テストテストを実施する方法は2つあります。
question-and-answer (QnA) ペアを手動で定義
テストシナリオを自動的に生成
本記事では直観的に確認できるようにするため、コンソール操作で手動定義を例に挙げますが、多数のテストを機械的に実行するにはCLIやSDKで自動生成を活用した方が楽です。手動定義でルールを検証する前に自動生成を利用してテストしてみます。
 自動生成テスト
コンソールでは生成のボタンを押すと、こういう形でテストシナリオを作成してくれます。

riskCategoryとmaxPostDischargeTelephoneContactHoursが条件にありましたので、定義の画面からLOW_RISKで検索してみます。
しかし、maxPostDischargeTelephoneContactHoursの変数があるルールがないです。この変数の説明は「退院後、退院後の電話連絡が発生する最大時間」ですので、このシナリオの要件を知っているユーザーが妥当性を判断することができます。シナリオが違っていたと判断したら、説明を書くことでテストシナリオを修正してもらえることもできますが、一旦、提案してくれたままテストシナリオを作ってみます。
そうしたら、作成されたテストケースに入ったらこのような画面が出て、テストを実行することができます。実行しますと、
条件と合っているルールがないのに成功しました。その理由はなんでしょうか？
自動で生成されたテストシナリオで想定した期待される結果（Expected result）が実際結果（Actual result）と一致していたからです。自動推論でテストの結果を判断する基準は7つあります。
VALID：クレーム(Claim)がルールと論理的に一致
INVALID：クレームがルールと論理的に矛盾・違反
SATISFIABLE：クレームがルールの条件と少なくとも 1 つ一貫していますが、関連するすべてのルールに一致していない
IMPOSSIBLE：自動推論ポリシー内に競合がある可能性
TRANSLATION_AMBIGUOUS：自然言語からロジックへの翻訳で曖昧さが検出
TOO_COMPLEX：入力に含まれる情報が多すぎる
NO_TRANSLATIONS：入力プロンプトの一部またはすべてがロジックに変換されなかった
riskCategory is equal to LOW_RISK
maxPostDischargeTelephoneContactHours is equal to 72
それぞれのクレームがどこかのルールの条件の一つとして存在していたのでSATISFIABLEの実際結果を出していて、テストシナリオではそれを踏まえて期待される結果にしたことになります。
 注釈ここで、要件が「退院後、退院後の電話連絡が発生する最大時間が120時間だったら、リスクカテゴリが低リスクである」だと仮定してみましょう。その場合、新しいルールを追加する必要があります。
この時に、追加・修正するために注釈を付けることができて、注釈を適用することが可能になります。
ここで進めると、
変更事項を確認して廃棄したり、承認したり、それともポリシーに戻って見直しすることができます。想定通りにルールが生成されましたので承認します。
ルールが反映されたら、実際結果がINVALIDになって失敗に変わりました。ルールが新しく適用されたので明確にINVALIDだと判断するように変わったので、テストシナリオの想定を変更する必要があります。
期待される結果をINVALIDに変更したら、成功するように変わります。
 手動定義テスト結果をみて注釈を付けながら修正する流れは、手動で行うことも大きく変わることはないです。下記のような内容でテストを追加してみます。手動で入れる内容は実際のLLMアプリケーションの応答を真似して入れます。
インプット：ホゲホゲさんは医薬品の使用に注意が必要な患者です。この人のリスクカテゴリは？
アウトプット：特定の特徴を持つガイダンスがある患者なので、リスクカテゴリは高リスクである
期待される結果：VALID
結果は当然ですが、成功になっています。
ここで追加されたタイプが見えますが、質疑応答のテストで登場する前提（Premise）になります。今回は質問に特徴がある患者であることを前提としたように、クレームの評価方法に影響するコンテキスト、前提条件、または条件を提供するタイプです。
それ以外に、自動推論が自然言語から形式ロジックへの翻訳で持つ信頼スコア(Confidence threshold)を想定して、正確に翻訳しているのかを確認することもできて、
調査結果が有効かどうかを証明する変数の割り当て(Assignments)を見て、正しいシナリオや正しくないシナリオの例をすぐに確認できます。
テストは今までの過程を重ねて、LLMアプリケーションに正しいポリシーを提供するようにします。このポリシーをLLMアプリケーションに適用するためにはAWS Bedrock Guardrailsに紐付けて、ガードレールを使用しなければなりません。
 6. まとめこの後は、作成したポリシーをガードレールに紐付けて、自動推論をどのように行うかの実運用の話になりますが、実際にアプリケーションに適用する自動推論チェックはBedrock Guardrailsの機能の一つとしてあるため、ガードレールの説明と一緒にした方がいいと思います。今後、Bedrock Guardrailsの新機能と一緒に紹介させてください。
本記事では自動推論の全体像の中で、AWSが提供する概念と仕組み、そしてポリシーを設計・完成させるフローについて説明しました。
自動推論チェックは、AWSが提供する生成AIの機能であり、AIが生成したコンテンツの正確性を検証するためのツールです。これにより、AIのハルシネーションによる事実の誤りを防ぎ、数学的論理と形式的検証技術を使用して精度を確認します。具体的には、ポリシーの作成、定義、テスト、注釈のプロセスを経て、生成AIの出力を評価し、ハルシネーションを抑止することができます。言い換えますと、ユーザーが提供する文書を基にポリシーが自動生成され、テストを通じてその正確性を確認する仕組みです。これにより作り上げたポリシーはAWSのBedrock Guardrailsとの連携により、生成AIの実装において高い正確性を実現できます。
本記事を通じて、自動推論の理解が少しでも深めていただけたら嬉しいです。

脚注
https://www.linkedin.com/pulse/aws-introduces-automated-reasoning-checks-mathematical-certainty-lqvmc ↩︎
2024年に公開された時には、ガードレールと連携されることが基本でしたので、自動推論チェックという名前で紹介されました。しかし、今年8月のGAではBedrockの独立された機能として自動推論が出ました。それ故、本記事ではガードレールから機能している時には自動推論チェック、単独で機能している時には自動推論と記述します。 ↩︎