本ブログは 2026 年 5 月 12 日に公開された AWS Blog “ Enabling AI sovereignty on AWS ” を翻訳したものです。 クラウドと AI は、研究の加速や顧客体験の向上から、ビジネスプロセスの最適化や公共サービスの充実に至るまで、かつてないスピードで産業や社会を変革しています。 Amazon Web Services (AWS) は、クラウドと AI がその可能性を最大限に発揮するには、お客様がデータをコントロールでき、ワークロードをどのように、どこで実行するかを選択できる必要があると考えています。2022 年には、 AWS Digital Sovereignty Pledge によってコントロールと選択肢へのコミットメントを正式に表明しました。これにより、クラウドで利用できる最も高度な主権コントロールと機能を、すべての AWS のお客様に提供しています。AI の導入が加速する中、AWS はお客様と協力し、 主権要件を満たしながら AI イノベーションを取り入れられるよう 支援してきました。AWS は、お客様が AWS クラウドの機能、パフォーマンス、イノベーション、セキュリティ、スケールを犠牲にすることなく、AI 主権を含む主権のニーズを満たしながら、AI の変革力を引き続き活用できるよう取り組んでいます。AI 主権に対する AWS のアプローチは、こうしたニーズと、それに伴う実際の導入上の課題に対する深い理解に基づいています。 お客様、パートナー、アナリスト、規制当局との議論を通じて、デジタル主権、そして AI 主権の意味はステークホルダーによって異なることがわかりました。国や地域ごとに独自の主権要件があり、その要件も変化し続けています。また、どのワークロードやセクターが準拠すべきかについて、統一的なガイダンスはありません。このように違いがある一方で、共通するテーマも見えてきました。それは、データ主権 (データレジデンシーとオペレーターによるアクセスの制限を含む) と運用主権 (レジリエンス、存続性、独立性を含む) です。AI 主権はこれらを基盤とし、さらに AI の出力において文化的規範、価値観、現地の言語を守るといった新たな考慮事項が加わります。つまり、デジタル主権と AI 主権の要件を満たすことは、最終的にはお客様により多くのコントロールと選択肢を提供することにほかなりません。 AI スタック全体でのお客様によるコントロールと選択肢の実現 AI 主権には、AI スタック全体にわたるコントロールと選択肢が必要です。AI スタックとは、コンピューティング、ネットワーキング、データ管理、セキュリティコントロール、専門的なアプリケーションサービス、そして人材を組み合わせた包括的なクラウドインフラストラクチャを指します。お客様独自のニーズ、規制要件、イノベーションの目標に沿って、ロケーション、依存関係、サービス、パートナーなどをスタック全体で意図的に選択できることも、これに含まれます。AWS を利用することで、お客様はデータを安全かつ自らのコントロール下に置いたまま、信頼できる基盤の上で AI を開発できます。また、 専用設計の AWS シリコン や、NVIDIA、AMD、Intel のチップなど、AI に最適化された幅広いチップから自由に選択できるため、ワークロードに最適なチップを選べます。AWS は 20 年にわたって培ってきた専門知識を包括的な AI スタックに活かしており、組織はデータと運用を完全にコントロールしながら、最先端の機能を活用して地域の課題を解決できます。 AWS は、AI を個別のユースケースにとどめず、バリューチェーン全体に組み込むためのインフラストラクチャとツールをお客様に提供しています。これにより AI は、モデルのトレーニングとデプロイ、そして卓越したパフォーマンスを備えた高度な AI アプリケーションや生成 AI アプリケーションの構築を可能にする基盤的な能力となります。その結果、お客様はインフラストラクチャではなくイノベーションに集中できます。さらに、 AWS AI Factories 、 AWS Outposts 、 AWS Local Zones 、 AWS Dedicated Local Zones 、 AWS リージョン ( AWS European Sovereign Cloud を含む) など、さまざまな選択肢の中から、最も必要とされる場所でクラウドを利用できます。例えば、ミッションクリティカルな AI ワークロードの主権要件を満たすために専用のデプロイを必要とするお客様は、AWS AI Factories を利用できます。お客様専用に構築され、物理的に分離されたこのデプロイ環境は、 AWS Trainium アクセラレーター、NVIDIA GPU、専用のネットワーキング、ストレージといった最新の AI インフラストラクチャを組み合わせています。AWS AI Factories は、トレーニング、ファインチューニング、リアルタイム推論を安全に実行できるオンプレミスの AI 機能を提供し、AI 主権のニーズに対応します。 AWS の AI ポートフォリオは、 基盤モデル (FM) を提供する Amazon Bedrock から、 Amazon SageMaker AI などの機械学習サービス、 Amazon Q などのアプリケーションサービス、 Kiro などの開発者ツールまで、幅広いサービスで構成されています。これらはいずれも、お客様がデータをコントロールし、AI のデプロイ方法を選択できるように設計されています。Amazon Bedrock では、AI21 Labs、Anthropic、Amazon、Cohere、Mistral AI、OpenAI などの主要プロバイダーが提供する数百のモデルから選択できます。お客様は、特定のニーズに最適な FM を評価して選択し、デプロイ先を決められるほか、独自のデータを使用してモデルをプライベートにファインチューニングすることもできます。データは常にお客様のコントロール下にあります。特に重要な点として、お客様の Amazon Bedrock への入力や Amazon Bedrock からの出力が、 Amazon Nova やサードパーティーのモデルのトレーニングに使用されることは一切ありません。 国家 AI 戦略の支援 AI 戦略を成功させるには、地域の人材を育成し、スタートアップを支援し、業界固有のアプリケーションを開発し、官民パートナーシップを促進する包括的な環境を構築する必要があります。クラウドによって、AI は巨額の投資を必要とする一部の組織だけの技術から、あらゆるセクターや規模の組織がイノベーションに活用できる身近なツールへと変わりました。AI 主権を考える際には技術インフラストラクチャに注目が集まりがちですが、各国の FM が持つ文化的・戦略的な側面も同様に重要です。こうした FM は単なる計算ツールではありません。文化的な知識、言語のニュアンス、社会的な文脈といった要素を取り込めるため、地域との関連性は後から付け加えるものではなく、設計段階から考慮すべき事項となります。また、こうした FM は技術的な能力にとどまらない役割を果たします。地域でトレーニングされた FM は、その地域の法制度、商慣行、規制の枠組みを理解しながら、国の教育カリキュラムや文化的価値観を反映できます。現地の言語、方言、文化的文脈でトレーニングされたモデルは、言語の多様性を支え、これまで十分に扱われてこなかった言語が AI 製品やサービスに反映されるよう後押しします。 AWS は、文化的規範、価値観、現地の言語の保護や、地域や現地の言語に対応した言語モデルの能力開発など、国家にとって重要な優先事項やお客様のミッションを支援しています。 モデルをカスタマイズする 際には、 Amazon SageMaker AI を使用して、音声への対応やドメインへの特化を行ったり、モデルの精度を評価したりできます。例えば、2024 年 3 月に初のギリシャ語の大規模言語モデル (LLM) として公開された Meltemi は、Mistral-7B をベースに構築され、AWS のインフラストラクチャ上で稼働しています。さらに、285 億のギリシャ語トークンからなるデータセットで継続的な事前トレーニングを行うことで、ギリシャ語の能力を高めています。Meltemi は HuggingFace で利用できます。 SEA-LION は東南アジア向けのオープンソースの多言語 LLM ファミリーで、マネージド GPU クラスターを使用し、すべて AWS 上でトレーニングされました。開発チームは 30 億パラメータのモデルをわずか 3 か月で完成させており、これは同等のオンプレミスプロジェクトと比べて 60% 速いペースです。 データアクセスに対する検証可能なコントロール 主権は、データがどこに保存されているかだけの問題ではありません。誰が、どのような条件でデータにアクセスできるかという問題でもあります。AI の文脈では、アクセス制限の対象はインフラストラクチャにとどまらず、モデルの入力と出力、トレーニングプロセス、さらに AI が実行される運用環境にまで及びます。従来のインフラストラクチャとは異なり、AI ワークロードには新たなアクセス対象が存在します。具体的には、モデルそのもの、モデルのトレーニングに使用されるデータ、そして機密性の高い入力が流れる推論パイプラインです。そのため、IT システムにおける検証可能なガバナンスとアイデンティティの伝播の必要性がさらに高まっています。 お客様データの機密性と完全性を確保するため、最新のすべての Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、 AWS Inferentia や AWS Trainium などの AI アクセラレーターを搭載したインスタンスも含め、 AWS Nitro System の業界をリードするセキュリティ機能によって保護されています。お客様がワークロードの実行に使用する Nitro EC2 インスタンス上のお客様データに、AWS の誰であってもアクセスできる仕組みは、設計上存在しません。Amazon EC2 上に構築された AI 機能を持つサービスを含め、AWS のサービスはこれと同じ保護を継承しています。これらの保護は AWS Nitro System 上で処理される AI データに適用されるため、モデルトレーニングから推論まで、あらゆる段階でデータが保護されます。独立したサイバーセキュリティ企業である NCC Group は、 Nitro System の設計を検証 しました。AWS は、このレベルの透明性を提供することが、信頼の構築と維持に不可欠であると考えています。 AI エージェントがユーザーに代わって複数のシステムにまたがるアクションを実行することが増える中、誰が、また何がリソースにアクセスできるかを制御し、人間による適切な監督を確保することが重要になっています。 AWS Identity and Access Management (IAM) は、きめ細かなアクセス許可と包括的な監査証跡によって、認可されたユーザーとアプリケーションだけが AI リソースにアクセスできるようにします。AI エージェントや自動化されたワークロードについては、 Amazon Bedrock AgentCore Identity がアイデンティティと認証情報の管理機能を提供するため、エージェントは必要最小限のアクセス許可だけで動作します。 透明性と保証 透明性は、AWS のデジタル主権へのコミットメントの中核です。AWS は、データをどこに保存し、誰がアクセスでき、どのように使用されるかをお客様がコントロールできるよう、業界をリードする包括的な技術的対策、運用上のコントロール、契約上の保護を提供しています。また、AWS のサービスの設計と運用についてより高い保証を提供するため、お客様のコンプライアンスニーズへの対応に役立つ第三者による証明、認定、認証の取得に引き続き取り組んでいます。 AWS は、お客様への保証と透明性を引き続き強化しています。例えば、 AWS サービス条件を更新 して技術的保護に関するコミットメント (AWS Nitro System など) を反映したほか、お客様データの開示を求める第三者からの要請の取り扱いについて、契約で詳細なコミットメントを示しています。さらに、お客様が主権に関する事項について十分な情報に基づいて判断できるよう、補足的な説明やリソース ( CLOUD Act に関するブログ など) も提供しています。こうした取り組みは 責任ある AI へのコミットメントにも及んでおり、お客様が AWS のサービスを使用して、安心して AI アプリケーションを責任ある形で構築、運用できるよう支援しています。ISO/IEC 42001 は、組織が AI システムの責任ある開発と使用を推進するための要件と管理策を定めた国際的なマネジメントシステム規格です。AWS は、 主要クラウドサービスプロバイダーとして初めて、認定を受けた認証機関から AI サービスを対象とした ISO/IEC 42001 認証を取得 しました。対象には Amazon Bedrock、 Amazon Q Business 、 Amazon Textract 、 Amazon Transcribe が含まれます。2025 年 11 月には、ISO 42001:2023 の初回サーベイランス審査を 指摘事項なし で完了し、責任ある AI の実践に対する AWS の継続的なコミットメントを改めて示しました。 革新的なテクノロジーには、安全で信頼できる基盤が欠かせません。AWS は 140 を超えるセキュリティ標準とコンプライアンス認証をサポートしており、お客様やパートナーはこれらを継承することで、各地域の法律や規制への準拠に役立てることができます。AWS は 20 年にわたり、規制当局やサイバーセキュリティ当局と緊密に連携し、提供するサービスを国家の優先事項に合わせるとともに、ソリューションがイノベーションとコントロールの両方を支えられるよう取り組んできました。また、進歩を妨げることなく新たな動向に対応できるフレームワークづくりにも積極的に貢献しています。 お客様の主権目標の達成に向けた継続的なコミットメント AWS は、お客様がデータに対して持っているのと同じコントロールと選択肢を、AI システムに対しても提供することに取り組んでいます。AWS クラウドの機能、パフォーマンス、イノベーション、セキュリティ、スケールを維持しながら、お客様が AI の変革力を活用できるよう支援します。クラウドと AI の進化に合わせて、AWS は今後も、利用可能な最も高度な主権コントロールと機能を提供し続けます。 Stéphane Israël Stéphane は、AWS European Sovereign Cloud のリーダー兼 Managing Director です。AWS European Sovereign Cloud のインフラストラクチャ、テクノロジー、サービスを含む管理と運用に加え、AWS におけるより広範なデジタル主権の取り組みを担当しています。AWS に入社する前は Arianespace の CEO を務め、ジェイムズ・ウェッブ宇宙望遠鏡の打ち上げをはじめ、成功を収めた数多くの宇宙ミッションを統括しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 4 月 16 日に公開された AWS Blog “ How Automated Reasoning checks in Amazon Bedrock transform generative AI compliance ” を翻訳したものです。 規制業界のコンプライアンスチームは、手作業のレビューに数週間を費やし、外部コンサルタントにも費用を支払っていますが、AI の出力に形式的な証明がない場合には、依然として監査上のギャップに直面します。 Amazon Bedrock Guardrails の自動推論チェック (Automated Reasoning checks) は、確率的な AI 検証を数学的な検証に置き換えることでこの課題に対処し、AI が生成した判断を、正しさを証明でき、監査も可能な結果へと変えます。 この記事では、規制業界で確率的な AI 検証が不十分となる理由と、自動推論チェックが 形式的検証 によって数学的に証明された結果を提供する仕組みを説明します。さらに、6 つの業界のお客様がこのテクノロジーを活用して形式的に検証された監査可能な AI 出力を実現している事例と、利用を開始する方法も紹介します。 コンプライアンスの課題 規制業界は、失敗の代償が大きいコンプライアンスの課題に直面しています。病院は放射線安全規制に対応しなければなりません。金融機関は EU AI 法 に基づいて AI リスクを分類します。保険会社は補償範囲に関する質問に答えていますが、回答を誤ると規制上の責任を問われかねません。手作業のレビュー、高額なコンサルタント、従来型のプロセスはスケールしません。 生成 AI やエージェンティック AI ソリューションを構築する多くのチームは、LLM-as-a-judge パターン、つまり 2 つ目の大規模言語モデル (LLM) に最初のモデルの出力を評価させる手法に頼りがちです。直感的な方法ではありますが、このアプローチには 根本的な限界 があります。確率的なシステムが別の確率的なシステムを検証しても、規制業界が求める形式的で監査可能な保証は得られないのです。 自動推論チェックが定義済みのルールと制約に対して証明可能なコンプライアンスを実現する仕組み Amazon Bedrock Guardrails の自動推論チェックは、数理論理学に基づく 形式的検証手法 を適用し、AI が生成した出力を定義済みのルールと制約に照らして検証します。これにより、すべてのリクエストに対して、正しさを証明でき、監査も可能な評価結果が得られます。 例を挙げて考えてみましょう。AI アシスタントが、顧客の保険金請求は補償対象だと回答したとします。LLM-as-a-judge のアプローチでは、2 つ目のモデルがその回答をレビューして「妥当と思われる」と判断するだけです。一方、自動推論チェックでは、その回答がポリシー内のすべてのルールと整合していることを数学的に証明します。ルール違反があれば、どのルールにどのような理由で違反しているのかを正確に特定します。 図 1: 定理証明、型システム、モデル検査、抽象解釈、シンボリック実行、SMT 問題の求解、SAT 問題の求解を含む自動推論の分類。SAT 問題と SMT 問題の求解が自動推論チェックの基盤を形成します   自動推論は、与えられた前提から論理的な結論を自動的に導き出すアルゴリズムを開発する分野です。 形式的検証 (システムが仕様を満たすことを数学的に証明する手法)、 充足可能性判定 (satisfiability solving。論理式を充足できるかどうかを判定する手法)、 数理論理学 といった分野で数十年にわたり蓄積された研究成果を基盤としています。 これと同じ基盤は、ハードウェア設計の検証、暗号プロトコルの健全性の証明、安全性に直結するソフトウェアにおける仕様違反箇所の正確な特定にも使われています。自動推論チェックは、これらの手法を生成 AI に適用したものです。 自動推論チェックは、ニューラルネットワークと論理的推論を組み合わせ、AI の出力を定義済みのルールと制約に照らして検証することで、確率的な応答を形式的に検証された監査可能なアーティファクトへと変換します。AWS は、AI アプリケーションを保護するための複数の 責任ある AI ツールの 1 つとして、自動推論チェックを提供しています。 自動推論ポリシー (Automated Reasoning policy) の設定方法と検証の実際の動作を詳しく知りたい場合は、 「Minimize generative AI hallucinations with Amazon Bedrock Automated Reasoning checks」 を参照してください。 訳注: 上記の記事はプレビュー期間中 (2025 年 4 月) に公開されたものです。一般提供開始後の機能に基づいた手順は、日本語版ブログの「 Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1 」で確認できます。 図 2: Amazon Bedrock の自動推論チェック。ポリシーのエンコード、出力の変換、形式的検証エンジン、結果の生成という 4 段階のプロセスを示しています。 業界での活用例 ヘルスケア、金融、エネルギー、保険、教育といった分野の組織が、自動推論チェックを使って AI の出力を検証し、監査にそのまま使えるエビデンスとともにコンプライアンス上の判断を説明しています。 オペレーションエンジニアリング: Amazon Logistics Amazon Logistics では、エンジニアリングレビューの所要時間を約 8 時間から数分へ短縮しながら、すべての判定について形式的なコンプライアンス検証を得られるようになりました。Amazon Logistics の Sustainability Engineering チームは、Amazon のデリバリーステーションネットワーク全体への電気自動車充電ポイント (EVCP) の展開を主導しています。設置提案は、それぞれ地域固有の規制と社内技術仕様を満たす必要があります。以前は、レビュー 1 件ごとに対象分野の専門家がエンジニアリングパラメータを手作業で照合し、約 8 時間を費やしていました。 チームは AWS と協力し、自動推論チェックを活用した生成 AI 支援の設計レビューポータルを構築しました。このポータルは技術仕様を自動推論ポリシーへ変換し、変数、型、条件を明示的に定義した厳密な論理ルールを作成します。そして、提案書から抽出したエンジニアリングパラメータを形式的な数学的推論によって検証します。ドキュメントインテリジェンスレイヤーは Amazon Bedrock の Claude が担い、構造化されていない提案書からデータを抽出して構造化します。 「意思決定を行うのは引き続き当社の専門家です。ツールの動作は完全に可視化されており、あらゆる推奨事項をトレース、検証、妥当性確認できるという確信を持てます」 – AMZL、Sr. Sustainability Engineer、Paula Garcia Carrasco 対象分野の専門家は、煩雑なパラメータの照合ではなく、エンジニアリング上の判断に集中できるようになりました。 詳細は Amazon Logistics の導入事例をご覧ください 。 金融サービス: Lucid Motors と PwC Lucid Motors は、予測の生成にかかる時間を数週間から 1 分未満へ短縮し、わずか 10 週間で 14 の AI ユースケースを全社規模にスケールしました。電気自動車メーカーである同社は、PwC および AWS と協力して、AI ネイティブな財務予測・分析ソリューションを構築しました。財務チームが抱えていたのは、予測サイクルに数週間の手作業を要し、急速に変化する市場環境へ迅速に対応できないという、多くの企業に共通する課題でした。 PwC と AWS は共同で、Amazon Bedrock 上に機械学習 (ML) ベースの予測エージェントを構築しました。さらに自動推論チェックを形式的検証レイヤーとして適用し、モデルの出力があらかじめ定義された財務上のルールと制約に従っていることを数学的に検証しました。このアプローチにより、確率的な AI だけでは見逃しかねない論理的な不整合を検出できます。 財務チームは、レポートを数週間待つのではなく、リアルタイムでビジネス上の意思決定に積極的に関与できるようになりました。 「PwC と AWS とともに、Lucid はクラウド環境をイノベーションのためのプラットフォームへと変えています……PwC のチームは予測ツールを迅速に構築し、数週間かかっていた手作業を 1 分未満に短縮しました」 – Lucid、Head of Business Finance、Aditya Baheti 氏 Lucid Motors の導入事例をご覧ください。 ヘルスケア: 規制の複雑さへの対応 ヘルスケア組織は規制と安全に関する厳しい監督の下で事業を運営しており、厳格な内部統制、文書化、継続的な監査が求められます。臨床、業務、安全の各基準にわたってコンプライアンスを確保する作業はヘルスケアチームに大きな負担となり、本来の患者ケア業務から時間と労力を奪っています。 Fortive のヘルスケア事業会社は、テクノロジーを活用した安全性とコンプライアンスのソリューションを通じて、顧客がこの複雑さに対処できるよう支援することに注力しています。Fortive はイノベーション戦略の一環として、自動推論などの AI 主導のアプローチがよりプロアクティブなコンプライアンス管理をどう支援できるかを評価しています。ポリシーを要件に照らして決定論的に検証し、潜在的なギャップを早期に可視化することで、監督業務の効率化、手作業の削減、そして厳密性を損なわない意思決定の迅速化を実現できる可能性があります。 「自動推論を評価したことで、その強みと、最も価値を発揮する課題の種類の両方をより深く理解でき、確率的な AI を超えて数学的な確実性へと進むことができました」 – Fortive、Data Science & AI Leader、Gaurav Mantro 氏 教育: First Education & Technology Group (FETG) と PwC FETG は、ルール設定の作業を最大 80%、継続的なコンプライアンスの運用負荷を 50% それぞれ削減し、応答レイテンシーを 8～13 秒から 1.5 秒へ最適化しました。MarsLadder AI 学習システムを運営する First Education & Technology Group (FETG) は、PwC および AWS と協力して、生徒向け生成 AI のための責任ある AI ガバナンスレイヤーを構築しました。従来のモデレーション手法やキーワードフィルター、確率的な分類器では、文脈と意図が重要となる Safer Technologies 4 Schools (ST4S) フレームワークを確実に適用できませんでした。 PwC は自動推論チェックを決定論的な検証レイヤーとして実装し、ST4S の原則をデータ保護と生徒の安全を網羅する 10 個の形式論理ルールへ変換しました。このシステムは、AI が生成したすべての応答を学習者に届く前に検証し、確率的な判断を数学的に証明可能なコンプライアンスへ置き換えます。 このソリューションは、教育分野の規制当局が ST4S フレームワークの遵守のために求める、数学的に証明可能なコンプライアンスのエビデンスを提供します。 教育における責任ある AI に関する PwC の導入事例をご覧ください。 自動推論チェックを採用するその他の業界 他の規制業界の組織も、コンプライアンスを強化するために自動推論チェックを採用しています。 金融サービス (EU AI 法): EU AI 法に基づいて AI リスクを分類する組織は、自動推論チェックを使って、一貫性のない手作業のレビューから、形式的に検証でき、監査にも対応できるコンプライアンスワークフローへ移行しています。詳細は 「PwC and AWS Build Responsible AI with Automated Reasoning on Amazon Bedrock」 をご覧ください。 エネルギー・公益事業: 電力事業者は、AI が生成した停電の分類を北米電力信頼度協議会 (NERC) および米国連邦エネルギー規制委員会 (FERC) の規制要件に照らして検証し、個々のディスパッチ判断を形式的検証で裏付けています。 このユースケースに関する PwC との re:Invent セッションをご覧ください 。 製薬とライフサイエンス: プロフェッショナルサービス企業は、AI 主導のマーケティングコンテンツ向けに数学的に裏付けられる検証レイヤーを構築し、コンテンツの主張が承認済みの根拠資料に基づいていることを確認しています。 保険: 保険会社は、約款の記述に対して形式的に推論する顧客向けチャットボットを構築し、確率的な近似ではなく検証可能な補償判定を提供しています。 まとめ この記事では、Amazon Bedrock Guardrails の自動推論チェックが、監査にそのまま使えるエビデンスとともに数学的に証明可能な検証を提供する仕組みを説明しました。規制業界でコンプライアンスアシスタントを構築するチームや、既存の AI ワークフローに形式的検証レイヤーを追加したいチームにとって、このテクノロジーは確率的な確信から数学的な証明へ進むための道筋となります。 自動推論チェック は、AWS の他の責任ある AI 機能を補完します。例えば、検索拡張生成 (RAG) のための Amazon Bedrock ナレッジベース 、コンプライアンス追跡のための AWS Audit Manager 、モデルガバナンスのための Amazon SageMaker AI などです。 訳注: AWS Audit Manager はメンテナンスモードへの移行が公表されており、2026 年 4 月 30 日以降は新しいアカウントでこのサービスをセットアップできません。セットアップ済みのアカウントでは引き続き利用できます。参照: AWS Audit Manager 可用性の変更 、 AWS Audit Manager とは 開始方法 使ってみる: セットアップのガイダンスについては、 自動推論チェックのドキュメント をご覧ください。 訳注: 2026 年 9 月現在、自動推論チェックがサポートする言語は英語です。最新の対応状況は、Amazon Bedrock ユーザーガイドの「 Amazon Bedrock ガードレールの自動推論チェックとは 」を参照してください。 実践的な手順については、 「Minimize generative AI hallucinations with Amazon Bedrock Automated Reasoning checks」 を参照してください。 チャットボットは、自動推論チェックのフィードバックを使い、正しさを証明できる回答に到達するまでユーザーに確認の質問をしながら、回答を繰り返し書き換えることができます。 始めるには、 「自動推論チェックで回答を書き換えてハルシネーションを抑えるチャットボットのリファレンス実装」 を参照してください。 エージェントを使えば、自動推論ポリシーを改善するプロセス全体を自然言語で対象分野の専門家に案内できます。そうしたエージェントの オープンソースのサンプル をご覧ください。 お客様の成果を見る: Amazon Logistics の導入事例 | 教育における責任ある AI に関する PwC の導入事例 | AWS の責任ある AI のリソース Amazon Bedrock の機能の詳細: Amazon Bedrock Guardrails | Amazon Bedrock AgentCore AI ライフサイクル全体にわたるガイダンスと責任ある AI のベストプラクティス: AWS Well-Architected 責任ある AI レンズ 自動推論チェックがお客様のコンプライアンスのユースケースにどう役立つかについては、担当の AWS アカウントチームにお問い合わせください。準備として、AI の出力に形式的検証が必要となるコンプライアンスワークフローを、重要度の高い順に 3 つ挙げておくとよいでしょう。 図 3: Amazon Bedrock の自動推論によるコンプライアンスチェックのリファレンスアーキテクチャ。 ユーザーは Amazon CloudFront 経由でアプリケーションにアクセスします。CloudFront は Amazon Simple Storage Service (Amazon S3) の静的ホスティングから React フロントエンドを配信します。 Amazon Cognito がユーザーを認証し、JWT トークンを発行します。CloudFront は下流のリクエストに対して認証を強制します。 ユーザーは、地域、施設タイプ、ライセンスカテゴリを指定してコンプライアンスチェックのリクエストを送信します。CloudFront はそのリクエストを AWS Lambda にルーティングします。 Lambda は、地域、施設タイプ、ライセンスカテゴリをキーとして Amazon DynamoDB のルールエンジンにクエリを実行し、該当する規制ルールを正確に取得します。 Lambda はルールをプロンプトに挿入し、Amazon Bedrock を呼び出します。ナレッジベースは、Amazon S3 に保存された検証済みの規制文書から RAG のコンテキストを提供します。 生成されたコンプライアンスチェックリストは Amazon Bedrock の自動推論チェックに送信されます。自動推論チェックはルールを形式論理モデルにコンパイルし、各項目を数学的に検証します。この検証は確率的ではなく、証明可能です。 検証済みの項目は Amazon S3 に保存され、ユーザーに返されます。無効な項目は、モデルによって修正版が再生成されます (最大 3 回まで再試行)。対象範囲外の項目は理由付きで自動的に除外されます。 2 つ目の DynamoDB テーブルには顧客施設のプロファイルが保存されており、リクエストごとにデータを再アップロードすることなく、ID で病院を検索できます。 Amazon EventBridge スケジューラが設定可能なスケジュールで Lambda のウェブクローラーを起動し、政府の規制関連ウェブサイトをスクレイピングして、ポリシーの変更に関する情報を収集します。 スクレイピングしたコンテンツは Amazon Bedrock のポリシー差分エージェントに送信され、変更内容が検出されます。更新されたルールは DynamoDB に書き込まれ、新しい文書はナレッジベースに再インデックスされます。 自動推論チェックの検証証明を含むコンプライアンスレポートは DynamoDB に保存され、監査証跡、フィルタリング、ダウンロードのために [レポート] タブからアクセスできます。 謝辞 本取り組みに貢献いただいた Suresh Kanan、Tonny Ouma、Laurie Kasper、Stefano Buliani に特に感謝します。 著者について Nafi Diallo Nafi Diallo は Amazon Web Services の Senior Automated Reasoning Architect で、信頼できる AI ソリューションのための AI の安全性、形式的検証、ガードレールの実装を専門としています。Amazon Bedrock 上の生成 AI およびエージェンティック AI システムの信頼性を評価し、向上させる豊富な経験を持っています。また、AWS の Women in AI and ML (WAIML) 組織で北米地域の Regional Lead を務め、チャプターの成長を支援しながら、地域全体で WAIML のミッションを推進しています。 Aishwarya Natarajan Aishwarya Natarajan は、ジョージア州アトランタを拠点とする AWS の Solutions Architect で、産業用 IoT と AI/ML の専門知識を活かして自動車・製造業界を担当しています。クラウドテクノロジーを使ってお客様独自のビジネス課題の解決を支援することに情熱を注いでいます。余暇には家族や友人と過ごしたり、新しい場所を訪れたりすることを楽しんでいます。 Adewale Akinfaderin Adewale Akinfaderin は Amazon Bedrock の Generative AI 担当 Sr. Data Scientist で、AWS における基盤モデルと生成 AI アプリケーションの進化に貢献しています。再現可能でエンドツーエンドの AI/ML 手法、実践的な実装、そして世界中のお客様が学際的な課題に対してスケーラブルなソリューションを策定・開発できるよう支援することを専門としています。物理学分野で大学院の学位を 2 つ、工学の博士号を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 8 月 3 日に公開された AWS Blog “ Automated Reasoning policy refinement in Amazon Bedrock ” を翻訳したものです。 Amazon Bedrock で自動推論ポリシー (Automated Reasoning policy) を改善する作業は、これまで診断、手作業での編集、再テストを繰り返す手動のサイクルでした。本日 (2026 年 8 月 3 日)、このサイクルのうち診断と修正の作業を自動化するポリシーの自動改善を発表します。改善エンジンが失敗したテストを診断し、形式論理の修正案を提示します。どの変更も、お客様が承認してから反映されます。 自動推論チェック (Automated Reasoning checks) は、Amazon Bedrock Guardrails において形式検証を使用して回答の正しさを証明します。自然言語から形式論理への変換があいまいでなければ、最大 99% の検証精度を実現します。これは「 自動推論チェックを使用して、AI のハルシネーションを最小限に抑え、最大 99% の検証精度を実現: 今すぐご利用いただけます 」で報告したとおりです。使い始めるには、ソースドキュメントから自動推論ポリシーを構築し、テストケースで検証します。お客様からは、この反復的なチューニングがポリシー開発における最大のボトルネックになっているという声が寄せられていました。 この記事では、2 つの新しい改善モードを解説します。ルールの問題に対応する Iterative Refinement (反復的な改善) と、言語の問題に対応する Ambiguous Variable Refinement (あいまいな変数の改善) です。各モードについて、API ワークフロー全体 (開始、ポーリング、取得) と、失敗するポリシーを合格するポリシーに変えるための再現可能なコンソール手順を紹介します。 自動推論チェックとは何か 自動推論チェックは自然言語を形式論理に変換し、自動推論の技術を適用して次のいずれかの検出結果を生成します。 VALID 、 INVALID 、 SATISFIABLE 、 IMPOSSIBLE 、 TRANSLATION_AMBIGUOUS です。ポリシーの仕組みについて詳しくは、「 自動推論チェックを使用して、AI のハルシネーションを最小限に抑え、最大 99% の検証精度を実現: 今すぐご利用いただけます 」を参照してください。 訳注: 2026 年 9 月 13 日時点の Amazon Bedrock API リファレンスでは、自動推論チェックが返す検出結果 (finding) として、本文で挙げた 5 種類に加えて NO_TRANSLATIONS と TOO_COMPLEX が定義されており、合計 7 種類があります。参照: GuardrailAutomatedReasoningFinding – Amazon Bedrock API Reference この記事で重要となる概念は、 2 ステップの検証パイプライン です。まず、 変換 (translate) ステップでは、ポリシー内の変数の説明を使用して、自然言語の入力/出力を変数の割り当てにマッピングします。次に、 検証 (validate) ステップでは、それらの割り当てに形式ルールを適用します。テストが失敗したときは、根本原因はこの 2 つのステップのいずれかにあり、各改善モードはそれぞれ異なるステップを対象としています。図 1 はこのパイプラインを最初から最後まで示しています。 図 1: 自動推論チェックが実行時に応答を検証する仕組み。自動推論チェックは、ポリシーの変数の説明を使用して自然言語を変数に変換し、それらの変数をポリシーの形式ルールに照らして検証し、検出結果を返します。この 2 ステップのパイプラインがあるため、改善には 2 つのモードが存在します。 ポリシーのテスト。 ポリシーにテストを追加して検証します。各テストは、入力/出力テキストと期待する結果で構成されます。テストは個別にも一括でも実行できます。失敗結果を見れば、ポリシーが意図からどこで逸脱しているかが正確にわかります。 ポリシーに改善が必要な理由: 2 つの失敗モード 2 ステップのパイプラインを思い出してください。 変換 (自然言語から変数の割り当てへ) と、それに続く 検証 (形式論理から検出結果へ) です。テストの失敗は、このいずれかのステップが予期しない結果を生成したことを意味します。自動推論チェックは、各ステップに明確に対応する 2 種類の失敗シグナルを提示します。 失敗モード 1: ルールの問題 (論理が誤っている) ルールの問題による失敗では、変換は正しく機能しています。適切な変数に適切な値が入っているのに、検証結果が期待と一致しません。問題はルールにあり、ルールが緩すぎる、厳しすぎる、あるいはまったく存在しないというケースです。具体的には、不足しているルールや緩すぎるルールが誤った回答を通してしまい、 INVALID を期待していたのに SATISFIABLE が返される場合です。逆に、過度に厳格なルールが正しい回答をブロックし、 SATISFIABLE を期待していたのに INVALID が返される場合もあります。 考え方: システムは質問を完全に理解していたものの、誤った論理を適用しました。修正すべきなのは ルール です。 失敗モード 2: 変換のあいまいさ (言語が誤っている) テストが TRANSLATION_AMBIGUOUS を返す場合、検証エンジンは動作しますが、どの解釈に従うかによって結果が変わります。自然言語の入力をポリシーの変数にどうマッピングするかで変換モデル間の判断が分かれ、競合する各解釈がそれぞれ異なる検証結果につながるケースもあります。検出結果には、それぞれ独自の変換と結論を持つ 2 つ以上の選択肢が示され、さらに解釈が実際にどこで分かれるかを示す differenceScenarios も提示されます。よくある根本原因としては、変数定義の重複 (「tenure」と「years of service」など)、説明があいまいであること、値の形式が一貫していないこと (「5%」に対して 5 と 0.05 のどちらを使うかなど) が挙げられます。 失敗とモードの対応 次の表は、どの改善モードがどの失敗タイプに対応するかをまとめたものです。 失敗モード 根本原因 改善モード 動作内容 ルールの問題 論理が誤っている Iterative Refinement ルールまたは変数の追加、編集、削除を提案する 変換のあいまいさ 言語があいまいである Ambiguous Variable Refinement 複数の解釈を 1 つにまとめる、より明確な変数の説明を提案する システムが単一の変換を決定できない場合は、 Ambiguous Variable Refinement を使用します。続く 2 つのセクションでは、各モードについて、何をするのか、いつ使うのか、レビューゲートはどう機能するのか、そしてプログラムからどう起動するのかを順に説明します。ルールの問題による失敗のほうが多いため、まず Iterative Refinement から始めます。 Iterative Refinement: ルールの修正 論理が誤っているためにテストが失敗する場合 (変換は問題ないが検証結果が期待と一致しない場合)、問題はルールにあります。 Iterative Refinement ( ITERATIVELY_REFINE_POLICY ) は診断と修正のサイクルを自動化するため、各ルールを手作業でたどり、修正内容を推測し、形式論理を手で編集する必要がなくなります。 10～30 個のルールを持つポリシーを考えてみましょう。従来は、1 つの修正のために、対象分野の専門家が手動で診断し、SMT-LIB で記述された形式論理を手作業で編集することを何度も繰り返す必要がありました。この作業は今では、レビューして承認するだけの 1 ステップに集約され、形式論理を手で書く必要はなくなります。 仕組み Iterative Refinement は 3 つの入力を受け取ります。1 つ目は既存のポリシー定義 (現在のルール、変数、型) です。2 つ目は、本来どう動作 すべき かを記述した信頼できる自然言語テキストを含むソースドキュメントです。3 つ目の入力は任意で、望む変更を明示的に指示する自然言語のフィードバックです。 例えば、フィードバックフィールドには次のような内容を記述できます。 「改訂版ドキュメントのセクション 3 に規定されているとおり、育児休暇の勤続期間要件を 12 か月から 6 か月に更新してください」 。 これらの入力を受けて、改善エンジンは現在のルールがソースドキュメントとフィードバックからどのように逸脱しているかを分析します。そして、ポリシーを整合させる一連の変更候補 (新しいルール、編集されたルール、追加された変数) を提案します。 収束ループ Iterative Refinement は名前が示すとおり反復処理を行います。内部では、エンジンが変更候補を生成し、保存済みのテストへの影響をシミュレートし、これまで失敗していたテストが合格するようになったかを確認し、そうでなければ調整します。1 回のリクエストで複数の内部サイクルが発生することもあります。特に、1 つのルールの修正が他のルールに波及する場合にそうなります。ただし、この反復は 内部的に 行われます。中間段階の試行は 1 つずつ表示されず、進行を管理する必要もありません。受け取るのは収束後の結果、つまりどのルールが変わり、どの変数が変わり、その変更がテストスイート内のすべてのテストにどう影響するかを正確に示す差分案です。 レビューゲート 収束後、 [Review policy changes] 画面が表示されます。 次に、 [Accept changes] または [Discard changes] を選択します。承諾すると、変更が DRAFT ポリシーに書き込まれます。破棄すると、すべてが元のまま維持されます。 前提条件と使用する場面 Iterative Refinement では、ポリシーに少なくとも 1 つのテストが追加されている必要があります。失敗したテストのシグナルがなければ、改善の手がかりが得られないからです。このモードは、変換が正しい (適切な変数と適切な値) にもかかわらず検証結果が予期しないものである場合に使用します。検出結果が TRANSLATION_AMBIGUOUS の場合には使用しないでください。それは言語の問題であり、 Ambiguous Variable Refinement で対処するほうが適切です。 API からの実行 改善処理は非同期のビルドワークフローとして実行されます。AWS SDK for Python (Boto3) を使用する場合、フローは 4 つのステップで構成されます。現在のポリシー定義をエクスポートし、ワークフローを開始し、完了をポーリングし、提案された変更を取得します。 buildWorkflowType には ITERATIVELY_REFINE_POLICY を設定します。 iterativeRefinementContent ブロックは、1～5 個のソースドキュメント (必須) と、最大 4,000 文字の任意のフィードバックを受け取ります。 import boto3 bedrock = boto3.client("bedrock") # Export the current policy definition (required input to the workflow). policy_definition = bedrock.export_automated_reasoning_policy_version( policyArn=policy_arn, )["policyDefinition"] with open("hr-leave-policy.pdf", "rb") as f: source_document = f.read() response = bedrock.start_automated_reasoning_policy_build_workflow( policyArn=policy_arn, buildWorkflowType="ITERATIVELY_REFINE_POLICY", sourceContent={ "policyDefinition": policy_definition, "workflowContent": { "iterativeRefinementContent": { "documents": [ { "document": source_document, "documentName": "hr-leave-policy.pdf", "documentContentType": "pdf", } ], "feedback": "Update the tenure requirement from 12 to 6 months per section 3.", } }, }, ) build_workflow_id = response["buildWorkflowId"] この呼び出しは、提案された変更ではなく buildWorkflowId を即座に返します。ワークフローは SCHEDULED から BUILDING へ移行し、最終的に COMPLETED 、 FAILED 、または CANCELLED に到達します。収束にかかる時間はポリシーのサイズに応じて通常 1 分から数分です。ステータスが終端状態に達するまで get_automated_reasoning_policy_build_workflow をポーリングします。その後、 get_automated_reasoning_policy_build_workflow_result_assets で収束した提案を取得します。更新されたルールを確認するには POLICY_DEFINITION アセットを、アクションログを確認するには BUILD_LOG をリクエストします。 import time while True: workflow = bedrock.get_automated_reasoning_policy_build_workflow( policyArn=policy_arn, buildWorkflowId=build_workflow_id, ) status = workflow["status"] if status in ("COMPLETED", "FAILED", "CANCELLED"): break time.sleep(10) if status == "COMPLETED": assets = bedrock.get_automated_reasoning_policy_build_workflow_result_assets( policyArn=policy_arn, buildWorkflowId=build_workflow_id, assetType="POLICY_DEFINITION", ) proposed_definition = assets["buildWorkflowAssets"]["policyDefinition"] 返されるポリシー定義は提案された DRAFT であり、新しい定義の全体です。これをコミットするには、この定義を指定して update_automated_reasoning_policy を呼び出します。何が変わったかを確認するには、ワークフローを開始する前にエクスポートしたポリシー定義との差分を取ります。コンソールの [Review policy changes] 画面は、この開始・ポーリング・取得という同じ手順をラップし、[Accept changes] ボタンと [Discard changes] ボタンで操作できるように差分を表示しています。 Ambiguous Variable Refinement: 言語の修正 Iterative Refinement はルールの問題に対応しますが、失敗するテストのすべてがルールの問題であるとは限りません。変換そのものが不安定な場合、ルールをいくら編集しても解決しません。この場合は、ポリシーが変数を説明するために使っている言語を修正する必要があります。それを行うのが Ambiguous Variable Refinement です。このモードも同じ非同期の開始・ポーリング・取得パターンに従い、同じレビューと承諾の画面に到達します。違いは提案内容です。提案は変数の説明とマージを中心とし、ポリシーの一貫性を保つために必要に応じてルールと型の更新も適用されます。 テストが TRANSLATION_AMBIGUOUS の結果を生成する場合 (この記事の前半にある失敗モード 2 を参照してください)、競合する変換が異なる検証結果につながっています。あいまいさは、検証対象のコンテンツ自体の表現方法から生じることもあります。このセクションでは、ポリシー変数におけるあいまいさに焦点を当てます。 仕組み ポリシー変数の問題に起因する変換のあいまいさは、通常いくつかの根本原因から生じます。重複する変数は、2 つの変数が同じ概念を記述している場合に発生します。例えば、tenureMonths (「従業員が何か月働いているか」) と monthsOfService (「従業員の勤続月数」) はどちらも雇用期間をとらえています。その結果、どちらを使うべきかについて、変換モデル間で判断が分かれます。説明が不完全なケースは、変数の説明があいまいすぎて変換を導けないときに起こります。値の形式が一貫していないケースでは、「5%」を interestRate = 5 とすべきか interestRate = 0.05 とすべきかをシステムが判断できず、あいまいさが生じます。変数名に論理が埋め込まれていると混乱を招きます。timelyReportingNotFeasible のような名前は既に否定を含んでいるため、肯定のケースを表現するには否定の否定が必要になります。変換モデルはしばしばこの 2 つの否定のうち 1 つを取りこぼします。 これらは最も一般的なパターンにすぎません。検出は既知の問題の固定リストと照合するのではなく、ポリシーの変数を実際に変換で使用して行われるため、変換の不一致を引き起こす変数レベルの問題は、ここに挙げた以外のものも表面化し得ます。 Ambiguous Variable Refinement を実行すると、どの変数の説明や重複する定義が不一致の原因になっているかを特定し、複数の解釈を 1 つの正確な定義にまとめる、改善された説明を提案します。 改善された説明には、単位変換のルール、同義語、別の表現、明示的な形式のガイダンスが盛り込まれます。次のビフォー/アフターの例は、典型的な提案を示しています。 変更前 変更後 (提案) tenureMonths: 「従業員が何か月働いているか」 tenureMonths: 「従業員が継続して雇用されている期間の月数 (1 か月未満の端数は含めません)。ユーザーが勤続年数に言及した場合は月数に変換します (例: 2 年 = 24 か月)。この変数は、雇用期間、勤続期間、在社期間、または勤続年数への言及をとらえます」 重複する変数が検出された場合は、マージも提案されることがあります。一方の変数が削除され、それを参照するルールは残った変数を使用するように更新されます。 レビューゲート Iterative Refinement と同様に、何も適用される前に提案された変更をレビューします。 また、[Test results] も表示されます。以前は TRANSLATION_AMBIGUOUS を返していたテストが、確定的な VALID 、 INVALID 、または SATISFIABLE の結果を生成するようになります。 [Accept changes] または [Discard changes] を選択します。承認するまで、DRAFT ポリシーには一切の変更が加えられません。 使用する場面 Ambiguous Variable Refinement は、テストが TRANSLATION_AMBIGUOUS の結果を生成する場合、または VALID / INVALID の検出結果を確認したときに、変換が誤った変数に値を割り当てていることが判明した場合に使用します。変換が正しいのに検証結果が予期しないものである場合には使用しないでください。それはルールの問題であり、 Iterative Refinement の対象です。 API からの実行 Ambiguous Variable Refinement は、同じ非同期の開始・ポーリング・取得パターンを使用します。 buildWorkflowType には RESOLVE_POLICY_AMBIGUITIES を設定します。このモードはポリシーの変数を直接分析するため、ソースドキュメントも追加済みのテストも必要とせず、workflowContent は省略できます。ただし、現在のポリシー定義は sourceContent に引き続き必要です。 Iterative Refinement の場合と同様に、前述の export_automated_reasoning_policy_version を使ってまずエクスポートしてください。 response = bedrock.start_automated_reasoning_policy_build_workflow( policyArn=policy_arn, buildWorkflowType="RESOLVE_POLICY_AMBIGUITIES", sourceContent={ "policyDefinition": policy_definition, }, ) build_workflow_id = response["buildWorkflowId"] Iterative Refinement と同様に、レスポンスは buildWorkflowId です。ステータスが終端状態に達するまで get_automated_reasoning_policy_build_workflow をポーリングします。その後、 get_automated_reasoning_policy_build_workflow_result_assets を assetType="POLICY_DEFINITION" とともに呼び出して、提案された変数の説明とマージを取得します。 while True: workflow = bedrock.get_automated_reasoning_policy_build_workflow( policyArn=policy_arn, buildWorkflowId=build_workflow_id, ) status = workflow["status"] if status in ("COMPLETED", "FAILED", "CANCELLED"): break time.sleep(10) if status == "COMPLETED": assets = bedrock.get_automated_reasoning_policy_build_workflow_result_assets( policyArn=policy_arn, buildWorkflowId=build_workflow_id, assetType="POLICY_DEFINITION", ) proposed_definition = assets["buildWorkflowAssets"]["policyDefinition"] 承諾するまで、変更は提案の状態にとどまります。 すべての変更はお客様が承認: ヒューマンインザループのゲート 両方の改善モードには、譲れない共通の性質が 1 つあります。 お客様が承認するまで、いかなる変更も反映されません。 改善エンジンが持つのは 提案する権限 で、分析し、診断し、提案できます。お客様が持つのは コミットする権限 です。DRAFT ポリシー、ひいては本番環境に何を反映するかを決めるのはお客様です。 5 ステップのループ どの改善モードを使用する場合も、ワークフローは同じ 5 ステップのパターンに従います。第 1 にテストです。保存済みのテストを現在のポリシーに対して実行します。第 2 に確認です。どのテストが期待した結果と一致しないかを特定します。第 3 に提案です。システムがルールまたは変数の説明に対する修正候補を生成します。第 4 にレビューです。提案された差分とテストへの影響を確認します。第 5 に適用です。変更を承諾して DRAFT に適用するか、拒否して何も変更しないかを選びます。 承諾した後は、他のテストを壊さずに問題が解決したことを確認するため、再テストを行います。このようにして、各サイクルの進展が後戻りせずに積み重なっていきます。サイクルごとに、テストに合格するポリシーに近づくか、新たな診断情報が得られるかのいずれかです。 レビュー画面で確認できる内容 レビュー画面では、変更内容そのものだけでなく、その変更の 波及効果 を把握できます。この画面は 2 つの問いに同時に答えます。エンジンは何を提案したのか、そしてその提案は、重視しているすべてのテストにどう影響するのかです。 提案は 3 つのセクションで示されます。 [Changes to rules] には、追加、編集、削除されたルールが、それぞれの形式論理の式とともに一覧表示されます。 [Changes to variables] には、更新された変数の説明と、追加または削除された変数が表示されます。変更前の文言と提案された文言が並べて示されるため、両者を直接比較できます。 [Changes to custom variable types] は、ポリシーの列挙型に対する変更を扱います。 これらの変更とあわせて、画面には [Test results] セクションが表示され、保存済みのテストとその変更前後の結果が一覧化されます。各行には期待される検出結果と、変更前後でテストが合格したかどうかが示されます。行の [View findings] を選択すると、検出結果そのものを確認できます。このビューは画面上で最も重要な指標です。失敗していたテストが合格し、合格していたテストが引き続き合格しているのであれば、安心して承諾できます。 Fidelity Report による検証 変更を適用した後は、 Fidelity Report (忠実度レポート、 GENERATE_FIDELITY_REPORT ) を生成し、更新後のポリシーがソースドキュメントを引き続き忠実に表現しているかを検証します。このレポートは 3 つの測定値を提供します。 カバレッジスコア (0.0～1.0) は、ソースドキュメントのどれだけがポリシーに反映されているかを示します。 精度スコア (0.0～1.0) は、ルールが元のドキュメントの意図にどれだけ忠実に一致しているかを示します。 ルールごとのグラウンディング は、各ルールを、その裏付けとなるソースドキュメント内の具体的な記述に、根拠とともに結び付けます。 改善の前後で Fidelity Report を比較してください。精度スコアが低下している場合、提案された修正がソース資料から逸脱している可能性があり、拒否するかさらに反復すべきというシグナルになります。 原則 自動改善が加速するのは、失敗を診断し修正候補を生成する 作業 です。ただし、ガードレールが適用するルールを変更する 権限 は、引き続きお客様が保持します。すべての修正は、お客様が承諾すると決めるまで提案のままです。 エンジンの方向付け: ソースドキュメントとカスタムフィードバック 適切な修正へより早くたどり着けるようコンテキストを提供すれば、両方のモードを望む方向に導けます。 ソースドキュメント Iterative Refinement を起動するときは、ポリシーが表現すべきグラウンドトゥルースを表すソースドキュメントを指定します。コンソールでは、そのための 3 つのモードが用意されています。 [Recently used] は以前にアップロードしたドキュメントを再選択し、 [Upload] は新しい PDF またはテキストファイルを受け取り、 [Enter text] は貼り付けたコンテンツを直接受け取ります。ドキュメントが明確で焦点が絞られているほど、提案も正確になります。 カスタムフィードバック: 明示的な if-then ガイダンス 何を修正すべきかをシステムに正確に伝える 自然言語のフィードバック を提供することもできます。効果的なフィードバックは具体的で検証可能です。「勤続期間のルールを修正してください」のようなあいまいなフィードバックは、エンジンに過大な裁量を与えてしまいます。次のような具体的で検証可能な代替案と比べてみてください。「従業員がフルタイムで、6 か月 (12 か月ではなく) を超えて勤務している場合、育児休暇の対象となるべきです」。 フィードバックは制約として機能します。システムは、ソースドキュメントとガイダンスの両方を満たす変更を生成します。両者が矛盾する場合は、その矛盾がレビュー用にフラグ付けされます。 ソースドキュメントとフィードバックを同時に指定することもできます。ドキュメントの情報量が多い場合、フィードバックによって重要な特定のセクションにシステムの注意を集中させられます。 エンドツーエンドのウォークスルー このセクションでは、各改善モードに対応する 2 つのウォークスルーを紹介します。この 2 つを合わせることで、両方の失敗タイプに対する再現可能なワークフローが得られます。 前提条件 Amazon Bedrock の自動推論チェックでポリシーの自動改善を使用するには、次の前提条件を満たしていることを確認してください。 有効な AWS アカウント 自動推論チェックが利用可能な AWS リージョンの確認と、そのいずれかのリージョンにおける Amazon Bedrock へのアクセス 訳注: 2026 年 9 月現在、自動推論チェックがサポートする言語は英語です。最新の対応状況は、Amazon Bedrock ユーザーガイドの「 Amazon Bedrock ガードレールの自動推論チェックとは 」を参照してください。 自動推論ポリシーを作成、表示、改善し、Amazon Bedrock Guardrails を操作するための IAM アクセス許可 強制したいルールを記述したソースドキュメントから作成された、アカウント内の自動推論ポリシー。手順の詳細については、「 自動推論ポリシーを作成する 」を参照してください。このポリシーには少なくとも 1 つのテストが追加されている必要があります。Iterative Refinement は診断を進めるために失敗したテストのシグナルを必要とします。テストを追加するには、「 自動推論ポリシーをテストする 」を参照してください。 ウォークスルー A: Iterative Refinement によるルールの問題の修正 休暇の取得資格を定める人事ポリシーに、失敗するテストがあります。アシスタントは、 勤続 8 か月のパートタイム従業員が育児休暇の対象になる と回答します。テストは INVALID を期待していますが、ポリシーは VALID を返します。 ステップ 1: テストを検証する Amazon Bedrock コンソールで [Automated Reasoning] に移動し、ポリシーを開きます。 [Tests] タブを選択し、次に [Validate all tests] を選択します。図 2 に結果を示します。4 つのテストのうち 3 つは合格し、育児休暇のテストは予期しない VALID の検出結果で失敗します。 図 2: 検証後の [Tests] タブ。4 つのテストのうち 3 つが合格 (75%) ステップ 2: 失敗した検出結果を確認する 失敗したテストの検出結果を開き、図 3 に示す変換内容を確認します。変数は正しくとらえられています。 monthsOfContinuousService = 8 employmentStatus = PART_TIME 図 3: 失敗したテストの検出結果。変換が変数を正しくとらえていることがわかる 検出結果が VALID となっているのは、根拠となる唯一のルールが継続勤務 6 か月後に資格を付与しており、パートタイム従業員を除外するルールが存在しないためです。変換に問題はなく、論理が誤っているため、これはルールの問題です。 ステップ 3: ポリシーを改善する [Refine policy] を選択し、次に [Automatically refine policy] を選択します。 改善タイプを Iterative Refinement に設定します。 次の 3 つのモードのいずれかを使用して、ソースドキュメントを指定します。 [Recently used] [Upload] (新しいバージョンをアップロード) [Enter text] (該当する段落を貼り付ける) 必要に応じて、修正の焦点を絞るためのカスタムフィードバックを追加します。例: 「 パートタイム従業員を育児休暇の対象外とすることを明示するルールを追加してください 」。 入力の準備ができたら、 [Start] を選択します。 図 4 は、改善タイプを選択し、ソースドキュメントを添付し、カスタムフィードバックを入力した設定完了時の状態を示しています。 図 4: ソースドキュメントとカスタムフィードバックを指定した Iterative Refinement の設定 ステップ 4: 変更をレビューして承諾する 収束が完了すると、 [Review policy changes] 画面が表示されます。 [Changes to rules] には、削除されたルール 1 件と追加されたルール 1 件の 2 つの変更が一覧表示されます。エンジンは、継続勤務のみで資格を付与していたルールを削除しました。 monthsOfContinuousService が 6 以上の場合、 isEligibleForParentalLeave は true になります そして、パートタイム従業員を除外するルールを追加しました。 employmentStatus が PART_TIME と等しい場合、 isEligibleForParentalLeave は false になります [Test results] では、パートタイムのテストが [Failed] から [Passed] に変わり、他の 3 つのテストは [Passed] のままです。図 5 は承諾前の画面を示しています。 図 5: [Review policy changes] 画面。[Changes to rules] には、削除された勤続期間のみによる資格ルールと、追加されたパートタイム除外ルールが一覧表示され、[Test results] にはパートタイムのテストが Failed から Passed に変わり、リグレッションがないことが示されています。 [Accept changes] を選択します。 ステップ 5: 修正を確認する [Tests] タブに戻り、再度 [Validate all tests] を選択します。 図 6 に期待される結果を示します。これまで失敗していたテストが合格し、合格率は 100% に達します。 図 6: 改善後の [Tests] タブ。4 つのテストすべてが合格 (100%) テストが引き続き失敗する場合やリグレッションが発生した場合 1 回の改善サイクルですべての失敗が解消されることや、リグレッションが発生しないことは保証されません。これまで失敗していたテストが依然として失敗する場合、または以前は合格していた他のテストが失敗するようになった場合は、次の手順を行ってください。 レビュー画面で [Discard changes] を選択します。 エンジンが前回とは異なる形で何を修正すべきかを説明する、より具体的なカスタムフィードバックを追加します。例: 「このルールは、パートタイム従業員の資格期間を短縮するだけで済ませず、育児休暇の対象から完全に除外すべきです」 。 ソースドキュメントを、失敗しているルールに対応する正確なセクションに絞り込みます。 これらの絞り込んだ入力で、再度 Iterative Refinement を実行します。 2 回か 3 回試してもテストが合格しない場合は、手作業による編集に切り替えてください。失敗した検出結果の変換内容とルールのトレースを手がかりに、ポリシーエディタで該当するルールを手で編集します。 ステップ 6: レポートを生成してデプロイする [Generate Fidelity Report] を選択し、前回のレポートとスコアを比較します。 結果に問題がなければ、デプロイ用に 番号付きバージョン を作成します。 ウォークスルー B: Ambiguous Variable Refinement による言語の問題の修正 同じ人事ポリシーを使いますが、今回はテストが TRANSLATION_AMBIGUOUS を返します。検出結果には 2 つの選択肢が示されます。 一方は「2 years of service」を tenureMonths = 24 と解釈しました。 もう一方は monthsOfService = 24 と解釈しました。 この 2 つの選択肢から、変数の重複が明らかになります。tenureMonths と monthsOfService はどちらも雇用期間を記述しており、どちらを使うべきかについて変換モデル間で判断が一致しません。この重複があいまいさの根本原因です。 ステップ 1: ポリシーを改善する [Refine policy] を選択し、次に Ambiguous Variable Refinement を選択します。 図 7 に示すように、このモードではソースドキュメントは必要ないため、設定は 1 つの選択だけで完了します。 図 7: ソースドキュメントを必要としない Ambiguous Variable Refinement の設定 [Start] を選択します。 ステップ 2: 変更をレビューして承諾する [Review policy changes] 画面で、提案された変数のマージをレビューします。 monthsOfService が削除されます。 ルールが tenureMonths を参照するように更新されます。 tenureMonths の説明が次のように拡張されます。 「従業員が継続して雇用されている期間の月数 (1 か月未満の端数は含めません)。ユーザーが勤続年数に言及した場合は月数に変換します (例: 2 年 = 24 か月)。この変数は、雇用期間、勤続期間、在社期間、または勤続年数へのすべての言及をとらえます」 [Test results] では、これまであいまいだったテストが確定的な VALID の結果を生成するようになります。 [Accept changes] を選択します。 ステップ 3: 修正を確認する [Tests] タブに戻り、再度 [Validate all tests] を選択します。 図 8 に確認結果を示します。これまで TRANSLATION_AMBIGUOUS を返していたテストが、確定的な VALID の検出結果を生成し、合格するようになります。 図 8: あいまいな変数の改善を適用した後の [Tests] タブ ステップ 4: レポートを生成してデプロイする [Generate Fidelity Report] を選択し、前回のレポートとスコアを比較します。 結果に問題がなければ、デプロイ用に番号付きバージョンを作成します。 注意 どちらの改善モードでも、テストが合格することや、提案された変更がリグレッションを引き起こさないことは保証されません。テストが合格しない場合や、合格していた他のテストが失敗するようになった場合は、変更を破棄して再度試すことができます。 ベストプラクティスと実際のユースケース 改善エンジンは、明確なシグナルと範囲の限定された変更を与えたときに最も効果を発揮します。次のプラクティスはその方法を示し、ユースケースはそれが効果を発揮する場面を示します。 ベストプラクティス 次のプラクティスは、改善がうまくいかなくなる最も一般的な 2 つのパターンから導かれたものです。あいまいな失敗シグナルで改善を実行してしまうケースと、意図した以上にポリシーを変更させてしまうケースです。 モードを選ぶ前に変換内容を読む。 まず失敗した検出結果を開き、変数の割り当てを確認します。適切な変数に適切な値が入っているのに結果が誤っている場合は、 Iterative Refinement で対処すべきルールの問題です。割り当てが誤っている場合、または検出結果が TRANSLATION_AMBIGUOUS の場合は、 Ambiguous Variable Refinement で対処すべき言語の問題です。変換内容を確認せずに症状だけでモードを選ぶことが、誤った箇所を「修正」してしまう改善の最も多い原因です。 入力の範囲を絞って変更を限定する。 ポリシーの一部分 (例えば育児休暇の資格) に範囲を絞ったソースドキュメントに対して改善を実行します。修正が必要なルールが 1 つだけの場合は、具体的な if-then 形式のフィードバックを組み合わせます。焦点の絞られた入力は、「勤続期間のルールを修正してください」のようなあいまいなガイダンスで 40 ページのハンドブック全体をエンジンに与える場合よりも、範囲が限定されレビューしやすい提案を生み出します。 差分よりも [Test results] を信頼する。 レビュー画面には、変更されたルールと、保存済みのすべてのテストへの影響の両方が表示されます。判断の決め手となるのは [Test results] パネルです。失敗していたテストが合格に転じ、合格していたテストがそのまま合格を維持しているときに承諾してください。きれいに見える差分でも、それによって以前は合格していたテストが失敗するようになるなら、それは修正ではありません。 バージョンを作成する前に Fidelity Report を比較する。 改善処理はテストを合格させるように最適化します。その最適化により、ルールがソースドキュメントの実際の記述から離れてしまうことがあります。承諾した後は、改善前の実行結果と精度スコアを比較してください。スコアの低下は逸脱のシグナルであり、やり直しを盲目的に繰り返すのではなく、拒否して反復すべき理由になります。テストが合格し、レポートの内容にも問題がなければ、番号付きバージョンを作成して変更を本番環境に昇格させます。 実際のユースケース これらのパターンは規制業界全体に当てはまります。人事制度の適用対象を判定するシナリオでは、従業員ハンドブックが毎年更新されます。Iterative Refinement が新しいドキュメントを取り込んでルールの変更を提案するため、人事チームは形式論理に触れることなくレビューできます。金融サービスでは、debtToIncomeRatio と DTI のような重複する変数が、顧客の多様な表現に対して変換のあいまいさを引き起こします。Ambiguous Variable Refinement はそれらを統合し、決定論的な検証を可能にします。臨床プロトコルが改訂された場合、ヘルスケアのコンプライアンスチームは新しいガイドラインをアップロードします。Iterative Refinement がルールの更新を提案し、チームは本番環境へ反映する前に提案を検証します。製造業の品質保証では、公差が時間とともに厳しくなります。チームはポリシーを反復的に改善しながら、バージョン管理されたスナップショットと Fidelity Report を通じて監査証跡を維持します。 まとめ 規制対象の領域に生成 AI を投入するチームは、隠れたコストを支払ってきました。それがポリシーのメンテナンスです。 ポリシーの自動改善は、変更を承認する権限をお客様に残したまま、必要な作業量を減らします。 ルールと言語の二分法。 論理が誤っている場合 (ルールが緩すぎる、厳しすぎる、または存在しない場合) は、 Iterative Refinement がソースドキュメントとフィードバックに基づいた形式論理の修正案を提示します。言語が誤っている場合 (変数の重複、あいまいな説明、一貫性のない形式) は、 Ambiguous Variable Refinement が、競合する解釈を 1 つにまとめる正確な変数定義を提案します。 承認ゲート。 どちらの場合も、システムが提案し、お客様が決定します。提案されたすべての変更は、差分 と 、保存済みのテストへの影響を示すレビュー画面に表示されます。明示的な承認がなければ、DRAFT ポリシーにも、まして本番環境にも変更は届きません。作業は自動化され、権限はお客様の手に残ります。 次のステップ テストを追加した自動推論ポリシーをまだお持ちでない場合は、まずソースドキュメントからポリシーを作成し、重要なシナリオをカバーするテストを追加してください。リンクについては、「 前提条件 」セクションを参照してください。ポリシーと少なくとも 1 つの失敗するテストが手元にあれば、今日のうちに失敗するテストを 1 つ選び、その検出結果を確認してみてください。変換が正しいのに結果が誤っている場合は、焦点を絞ったソースドキュメントを用意して Iterative Refinement を実行します。結果が TRANSLATION_AMBIGUOUS の場合は、 Ambiguous Variable Refinement を実行します。 提案を承諾し、再テストを行い、前後で Fidelity Report を比較してください。形式論理を 1 行も手で書くことなく、あいまいでない変換において最大 99% の精度で検証された、より緻密なポリシーが得られます (「 自動推論チェックを使用して、AI のハルシネーションを最小限に抑え、最大 99% の検証精度を実現: 今すぐご利用いただけます 」を参照してください)。 リソース 開始する: セットアップのガイダンスについては、「 自動推論チェックのドキュメント 」を参照してください。または、 Amazon Bedrock コンソール で既存のポリシーを開き、 [Refine policy] を選択してください。このサービスの詳細については、 Amazon Bedrock をご覧ください。 実践的なウォークスルー: 手順を追ったガイドについては、「 How to minimize generative AI hallucinations with Automated Reasoning checks 」を参照してください。 訳注: 上記の記事はプレビュー期間中 (2025 年 4 月) に公開されたものです。一般提供開始後の機能に基づいた手順は、日本語版ブログの「 Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1 」で確認できます。 回答を書き換えるチャットボット: チャットボットは、自動推論チェックのフィードバックを利用して回答を反復的に書き換え、証明可能に正しい回答に到達するまでユーザーに確認の質問を投げかけることができます。「 自動推論チェックで回答を書き換えてハルシネーションを抑えるチャットボットのリファレンス実装 」と、 GitHub のサンプルコード を参照してください。 ポリシー形式化エージェント: エージェントは、自動推論ポリシーを改善するプロセス全体を自然言語で対象分野の専門家に案内できます。そのようなエージェントの オープンソースサンプル を参照してください。 コードサンプル: GitHub の 自動推論チェックのサンプル をご覧ください。 お客様の成果: Amazon Logistics の導入事例 | PitCrew の導入事例 | PwC の教育分野における責任ある AI の導入事例 | AWS の責任ある AI に関するリソース Amazon Bedrock の機能に関する詳細情報: Amazon Bedrock Guardrails | Amazon Bedrock AgentCore 責任ある AI のガイダンス: AWS Well-Architected Responsible AI Lens 99% という精度の数値について 冒頭とまとめのセクションで引用している 99% という数値は、自然言語から形式論理への変換があいまいでない場合に、正しい検出結果 ( VALID 、 INVALID 、または SATISFIABLE ) が得られる割合を測定した検証精度を指します。この数値は一般提供開始のお知らせ「 自動推論チェックを使用して、AI のハルシネーションを最小限に抑え、最大 99% の検証精度を実現: 今すぐご利用いただけます 」(AWS News Blog、2025 年 8 月 6 日) で初めて公開されました。 著者について Nafi Diallo Nafi は Amazon Web Services の Senior Applied Scientist で、AI の安全性、自動推論、信頼できる AI ソリューションのためのガードレール実装を専門としています。Amazon Bedrock 上の生成 AI およびエージェンティックシステムの信頼性を評価し改善する分野で豊富な経験を持っています。また、AWS の Women in AI and ML (WAIML) 組織の北米地域リードも務め、チャプターの成長を支援しながら、地域全体で WAIML のミッションを推進しています。 Ferhat Erata Ferhat は AWS AI Labs の Applied Scientist で、大規模言語モデルと形式的推論を組み合わせたニューロシンボリックシステムを構築し、生成 AI およびエージェンティック AI を検証可能にする取り組みを行っています。その研究は AI の安全性とセキュリティ、自動形式化、検証済みコード生成にまたがり、検証器のフィードバックを用いて推論モデルを事後学習させ、出力を形式仕様に整合させています。Ferhat はイェール大学でコンピュータサイエンスの博士号を取得しており、NeurIPS、ICML、AAAI、ACL の査読者を務めています。 Fernando Galves Fernando は AWS の Senior Applied AI Architect で、金融サービスやその他の規制業界の企業が生成 AI およびエージェンティック AI を実験段階から本番環境へ移行できるよう支援しています。AI のセキュリティ、ガバナンス、評価を専門とし、お客様との取り組みは AWS のエージェンティック AI サービスのセキュリティ方針に直接反映されています。ソフトウェアエンジニアリング、サイバーセキュリティ、機械学習にわたる 25 年以上の経験を持ち、以前は大手銀行や小売企業で利用されるクラウドベースの生体認証および不正防止システムを構築していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。