AIに「越えてはいけない線」を引く仕組み、『Policy as Code』――賢さより大事なのは"守らせる力"

1. 導入：AIは賢くなった。でも、任せるのは怖い。

エージェント型AIの進化には目を見張るものがあります。

調査もする。コードも書く。メールも送る。データベースにも問い合わせる。

「もう、これ人間いらないのでは？」と一瞬思うのですが――

金融機関の担当者にこう聞かれた瞬間、空気が変わります。

「で、このAIは顧客の信用情報を、規則に反して参照しない保証はあるんですか？」

......。

賢さと、信頼できることは、別問題なのです。

LLMは確率的に動きます。指示をほぼ守ってくれますが、「ほぼ」では済まない業界があります。医療、金融、政府、重要インフラ。一度でもルール違反が起きたら、即アウトの世界です。

ここで登場するのが、**「Policy as Code（ポリシー・アズ・コード）」**という考え方です。

整理すると、こうなります。

• Agent Skills → AIに「どうやるか」を教える（手順）
• Policy as Code → AIに「やってはいけないこと」を強制する（境界線）

Skillsが「仕事の教科書」だとすれば、Policy as Codeは「越えたら警報が鳴るフェンス」。

両方そろって、初めてAIは規制業界で使えるのです。

2. 正体は、意外と古くからある仕組み

「Policy as Code」と聞くと新しい技術に聞こえますが、実はクラウド業界では何年も前から使われている概念です。

組織のルール（規制、コンプライアンス、社内規程）を、機械が読める形のコードに書き起こす。

それだけです。

たとえば、「本番環境のサーバーは特定のタグが必須」「データベースへのアクセスは業務時間内のみ」といったルールを、人間の文書ではなくコードとして定義します。

そして、システムが何か操作をするたびに、そのコードに照らして「OK」か「NG」かを判定するのです。

元々はKubernetesやクラウドインフラの世界で発展してきた仕組みですが、AIエージェント時代になって、その価値が一気に再評価されている――これが今のトレンドです。

3. 一番の誤解――AIはポリシーを「理解」しない

ここで、多くの人が最初にハマる落とし穴を紹介します。

「AIにポリシーを教えれば、守ってくれますよね？」

いいえ。違います。

Policy as Codeの設計思想は、AIの理解や善意に頼らないことにあります。

たとえ話で説明しましょう。

空港のセキュリティゲートを思い出してください。

乗客（AI）は、手荷物検査のルールブック（ポリシー）を読みません。読む必要もありません。

X線を通せば、検査員（ポリシーエンジン）が「OK」か「NG」を判定してくれる。乗客はその結果に従うだけ。

Policy as Codeも同じ構造です。AIの横に別のエンジンが立っていて、AIが何かしようとするたびに、そのエンジンがポリシーに照らして判定する。

AIは判定結果（yes/no）を受け取るだけで、ポリシーの中身は見えません。

「賢いAIに信じて任せる」のではなく、「AIを物理的に囲い込む」

これがPolicy as Codeの本質です。

4. 業界標準の道具――OPAとRego

この仕組みを実現する、最も有名な道具が2つあります。

OPA（Open Policy Agent）

ポリシーを評価するエンジン本体。オープンソースで、Cloud Native Computing Foundation（CNCF）の最上位認定を受けた、いわば業界公認ツールです。

KubernetesやPrometheusと同じ卒業プロジェクト。つまり「これは信頼していい技術ですよ」という業界のお墨付きがあります。

Rego（レイゴー）

OPAで使うポリシー記述言語。Datalogという論理型言語から派生した、宣言型の言語です。

「こういう条件を満たすなら許可する」を書き並べていくスタイルで、SQLに少し似ています。

ポリシーのサンプルはこんな雰囲気です。

package medical.access

default allow = false

allow {
    input.user_role == "doctor"
}

allow {
    input.user_role == "billing_assistant"
    input.purpose == "insurance_claim"
}

これを見て「ちょっとコードっぽくて怖い」と思うかもしれませんが、ポイントは――

このコードを読むのはAIではなく、OPAエンジンだけだということです。

AIは何も理解しなくていい。ただ、OPAが「NG」と言ったら、それに従って動きを止めるだけ。

5. AIがルールに「従う」のではなく、「従わざるを得ない」設計

では、どうやってAIに従わせるのか？

ここが設計の肝です。

Policy as Codeの実装では、AIエージェントの行動経路そのものを物理的に制限します。

AIがデータベースに問い合わせたい？――直接はアクセスできません。必ず「ゲートウェイ」を通る設計になっています。

AIが外部APIを叩きたい？――プロキシを経由します。そこでOPAが判定します。

AIが重要な書類を送ろうとする？――送信ラッパーがOPAに問い合わせ、許可されなければ送信は起きません。

つまり――

AIが「従いたくない」と思っても、従わないという選択肢自体が存在しない。

プロンプトで「このルールを守ってね」とお願いするのとは次元が違います。お願いは忘れられますが、物理的なフェンスは忘れられません。

この強制力こそが、規制業界がPolicy as Codeに惹かれる最大の理由です。

6. Agent Skillsとの美しい補完関係

ここで、前提を整理しておきましょう。

Agent SkillsとPolicy as Codeは、競合するものではありません。むしろ、セットで威力を発揮するものです。

Skillsで「業務の進め方」を教えれば、AIは効率よく仕事をします。

その上でPolicy as Codeが最終防衛線として機能することで、万が一Skillsの指示に誤りがあったり、プロンプトインジェクションでAIが騙されたりしても、致命的な違反は防げる。

教えつつ、囲い込む。

これがAIエージェント運用の王道パターンになりつつあります。

7. 課題もある――標準化はまだ発展途上

ただし、正直に言うと、Policy as Codeはまだ完成形ではありません。

Agent Skillsが「SKILL.md」という単一フォーマットで綺麗にまとまっているのに対し、Policy as Code業界には複数の流派が並立しています。

• OPA / Rego：CNCF公認、最も普及
• HashiCorp Sentinel：Terraform等と統合
• Amazon Cedar：AWS発、認可特化
• Kubernetes Network Policy等：YAMLベース

どれを選ぶか悩ましいところですが、マルチクラウド・ベンダー中立を重視するなら、現時点ではOPA/Regoが最も無難な選択肢と言えます。

また、ポリシー判定APIの標準化（OpenID FoundationのAuthZEN）や、MCPとの統合など、AI時代に向けた標準化の動きも進行中です。

今後5〜10年で、もう少し綺麗に収斂していくはずです。

8. 明日からできる、2つのアクション

理屈はわかった。では何から始めるか。

(1) 自社の「AIに絶対にやらせたくないこと」を書き出す

難しい技術の話の前に、まずは日本語で構いません。

「顧客の個人情報を社外に送らない」「承認なしに10万円以上の支払いをしない」「本番DBに直接書き込まない」――

書き出した一つひとつが、将来のRegoポリシーの原型になります。

(2) OPA Playgroundで遊んでみる

OPAにはブラウザ上でRegoを試せるPlaygroundがあります。

インストールも不要、登録も不要。

サンプルコードをいじってみるだけで、「あ、こういう仕組みなのね」がわかります。

9. 結論：AIの「賢さ」ではなく「振る舞い」を設計する時代

これからのAIエージェント開発では、もはや「AIをどれだけ賢くするか」だけが勝負ではありません。

「AIをどう囲い込み、どう振る舞わせるか」が同じくらい、あるいはそれ以上に重要になります。

LLMはこれからも確率的なままでしょう。

時々間違えるし、時々騙されるでしょう。

それでも、システム全体としては絶対に違反を起こさない。

そういう設計を可能にするのが、Policy as Codeなのです。

派手さはありません。OPAもRegoも、地味な道具です。

でも、AIを「実験室のおもちゃ」から「本番業務の相棒」に変えるには、この地味な仕組みが絶対に必要になる――私はそう考えています。

最後に、問いを一つだけ残して終わります。

あなたの業務で、もしAIが暴走したら一番怖いことは何ですか？

それを言語化した瞬間から、あなたのPolicy as Codeづくりは、もう始まっています。