Oracleが一般提供を開始した内容
Oracleは10月26日、Oracle AI Database Agent EngineをOracle AI Database 26aiで一般提供すると発表しました。このruntimeは、対応するAgent Spec workflowをdatabase内で実行します。DBMS_AI_AGENT interfaceを通じて、宣言型flow、modelとtoolを反復するagent、PL/SQL tool、model call、branch、parallel workを連携できます。
Oracleによると、database privilegeがsource dataを保護し、toolのoutput contractと宣言済みdata-flow edgeが後続componentへ渡せる情報を決めます。そのためtrusted operationは機微な値を使って計算し、より限定されたdecision contractだけをmodelやcalling applicationへ開示できます。Documentationはoptionalなstructured trace、transactional execution context、resource governance、databaseのnetwork boundaryを越えるmodel callも説明しています。ここまではOracleが公表した機能であり、以下はIneezaの本番運用分析です。
可用性について重要な区別があります。Oracleのoverviewではresumabilityとdurable conversationが「coming in 23.26.4.2」と記載されています。Workflow stateがtransactional dataの近くにあることだけを理由に、すべてのworkflowが現在すでに最後のdurable boundaryから安全に再開できると推定すべきではありません。
Database commitはbusiness completionではない
Orchestrationをdatabase内へ移すことで、workflow stateとdatabase mutationを一貫したtransaction modelで扱いやすくなります。しかし、LLM response、外部API call、email、payment submission、human approvalまで同じatomic commitの一部になるわけではありません。
Ineezaの分析: 各stepには明示的なeffect classが必要です。Pure readは繰り返し可能、database writeにはtransactionとisolation rule、外部side effectにはidempotency keyとrecovery query、重大なactionには認可と記録されたdecisionが必要です。Workflow stateはprepared、submitted、acknowledged、uncertain、compensated、finalizedを区別すべきです。「Agent runがcommitされた」ことをbusiness operationのfinalityの証明として扱ってはいけません。
すべてのedgeでdisclosure contractを強制する
Privileged computationとpermitted disclosureを分離するOracleの設計は強いboundaryです。Raw database rowをmodelへ送る必要を減らせますが、各output contractがsource authorityより狭く、すべてのdownstream edgeがその制約を維持する場合に限ります。
Ineezaの分析: 実行前にfieldを分類し、各model、tool、trace、caller、error pathへ実際に渡るpayloadをtestすべきです。派生値でも、小さい母集団、反復query、free-text explanation、step間の相関から保護対象の事実を明らかにし得ます。Logとtraceには独自のaccess control、retention、redaction policyが必要であり、audit artifactを第二の開示経路にしてはいけません。
Portable specificationでもcontrolは自動的にportableにならない
Agent Specは宣言型workflow definitionとdatabase runtimeを分離します。Oracleは実行前に対応component、reference、path、contractを検証すると記載する一方、database privilege、credential、network controlはexecution environmentの性質として残ります。
Ineezaの分析: 同じspecificationを別の互換runtimeへ移しても、security propertyが自動的に再現されるわけではありません。Deployment evidenceはspecification digestをruntime version、対応するAgent Spec subset、tool implementation、database role、model endpoint、egress policy、limit、approval ruleへ結び付けるべきです。Compatibility testでは成功時のoutput equivalenceだけでなく、拒否経路とpartial failureも確認する必要があります。
Model conversationではなくauthority chainをtraceする
Optionalなexecution traceは、どのcomponentが実行され値がどう移動したかを説明できます。規制対象または金融上重大なworkflowでは、各operationがなぜ認可され、そのeffectがどう照合されたかも証明する記録が必要です。
Ineezaの分析: Caller identity、保存済みspecification version、input contract、database sessionとrole、tool parameter、source record version、model identity、開示payload、policy decision、approval、外部idempotency key、response、最終business recordを一つのcorrelation chainで結ぶべきです。Resource throttling、cancellation、timeout、fallback eventも、どのpathがresultを生成したかを変え得るため同じchainに含めます。
Ineezaの見解
Oracle Agent Engineが重要なのは、databaseをagent workflowのretrieval sourceだけでなくexecution targetにした点です。Synchronization tierを減らし、より緊密なinformation boundaryを作れる可能性があります。ただし本番で有効なpatternはさらに限定的です。Deterministic workが事実を確立し、contractが開示を限定し、modelは宣言済みのpointだけで動作し、重大なeffectは明示的な認可とfinalityのgateを通過します。Transactional proximityは有用ですが、data consistency、model reasoning、external effect、説明責任を持つbusiness decisionの境界を曖昧にしてはいけません。