AIエージェントが社内データを読み取り、問い合わせに答えるデモは動きました。それでも、顧客情報へのアクセスや夜間の障害対応を考えると、本番稼働には踏み切れません。Oracleが問題視しているのは、この「動くこと」と「業務を任せられること」の間にある隔たりです。

同社は、データを保護する仕組みやサービスを止めずに更新する能力を、エージェント向けのデータ基盤に求められる要件として説明しています。企業が見極めるべきなのは、回答の見栄えだけではありません。

Oracleでデータウェアハウスおよび自律型データベースの製品・研究を統括するエグゼクティブ・バイスプレジデントのÇetin Özbütün氏によると、約70％の組織がAIエージェントの導入を計画している一方、本番環境で稼働させている組織はごく一部にとどまります。この数値は同氏が示したもので、調査対象や集計方法の詳細は今回確認できた情報には含まれていません。市場全体の普及率として扱うには留意が必要です。

Özbütün氏は、Oracleのイベント「Oracle AI World」で、テクノロジー分野のインタビュー配信を手がけるtheCUBEに登壇しました。企業がAIを本番導入する際には四つの困難に直面すると述べていますが、今回の説明で具体的に掘り下げられているのは、主にセキュリティと、障害や更新に耐えてサービスを継続する能力です。



デモでは、対象データや利用者を絞り、処理が成功するかを確かめられます。本番環境では、担当者によって参照できる情報が異なり、利用の集中や障害も想定しなければなりません。エージェントが必要な情報を取得できても、取得してはいけない情報まで読める状態では、業務への適用範囲を広げにくくなります。

この違いから考えると、実証実験の次の評価項目は回答精度だけでは不十分でしょう。誰の権限で処理し、どのデータに触れ、失敗時にどこまで影響するのかを確認する必要があります。Oracleの説明は、エージェント導入をモデル選定だけで捉えず、それを支えるデータ基盤まで含めて判断する視点を示しています。

Özbütün氏は、本番導入の最初の難所としてセキュリティを挙げています。AIエージェントに安全なデータアクセスを提供することは難しく、企業にとって主要な課題の一つになっているという説明です。また、AIエージェントによる脆弱性の発見が進むなか、攻撃者に悪用される前に顧客がデータベースを修正しきれない場合があるとも指摘しています。

OracleのAutonomous AI Databaseは、運用の自動化を特徴とするデータベースサービスです。同氏によると、保存中と通信中のデータは標準で暗号化され、利用者がその保護を無効にすることはできません。脆弱性への修正についても、広く公表される前に同サービスへ適用する運用を説明しています。いずれもOracle側が示した製品・運用上の特徴として受け止める必要があります。



ここで区別したいのが、暗号化とアクセス制御です。暗号化は、保存媒体や通信経路などでデータの内容を保護する仕組みです。対してアクセス制御は、誰がどの情報を読んだり更新したりできるかを決めます。データが暗号化されていても、エージェントに広すぎる閲覧権限を渡していれば、その権限による取得まで防げるわけではありません。

企業の導入担当者にとっては、暗号化が標準で有効かという確認に加え、エージェントへ渡す権限の範囲を具体化することが欠かせません。例えば、顧客への回答を支援する用途なら、その処理に必要な顧客情報と、不要な社内情報を分けて考えられます。製品の保護機能と、自社が設定する権限の両方がそろって初めて、安全な利用条件を検討できるでしょう。

エージェントが昼夜を問わず処理を続けると、データベースには重く、予測しにくい負荷がかかります。Özbütün氏は、セキュリティに続く課題としてレジリエンス、つまり障害や変化があっても機能を維持する能力を挙げました。人が画面を操作する業務と比べ、処理の発生時間や回数を人の勤務時間だけで見積もれない点が、運用設計の論点になります。

Oracleは、除外条件を設けない99.995％の可用性を約束していると同氏は説明しています。その判定基準は、基盤となるインフラが動作しているかではなく、クライアントが接続してクエリを実行できるかです。クエリとは、データの検索などをデータベースに依頼する処理を指します。利用者が業務を続けられる状態を基準に据えている点が、この説明の焦点です。



この数値だけで、自社の業務全体の稼働率を判断することはできません。エージェントの処理には、モデルを呼び出すサービス、認証、ネットワーク、業務アプリケーションなども関わるためです。データベースへの接続が成功しても、別の部分で処理が止まれば、利用者は目的を達成できない場合があります。

導入時には、サービスの可用性に関する説明と、自社の業務が完了する条件を結び付けて確認したいところです。問い合わせへの回答が必要な用途なら、接続できることに加え、必要な時間内に検索結果を得られるかも評価対象になります。契約上の適用範囲や測定方法を確認し、実際の利用に近い負荷で試すことで、提示された数値を業務上の判断材料として扱いやすくなります。

セキュリティ修正を急ぐほど、サービス停止の調整が難しくなることがあります。Özbütün氏は、Oracleが週次でシステムにパッチを適用し、その間もデータベースが新しい接続やリクエストを受け付けると説明しています。修正のために処理を止める時間を確保するのではなく、稼働中に更新できる仕組みを運用の前提に置いています。

同氏は、顧客が定義したセキュリティ設定をデータベース側で強制する「Deep Trust AI」アーキテクチャにも言及しました。拡張された「Deep Data Security」のような新機能は、オンプレミス向けの提供に先行して、発表時点でAutonomous AI Databaseから利用できるとしています。オンプレミスとは、企業が自社で管理する設備などにシステムを設置・運用する形態です。



Oracleが強調しているのは、利用者や管理者が機能を受け取るための更新作業をしなくても、新しい能力を使えるようになる点です。一般に、企業側で更新の準備や停止調整を行う負担が減れば、修正適用を待つ時間の短縮につながると考えられます。ただし、今回の情報から、個々の企業でどれほど工数が減るかまでは判断できません。

機能が利用可能になることと、自社の業務に合わせて使うことも別の作業です。どの情報を保護対象とし、誰にどの範囲の利用を認めるかは、企業側で定義する必要があります。運用が自動化されるほど、管理担当者の仕事は更新作業から、設定の妥当性や実際の挙動を確かめる仕事へ移っていくでしょう。自動化の範囲を把握し、社内で判断すべき事項を明確にすることが導入準備になります。

今回の説明から読み取れるのは、データベース提供企業が、データの保存・検索に加えて、エージェントの安全な利用と継続稼働を支える役割を打ち出していることです。これはOracleの提案の方向性として理解できます。ただし、同社の説明だけから、ほかの選択肢との優劣や、特定企業への適合性まで結論付けることはできません。

企業が比較を進める際には、製品の機能名をそのまま評価項目にするより、業務で満たすべき条件へ置き換えると整理しやすくなります。暗号化なら対象となるデータや通信の範囲、アクセス制御なら部署や利用者ごとの制限、可用性なら接続と処理が成立する条件、更新なら業務への影響を確認します。説明されている機能が、自社のどの課題に対応するのかをたどる進め方です。



費用についても同じ姿勢が必要でしょう。エージェントが検索を繰り返す設計では、処理回数や実行時間が増える可能性があります。これは一般的な設計上の論点であり、今回、Oracleが具体的な費用削減効果や料金比較を示したわけではありません。導入予算を判断するには、想定する利用件数と、一件の業務で発生する処理を確認する必要があります。

調達の段階では、「安全に使える」「止まりにくい」といった言葉を、確認可能な条件にすることが有効です。例えば、閲覧権限の異なる利用者で同じ質問を試し、返される情報が適切に変わるかを確かめられます。判断の根拠を業務に近づけることで、デモの印象だけに依存せず、運用担当者や情報システム部門と導入条件を共有できるようになります。

日本企業がこの議論を自社に引き寄せるなら、エージェントに任せたい業務を一つ選び、必要なデータと権限を洗い出すところから始められます。例えば社内問い合わせへの回答支援なら、参照を許可する資料、利用する部署、回答を人が確認する場面を具体化できます。これは導入の進め方に関する提案であり、Oracleが今回公表した導入事例ではありません。

評価では、正しい質問に答えられるかだけでなく、権限外の情報を求められた場合や、データ取得に失敗した場合の挙動も確かめたいところです。処理を続けるのか、停止するのか、人へ引き継ぐのかが決まっていなければ、現場は障害のたびに判断を迫られます。小さな対象範囲で失敗時の対応まで確認することが、本番へ進む条件を明らかにします。



その結果を基に、データ基盤が提供する保護や更新の仕組みと、自社が担う設定・監視を対応付けます。自動化される作業が増えても、業務上の責任まで自動的に移るわけではありません。アクセス権限の承認、異常時の連絡先、利用範囲を広げる判断を誰が担うかを定めると、技術評価が実際の運用につながります。

なお、今回の発言はOracle主催イベントでのインタビューによるものです。theCUBEは同イベントの有償メディアパートナーであり、SiliconANGLEは、Oracleなどのスポンサーに編集内容を管理する権限はないと開示しています。製品提供側の説明という文脈を踏まえ、自社に必要な条件を個別に検証する姿勢が適切でしょう。

着手するなら、既存のデモを一つ選び、「必要な情報だけを読めるか」「更新や障害時に業務をどう扱うか」を担当部門と確認してください。そこで見つかる未解決事項が、モデルの調整で解く問題なのか、データ基盤や運用設計で解く問題なのかを分けることが、本番導入に向けた具体的な一歩になります。