Microsoft EdgeでAI/Copilot活用を進める企業にとって、今回押さえるべきポイントは「Edgeの見た目が変わる」ことではなく、社内データを根拠に回答するエージェントを、Microsoft Foundry側で作りやすくなることです。公式情報「Connect Agents to Foundry IQ Knowledge Bases」では、Foundry IQのナレッジベースをFoundry Agent Serviceのエージェントに接続し、MCPツールとして検索・引用付き回答に使う構成が整理されています。なお、英語版の公式ページ上の最終更新日は2026年5月15日、日本語版は2026年4月30日と表示されています。(Microsoft Learn)
特に管理者・開発者が確認すべきなのは、APIバージョン、MCP接続、RBAC、マネージドID、SharePointなどのユーザー別権限制御です。一部のエージェント検索機能は2026-04-01 REST APIで一般提供されていますが、公式手順ではプレビュー機能を含む全体像を示すために2025-11-01-previewが使われています。プレビュー機能は本番利用に慎重な判断が必要です。(Microsoft Learn)
Microsoft EdgeのAI/Copilot更新とFoundry IQ接続の関係
Microsoft Edgeのリリースノートでは、2026年5月のStable ChannelでCopilot New Tab Page、AI設定ページ、Microsoft 365 Copilot Chat、関連ポリシーの更新が案内されています。Copilot関連の設定は1つのAI設定ページに集約され、既存の管理者制御やポリシー構成は引き続き適用されるとされています。(Microsoft Learn)
一方、Foundry IQナレッジベース接続は、Edgeそのもののブラウザー機能ではありません。位置づけとしては、Edge for BusinessやMicrosoft 365 Copilot Chat、社内ポータル、業務Webアプリなどから利用するAIエージェントに、社内ナレッジを安全に参照させるためのバックエンド構成です。
つまり、利用者から見ると「Edge上のCopilotやAIチャットが社内文書を根拠に答える」体験につながりますが、管理者・開発者から見ると、作業の中心はMicrosoft Edgeの設定だけでなく、Microsoft Foundry、Azure AI Search、Microsoft Entra ID、RBAC、ナレッジソース設計にあります。
今回の公式情報で何が変わるのか
今回の要点は、Foundry IQのナレッジベースをFoundry Agent Serviceのエージェントに接続し、MCPを通じてナレッジ検索ツールとして呼び出せることです。エージェントがナレッジベースを呼び出すと、ユーザーの質問をサブクエリに分解し、キーワード検索・ベクトル検索・ハイブリッド検索を使い、セマンティック再ランキングを行ったうえで、ソース参照付きの回答に統合します。(Microsoft Learn)
従来の単純なRAGでは、アプリごとに検索対象やプロンプト、参照データを個別に作り込みがちでした。Foundry IQでは、ナレッジベースを1つのまとまった単位として扱い、複数のナレッジソースをエージェントから利用しやすくします。Foundry IQ FAQでも、1つのFoundry IQナレッジベースから複数ソースにアクセスできるため、各エージェントを各ソースに個別接続する必要がないと説明されています。(Microsoft Learn)
| 観点 | 従来起きやすかった課題 | Foundry IQ接続で整理される点 |
|---|---|---|
| データ接続 | エージェントごとに検索インデックスやAPI連携を作る | ナレッジベースをMCPツールとしてエージェントに接続 |
| 検索品質 | 1回の検索で外すと回答品質が落ちる | クエリ計画、サブクエリ分解、再ランキングを利用 |
| 根拠提示 | 出典の扱いが実装依存になりやすい | ソース参照付きの回答を前提に構成しやすい |
| 権限制御 | ユーザーごとの閲覧権限を後付けしがち | ACL、RBAC、ユーザートークン、SharePoint権限を設計に含める |
| 運用 | プロンプトや接続情報が分散しやすい | プロジェクト接続、MCPツール、エージェント定義で管理 |
影響を受ける管理者・開発者・利用者
今回の更新は、Microsoft Edgeを単体で使っている一般ユーザーよりも、Edge上でAI/Copilot体験を業務展開する組織に影響します。特に、社内規程、製品仕様書、営業資料、FAQ、SharePoint上の文書、Azure Blob Storage上のドキュメントなどをAIエージェントに参照させたい企業では確認優先度が高いです。
| 対象 | 影響 | 確認すべきこと |
|---|---|---|
| Edge管理者 | Copilot New Tab Page、AI設定、サイドバー、ポリシー管理に影響 | Edge management service、対象グループ、edge://policy、Copilot関連ポリシー |
| Azure/Foundry管理者 | Foundryプロジェクト、接続、マネージドID、RBACが必要 | Foundryロール、Search Index Data Reader、ProjectManagedIdentity |
| 開発者 | エージェント定義、MCPツール、APIバージョン、プロンプト設計が必要 | knowledge_base_retrieve、2025-11-01-preview、SDKバージョン |
| セキュリティ担当者 | 社内データの参照範囲、SharePoint権限、ACLが重要 | ユーザー別認可、x-ms-query-source-authorization、監査ログ |
| 利用者 | Edgeや業務アプリ上で、根拠付き回答を受け取れる | 回答の引用、参照元、回答できない場合の挙動 |
管理者が最初に確認すべき前提条件
Foundry IQナレッジベースをエージェントに接続するには、Azure AI Search上のナレッジベース、Microsoft Foundryプロジェクト、LLMデプロイ、検索サービスとプロジェクトへの認証・アクセス許可が必要です。公式手順では、最新のプレビューPython SDK 2.0.0以降、または2025-11-01-preview REST APIバージョンが前提として示されています。(Microsoft Learn)
| 確認項目 | 具体的な確認内容 |
|---|---|
| Azure AI Search | ナレッジベースと1つ以上のナレッジソースが作成済みか |
| Microsoft Foundry | FoundryプロジェクトとLLMデプロイがあるか |
| 認証方式 | 本番ではRBACを基本にするか、やむを得ずキー認証にするか |
| マネージドID | Foundryプロジェクトにシステム割り当てマネージドIDがあるか |
| ロール | 検索サービス側でSearch Index Data Readerを付与しているか |
| 書き込み要件 | インデックスへ書き込む場合にSearch Index Data Contributorが必要か |
| SDK/API | Python SDK 2.0.0以降、または対象REST APIを使うか |
| データ権限 | ACLやSharePoint権限をクエリ時に反映する設計か |
ロール名にも注意が必要です。英語版公式ドキュメントでは、Foundry RBACロールが最近リネームされ、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerという名称に変わった一方、ロールIDと基本権限は変わらないと説明されています。画面や日本語ドキュメント上では旧名称が残る可能性があるため、名称だけで判断せず、実際の権限とロールIDを確認してください。(Microsoft Learn)
接続の流れ：Foundry IQナレッジベースをエージェントに使わせる手順
実装の流れは、大きく分けると「ナレッジベースを用意する」「Foundryプロジェクトに接続を作る」「エージェントにMCPツールを追加する」「回答を検証する」の4段階です。
ナレッジベースとナレッジソースを用意する
最初に、Azure AI SearchでFoundry IQナレッジベースを作成します。ナレッジソースには、インデックス付きソースとリモートソースがあります。Foundry IQ FAQでは、インデックス付きソースとしてAzure Blob Storage、OneLake、SharePoint、既存の検索インデックスが挙げられ、リモートソースとしてSharePointやWebソースが説明されています。(Microsoft Learn)
実務では、最初から全社データを接続するよりも、対象を絞ったナレッジベースで検証するのが安全です。たとえば、以下のような小さなユースケースから始めると、権限・検索品質・引用精度を確認しやすくなります。
| ユースケース | 最初に接続するデータ例 | 成功判定 |
|---|---|---|
| 社内規程Q&A | 就業規則、申請手順、福利厚生FAQ | 回答に規程名やページが引用される |
| 情シス問い合わせ | VPN手順、Edge設定、端末申請FAQ | 古い手順を参照しない |
| 営業支援 | 製品資料、価格表、提案テンプレート | 禁止された資料を出さない |
| サポート対応 | 障害FAQ、既知問題、対応履歴 | 不明な場合に推測で答えない |
FoundryプロジェクトにRemoteTool接続を作成する
公式手順では、Microsoft FoundryプロジェクトにRemoteTool接続を作成します。この接続では、プロジェクトのマネージドIDを使ってナレッジベースのMCPエンドポイントをターゲットにし、エージェントがAzure AI Searchと安全に通信できるようにします。RemoteToolカテゴリとProjectManagedIdentity認証タイプは、Microsoft Foundryプロジェクト接続固有の設定です。(Microsoft Learn)
接続先のMCPエンドポイントは、概念的には次の形式です。
{search_service_endpoint}/knowledgebases/{knowledge_base_name}/mcp?api-version=2025-11-01-previewここで間違えやすいのは、search_service_endpointに検索サービスのURLを入れる点です。ナレッジベース名やFoundryプロジェクトのエンドポイントと混同すると、400や404の原因になります。
エージェントにMCPツールを追加する
エージェント側では、作成済みのプロジェクト接続を使ってMCPツールを追加します。公式情報では、Azure AI SearchナレッジベースがFoundry Agent Service向けに公開するツールはknowledge_base_retrieveであり、現時点でFoundry Agent Serviceでサポートされる唯一のツールと説明されています。(Microsoft Learn)
実務上は、allowed_toolsにknowledge_base_retrieveが入っているかを必ず確認してください。ここが抜けていると、エージェントはナレッジベースを使える構成に見えても、実際には検索ツールを呼び出せません。
エージェント指示で「根拠なし回答」を防ぐ
ナレッジベースを接続しても、プロンプトが曖昧だとエージェントが自分の学習済み知識に頼る可能性があります。公式手順では、ナレッジベースを使って回答すること、ナレッジベースに答えがない場合は「I don’t know」と返すこと、取得したソースを引用することを指示するテンプレートが示されています。(Microsoft Learn)
日本語の業務エージェントでは、次のように具体化すると運用しやすくなります。
あなたは社内文書に基づいて回答する業務アシスタントです。
ユーザーの質問には、必ずナレッジベースツールを使用して回答してください。
ナレッジベースに根拠がない場合は、推測せず「確認できる情報がありません」と回答してください。
回答には、参照した文書名またはソースを必ず含めてください。
社外秘、個人情報、権限外の情報は表示しないでください。ポイントは「便利に答える」よりも「根拠がないときに答えない」ことです。AIエージェントの社内展開では、正しい回答を増やすだけでなく、誤った自信を持った回答を減らす設計が重要です。
SharePoint連携とユーザー別権限制御の注意点
リモートSharePointナレッジソースを使う場合は、特に注意が必要です。公式情報では、リモートSharePointナレッジソースではx-ms-query-source-authorizationヘッダーでユーザーIDを渡し、SharePointがクエリ時にドキュメント権限を適用できると説明されています。(Microsoft Learn)
ただし、同じ公式手順では、プレビュー段階のFoundry Agent ServiceはMCPツールのリクエストごとのヘッダーをサポートしておらず、エージェント定義で設定したヘッダーはすべての呼び出しに適用され、ユーザーやリクエストごとに変えられないとされています。ユーザーごとの承認が必要な場合は、Azure OpenAI Responses APIの利用が案内されています。(Microsoft Learn)
この制約は、展開判断に直結します。
| シナリオ | 推奨判断 |
|---|---|
| 全員が同じFAQを参照する社内ヘルプ | Foundry Agent ServiceのMCP接続で検証しやすい |
| 部門ごとに文書アクセス権が違う | ナレッジソース設計とACL同期を先に確認 |
| ユーザーごとにSharePoint権限を厳密に反映したい | per-user認可の方式を別途設計し、Responses APIの検討が必要 |
| 機密文書を含む全社横断検索 | 小規模パイロットで権限制御の検証を必須にする |
「SharePointにつながるから安全」と考えるのは危険です。重要なのは、エージェントが取得する時点で、そのユーザーが本当に閲覧できる情報だけが返るかどうかです。
Microsoft Edge側で確認すべきAI/Copilot設定
Edge側では、AI/Copilot関連の表示や利用可否を管理する必要があります。2026年5月のEdge Stableリリースでは、Copilot New Tab Page、Microsoft 365 Copilot Chat、AI設定ページ、Copilot関連ポリシーの追加が案内されています。(Microsoft Learn)
Edge management serviceでは、Microsoft 365管理センターからEdgeのブラウザー設定をクラウド管理でき、設定はグループ割り当てやグループポリシーを通じてユーザーのブラウザーに適用できます。利用者は設定を取得するためにMicrosoft Edgeへサインインしている必要があります。(Microsoft Learn)
Copilot New Tab Pageを有効化する場合は、対象ユーザーを含むMicrosoft Entraグループを用意し、Edge management serviceのCopilotタブから設定を有効化します。検証時はedge://policyでCopilotNewTabPageEnabledがTRUEになっているか確認できます。(Microsoft Learn)
| Edge側の確認項目 | 確認ポイント |
|---|---|
| 対象ユーザー | Microsoft Entraグループで段階展開できるか |
| Copilot New Tab Page | CopilotNewTabPageEnabledが意図したユーザーに適用されるか |
| サイドバーCopilot | Microsoft 365 Copilot Chatアイコンの表示方針を決めているか |
| ページコンテキスト | Copilotがページ内容へアクセスしてよい範囲を定義しているか |
| ポリシー競合 | GPO、MDM、Edge management serviceの優先順位を確認したか |
| 反映確認 | edge://policy、ブラウザー再起動、対象プロファイルを確認したか |
Copilotのページコンテキストについては、CopilotPageContextポリシーでMicrosoft Edgeサイドペイン内のCopilotがページ内容にアクセスできるかを制御できます。このポリシーはMicrosoft Entra IDプロファイルに適用され、Copilotがページ要約や選択テキストとのやり取りを行うにはページ内容へのアクセスが必要です。(Microsoft Learn)
また、Microsoft 365 Copilot Chatのツールバーアイコン表示はMicrosoft365CopilotChatIconEnabledで制御できます。Edge for BusinessでのAI体験を展開する場合、単に機能を有効化するだけでなく、どのユーザーに表示し、どのデータにアクセスさせるかをセットで設計してください。(Microsoft Learn)
開発者が注意すべきAPIバージョンと本番移行
今回の公式手順で特に注意したいのは、APIバージョンの扱いです。一部のエージェント検索機能は2026-04-01 REST APIで一般提供されていますが、公式記事はプレビュー機能を含む完全な機能セットを示すために2025-11-01-previewを使っています。プレビュー機能はSLAなしで提供され、本番ワークロードには推奨されないと明記されています。(Microsoft Learn)
本番移行時は、次のように整理すると判断しやすくなります。
| 判断項目 | 検証環境 | 本番環境 |
|---|---|---|
| APIバージョン | プレビュー機能を含めて検証可能 | GA APIで代替できるか確認 |
| SDK | 最新プレビューSDKを試す | 依存関係と更新頻度を管理 |
| ナレッジソース | 少数の文書で検索品質を確認 | 権限・監査・更新頻度を確認 |
| プロンプト | 回答方針を反復調整 | 変更履歴と承認フローを用意 |
| 権限制御 | テストユーザーで確認 | 部門・役職・退職者・外部委託者まで確認 |
| 監視 | 失敗ケースを収集 | 401/403、400/404、未根拠回答を継続監視 |
開発段階では「接続できたか」だけで満足しないことが重要です。社内AIエージェントは、接続成功よりも「権限外データを出さない」「根拠がないときに答えない」「古い情報を優先しない」ことのほうが運用品質に直結します。
展開前チェックリスト
本番展開前には、管理者、開発者、セキュリティ担当者が同じチェックリストを見て確認できるようにしておくと、後戻りを減らせます。
| チェック項目 | 合格基準 |
|---|---|
| ナレッジベース | 対象業務の文書だけを含み、不要な機密文書が混在していない |
| ナレッジソース説明 | 「どの質問に使うか」が明確に書かれている |
| RBAC | FoundryとAzure AI Searchの必要ロールが最小権限で付与されている |
| マネージドID | プロジェクトのシステム割り当てマネージドIDが有効 |
| MCPエンドポイント | 検索サービスURL、ナレッジベース名、APIバージョンが正しい |
| MCPツール | allowed_toolsにknowledge_base_retrieveが設定されている |
| エージェント指示 | ナレッジベース利用、引用、不明時の回答拒否が明記されている |
| SharePoint権限 | ユーザー別認可が必要な場合の方式を確認済み |
| Edgeポリシー | 対象グループ、AI設定、Copilot表示、ページコンテキストを確認済み |
| テスト | 権限あり・権限なし・根拠なし・曖昧質問の4パターンで検証済み |
| ロールバック | エージェント、接続、Edgeポリシーを戻す手順がある |
よくある失敗と対処法
401/403が出る
Azure AI Searchから403が返る場合は、プロジェクトのマネージドIDにSearch Index Data Readerが付与されているか確認します。インデックスに書き込む構成ならSearch Index Data Contributorも必要です。Azure Resource Manager側で403が出る場合は、プロジェクト接続を作成・削除するユーザーまたはサービスプリンシパルに、Microsoft Foundryリソースとプロジェクトへの権限があるか確認してください。(Microsoft Learn)
400/404が出る
MCPエンドポイントエラーでは、search_service_endpointがhttps://<name>.search.windows.net形式のAzure AI SearchサービスURLになっているか、knowledge_base_nameがAzure AI Searchで作成したナレッジベース名と一致しているかを確認します。公式トラブルシューティングでは、ナレッジベースのMCPエンドポイントに2025-11-01-preview APIバージョンを使う点も確認事項として挙げられています。(Microsoft Learn)
エージェントが根拠を示さない
エージェントがナレッジベースを使わずに回答する場合は、MCPツールが構成されているか、allowed_toolsにknowledge_base_retrieveが含まれているか、エージェント指示でナレッジベース利用を明示しているかを確認します。取得結果に答えがないときに「確認できる情報がありません」と返すようにしておくと、幻覚回答を抑えやすくなります。(Microsoft Learn)
EdgeでCopilot機能が見えない
Edge側のCopilot機能が表示されない場合は、対象ユーザーが正しいMicrosoft Entraグループに入っているか、Edgeに職場アカウントでサインインしているか、edge://policyで対象ポリシーが反映されているかを確認します。Edge management serviceのポリシーは、GPOやMDMと競合する場合に優先順位の影響を受けるため、既存ポリシーとの競合確認も必要です。(Microsoft Learn)
Copilotナレッジソースとの混同に注意
Foundry IQとCopilotのナレッジソースは、概念としてはどちらもエージェントをエンタープライズデータに接続するものですが、サポートされるデータソースやプラットフォームは異なります。Foundry IQ FAQでは、CopilotでFoundry IQナレッジソースを使うことはできず、Foundry IQでCopilotナレッジソースを使うこともできないと説明されています。(Microsoft Learn)
この点は、社内説明で誤解が起きやすいところです。「Copilotで使えるナレッジ」と「Foundry Agent Serviceで使うFoundry IQナレッジベース」は同じものではありません。Microsoft Edge上のCopilot体験と、Foundryで作る業務エージェントをつなげて考える場合でも、データ接続、認可、対応API、展開経路は別々に確認してください。
まず取るべき次のアクション
最初にやるべきことは、全社展開ではなく、1つの業務シナリオを選んで小さく検証することです。おすすめは、社内規程や情シスFAQのように、文書の範囲が明確で、回答の正誤を確認しやすい領域です。
進め方は次の順番が現実的です。
- 対象業務とナレッジソースを1つに絞る
- Azure AI SearchでFoundry IQナレッジベースを作成する
- FoundryプロジェクトにマネージドIDと必要ロールを設定する
RemoteTool接続でMCPエンドポイントを登録する- エージェントに
knowledge_base_retrieveを追加する - 「引用あり」「根拠なし拒否」「権限外データ非表示」をテストする
- Edge側では対象グループだけにCopilot関連ポリシーを適用して検証する
今回の更新は、Microsoft EdgeのAI/Copilot活用を「便利なチャット」から「業務データに根拠を持つエージェント」へ進めるための重要な土台です。成功の鍵は、機能を有効にすることではなく、ナレッジソース、権限、APIバージョン、プロンプト、Edgeポリシーを一体で設計することです。
コメント