RAGの限界と対応：社内データ連携における多層的なエージェントアーキテクチャの検討ポイント

解説

生成AIを活用した社内情報検索は注目されていますが、単にドキュメントをデータ化して「RAG（検索拡張生成）」を構築するだけでは限界に直面することがあります。

特に、部署や役職といった複雑な条件に基づいたアクセス権限の制御が難しくなる場合があるため、セキュリティ設計の見直しが必要となります。

本来目指すべきは、情報源ごとに最適な技術を選び、複数の検索・分析手段を組み合わせて動く「エージェント」のような仕組みを構築することです。

ポイント

• RAG（検索拡張生成）導入時に直面する「複雑な権限制御」「検索精度低下」などの限界点を提示。
• 単一の手法に依存せず、データ特性や課題の性質に応じて複数の検索・分析手段を組み合わせるエージェントアーキテクチャへ移行した経緯を紹介。
• 具体例として、API呼び出しやデータベースの行レベルセキュリティ（RLS）を活用し、安全性と柔軟性を両立させる次世代のアプローチを示す。

情シスへの影響

■社内情報検索エージェント構築

従来：全データをベクトルストアに集約しセマンティック検索を行う「とりあえずRAG」を採用。

問題点：複雑な属性（部署・役職）に基づくドキュメントレベルのアクセス権限を表現できない。

採用戦略：「Agentic Search」へ移行。FAQシステムなど既存システムが持つAPIをAIエージェントから呼び出し、元々の権限制御ロジックを利用する構成を採用。これにより、データ同期や新規権限実装の手間を排除し、セキュリティと利便性を両立させている。

■日報分析エージェント構築（構造化データの利用）

目的：フリーテキストの日報データから組織的な課題を抽出し、AIで分析する仕組みの構築。

採用戦略：「自然言語からSQLへの変換」（NL2SQL）を利用し、データをAWS RedshiftなどのDWHに集約。これにより、横断的かつ構造的な分析が可能となる。

セキュリティ強化：単なるアプリケーション層の制御では不十分なため、Amazon Redshiftの「RLS（Row Level Security）」を適用。AIエージェントが生成したSQLであっても、DBレベルで閲覧権限のないレコードを物理的に除外する仕組みを採用し、安全性と柔軟性を両立させている。

影響範囲

【対象システム】

• 社内情報検索システム（ブログ、FAQなど複数の情報源）

• 日報データ管理・分析基盤（DWH: Amazon Redshiftなどが想定される)

• AIエージェントを稼働させる環境（Amazon EKSやAPI呼び出し機構）

【影響範囲】

• セキュリティ関連: 従来のRAGで考慮しきれなかった「アプリケーション層のアクセス制御の限界」と、これに対するDBレベルでの高度な権限制御（RLSなど）の必要性が浮上。

• アーキテクチャ設計: 単一のベクトルストア/セマンティック検索に依存するのではなく、「既存API」「ベクトル検索」「SQLクエリ実行」といった複数のツールを使い分けるエージェントワークフローへの移行が推奨される。

重要度

★★★★☆

対象者

• セキュリティ担当者
• M365管理者
• Entra管理者
• AD管理者
• ネットワーク管理者

優先度

早めに対応

優先度の理由

AI活用を進めるにあたり、単にデータを取り込むだけでなく、「誰が（ユーザー）」「どの属性の範囲で（権限）」「何ができるか」というガバナンス層での確認と設計の見直しが必要です。特にアクセス制御は情報漏洩リスクに直結するため、早めに検討すべき重要課題です。

確認手順

• 既存の情報検索・分析システムにおけるデータ連携の「単一障害点（SPOF）」を確認する。
• 全社的なデータの閲覧権限を、「アプリケーション層」「データベース層」「AIエージェントからのAPI呼び出し」のどこで制御するか、設計レビューを行う。
• 個人情報や機密性が高いデータを扱う場合、AWS RedshiftなどのDWHサービスにおけるRLS（行レベルセキュリティ）の実装可能性と工数を確認する。
• 社内データが複数のシステムに分散している場合、単一のエージェントワークフローを構築するためのAPIラッパー設計が必要な箇所を洗い出す。