Azure AI Foundryで最新のWeb情報を使うAIエージェントや社内Copilotを作る場合、Agents APIの「Grounding with Bing Search」は有力な選択肢です。結論から言うと、単にBing検索を追加する機能ではなく、エージェントが検索クエリを作り、公開Webデータを取得し、回答に引用を付けるためのグラウンディング機能です。導入時は、権限、Bingリソース、Foundryプロジェクト接続、データ境界、料金、引用表示、ネットワーク条件を必ず確認してください。Microsoft Learnの公式情報では、Bing SearchとBing Custom Searchを使ったGroundingにより、Foundryモデルの知識カットオフを補い、リアルタイムの公開Webデータを応答に組み込めると説明されています。(Microsoft Learn)
Azure AI FoundryのAI/Copilot更新で何が変わるのか
今回のポイントは、Azure AI Foundryのエージェントが「学習済み知識だけで答える」状態から、「必要に応じてWebを検索し、取得した情報を根拠に回答する」構成を取りやすくなることです。
Microsoft Learnの「Use Grounding with Bing Search tools with the agents API」では、Groundingの流れとして、エージェントが情報不足を判断し、検索クエリを作成し、検索を実行し、検索結果を回答に統合し、ソースを引用する流れが示されています。つまり、開発者が検索APIの結果をそのまま整形するというより、Agents APIのツールとしてBing Searchをエージェントに組み込む考え方です。(Microsoft Learn)
| 変更点 | 実務での意味 | 確認すべきこと |
|---|---|---|
| リアルタイムWebデータを回答に使える | 最新ニュース、製品情報、公開ドキュメント、障害情報などを扱いやすくなる | 本当にWeb検索が必要な質問だけに使う設計にする |
| Bing Custom Searchが利用できる | 特定の公開ドメインや範囲に絞った回答を作りやすくなる | 対象サイトがBingにインデックスされているか確認する |
| SDKとREST APIで利用できる | Python、C#、JavaScript、Java、RESTを使った実装が可能 | 使用中のSDKバージョンとサンプルの前提を確認する |
| 管理者による制御が重要になる | 組織のコンプライアンス、費用、利用範囲に影響する | RBAC、リソースプロバイダー、Azure Policyを確認する |
| 引用表示が前提になる | ユーザーに根拠を示すUI設計が必要になる | APIの引用情報をそのまま表示できる画面を用意する |
影響範囲は開発者だけでなく管理者・法務・運用にも及ぶ
Grounding with Bing Searchは、AIアプリの精度向上だけを目的に見ると導入しやすそうに見えます。しかし実際には、Azure管理者、セキュリティ担当、法務・コンプライアンス担当、アプリ運用担当の確認が必要です。特に、Microsoft Data Protection AddendumがBing SearchやBing Custom Search経由で送信されるデータには適用されず、データがAzureのコンプライアンス境界や地理的境界の外に流れる点は、導入前に社内で合意しておくべき重要事項です。(Microsoft Learn)
| 立場 | 主な影響 | 具体的な確認ポイント |
|---|---|---|
| Azure管理者 | Bingリソース作成、権限、利用制御 | Microsoft.Bing の登録、RBAC、Azure Policy |
| 開発者 | Agents APIへのツール組み込み | 接続名・接続ID、SDK、tool_choice、引用取得 |
| セキュリティ担当 | データ送信先と境界 | 送信される情報、ネットワーク構成、監査ログ |
| 法務・コンプライアンス担当 | 利用規約と表示要件 | WebサイトURL、Bing検索クエリURL、引用の保持 |
| 運用担当 | コストと障害対応 | ツール呼び出し回数、タイムアウト、利用状況監視 |
Web Search、Grounding with Bing Search、Bing Custom Searchの使い分け
Azure AI FoundryでWebグラウンディングを始める場合、公式ドキュメントではまずWeb Searchツールから始めることが推奨されています。Web Searchは追加のAzureリソースが不要で導入しやすい一方、Grounding with Bing Searchはより多くのBing検索パラメーターを使える点や、Azureに直接デプロイされたOpenAI以外のモデルもサポートする点が違いとして説明されています。(Microsoft Learn)
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Web Search | まずWebグラウンディングを試したい。追加リソース管理を避けたい | Bing Search固有の詳細パラメーターを使いたい場合は不足することがある |
| Grounding with Bing Search | 広い公開Webから最新情報を取得したい。count、freshness、market、set_langなどを使いたい | Bing Groundingリソース、接続、費用、データ境界の確認が必要 |
| Grounding with Bing Custom Search | 自社サイト、製品ドキュメント、指定した公開ドメインに絞りたい | プレビュー機能であり、対象ページが公開されBingにインデックスされている必要がある |
Bing Custom Searchは「社内ナレッジ検索」ではなく、構成可能な公開Webドメインの範囲をエージェントに検索させる機能です。イントラネット、認証が必要なサイト、Bingにインデックスされていないページを対象にしたい場合は、Azure AI Search、ファイル検索、SharePoint連携など別のナレッジ設計を検討する必要があります。公式情報でも、Bing Custom Searchは公開され、BingにインデックスされたドメインやWebページの結果のみを返すと説明されています。(Microsoft Learn)
導入前に確認すべき前提条件
Grounding with Bing SearchをAgents APIで使うには、Azure AI Foundryのプロジェクトだけでなく、Bing GroundingまたはBing Custom Searchリソースと、そのリソースをFoundryプロジェクトに接続する設定が必要です。公式ドキュメントでは、Azureサブスクリプション、必要なRBACロール、構成済みのFoundryプロジェクト、デプロイ済みAIモデル、SDK、Azure認証情報、Bingリソースの準備が前提条件として示されています。(Microsoft Learn)
| 確認項目 | 必要な内容 | つまずきやすい点 |
|---|---|---|
| Azureサブスクリプション | 適切な権限を持つサブスクリプション | 検証環境と本番環境で権限が違う |
| RBAC | Bingリソース作成にはサブスクリプションまたはリソースグループレベルの共同作成者または所有者が必要 | 開発者にFoundry側の権限だけ付与してもリソース作成できない |
| Foundryプロジェクト | エンドポイントが構成されたプロジェクト | エンドポイントURLの取り違え |
| モデル | プロジェクトにデプロイ済みのAIモデル | モデルやリージョンがツールをサポートしていない |
| SDK | Python、C#、JavaScript、Javaなどの対応SDK | 古いSDKでサンプルコードが動かない |
| 接続情報 | SDKでは接続名、RESTでは接続IDを使う | 接続名と接続IDを混同する |
| 認証 | DefaultAzureCredentialやREST用ベアラートークン | ローカルでは動くがCI/CDで認証できない |
特に重要なのは、SDKサンプルではプロジェクト接続名を使い、RESTサンプルではプロジェクト接続IDを使う点です。接続IDはサブスクリプション、リソースグループ、Foundryアカウント、プロジェクト、接続名を含む長いリソースID形式になります。(Microsoft Learn)
管理者が確認すべき設定とガバナンス
管理者は、Grounding with Bing SearchとGrounding with Bing Custom Searchの利用をRBACロール割り当てで制御できます。公式ドキュメントでは、管理者がAzureサブスクリプションでMicrosoft.Bingリソースプロバイダーを登録し、権限を持つユーザーがBing Groundingリソースを作成し、その後Foundry接続を作成してFoundry Agent Serviceのツールとして利用する流れが示されています。(Microsoft Learn)
有効化時のチェックリスト
| 項目 | 確認内容 |
|---|---|
Microsoft.Bingの登録 | サブスクリプションでリソースプロバイダーを登録できるか |
| 権限 | Bingリソース作成者に共同作成者または所有者ロールがあるか |
| Foundry接続 | Foundryプロジェクトで接続を作成できるロールがあるか |
| リソースキー | Azure PortalのBingリソースでキーを取得できるか |
| 利用範囲 | 検証環境、本番環境、部門別サブスクリプションのどこで許可するか |
| 予算 | 検証中に大量のツール呼び出しが発生しないように制御するか |
無効化時のチェックリスト
組織としてGrounding with Bing Searchを使わせない場合は、単に開発者に「使わないでください」と伝えるだけでは不十分です。公式ドキュメントでは、無効化の流れとして、Bing Grounding関連リソースを削除し、Microsoft.Bingリソースプロバイダーの登録を解除し、Azure Policyで新規作成を禁止する手順が示されています。(Microsoft Learn)
開発者が確認すべき実装ポイント
開発者が最初に確認すべきなのは、どのエージェントに、どのBing接続を、どの条件で使わせるかです。Grounding with Bing Searchは、エージェント定義にBingグラウンディングツールを追加し、Responses API経由でエージェントを呼び出す構成になります。公式サンプルでは、PythonでAIProjectClientを作成し、接続名から接続IDを取得し、BingGroundingToolをエージェント定義に含める流れが示されています。(Microsoft Learn)
実装時は、次の順で確認すると失敗を減らせます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | Foundryプロジェクトとモデルを確認 | 対応リージョン・対応モデルか |
| 2 | Bing GroundingまたはBing Custom Searchリソースを作成 | 有料サブスクリプション、権限、リソースキー |
| 3 | Foundryプロジェクトに接続を追加 | SDK用の接続名、REST用の接続IDを控える |
| 4 | エージェント定義にツールを追加 | Bing SearchかCustom Searchかを明確にする |
| 5 | 検証クエリで動作確認 | 最新情報が必要な質問で試す |
| 6 | 引用表示を確認 | APIの引用情報をUIで表示できるか |
| 7 | 本番前に監視を追加 | ツール呼び出し回数、エラー、費用を追跡する |
エージェントがBingツールを使わずに通常回答してしまう場合は、質問が最新情報を必要としているか、エージェント定義にツールが正しく追加されているか、指示文で現在情報の取得にツールを使うよう促しているかを確認します。明示的にツール利用を強制したい場面では、公式ドキュメントでもtool_choice="required"の利用が案内されています。(Microsoft Learn)
省略可能パラメーターは検索品質に直結する
Grounding with Bing SearchやBing Custom Searchでは、count、freshness、market、set_langなどのパラメーターを渡せます。これらは検索結果の数、鮮度、地域、言語に関わるため、日本向けサービスでは特に重要です。たとえば、日本のユーザーに対して海外英語圏の結果ばかり返る場合は、marketやset_langの指定を見直す価値があります。公式ドキュメントでは、countの既定値や最大値、freshnessによる期間指定、marketとset_langの形式が説明されています。(Microsoft Learn)
| パラメーター | 使いどころ | 注意点 |
|---|---|---|
count | 候補となる検索結果数を増減したい | 多く返してもAIモデルがすべて使うとは限らない |
freshness | 直近24時間、7日、30日など鮮度を重視したい | ニュース、障害情報、リリース情報で有効 |
market | 地域に合った検索結果を返したい | 日本向けサービスでは必ず検証する |
set_lang | UI文字列や言語を調整したい | marketと合わせて設計するとブレを減らせる |
ただし、パラメーターを増やせば必ず回答品質が上がるわけではありません。実務では、ユーザーの検索意図に合わせたエージェントの指示文、検索対象の制御、引用表示、回答後の検証フローをセットで調整する必要があります。
セキュリティとコンプライアンスで特に注意すべきこと
Grounding with Bing SearchまたはBing Custom Searchを使う場合、Bingに送信される情報は、Bing検索クエリ、ツールパラメーター、リソースキーであり、サービスはエンドユーザー固有の情報を送信しないと説明されています。一方で、生成されたBing検索クエリとリソースキーはAzureコンプライアンス境界外のBing Searchサービスに転送されるため、データ主権、業界規制、政府系クラウド要件がある環境では慎重な確認が必要です。(Microsoft Learn)
実務上は、次のような社内ルールを決めてから展開するのが安全です。
| ルール | 具体例 |
|---|---|
| 入力制限 | 個人情報、顧客固有情報、契約情報をWebグラウンディングの質問に含めない |
| 利用用途 | 一般公開情報の調査、製品ドキュメント確認、公開ニュース確認に限定する |
| ログ管理 | 検索クエリや回答ログに機密情報が残らないようにする |
| 法務確認 | Bingの利用規約、表示要件、プライバシー文書を確認する |
| 例外申請 | 規制対象業務で使う場合はセキュリティレビューを必須にする |
また、Grounding with Bingの利用規約では、出力に含まれる参照情報をMicrosoftが提供した形式で保持・表示すること、参照リンクや属性情報を変更しないこと、出力をAIモデルの学習・評価・改善に使わないことなどが示されています。アプリケーション画面に引用を出さず、裏側だけで検索結果を使う設計は避けるべきです。(Microsoft)
引用表示はUI設計の必須要件
Grounding with Bing Searchでは、開発者とエンドユーザーがBing Searchから返された生コンテンツに直接アクセスする形ではありません。モデルの応答には、回答生成に使われたWebサイトへのリンクを含む引用と、検索に使われたBingクエリへのリンクが含まれると説明されています。これらの参照は、Microsoftが提供する正確な形式で保持・表示する必要があります。(Microsoft Learn)
そのため、実装では以下を確認してください。
| 確認項目 | 悪い例 | 良い例 |
|---|---|---|
| 引用の取得 | モデルに「出典URLを作って」と指示する | APIレスポンスの引用情報を使う |
| 表示位置 | 回答の末尾に曖昧に「参考: Web」と書く | 回答文の近くに引用リンクを表示する |
| Bing検索クエリ | 表示しない | 要件に従って検索クエリURLも扱う |
| UIテスト | 開発者だけが確認する | 実際のユーザー画面でリンクの表示・遷移を確認する |
引用は「信頼感を出すための装飾」ではなく、利用規約と透明性のための実装要件です。特に社内Copilotや顧客向けチャットボットでは、回答本文だけでなく、参照情報の表示状態までリリース判定に含めるべきです。
ネットワーク保護環境での展開には注意が必要
Grounding with Bing Searchツールは、ネットワークで保護されたFoundryプロジェクトで動作する場合でも、パブリックエンドポイントのように振る舞うと説明されています。さらに、トラブルシューティングでは、Bing SearchおよびBing Custom SearchによるGroundingは、VPNやプライベートエンドポイントでは機能せず、通常のインターネットアクセス、VPN未使用、Private Endpoint未構成、Bingサービスへのアウトバウンド許可を確認するよう案内されています。(Microsoft Learn)
閉域網、Private Link、厳格なファイアウォールを前提にしたAzure環境では、次の確認を本番前に行ってください。
| 確認対象 | 確認内容 |
|---|---|
| ネットワーク経路 | エージェントがBingサービスへアウトバウンド接続できるか |
| Private Endpoint | エージェントサービスでPrivate Endpoint前提の構成になっていないか |
| VPN | 検証端末や実行環境がVPN経由になっていないか |
| ファイアウォール | Bing関連サービスへの通信が遮断されていないか |
| 障害時の挙動 | 検索に失敗した場合、ユーザーにどう表示するか |
料金は検証段階から管理する
Grounding with Bing SearchとGrounding with Bing Custom Searchは追加コストが発生します。公式価格ページでは、本稿確認時点でGrounding with Bing SearchとGrounding with Bing Custom Searchのどちらも、最大150 TPS、1日100万トランザクション、1,000トランザクションあたり14ドルと表示されています。ただし、価格は変更される可能性があるため、本番導入前には必ず最新の公式価格ページと契約条件を確認してください。(Microsoft)
コスト管理で重要なのは、ユーザーの全質問に無条件でBingツールを使わせないことです。公式FAQでは、モデルの推論がGrounding with Bing SearchまたはBing Custom Searchを必要と判断したときにツールが呼び出され、Azure AI Foundry内で有効化した場合はBingから要約結果を返すためのグラウンディングトランザクションに課金されると説明されています。(Microsoft)
実務では、以下のように設計します。
| 対策 | 実装例 |
|---|---|
| 利用条件を限定する | 「最新情報が必要な場合のみWeb検索を使う」と指示する |
| 検証環境を分ける | 開発者の試行錯誤で本番サブスクリプションに課金されないようにする |
| 呼び出し回数を監視する | 予期しないツール呼び出し増加を検知する |
tool_choice="required"を乱用しない | 強制検索は検証時や明確に必要な画面に限定する |
| 回答品質を評価する | 検索したのに回答品質が上がらない質問を洗い出す |
既存のクラシック環境からの移行で見るべきポイント
クラシックのMicrosoft Foundryエージェントを使っている場合は、移行計画も必要です。クラシックのBing Groundingドキュメントでは、エージェントAPIを使った新しいWeb Searchツールの利用が推奨され、クラシックエージェントは非推奨で2027年3月31日に廃止されると説明されています。(Microsoft Learn)
新しいFoundry Agent Serviceでは、以前のAssistants APIではなくResponses APIを基盤にした開発者体験や、エージェントのバージョン管理、可観測性、エンタープライズ向け機能が強化されています。移行ガイドでは、スレッドから会話、実行から応答、アシスタント/旧エージェントから新しいエージェントへといったAPI上の主な変更点も整理されています。(Microsoft Learn)
移行時は、単にAPI呼び出しを置き換えるのではなく、以下をまとめて見直してください。
| 移行観点 | 見直す内容 |
|---|---|
| API構造 | スレッド、実行、メッセージの扱いが新APIでどう変わるか |
| ツール設定 | Bing Grounding、Web Search、Bing Custom Searchのどれを使うか |
| UI | 引用表示とBing検索クエリURL表示を満たしているか |
| セキュリティ | データ境界、ログ、入力制限を再確認する |
| コスト | 旧構成と新構成でツール呼び出し回数が変わらないか |
| 運用 | トレース、失敗時メッセージ、管理者制御を整備する |
失敗しやすいポイントと対処法
Grounding with Bing Searchは、設定項目が多いため、エラーの原因がコードなのか、権限なのか、ネットワークなのかを切り分けにくいことがあります。公式ドキュメントのトラブルシューティングでは、接続ID形式、認証、ネットワーク、Custom Searchの結果なし、構成値不足、ツール未使用、インスタンス名エラーなどが整理されています。(Microsoft Learn)
| 症状 | よくある原因 | 対処 |
|---|---|---|
UnauthorizedやForbiddenが出る | RBAC不足、資格情報不備 | 共同作成者/所有者、Azure AIプロジェクトマネージャー、DefaultAzureCredentialを確認 |
| 接続IDエラーが出る | RESTで接続名を使っている、ID形式が違う | 接続IDの完全なリソースパスを使う |
| エージェントが検索しない | 質問が最新情報を必要としていない、ツール定義不足 | 指示文を見直し、必要に応じてtool_choice="required"を使う |
| Custom Searchが空になる | 対象サイトが非公開、未インデックス、ドメイン設定ミス | 対象ドメイン、パス、Bingインデックス状況を確認 |
| 404でインスタンスが見つからない | Custom Searchインスタンス名の誤り | リソース内のインスタンス名とスペルを確認 |
| タイムアウトする | VPN、Private Endpoint、ファイアウォール | 通常のインターネットアクセスとアウトバウンド許可を確認 |
| 引用が表示されない | APIの引用情報をUIに渡していない | annotationsなど、APIが返す引用情報を表示する |
導入判断の基準
Grounding with Bing Searchを使うべきかどうかは、「Web検索ができると便利か」ではなく、「公開Webの最新情報が回答品質に不可欠か」で判断します。
使う価値が高いのは、公開ドキュメント、最新ニュース、製品リリース、法令・制度の公開情報、障害情報、技術仕様の更新などを扱うエージェントです。一方で、社内規程、顧客情報、契約内容、非公開ナレッジが主な情報源であれば、Bing GroundingよりもAzure AI Search、SharePoint、ファイル検索などの社内データ連携を優先すべきです。
導入前に、次の5点を満たしているか確認してください。
- 最新の公開Web情報が回答に必要である
- Bingに送信される検索クエリの範囲を許容できる
- 引用とBing検索クエリURLを表示できるUIがある
- 追加コストを監視・制御できる
- 管理者がRBAC、リソースプロバイダー、Azure Policyを把握している
まとめ：次に取るべき行動
Azure AI FoundryでGrounding with Bing Searchを使うと、Agents APIで構築するAIエージェントに最新の公開Web情報を組み込めます。ただし、導入の成否はコードだけで決まりません。権限、Bingリソース、Foundry接続、対応モデル、ネットワーク、データ境界、料金、引用表示を事前に確認することが重要です。
まずは小さな検証環境で、Web Search、Grounding with Bing Search、Bing Custom Searchのどれがユースケースに合うかを比較してください。そのうえで、管理者はMicrosoft.BingとAzure Policy、開発者は接続名・接続ID・引用表示、運用担当はツール呼び出し回数とエラー監視を整備します。公開Webの最新情報が回答品質を左右するエージェントであれば、Grounding with Bing Searchは有力な選択肢になります。
コメント