OracleのAI Database Agent Engineは、アーキテクチャの根幹に関わる選択を変えます。機密レコードをオーケストレーション層経由で外部のエージェントプラットフォームに送るのではなく、Oracle AI Database 26ai内でエージェントの実行環境を動かします。つまり、Open Agent Specificationで記述した宣言型ワークフローを、データが存在する場所で実行できます。実務上の主なメリットは、ネットワーク通信の往復を減らせること、機密性の高い中間結果がさらされる攻撃対象領域を縮小できること、そしてワークフローの状態をデータベース操作とトランザクション上、一貫性のある形で保てることです。

Agent Engineは、幅広いワークフローパターンに対応しています。ReAct形式のツールとモデルの連携、順次・並列パイプライン、分岐ロジックに対応するオーケストレーターやルーターの構成、反復処理のためのループ構造などです。組み込みメモリによって、ワークフローのコンテキストと状態をデータとともに保持でき、人間による確認工程や監査機能も標準で備えています。こうした機能は、請求書の審査、不正のトリアージ、規制チェックなど、データ中心でレイテンシに敏感な処理を想定したものです。中間出力が大容量または機密性の高いワークロードでは、外部オーケストレーターへのシリアライズを繰り返すコストやリスクを抑えられます。

運用面では、Agent Engineにより、LLMはオーケストレーション層そのものではなく、より大きなトランザクション処理の一工程として位置づけられます。結合、集計、ルール評価といった決定論的な処理はSQL/PLSQLに任せ、解釈、要約、生成が必要な場合に限ってモデルを呼び出します。この分離により、生データがモデルに渡る範囲を抑えられます。モデルへの入力は、意思決定コントラクトによって範囲と形式が定められ、ポリシー制御によってモデルがテーブルへ無制限にアクセスすることを防ぎます。規制対象の企業にとって、広範なデータ抽出を外部LLMに送る場合と比べ、ガバナンス面で大きな利点となります。

トレードオフも明確です。実行環境をデータベース内に置けば、レイテンシと転送コストを削減できますが、計算負荷と可用性への依存がデータベース環境に集中します。モデルの停止中はワークフローも止まり、チームは本番ワークロードとのリソース競合を避けるため、分離計画を立てる必要があります。Open Agent Specificationに準拠することで移植性は高まりますが、移行経路やベンダーロックインへの懸念、DBAやプラットフォームチームに求められるスキルの変化を踏まえ、慎重に変更管理を進めなければなりません。