Amazon AWS、Bedrockポリシー修復を自動化するも最終判断は人間に委ねる

Amazon AWSは、ソフトウェアにコンプライアンスロジックを書き換えさせることのリスクを踏まえつつ、Bedrock Automated Reasoningポリシー向けに2つの自動改善経路を追加した。このシステムは、失敗したテストを診断し、形式的なルール修正案を提示し、曖昧な言語表現の変換精度を高められる。ただし、提案された変更が有効になるのは、人間がレビューして受け入れた後に限られる。

この承認の境界こそ、今回の発表で最も重要な点だ。Amazon Bedrockは、これまで専門家が変数、ルール、型、テスト結果を手作業で確認していた診断作業を、より多く担えるようになった。AWSが自動化するのは修復案の作成であり、ポリシーの所有権を不透明な最適化ループへ移すことではない。

この動きは、スプレッドシート、プロンプトベースのチェック、あるいは専門家による形式表現の手編集に依存する、手作業のルール作成ワークフローに圧力をかける。また、Automated Reasoningが掲げるより大きな約束も試される。つまり、企業はすべてのポリシー更新を形式手法のプロジェクトに変えることなく、通常のモデル評価より強力な保証を得られるという約束だ。

Amazon AWSがBedrockポリシー改善で変更したこと

新しいワークフローでは、失敗したポリシーテストから、診断結果だけで終わらせず、レビュー可能な修復案を作成する。

Automated Reasoningポリシーは、対象分野の要件を変数、カスタム型、論理ルールとして表現する。Bedrockはこの形式定義を用いて、AIが生成した主張がエンコードされた要件に従うかを検証する。これは、別の確率モデルで品質を推定するモデルベースの採点器とは異なる。

AWSは2024年のre:InventでAutomated Reasoningチェックをプレビュー公開した。その後、このサービスはテスト管理、シナリオ生成、ドキュメント処理の拡張を備えて一般提供に至った。AWSによれば、そのreasoning checksは最大120,000トークン、すなわちおよそ100ページのソース資料を処理できる。

今回の改善機能は、チームがポリシーが意図どおりに動作していないことを発見した後の対応を扱う。形式ルールに条件が欠けているためにテストが失敗する場合がある。また、Bedrockが通常の言語を誤った変数に対応付けたり、複数のもっともらしい変換を見つけたりすることでも失敗しうる。

これらは異なる失敗分類であるため、AWSは2つの改善経路を提供する。

• ルール改善は、ポリシーの形式的構造を対象とする。ルール、変数、カスタム型の追加、更新、削除を提案できる。

• 言語改善は、曖昧または不正確な説明を対象とする。後続の変換で言語をポリシー概念へより一貫して対応付けられるよう、変数の説明や型定義を修正できる。

どちらの経路も、アクティブな定義を即座に上書きするのではなく、変更案を生成する。コンソールでは、ユーザーは結果を受け入れる前にレビュー画面へ進む。APIでは、アプリケーションが生成済みのポリシー定義を取得し、その後にドラフトを明示的に更新する。

この分離は重要だ。構文的に有効な修復でも、誤った事業判断をエンコードしている可能性がある。従業員福利厚生のポリシーは、誤った勤続期間のしきい値を適用していても正しくコンパイルできる。金融ポリシーでは、意図的な例外を表す競合を、見かけ上の競合として除去してしまう可能性がある。

したがって、この発表が変えるのは作成時のボトルネックであって、説明責任のモデルではない。Bedrockは失敗を調査し、修復案を下書きできる。提案されたロジックが権威あるソースと一致するかを最終的に判断するのは、依然としてドメイン所有者だ。

AWSは、SCHEDULED、PREPROCESSING、BUILDING、TESTING、COMPLETED、FAILEDを含む複数のワークフロー状態を文書化している。返されるワークフロー識別子により、クライアントは結果アセットを要求する前に、この非同期プロセスを監視できる。

このサービスは、ビルド後に品質レポートも生成する。このレポートは、曖昧な説明、分断されたルールグループ、未使用の変数、矛盾する関係など、構造上の問題を特定できる。こうしたシグナルは、チームが局所的なテスト失敗と、より広範なモデリング上の欠陥を区別する助けとなる。

これにより、より完全なループが生まれる。ソースドキュメントをエンコードし、テストを実行し、失敗を調べ、修復を要求し、提案された定義をレビューし、スイートを再実行する。このループは以前から存在していたが、その診断と変換作業の多くがBedrock内に組み込まれるようになった。

ルール改善はテストフィードバックを形式的な変更へ変換する

ルール改善は、主張が合格か不合格かを決めるロジックを変更できるため、より重大なモードである。

従業員の休暇ポリシーを考えてみよう。ソースドキュメントには、フルタイム従業員は勤続期間が12か月を超えて初めて育児休暇の対象となるとある。しかし、生成されたポリシーには次の式が含まれている。

このルールには勤続期間が含まれていない。新たに採用されたフルタイム従業員を扱うテストは、期待結果が不承認であるにもかかわらず、承認を返すことになる。この失敗は言語だけの問題ではない。形式モデルには、関連する変数と必須条件の両方が欠けている。

AWSはアノテーションを、ポリシー要素に付加される対象を絞った修正として説明している。サポートされる操作には、変数、ルール、カスタム型の追加、更新、削除が含まれる。ユーザーはaddRuleFromNaturalLanguageを通じてルールを平易な英語で送信することもでき、Bedrockがそれを形式論理へ変換する。

修正後の定義では、tenureMonthsという整数変数を追加し、元の式を次のように置き換えることが考えられる。

コンソールのワークフローは、ポリシーのテストスイート内から始まる。

1. Amazon BedrockコンソールでAutomated Reasoningポリシーを開く。

2. 失敗したテストを選び、その検出結果を確認する。

3. 前提、主張、期待結果が意図したシナリオを表していることを確認する。

4. テスト自体が不完全であれば、テスト条件を修正する。

5. テストを再実行し、修正したシナリオが期待する挙動を表現していることを確認する。

6. アノテーションの適用またはポリシー改善を選択する。

7. Bedrockにテストフィードバックからポリシービルドワークフローを開始させる。

8. ルール、変数、型に対するすべての変更案をレビューする。

9. ソースポリシーと一致する場合にのみ変更を受け入れる。

10. 保存済みテストと生成済みシナリオを、修正後のドラフトに対して再実行する。

3番目と4番目の手順には注意が必要だ。失敗したテストが、常にポリシーが誤っていることを証明するわけではない。テストに必要な前提が欠けている、期待結果が不正確である、あるいは主張の表現が意味を変えている可能性がある。

そのためAWSは、アノテーションを適用する前に検出結果を確認することを推奨している。同社の改善ガイダンスでは、適切な場合はまずテストを修正して再実行するよう利用者に案内している。修正後のテストで期待結果が得られれば、そのフィードバックは対象を絞ったアノテーションを支えられる。

APIでは、同じ機能がStartAutomatedReasoningPolicyBuildWorkflowを通じて提供される。ルール修復にはREFINE_POLICYワークフロータイプを使用する。リクエストには、変更する要素だけでなく、現在の完全なポリシー定義を含める必要がある。

簡略化したAWS CLIリクエストは次のようになる。

本番用リクエストでは、空の配列を完全なドラフト定義に置き換える。ポリシースキーマのバージョンは1.0でなければならず、これはリソースのDRAFTまたは番号付きポリシーバージョンとは別のものだ。

成功時のレスポンスには2つの値が含まれる。

アプリケーションはGetAutomatedReasoningPolicyBuildWorkflowでワークフローをポーリングするか、リスト操作でワークフローを確認できる。処理が完了すると、GetAutomatedReasoningPolicyBuildWorkflowResultAssetsを通じて生成されたポリシー定義を取得する。

一般的な取得コマンドは、次のパターンに従う。

取得しただけでは、提案された定義が正式なものになるわけではない。クライアントは結果を現在のドラフトと比較し、権限を持つレビュー担当者に差分を提示し、関連するテストを再実行すべきである。

承認後、クライアントはレビュー済みの定義を用いてUpdateAutomatedReasoningPolicyを呼び出せる。この明示的な更新は、コンソールで変更を受け入れることに相当するAPI操作だ。

このワークフローは、ポリシー全体を無差別に置き換えるよりも精密な操作をサポートする。変数アノテーションにはaddVariable、updateVariable、deleteVariableが含まれる。ルールアノテーションにはaddRule、updateRule、deleteRule、addRuleFromNaturalLanguageが含まれる。

カスタム型の操作は、追加、更新、削除を網羅する。updateFromRulesFeedbackやupdateFromScenarioFeedbackなどのフィードバックアノテーションにより、ユーザーはルールまたはシナリオがどのように誤って動作したかを説明できる。

この幅広さは有用だが、レビューの負担も増やす。重複した変数を削除すれば、変換の一貫性を改善できる。似て見えるルールを削除すると、意図的な例外まで消してしまう可能性もある。生成された式がBedrockの構造チェックに合格していても、すべての提案には意味的なレビューが必要だ。

言語改善は曖昧さがソルバーに届く前に解消する

言語改善は、通常の文が形式的な前提や主張へ変わる境界を対象とする。そこはしばしば、ポリシー失敗の最も見えにくい原因となる。

形式論理が評価できるのは、そこに与えられた概念だけだ。その評価が行われる前に、Bedrockはユーザーの入力とAIの応答を、ポリシーで定義された変数に変換する必要がある。

曖昧な説明は、この変換ステップを弱める。たとえば、ポリシーにtenureMonthsとmonthsOfServiceがあり、説明がほぼ同じだとする。「彼女はここで2年間働いている」という文は、どちらの変数にも対応付けられる可能性がある。

基礎となるルール自体は正しいかもしれないが、それでもテストはTRANSLATION_AMBIGUOUSを返すことがある。この結果は、システムが複数のもっともらしい形式的解釈を見つけたことを意味する。主張が有効か無効かを意味するものではない。

言語改善は、こうした重複を変数の説明とカスタム型から調査する。曖昧さを減らすために、より明確な表現、概念の統合、またはその他の定義変更を提案する。その目的は文体上の推敲ではない。自然言語と形式スキーマの間の、より安定した対応付けだ。

コンソールのワークフローは、対象を絞ったルール修復より短い。

1. BedrockコンソールでAutomated Reasoningポリシーを開く。

2. Definitionsページへ移動する。

3. 品質レポートの警告を確認する。

4. Resolve ambiguitiesを選択する。

5. Bedrockが変数の説明と型定義を分析するまで待つ。

6. 提案された言語変更をレビューする。

7. 各提案を元のソースドキュメントと比較する。

8. 意図した意味を維持する変更だけを受け入れる。

9. 多様な表現や境界条件を含むテストを再実行する。

APIでは同じビルドワークフローエンドポイントを使用するが、ワークフロータイプはRESOLVE_POLICY_AMBIGUITIESとなる。リクエストには完全な現在の定義を含める。

その後、クライアントはワークフローを監視し、POLICY_DEFINITIONアセットタイプで提案された定義を取得する。また、QUALITY_REPORTアセットを取得し、どの構造上の問題が推奨のきっかけになったかを把握することもできる。

ビルドワークフローAPIでは、ワークフローコンテンツをユニオンとして扱う。リクエストに含められるのは、サポートされるコンテンツメンバーのうち1つだけだ。クライアントは、曖昧さ解消用コンテンツを別のワークフローペイロードと組み合わせ、両方の操作が同時に実行されることを期待すべきではない。

言語の改良は、ITERATIVELY_REFINE_POLICY とは異なります。反復的な改良ワークフローでは、既存のポリシーを改善するためにソース文書と任意の自然言語フィードバックを使用します。これは、権威ある文書が変更された場合や、ユーザーがより広範な改良の方向性を示したい場合に適しています。

たとえば、改訂された従業員ハンドブックで勤続年数の要件を緩和し、忌引休暇を追加する場合があります。クライアントは、完全な現行定義、更新後の文書、および変更内容を説明するフィードバックを提供できます。

簡略化したリクエストは、次の構造を使用します。

AWSはこの操作をINGEST_CONTENTと区別しています。反復的な改良では、既存の定義を改善するためのコンテキストとして文書を使用します。インジェストは新しい資料から新たなルールを抽出し、既存のポリシーへ統合できます。

この区別により、よくある実装上の誤りを防げます。新しいハンドブックの章は通常、インジェストを通じて取り込むべきです。既存のロジックを修正することを目的とした改訂済みの章は、反復的な改良に属します。

言語の修正は、引き続き複数の言い回しでテストする必要があります。改訂された説明がある曖昧さを解消する一方で、別の曖昧さを生み出すこともあります。チームは、同義語、省略語、否定表現、判断の境界に近い値を含めるべきです。

ソース条項、テスト証拠、承認済み改訂の検索可能な記録も、定義が変更された理由をレビュー担当者が再構築するのに役立ちます。エンジニアリングチームは、ポリシー上の判断とその裏付け文書を分けるのではなく、技術ナレッジベースでその証拠を整理できます。

人による承認は制約ではなく機能である

自動診断は形式的ポリシーの保守コストを下げるが、承認ゲートは最適化の誤りが組織のルールになることを防ぐ。

形式検証は、ときに数学的確実性として説明されます。この表現には境界が必要です。エンジンは、受け取った形式的ポリシーについて厳密に推論できます。しかし、そのポリシーが法令、臨床ガイダンス、契約、または内部手順を完全に表現していることまでは保証できません。

これは古典的な仕様問題です。ソルバーは、欠陥のあるルールに従って出力が導かれることを正しく判断できます。数学が検証するのはモデルとの整合性であり、モデルの前提となる情報源の真実性ではありません。

自動改良によって、この制約がなくなるわけではありません。二つの変数が重複していること、ルールセットが分断されていること、失敗したテストが条件の欠落を示していることは発見できます。しかし、どの解釈が組織の正当なポリシーを反映するかを独立して決定することはできません。

そのため、人によるレビュー画面には三つの役割があります。

第一に、変更管理を実現します。レビュー担当者は、Bedrockが条件の追加、ルールの削除、変数名の変更、型定義の変更のいずれを提案しているかを確認できます。

第二に、ドメインの責任所在を維持します。エンジニアは構文やワークフローの動作を検証でき、弁護士、臨床医、コンプライアンス担当者、またはポリシー所有者は意味を検証します。

第三に、監査証跡を支えます。チームは、失敗したテスト、提案された注釈、承認済みの定義、その後のテスト結果を、ポリシー変更の理由を示す証拠として保持できます。

AWS自身のドキュメントも、生成されたポリシー情報について人によるレビューを推奨しています。自然言語文書からの抽出は非決定的であるため、別々の実行ではルール、変数、型に差異が生じる可能性があります。

最も安全な運用モデルでは、少なくとも四つの統制を用います。

• 意味上の変更については、指名されたポリシー所有者による承認を必須にする。

• 提案された定義を、現行バージョンとソース条項の両方と比較する。

• 改良を引き起こしたテストだけでなく、完全な回帰スイートを再実行する。

• レビューとテストの完了後にのみ、番号付きのポリシーバージョンを公開する。

アプリケーションは、ワークフロー開始時に冪等性トークンも使用すべきです。任意のclientRequestTokenにより、同じトークンを再利用する場合に、再試行によって重複した操作が作成されるのを防げます。

ワークフローの制限にも計画が必要です。AWSのドキュメントでは、ポリシーは最大二つのビルドワークフローをサポートし、同時に進行できるワークフローは一つだけとされています。クライアントは、別のビルドを開始する前に古いワークフローを削除する必要がある場合があります。

ポリシー定義には機密性の高いビジネスロジックが含まれる可能性があるため、暗号化とアクセス制御も引き続き重要です。Bedrockは顧客管理のAWS KMSキーをサポートしていますが、呼び出し元のIDとキーポリシーには、必要な復号、記述、データキーの権限が付与されていなければなりません。

これらの保護策は、通常の意味でポリシー保守を自動化するものではありません。これは監督された自動化です。システムが分析を実行して候補アーティファクトを生成する一方で、人が状態変更を管理します。

このモデルは、自己変更型のガードレールよりも擁護しやすいものです。本番障害によってそれを検出したルールが自動的に緩和されるなら、攻撃者は細工した入力や誤解を招くフィードバックを通じてポリシーに影響を及ぼせる可能性があります。

レビューゲートはその経路を遮断します。また、テストの合格率を上げる代わりに、形式的ポリシーのソースへの忠実性を下げる修正をチームが却下することも可能にします。

懐疑的に問うべきなのは、組織がレビューを真の統制として扱うのか、それとも定型的な確認画面として扱うのかです。特にレビュー担当者に形式表現を読む経験が不足している場合、自動提案は自動化バイアスを生み出す可能性があります。

チームは、提案された変更を複数の形式で提示すべきです。すなわち、形式表現、平易な言葉による説明、ソース条項、影響を受けるテストシナリオです。その文脈なしに緑色の承認ボタンだけを置いても、ボトルネックを解決するのではなく移すだけです。

論理を書くことから変更を統治することへ、重心が移る

Amazon AWSは形式的ポリシーの修正をより利用しやすくしているが、組織はいま、変化のスピード向上に見合うレビュー慣行を構築しなければならない。

直接の競合は、特定のクラウドプラットフォームやモデルベンダーではありません。多くのガバナンスチームが使う手作業の方法です。ルールを手で書き、失敗したケースを個別に調べ、少数の専門家に形式モデルの修正を依存する方法です。

プロンプトベースのガードレールは別の方法を提供します。モデルにポリシーに従うよう指示したり、二つ目のモデルにコンプライアンスを判定させたりできます。こうした方法は始めやすい一方で、判断は依然として確率的であり、表現やモデルのバージョンによって変動する可能性があります。

Automated Reasoningは、明示的な変数と制約を使用します。この構造は、反例、充足可能性分析、監査可能な検出結果を支えます。また、忠実な仕様を必要とするため、セットアップと保守の作業は増えます。

改良はその保守コストを対象にします。Bedrockがテストフィードバックを狭い範囲でレビュー可能なパッチへ確実に変換できるなら、ドメイン専門家は通常のポリシー言語をソルバー表現へ翻訳する時間を減らせます。

AWSの顧客事例として報告されたものは、意図された成果を示しています。金融サービスプロバイダーのPitCrewは、40件のAutomated Reasoningポリシーをエンコードし、三つの本番エージェントでそれらの組み合わせを使用していると述べています。そのコンプライアンスワークフローは、マーケティング資料と規制書式を形式的制約に照らして確認します。

同社によると、あるレビュー工程は2週間から30分に短縮されました。従来は3日間のキューに入っていたマーケティングおよびソーシャルコンテンツは、30秒で処理されると報告されています。これらは特定の実装に基づく顧客報告の結果であり、一般的な性能保証ではありません。

このユースケースは、改良が重要である理由を示しています。規制資料は変化し、顧客ポリシーには違いがあり、デプロイ後にはエッジケースが現れます。効率的に修正できないポリシーは、古くなるか、形式システムの外に手作業の例外を蓄積することになります。

ただし、修正の高速化はポリシー変更の頻度を高める可能性もあります。チームは、各変更が他のルールグループに与える影響を確認せずに、局所的な修正を頻繁に受け入れるかもしれません。時間が経つと、定義は内部的には整合していても、人間には理解しにくくなる可能性があります。

品質レポートは、分断されたルールセット、競合する要素、曖昧な説明を特定する助けになります。バージョン管理の規律や回帰テストに代わるものではありません。

この機能を評価する組織は、受け入れた提案の数以上を測定すべきです。有用な指標には次のものがあります。

• 修正なしで受け入れられた提案変更の割合。

• 意図した意味を変えてしまうため却下された割合。

• 受け入れた修正によって生じた回帰失敗。

• 現実的なユーザー表現における翻訳の曖昧さ。

• テスト失敗からレビュー済みポリシー更新までの時間。

• ドメイン所有者による承認とエンジニアによる承認の差異。

これらの指標は、改良が専門家の作業を減らすのか、それとも単にレビューへ移すだけなのかを明らかにします。また、エンジンがもっともらしいが意味論的には誤った変更を繰り返し提案するケースも明らかにします。

この機能は、ルールに権威ある情報源があり、判断に説明が必要な規制対象アプリケーションに特に関連するはずです。医療の適格性、金融開示、従業員福利厚生、保険補償、契約要件は、このパターンに当てはまります。

「役に立つこと」や「魅力的なコピーを書くこと」といった広範な好みには、あまり適していません。こうした目標には、形式評価に必要な正確な変数や制約が欠けています。

主要なトレードオフは、依然として能力とガバナンスの間にあります。自動修正は、より多くの人がポリシー開発に参加できるようにします。同時に、レビュー担当者がその結果を十分に追跡せずに承認する可能性のある変更数も増やします。

Amazon AWSが改良を自動化した後に注目すべきこと

次の試金石は、ポリシーが制御された例を超えて拡大したときにも、Bedrockの提案が狭い範囲に留まり、説明可能で、忠実であり続けるかどうかである。

最初のシグナルは、実運用における受け入れ品質です。AWSは、ドメイン専門家が提案された修正を変更なしで受け入れる頻度、修正する頻度、却下する頻度を示すべきです。安定した回帰結果を伴う高い受け入れ率は、改良が形式的なオーサリング作業を減らすという主張を裏付けるでしょう。

高い却下率は、診断は有用でも、意味論的な修正は依然として専門家の仕事であることを示唆します。レビュー担当者は悪い提案を承認し得るため、受け入れだけでは不十分です。結果には回帰と、その後の本番での検出結果も含める必要があります。

二つ目のシグナルは、大規模で相互接続されたポリシーからの証拠です。公開された例では、休暇の適格性や病院のリスク評価といった理解しやすいルールが使われています。企業の定義には、例外、相互参照、カスタム型、多くのセクションにまたがって相互作用する要件が含まれる場合があります。

一つの失敗シナリオを修正すると、離れた複数のルールの結果が変わる可能性があります。テストでは、エンジンがそのより広い影響を特定できるか、またレビューインターフェースがその影響を可視化できるかを明らかにすべきです。

三つ目のシグナルは、AWSが統合とガバナンスをどのように拡張するかです。有用な追加機能には、より豊富なポリシー差分、承認ロール、必須レビュー担当者、ソース条項のトレーサビリティ、承認済みの変更と影響を受けるテストとのより明確な関連付けが含まれます。

クロスアカウントのガバナンスにも注意が必要です。AWSはBedrockの一元的な保護機能を拡張してきましたが、一部のクロスアカウント実施シナリオにおけるAutomated Reasoningチェックについて、制約を文書化しています。大規模組織がこれらのポリシーをチーム間で一貫して統治できるかは、より広範なサポートによって決まるでしょう。

開発者にとって、直近の行動は実務的です。一つの範囲が限定されたポリシーから始め、権威ある文書を保存し、想定される承認、拒否、曖昧さ、エッジ条件についてテストを作成します。テスト自体が正しいことを確認してから、ルールの改良をトリガーしてください。

そして、すべての提案をコード生成の利便性ではなく、ポリシー上の判断としてレビューしてください。ポリシー定義と品質レポートを取得し、現行ドラフトと比較し、完全なスイートを再実行して、承認済みの結果をバージョン管理します。

エンタープライズの購入担当者は、変更を誰が承認し、却下された提案がどのように記録されるのかを確認すべきです。レビュー担当者が、正式な差分、平易な言葉による説明、根拠となるソース、回帰への影響をまとめて確認できるかも尋ねてください。

Amazon AWSは、障害から修正候補に至るまでの道のりを短縮しました。より難しい問いは組織面にあります。Bedrockが現在生成できるほど慎重に、あなたのチームは正式なポリシー変更をレビューできるでしょうか。