TL;DR

  • Oracle AI World 2026 のセッション「Trusted Agentic AI with Oracle AI Database」で、Oracle AI Database の中で AI エージェントを動かす新しい仕組み、Agent Engine が紹介された。
  • エージェントの定義（Open Agent Spec）、実行（Agent Executor）、記憶（Agent Memory）、統制（AI Governor）を、データベース（DB）の中にまとめる構成だ。エージェントを SQL で作って SELECT で呼び出す Agent SQL も示された。

はじめに

2026 OCI Top Partner Engineers の今井です。

2026年10月25日〜28日にラスベガスで開催された Oracle AI World 2026 に参加した。このうち、2026年10月27日のセッション「Trusted Agentic AI with Oracle AI Database」を聴講した。

本記事では、このセッションで新しく紹介された Agent Engine を中心に、何ができるようになるのかを紹介する。

Agent Engine とは？

セッションは「AI エージェントに機密性の高い企業データを任せるには、どう信頼すればよいか」という問いから始まった。登壇者は、データ（Data）、データへのアクセス（Access）、データとアプリケーションの知識（Knowledge）、エージェントの実行（Execution）の4つの層それぞれで信頼を作る必要があるとし、最後の実行から説明を始めた。

Agent Engine を構成する4つの部品
Agent Engine を構成する4つの部品

Agent Engine は、この実行の層を担う、DB の中に常駐するエージェントの実行エンジンだ。統制・制御・監査ができ、失敗しても回復できるワークフローとしてエージェントを動かすためのもので、定義（Agent Definition）、実行（Agent Executor）、記憶（Agent Memory）、統制（AI Governor）の4つの部品で構成される。

Agent Engine でできること

セッションで説明された内容を、利用者の目線で表にまとめた。

できること 中身
エージェントを一度定義して、どこでも動かす Open Agent Spec でエージェントとワークフローを1つの定義にまとめ、Oracle AI Database の Agent Engine でも、他のランタイムやフレームワークでも実行する
エージェントを DB の中で実行する Open Agent Spec の定義を取り込み、dbms_ai_agent.create_agent で作成し、dbms_ai_agent.execute_agent で DB の中で実行する。DB のトランザクション、制御、回復の仕組みの上で動く
エージェントの記憶を DB に持つ 長期から直近までの記憶を、業務データと同じ DB に1つの写しとして持ち、SQL・ベクトル・ハイブリッド検索で取り出す。Oracle Agent Memory Utility（DBMS_AGENT_MEMORY）が、検索（retrieval）、進化（evolution）、振り返り（reflection）などの API を提供する
エージェントの行動を記録・制御し、巻き戻す 近日提供予定の Oracle AI Governor が、改ざんできない行動の記録、実行ごとのトークン・CPU・メモリの観測、各ステップでのポリシーの適用、実行の再構成と取り消しを担う
エージェントを SQL で作って呼ぶ 近日提供予定の Agent SQL では、CREATE AI AGENT でエージェントを DB のオブジェクトとして作り、SELECT で呼び出し、CROSS APPLY で表のデータと組み合わせる

発表のポイント

1. 定義と実行を分ける Open Agent Spec と Agent Executor

登壇者は、Open Agent Spec を業界初（industry first）の取り組みとして紹介した。どのフレームワークで設計したエージェントも1つの定義にまとめ、Oracle AI Database の Agent Engine でも、他のランタイムでも実行するという考え方だ。LangGraph をはじめとする他のフレームワークやツールとの相互運用も挙げていた。他の提供元との連携は進行中だと、登壇者は説明した。

Open Agent Spec。一度定義して、どこでも動かす
Open Agent Spec。一度定義して、どこでも動かす

定義したエージェントは、Agent Executor が DB の中で実行する。手順は、パッケージ dbms_ai_agent でエージェントを作成し、実行し、出力を受け取る3段階だ。実行は一貫性が保たれ、途中からの再開・取り消し・再実行ができ、ポリシーとリソースで制御され、行動を監査できるとしている。

Agent Executor。dbms_ai_agent でエージェントを作成・実行する
Agent Executor。dbms_ai_agent でエージェントを作成・実行する

近日提供予定の Agent SQL では、エージェントが表のように見えるようになる。例として、ミッションの一覧の表に対してエージェントを CROSS APPLY で実行し、成功したミッションを行き先ごとに数える SQL が示された。登壇者は、SQL がオーケストレーションの言語になると述べた。

Agent SQL。SQL でエージェントを作り、呼び出す
Agent SQL。SQL でエージェントを作り、呼び出す

2. エージェントを DB の中で動かす理由

登壇者は、データ中心で機密データを多く扱うエージェントには、DB の中で動かすのが最善の形だと述べた。利点として挙げられたのは次の4つだ。

観点 キーワード 中身
Security Compute vs. Disclose privilege separation Deep Data Security によるデータの保護と監査。エージェントは、エンドユーザーがアクセスできるデータを参照する
Performance Agent-Data Locality エージェントがデータの近くで動き、DB への往復なしに何度もデータにアクセスできる
Execution Integrity Transactionally Consistent Snapshots Exactly-Once Execution、Resource Management、Audited actions など
Simplified Deployment Build Once, Run Anywhere Oracle AI Database が動く場所ならどこでも（on-prem、cloud、multi-cloud）
DB の中で動かす4つの利点
DB の中で動かす4つの利点

Agent Memory について登壇者は、記憶をデータと同じ場所に置くほうが効率がよいと説明した。記憶をベクトル DB・文書 DB・グラフ DB などに分けると、効率、一貫性、セキュリティ、信頼性に問題が出るうえ、エージェントが何を知っていたかを1か所で監査できず信頼を損なう、という説明もあった。Oracle Agent Memory Utility は、Mem0 と Letta からそのまま使え、LangGraph、CrewAI、N8N からも記憶として使えると紹介された。

Oracle Agent Memory Utility
Oracle Agent Memory Utility

AI Governor について登壇者は、銀行や医療のような業種では、エージェントがなぜその行動をし、どのポリシーで何が許可・拒否されたかの記録が必要になると説明した。例では、資格のない訓練生による修理をポリシーで止め、ロボットによる修理を許可した記録が残る様子が示された。

Oracle AI Governor の4つの機能
Oracle AI Governor の4つの機能

押さえておきたい制約・前提

ここで重要なのは、Agent Engine のうち AI Governor と、Agent SQL は近日提供予定と説明された点だ。どちらも発表時点の計画で、変更の可能性がある。Agent Engine はこのセッションで新しい機能として紹介されたが、一般提供（GA）かプレビューか、どの環境やリージョンで使えるかは、私が確認できたセッションの内容からは分からなかった。利点に挙げられた「Oracle AI Database が動く場所ならどこでも」も、個々の環境での提供状況を示したものではない。詳細は公式の情報を確認いただきたい。

ユースケースの考察

同じ日の別のセッション「Oracle AI Database: What’s New and What’s Next」でも、Agent Memory が取り上げられた。例に挙がったのは顧客対応のエージェントで、顧客の会員の区分や前日の問い合わせ、在庫のある倉庫などを覚えておく必要があるという。記憶はベクトルだけでなく、いろいろな種類のデータにまたがるという説明だった。

こうした記憶は、どれも顧客個人の情報だ。だから、似ている記憶を探せるだけでは足りず、「この利用者に見せてよい記憶か」を先に判断する必要がある。Oracle Agent Memory のホワイトペーパーも、返すべきなのは最も似ている記録ではなく、見せてよい中で最も近い記録だとしている。

記憶を業務データと同じ DB に置けば、この判断を、業務データですでに使っている権限の仕組みに任せられる。別の顧客の問い合わせ履歴をうっかり答えてしまう、といった事故も防ぎやすくなる。

エージェントの記憶を設計するとき、最初に決めるべきなのは「何を覚えるか」より「誰に見せてよいか」だ。それを DB の権限で決められることが、Agent Memory を DB に置く一番の理由になる。

参考