企業内データをより柔軟に活用する方法として、第2回ではRAGを、第3回ではAIエージェントを取り上げ、生成AIが業務にもたらす可能性を紹介してきました。
しかし、実際の現場ではこうした仕組みを十分に活かせている企業はまだ多くありません。
その背景にはさまざまな理由があり、生成AIがデータにアクセスするためのガバナンスやセキュリティの整備が追いついていないことも要因の一つです。
生成AIがどのデータにアクセスするのか、どの情報が回答に含まれるのか——こうしたポイントが見えにくいことが企業の足踏みにつながっています。
一方、これらの懸念が解消された世界では、生成AIが安全に企業データへアクセスし、業務の自動化や高度な意思決定支援が進み、企業や社員が“安心して生成AIに任せられる”世界が一気に広がります。
こうした未来に近づくためには、企業データを扱う基盤側のセキュリティとガバナンスの強化が不可欠です。
今回はその観点からOracle Database が備える機能に注目します。

目次

1　はじめに

生成AIの登場によって、私たちの業務の在り方は大きく変わり始めました。
文章生成や要約といった「手を動かす作業」の効率化にとどまらず、近年は生成AIを業務に深く組み込むための技術として、社内データを取り扱うことができるRAG（Retrieval-Augmented Generation）や、自律的に考えて業務フローを代行するAIエージェントが注目されており、業務プロセスそのものを変える技術として進化しつつあります（それぞれ下記過去ブログで紹介しているので、詳細はそちらをご覧ください）。
RAG：【Oracle×生成AI　第2回】社内ナレッジ活用のユースケースで考えるRAG実現のポイント | NEC
AIエージェント：【Oracle×生成AI　第3回】新機能 Select AI Agent を試して分かった AI エージェントの使い道 | NEC

一方で、現場の実態として「AIを活用したいが、セキュリティの壁が高くて導入が進まない」という声は少なくありません。
生成AIの利用が広がるにつれ、機密情報の漏えい、意図しないデータ利用、権限のないユーザーによる参照、監査不能な利用、プロンプト経由の情報流出など、生成AIが登場したことで起こり得るさまざまなセキュリティリスクも顕在化してきました。
こうした背景から、生成AI利用に関する社内ガイドラインやルールを整備する企業も増えています。
しかし、問題はその“ルールをアプリケーションに落とし込む”段階です。生成AIを扱うアプリケーションのセキュリティ設計では、機密データの保護、アクセス管理、監査、暗号化、データの持ち出し制御など、検討すべき項目が多岐にわたり、実装・運用の難易度が一気に上がります。結果として、ルールはあるのに適用が追いつかず、PoCで止まってしまうケースも起こりがちです。

こうした状況で重要になるのが、アプリ側で全て作るのではなく、データ基盤におけるセキュリティ機能も活用していくことです。
個々のアプリケーションで全てのセキュリティ要件に対応するのではなく、共通基盤となるデータ基盤側でセキュリティ機能を導入することで要件充足までの距離を大きく縮められます。

AI／RAG／AIエージェント活用においては、どのデータへのアクセスを許可するのかが、セキュリティの面だけでなく回答の精度にも大きく関わってきます。そのため、本ブログでは「データへのアクセス制御」と 「データ保護」に着目します。数あるデータベースの中でも、Oracle Databaseはセキュリティ機能の強化にも注力しており、生成AIで企業データを活用する際に役立つセキュリティ機能が豊富に用意されています。そこで、今回は実務に効くOracleのセキュリティ機能についてご紹介します。

2　生成AI活用におけるアクセス制御、データ保護の必要性

生成AI活用において重要度が高いセキュリティ項目である「アクセス制御」と「データ保護」について、その必要性を改めて整理します。
RAGやAIエージェントを用いたシステムでは、生成AI（LLM）やAIエージェントが、社内文書やデータベースといった企業データへ“直接”アクセスして回答や処理を行います。便利になる一方で、権限やどのデータを使ってよいかの整理が不十分なまま連携すると、ユーザーの意図しないデータ参照や操作が発生するリスクが高まります。

例えば、AIエージェントに「顧客一覧を出して」と依頼した場面を考えます。
データベースの顧客情報は「自分が担当の顧客」のみ閲覧可能なルールにもかかわらず、生成AIが「全ての顧客情報」を取得してしまい、本来は参照してはいけない顧客情報が見えてしまう――といった事故は現実に起こり得ます。
これは「AIが間違える」こと自体よりも、 “本来触れてはいけないデータ”へ到達できてしまう点が本質的な問題です。

こうした課題に対してまず検討される対応が「とにかくアクセスを厳しく制限する」ことです。しかし単純な締め付けは利便性を犠牲にすることに繋がります。例えば、今度は内部向け資料として「原価情報を参照して作成してほしい」といった正当な業務ニーズが出たときに対応できず、生成AI活用の利便性や業務スピードを落としかねません。また、要件に合わせてアクセス権限を変えたアプリケーションやAIエージェントを作成するという方法もあります。しかし管理対象が膨大になり、管理が煩雑になりかねません。
つまり重要なのは、「アクセスを止める」ことではなく、生成AIを利用するユーザーの役割（職種・部署・権限）や利用目的、データの機密区分に応じて、生成AIが参照できるデータ範囲を変えるなどの柔軟なアクセス制御を行うことです。
Oracleでは、データベース上のデータに対して柔軟なアクセス制御を実現する機能としてVPDとData Redactionがあります。次の章で詳しくご説明します。

3　Oracle Databaseが提供する柔軟なアクセス制御機能

ここからは、Oracle Database上で実現できるアクセス制御機能として、VPDとData Redactionを紹介します。

3.1 VPDによる見せるデータの制御
VPD（Virtual Private Database）とは、テーブルの行や列レベルでのアクセス制御をデータベース側で行う仕組みです。ユーザーが書いたSQLに対して、動的に条件を付与し、データベース側で強制的にアクセス制御を適用できます。
例えば従業員の情報をまとめたテーブルに対し、部門ごとに見せるデータを制御したい際は、アクセスルールとして「人事部はすべての従業員データにアクセス可、他の部門は自身の部門のデータのみアクセス可」というルールを作成し、テーブルに付与しておきます。
従業員テーブルにアクセスされると、ユーザーの属性に合わせて、SQL文に条件文を付与し見せるデータをコントロールできます。

生成AIがどのようなSQLを生成・実行するのかコントロールをすることは難しいですが、VPDを設定しておくことで、生成AIやユーザーがどのようなSQLを生成しても、データベース側でアクセス可能な範囲を制御できます。

3.2 Data Redactionによるデータの見せ方の制御
Data Redactionとは、ユーザーに合わせてデータの見せ方を変える仕組みです。ユーザーがSQL文を発行すると、ユーザーの属性に合わせて全て伏字にしたり、データの一部のみを見せたりなどの設定ができます。
先程と同様の従業員データに対して、部門ごとにデータの見せ方を制御したいとき、「人事部以外は給料列をマスキングする」というルールを作成し、テーブルに付与しておきます。
従業員データにアクセスされると、アクセスしたユーザーの属性に合わせて、データの見せ方をコントロールできます。

Data Redactionはデータを“保持したまま隠す”仕組みです。ユーザーに与えるデータの粒度を制御することで、必要以上の情報を与えないようにすることが可能になります。

見せるデータの“範囲”を制御する VPD と、データの“見せ方”を制御する Data Redaction を組み合わせることで、生成AIによる企業データ活用を、より安全かつ柔軟に進めることができます。
次の章では、営業部・マーケティング部など実際の業務シナリオを例に、これらの機能がどのように働き、同じ質問でもユーザーによって結果がどのように変わるのかをご紹介します。

4　生成AI×アクセス制御のユースケース

ここからは、生成AIによる企業データ活用において、アクセス制御とデータ保護がどのように役立つのかを、業務シナリオをもとに紹介します。

• 4.1 シナリオ
  〇△株式会社では複数の商品を展開しており、販売に関わる情報はOracle Database（Autonomous AI Database）上で一元管理されています。
  部門ごとの利用シーンは以下の通りです。
  ・　営業部：自分の担当エリアのお客様の購入状況を把握したい
  ・　マーケティング部：全体の注文の傾向を分析したい
  
  しかし、この作業は長年「手作業」で行われており、次のような課題がありました。
  ・　営業部：SQLを書く必要があり、担当者によって得意・不得意がある
  ・　マーケティング部：SQLの記述に加えて、分析作業にも時間がかかる
  
  

そこで、〇△株式会社では 生成AI を活用して業務効率化を進めることにしました。
Oracle Database が提供する Select AIを利用すれば、自然言語で「このエリアの売上を教えて」のように質問するだけで、必要な情報を取得できます。

Select AIによりデータ取得は簡単になりますが、次は部門ごとに閲覧してよいデータの範囲が異なるという問題が顕在化します。顧客情報に関しては次のような要件がありました。

生成AIに部門ごとのアクセスルールを教えたとしても、そのルール通りにデータの取得を行うのかは確実ではありません。
そのため、ユーザーの属性に応じて、見せるべきデータの範囲と表示方法を制御する仕組みが必要になります。これをVPDとData Redactionを用いて実現します。

4.2 動作結果
VPDとData Redactionを使うことでどのような結果になるのかを確認します。
営業部が見るデータの要件に合うよう、顧客テーブルに”マーケティング部は全件、営業部は自身の担当エリアのお客様のみアクセス可”というルールのVPDを適用します。
また、マーケティング部の要件に合わせて、顧客テーブルに”マーケティング部は個人情報の列をマスキングする”というルールのData Redactionを適用します。
では、実行結果を見ていきましょう。

営業部の担当者としてデータ取得
担当エリアが愛知県の営業部ユーザーとして、顧客情報を取得するような質問をしてみました。

Select AIが作成したSQLはすべての顧客データを出力するようになっていますが、得られた結果は愛知県の顧客のみになっています。
データへのアクセスの際、ユーザーが営業部であるというセッション情報を基にVPDによってアクセス制限がされていることがわかります。

マーケティング部の担当者としてデータ取得
次に、マーケティング部の担当者として質問した場合、どのような動作になるか確認します。

このように、マスキングするような指示を出していないにもかかわらず、Data Redactionによって顧客情報がマスキングされた状態で出力されました。

営業部とマーケティング部で同じ質問をしているにも関わらず、VPDやData Redactionによって実行結果が変わることが確認できました。

このようにVPDで“見せるデータの範囲”を、Data Redactionで“見せる内容”を制御することができます。
これらを組みあわせることで、生成AIがどんな問い合わせを行っても、ユーザーごとに適切なデータのみを安全に返すことができます。
企業が持つデータを“安心して生成AI活用できる状態”を、データベース側で実現できるのが大きな強みです。

5　おわりに

今回は生成AI活用時におけるセキュリティ・ガバナンスの観点から、VPDとData Redactionをご紹介しました。生成AIがアクセスしてよいデータを基盤側で設定しておくことで、より安全に企業データ活用を進めることが可能になります。

本記事が、皆様の業務効率化や新しい価値創出の一助になりましたら幸いです。
本記事の内容について詳しく知りたい方は、以下よりお問い合わせください。

お問い合わせ