Azure AI Foundryで社内文書や業務データを使った生成AIを作るなら、RAGは「モデルを賢くする機能」ではなく、検索で正しい根拠を取り出し、その根拠をLLMに渡して回答させる設計パターンとして理解するのが重要です。今回のMicrosoft Foundry公式情報では、RAGの基本動作、インデックスの役割、Agentic RAG、セキュリティ、コスト、トラブルシューティングの確認点が整理されています。管理者と開発者がまず確認すべきなのは、Azure AI Searchとの接続方法、インデックス設計、Microsoft Entra IDによる権限管理、引用に必要なメタデータ、そして本番展開前の評価方法です。(Microsoft Learn)
特に注意したいのは、RAGを導入しても「検索で不適切な情報を取ってくる」「権限のない文書まで検索対象にする」「取得した文章をプロンプトインジェクションの入口にする」といった設計ミスがあると、回答品質や情報漏えいリスクが一気に悪化する点です。2026年5月時点の公式ドキュメントでは、英語版ページの更新日は2026-05-20、ja-jp版は2026-05-06と表示されています。日本語版だけで判断せず、最新の仕様確認では英語版も併読するのが安全です。(Microsoft Learn)
Azure AI FoundryにおけるRAGとインデックスの基本
RAG、つまりRetrieval augmented generationは、検索と大規模言語モデルを組み合わせ、LLMの回答を自社データや最新情報に基づかせるためのパターンです。LLMは学習時点の公開データをもとに動作するため、社内規程、製品マニュアル、顧客向けFAQ、障害対応手順のような非公開データや頻繁に変わる情報には、そのままでは対応できません。RAGでは、ユーザーの質問に関連する情報をインデックスやデータストアから取得し、その情報をプロンプトに加えて回答を生成します。(Microsoft Learn)
公式情報では、RAGの処理は大きく次の3段階で説明されています。
| 段階 | 役割 | 実務で確認すること |
|---|---|---|
| Retrieve | インデックスやデータストアから関連情報を検索する | 検索方式、検索対象、権限フィルター、上位何件を取得するか |
| Augment | ユーザーの質問と取得した根拠データをプロンプトに組み込む | 取得文の長さ、引用情報、システムメッセージ、トークン量 |
| Generate | LLMが根拠データに基づいて回答を生成する | 引用の有無、根拠外の推測を抑える指示、回答品質の評価 |
この流れから分かるように、RAGの品質はモデル選びだけでは決まりません。むしろ本番では、どの文書を、どの粒度で、どの検索方式で取り出すかが成否を分けます。たとえば、社内規程のチャットボットで「育児休業中の副業可否」を聞かれた場合、休業規程、就業規則、副業規程の該当箇所をまとめて拾えなければ、LLMはもっともらしいが不完全な回答を返す可能性があります。
公式情報で明確になった主な確認ポイント
今回の公式情報は、単なる用語解説ではなく、Azure AI FoundryでRAGアプリケーションを作る際の設計判断を整理した内容です。大きなポイントは、インデックスの役割、Azure AI Searchとの接続、Agentic RAG、セキュリティ、コストと待機時間の5つです。
| 項目 | 公式情報の要点 | 管理者・開発者への影響 |
|---|---|---|
| インデックスの役割 | キーワード検索、セマンティック検索、ベクター検索、ハイブリッド検索を支える取得用データ構造 | 文書をそのまま置くだけでは不十分。チャンク、メタデータ、ベクトル化、検索設定の設計が必要 |
| Azure AI Search連携 | FoundryプロジェクトはAzure AI Searchサービスやインデックスに接続でき、機能やAPIによってプロジェクト接続またはインデックス資産IDとして表される | IaC、REST API、SDK、ポータルで参照する接続情報を混同しない |
| 引用品質 | インデックスには文書タイトル、URL、ファイル名など引用品質を高めるフィールドを保持できる | 回答に出典を出したい場合、本文フィールドだけでなく出典用フィールドを設計する |
| Agentic RAG | 複雑な質問を複数のサブクエリに分解し、並列実行して構造化された根拠データを返す | 単純FAQより、複数条件・会話履歴・複数ソースを扱うチャットで効果が出やすい |
| セキュリティ | 取得時のアクセス制御、Microsoft Entra ID、プロンプトインジェクション対策が重要 | APIキー前提の検証構成を本番に流用しない |
Foundry Project REST APIプレビューでは、Azure AI Searchのインデックスリソースに対してindex_asset_idフィールドが含まれると説明されています。画面上の接続名だけでなく、APIや自動化スクリプトで使う識別子を棚卸ししておくと、環境移行やCI/CDでの設定漏れを防ぎやすくなります。(Microsoft Learn)
対象者と影響範囲
今回の情報で影響を受けるのは、Azure AI Foundryを使っている開発者だけではありません。RAGは検索、認証、データ分類、運用監視まで関わるため、管理者、セキュリティ担当、業務部門も確認対象になります。
| 対象者 | 確認すべきこと |
|---|---|
| Azure管理者 | Azure AI Searchのサービス階層、リージョン、ネットワーク、RBAC、課金設定 |
| ID管理者 | Microsoft Entra ID、マネージドID、ロール割り当て、APIキー利用有無 |
| 開発者 | Foundry SDKまたはREST API、検索クエリ、プロンプト、引用、評価ロジック |
| データ管理者 | 検索対象文書、機密区分、文書更新頻度、削除・非公開時の反映方法 |
| セキュリティ担当 | 取得時アクセス制御、ドキュメントレベル権限、ログ、プロンプトインジェクション対策 |
| 業務部門 | 回答してよい範囲、出典として表示すべき文書、誤回答時のエスカレーション先 |
実務では、PoC段階で「とりあえず社内文書をBlob Storageに置いて検索できるようにする」構成になりがちです。しかし本番化する場合は、文書を持っていることよりも、誰が、どの質問で、どの文書を検索できるかを明確にする必要があります。
管理者が確認すべき設定
Azure AI Searchとの接続方式
公式情報では、Azure AI SearchはRAGシナリオに推奨されるインデックスストアとして位置付けられています。Azure AI Searchは検索インデックスに保存されたテキストデータとベクターデータを対象に取得でき、Agentic retrievalを使う場合は他のターゲットへのクエリも扱えます。(Microsoft Learn)
管理者は、次の点を確認してください。
| 確認項目 | 見るべきポイント | よくある失敗 |
|---|---|---|
| Foundryプロジェクトの接続 | Azure AI Searchサービス、インデックス、接続名、index asset ID | 開発環境の接続を本番に流用する |
| 検索サービスのリージョン | Foundry、Azure OpenAI、データソースとの配置 | リージョン差による遅延やデータ所在要件の見落とし |
| サービス階層 | インデックス容量、レプリカ、パーティション、セマンティック機能、Agentic retrievalの利用可否 | PoCの低いSKUのまま本番負荷を受ける |
| ネットワーク | Private Link、ファイアウォール、マネージドID、ストレージ接続 | 途中のデータソースだけ公開アクセスのままになる |
| 認証方式 | Microsoft Entra ID、RBAC、APIキー | APIキーをアプリ設定に平文で残す |
Azure AI Searchのロールベースアクセス制御は任意ですが推奨されており、キー認証が既定の代替手段として説明されています。本番環境では、管理者権限を広く配るのではなく、検索オブジェクトを管理する人、ドキュメントを投入する処理、検索だけを行うアプリを分けてロール設計することが重要です。(Microsoft Learn)
Microsoft Entra IDとロール割り当て
RAGの検索処理では、Azure AI Searchのデータプレーン権限が重要です。公式のRBAC説明では、Search Service Contributorはインデックスやナレッジベースなどの検索オブジェクトを作成できますが、ドキュメントの読み込みやクエリ実行はできません。Search Index Data Contributorはドキュメントの読み込みとクエリ、Search Index Data Readerはクエリとナレッジベースからの取得ができます。(Microsoft Learn)
本番アプリでは、最小権限を意識して次のように分けると管理しやすくなります。
| 用途 | 推奨される考え方 |
|---|---|
| インデックス定義の作成・変更 | 管理者またはCI/CD用IDにSearch Service Contributor相当を付与 |
| 文書投入・再インデックス | インデックス更新用のマネージドIDにSearch Index Data Contributor相当を付与 |
| チャットアプリからの検索 | 読み取り専用のアプリIDにSearch Index Data Reader相当を付与 |
| 機密文書を含む部門別検索 | インデックス単位またはドキュメントレベルのアクセス制御を検討 |
APIキーは検証では便利ですが、本番で長期運用する場合はキー漏えい時の影響範囲が大きくなります。公式情報でも、本番環境ではAPIキーよりMicrosoft Entra IDを優先するよう説明されています。(Microsoft Learn)
開発者が確認すべきインデックス設計
RAGの精度を上げるには、インデックスに入れるフィールド設計が欠かせません。本文だけをベクトル化しても、回答時に「どの文書の何ページか」「いつ更新された情報か」「ユーザーに見せてよいURLか」が分からなければ、業務利用には不十分です。
実務では、少なくとも次のフィールドを検討します。
| フィールド例 | 目的 |
|---|---|
id | チャンク単位の一意識別子 |
content または chunk | LLMに渡す本文 |
title | 引用や検索結果表示に使う文書名 |
source_url | 回答に表示する出典URL |
file_name | PDFやWord文書のファイル名 |
page_number | PDFやマニュアルでの参照位置 |
updated_at | 古い情報を下げる、または表示時に注意喚起する |
department | 部門別フィルター |
security_group | ドキュメントレベルアクセス制御 |
vector | ベクター検索用の埋め込み |
language | 日本語・英語混在時の検索調整 |
チャンク設計では、単に文字数で分割するだけでは不十分です。たとえば就業規則なら「条」「項」「見出し」を壊さず、製品マニュアルなら「手順」「注意」「エラーコード」を同じチャンクまたは近接チャンクに保つほうが、回答時の文脈が失われにくくなります。逆に、1チャンクに長大な章全体を入れるとトークンを消費し、検索結果が広すぎて回答がぼやけます。
検索方式はハイブリッドを基準に検討する
公式情報では、RAGで使われるインデックスの取得モードとして、キーワード検索、セマンティック検索、ベクター検索、ハイブリッド検索が挙げられています。ハイブリッド検索はキーワードとベクターを組み合わせ、必要に応じてセマンティックランキングも利用する考え方です。(Microsoft Learn)
| 検索方式 | 向いている質問 | 注意点 |
|---|---|---|
| キーワード検索 | 製品型番、エラーコード、契約条項番号、固有名詞 | 表記ゆれや言い換えに弱い |
| ベクター検索 | 「退職時の有給はどうなる？」のような自然文質問 | 正確な番号や固有名詞の一致を取りこぼすことがある |
| セマンティック検索 | 意味に基づいて関連性を高めたいFAQや社内文書検索 | 利用可否、課金、対応リージョンを確認する |
| ハイブリッド検索 | 本番RAGの標準候補。固有名詞と意味検索の両方を扱う | チューニングしないと検索結果が多すぎる場合がある |
日本語環境では、特に表記ゆれが問題になります。「Microsoft Entra ID」と「Azure AD」、「有給休暇」と「年休」、「稟議」と「申請」のように、ユーザーが使う語と文書上の語が一致しないことがあります。ベクター検索やセマンティック検索はこの問題を緩和できますが、型番やエラーコードのような完全一致が重要なデータではキーワード検索も残すべきです。
Agentic RAGはいつ使うべきか
Agentic RAG、またはAgentic retrievalは、従来のRAGのように1つのクエリで検索するのではなく、LLMを使って複雑な入力を複数のサブクエリに分解し、並列実行して構造化された根拠データ、引用、実行メタデータを返す方式です。公式情報では、会話履歴を使った文脈理解、並列実行、構造化応答、組み込みのセマンティックランキング、任意の回答合成が利点として説明されています。(Microsoft Learn)
| 選択肢 | 向いているケース |
|---|---|
| 従来型RAG | 単純FAQ、問い合わせ分類、検索対象が1つのインデックス、低遅延を優先する業務 |
| Agentic RAG | 複数条件の質問、会話履歴を使うチャット、複数ソースの横断検索、引用や実行内容の追跡が重要な業務 |
| ファインチューニング | 新しい知識を追加するより、回答の口調、形式、特定タスクの振る舞いを変えたい場合 |
| エージェントツール | エージェントが検索、計算、外部API呼び出しなどを道具として使う場合 |
ただし、Agentic retrievalは万能ではありません。LLMによるクエリ計画が入るため、従来型の単一検索より遅延やコストが増える可能性があります。公式情報でも、LLMを含むクエリ計画は待機時間を追加するため、より高速なモデルの利用、メッセージスレッドの要約、LLM処理を制限する設定などで緩和できると説明されています。(Microsoft Learn)
また、Agentic retrievalの一部機能は2026-04-01 REST APIで一般提供されている一方、Azure portalとMicrosoft Foundry portalではプレビューのみのアクセスが続くと説明されています。プレビューREST APIを使う場合、SLAなしで提供され、本番ワークロードには推奨されない機能が含まれる点にも注意が必要です。(Microsoft Learn)
移行で注意すべきポイント
既存のRAGアプリケーションをすぐに全面移行する必要があるとは限りません。単純な社内FAQや、すでにAzure AI Searchのハイブリッド検索で十分な精度と速度が出ているアプリでは、従来型RAGを維持しながら評価を進めるのが現実的です。
一方で、過去のプレビューAPIを使ってAgentic retrievalを実装している場合は、移行手順を確認する必要があります。公式の移行ドキュメントでは、Agentic retrievalをサポートする各APIバージョンで破壊的変更が導入されており、古いコードはAPIバージョンを維持すれば動かせるものの、修正や新機能の恩恵を受けるにはコード更新が必要と説明されています。(Microsoft Learn)
移行時の実務ポイントは次の通りです。
| 確認項目 | 対応 |
|---|---|
| 利用APIバージョン | 2025-05-01-preview、2025-08-01-preview、2025-11-01-preview、2026-04-01などを棚卸しする |
| 移行順序 | サポートされる移行パスは段階的。古いプレビューから一足飛びに移行しない |
| オブジェクト作成 | 既存オブジェクトを上書きせず、新しい一意名のknowledge sourceやknowledge baseを作る |
| 検索インデックス | 2025-11-01-previewから2026-04-01へ移行する場合、インデックスとコンテンツは変更不要と説明されている |
| retrieveリクエスト | 2026-04-01ではmessagesではなくintents、maxOutputSizeではなくmaxOutputSizeInTokensを使う |
| 課金同意 | 2026-04-01以降はagentic retrievalの課金同意がknowledgeRetrievalプロパティで管理される |
| 削除タイミング | 新しい構成を検証・展開してから古いプレビューオブジェクトを削除する |
特に危険なのは、プレビュー環境で作ったナレッジソースやナレッジベースの名前を本番コードに直接埋め込んでいるケースです。移行時に新しい一意名のオブジェクトを作る設計では、アプリ設定、環境変数、IaC、監視設定、権限設定まで同時に見直さないと、検索は成功しているのに古いインデックスを参照している、という事故が起きます。
本番展開前に必ず評価すべき項目
RAGは「動いた」だけでは本番品質とはいえません。最低限、検索品質、回答品質、引用品質、セキュリティ、コスト、遅延を分けて評価します。
| 評価項目 | 確認方法 |
|---|---|
| 検索品質 | 代表的な質問50〜100件を作り、正しいチャンクが上位に出るか確認する |
| 回答品質 | 根拠に基づいた回答か、根拠外の推測が混ざっていないかレビューする |
| 引用品質 | URL、文書名、ページ番号、更新日が表示できるか確認する |
| 権限 | 権限のないユーザーで機密文書が取得されないかテストする |
| プロンプト安全性 | 文書中の命令文に従ってしまわないか、プロンプトインジェクションを試験する |
| コスト | 検索回数、埋め込み、入力トークン、出力トークン、Agentic retrievalの追加コストを見積もる |
| 遅延 | 通常時、ピーク時、再試行時の応答時間を測る |
| 更新反映 | 文書更新・削除・権限変更が検索結果に反映されるまでの時間を確認する |
公式情報でも、RAGはモデル単体のリクエストに比べて、インデックス検索、埋め込み、取得したパッセージによる入力トークン増加などの追加コストと待機時間が発生すると説明されています。特にセマンティック検索やハイブリッド検索を使う場合は、Azure AI Searchの価格と制限を本番ロールアウト前に確認すべきです。(Microsoft Learn)
よくある失敗と対策
| 失敗しやすいポイント | 何が起きるか | 対策 |
|---|---|---|
| 文書を大きすぎるチャンクで入れる | 検索結果が広すぎて回答が曖昧になる | 見出し、段落、手順単位で分割する |
| 本文だけをインデックス化する | 出典表示や監査ができない | タイトル、URL、ファイル名、ページ番号、更新日を持たせる |
| 権限フィルターを後段で処理する | LLMに権限外文書が渡る可能性がある | 取得時にアクセス制御を適用する |
| APIキーを本番アプリで使い続ける | キー漏えい時の影響が大きい | Microsoft Entra IDとマネージドIDを使う |
| 評価データを作らない | 精度改善が感覚的になる | 業務部門と代表質問・期待回答・参照文書を作る |
| 引用を有効にしない | 回答の検証ができない | sourceフィールドと引用表示を標準化する |
| 取得文を無条件に信頼する | プロンプトインジェクションの影響を受ける | システムメッセージで根拠利用ルールを明示する |
| コストをモデル料金だけで見る | 検索、埋め込み、再ランキング、トークン増を見落とす | 検索処理全体で見積もる |
RAGシステムでは、アクセスとプロンプトを慎重に設計しない場合、機密コンテンツが露出する可能性があります。公式情報でも、取得時アクセス制御、Microsoft Entra IDの優先、取得コンテンツを信頼されていない入力として扱うことが明記されています。(Microsoft Learn)
導入時の実践手順
Azure AI FoundryでRAGを導入する場合、いきなり大規模な社内文書全体を対象にするより、業務範囲を絞って検証するほうが成功しやすくなります。
| 手順 | 実施内容 |
|---|---|
| 業務範囲を決める | 例：情シスFAQ、製品マニュアル、社内規程など、回答責任を持てる範囲に絞る |
| データを棚卸しする | 文書の種類、更新頻度、機密区分、所有部門、参照権限を整理する |
| インデックスを設計する | チャンク、メタデータ、ベクトル、引用フィールド、ACLフィールドを決める |
| 検索方式を決める | まずハイブリッド検索を基準にし、型番検索や自然文検索の要件で調整する |
| Foundryに接続する | プロジェクト接続またはindex asset IDを確認し、環境ごとに分離する |
| プロンプトを設計する | 根拠がない場合は回答しない、引用を付ける、取得文の命令に従わない、などを明示する |
| 評価する | 代表質問、期待回答、参照すべき文書、禁止回答を用意する |
| 本番化する | Entra ID、RBAC、監視、課金、再インデックス、障害時対応を整える |
次に取るべき行動は明確です。まず、RAGで答えさせたい業務範囲を1つ選び、検索対象文書と権限を棚卸ししてください。そのうえで、Azure AI Searchのインデックス設計、Foundryプロジェクトとの接続、Microsoft Entra IDによる認証、引用に必要なメタデータを確認します。既存のプレビュー版Agentic retrievalを使っている場合は、APIバージョン、knowledge source、knowledge base、retrieveリクエスト、課金同意の移行要否を先に洗い出すことが重要です。RAGはLLMの回答を業務に近づける強力な設計ですが、成功の鍵は「モデル」よりも「検索できるデータ構造」と「安全に取り出す仕組み」にあります。
コメント