11月2日、Brad Shimminが「Oracle AI World: Oracle Introduces Deep Trust AI to Enforce AI Safety at the Database Tier」と題した記事を公開した。OracleがAIエージェントのセキュリティ制御をミドルウェアではなくデータベースカーネル自体に組み込む「Deep Trust AIアーキテクチャ」を発表したことを詳しく紹介している。エンタープライズAIが自律的なデータ書き込みへ踏み込む今、従来のセキュリティ設計が機能不全に陥りつつあるという問題意識がその背景にある。
ミドルウェア型ガードレールの限界が露呈した
エンタープライズAIが「情報の検索」から「自律的なデータ書き込み」へ移行するにつれ、従来のセキュリティ設計が機能不全に陥り始めている。
これまでのエンタープライズシステムは、APIゲートウェイやアプリケーション層のミドルウェアが入力を検証し、ロールベースアクセス制御（RBAC）を適用してからデータベースにアクセスするという前提で設計されていた。しかしAIエージェントがModel Context Protocol（MCP）や自然言語インターフェース経由でデータストアに直接書き込みを行う場合、この前提は崩れる。非決定論的なエージェントが機械速度で動作すれば、不正なクエリを生成したり、プロンプトインジェクション経由でミドルウェアのガードを完全に迂回したりしうる。
この問題は数字にも表れている。Futurum Intelligenceの2026年下半期調査によれば、24.6%の組織が「AIエージェントがシステム・オブ・レコードへ書き戻せないこと」を主要なデータインフラのボトルネックとして挙げている。
Deep Trust AIの核心：セキュリティをカーネルに埋め込む
Oracle AI World 2026（ラスベガス）でOracleが発表したOracle Deep Trust AIアーキテクチャは、この問題への直接的な回答だ。同社がデータベース高可用性設計の指針として使ってきた「Maximum Availability Architecture（MAA）」の設計思想を踏襲し、セキュリティ・プライバシー・ビジネスガバナンスをアプリケーション側の責務ではなくプラットフォームの固有機能として実装する。
アーキテクチャは4層で構成される：
- ソフトウェアプラットフォーム層 — Oracle Autonomous AI Databaseが、OS・データベースカーネル・Exadataストレージ・ファームウェアに対して、脆弱性が公開される前に自動ローリングパッチを適用する。
- データ層 — Oracle Deep Data SecurityがSQLパーサーレベルで暗号署名されたディレクトリトークンを検証し、エージェントのトランザクションを認証済みのユーザー・サービスIDに紐付ける。さらにOracle SQL Assertionsが、支出上限や承認フローといったビジネスルールをデータベースエンジン内部の不変制約として直接定義する。エージェントの意図がどうであれ、制約に違反するデータ変更は拒否される。
- データアクセス層 — Oracle Deep Trust Data APIsがJSONリレーショナルなビジネスオブジェクトを公開し、Oracle Deep NL2SQLが自然言語クエリをSQLに変換する際に「Knowledge Change Verification」を用いてゴールドアンサーとの回帰テストを継続実行し、意味的なドリフトを防止する。
- アプリケーション開発層 — Oracle APEX AI Application Generatorが自然言語プロンプトを宣言的なAPEXlang仕様にコンパイルし、ハードニングされたランタイムエンジン上で実行する。
SQL Assertionsの意味するもの
エンジニア視点で最も注目すべきはSQL Assertionsだ。従来のデータベースパーミッションはバイナリ（書き込み権限あり・なし）であり、「一定金額以上の取引には承認が必要」といったビジネスルールをDB側で表現する手段がなかった。SQL Assertionsはこれを宣言的な制約としてカーネルに埋め込むことで、アプリケーション層やエージェント層が何をしようとも、ポリシー違反のミューテーションを構造的にブロックする。
トレードオフ：プロプライエタリスタックへの依存
このアーキテクチャには明確な戦略的トレードオフがある。
信頼とセマンティクスのコンテキストをOracle Autonomous AI Databaseの深部に押し込むことで、不正エージェント（rogue agent）に対する高い防御力を実現する一方、そのセキュリティはOracleのプロプライエタリなリレーショナルスタックに強く依存している。Apache Icebergなどのオープンテーブルフォーマットを使ったマルチクラウドのコンポーザブルなレイクハウスを志向する組織にとって、異種クエリエンジン間でカーネルレベルのアサーションを再現することは継続的なインテグレーション課題として残る。
Brad Shimminはこの点を率直に認めており、OracleがMCPやDeep Trust Data APIs向けのオープンソースコネクタを公開するかどうかが今後の普及を左右する鍵と指摘している。
※編集部の考察：同様のガバナンス課題にアプローチする動きは他社にも見られる。たとえばSnowflakeはSnowflake Cortexにおいてウェアハウス層でのアクセス制御とAI機能を統合する方向を打ち出しており、「どのレイヤーにガードレールを置くか」という設計思想の違いが各プラットフォームの差別化軸になりつつある。Oracleのカーネル埋め込みアプローチはその中でも最もデータベース寄りに振り切った選択といえる。
今後の注目点
- SQL Assertionsの本番採用率：読み取り専用パイロットから書き込み系ERPオペレーションへ移行する企業でどこまで実運用に乗るか。
- プロトコル相互運用性：LangGraphやハイパースケーラーのエージェントスタジオとのMCPコネクタをOracleがオープンに提供するかどうか。
- 競合の対抗策：他のクラウドデータプラットフォームがカタログレベルのガバナンスをクエリ実行層まで拡張する動きがあるかどうか。
詳細はOracle AI World: Oracle Introduces Deep Trust AI to Enforce AI Safety at the Database Tierを参照していただきたい。
