AI policy regression testing-as-code

revision_id: EA-730-RESEARCH-20261027-R1 evidence_as_of: 2026-10-27 JST status: RESEARCH_COMPLETE / INDEPENDENT_REVIEW_PENDING

AI policy regression testing-as-codeは、AIのツール権限、送信先、モデル経路、承認要件、情報保護などを決める方針について、入力と期待する判断を実行可能な試験データとして保存し、変更のたびに意図しない許可・拒否を検出する運用です。自然言語の注意書きを読み比べるだけでなく、実際の強制点へ渡す入力、判断結果、判断後に許される動作を検証対象にします。

対象は方針エンジンに限りません。プロンプトの指示、アプリケーションの条件分岐、ゲートウェイ、ツール実行直前の認可など、強制点が複数あればそれぞれを検証します。ただし、モデルが「許可しません」と回答したことと、外部APIの実行が拒否されたことは別です。生成文の評価だけでツール権限の回帰試験を代替しません。

OPAの公式Policy Testing資料[S1]では、Regoの試験規則を実行し、入力やデータを差し替え、成功・失敗・エラーやカバレッジを確認できます。また、試験が一つも実行されない場合を失敗にする選択肢があります。試験結果が成功でも、対象を取り違えて空実行していないかを別途確認する必要がある具体例です。

Cedarの認可資料[S2]は、適合するforbidがpermitより優先すること、どの規則も許可しなければ拒否すること、評価エラーを起こした規則は判断から除外されることを説明しています。したがって「エラーが一つでも起きれば必ず全体が拒否される」という想定は成立しません。判断結果と診断情報を併せて検証する必要があります。

Cedarのschema validation資料[S3]は、型や名前の不整合を事前に検出する仕組みと、schema変更によって以前の方針が無効になり得ることを説明します。静的検証は業務上の許可判断が正しいことの証明ではありません。以下は、これらの機能と制約を踏まえた運用設計の提案です。全エンジンがCedarと同じエラー処理をするという主張ではありません。

一つの試験には、主体、対象、操作、認証済みtenant、依頼目的、情報分類、要求時点、承認記録など、判断に必要な属性を含めます。AIが生成したtenant名や「承認済み」という文を、そのまま信頼済み属性に変換してはなりません。どの属性を認証層、資産台帳、承認システムから取得するかも試験条件にします。

試験データ、方針、schema、属性変換器、エンジン版、組織データの版を対応付けます。方針のファイルだけ固定しても、部署階層やラベル変換が変われば判断が変わり得ます。秘密や実際の顧客記録は模擬値へ置き換え、型、所属関係、欠損状態など、判断に意味のある構造を保持します。

期待値は単純なallow/denyだけで足りないことがあります。承認要求、特定モデルへの経路、マスキング義務、許可された操作範囲、有効期限、診断エラーの有無を含めます。エンジンが二値判断しか返さない場合は、承認等をアプリケーション側の別条件として試験します。存在しないエンジン機能を仮定しません。

次は送信ツールを持つ業務エージェントの設計例で、特定組織へ適用済みの方針ではありません。

否定試験は、正例から一属性だけを変えた対にすると、どの境界を検証しているか明瞭になります。さらに、明示拒否と許可が重なる条件、複数tenantへの所属、空の属性、期限境界、承認者と依頼者の同一性などを追加します。試験名だけで安全性を宣言せず、何を変えて何が拒否されるべきかを記録します。

単体試験では、方針が与えられた属性から期待する判断を返すかを確認します。結合試験では、実アプリケーションが正しい属性を渡し、判断結果に従って実行を止めるかを確認します。モックが常に正しいtenantや承認状態を返す試験だけでは、属性変換器の不具合を見落とします。

副作用のあるツールは隔離先や模擬ツールを使用し、拒否条件で呼び出し回数が0であることを確認します。書き込みAPIの直前にも認可がある設計なら、計画作成時の判断だけで終えず、実行時に権限が変わる条件を含めます。キューに積まれた作業、再試行、手動再開、モデル変更時のfallbackも同じ強制点を通るかを確かめます。

モデルに依存する情報分類や目的推定は、決定的な方針試験と分けて評価します。分類器の出力を固定した試験は方針側の正しさを調べるもので、分類器自身の精度は証明しません。逆に、分類器の評価が高くても、受け取ったラベルをアプリケーションが誤解すれば強制は失敗します。両者の境界を一つの総合点で隠さないことが重要です。

変更時は構文・schema検証、決定的な判断試験、強制点の結合試験、変更前後の差分判定の順に進めます。実行した試験数、対象ファイル、エンジン版を記録し、空実行や対象除外で成功した状態を防ぎます。方針、schema、属性データ、アプリケーションのどれが変わった場合も、関連する試験を再実行するよう依存関係を持たせます。

変更前後で判断が変わる入力には、期待した変更かを責任者が確認します。旧判断との一致だけを合格条件にすると、従来の過剰許可まで保存してしまいます。業務要件を変える変更では、変更理由、影響範囲、更新した期待値、承認を一緒に残し、テストを通すためだけに期待値を出力へ追従させません。

緊急変更でも、実行可能な最小の否定試験と変更証跡を残します。通常のCI全体が使えない場合の代替手順は別途定めますが、未試験を成功と読み替えません。復旧後には実効版と試験済み版を照合し、緊急経路が通常の統制を恒久的に迂回していないかを確認します。

多数の試験や高い行カバレッジでも、全入力、全権限関係、全実行経路の網羅は証明できません。特に誤った期待値を大量に複製した試験は、同じ誤りを繰り返し確認するだけです。業務責任者による期待値の独立確認、事故や拒否ログからの追加fixture、属性の組合せを変える試験が必要です。

実行ログの再生は有用ですが、ログに残っていない拒否要求や低頻度の重要操作が欠けることがあります。また、過去の属性や時刻を再構成できなければ結果が異なる理由を判断できません。収集範囲と再生可能性を記録し、ログ再生を唯一の根拠にしません。

本番では判断の失敗率、診断エラー、拒否後の下流実行、期限切れ承認の使用などを監視します。試験成功は実効方針の配備成功ではないため、配備後に版と強制点の動作を確認します。監視が見つけた事象は、個人情報を除去した最小再現fixtureへ変換し、次の変更で同じ問題を検出できる形にします。

• 対象組織の強制点、方針言語、属性の信頼源、承認契約、失効時間、許容する拒否・誤許可は未確認です。
• OPA/Cedarの実行、fixtureの実動試験、CI組込み、配備後の拒否確認は本RUNではNOT_RUNです。本文の表は受入試験の提案であり実測結果ではありません。
• SAFE_WORDINGは「定義した入力と強制点について、期待する判断および副作用の回帰を検出する」です。「テスト成功で全AI行動が安全」「エラーは必ず全体拒否」「高いカバレッジで全境界を証明」とは記述しません。

[S1] Open Policy Agent, Policy Testing, https://www.openpolicyagent.org/docs/policy-testing 。2026-10-27 JST確認。Getting Started、Failing on No Tests Run、Data and Function Mocking、Coverage。製品の試験機能と範囲の根拠です。

[S2] Cedar Policy Language Reference Guide, How Cedar authorization works, https://docs.cedarpolicy.com/auth/authorization.html 。同日確認。Request authorization / Algorithm / Discussion。判断の優先関係とエラー処理の根拠です。

[S3] Cedar Policy Language Reference Guide, Cedar policy validation against schema, https://docs.cedarpolicy.com/policies/validation.html 。同日確認。schema変更と検証の限界の根拠です。

統合台帳EA_MASTER!731の正規topicを維持しました。原案はGoogle Doc 1_9XrDkXlopnx39HlRa1YDO8yRvOEBXup2vvY6senU7s、EA-730見出しt.0:208244で、採集済・検討未着手という旧記録です。今回、改訂台帳の全キー範囲と既存SOURCE_EA_RELATIONの対象キーを確認し、先行する正式改訂・接続行を確認できませんでした。所在確認自体を既存の完成研究とせず、上記一次資料を取得して本稿を作成しました。