Azure AI Foundryで最新情報に基づくAI回答を作りたい場合、今回まず押さえるべき結論は、Responses APIではWeb検索ツールとしてweb_searchを使う、という点です。従来のweb_search_previewはサポート対象ではあるものの推奨されていないため、既存コードや検証環境で使っている場合は見直しが必要です。Microsoft Learn日本語版の公式ページは2026年5月14日に更新されており、Web検索の使い方だけでなく、管理者による有効化・無効化、コスト、データ境界、ドメイン制限、移行時の注意点まで確認すべき内容が整理されています。(Microsoft Learn)
Azure AI Foundryの「Web search with the Responses API」とは
Azure AI Foundryにおける「Web search with the Responses API」は、Azure OpenAIのResponses APIからweb_searchツールを呼び出し、モデルが回答を生成する前に公開Web上の情報を検索・参照できるようにする機能です。
通常のLLMは、モデルが学習済みの知識や入力されたコンテキストをもとに回答します。一方でWeb検索を有効にすると、ニュース、製品情報、仕様変更、価格、規制、公開ドキュメントなど、時間とともに変わる情報を検索し、その結果を根拠として回答を生成できます。公式ドキュメントでは、Web検索を有効にすると最新情報を含む引用付きの回答を返せると説明されています。(Microsoft Learn)
実務上は、次のような用途で特に効果があります。
- 最新のMicrosoft Learnやベンダードキュメントを参照する社内AIアシスタント
- ニュースや市場動向を要約する調査支援ツール
- 公開Web上の製品仕様やFAQを根拠付きで回答するサポートボット
- 医療、法務、金融などで信頼できる公開情報源に限定して調査するワークフロー
ただし、Web検索を使えば何でも安全に最新化できるわけではありません。検索クエリとして送信されるデータ、参照先の信頼性、コスト、レイテンシ、引用表示の扱いまで含めて設計する必要があります。
何が変わるのか：実務で重要なポイント
今回の公式情報で最も重要なのは、Responses APIで使うWeb検索ツールの扱いが明確になったことです。Azure OpenAI Responses APIではweb_searchを使い、web_search_previewは推奨されません。既存の検証コードやサンプルをそのまま本番化しようとしている場合は、この違いを最初に確認してください。(Microsoft Learn)
| 確認項目 | 内容 | 実務への影響 |
|---|---|---|
| 推奨ツール名 | web_search | web_search_previewを使っているコードは移行対象 |
| API | Responses API | Chat Completions APIの延長ではなく、Responses API前提で設計する |
| 検索モード | 推論なし、推論モデルによるエージェント検索、Deep Research | 速度重視か、調査品質重視かで使い分ける |
| 管理者制御 | サブスクリプション単位で有効化・無効化 | 1つの設定が同一サブスクリプション内の複数アカウントに影響する |
| 引用 | url_citationとしてレスポンスに含まれる | UI側で出典表示や監査ログの設計が必要 |
| ドメイン制限 | 許可ドメインを指定可能 | 信頼できる情報源に限定した検索がしやすくなる |
| データ境界 | Bing Search / Bing Custom Searchへのデータ送信に注意 | コンプライアンス、地理的境界、機密情報の扱いを事前確認する |
| コスト | Web検索やBingでのグラウンディングに費用が発生 | PoC段階から利用量と検索回数を監視する |
特に管理者とセキュリティ担当者が見落としやすいのは、Web SearchがGrounding with Bing SearchまたはGrounding with Bing Custom Searchを利用し、送信データがコンプライアンス境界や地理的境界の外に流れる可能性がある点です。MicrosoftのData Protection Addendumが該当データに適用されないことも明記されています。(Microsoft Learn)
対象者ごとの確認ポイント
この更新は、単に開発者がAPIパラメータを変更すればよい話ではありません。Azure AI Foundryで生成AIアプリを運用している組織では、管理者、開発者、セキュリティ担当者、プロダクト責任者がそれぞれ確認すべき項目があります。
| 対象者 | 確認すべきこと | 具体的なアクション |
|---|---|---|
| Azure管理者 | web_searchを許可するか、ブロックするか | サブスクリプション単位の設定方針を決める |
| 開発者 | web_search_previewからweb_searchへの移行 | コード、SDK、レスポンス解析、テストケースを見直す |
| セキュリティ担当者 | 検索クエリに機密情報が含まれないか | 入力フィルタ、ログ設計、ドメイン制限を検討する |
| コンプライアンス担当者 | データ境界と利用規約 | Bing関連サービスへのデータ送信可否を確認する |
| プロダクト責任者 | 速度、品質、コストのバランス | 検索モードと利用シーンを決める |
| 運用担当者 | 障害時やブロック時の挙動 | 「引用がない」「ツールがブロックされた」場合のエラーハンドリングを用意する |
開発者が最初に確認すべき前提条件
Responses APIでWeb検索を使うには、事前にAzure OpenAIモデルのデプロイ、認証方式、実行環境を確認します。公式ドキュメントでは、Azure OpenAIモデルのデプロイ、APIキーまたはMicrosoft Entra IDによる認証、Python利用時のopenaiパッケージやazure-identityの準備が前提条件として示されています。(Microsoft Learn)
本番環境では、次の順序で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 対象API | /openai/v1/responsesを使う |
| 2 | モデル | Web SearchはGPT-4以降のモデルで動作する前提で設計する |
| 3 | 認証 | APIキーまたはMicrosoft Entra IDを使う |
| 4 | 管理者設定 | サブスクリプションでweb_searchがブロックされていないか確認する |
| 5 | 検索制御 | 必要に応じてuser_locationやドメインフィルタを使う |
| 6 | 出力処理 | 回答本文だけでなく、引用情報をUIやログで扱えるようにする |
Azure OpenAI Responses API自体は最新機能にアクセスするためにv1 APIが必要とされています。また、Responses APIの利用可否はリージョンやモデルによって変わるため、japaneastなど対応リージョンに見えても、利用したいモデルがそのリージョンで使えるとは限りません。展開前にモデルのリージョン可用性を確認してください。(Microsoft Learn)
最小構成のリクエスト例
最小構成では、Responses APIのリクエストにtoolsとしてweb_searchを指定します。ポイントは、Web検索を「プロンプトでお願いするだけ」にしないことです。ツールとして宣言しなければ、モデルがWeb検索を使える状態にはなりません。
{
"model": "gpt-4.1",
"tools": [
{
"type": "web_search"
}
],
"input": "最新のAzure AI FoundryのResponses APIに関する公式情報を調べて要約してください。"
}Azure OpenAIでは、modelに実際のモデル名ではなくデプロイ名を指定する構成になっている環境があります。サンプルコードを流用するときは、自社のAzure AI Foundry上で作成したデプロイ名に置き換えてください。
レスポンスには、Web検索を実行したことを示すweb_search_callと、生成されたメッセージが含まれます。引用はmessage.content[0].annotations内のurl_citationとして扱われ、URL、タイトル、文字範囲などを取得できます。引用を画面に表示する場合は、回答文だけを取り出すのではなく、注釈情報も保持する設計にしてください。(Microsoft Learn)
Web検索の3つの使い分け
公式ドキュメントでは、Web検索の利用方法として「推論なしのWeb検索」「推論モデルを使ったエージェント検索」「Deep Research」の3つが整理されています。使い分けを誤ると、必要以上に遅くなったり、逆に調査品質が足りなくなったりします。(Microsoft Learn)
| モード | 向いている用途 | 注意点 |
|---|---|---|
| 推論なしのWeb検索 | 最新ニュース、公式ページの確認、単純な事実確認 | 速いが、複雑な調査には向きにくい |
| 推論モデルによるエージェント検索 | 複数条件の比較、原因分析、調査手順が必要な質問 | 検索回数や処理時間が増えやすい |
| Deep Research | 法務・科学調査、市場分析、競合調査、大量情報の統合 | 数分かかる可能性があり、バックグラウンド処理向き |
例えば、ユーザーが「今日発表されたAzureの更新を3行で教えて」と聞く用途なら、推論なしのWeb検索で十分な場合があります。一方で、「複数ベンダーの公式ドキュメントを比較し、移行リスクを表にまとめて」といった依頼では、推論モデルによるエージェント検索やDeep Researchを検討する価値があります。
管理者が確認すべき有効化・無効化設定
Web検索は、開発者が勝手に使えるかどうかだけで判断してはいけません。公式ドキュメントでは、Azure CLIを使ってResponses APIのweb_searchツールをサブスクリプションレベルで有効化または無効化できると説明されています。この設定は、指定したサブスクリプション内のすべてのアカウントに適用されます。(Microsoft Learn)
無効化する場合は、次のコマンドを使います。
az feature register \
--name OpenAI.BlockedTools.web_search \
--namespace Microsoft.CognitiveServices \
--subscription "<subscription-id>"有効化する場合は、次のコマンドを使います。
az feature unregister \
--name OpenAI.BlockedTools.web_search \
--namespace Microsoft.CognitiveServices \
--subscription "<subscription-id>"ここで間違えやすいのは、registerが「有効化」ではなく、OpenAI.BlockedTools.web_searchというブロック機能を登録するため、結果としてWeb検索を無効化する点です。反対に、unregisterでブロック機能を外すとWeb検索が有効になります。(Microsoft Learn)
本番環境で変更する前に、次の点を必ず確認してください。
- 対象サブスクリプションに本番・検証・開発のリソースが混在していないか
- 無効化した場合に、既存アプリの回答品質や機能に影響しないか
- 有効化した場合に、データ送信、コスト、監査ログのルールが整っているか
- OwnerまたはContributor権限を持つ担当者だけが変更できる運用になっているか
- 変更後に、実際のAPI呼び出しでWeb検索が使えるか、またはブロックされるかを確認したか
セキュリティとコンプライアンスで特に注意すべき点
Azure AI FoundryのWeb検索機能は便利ですが、社内データや顧客データを扱うアプリでは慎重な設計が必要です。公式ドキュメントでは、Grounding with Bing SearchやGrounding with Bing Custom Searchを使う場合、データがコンプライアンス境界および地理的境界の外部に送信されると説明されています。(Microsoft Learn)
特に避けるべきなのは、ユーザー入力をそのまま検索クエリに渡す実装です。例えば、次のような情報が入力される可能性がある画面では、Web検索の前にマスキングや利用可否判定を入れるべきです。
- 顧客名、メールアドレス、電話番号
- 契約内容、見積金額、未公開の製品情報
- 社内インシデント、脆弱性情報、障害情報
- 医療、金融、人事などのセンシティブ情報
- NDA対象のプロジェクト名やコードネーム
実務では、「Web検索してよい質問」と「社内RAGやナレッジベースだけで処理すべき質問」を分ける設計が有効です。たとえば、公開ドキュメントの更新確認にはWeb検索を使い、顧客別の契約条件や内部手順はAzure AI Searchなどの社内データソースに限定する、といった分離が考えられます。
ドメインフィルタで検索対象を絞る
Web検索を業務利用する場合、検索対象を広くしすぎると、信頼性の低いページや古い記事を参照するリスクが高まります。Responses APIのWeb検索では、allowed_domainsを使って検索対象ドメインを制限できます。公式ドキュメントでは、許可リストに最大100個のURLを指定でき、HTTP/HTTPSのプレフィックスは省略可能、サブドメインも検索対象に含まれると説明されています。(Microsoft Learn)
例えば、医療系の調査支援であれば、公的機関や査読論文データベースに限定する設計が考えられます。
{
"model": "gpt-4.1",
"tools": [
{
"type": "web_search",
"filters": {
"allowed_domains": [
"pubmed.ncbi.nlm.nih.gov",
"clinicaltrials.gov",
"www.who.int"
]
}
}
],
"input": "糖尿病治療に関する最新の公的情報を要約してください。"
}ドメインフィルタは、検索品質を上げるだけでなく、監査や説明責任の観点でも役立ちます。ただし、許可ドメインに含まれるページが常に正しいとは限りません。回答UIでは引用元を表示し、重要な判断は人間が原典を確認できる導線を残してください。
ユーザーの場所を指定して検索結果を調整する
Web検索では、user_locationを使って国や地域に応じた検索結果に寄せることができます。公式ドキュメントでは、2文字の国・地域コードを指定して検索結果を絞り込めると説明されています。(Microsoft Learn)
日本向けのサービスであれば、次のようにJPを指定する設計が考えられます。
{
"model": "gpt-4.1",
"tools": [
{
"type": "web_search",
"user_location": {
"type": "approximate",
"country": "JP"
}
}
],
"input": "日本国内向けのMicrosoft 365関連の最新情報を調べてください。"
}注意したいのは、場所指定はあくまで検索結果を調整するための設定であり、回答の正確性を保証するものではないことです。法令、価格、提供リージョン、サポート範囲などは、必ず公式ページの引用と組み合わせて確認する運用にしてください。
external_web_accessではなくweb_searchを使う
移行時に見落としやすいのが、external_web_accessの扱いです。公式ドキュメントでは、ライブインターネットアクセスはサポートされておらず、external_web_accessパラメータを渡しても無視されると明記されています。(Microsoft Learn)
つまり、次のような実装は期待通りに動きません。
{
"model": "gpt-4.1",
"external_web_access": true,
"input": "最新情報をWebで調べてください。"
}Web検索を使いたい場合は、必ずtoolsにweb_searchを指定します。
{
"model": "gpt-4.1",
"tools": [
{
"type": "web_search"
}
],
"input": "最新情報をWebで調べてください。"
}この違いは、既存のOpenAI APIサンプルや古い検証コードをAzure AI Foundryに移植するときに問題になりやすいポイントです。移行時には、パラメータ名だけでなく、APIエンドポイント、認証方式、レスポンス構造までまとめて確認してください。
移行チェックリスト
既存アプリやPoC環境から本番利用へ進める場合は、次のチェックリストを使うと安全です。
| チェック項目 | 確認内容 |
|---|---|
| ツール名 | web_search_previewではなくweb_searchを使っているか |
| API | Responses APIの/openai/v1/responsesを使っているか |
| モデル | 対象リージョンで利用できるモデルデプロイか |
| 認証 | APIキーを直書きしていないか、Entra ID利用も検討したか |
| 管理者設定 | サブスクリプションでWeb検索がブロックされていないか |
| データ保護 | 検索クエリに機密情報が含まれない設計か |
| ドメイン制限 | 業務上必要な場合、許可ドメインを定義したか |
| 引用表示 | url_citationをUIやログで扱えるか |
| コスト | 検索回数、Deep Research利用、ツール呼び出しを監視できるか |
| 障害対応 | 引用なし、ツールブロック、認証エラー時の分岐を実装したか |
特にweb_search_previewからの移行では、単純な文字列置換だけで終わらせないことが重要です。レスポンスに含まれる引用、検索アクション、ツール呼び出しコスト、管理者によるブロック設定まで含めてテストしてください。
よくある失敗と回避策
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| Web検索されず、通常回答だけ返る | toolsにweb_searchを指定していない | リクエストにtools: [{"type": "web_search"}]を入れる |
| 引用が返らない | モデルがツールを呼び出していない | プロンプトでWeb検索と引用を明示する |
| 403やツールブロックのような挙動になる | サブスクリプションでweb_searchがブロックされている | 管理者にOpenAI.BlockedTools.web_search設定を確認してもらう |
| 認証エラーになる | APIキーまたはEntra IDトークンの設定不備 | APIキー、環境変数、https://ai.azure.com/.defaultスコープを確認する |
| 期待した国の情報が出ない | 場所指定をしていない | user_locationで国コードを指定する |
| 信頼できないページを参照する | 検索対象が広すぎる | allowed_domainsで公式サイトや信頼できるドメインに絞る |
| コストが増える | エージェント検索やDeep Researchで検索回数が増える | ユースケースごとに検索モードを分け、利用量を監視する |
公式ドキュメントのトラブルシューティングでも、引用が返らない場合はweb_searchツールの指定を確認すること、ツールがブロックされている場合はサブスクリプションの設定を確認すること、認証エラーではAPIキーやEntra IDのスコープを確認することが示されています。(Microsoft Learn)
本番展開での判断基準
Web search with the Responses APIは、最新情報を扱うAIアプリにとって有力な選択肢です。ただし、すべての用途で最初から有効化すべき機能ではありません。
導入しやすいのは、公開情報を扱い、引用元をユーザーに見せられる用途です。たとえば、Microsoft Learnの更新確認、公開ニュースの要約、製品仕様の比較、競合調査の下調べなどです。
一方で、次のような用途では慎重に設計してください。
- 顧客固有の情報を入力するサポート業務
- 未公開情報や社内文書を扱う業務
- データの地理的境界を厳密に管理する必要がある業務
- 回答に使う情報源を完全に固定したい業務
- 監査上、外部サービスへのデータ送信を避けたい業務
このような場合は、Web検索を使わず、社内データベースやAzure AI Searchを使ったRAG構成に限定するほうが適していることがあります。Web検索は「最新の公開情報を取りに行く機能」であり、「社内情報を安全に検索する機能」ではないと切り分けて考えるべきです。
次に取るべきアクション
Azure AI FoundryでResponses APIのWeb検索を使うなら、最初にやるべきことは3つです。
まず、既存コードやPoCでweb_search_previewやexternal_web_accessを使っていないか確認してください。次に、Azure管理者と相談し、サブスクリプション単位でweb_searchを許可するか、ブロックするかを決めます。最後に、開発チームはweb_search、引用表示、ドメイン制限、コスト監視を含めた小さな検証環境を作り、本番データを入れずに動作を確認するのが安全です。
Web検索は、生成AIアプリの回答を「それらしくする」ための機能ではありません。公開Webの情報をどの範囲で取得し、どの出典を根拠として表示し、どのデータを外に出さないかを設計する機能です。管理者設定、セキュリティ確認、開発実装を同時に進めることで、Azure AI FoundryのResponses APIを実務で使える形にできます。
コメント