Microsoft Edgeを業務ブラウザとして使い、Microsoft FoundryやAIエージェント活用を進めている組織では、「MCP Server Knowledge Source in Microsoft Foundry IQ」のパブリックプレビューを確認しておく価値があります。結論から言うと、これはMicrosoft Edgeの画面やブラウザ設定が直接変わるアップデートではなく、Foundry IQのナレッジ取得元に外部MCPサーバーを追加できるようにする変更です。Salesforce、Atlassian、Confluence、ServiceNowのような外部システムや独自バックエンドの情報を、事前にAzure AI Searchへ取り込まなくても、検索・回答生成の根拠として使える可能性が広がります。(マイクロソフト アジュール)
一方で、外部MCPサーバーを「知識ソース」として扱うということは、AIエージェントの回答品質だけでなく、認証、権限、データ境界、応答遅延、監査、運用責任にも影響します。特にMicrosoft Edgeから社内ポータル、Copilot、業務アプリ、Foundryベースのエージェントを利用している環境では、「ユーザーがブラウザから投げた質問が、どの外部システムへ問い合わせられるのか」を管理者が把握できる状態にしておくことが重要です。
MCP Server Knowledge Source in Microsoft Foundry IQとは
MCP Server Knowledge Sourceは、Model Context Protocol、つまりMCPに対応した外部サーバーをFoundry IQのナレッジソースとして扱うための仕組みです。Microsoft Learnでは、MCP Server knowledge sourceを「MCP互換エンドポイントをAzure AI Searchのエージェント型検索パイプラインに接続するプレビュー機能」と説明しています。(Microsoft Learn)
従来のナレッジソースでは、Blob Storage、SharePoint、既存の検索インデックスなどをAzure AI Search側に取り込み、インデックス化してから検索対象にする構成が一般的でした。これに対してMCP Server Knowledge Sourceでは、MCPサーバーが公開するツールを検索時に呼び出し、外部システムの情報を取得します。Microsoftのドキュメントでも、MCP Server knowledge sourceはインデックス型ナレッジソースと異なり、取り込みパイプラインを必要とせず、検索時にライブデータへ直接問い合わせると説明されています。(Microsoft Learn)
実務的には、次のような使い方が想定されます。
| 利用シーン | これまでの課題 | MCP Server Knowledge Sourceで期待できること |
|---|---|---|
| Salesforceの商談情報を参照するAIエージェント | 商談データを別インデックスに同期する設計が必要 | MCPサーバー経由で検索時に必要な情報を取得しやすくなる |
| ConfluenceやAtlassian系ナレッジの参照 | ページ更新の同期遅延やコネクタ管理が負担 | MCP対応ツールを通じて、外部ナレッジを取得対象にできる |
| ServiceNowのチケット情報確認 | チケット情報の権限・鮮度・API連携が複雑 | 検索時取得により、最新状態に近い情報を使いやすくなる |
| 独自社内システムのナレッジ連携 | Azure AI Searchがネイティブ対応していない | 自社でMCPサーバーを用意すれば連携候補になる |
ポイントは、「すべてのデータをMicrosoft側に取り込む」のではなく、「必要なタイミングでMCPツールを呼び出す」方向にも選択肢が広がることです。これは、データ量が多いシステム、更新頻度が高いシステム、既存の権限管理をできるだけ維持したいシステムで特に意味があります。
Microsoft Edge利用環境では何が変わるのか
このアップデートはMicrosoft Edgeの新しいブラウザ機能ではありません。Edgeのポリシー、拡張機能、レンダリングエンジン、セキュリティ機能が直接変更されるわけではない点は、最初に整理しておくべきです。
ただし、Microsoft Edgeは多くの企業でMicrosoft 365、Copilot、社内ポータル、業務SaaS、AIエージェント画面への入口になっています。そのため、Foundry IQを使ったAIエージェントをEdge上で利用している場合、管理者が見るべき対象は「Edgeそのもの」から「Edge経由で利用されるAIエージェントのデータ取得経路」へ広がります。
Edge管理者が意識すべき変化
Edge管理者にとって重要なのは、ユーザーがブラウザから入力した質問が、どのナレッジソースに流れ、どの外部MCPサーバーが呼び出されるかです。特に次の観点は見落とされがちです。
| 確認項目 | 見るべき理由 |
|---|---|
| AIエージェントの公開範囲 | Edgeから誰がエージェントを利用できるかを把握するため |
| 接続されるMCPサーバーの一覧 | 外部システムへの問い合わせ先を可視化するため |
| ユーザー認証と権限の渡し方 | 本人が見られない情報をAIが取得しないようにするため |
| ブラウザからのアクセス制御 | 社外端末、個人端末、非管理ブラウザからの利用を制御するため |
| ログと監査の取得範囲 | 回答根拠や外部呼び出しを後から追跡できるようにするため |
例えば、営業部門向けに「顧客状況を要約するAIエージェント」をEdgeから利用させる場合、エージェントがCRM、チケット管理、Confluenceの議事録を横断して参照する可能性があります。このとき、Edgeのサインイン状態や条件付きアクセスだけでは不十分で、Foundry IQ側のナレッジソース設定、MCPサーバー側の認可、外部SaaS側の権限も合わせて確認する必要があります。
今回の変更点を実務目線で整理
今回の変更で最も大きいのは、Foundry IQの知識取得が「Azure側にインデックスしたデータ中心」から、「外部MCPサーバーを含むフェデレーション型の検索」へ広がる点です。MicrosoftのAzure AI Searchの更新情報でも、MCP Server knowledge sourceは外部MCPサーバーに接続し、任意のMCP互換ツールやサービスからグラウンディングデータを取得できる新しいリモートナレッジソースとして位置付けられています。(Microsoft Learn)
変更前と変更後の違い
| 観点 | 変更前の一般的な構成 | 変更後に可能になる構成 |
|---|---|---|
| データ取得方法 | 事前にインデックス化したデータを検索 | MCPサーバーを検索時に呼び出して取得 |
| 対象データ | Azure AI Searchが扱いやすいストレージや既存インデックス中心 | MCP互換の外部ツール、SaaS、独自APIまで拡張 |
| データ鮮度 | インデックス更新タイミングに依存 | 外部システムの最新データに近い取得が可能 |
| 設計負荷 | インデクサー、スキルセット、同期設計が必要になりやすい | MCPサーバー側のツール設計と認証設計が重要 |
| 運用リスク | インデックス肥大化、同期失敗、権限同期遅延 | 外部呼び出しの遅延、認証失敗、外部サービス障害 |
この変更は「インデックスが不要になる」という意味ではありません。ナレッジソースの性質に応じて、インデックス型とMCP型を使い分けることが重要です。
例えば、社内規程、製品マニュアル、FAQのように内容が比較的安定していて全文検索の品質を高めたい情報は、引き続きインデックス型が向いています。一方、商談ステータス、サポートチケット、在庫、ワークフロー状態のように常に変わる情報は、MCPサーバー経由で検索時に取得する方が合う場合があります。
対象者は管理者、開発者、セキュリティ担当者
このアップデートは、AIエージェントを「作る人」だけでなく、「許可する人」「監査する人」「利用環境を配布する人」にも関係します。
管理者が確認すべきこと
Microsoft EdgeやMicrosoft 365の管理者は、ユーザーがどの入口からFoundryベースのエージェントを使うかを確認しましょう。Edgeで業務アプリを固定表示している、社内ポータルからAIチャットを使わせている、TeamsやMicrosoft 365からエージェントを呼び出している場合は、利用経路を棚卸しする必要があります。
特に確認すべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| 利用者 | どの部署・グループがエージェントを使えるか |
| 端末条件 | 管理端末、準拠端末、社外端末から使えるか |
| ブラウザ条件 | Edgeサインイン、プロファイル分離、拡張機能制御が効いているか |
| データ取得先 | MCPサーバー、SaaS、社内APIの一覧があるか |
| ロール | Foundry、Azure AI Search、外部SaaSの権限が過剰でないか |
| 障害時の挙動 | 外部MCPサーバーが失敗した場合に回答を止めるか、部分回答にするか |
開発者が確認すべきこと
開発者は、MCPサーバーを「つなげること」よりも「安全に、安定して、AIが扱いやすい形で返すこと」を重視すべきです。Microsoftのドキュメントでは、MCP Server knowledge sourceに設定する主な要素として、serverURL、authentication、toolsが示されており、ツールは自動的にすべて許可されるのではなく、許可するツールを明示的に列挙する必要があります。(Microsoft Learn)
これは重要です。MCPサーバー側に「検索」「更新」「削除」「承認」など複数のツールがある場合、Foundry IQのナレッジ取得用途で本当に必要なのは検索系だけかもしれません。回答の根拠取得に使うだけなら、書き込み系ツールを許可しない設計が基本です。
ツール設計で失敗しやすい例
| 失敗例 | 起きる問題 | 改善策 |
|---|---|---|
| MCPサーバーの全ツールを許可する | AIが不要な機能まで呼び出せる | 取得専用ツールだけを明示的に許可する |
| 返却データが長すぎる | 回答遅延、コスト増、重要情報の埋没 | 要約済み・構造化済みの結果を返す |
| 権限チェックをMCP側で省略する | 本来見えないデータが回答に混ざる | ユーザーまたはサービス単位で認可を実装する |
| エラー形式が不統一 | エージェント側で原因を判断しにくい | 認証失敗、権限不足、タイムアウトを分けて返す |
| ツール名が曖昧 | クエリプランナーが使い分けに失敗する | search_cases、get_customer_summaryのように用途を明確にする |
セキュリティ担当者が確認すべきこと
MCP Server Knowledge Sourceは便利ですが、外部システム呼び出しを含むため、セキュリティ担当者の確認が不可欠です。Microsoftのドキュメントでは、2026-05-01-previewがMicrosoftサービスやサードパーティサービスへの接続をサポートする一方、データがAzureコンプライアンス境界の外で処理・保存されたり、Azure側へ流入したりする可能性があると説明されています。(Microsoft Learn)
また、MCP実装には攻撃、連鎖的障害、人間の監視喪失などのリスクがあるため、MCPサーバーのセキュリティと信頼性の確認、承認メカニズム、カスケード動作の監視が必要だとMicrosoftは注意しています。(Microsoft Learn)
確認すべきポイントは、少なくとも次の5つです。
| セキュリティ観点 | 確認する内容 |
|---|---|
| 認証 | MCPサーバー呼び出しに匿名アクセスが残っていないか |
| 認可 | ユーザー、部署、ロールごとのアクセス制御が維持されるか |
| データ境界 | 外部SaaSや他リージョンへデータが流れる可能性があるか |
| ログ | 誰が、いつ、どのツールを、どの条件で呼び出したか追えるか |
| 人間の承認 | 高リスクな取得・アクションに承認フローを設けるか |
設定・展開前に確認するべき前提条件
MCP Server Knowledge Sourceを試す前に、技術的な前提を確認しましょう。Microsoft Learnでは、MCP Server knowledge sourceを作成する前提として、エージェント型検索を提供するリージョンのAzure AI Searchサービス、HTTPSでAzure AI Searchから到達可能なMCPサーバー、ナレッジソース作成権限、2026-05-01-preview REST APIなどが挙げられています。(Microsoft Learn)
事前確認チェックリスト
| 分類 | チェック項目 | 判断基準 |
|---|---|---|
| Azure AI Search | 対象リージョンでagentic retrievalが利用できるか | 検証環境でナレッジベース作成まで確認する |
| APIバージョン | 2026-05-01-previewを使うか | プレビュー機能が必要なら同APIを指定する |
| MCPサーバー | HTTPSで到達可能か | Azure AI Searchから呼び出せる公開経路を用意する |
| 認証 | Foundry connection、stored headers、実行時ヘッダーのどれを使うか | 利用者単位・サービス単位の認可要件で選ぶ |
| ツール | 許可するMCPツールを明示したか | 不要なツールを含めない |
| 応答時間 | 外部呼び出しの最大実行時間を考慮したか | maxRuntimeInSecondsなどで余裕を持たせる |
| 監査 | 呼び出しログを取得できるか | Azure側と外部システム側の両方で確認する |
特に重要なのが、プレビュー機能である点です。Azure AI Searchのドキュメントでは、2026-05-01-previewの機能がAzureプレビュー条件の対象になることが明記されています。(Microsoft Learn) 本番ワークロードへそのまま広げるのではなく、まず検証環境で動作、権限、ログ、失敗時の挙動を確認するのが安全です。
認証方式は用途に合わせて選ぶ
MCPサーバーが認証を必要とする場合、認証方式の選択が設計の分かれ目です。Microsoftのドキュメントでは、MCP Server knowledge sourceの認証オプションとしてfoundryConnectionとstoredHeadersが示されています。また、リクエストごとの資格情報が必要な場合は、取得リクエスト時に制御ヘッダーを渡す方法も説明されています。(Microsoft Learn)
認証方式の使い分け
| 方式 | 向いているケース | 注意点 |
|---|---|---|
foundryConnection | Foundry Agent Serviceからナレッジベースを呼び出す構成 | Foundry Agent Service以外から直接呼ぶ場合は機能しない |
storedHeaders | APIキーなど静的で長期利用する資格情報を使う場合 | ユーザーごとの資格情報や頻繁に更新されるトークンには向かない |
| 実行時ヘッダー | リクエスト単位でアクセストークンを渡したい場合 | ヘッダー名・値の対応、トークン管理、ログ漏えい対策が必要 |
実務では、単に「接続できる方式」を選ぶのではなく、誰の権限で外部データを取得するのかを先に決めるべきです。営業担当者が自分の担当顧客だけを検索できるべきなのか、部門共通のサービスアカウントで検索してよいのかで、適切な認証方式は変わります。
ナレッジソースの使い分けが品質を左右する
Foundry IQでは、ナレッジソースを独立したオブジェクトとして作成し、ナレッジベースのknowledgeSources配列から参照する構成になっています。Microsoft Learnでも、ナレッジソースはスタンドアロンで作成し、その後ナレッジベースに指定すると説明されています。(Microsoft Learn)
MCP Server Knowledge Sourceを追加するときは、「とりあえず全部つなぐ」のではなく、検索意図ごとに適切な取得元を分けることが重要です。
使い分けの判断基準
| データの性質 | 推奨されるナレッジソースの考え方 |
|---|---|
| 更新頻度が低いドキュメント | Blob、SharePoint、検索インデックスなどのインデックス型 |
| 更新頻度が高い業務データ | MCP Serverやリモート系ナレッジソース |
| 権限が細かく分かれるデータ | 元システムの権限を維持できる連携方式を優先 |
| 回答根拠として引用が重要 | 参照情報、ソースデータ、引用の返し方を設計 |
| 応答速度を重視 | 事前インデックス化、キャッシュ、取得件数制限を検討 |
例えば、社内規程はSharePointやBlobからインデックス化し、顧客ごとの最新問い合わせ状況はServiceNowやCRMのMCPサーバーから取得する、というハイブリッド構成が現実的です。
展開時の注意点：プレビューだからこそ小さく始める
MCP Server Knowledge Sourceは強力ですが、最初から全社展開するのは避けるべきです。外部MCPサーバーの応答速度、認証エラー、API制限、回答の根拠表示、アクセス権限の境界など、実際に動かして初めて分かる点が多いためです。
推奨される展開ステップ
| ステップ | 実施内容 | 合格基準 |
|---|---|---|
| 検証環境を作る | 本番データではなく限定データでMCPサーバーを接続 | 接続、認証、取得、ログ確認ができる |
| ツールを絞る | 読み取り専用の検索ツールだけを許可 | 書き込み・削除・承認系ツールが呼べない |
| ユースケースを限定する | 例：社内FAQ、営業ナレッジ、サポート検索など1用途に絞る | 回答品質と誤回答パターンを評価できる |
| 権限テストを行う | 部署違い、退職者、外部ユーザー、権限なしユーザーで確認 | 本来見えない情報が返らない |
| 障害テストを行う | MCPサーバー停止、タイムアウト、認証失敗を再現 | ユーザーに誤解を与えないエラー応答になる |
| Edge利用経路を制御する | 管理対象端末・対象プロファイルからのみ利用させる | シャドーIT的な利用経路が残らない |
特に、外部MCPサーバーの応答が遅い場合は、通常の検索よりも回答時間が長くなる可能性があります。Microsoftのドキュメントでも、MCPサーバーツール呼び出しは外部ネットワークリクエストを伴い、通常の検索クエリより時間がかかることがあるため、maxRuntimeInSecondsを設定して十分な応答時間を確保するよう案内されています。(Microsoft Learn)
移行で考えるべきポイント
既存のAzure AI Search、RAG、Copilot連携をすでに構築している場合、MCP Server Knowledge Sourceへの移行は「置き換え」ではなく「追加選択肢」として考えるのが安全です。
移行判断のポイント
| 既存構成 | 移行・追加を検討する条件 | 無理に移行しない方がよい条件 |
|---|---|---|
| SharePointをインデックス化している | 権限同期や鮮度が課題になっている | 現在の回答品質と速度に問題がない |
| CRMデータを定期同期している | 同期遅延が業務上の問題になっている | API制限が厳しくリアルタイム呼び出しに不向き |
| 独自DBを検索インデックス化している | テーブル更新が多くインデックス保守が重い | 検索品質をチューニング済みで安定している |
| 外部SaaSを手動参照している | AIエージェントに横断検索させたい | SaaS側のAPIや契約条件が不明確 |
移行時にやってはいけないのは、既存のインデックス型ナレッジソースをすぐ削除することです。Microsoftのドキュメントでは、使用中のナレッジソースを削除するには、参照しているナレッジベースを削除するか、ナレッジベース定義から参照を外す必要があると説明されています。(Microsoft Learn) まずは既存構成を残したまま、MCP Server Knowledge Sourceを追加し、回答品質、速度、権限、コストを比較しましょう。
管理者が作るべき運用ルール
MCP Server Knowledge Sourceは、開発チームだけで自由に増やすと管理不能になりやすい領域です。特にEdge経由で多くの従業員が利用するAIエージェントに接続する場合は、運用ルールを先に決める必要があります。
最低限決めておきたいルール
| ルール | 内容 |
|---|---|
| MCPサーバー登録申請 | 目的、データ種別、管理者、認証方式、利用部署を明記する |
| 許可ツールの審査 | 読み取り専用か、書き込み操作を含むかを確認する |
| データ分類 | 個人情報、機密情報、顧客情報、契約情報を扱うか判断する |
| プロンプト・回答検証 | 典型質問、悪意ある質問、権限境界テストを行う |
| ログ保存期間 | 誰がどのMCPサーバーを使ったか追跡できるようにする |
| 変更管理 | MCPサーバー側のツール追加・仕様変更をFoundry側へ通知する |
| 廃止手順 | 使わなくなったナレッジソースをナレッジベースから外す手順を定める |
このルールがないまま導入すると、「誰が作ったか分からないMCPサーバーがAIエージェントから呼ばれている」「外部SaaSの仕様変更で回答品質が急に落ちる」「退職者や異動者の権限が反映されない」といった問題が起きやすくなります。
Microsoft Edge側で見直したい設定
今回の機能はFoundry IQ側の更新ですが、Edge管理者が何もしなくてよいわけではありません。AIエージェントをブラウザから利用する場合、Edgeの管理ポリシーやMicrosoft Entra IDの条件付きアクセスと組み合わせて、利用経路を整理しましょう。
Edge環境で確認したい項目
| 項目 | 目的 |
|---|---|
| 職場プロファイルの利用 | 個人プロファイルから業務AIへアクセスさせない |
| サインイン必須化 | 誰が利用しているかを識別する |
| 拡張機能の制御 | 入力内容や回答を外部へ送信する拡張機能を抑止する |
| ダウンロード制御 | AI回答から取得した機密資料の持ち出しを抑える |
| セッション制御 | 非準拠端末や社外ネットワークからの利用を制限する |
| URL許可リスト | Foundryポータル、社内AIアプリ、外部MCP管理画面へのアクセスを制御する |
特に、AIエージェントの回答欄には顧客名、案件名、社内手順、チケット内容などが表示される可能性があります。Edgeの管理は「ブラウザを安全にする」だけでなく、「AIが表示した業務データをどの環境で扱わせるか」を決める役割を持ちます。
よくある誤解と正しい理解
EdgeのアップデートでMCPサーバーが自動的に有効になるわけではない
今回の内容はMicrosoft Edgeのブラウザ更新ではなく、Microsoft Foundry IQおよびAzure AI Searchのナレッジソース拡張です。Edgeを更新しただけで外部MCPサーバー連携が有効になるわけではありません。
外部データをMicrosoftにすべてコピーしなくてよいが、データ流通の確認は必要
MCP Server Knowledge Sourceは検索時に外部MCPサーバーを呼び出すため、従来のような取り込みパイプラインが不要になるケースがあります。ただし、データがどこで処理されるか、どの資格情報で取得されるか、外部サービスの利用規約に沿っているかは別問題です。
MCP対応なら何でも安全に使えるわけではない
MCPは接続の標準化に役立ちますが、セキュリティ品質まで自動で保証するものではありません。MCPサーバーの実装、認証、認可、ログ、ツールの粒度、エラー処理は、導入側が確認する必要があります。
リアルタイム取得は常に最適とは限らない
検索時に外部へ問い合わせる方式はデータ鮮度に強い一方、応答遅延や外部サービス障害の影響を受けます。安定した静的ドキュメントはインデックス型、鮮度が重要な業務データはMCP型、という使い分けが現実的です。
導入前の実践チェックリスト
最後に、管理者・開発者・セキュリティ担当者が導入前に確認すべき項目をまとめます。
| 担当 | 確認項目 | 完了の目安 |
|---|---|---|
| 管理者 | Edgeから利用されるAIエージェントの一覧を作成した | 利用部署、URL、公開範囲が分かる |
| 管理者 | MCP Server Knowledge Sourceの利用有無を確認した | どのエージェントが外部MCPを使うか分かる |
| 開発者 | MCPサーバーのツールを読み取り中心に絞った | 許可ツール一覧をレビュー済み |
| 開発者 | 認証方式を決めた | foundryConnection、storedHeaders、実行時ヘッダーの選定理由がある |
| セキュリティ担当 | データ分類と越境・外部処理の可能性を確認した | 個人情報・機密情報の扱いが明確 |
| セキュリティ担当 | 権限境界テストを実施した | 権限なしユーザーで情報が返らない |
| 運用担当 | 失敗時の挙動を決めた | 部分回答、エラー表示、再試行方針が決まっている |
| 運用担当 | ログと監査の取得先を確認した | Azure側と外部MCP側のログが追える |
MCP Server Knowledge Source in Microsoft Foundry IQは、AIエージェントが参照できる情報の範囲を大きく広げるプレビュー機能です。Microsoft Edge管理者にとっては、ブラウザ設定そのものの変更ではなく、Edgeから利用されるAIエージェントのデータ取得経路を管理対象に含めるきっかけと考えると分かりやすいでしょう。
まずは、本番利用中のエージェントに直接追加するのではなく、限定された検証環境で「どのMCPサーバーを呼ぶのか」「誰の権限で取得するのか」「回答根拠を追跡できるのか」「外部サービス停止時にどう振る舞うのか」を確認してください。そのうえで、Edgeの利用制御、Foundry IQのナレッジソース設計、MCPサーバーの認証・認可を一体で整備することが、安全な展開への近道です。
コメント