記事のサマリー（TL;DR）
- エージェント層のガードレールは「確率的な振る舞い」に依存するため、ミリ秒単位で動くAIエージェントの統制には構造的に限界がある
- EDBは「宣言的パーパス（Declared Purpose）」をセッション開始時にIDに紐付け、既存のアクセス制御ポリシーエンジンで評価する9コントロール枠組みを提示
- Postgresベースのオープンソーシャン基盤により、オンプレ・クラウド・エアギャップ環境を問わずソースレベルのガバナンスを一元適用できる
国内金融・医療・製造業のAIエージェント導入が「データ層ガバナンス」を必要とする理由
日本では金融庁のシステム管理基準改訂や医療情報安全管理ガイドライン、個人情報保護法の改正など、データの取り扱いに対する規制環境が年々厳格化しています。AIエージェントが社内システムを横断して自律的に動き始めると、「どのデータに誰の権限でいつ触ったか」を事後に証明する責任が企業に直接課せられます。本記事が主張する「ガバナンスはデータ層に実装する」というアプローチは、日本の規制要件と直結しています。
kintone・Salesforce・freeeといった業務SaaSを複数組み合わせて運用している国内企業では、エージェントが複数システムをまたいで行動するシナリオが現実的です。その際、各SaaSのAPIレベルで完結するアクセス制御だけでなく、バックエンドのデータ基盤（BigQueryやPostgres等）でも行・列レベルのポリシーを統一的に適用できる構成が、監査証跡の一貫性を保つ上で重要です。Shopify Plusを用いたECオペレーションでも、顧客PII（個人識別情報）へのエージェントアクセスを行単位でマスキングする設計は、個人情報保護の観点から実用的な選択肢になります。
詳細
エージェント層だけに頼ることの構造的限界
企業がAIエージェントに「計画・判断・実行」を任せるようになると、アーキテクチャレビューの中心に必ず一つの問いが浮かぶといいます。「エージェントが想定外の行動をしようとしたとき、それを実際に止めるものは何か？」
本記事はEDBのCTO Max Romanenko氏による寄稿で、この問いに対して明快な回答を示しています。エージェント層の上にポリシーや指示・モニタリングを積み重ねる「ガードレールアプローチ」には構造的な限界があるというものです。
比喩として使われているのが「車のドアを絶対に開けるな」というルールです。文字通りに従えばエージェントは乗り降りすらできません。しかし車が衝突事故を起こして火災が発生し、人が閉じ込められている状況では、ルールの「正しい解釈」はまったく逆になります。コンテキストが全てを変える、というのがこの比喩の示す点です。エージェントに高度な判断を求める以上、ルール自体も文脈を理解する必要があり、そのロジックを「エージェントの善意ある解釈」に委ねることはリスクです。
エージェントの振る舞いは確率的です。ミリ秒単位、複数システムにまたがって動く自律システムに対して、人間が事前にアクションをレビューするガバナンスはスケールしません。
データ層こそが執行ポイント（The data layer is the enforcement point）
エージェントは価値を生み出すためにデータに触れます。クエリ・検索・変換・書き込み——これらすべてにおいて、ポリシーの執行はアクセスが要求された「その瞬間」に行われる必要があります。「あるクラスのデータにエージェントはアクセスすべきでない」という方針は、実際にそのアクセスをシステムが拒否できて初めて意味を持ちます。
ガバナンスがデータ層に存在する場合、エージェントがどのように構築されていても、どのように振る舞おうとも、コントロールはデータベース自体のプロパティとして機能します。エージェントの「約束」ではなく、インフラの「仕組み」として機能するのです。
EDBのプロダクト管理VP、Priyanka Jain氏は次のように述べています。「宣言的パーパス（Declared Purpose）こそが違いを生む。それはアクセス層がすでに理解している属性となり、ロールや行レベルセキュリティと同じポリシーパスで評価される。執行の仕組みは変わらない。変わるのは、エージェントのパーパスが評価対象の一部になり、事後の記録が証明する内容の一部になるという点だ」
9つのコントロール、3つの命題
EDBは、実践的なフレームワークとして9つのコントロールを3つの命題（Imperative）のもとに整理しています。
① Enforce it（執行する）
- クエリ時に実施されるロール・属性ベースのアクセス制御（RBAC/ABAC）——エージェントもユーザーと同等に対象とする
- 同じポリシーパスで駆動する動的カラムマスキング
- エージェントIDをファーストクラスのプリンシパルとして扱う——セッション開始時に宣言的パーパスをIDに紐付け、操作対象ユーザーも保持する
② See it and prove it（可視化し、証明する）
- ポリシーを駆動するデータ分類・タグ付け
- セッションレベルの監査ログ——「どのエージェントが・誰のために・どのような宣言されたパーパスのもとで」行動したかを記録
- パイプラインにまたがるリネージ（Lineage）——あるアウトプットをそれを生成したリクエストまでさかのぼれる
③ Unify and harden（統一し、堅牢化する）
- 集中管理・ポータブルなポリシーマネジメント
- 保存時・転送時の暗号化
- オンプレ・クラウド・ソブリンまたはエアギャップ環境にまたがる一貫した執行
“Digital leash”——「鍵のかかったドア」ではなく「デジタルリーシュ」
記事のゴールはエージェントの有用な仕事を止めることではありません。「どこまで進めるか・何に触れられるか・何を変更できるか・何がエスカレーションを必要とするか・何か問題が起きたとき組織はどう再現するか」を定義することです。
このように統治されたエージェントは、識別（Identified）・スコープ設定（Scoped）・監視（Monitored）・監査可能（Auditable）な状態に置かれます。セキュリティ・リスク・経営層がその運用モデルを信頼できるからこそ、企業はより速くエージェントを採用できる——これが記事の主張する逆説的な結論です。
オープンソースPostgresによるオープンかつソブリンな基盤
EDBの製品「EDB Postgres AI」はオープンソースのPostgresをベースとした企業向けデータ・AIプラットフォームです。トランザクション・分析・AIワークロードを統合し、データが存在する場所でガバナンスを執行します。
このオープン基盤によって、企業はデータの所在・アクセス権・ポリシーのコントロールを「自分たちが所有し検査できない外部レイヤー」に委ねることなく維持できます。金融・医療・公共といった規制産業にとって、データ主権とソースレベルの執行を組み合わせたこのアプローチは「あれば望ましい機能」ではなく、エージェントを本番環境に投入するための前提条件だと記事は述べています。
結論——速度を落とさないためのガバナンス
エージェントシステムはより高性能・より自律的になり続けます。それはコントロールの所在を慎重に設計する理由であり、速度を落とす理由ではありません。データ層でガバナンスを執行できる企業は、データを保護するものが「期待と善意」以上の何かであるという確信のもとで、AIに対して攻撃的に投資できます。
詳細なフレームワークはEDBのホワイトペーパー「Governing Agentic AI at Enterprise Speed」で公開されています。