Microsoft developer platformの「docs: add agent-rag-governance proposal」は、既存コードをすぐ書き換える必要がある更新ではありません。2026年5月5日にMicrosoftのAgent Governance Toolkitリポジトリへマージされた、RAG検索段階のガバナンスを扱う新パッケージ案のドキュメント追加です。対応すべきなのは、RAGを使って社内文書、顧客データ、製品マニュアル、ナレッジベースをAIエージェントに検索させている開発チームです。今すぐの移行よりも、検索対象コレクションの権限、監査ログ、PII検査、レート制限の設計を確認することが重要です。(GitHub)
今回のMicrosoft developer platform更新で追加された内容
今回の更新は、agent-rag-governanceという新パッケージの設計提案ドキュメントを追加するものです。Pull Request #1730は2026年5月5日にmicrosoft:mainへマージされ、docs/proposals/RAG-GOVERNANCE-PROPOSAL.mdが1ファイル、223行追加されました。内容は実装コードではなく、RAGパイプラインの検索処理にポリシー評価を挟むための設計案です。(GitHub)
| 確認項目 | 今回示された内容 | 実務で見るべきポイント |
|---|---|---|
| 対象パッケージ | agent-rag-governance | まだ提案段階として扱い、正式な導入手順は今後の実装PRやREADMEで確認する |
| 中核API | RAGGovernor | 既存のretrieverを包み、検索前後にポリシーを適用する想定 |
| 戻り値 | GovernedRetrievalResult | 許可可否、取得文書、理由、監査IDを扱う設計 |
| 対応フレームワーク | LangChain、LlamaIndexを最初のアダプター候補にする案 | 自社のRAG基盤がどちらに近いか確認する |
| ポリシー基盤 | 既存のPolicyEvaluatorを利用 | Cedar/Regoなど既存のPolicy-as-Code運用と統合できるか確認する |
| 変更の性質 | ドキュメント追加 | 破壊的変更や即時のコード移行ではない |
この更新の要点は、「RAGの検索結果がLLMへ渡る前に、アクセス制御・レート制限・コンテンツ検査・監査ログを適用する」という方向性です。従来のプロンプトガードや出力検査だけでは、検索された機密チャンクがすでにLLMに渡ってしまう可能性があります。agent-rag-governance案は、その前段で止める仕組みを設計しようとしています。(GitHub)
agent-rag-governanceが解決しようとしている課題
RAGは便利ですが、実務では「検索できてはいけないデータを検索してしまう」リスクがあります。たとえば、顧客向けエージェントが製品FAQだけでなく、人事情報、財務情報、別テナントのドキュメントまで検索できる状態になっていると、回答生成の前に機密情報がLLMへ渡る可能性があります。
提案ドキュメントでは、RAGパイプラインに不足しがちな課題として、ベクトルDBコレクションへの無制限アクセス、回答に影響した文書の監査証跡不足、検索ループ時のレート制限不足、LLM到達前のコンテンツスキャン不足が挙げられています。(GitHub)
RAGで特に問題になりやすい場面
RAGガバナンスが必要になりやすいのは、次のようなケースです。
| 利用シーン | 起きやすい問題 | 確認すべきこと |
|---|---|---|
| 顧客向けチャットボット | 別顧客・社内向け文書の混入 | テナント別、ロール別に検索対象を分けているか |
| 社内ナレッジ検索 | 人事・法務・財務データの過剰検索 | 機密度別のコレクション設計があるか |
| 営業支援AI | 未公開価格、契約条件、顧客情報の露出 | agent IDごとの許可範囲が定義されているか |
| 自律型エージェント | 検索ループによるAPIコスト増加 | 1分あたり、1タスクあたりの検索回数制限があるか |
| 監査が必要な業務 | どの文書を根拠に回答したか追えない | 文書ID、コレクション、ポリシー判定をログ化しているか |
重要なのは、「RAGの品質改善」と「RAGの権限制御」を分けて考えることです。検索精度を高めるだけでは、検索してはいけない情報を止められません。運用環境では、retrieverが返す文書の妥当性だけでなく、「そのエージェントがそのコレクションを検索してよいか」を判定する必要があります。
すぐ移行が必要な変更ではない
今回のPull Request #1730は、提案ドキュメントの追加です。GitHub Actionsのコメントでも、このPRはドキュメント提案のみでコード変更を含まないため、テストカバレッジ分析は対象外とされています。また、API互換性チェックでは破壊的変更は検出されていません。(GitHub)
そのため、既存のMicrosoft developer platform関連プロジェクトでAgent Governance Toolkitを利用している場合でも、今回の更新だけを理由に依存関係を更新したり、RAGコードを書き換えたりする必要は基本的にありません。
ただし、RAGを本番運用しているチームは「何もしなくてよい」と考えるべきではありません。今回の提案は、将来的にRAG検索の統制がAgent Governance Toolkitの重要な領域になる可能性を示しています。今のうちに、自社のRAG構成がガバナンスを挟める設計になっているか確認しておくと、正式実装後の移行が楽になります。
影響を受けやすい開発チーム
今回の更新で特に注目すべきなのは、RAGを業務データと組み合わせているチームです。単なる社内検証やPoCよりも、権限、監査、コンプライアンスが絡む本番環境ほど影響が大きくなります。
| 対象チーム | 優先度 | 理由 |
|---|---|---|
| LangChainでRAGエージェントを構築しているチーム | 高 | 提案ではLangChainアダプターが最初の候補に含まれている |
| LlamaIndexでナレッジ検索を実装しているチーム | 高 | LlamaIndex向けのGovernedQueryEngine案が示されている |
| ベクトルDBを複数コレクションで運用しているチーム | 高 | コレクション単位のACLが主要テーマになっている |
| Cedar/RegoでPolicy-as-Codeを運用しているチーム | 高 | 既存のPolicyEvaluatorとの連携が設計方針に含まれている |
| RAGを使っていないAIチャット開発チーム | 低 | 直接の移行影響は小さい |
| 監査・セキュリティ担当 | 高 | 取得文書、agent ID、判定結果の監査証跡が論点になる |
特に注意したいのは、同じベクトルDB内に「公開可能なFAQ」と「社内限定資料」と「顧客別データ」を同居させているケースです。検索クエリの内容やメタデータフィルターだけに依存している場合、ポリシー評価を別レイヤーで行う設計に変えられるかを確認しておくべきです。
RAGGovernorの想定APIから分かる設計方針
提案ドキュメントでは、RAGGovernorをフレームワーク非依存の中核として置き、LangChainやLlamaIndex向けのアダプターを別に用意する設計が示されています。RAGGovernorはquery、collection、agent_id、retriever_fnを受け取り、GovernedRetrievalResultを返す想定です。戻り値には、検索が許可されたか、返却文書、拒否理由、監査IDが含まれます。(GitHub)
この設計で実務上重要なのは、RAGのガバナンスを特定フレームワークの機能に閉じ込めない点です。LangChainを使っているチームも、LlamaIndexを使っているチームも、将来的には同じようなポリシー評価の考え方を適用できる可能性があります。
設計を読むときのポイント
agent-rag-governanceを「新しいRAGライブラリ」として見るより、「既存のretrieverの前後に挟む統制レイヤー」として見ると理解しやすくなります。
| API・構成要素 | 役割 | 開発者が確認すべきこと |
|---|---|---|
RAGGovernor | 検索呼び出しを統制する中核 | 既存のretrieverをラップできる構造か |
CollectionACL | 許可・拒否コレクションを制御 | コレクション名と権限設計が整理されているか |
ContentPolicy | PIIやインジェクションを検査 | 検査対象をLLM入力前に置けるか |
GovernedRetriever | LangChain向けアダプター案 | .get_relevant_documents()など既存呼び出しとの差分を確認する |
GovernedQueryEngine | LlamaIndex向けアダプター案 | query engineの入出力を監査できるか |
GovernedRetrievalResult | 検索結果と判定情報を返す | 失敗時のUI表示、ログ、再試行制御を設計する |
PolicyEvaluatorとの統合が重要な理由
今回の提案で見落としてはいけないのが、agent-rag-governanceが独自の別ポリシーシステムを作るのではなく、既存のagent-osのPolicyEvaluatorへ委譲する設計になっている点です。提案では、Cedar/Regoで表現したコレクションACLを、AGT内の既存のPEP/PDPペアで評価する流れが示されています。(GitHub)
これは運用面で大きな意味があります。ツール呼び出し用のポリシーとRAG検索用のポリシーを別々に管理すると、例外ルールや監査ログが分散しやすくなります。一方、既存のPolicyEvaluatorに寄せられるなら、同じPolicy-as-Codeの運用ルールで「ツールを呼んでよいか」と「この文書コレクションを検索してよいか」を管理できます。
ポリシー設計で先に決めるべきこと
実装が正式に利用可能になる前でも、次の設計は進められます。
| 設計項目 | 決める内容 | 悪い例 |
|---|---|---|
| agent ID | エージェントをどう識別するか | bot1、test-agentのように用途が分からないIDを本番で使う |
| collection名 | データ分類が分かる命名にする | docs1、data-oldのように権限判断できない名前にする |
| 許可ルール | 原則allowかdenyか | 全体許可してから例外的に拒否する |
| 監査単位 | 1検索ごと、1会話ごと、1タスクごとのどれで記録するか | 後から根拠文書を追えない粒度でログを残す |
| 保持期間 | 監査ログをどれくらい保存するか | 個人情報を含むログを無期限に保存する |
| 失敗時の動作 | 拒否・レート制限・検査NG時の返答 | エラーをそのままユーザーに見せる |
基本方針としては、deny list中心ではなくallow list中心で設計するのが安全です。たとえば、営業支援エージェントにはproduct_manualsとsales_faqだけを許可し、hr_recordsやfinancial_dataは明示的に拒否する、という形です。
移行に備えて確認すべき設定チェックリスト
今回の更新はドキュメント追加ですが、将来の実装に備えるなら、次の順番で確認すると無駄がありません。
| 手順 | 作業 | 具体例 |
| -: | ————————- | ——————————————————————- |
| 1 | RAGで使っているretrieverを棚卸しする | LangChain retriever、LlamaIndex query engine、独自検索関数を一覧化する |
| 2 | ベクトルDBのコレクションを分類する | public_docs、product_manuals、hr_records、financial_dataなどに分ける |
| 3 | エージェントごとの検索権限を決める | 顧客向け、社内向け、管理者向けで許可範囲を分ける |
| 4 | 既存のPolicyEvaluator運用を確認する | Cedar/Rego/YAMLなど、どの形式で管理しているか確認する |
| 5 | 監査ログの項目を設計する | timestamp、agent ID、collection、document ID、policy decisionを検討する |
| 6 | レート制限の基準を決める | 1分100回のような固定値ではなく、業務とコストに合わせる |
| 7 | コンテンツスキャン対象を定義する | メールアドレス、電話番号、顧客ID、プロンプトインジェクション文を検査候補にする |
| 8 | テストケースを用意する | 許可、拒否、PII検出、検索ループ、監査ログ出力を確認する |
この作業で特に時間がかかるのは、コード修正ではなくデータ分類です。どのコレクションに何が入っているか分からない状態では、RAGGovernorのような仕組みを導入しても適切なポリシーを書けません。
注意すべき落とし穴
提案ドキュメントを正式リリース済み機能として扱わない
今回のPRは設計提案です。実装PR、README、CHANGELOG、パッケージ公開状況が揃うまでは、本番コードに組み込める機能として扱わない方が安全です。関連する実装PR #1754は2026年5月6日時点でOpenの状態で、設計レビュー後の実装参考として扱う旨のコメントもあります。(GitHub)
監査ログに機密情報を残しすぎない
RAG監査では「どの文書が回答に影響したか」を追えることが重要です。一方で、検索クエリ本文やチャンク全文をそのままログに残すと、ログ基盤自体が機密情報の保管場所になります。実務では、文書ID、コレクション名、判定結果、監査IDを中心にし、検索クエリや本文の扱いは最小化する設計が望まれます。
レート制限を全体一律にしない
RAGの検索回数は用途によって大きく変わります。FAQボットと調査支援エージェントでは、正常な検索回数が違います。全エージェントに同じ上限を設定すると、必要な検索まで止めるか、逆に高リスクなエージェントを止められない可能性があります。
実務では、少なくとも次の単位で分けて考えるべきです。
- agent IDごとの上限
- ユーザーまたはテナントごとの上限
- 1会話または1タスクごとの上限
- 高機密コレクションへの検索上限
コンテンツスキャンだけに頼らない
PII検出やプロンプトインジェクション検出は重要ですが、完全ではありません。検出漏れも誤検知も起こり得ます。まずコレクションACLで検索対象を絞り、その後にコンテンツスキャンを追加する二段構えが現実的です。
検索拒否時のユーザー体験を設計しておく
ガバナンスを強化すると、これまで返っていた回答が返らなくなる場面があります。そのときに「権限がありません」とだけ返すと、ユーザーには不親切です。
たとえば、顧客向けチャットなら「この内容は公開情報の範囲では回答できません。契約条件については担当窓口にお問い合わせください」のように、代替行動を示す文面を用意しておくと運用しやすくなります。
実務での判断基準
今回のMicrosoft developer platform更新を受けて、対応優先度を判断するなら、次の質問に答えてください。
| 質問 | Yesの場合の対応 |
|---|---|
| RAGが複数の機密度のデータを検索しているか | コレクション単位のACL設計を優先する |
| 顧客別、部署別、ロール別に検索権限が違うか | agent IDとテナントIDの対応表を作る |
| 回答の根拠文書を後から追跡する必要があるか | 監査ログのスキーマを先に決める |
| 検索回数が急増してコストが膨らんだ経験があるか | レート制限と異常検知を検討する |
| LLMに渡る前にPIIや攻撃文を止めたいか | コンテンツスキャンの検査ポイントをretriever直後に置く |
| LangChainまたはLlamaIndexを使っているか | 将来のアダプター対応状況を継続確認する |
2つ以上Yesなら、今回の更新は単なるニュースではなく、設計見直しのきっかけにした方がよいでしょう。
開発チームが今やるべきこと
今回の更新で今すぐ行うべきなのは、パッケージのインストールではなく、RAG運用の棚卸しです。まず、どのエージェントが、どのretrieverを通じて、どのコレクションを検索しているかを表にしてください。そのうえで、検索してよい範囲と、検索してはいけない範囲を明確にします。
次に、既存のAgent Governance Toolkit運用でPolicyEvaluatorを使っている場合は、ツール呼び出しだけでなく検索呼び出しも同じポリシー体系で扱えるかを確認します。すでにCedar/Regoを使っているなら、コレクションACLを追加するだけで運用できるかもしれません。使っていない場合は、まずRAG用に小さなポリシー設計を作るところから始めるとよいでしょう。
最後に、正式な実装が入ったときの検証項目を用意します。許可されたコレクションは検索できるか、拒否されたコレクションは検索できないか、レート制限時に監査ログが残るか、PIIを含むチャンクがLLMに渡らないかを、テストケースとして準備しておくと移行がスムーズです。
まとめ
Microsoft developer platformの「docs: add agent-rag-governance proposal」は、RAG検索段階のガバナンスをAgent Governance Toolkitに組み込むための設計提案です。今回のPR自体はドキュメント追加であり、破壊的変更や即時移行は不要です。(GitHub)
ただし、RAGを本番運用しているチームにとっては重要なシグナルです。検索対象コレクションの権限、agent ID、PolicyEvaluatorとの接続、監査ログ、PII検査、レート制限を今のうちに整理しておけば、agent-rag-governanceの実装が正式に進んだときに安全に取り込めます。次に取るべき行動は、既存RAGのretrieverとコレクションを棚卸しし、「どのエージェントが何を検索してよいのか」を明文化することです。
コメント