shirokuronoir

AIルールを曖昧にしない4条件

AIルールを曖昧にしない4条件

AWSは2026年8月20日、Amazon Bedrock AgentCoreのPolicy Authoringを拡張し、自然文から時間・順序・累積上限を扱うDogwoodポリシーを生成できると発表しました。社内規程を形式ポリシーへ移しやすくなる一方、曖昧な規程を入力すると、文法的に正しくても意図と違う境界ができる可能性があります。

公式ブログとAgentCoreの公式ドキュメントを照合し、変換前に書き直すべき自然文ルールを6ケースで確認しました。

先に結論

自然文から生成されたポリシーは、主体と対象操作、時間窓、閾値の境界、試行か結果かの4条件を人が確認してから適用します。

Policy Authoringはルールの設計者ではなく、既に決めたルールを形式言語へ移す翻訳者として使うのが安全です。背景説明や目的を混ぜず、1文1ルールに分け、生成後は原文と並べて意図を照合してください。

AWSの一次情報で確認したこと

AWS公式ブログ「Authoring Dogwood policies from natural language in Amazon Bedrock AgentCore」では、Policy Authoringが自然文の規程をDogwoodへ変換し、ツール引数、前提となる操作、累積上限、レート制限、自由文の内容検査を扱えると説明されています。

入力には規程文だけでなく、MCPツールの名前、引数、戻り値を示すスキーマも使われます。生成結果が実際のツール名を参照できる一方、AWSは、変換前に規程から背景や解説を除き、ルールだけへ整理することを勧めています。

Policy in Amazon Bedrock AgentCoreでは、ポリシーをエージェントのコード外側で評価し、ツール実行前に決定的な許可・拒否を行う境界として説明しています。自然文から生成した候補はスキーマ検証と自動分析を受けますが、過剰許可、過剰拒否、成立しない条件の検出は、業務上の意図まで保証するものではありません。

ポリシー生成の検証手順では、生成された各ポリシーを個別にスキーマ検証し、分析結果を取得する流れが示されています。つまり「生成に成功した」と「適用してよい」は別の状態です。

時間ベースのポリシーはUTCで評価され、ローカル時刻の自動変換を行いません。営業時間を日本時間で書く場合も、実際に評価されるUTCへ変換した境界を確認する必要があります。

今回試したこと

AWSアカウントや実データは使わず、6件の架空ルールへ事前チェックを適用しました。必要な項目が揃ったものをPASS、生成前に書き直すものをREWRITEとしています。

| 自然文ルール | 判定 | 確認結果 |

|—|—|—|

| 各利用者のrefund呼び出しは1時間3回まで | PASS | 主体、操作、時間窓、許可する上限、試行回数が明確 |

| 本人確認が成功した後だけtransferを実行 | PASS | 前提操作と成功結果、後続操作の順序が明確 |

| 各口座の送金成功額を24時間で合計10万円以下 | PASS | 集計対象、成功結果、窓、累積上限が明確 |

| 短時間に多すぎる返金を止める | REWRITE | 短時間と多すぎるの数値、誰単位かが不明 |

| 3回を超えたら止める | REWRITE | 対象操作、集計主体、時間窓、試行か成功かが不明 |

| 不適切な文章を拒否する | REWRITE | 使用する内容検査、判定閾値、対象引数が不明 |

結果はPASSが3件、REWRITEが3件でした。これはAgentCoreの実サービス検証ではなく、生成前の規程文から解釈の分岐を減らせるかを確認したローカルの事前判定です。

変換前に確認する4条件

1. 主体と対象操作を名前で書く

「3回まで」では、利用者単位、口座単位、セッション単位のどれか分かりません。誰の何を数えるのか、実際のツール名と引数名へ対応できる形で書きます。

2. 時間窓とタイムゾーンを固定する

「短時間」「営業時間内」は数値へ変換できません。直近60分、UTC 00:00から24:00など、開始・終了とタイムゾーンを明記します。日本時間の営業時間を使う場合は、日付をまたぐUTC変換もテストします。

3. 閾値と境界を分ける

「3回を超えたら拒否」と「3回以上で拒否」では、3回目の扱いが違います。許可する最大値、拒否が始まる値、金額なら通貨と合計方法まで書きます。

4. 試行・成功・前提条件を区別する

失敗した呼び出しも回数へ含めるのか、成功額だけを累積するのかで制御結果が変わります。順序制御では、前提操作を呼んだ事実ではなく、成功結果が必要かを明記します。自由文を判定する場合は、検査名と閾値も固定します。

今日から行う3つのアクション

1. 既存規程から背景、理由、例外説明を外し、1文1ルールの表へ分解する

2. 各行へ主体、操作、時間窓、閾値境界、試行・成功の列を追加し、空欄を埋める

3. 生成ポリシーを原文と並べ、境界値の直前・一致・直後を架空データでテストしてから適用する

AIにツール実行を許すときは、モデル自身へルール順守を頼むだけでは不十分です。「AI決済を任せる前の5つの制御」で整理した予算、期限、承認、監査ログと同じく、実行前の外部境界で止めます。

判断基準

適用可否は「形式ポリシーが生成できたか」ではなく、境界値で原文どおり許可・拒否されるかで決めます。スキーマ検証が通っても、4条件のどれかを複数解釈できるならREWRITEへ戻してください。

関連記事

出典

執筆・検証: しろのあ。AWS一次情報、架空ルールで行った事前判定、実サービスで未検証の部分を分けて記載しています。