Oracle Deep Trust AI Architecture、AIの安全対策をエンタープライズスタックに組み込む
Oracleは10月26日、個々のAIアプリケーションに実施を委ねるのではなく、エンタープライズ技術の4層にわたって保護機能を配置するOracle Deep Trust AI Architectureを発表した。このブループリントは、ソフトウェアプラットフォーム、データ、データアクセス、アプリケーション開発を対象とする。その中心的な主張は実務的だ。AIモデルが誤りを犯した場合でも有効であり続ける制御が、企業には必要である。
この発表は、モデルを使ってツールを選択し、タスクを実行するソフトウェアであるAIエージェントを対象としている。こうしたシステムは、難しいアーキテクチャ上の問いを生む。エージェントが新たな経路で業務データに到達した場合、既存アプリケーションに組み込まれた制約は引き続き適用されるのか。
Oracleの答えは、アプリケーションの下位層での実施を重視する。AWSは、エージェントの実行境界の外側にあるAgentCoreの制御を通じて、関連する目的を追求している。意味のある比較は、各アプローチがどこでポリシーを実施するか、何を対象とするか、そして顧客がなお何を設定しなければならないかに関わる。エンタープライズの購入者にとって、この発表はソフトウェアだけでなく責任に関する判断でもある。
Oracle Deep Trust AI Architecture、4つの制御層を接続
Oracleは、信頼できる振る舞いを保証するモデルを発表したのではなく、既存製品の機能を組み合わせるアーキテクチャのブループリントを提示している。
10月26日のエンタープライズAIアーキテクチャに関する発表は、ラスベガスで開催されたOracle AI Worldで行われた。Oracle AI Database、Oracle Autonomous AI Database、Oracle APEX AI Application Generatorをまとめるものだ。
Oracleはこのアプローチを、信頼性の高いシステムを設計するための同社のブループリントであるMaximum Availability Architectureと比較している。ここでの組織化の目的は、AIのアクセスとアクションに対する制御を維持することだ。同社によれば、共有される保護機能により、各アプリケーションで個別に実装される安全対策への依存を減らせる。
何が変わったのかを評価する際、この区別は重要である。アーキテクチャの発表は、発表日にすべてのコンポーネントが新たに利用可能になることを意味せずとも、共通の設計方針を示すことができる。購入者は、ブループリントの公開と、導入予定の各機能の提供状況を区別すべきだ。
実務上の重要性は、これらのコンポーネントがどのように連携することを想定されているかにある。企業にはすでに、データベース権限、アプリケーションのチェック、運用上のセキュリティプロセスがあるかもしれない。アーキテクチャ上の問いは、エージェントがシステムを通る別の経路を導入した際に、それらが一貫した境界を形成するかどうかだ。
購買記録を読み取り、変更案を作成する仮想的な調達支援アシスタントを考えてみよう。通常のアプリケーションインターフェースでは、従業員の権限を超える要求を拒否するかもしれない。アシスタントがそのインターフェースを一度も開かなくても、基盤となるデータへの別接続には同等の制約が必要になる。
この例は、顧客導入を記録したものではなく、Oracleが取り組もうとしている問題を示している。制御は、ワークフローが実際にそれに遭遇する場合にのみ、そのワークフローを保護する。別の経路がそのチェックを完全に回避するなら、アプリケーションのチェックをもう1つ追加しても、得られる安心は限定的だ。
したがってOracleの提案は、評価対象を変える。購入者は、人の要求から重大なシステムアクションに至る完全な経路を検証する必要がある。アシスタントの画面上の会話だけを確認しても、その経路の重要な部分は調査されないままになる。
4層の枠組みは、信頼という異なる意味も分けている。プラットフォームを維持することと、レコードへのアクセスを制限することは異なる。アクセスを制限することと、財務上の質問を正しく解釈することも異なる。あるアプリケーションは、1つの責任を果たしていても、別の責任では失敗する可能性がある。
この発表を追う読者にとって、この分離は不可欠だ。「信頼できるAI」は単一の製品特性のように聞こえるかもしれない。このブループリントでは、それは異なる証拠、担当者、受け入れ基準を必要とする複数のエンジニアリング上の責任を表している。
ニュースとなるのは、連携したアーキテクチャと、実施を重視するその姿勢である。このブループリントを採用するすべての企業が、すでにこれらの責任を解決していることを示すものではない。
データ所有者が直面する最も難しいガバナンス判断
スタックのより深い層へ実施を移すほど、ルールを正確に定義する重要性は高まる。
Oracleのデータセキュリティ設計では、エンドユーザーの検証済みIDに結び付いたデータベースでの実施が説明されている。リレーショナルデータを照会・変更するための言語であるSQLは、引き続きそれらのルールに従う。
同社はまた、定義された業務要件に違反する変更を拒否するデータベース条件であるSQL Assertionsについても説明している。その例は従業員の支出上限に関するものだ。これらの仕組みは、エージェントが指示を記憶していることに依存するのではなく、アクセスと有効な変更を扱う。
エンタープライズチームにとって、その含意は組織的なものだ。誰かが、どの権限と業務条件をその実施地点に置くかを決めなければならない。技術システムはルールを一貫して適用できても、組織内では、そのルールが何を許可すべきかについて意見が割れたままであり得る。
仮想的な購買ワークフローは、この違いを明確にする。購入要求を閲覧する権限があっても、必ずしも承認する権限まで含まれるわけではない。要求を承認する権限は、部署、要求の目的、または一時的な委任に左右される可能性がある。
これらは開発者だけでなく、プロセス所有者にとっての問題でもある。データベース管理者は、合意済みの条件の実装を支援できる。しかし、その管理者が非公式な会話から曖昧な購買ポリシーを推測する必要があってはならない。
したがってOracle AIガバナンスは、企業ポリシーの定義の質に圧力をかける。慣習だけで表現されてきたルールは、ソフトウェアが明確な判断を必要とする場面で管理が難しくなる。例外は、通常のワークフローに隠れた前提をしばしば明らかにするため、特に注意を要する。
これは、すべての判断をデータベース内に置くべきだという意味ではない。判断によっては、その範囲外の情報に依存するものがある。人間の裁量や別システムからの承認を必要とするものもある。アーキテクチャには、各制御が何を判断できるのかについて明確な境界が必要だ。
調達の例は、適格性と意図の違いも浮き彫りにする。ある要求が支出上限を満たしていても、誤った品目を購入している可能性がある。上限を実施することは定義済みの条件に対応するが、その購入が事業目的にかなっていることまで示すものではない。
この区別は購入判断に反映されるべきだ。チームは、提案された制御がどの失敗を防ぎ、どの失敗がなお起こり得るかを特定する必要がある。ガバナンスに関する広範な約束よりも、対象となるアクションを明示的に説明するほうが有用だ。
開発者も関連する責任の変化に直面する。共有の実施は繰り返しの作業を減らせるが、アプリケーションは依然として拒否を適切に処理する必要がある。アシスタントは拒否されたアクションを正確に説明し、その拒否を回避すべき技術的問題として扱わないようにすべきだ。
データ所有者には、ポリシーを変更するプロセスも必要である。導入時には正しかったルールも、組織再編や承認プロセスの改訂後には古くなる可能性がある。信頼できる実施は、影響が対象となるすべてのアプリケーションに及ぶため、規律ある更新の価値を高める。
したがって、成功の尺度はポリシーエンジンが動作するかどうかより広い。組織には、ポリシーの意味、所有権、例外、レビューについての合意が必要である。こうした判断が、一貫した実施が実際に何を達成するのかを決める。
共有された実施がOracleとAWSの比較を変える
アプリケーションの下位層にある制御を重視するOracleの姿勢は、エンタープライズAIの権限をどこに置くべきかをめぐる、より広い競争の一部である。
AWSは、ツールへのアクセスを仲介するサービスであるGatewayでのAgentCoreポリシー実施を説明している。AWSによれば、Policyはエージェントのコードの外側でツール呼び出しを評価し、許可されるアクションを管理するルールを適用する。
これは、同等の対象範囲を確立することなく、重要な比較を可能にする。Oracleはデータベースとアプリケーションスタックを重視する。AWSはツールアクセス周辺での実施を説明している。どちらもエージェント内に埋め込まれた指示だけに頼ることに異議を唱えるが、その実施地点は異なるアーキテクチャ上の役割を果たす。
ゲートウェイは、提案されたツール呼び出しが許可されるかを評価できる。データベースの制御は、要求がデータベースに到達したときにアクセスや変更を評価できる。企業にどちらか一方、あるいは両方が必要かどうかは、そのワークフローと既存システムに依存する。
したがって、購入者にとって有用な問いは具体的だ。要求が効果を生む前に、どこを通過しなければならないのか。チームがその周囲を通る、あるいはその先にあるすべての経路を特定できるとき、実施地点を示す図は意味を持つ。
たとえば、承認済みのツールを通じて業務レコードを更新できるアシスタントを想像してほしい。同じ環境には、より広い権限を持つ別の統合が存在する可能性もある。評価では、承認済みツールが境界全体を表すと仮定するのではなく、両方の経路を調べるべきだ。
これは分析上の例であり、いずれかのベンダー製品に特定された弱点があるとの主張ではない。機能名を比較しても得られる指針が限定的である理由を示している。対象範囲は、実際の導入と、そのコンポーネントに割り当てられた権限に依存する。
そのためOracleエージェントセキュリティは、顧客のデータ経路に照らして評価すべきである。関連するレコードとルールがデータベースに存在する場合、データベース中心の設計は綿密な検討に値する。外部サービスにまたがるワークフローには、それらのサービスに適した制御も必要となる。
比較において、Oracleのアプローチを、競合他社がプロンプトだけに依存している証拠として扱うべきではない。AWSの文書は外部での実施を明示的に説明している。競争上の違いは、統合、対象範囲、管理、一貫したポリシーを維持するために必要な作業に関わる。
責任を集約することにはトレードオフもある。共有制御は、チームにポリシーを調査する共通の場所を与えることで監督を簡素化できる。一方で、共有設定の誤りが複数のアプリケーションに重大な影響を及ぼす可能性もある。
反対に、チェックをツールやサービスに分散すれば、ローカルな文脈を維持できる。その一方で、一貫性を評価することは難しくなり得る。どちらのアーキテクチャ上の選好も、ID、権限、判断が完全なワークフローを通じてどう移動するかを理解する必要性をなくすものではない。
購入者にとっては、一般的なアーキテクチャ上の優位性の主張よりも、運用上の適合性のほうが有益な情報となる。最も強力な評価は、組織自身の権限境界と現実的なタスクを用いるものだ。なじみのないサンプルプロセスに基づくデモは、導入準備に関する証拠としては弱い。
この発表は実質的な競争論点を提起している。企業は、AIの振る舞いを生成するシステムと並行して、それを制約するシステムも購入している。そうした制約の価値は、企業が実際に利用する経路全体で有効であり続けるかどうかに依存する。
正確な回答には権限チェック以上のものが必要
エージェントはデータへの正当なアクセス権を持っていても、誤解を招く業務上の回答を生成する可能性がある。
OracleのDeep Trust capabilitiesには、自然言語の質問をデータベースクエリに変換するシステム「Deep NL2SQL」が含まれます。Oracleによると、ビジネスコンテキストを取り込み、回答の改善を目的としたフィードバックと検証をサポートしています。
これは、ある行為が許可されるかどうかを判断する認可とは別の責務に対応するものです。許可されたクエリであっても、質問を誤解する可能性があります。有効な結果であっても、基礎となるデータが正当化しない解釈を支えることがあります。
たとえば、最も強い顧客関係を特定するよう求められた架空の財務アシスタントを考えてみましょう。「最も強い」は、売上、継続率、収益性、戦略的重要性のいずれを指す場合もあります。確認せずに一つの解釈を選べば、レコードを取得する前から回答の方向性が決まってしまいます。
問題は必ずしも計算ミスではありません。アシスタントは、選択した指標を正しく計算しているかもしれません。失敗は、その指標がビジネス上の問いに答えているかどうかに関わります。
ここでOracle AIガバナンスはナレッジマネジメントと交差します。組織には、用語、承認済みの指標、関連コンテキストを継続的に管理した記録が必要です。アクセスを規定するポリシーは、こうした定義の代わりにはなりません。
情報システムを比較する読者にとって、個人とチームの知識の違いは有用な背景となります。個人の理解と組織の定義は、異なる目的に役立ちます。ビジネス上の回答には、対象業務に適した権威ある情報源が必要です。
分析上の課題は、誰の解釈をシステムの一部とするかを決めることです。営業責任者と財務責任者は、正当な理由から同じ用語を異なる意味で使うことがあります。有用な実装は、すべての質問を一つの意味に黙って標準化するのではなく、そのコンテキストを保持すべきです。
フィードバックは別の責務ももたらします。回答の修正は特定のやり取りを改善できますが、共有された定義は将来の質問にも影響します。特に複数のチームが同じ概念に依存している場合、変更はより広い影響を考慮してレビューする必要があります。
したがって、買い手は明白な答えの質問だけでなく、曖昧さを含む例を求めるべきです。要件が十分に定義されていない依頼に対するシステムの応答は、確認を求めるのか、前提を明示するのか、それとも解釈を確定した事実として提示するのかを明らかにします。
回答品質にも適切な評価基準が必要です。過去の回答が古い定義を使用していた場合、過去の回答との一致だけでは不十分です。レビューのプロセスは、一貫性と正確性を区別する必要があります。
こうした考慮は、データベース制御の重要性を弱めるものではありません。なぜ設計図がセキュリティだけにとどまらないのかを説明するものです。不正アクセスの防止と意思決定に値する回答の生成は、同じアシスタントが両方のタスクを担う場合でも、別の目標です。
ナレッジワーカーにとって、これが最も直接的な意味合いです。ビジネス上の前提が見えないままであれば、洗練された回答も精査に値します。エンタープライズの信頼には、権限の境界と並んで、理解可能な定義と追跡可能な推論が必要です。
Oracle Deep Trust AI Architectureは、これらの責務を一つのストーリーにまとめています。その有効性は依然として、組織の知識の質と、回答の検証に用いる証拠に左右されます。
信頼の主張には依然として導入の証拠が必要
この発表はOracleの設計上の立場を示すものですが、顧客環境への導入におけるセキュリティや正確性を独立して立証するものではありません。
AIが回避できない保護に関するOracleの広範な表現は、構成された制御の範囲内で読むべきです。それを、企業システム全体が悪用を受けないという主張に拡大解釈すべきではありません。
OWASPの過剰なエージェンシーに関するガイダンスは、不必要な機能、過剰な権限、過剰な自律性に伴うリスクを指摘しています。推奨事項には、能力の制限と、該当するユーザーのセキュリティコンテキスト内でのアクション実行が含まれます。
このガイダンスは、権限を制限するというアーキテクチャ原則を支持します。ただし、Oracleの実装を評価したものではありません。この違いは重要です。設計原則との整合は、特定の製品や構成に関する証拠の代わりにはならないからです。
慎重な評価では、意図的な攻撃だけでなく、日常的な誤りも検討すべきです。アシスタントは依頼を読み違えたり、誤ったレコードを選択したり、ユーザーが意図しなかったアクションを試みたりする可能性があります。制御は、このような条件でも理解可能な結果を生み出す必要があります。
信頼できない素材に埋め込まれた指示にモデルを従わせようとするプロンプトインジェクションは、別のテスト領域を加えます。買い手は、モデルが悪意ある指示を認識するかどうかとともに、その試行後にもどの権限が利用可能なままなのかを検証すべきです。
分析の中心的な問いは、失敗の結果です。モデルが誤動作した場合、どのアクションがなお実行され得るのでしょうか。この結果を評価することは、アシスタントが一般に指示へ従うかを問うより有用な証拠を生みます。
好意的なアナリストのコメントにもコンテキストが必要です。Oracleが公開したアーキテクチャの信頼に関する見解では、theCUBE ResearchのDave Vellante氏は統合作業を減らせる可能性を見ています。同氏は同時に、ポリシー、検証、導入ガバナンスについては企業側に責任が残ると強調しています。
これらのコメントはOracle自身のサイトに掲載されています。独立した比較テストではなく、ベンダーが選んだ、出典が明記された外部の見解です。読者は、この発表への評価を判断する際にこの違いを保つべきです。
本記事でレビューした資料には、全体的なセキュリティや回答精度を立証する独立した比較ベンチマークは含まれていません。これは、このローンチから導ける結論を限定します。制御が効果を持たないことを示すものではありません。
導入の証拠には、システムが拒否した正当な業務も含めるべきです。制限は望ましくないアクションを防ぐ一方で、必要なタスクも阻害することがあります。過剰な拒否は、従業員を手作業の回避策へ向かわせ、意図したプロセスを弱める可能性があります。
同様に、施行が成功した場合には、調査に十分な情報が残るべきです。チームは、どのIDが依頼を開始し、どのルールが適用され、どのような結果になったかを理解する必要があります。理解可能な説明のない拒否は、別の運用上の負担を生みます。
適切な結論には境界があります。Oracleは、信頼できるアーキテクチャ上の問題と、それに対応する統合的なアプローチを示しました。買い手には依然として、自社環境向けに構成した選択済みコンポーネントが、重視する失敗に対処できることを示す証拠が必要です。
2027年初頭までに買い手が注目すべきこと
次に有用な証拠は、導入可能性、測定された挙動、運用上の責任主体に関するものです。
最初のシグナルは、買い手が利用する予定の特定の機能について、導入に関する明確さです。2027年初頭にかけて、顧客はサポート対象環境、前提条件、制限事項、コンポーネントの提供状況を網羅する正確なドキュメントを求めるべきです。
この情報は、広範な設計図を評価可能な実装へと変えることで、Oracle Deep Trust AI Architectureの実用的価値を高めます。全体設計が魅力的であっても、要件に関する不確実性が続けば、導入計画は難しくなります。
このシグナルが重要なのは、エンタープライズ環境が異なるためです。組織は、提案のどの部分が自社の現行システムに適用されるかを判断できるべきです。アーキテクチャ範囲に関する一般的な説明では、コンポーネント単位の導入に関するすべての問いには答えられません。
二つ目のシグナルは、失敗事例を含む評価の証拠です。有用な結果では、不正な依頼、誤った解釈、許可されたアクション、制御が拒否する正当なタスクを検証します。買い手は、明確に説明されたセットアップと明示的な制約を探すべきです。
外部評価や文書化された顧客評価による証拠は、もう一つの一般的な支持表明よりも強い信頼をもたらします。狭いデモンストレーションに限定された結果は、より限定的な結論を支えるにとどまります。
重要なのは、評価が示される主張と一致しているかどうかです。一つの禁止された依頼が失敗することを示すテストは、関連しないアクションまでを対象とすることの証明にはなりません。定義済みの質問セットにおける精度結果を、普遍的な信頼性の主張にすべきではありません。
三つ目のシグナルは、時間の経過とともに制御を運用する顧客の証拠です。組織は、ポリシー変更、IDの更新、例外処理、保守について説明する事例に注目すべきです。こうした詳細は、初期導入後もアーキテクチャを管理可能な状態に保てるかを明らかにします。
ここで競合比較もより有用になります。OracleとAWSのドキュメントは、異なる実施箇所を説明しています。顧客の経験は、データベース、アプリケーション、外部サービスが実際に混在する環境で、カバレッジ維持に必要な作業を明確にする助けになります。
これらのシグナルは、いずれも市場の勝者を予測する必要はありません。アーキテクチャが実用的価値を提供するかを評価する方法を示しています。明確な導入要件、関連性のある評価、責任ある運用は、Oracleの主張を強めるでしょう。
開発者にとって直接的な意味は、アクションの生成とその認可を区別することです。エンタープライズの買い手にとっては、実施境界における証拠を求めることです。ナレッジワーカーにとっては、回答を支える定義を問うことです。
アシスタントの権限を拡大する前に、チームがルールと結果を理解しているワークフローを選んでください。ベンダーには、そのワークフローを使って、許可された依頼、禁止された依頼、曖昧な依頼を示すよう求めてください。モデルが誤った選択をした場合に何が起きるかを確認し、その結果生じるポリシーまたは知識の修正を誰が担うのかを明確にしてください。製品名を承認とみなすのではなく、実際の導入に証拠を結び付けてください。Oracle Deep Trust AI Architectureは、その議論の具体的な出発点を提供します。次のような明確な問いに用いてください。アシスタントが次の手順を誤ったとき、どの制御が、その誤りがビジネス上のアクションになることを防ぐのでしょうか。
