何が主張されているか
VentureBeatに掲載されたEDBのスポンサード記事で、同社CTOのMax Romanenko氏は、AIエージェントに計画・判断・実行の裁量を与えた企業が直面する中心的な問いを「結局、何が不正な操作を止めるのか」と定義しました。人間が一手ごとに承認しない前提に立つ以上、この問いに答えられないアーキテクチャは運用に耐えない、という立て付けです。
記事はガードレール型の対策——モデルの上にインストラクション、ポリシー、モニタリングを重ねるやり方——に構造的な限界があると指摘します。エージェント層の統制は、エージェントの出力が予測可能な範囲でしか効きません。しかし自律性とは、まさに出力を予測しにくくする性質そのものです。加えて、行動前レビューに依存するガバナンスは、ミリ秒単位で複数システムを横断して動く相手には追いつけません。
「車のドアを開けるな」の例
興味深いのは、ルールの文言だけでは足りないことを示す例え話です。「車のドアを絶対に開けるな」を文字どおり守るエージェントは、車に乗り降りできません。しかし事故で車が炎上し負傷者がいるなら、望ましいルールは正反対になります。エージェントは自らの行動に対して上位の判断を働かせないため、その瞬間の文脈に紐づいたルールが必要だ、という論旨です。
なぜデータ層なのか
エージェントが価値を生むのはデータに触れるときです。照会し、取得し、変換し、さらには操作する。だからこそデータ層が強制点になる——というのが主張の骨子です。「この種類のデータには触れさせない」というポリシーは、リクエストのその瞬間にアクセスを拒否できて初めて意味を持ちます。監査可能性も同様で、何をしたか、どのデータに触れたか、どのユーザーの代理で動いたか、結果どうなったかを再構成できなければ、原則としては存在しても実務では存在しないのと同じです。
重要なのは、データ層の統制がエージェントの作り方や振る舞いに依存しない点です。統制はデータベース自身の性質であり、エージェント側の約束ではない。記事は「エージェントの挙動は確率的でよいが、ガバナンスは確率的であってはならない」と整理しています。
仕組みは既存、変わるのは「誰を認識するか」
必要な統制の多くは、企業がすでにデータ層で運用しているものです。ロール／属性ベースのアクセス制御、行・列レベルのセキュリティ、分類とマスキング、ポリシー・アズ・コード、完全な監査証跡。エージェントが変えるのはメカニズムではなく、そのメカニズムが誰を認識すべきかです。
つまりID管理が、エージェントを独立したプリンシパル（主体）として扱う必要がある。固有のIDを持ち、セッション開始時に「目的」を宣言する。EDBのVP, product management, data & AI governanceであるPriyanka Jain氏は、宣言された目的こそが差分だと述べ、それはアクセス層がすでに理解している属性となり、ロールや行レベルセキュリティと同じポリシーパスで評価される、強制メカニズム自体は変わらない、と説明しています。
記事はこれを3つの命題×9統制に整理します。Enforce it（クエリ時に強制されるRBAC/ABAC、同一ポリシーパスによる動的な列マスキング、目的を束ねたエージェントIDと代理元ユーザーの保持）、See it and prove it（ポリシーを駆動する分類・タグ付け、どのエージェントが誰のためにどんな宣言目的で動いたかを記録するセッションレベル監査ログ、リクエストまで遡れるリネージ）、Unify and harden（集中管理かつ可搬なポリシー、保存時・通信時の暗号化、オンプレ／クラウド／ソブリンやエアギャップ環境での一貫した強制）。
「鍵のかかった扉」ではなく「デジタルの引き綱」
記事はこの構えを「a digital leash, not a locked door」と表現します。狙いはエージェントに有用な仕事をさせないことではなく、どこまで行けるか、何に触れられるか、何を変えられるか、何がエスカレーション対象か、問題時にどう再構成するかを定義することです。そう統制されたエージェントは識別・スコープ設定・監視・監査が可能になり、セキュリティ・リスク・経営が基盤の運用モデルを信頼できるため、かえって導入が速くなる、という順序で語られています。
技術的な土台はオープンソースのPostgresです。データの所在、到達できる主体、適用ポリシーを企業側が握り続けられる——自分が所有もできず検査もできない層にガバナンスを委ねずに済む、という位置づけで、EDB Postgres AIはトランザクション・分析・AIワークロードを統合するソブリンなデータ／AI基盤として説明されています。規制業種では、データ主権とソース側での強制の組み合わせが、そもそもエージェントを本番投入するための前提条件だと述べられています。
なお本稿の元記事はEDBによるスポンサード記事であり、VentureBeatは掲載企業が費用を負担するか事業関係にある旨を明示しています。ベンダーのポジショントークという性格は割り引いて読む必要がありますが、「統制点をどこに置くか」という問いの立て方自体は、製品選定と独立して検討する価値があります。
💼 事業会社視点：これは自社にどう効くか
日本企業にとって刺さるのは「ガバナンスは書類ではなく実行される仕組みか」という問いです。多くの現場でAIエージェント導入の稟議は、プロンプトの禁止事項リストと利用ログの提出で通っています。しかしエージェント層の統制は出力の予測可能性に依存するという指摘に照らせば、その承認は実質的な担保になっていません。
金融・保険・医療など規制業種：ソブリン性とソース側強制が本番投入の前提だという主張は、そのまま監査対応の論点です。「どのエージェントが、どのユーザーの代理で、どんな宣言目的で、どの行・列に触れたか」をDB側のログで再構成できるか。できないなら、PoCは通っても本番の内部監査で止まります。
EC・SaaS：在庫や価格、顧客データにエージェントが書き込む段階に入るなら、列マスキングと行レベルセキュリティをアプリ側ではなくデータ層に寄せる設計判断が必要です。アプリ層に散在した認可ロジックは、エージェントという新しい呼び出し元を想定していません。
受託開発・SIer：エージェントを「独立したプリンシパル」として扱うID設計は、そのまま提案の差別化材料になります。逆に、既存案件の権限設計をエージェント前提で棚卸しできなければ、責任分界点の議論で不利になります。
経営として今週動くべきは一点です。既存のRBAC・監査証跡・データ分類の資産を洗い出し、「エージェントをユーザーと同じポリシーパスで評価できるか」を情報システム部門に確認すること。多くの企業で、必要な部品はすでに持っているが、認識すべき主体だけが欠けています。