※本記事は、Allen Hosler による”Secure Agents, Built for the Enterprise” を翻訳したものです。
2026年5月5日

先週、私たちのチームは DeveloperWeek 2026 に参加し、AI 分野における最新の取り組みについて話を聞きました。ほぼすべての会話で中心となっていたテーマが 1 つあります。

セキュリティです。

以前は、モデル性能やプロンプト・エンジニアリングに焦点が当てられていました。今年、議論は変化しました。組織はエージェントに期待を寄せていますが、より難しい問いを投げかけています。

エージェントは自社のデータを安全に使用しているのか？

この問いは、見かけよりも複雑です。エージェント時代のセキュリティには、次のような要素が含まれます。

  • データ漏えいからの保護
  • 認証情報と API トークンの管理
  • エージェント・ランタイムの保護
  • オーケストレーション層のガバナンス
  • MCP サーバーとツール統合の制御
  • モデル・ガバナンス（どのモデルを許可し、どこで使用できるか）
  • デプロイと変更の監査可能性

そして、このリストは今も増え続けています。

一方で、初期段階のエージェント実験の多くは、ノート PC 上で行われています。開発者がエージェント・フレームワークをインストールし、個人の API キーを貼り付け、企業ドキュメントをアップロードして、それを社内システムに接続します。

それは動きます……動かなくなるまでは。

企業データがサードパーティ・ツールに送信されます。トークンは環境変数に置かれます。利便性のために権限は過度に広くなります。どのエージェントがデプロイされ、どこで実行され、どのデータにアクセスできるのか、誰も追跡していません。

Oracle AI Database 上でミッション・クリティカルなシステムを稼働している大規模組織にとって、このモデルは採用できません。

これらはまさに、Oracle AI Database Private Agent Factory が解決するために設計された課題です。

今日のエージェント環境におけるエンタープライズ・ギャップ

エージェントが強力なのは、データをまたいで推論し、ツールを呼び出し、自律的にアクションを実行できるからです。

しかし、ガバナンスのない自律性はリスクをもたらします。

実践的な例として、AWR Analysis Agent を考えてみましょう。

AWR Agent のユースケース

すべての Oracle Database は、Automatic Workload Repository（AWR）レポートを生成します。このレポートは、多くの場合 100 ページを超える詳細なパフォーマンス診断情報で構成されます。

従来、DBA はレポートを手作業でレビューしており、適切に分析されるのはその一部に限られていました。つまり、パフォーマンス劣化がすでに発生した後で、ようやく知見が得られる可能性があるということです。場合によっては、知見が得られないこともあります。

2026 年には、このアプローチはもはや十分ではありません。

エージェントは次のことを実行できます。

  • AWR レポートを自動生成する
  • ドキュメント全体を数秒で解析する
  • 過去のベースラインと比較する
  • 異常な待機イベントや SQL リグレッションを特定する
  • 推奨されるフォローアップ・アクションを含む簡潔な要約を提供する

これは真の運用レバレッジですが、同時に攻撃対象領域も拡大します。

エンタープライズ向けのツールがない場合、DBA はレポートを何らかのサードパーティ AI ツールにアップロードしてしまうかもしれません。一度貼り付けられただけでも、その情報は永久に漏えいしたことになります。

AWR レポートには、システム構成、ワークロード・パターン、インフラストラクチャ設計に関する詳細が含まれています。悪意あるサードパーティがシステムを停止させるために必要とする詳細がすべて含まれているのです。

その情報は、管理された環境の外に出してはなりません。

Private Agent Factory が変えるもの、そして実際にはどのように見えるのか

Oracle AI Database Private Agent Factory は、Oracle エコシステム内でエージェントを直接構築、デプロイ、管理するための、ガバナンスされた環境を提供します。

エージェントを個人の認証情報で個々のノート PC 上に実行する代わりに、次のことが可能になります。

  • 承認済みモデルを定義する
  • 承認済みデータ・ソースを定義する
  • Oracle IAM とデータベース・セキュリティ制御を使用する
  • 管理された環境にエージェントをデプロイする
  • エージェント定義とデプロイを一元的に追跡する

これにより、アドホックな実験から、管理された自動化へ移行できます。Oracle Database が記録システムである組織にとって、この違いは重要です。

セキュアなアーキテクチャ: AWR Agent の再考（アイデアからガバナンスされたフローへ）

Private Agent Factory を使用すると、同じ AWR Analysis Agent はまったく異なるものになります。

エージェントは、次のようなフローとして定義されます。

  • Oracle が管理する環境内で実行される
  • ガバナンスされたロールを通じてデータベースにアクセスする
  • 承認済みの OCI ホスト型モデル、または社内にデプロイされたモデルのみを使用する（たとえば企業は、vLLM や Ollama のようなフレームワークを通じて、自社のオンプレミス LLM をホストできます）
  • 誰がデプロイまたは呼び出しできるかを定義する IAM ポリシーによって管理される
  • やり取りをクラウド環境またはオンプレミス環境内に保持する

アクセスは明示的に定義されます。

  • どのデータベースに接続できるか
  • どのビューまたはプロシージャを呼び出せるか
  • 過去の AWR データにアクセスできるか
  • どのロール（例: DBA）が呼び出せるか

個人の API キーは不要です。
ローカル環境変数は不要です。
不明なサードパーティへの送信はありません。

実験からエンタープライズ・デプロイメントへ

エージェントの導入は、通常ボトムアップで始まります。初日からガバナンスを開始しなければ、データ漏洩も始まります。Private Agent Factory により、組織は次のことが可能になります。

  • 承認済みエージェントのカタログを維持する
  • エージェント定義をバージョン管理する
  • 環境全体にわたってデプロイを追跡する
  • モデル利用を認可済みエンドポイントに制限する
  • 一貫したセキュリティ・ポリシーを適用する

これにより、IT リーダーシップには可視性が、運用チームにはスケーラビリティがもたらされます。個々の DBA が保守する単発のスクリプトではなく、AI 支援ワークフローを標準化できます。

  • 本番環境向けの AWR Agent
  • 開発環境向けの別バージョン
  • キャパシティ・プランニング分析エージェント
  • コンプライアンスまたは監査向けの追加エージェント

すべてを一元的にガバナンスできます。

DBA が体験すること、そしてそれが重要である理由

ガバナンスは、セキュアな自動化を利用可能なものにします。
DBA は、次のような率直な質問をできるべきです。

  • 自分のデータベースが直面している最大のリスクは何か？ 今週実施すべきアクションはあるか？

そして、AWR データに基づいた、簡潔で運用上有用な回答を受け取れるべきです。レポートを公開ツールにコピーしたり、機密診断情報をエンタープライズ境界の外へ移動したりする必要はありません。

実践的な前進の道筋

エージェントはすでに組織全体で構築され始めており、多くの場合、正式な監督なしに進められています。リーダーシップは、自社の AI 戦略をどちらにするのかを決める必要があります。

追跡されず、認証情報に基づくもの
または
ガバナンスされ、ポリシー主導のもの

Oracle AI Database Private Agent Factory は、Oracle Database のお客様が、セキュリティ、ガバナンス、運用上の制御を損なうことなく、エージェント主導の自動化を活用できるようにします。

AWR 分析のような焦点を絞ったユースケースから始めてください。測定可能な価値を示してください。既存の Oracle セキュリティ・モデルの外へ出ることなく、意図的に拡張してください。

実際に体験したい場合は、live lab を確認し、最初のガバナンスされたエージェントを構築してください。

エージェントは、組織の運用方法を再構築していくでしょう。成功する組織は、迅速に、そして責任を持って実験を進める組織です。