Retrieval Augmented Generation（RAG）は、大規模言語モデル（LLM）が応答を生成する前に外部ソースから積極的に情報を取得することで、より正確で信頼性の高い回答を生成するのに役立ちます。RAGは、モデルの内部知識からのハルシネーションを減らし、最新のデータに基づいて出力を生成します。RAGは信頼性を向上させますが、モデルが取得した情報を誤って解釈したり、矛盾するコンテキストに遭遇したり、重要な詳細を見落としたりすると、エラーが発生する可能性があります。
エンタープライズアプリケーションの場合、LLMは、製品ロードマップ、顧客履歴、内部ポリシーなどのビジネスコンテキストを理解する必要があります。RAGは、モデルの一般的な知識と独自の組織データを橋渡しして、事実に基づいたコンテキスト固有の情報を提供します。機密情報を保護するために、検索パイプラインは検証可能なアイデンティティコントロールで保護し、承認されたユーザーまたはAIエージェントのみがエンタープライズデータにアクセスできるようにする必要があります。
Retrieval Augmented Generation（RAG）の仕組み
RAGシステムは、内部データベースやベクターストアなどの外部知識ソースにクエリを実行し、LLM出力に事実に基づいたコンテキストを提供します。ドキュメントは高密度または疎な埋め込みに変換され、関連性スコアリングと完全一致を組み合わせたセマンティック検索およびハイブリッド検索が可能になります。上位にランク付けされた関連情報は、モデルのコンテキストウィンドウに供給され、LLMの作り話をする傾向を抑えつつ、正確でプライベートなデータを必要とするエンタープライズユースケースをサポートします。
大まかに言うと、RAGは2つの段階で展開されます。まず、LLMの出力を最新の事実に基づいたコンテキストに接地し、知識のカットオフ制限を軽減し、独自のエンタープライズデータへの安全なリアルタイムアクセスを可能にします。
フェーズ1：コア定義と検索
ユーザーが質問を入力すると、RAGシステムはまず外部データソースを検索します。ベクターデータベースは通常、ストレージ層として機能し、埋め込みと呼ばれるドキュメントの数学的表現を格納します。多次元インデックスを使用すると、システムは意味的関連性を検索したり、意味的関連性と正確なキーワードマッチングを組み合わせたハイブリッド検索を使用したりできます。類似性スコアリングは、コサイン類似度、内積、またはユークリッド距離などの類似性測定基準によってスコアリングされた情報チャンクまたはレコードを識別します。それらをランク付けして、クエリに最も関連性の高い、スコアが最も高い候補を特定します。
検索ソースは以下を含みます：
- 企業の重要な手順を保持する社内ドキュメントとWiki。
- 過去に技術的な問題がどのように解決されたかを示すカスタマーサポートチケット
- APIからのリアルタイムデータ、Model Context Protocol（MCP）などの新しい標準やライブデータベースへの動的な関数呼び出しを含みます。
- セマンティック検索用にインデックス化された技術マニュアルと製品仕様
フェーズ2：拡張プロセス
取得された情報は、コンテキスト入力としてプロンプトに追加される前に、最もシグナルの高い抜粋を優先するように再ランク付けされます。次に、拡張されたプロンプトがコンテキストウィンドウ内のLLMに供給されます。モデルは、トレーニングデータと取得されたコンテキストの両方に基づいて回答を生成します。生成中にソースマテリアルを参照することで、応答はより根拠のあるものになり、確率的な推測が許容されないビジネスクリティカルなユースケースにRAGが適しています。
新たに発生している認可ギャップ
検索ステップでは、セキュリティが極めて重要になります。AIエージェントは、機密性の高い顧客情報や企業独自のビジネスデータを含むデータソースにアクセスすることがよくあります。従来のRAGの実装では、多くの場合、重要な疑問が見過ごされています。それは、リクエストしているユーザーがアクセスを許可されているデータのみを、エージェントが確実に取得するにはどうすればよいか、ということです。
Fine-grained authorization（FGA）は、これらの制御のギャップに対処し、エンタープライズRAGシステムでの採用の増加につながります。異なるユーザーが同様の質問をする可能性がありますが、異なるデータセットへのアクセスを必要とします。もし新入社員が役員報酬について質問し、RAGシステムが機密のスプレッドシートを取得した場合、それは重大なデータ漏洩となります。適切な動的認可制御がない場合、RAGシステムは機密データを漏洩するリスクがあります。大規模なデータ漏洩は、Indirect Prompt Injection（IPI）によって発生する可能性があります。これは、一般的なプロンプトインジェクション攻撃とグループ化されることが多い新しい用語で、悪意のある命令が取得されたドキュメントまたはその他の形式の不正なコンテキスト操作に組み込まれています。
RAGのセキュリティにおける主要な課題
組織がRAGを導入するにつれて、非人間アイデンティティ（NHI）であるAIエージェントという新しいクラスが導入されます。これらのエージェントは、ユーザーに代わって行動したり、自律的に動作して情報を処理したりします。AIエージェントは、従来型のアイデンティティ管理システムが大規模に処理するように設計されていないセキュリティ上の課題をもたらします。組織は、人間のアクセスのみを管理することから、デジタルワーカーとそれに関連するサービスプリンシパルのアクセスを管理することに移行しています。
エージェントアイデンティティの問題
AIエージェントは従来のIDフレームワークにうまく適合しません。パスワードを持つ人間のユーザーではありませんが、従来のAPI統合よりも複雑です。エージェントは、自律的な意思決定を行い、複数のシステムにまたがって動作し、タスクを継続的に実行し、PII（個人情報）や知的財産などの機密データを処理する可能性があります。
有効期間の長いAPIキーや静的なサービスアカウントは、広範で永続的なアクセスを許可するため、リスクをもたらします。エージェントが侵害された場合、攻撃者は制限なく水平展開し、データを不正に持ち出す可能性があります。最新のアーキテクチャでは、一時的なトークンとWorkload アイデンティティ連携（WIF）を使用してこのリスクを軽減し、共有シークレットなしで検証可能で有効期間の短いアクセスを提供します。
シャドーAIの問題
強力なアイデンティティ制御がないと、組織はシャドーAIのリスクを抱えることになります。これは、AIエージェントが集中管理された可視性やセキュリティ監視なしに構築およびデプロイされた場合に発生します。開発者は、承認された環境外でRAGパイプラインを簡単に作成でき、場合によっては、それらを本番データソースに直接接続することがあります。シャドーAIは、隠れた攻撃対象領域を作成し、データ損失防止プロトコルをバイパスすることで、組織のリスクを高めます。
RAGのセキュリティ保護：アイデンティティ基盤
RAGセキュリティは後付けではいけません。組織は、アイデンティティをAIアクセスのコントロールプレーンとして機能させる、セキュア・バイ・デザインのアプローチを必要としています。すべてのエージェントとすべてのデータリクエストは、認証および認可される必要があります。
1. 一元化されたApplication （アプリケーション）間アクセス認可によるエージェントのデータアクセス保護。
AIエージェントには、堅牢なマシン-to-マシン（M2M）認証が必要です。M2M認可パターンは、共有アイデンティティコントロールレイヤーを介してアクセス決定を一元化します。一元化されたポリシー適用は、断片化されたベクターストアとレガシーAPI全体で機能します。
主要な戦略は次のとおりです。
- ゼロスタンディング特権（ZSP）：タスクの実行時間中のみ許可を付与し、その後すぐに取り消す、ジャストインタイム（JIT）アクセスパターンです。JITは、侵害されたエージェントによる被害範囲を最小限に抑え、特権のエスカレーションを防ぐのに役立ちます。
- スコープされたアクセス制限：エージェントは現在の機能に必要なリソースのみに制限され、APIおよびデータ行レベルで最小権限の原則（PoLP）を適用します。
- 委任された認可： 代行認証を使用することで、システムはアイデンティティを伝播し、エージェントとユーザーの許可の共通部分にデータアクセスを制限します。この二重構造の制約により、「Confused Deputy（混乱した代理）」攻撃を効果的に防止できます。
2. 監査と追跡可能性
エージェントのアクションは、人間または開始システムまで追跡できる必要があります。トレーサビリティは、どのユーザーがアクションを開始したか、および取得中にどのデータソースにアクセスしたかをキャプチャする詳細な監査ログに依存します。規制対象の業界では、詳細な監査証跡がコンプライアンスおよびインシデント調査を支援します。組織は、情報の管理体制を維持するために、AIが応答を生成する際に使用した特定のベクトル「コンテキストチャンク」を証明する能力をますます必要としています。
3. 高リスクなアクションに対するヒューマン・イン・ザ・ループ
すべてのエージェントアクションを自動的に実行する必要はありません。機密データまたは金銭的影響を含む運用の場合、RAGシステムは、非同期またはステップアップ認可ワークフローを通じて実装される、明示的な人間の承認ステップから恩恵を受けます。エージェントは、人間のレビュー担当者がアクションを承認するまで実行を一時停止するため、人間はリスクの高い決定を制御できます。
きめ細かい認可（FGA）の役割
大規模にRAGを保護するために、組織は多くの場合、粗粒度のロールベースアクセスコントロール（RBAC）を超えて移行します。FGAを使用すると、オブジェクトまたはリレーションシップレベルでアクセスを決定できます。これは、ベクターデータベースが異なるソースシステムの許可を持つ複数のソースからデータをインデックス化する場合に特に重要です。
FGAがRAGの新たなベストプラクティスである理由
検索中、RAGシステムは、ユーザーが特定のドキュメントの断片へのアクセスを許可されているかどうかを判断するために、リアルタイムで認可サービスにクエリを実行できます。許可されていないコンテンツは、モデルのコンテキストウィンドウに入る前に候補セットから除外されます。リアルタイムの認可クエリは、静的なフィルタリングに頼るのではなく、クエリ時に取得されたドキュメントが既存のアクセスコントロールに準拠していることを保証します。
リアルタイム認可は次のことをサポートします。
- ReBAC: ユーザーがファイルを所有しているか、または権限の有向グラフで定義された特定のプロジェクトチームの一員であるかに基づいてアクセスを許可します。
- 動的な権限付与：ベクトルデータベース全体を再埋め込みまたは再インデックスする必要なく、アクセスを即座に取り消します。
- 粒度：ファイル全体をロックダウンするのではなく、段落またはレコードレベルの粒度でデータを保護することで、データの境界の整合性を維持しながら、LLMの有用性を最大化します。
統合されたアイデンティティ制御プレーン
RAGプロジェクトは、モデルのパフォーマンスではなく、データガバナンスの複雑さのために、本番環境で苦労する可能性があります。最初からアイデンティティを優先する組織は、より容易に拡張できます。複数の接続されていないプラットフォームにわたってエージェントのアイデンティティを管理すると、運用リスクが増加します。統合されたアイデンティティコントロールプレーンは、可視性を一元化し、ポリシーの適用を簡素化し、カスタム認可ロジックの必要性を減らします。AIエージェントを第一級のアイデンティティとして扱うことで、組織は永続的な、過剰な特権を持つアクセスパスを導入することなくRAGを拡張し、エージェント主導のすべてのトランザクションに対して否認防止を有効にすることができます。
よくある質問（FAQ）
RAGとファインチューニングの違いは何ですか？
RAGは、クエリ時に外部情報を取得し、最新のデータに基づいて応答します。ファインチューニングは、特定のデータセットでモデルを再トレーニングし、内部の重みと動作を調整します。RAGは、頻繁に変更される知識やファインチューニングでは適用できない厳格なデータアクセス境界を維持するのに最適です。
RAGにおけるベクターデータベースとは何ですか？
ベクトルデータベースは、セマンティックな意味を捉えた数学的な埋め込みとしてデータを格納します。RAGシステムでは、ドキュメントはベクトルに変換されます。クエリが送信されると、システムはコサイン類似度などの類似性測定基準を使用して、最も近いベクトルを見つけます。Maximal Marginal Relevance（MMR）は、主要な類似性測定基準ではなく、リランキングと多様性技術です。MMRは、精度とコンテキストの多様性の両方を確認し、LLMに代表的で冗長性のないエビデンスセットを提供します。その結果、従来のキーワードマッチングよりも優れた意図に基づいた検索が実現します。
RAGはLLMのハルシネーションをどのように軽減するのか？
RAGは、モデルに取得されたコンテキストを提供することにより、パラメトリックなハルシネーションを低減します。モデルは、学習された確率的パターンのみに基づいてではなく、事実データに基づいて応答します。システムに、取得されたコンテキストを優先し、情報が利用できない場合に指示するように促し、提供されたエビデンスを使用して、モデルを生成タスクから識別タスクに移行できます。
RAGの主なセキュリティ上の課題は何ですか？
主要な課題は、検索ステップ中のアクセス制御です。AIエージェントは機密データをクエリする可能性があるため、認可制御が不可欠です。その他のリスクには、管理されていないシャドウAIエージェントや、安全でない長期間有効なAPIキーの使用が含まれます。きめ細かいアクセス制御と継続的な監査を実施することで、これらのリスクを軽減し、検索ロジックを狙ったプロンプトインジェクション攻撃からも保護できます。
RAGは構造化データと連携できますか？
はい、RAGは非構造化テキストと構造化データの両方で機能します。構造化RAG（多くの場合、「Text-to-SQL」または「Table-RAG」と呼ばれます。代替の命名法であり、標準化されていません）では、システムはセマンティックマッピングを使用して、データウェアハウスから特定のレコードを取得するためのSQLクエリを生成する場合があります。クエリ結果は、LLMが処理するための自然言語コンテキストに変換されます。ただし、これには、不正なデータ流出またはSQLインジェクションを防ぐための、パラメーター化されたクエリと追加の検証レイヤーが必要です。SQLインジェクションは、RAGに固有のものではなく、安全でないクエリ生成のリスクです。
アイデンティティを活用して安全なAIを展開する
RAGを本番環境に移行するには、プロンプトエンジニアリング以上のものが必要です。アイデンティティを基盤的なセキュリティコントロールとして扱う必要があります。認証、認可、および監査ログを通じて、ガードレールを適用する必要があります。
Oktaプラットフォームは、組織が設計段階から安全なAIエージェントを構築できるように、統合されたアイデンティティレイヤーを提供します。単一のコントロールプレーンを通じて人間と非人間アイデンティティ（NHI）を管理することで、組織はデータ漏洩を防ぎ、シャドウAIを管理し、RAGのビジネス価値を最大限に引き出すために必要な可視性と制御を得ることができます。
