社内DBの情報を生成AIから安全に使うには？RAGを含むシステム構成の考え方
- 15 時間前
- 読了時間: 8分
社内の顧客情報や案件情報、商品マスタ、社内規程、過去の問い合わせ履歴などを、生成AIへ質問するだけで探せたら便利です。
一方で、社内データを生成AIにつなぐ場合は、機密情報の漏えい、権限のない社員への情報表示、誤回答、DBへの過剰なアクセスなどを防ぐ設計が必要です。
重要なのは、LLMへ社内DBを自由に触らせることではなく、認証・認可を行うバックエンドで必要な情報だけを取得し、その結果だけをLLMへ渡すことです。
はじめに：安全性の土台は「AIへ何を渡すか」の手前にある
たとえば営業担当者が「A社との直近のやり取りを要約して」と質問したとします。
このとき、システム内部では次の順序で処理するのが基本です。
質問した社員が誰かを認証する
その社員がA社の情報へアクセスできるか認可する
社内DBや文書検索から必要な情報だけを取得する
取得結果をバックエンド側で必要な範囲へ絞る
その結果だけをLLMへ渡す
回答を返し、必要に応じて監査ログを残す
ここで重要なのは、「権限のない情報は答えないで」とプロンプトへ書くことを認可の代わりにしないことです。
認証・認可・取得範囲は通常の業務システムと同様にバックエンドで確定させ、その結果だけを生成AIへ渡します。
結論：社内データとLLMの間に「取得と認可の境界」を置く
社内データを生成AIから利用する場合、概念的には次のような往復構造になります。
利用者が業務画面やチャット画面から質問する
バックエンドが利用者を認証し、アクセス可能な範囲を決める
バックエンドが検索サービス、読み取り専用API、社内DBなどへ問い合わせる
取得結果がバックエンドへ戻る
バックエンドが回答に必要な情報だけを選び、LLMへ渡す
LLMの回答をバックエンド経由で利用者へ返す
この構成なら、LLMが社内DBへ自由にアクセスする必要はありません。
また、LLMや検索方式を後から変更しても、社内データへの認証・認可を独立して管理しやすくなります。
外部のLLMサービスを使う場合は、入力データの利用・保持条件、処理地域、管理機能など、そのサービスの公式条件も確認したうえで、送信可能な情報を決めます。
RAGが向いているのは「文章から必要な箇所を探す」場面
RAGはRetrieval-Augmented Generationの略で、質問に関連する文書やナレッジを検索し、取得した内容をLLMへ渡して回答させる構成です。
就業規則、マニュアル、FAQ、議事録、製品資料など、文章の中から関連箇所を探したい場合に向いています。
MicrosoftのRAG解説でも、機密情報を扱う場合は取得時にアクセス制御を適用し、取得したコンテンツ自体を信頼されていない入力として扱うことが示されています。
ただし、RAGへ入れる検索インデックスやベクトルストアは、元の社内文書から作られた別の保管場所です。元ファイルだけを保護すればよいわけではありません。
検索インデックス側でも、アクセス制御、暗号化、削除同期、バックアップ、保持期間などを考える必要があります。
OWASPも、ベクトルや埋め込みを使うRAGでは、不十分なアクセス制御による情報漏えいや、利用者グループ間の情報混在などをリスクとして挙げています。
構造化DBは、必ずしもRAGへ入れる必要はない
一方、売上、請求、商品マスタ、顧客ステータスなどの構造化データは、文章検索とは性質が異なります。
たとえば、
「今月のA商品の売上はいくらか」
「未入金の請求は何件あるか」
「A社の現在の契約ステータスは何か」
といった質問では、ベクトル検索よりも、既存の検索APIやSQLで正確に取得した方が自然な場合があります。
当社では、まず読み取り専用APIや用途を限定した検索処理を候補にします。
LLMは「どのAPIを、どの条件で呼ぶか」という要求を出せても、実際のAPI実行、入力値検証、権限判定はバックエンド側で行います。これにより、LLMへDBの接続権限そのものを渡さずに済みます。
より自由な集計が必要な場合は、自然言語からSQLへ変換するText-to-SQLも選択肢です。Amazon Bedrock Knowledge Basesでも、構造化データに対して自然言語からSQLを生成して検索する構成が提供されています。
ただし、任意のSQLを実行できる構成には注意が必要です。AWSも、制限されたロール、読み取り専用DB、サンドボックスなどの対策を推奨し、CREATE・UPDATE・DELETE権限を与えない構成を案内しています。
見積・構成を大きく変えるのは「誰が何を見てよいか」
生成AIと社内データをつなぐ案件では、AIモデルそのものより、既存システムの権限モデルを検索・取得側へどう反映するかが大きな設計分岐になります。
社内データの見え方 | 必要になる構成 | 発注時の影響 |
全員が同じ情報を見てよい | 共通検索・共通API | 比較的小さく始めやすい |
部署・役割で見える文書が違う | 文書へアクセス許可情報を付け、検索時に権限で絞り込む | 既存の権限情報を検索側へ同期する設計が必要 |
顧客・案件単位で見えるデータが違う | 文書単位の制御に加え、DB側の行レベルセキュリティ（RLS）やAPI側の条件制御 | テナント混在防止まで含めて設計・試験が増える |
AIから更新操作もしたい | 実行権限の最小化、入力検証、承認、監査 | 読み取り機能とは別フェーズとして分ける方が安全 |
Azure AI Searchにも、文書へアクセス許可情報を持たせ、クエリ時に利用者の権限で検索結果を絞る文書レベルアクセス制御があります。
このため、発注前には「RAGを作りたい」だけでなく、現在の社内システムで権限がどの粒度まで整理されているかを確認した方が、見積や構成を現実的に決めやすくなります。
よくある失敗：検索できてから権限制御を後付けする
たとえば、社内文書を一つの検索インデックスへまとめてから、後で部署別の閲覧制限を付けようとすると、元文書の権限情報を検索インデックスへ持たせ直し、同期処理や検索条件まで作り直すことがあります。
また、「権限のない情報は回答しないで」とシステムプロンプトへ書くだけでは、検索段階で機密情報そのものがLLMへ渡る可能性を消せません。
検索結果へ出してよいかどうかを、LLMへ渡す前に判定することが重要です。
さらに、RAGでは取得文書に悪意ある指示が混入する「間接的なプロンプトインジェクション」も考慮する必要があります。
OWASPは、RAGやファインチューニングだけではプロンプトインジェクションを完全には防げないとしています。
ログを残すほど安全になるとは限らない
監査のため、誰が何を質問し、どのデータを参照したかを記録することは重要です。
ただし、質問文、取得文書、生成された回答をすべて全文保存すると、ログ自体が顧客情報や社内機密を集約した保管場所になります。
そのため、単に「ログを残す」と決めるだけでは十分ではありません。
何をログへ残すか
誰がログを閲覧できるか
何日間保持するか
質問や回答の全文を残す必要があるか
個人情報や機密情報をマスキングするか
といった点まで決める必要があります。
監査のためのログが、新しい機密情報データベースにならないようにすることも、生成AI連携では重要な設計ポイントです。
当社では、まず「読み取り」と「権限境界」から設計する
プレイリーソリューションズでは、生成AIを特別な箱として考えるより、既存の業務システムと同じく、誰が、どのデータへ、どの条件でアクセスできるかを先に整理する方針を取ります。
初期段階では、AIから既存データを更新できる構成よりも、まず読み取り側へ閉じ、必要なデータだけを返すAPIや検索層を境界に置く方が、責任範囲を明確にしやすくなります。
特にJava / AWS等の既存バックエンドや社内DBがある場合は、既存システムを作り直すのではなく、認証・認可、API、検索処理、LLM呼び出しを必要な範囲だけ追加する構成も検討できます。
すべてのケースで大がかりなRAG基盤が必要なわけではありません。
まず対象業務を一つに絞り、
どの利用者が使うのか
何を質問するのか
どのデータまで見てよいのか
を決めるところから始める方が、PoCだけで終わらない構成につながります。
発注前に整理したい10項目
生成AIと社内データの連携を相談する前に、次の項目を整理しておくと構成を検討しやすくなります。
誰が生成AI機能を使うのか
どの社内データを参照したいのか
全員が同じ情報を見てよいのか
部署・役割・顧客・案件ごとに閲覧範囲が違うか
文書検索か、構造化DB検索か、両方か
読み取り専用の利用でよいか、AIから更新操作も必要か
用途を限定したAPIで対応できるか、自由な検索・集計が必要か
質問・取得内容・回答のどこまでをログへ残すか
外部LLMへ送信できない情報はあるか
回答が誤っていた場合、人が確認すべき業務か
これらを最初からすべて確定させる必要はありません。
要件が固まっていない段階でも、「何を生成AIへ任せたいのか」「現在どこにデータがあるのか」から整理を始められます。
外部サービスとのAPI連携全般の発注準備については、「自社システムと外部サービスをAPI連携するとき、発注前に整理すべき情報」でも整理しています。
まとめ
社内DBや社内文書を生成AIから安全に使うために、最初から「RAGを導入する」と決める必要はありません。
まず、利用者の認証・認可をバックエンドで行い、必要なデータだけを取得し、その結果だけをLLMへ渡す境界を作ります。
文書検索にはRAG、構造化DBには読み取り専用APIや検索処理、必要に応じてText-to-SQLというように、データの性質に合わせて取得方式を選びます。
そして、検索インデックス自体の保護、権限同期、プロンプトインジェクション、ログの保持範囲まで含めて初めて「安全な社内データ活用」の構成になります。
事業会社の方で、既存の業務システムや社内DBを活かしながら生成AI機能を追加したい場合は、要件整理・構成検討の段階からご相談いただけます。
