Microsoft Edge関連の更新として見かけた「[In preview] Public Preview: Azure SQL as a knowledge source in Foundry IQ」は、Edgeブラウザーの設定やポリシー変更ではなく、Microsoft Foundry / Azure AI Search 側のプレビュー機能です。要点は、Azure SQL Database のテーブルやビューを Foundry IQ の Knowledge Source として扱い、Copilot、RAG、エージェント型アプリの回答根拠に使いやすくなることです。Edge管理者がブラウザー配布を急ぐ内容ではありませんが、社内AIや業務データ検索を設計している管理者・開発者は、権限、インデックス化、同期方式、プレビュー利用条件を必ず確認しておくべき更新です。MicrosoftのAzure Updatesでは、この機能が Public Preview として案内されています。(マイクロソフト Azure)
Microsoft Edgeの変更ではなく、Foundry IQとAzure AI Searchのナレッジ連携強化
今回の「Public Preview: Azure SQL as a knowledge source in Foundry IQ」は、名称だけを見るとMicrosoft Edge関連の告知のように見える場合があります。しかし、実際の対象はMicrosoft Edgeのブラウザー機能ではなく、Microsoft Foundry、Foundry IQ、Azure AI Search、Azure SQL Databaseの連携です。
Microsoft Learnのページには「Microsoft Edgeにアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます」という汎用的な案内が表示されることがありますが、これはドキュメント閲覧環境に関する表示であり、今回の機能変更そのものを指すものではありません。(Microsoft Learn)
今回の更新で重要なのは、Azure SQL DatabaseまたはAzure SQL Managed Instanceの行データを、Azure AI Searchのエージェント検索パイプラインに取り込み、Foundry IQのKnowledge Baseから参照できるようになる点です。公式ドキュメントでは、Azure SQLの各行が1つの論理ドキュメントとして扱われ、列マッピングに基づいてインデックス、データソース、必要に応じた埋め込み生成用スキルセット、インデクサーが作成されると説明されています。(Microsoft Learn)
何が変わるのか
これまでAzure SQLの業務データをRAGや社内Copilotに使う場合、開発者はSQLからデータを抽出し、検索用インデックスに変換し、ベクトル化し、更新差分を取り込む仕組みを個別に設計する必要がありました。
今回のプレビューにより、Azure SQLをFoundry IQのKnowledge Sourceとして扱えるようになり、Azure AI Search側でエージェント検索向けの取り込みパイプラインを構成しやすくなります。
| 観点 | 従来の設計で発生しやすかった作業 | 今回のプレビューで期待できる変化 |
|---|---|---|
| データ接続 | SQLから独自ETLやバッチで抽出 | Azure SQLをKnowledge Sourceとして定義 |
| 検索用データ化 | テーブル構造を検索インデックス向けに手作業で変換 | 列マッピングからインデックスを生成 |
| ベクトル検索 | 埋め込み生成処理を別途実装 | embeddingColumns指定時に埋め込み生成を構成 |
| エージェント連携 | アプリ側で検索処理、再ランキング、回答根拠付けを実装 | Knowledge Base経由でエージェント検索に組み込み |
| 運用 | 更新検知、インデクサー監視、権限設計が分散 | Azure AI Searchの管理対象として整理しやすい |
ただし、これは「SQLをリアルタイムに直接検索する機能」ではありません。公式ドキュメントでは、リアルタイム同期とリアルタイムSQL取得はサポートされず、生成されたインデクサーはスケジュールベースで動作すると説明されています。(Microsoft Learn)
影響を受ける対象者
今回の更新で直接影響を受けるのは、Microsoft Edgeの一般利用者ではありません。主な対象は、Azure上で社内AI、Copilot、RAG、エージェント型アプリを構築している開発者、アーキテクト、Azure管理者、データベース管理者です。
| 対象者 | 確認すべきこと |
|---|---|
| Microsoft Edge管理者 | Edgeポリシー、拡張機能、IEモードの変更は基本的に不要。社内ポータルやAIアプリをEdgeで利用する場合のみ動作検証を行う |
| Azure管理者 | Azure AI Search、Foundry、Azure SQL、マネージドID、RBACの権限設計を確認する |
| 開発者 | Knowledge Source、Knowledge Base、MCP連携、APIバージョン、SDKのプレビュー対応を確認する |
| データベース管理者 | 対象テーブル・ビュー、主キー、変更追跡、行データの公開範囲を確認する |
| セキュリティ担当者 | 機密情報、個人情報、アクセス制御、コンプライアンス境界を確認する |
Foundry IQは、Azure、SharePoint、OneLake、Webなどの構造化・非構造化データをつなぎ、エージェントが権限を考慮したナレッジにアクセスできるようにする管理型ナレッジレイヤーと位置付けられています。(Microsoft Learn)
管理者と開発者が最初に確認すべき設定
Public Previewは、正式リリース済み機能とは扱いが異なります。Azure Updates上でも「In preview」は、すべてのAzure顧客が非本番利用とテスト目的で使用できる状態として説明されています。(マイクロソフト Azure)
本番システムへ組み込む前に、次の項目を確認してください。
| 確認項目 | 判断基準 | 見落とすと起きやすい問題 |
|---|---|---|
| プレビュー利用可否 | 本番利用前提ではなく、検証環境で試す | SLAや仕様変更リスクを見落とす |
| APIバージョン | 2026-05-01-previewの利用が必要 | 古いAPIでKnowledge Sourceを作成できない |
| Azure AI Searchのリージョン | エージェント検索を提供するリージョンか | 機能が利用できない |
| SQLの対象 | 1つのテーブルまたは1つのビュー | 複数テーブル前提の設計が破綻する |
| 主キー | 単一値の主キーが必要 | 複合キーのテーブルをそのまま使えない |
| ビューの変更検出 | rowversion列など高水位変更検出に適した列 | 更新差分を正しく検出できない |
| 同期方式 | スケジュールベース | 在庫数や残高などリアルタイム性が必要な用途に不向き |
| 列マッピング | 検索対象列とベクトル化対象列を明確に分ける | 不要な列までAIの根拠に含まれる |
| 権限 | Search Service Contributor、Search Index Data Contributor、Cognitive Services Userなどを確認 | 401、403、埋め込み生成失敗が発生する |
| データ境界 | プレビュー利用時のデータ処理・保存場所を確認 | コンプライアンス要件と衝突する |
Azure SQL Knowledge Sourceでは、1つのナレッジソースが取り込めるのは1つのテーブルまたは1つのビューであり、複合キーはサポートされません。また、画像抽出や画像の言語化は対象外です。(Microsoft Learn)
移行・展開時の実務ポイント
既存のRAG基盤や社内CopilotにAzure SQLデータを使っている場合でも、すぐに全面移行する必要はありません。まずは「SQLのどのデータをAIの回答根拠にするべきか」を整理することが重要です。
使いやすいデータの例
Azure SQL Knowledge Sourceと相性がよいのは、1行ごとに意味のまとまりがあり、検索や回答根拠に使いやすいデータです。
| 向いている例 | 理由 |
|---|---|
| 商品マスタ、サービス仕様、料金プラン説明 | 1レコード単位で説明文を持ちやすい |
| FAQ、問い合わせ分類、ナレッジ記事の管理テーブル | RAGの根拠として扱いやすい |
| 社内規程の要約テーブル | 部署、カテゴリ、有効日などでフィルターしやすい |
| 障害対応履歴、過去チケットの要約 | 類似事例検索に使いやすい |
そのまま使うと危険なデータの例
一方で、次のようなデータは慎重に扱う必要があります。
| 注意が必要な例 | 理由 |
|---|---|
| 在庫数、口座残高、リアルタイムステータス | スケジュール同期のため最新値とは限らない |
| 個人情報を含む顧客テーブル | 検索インデックスに取り込む範囲を厳密に制御する必要がある |
| 権限が複雑な業務テーブル | SQL側の権限がそのまま検索結果に反映されるとは限らない |
| 正規化された複数テーブル | 1つのKnowledge Sourceは1テーブルまたは1ビュー前提のため、検索向けビュー設計が必要 |
実務では、業務テーブルを直接Knowledge Sourceにするよりも、AI検索用に整形したビューまたは専用テーブルを用意する方が安全です。たとえば、顧客管理システムの全カラムを取り込むのではなく、AI回答に必要な「契約プラン名」「公開可能な説明文」「サポート対象範囲」「更新日」だけを含むビューを作る、といった設計です。
Knowledge Baseとエージェント連携で確認すること
Azure AI SearchのKnowledge Baseは、どのKnowledge Sourceを検索するか、検索時の既定動作、取得パイプラインを管理する上位オブジェクトです。公式ドキュメントでは、Knowledge Baseがエージェント検索をオーケストレーションし、Knowledge Source、必要に応じたLLM、ルーティングや暗号化などの設定を持つと説明されています。(Microsoft Learn)
Foundry Agent Serviceと接続する場合は、MCPを介してKnowledge Baseをツールとして呼び出します。Knowledge Baseはユーザーの質問をサブクエリへ分解し、キーワード検索、ベクトル検索、ハイブリッド検索、セマンティック再ランキングなどを組み合わせ、出典付きの結果としてエージェントに渡します。(Microsoft Learn)
展開前には、特に次の3点を確認してください。
| 確認ポイント | 実務上のチェック内容 |
|---|---|
| エージェント指示 | ナレッジに存在しない内容は「分からない」と返すように指示する |
| 出典表示 | 取得したSQL行や検索結果を根拠として追跡できるか確認する |
| 権限エラー | 403が出る場合、プロジェクトのマネージドIDにSearch Index Data Readerなどが付与されているか確認する |
公式ドキュメントでも、エージェントがKnowledge Baseを使わずに学習済み知識だけで回答してしまう場合は、Knowledge Baseを使うよう明示し、回答が見つからない場合は「I don’t know」と返す指示に更新することが推奨されています。(Microsoft Learn)
失敗しやすいポイント
SQLをリアルタイム検索できると誤解する
Azure SQL Knowledge Sourceは、SQLに対して毎回リアルタイムクエリを投げる仕組みではありません。インデックス化されたKnowledge Sourceとして扱われるため、更新反映にはインデクサーの実行タイミングが関係します。
在庫引当、金融取引、配送ステータスなど、秒単位の正確性が必要な処理は、Knowledge Sourceではなく業務APIや専用ツール呼び出しで扱うべきです。
正規化された業務DBをそのまま取り込む
業務データベースは、検索や自然言語回答のためではなく、業務処理の整合性のために設計されています。注文、顧客、商品、請求、権限が複数テーブルに分かれている場合、そのまま1テーブルだけを取り込むと文脈不足になります。
AI検索用には、読み取り専用ビューやデータマートを作り、1行で意味が通る形に整えてからKnowledge Sourceにするのが現実的です。
機密列を不用意に含める
検索に使わない列までcontentColumnsに含めると、AIの回答根拠に不要な情報が混ざります。社内ID、内部メモ、個人情報、原価、未公開価格などは、取り込む前に除外を検討してください。
生成されたオブジェクトを直接編集する
Azure SQL Knowledge Sourceを作成すると、データソース、インデックス、スキルセット、インデクサーなどが生成されます。公式ドキュメントでは、これらの生成オブジェクトは固定テンプレートに基づき、名前もKnowledge Source名に基づいて作られるため、直接編集すると互換性やインデクサーパイプラインに問題が出る可能性があると説明されています。(Microsoft Learn)
設定変更が必要な場合は、Knowledge Source定義や再作成手順を管理対象にし、手作業で生成済みインデックスだけを修正する運用は避けるべきです。
Microsoft Edge管理者が対応すべきこと
Microsoft Edge管理者の観点では、今回の更新によりEdgeのグループポリシー、更新チャネル、拡張機能、IEモード設定を変更する必要は基本的にありません。
ただし、社内でFoundry IQを使ったAIアプリやCopilot風の業務ポータルをEdgeで利用する場合は、次の確認は有効です。
| 確認項目 | 対応内容 |
|---|---|
| 社内AIアプリのURL | Edgeのエンタープライズサイトリストやプロキシ設定に影響しないか確認 |
| 認証 | Microsoft Entra IDサインイン、条件付きアクセス、多要素認証の挙動を確認 |
| データ保護 | コピー制御、DLP、ブラウザー経由のファイルダウンロード制御を確認 |
| 拡張機能 | 社内AIアプリと競合する拡張機能がないか確認 |
| 利用者教育 | AI回答がSQLの最新値とは限らないことを明記 |
Edgeそのものの更新ではないため、ブラウザー管理者だけで完結する話ではありません。Azure管理者、DBA、セキュリティ担当、AIアプリ開発者で確認範囲を分担するのが安全です。
まず取るべき次の行動
今回のプレビューを検証するなら、最初から本番DBや機密データを接続するのではなく、影響の小さいデータで小さく試すのが現実的です。
おすすめの進め方は次の通りです。
- 社内でAI回答に使いたいAzure SQLデータを1テーマに絞る
- 検索向けの読み取り専用ビューまたは検証用テーブルを作る
- 単一主キー、変更追跡、
rowversion、除外すべき列を確認する - 検証用のAzure AI SearchとFoundryプロジェクトでKnowledge Sourceを作成する
- Knowledge Baseに追加し、エージェントからMCP経由で呼び出す
- 回答精度、出典、権限、更新反映、インデクサーエラーを確認する
- プレビュー条件を踏まえ、本番適用は正式提供状況と社内基準を確認して判断する
今回の「Public Preview: Azure SQL as a knowledge source in Foundry IQ」は、Microsoft Edgeのブラウザー運用を変える更新ではありません。一方で、Azure SQLに蓄積された業務データを、Copilot、RAG、エージェント型アプリの信頼できる根拠として使うための重要な一歩です。管理者と開発者は、プレビューであること、SQLデータがインデックス化されること、リアルタイム取得ではないこと、権限とデータ境界の設計が必要なことを押さえたうえで、まずは限定的な検証環境から始めるのが安全です。
コメント