OWN NEWS GATHER
← 戻る
AWS ML Blog

AWS、Amazon Bedrockの「自動推論チェック」にポリシー自動修正機能を導入　手動の調整サイクルを自動化

要点

  • AWSが、Amazon Bedrockにおける自動ポリシー修正エンジンの提供を開始した。

  • 従来は手動で繰り返されていたポリシーの「診断・編集・再テスト」の工程を自動化する。

  • 自動検証により失敗したテストを診断し、形式論理に基づいた修正案をユーザーに提示する。

  • 修正案の適用にはユーザーの承認が必要であり、意図しない書き換えを防ぐ。

  • ロジックに起因する問題と、言語の曖昧さに起因する問題の双方を解決する2つの修正モードを提供する。

  • アマゾン ウェブ サービス（AWS）は2026年8月3日、同社のAIサービス「Amazon Bedrock」において、ポリシー設定のデバッグ作業を効率化する「自動ポリシー修正機能（automatic policy refinement）」を発表した。本機能は、生成AIの出力制御などに用いられるポリシーの開発において、これまで開発者の負担となっていた手動によるテスト失敗の診断と修正のプロセスを自動化するものだという。

開発の摩擦となっていた手動プロセスを自動化

Amazon Bedrock Guardrails（生成AIアプリケーションで望ましくない入力や出力をフィルタリングし、安全性やポリシーへの適合性を担保するための制御機能）で利用できる「自動推論チェック（Automated Reasoning checks）」は、形式検証（数学的な手法を用いて、システムやプログラムが仕様通りに正しく動作するかを厳密に証明する技術）を用いてAIの回答の正確性を証明する技術である。AWSが過去に発表した内容によると、自然言語から形式論理への変換が明確に行われるケースにおいて、最大99%の検証精度を達成できると報告されている。

通常、自動推論チェックを利用する際には、元となるソース文書からポリシーを構築し、テストケースを用いてそのポリシーが正しく動作するかを検証する。しかし、この段階でテストが失敗した際、開発者はその原因を診断し、手動でポリシーを書き換え、再びテストを実行するというサイクルを何度も繰り返す必要があった。AWSによると、この手動によるポリシーの微調整プロセスが、開発者にとって最大の摩擦点（ボトルネック）になっていたという。

今回導入されたポリシー自動修正エンジンは、こうした手動の診断と修正の作業を自動化する。エンジンが失敗したテストを診断し、自動的に形式論理（数式や記号を用いて厳密に論理を構築する手法）に基づく修正案を生成して提示する。提示された修正は勝手に適用されるわけではなく、開発者がすべての変更内容を確認し、承認した上で適用する仕組みになっている。

ポリシーを検証する2段階のパイプライン

自動推論チェックは、まず入力された自然言語を形式論理に変換し、その後自動推論（論理法則に従ってコンピュータが自動的に結論を導き出す技術）の技術を適用して検証結果を導き出す。この検証結果には、「VALID（有効）」「INVALID（無効）」「SATISFIABLE（充足可能）」「IMPOSSIBLE（不可能）」「TRANSLATION_AMBIGUOUS（翻訳の曖昧性あり）」といった判定が含まれる。

AWSは、このチェック処理が「翻訳（translate）」と「検証（validate）」という2つのステップからなるパイプラインで実行されると説明している。

1つ目の翻訳ステップでは、ポリシー内に定義された変数の説明に基づいて、自然言語の入出力を具体的な変数割り当てへとマッピングする。2つ目の検証ステップでは、割り当てられた変数に対して、ポリシーの形式ルールを適用して妥当性を判断する。

開発者は、テストケース（入力および出力テキストと、期待する検証結果の組み合わせ）をポリシーに付与することで、ポリシー全体の動作をテストできる。テストは個別、あるいはバッチ（複数の処理をまとめて一括で実行する方式）で実行することが可能であり、テストが失敗した場合には、ポリシーのどの部分が開発者の意図と食い違っているかを特定できる仕組みになっている。

2つの失敗原因に対応する修正モード

テストの失敗が発生した際、その原因は「翻訳」と「検証」のどちらかのステップに存在する。新機能では、これら2つのステップにおける失敗に対応するため、以下の2つの修正モードが用意されている。

  • イテレーティブ・リファインメント（Iterative Refinement）：ルールの問題（論理的なエラー）を対象とするモード。
  • アンビギュアス・バリアブル・リファインメント（Ambiguous Variable Refinement）：言語の問題（変数の説明における曖昧さ）を対象とするモード。

これらのモードでは、ポリシー修正を開始し、処理状況をポーリング（一定間隔で問い合わせて状態を確認する処理）し、結果を取得するという一連のAPIワークフローが提供されるほか、コンソール画面から視覚的に実行できるワークフローも用意されている。

ポリシーの検証失敗には2つの主要なモードがあるが、そのうち「ルール問題」について、元記事は「翻訳ステップは正しく動作し、正しい変数に正しい値が割り当てられているが、検証結果が期待と一致しない状態」と定義している。これはポリシーに定義されたルールそのものに問題があるケースで、ルールが厳しすぎる、あるいは緩すぎる（too permissive, too restrictive）といった論理的な欠陥が原因になると説明されている。

元URL