Simulate Azure OpenAI API – Dev Proxy は、Azure OpenAI API を使うアプリの開発・テスト時に、本物の Azure OpenAI へ接続せず、ローカルの言語モデルで応答を模擬するための仕組みです。結論から言うと、今回確認すべきポイントは「本番環境の Azure OpenAI 設定変更」ではなく、開発環境での API 応答シミュレーションを安全に使うための設定確認です。2026年7月1日に更新された Microsoft Learn の手順では、Dev Proxy の OpenAIMockResponsePlugin、urlsToWatch、languageModel 設定を使って Azure OpenAI API の応答をローカルで再現する流れが整理されています。(Microsoft Learn)
Azure の新機能・変更点：「Simulate Azure OpenAI API – Dev Proxy」で確認すべきポイント
Azure OpenAI を組み込んだアプリでは、画面表示、入力チェック、ワークフロー、エラーハンドリングなど、必ずしも毎回本物の Azure OpenAI 応答を必要としないテストが多くあります。
今回の「Simulate Azure OpenAI API – Dev Proxy」は、そうした開発・検証フェーズで、Dev Proxy が Azure OpenAI API へのリクエストを捕捉し、ローカル LLM からの応答を返す構成です。Microsoft の公式手順では、目的は「ローカル LLM を使って Azure OpenAI をシミュレートすること」、利用プラグインは OpenAIMockResponsePlugin、前提条件は Dev Proxy とローカル言語モデルとされています。(Microsoft Learn)
この更新は、Azure OpenAI Service 自体の廃止や料金体系変更を示すものではありません。管理者や開発リーダーが見るべきなのは、主に次の4点です。
| 確認項目 | 実務上の意味 |
|---|---|
| 影響範囲 | 開発者PC、検証環境、ローカルテストに影響。本番 Azure OpenAI リソースの変更ではない |
| 設定変更 | devproxyrc.json でプラグイン、監視URL、ローカル言語モデルを有効化する |
| 移行期限 | 公式手順上、移行期限や廃止期限は示されていない |
| 管理者の確認点 | 証明書、プロキシ設定、ローカルLLM、APIパス、テスト結果の扱いを確認する |
Simulate Azure OpenAI API – Dev Proxy とは
Dev Proxy は、クラウド API の挙動やエラーをシミュレートし、アプリをより堅牢に作るためのコマンドラインツールです。初回起動時には、ローカル HTTPS 通信を復号して確認・変更できるように Dev Proxy 用の証明書を信頼する手順があります。Microsoft の説明では、この証明書はローカルに保存され、データを Microsoft にアップロードするものではないとされています。(Microsoft Learn)
Azure OpenAI API のシミュレーションでは、Dev Proxy が指定された Azure OpenAI API の URL を監視し、対象リクエストを OpenAIMockResponsePlugin で処理します。このプラグインは、Azure OpenAI または OpenAI への接続を実際に行わず、ローカル言語モデルを使って応答を生成します。(Microsoft Learn)
つまり、狙いは次のように整理できます。
| 観点 | 本物の Azure OpenAI API | Dev Proxy によるシミュレーション |
|---|---|---|
| 応答生成 | Azure OpenAI Service 上のモデル | ローカルの言語モデル |
| コスト | Azure OpenAI の利用量に応じて発生 | Azure OpenAI への不要な呼び出しを減らせる |
| 主な用途 | 本番処理、精度検証、最終確認 | 開発中の画面確認、ワークフロー確認、コスト削減 |
| 注意点 | 認証、ネットワーク、モデル選定が必要 | 本番モデルと同じ品質・応答傾向とは限らない |
特に重要なのは、Dev Proxy の応答を本番品質の最終判断に使わないことです。公式リファレンスでも、プラグインが生成する応答の正確性は使用するローカル言語モデルに依存するため、本番展開前には本番で使う予定の言語モデルでテストする必要があると説明されています。(Microsoft Learn)
影響範囲：本番システムよりも開発・検証プロセスに影響する
Simulate Azure OpenAI API – Dev Proxy の影響範囲は、主に Azure OpenAI を使うアプリの開発チームです。Azure 管理者、アプリ開発者、テスト担当者、セキュリティ担当者で見るべきポイントが少し異なります。
| 対象者 | 確認すべきこと |
|---|---|
| Azure 管理者 | Azure OpenAI リソースの変更ではなく、開発端末側の Dev Proxy 利用であることを理解する |
| 開発者 | devproxyrc.json、監視URL、ローカルLLMの起動順序を確認する |
| テスト担当者 | シミュレーション結果と本番モデル検証を分けて扱う |
| セキュリティ担当者 | ローカル証明書、プロキシ利用、入力データの扱いを確認する |
| 開発リーダー | コスト削減目的のテストと、品質保証目的のテストを混同しないようにする |
実務では、「Azure OpenAI の呼び出しをすべて Dev Proxy に置き換える」という考え方ではなく、本物の応答が不要なテストを Dev Proxy に寄せるのが適切です。
例えば、次のような場面では Dev Proxy が役立ちます。
| 活用シーン | 使い方の例 |
|---|---|
| UI 開発 | チャット画面や要約画面の表示崩れを確認する |
| ワークフロー確認 | 入力、送信、応答表示、履歴保存までの流れを確認する |
| コスト削減 | 頻繁な手動テストで Azure OpenAI を毎回呼ばない |
| 障害時の確認 | API が想定通りに返らない場合の画面挙動を確認する |
| 開発者教育 | Azure OpenAI 連携アプリの流れをローカルで体験する |
一方で、回答品質、ハルシネーション対策、プロンプトの最終評価、業務利用時の精度検証には、本番で使う Azure OpenAI モデルを使った確認が必要です。
設定変更：devproxyrc.json で3つの要素を有効化する
公式手順で中心になるのは、devproxyrc.json の設定です。大きく分けると、次の3つを設定します。
| 設定 | 役割 |
|---|---|
OpenAIMockResponsePlugin | Azure OpenAI / OpenAI の応答をローカルLLMで模擬する |
urlsToWatch | Dev Proxy が捕捉する Azure OpenAI API のURLを指定する |
languageModel | ローカル言語モデルの利用を有効化する |
公式手順では、次のような構成例が示されています。(Microsoft Learn)
{
"$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.1.0/rc.schema.json",
"plugins": [
{
"name": "OpenAIMockResponsePlugin",
"enabled": true,
"pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll"
}
],
"urlsToWatch": [
"https://*.openai.azure.com/openai/deployments/*/completions*"
],
"languageModel": {
"enabled": true
}
}この設定で特に注意すべきなのは、urlsToWatch です。アプリが実際に呼び出している Azure OpenAI API のパスと一致しない場合、Dev Proxy はリクエストを捕捉できません。
Azure OpenAI SDK や API バージョン、利用しているエンドポイントによってパスが異なる場合があります。開発者は、ブラウザの開発者ツール、アプリのログ、HTTP クライアントの設定などで実際の通信先を確認し、必要に応じて urlsToWatch を調整してください。
ローカル言語モデルの設定：既定では llama3.2 と Ollama が想定されている
Dev Proxy は、ローカル言語モデルと連携して応答を生成します。Microsoft Learn では、既定では Ollama 上で動作する llama3.2 モデルを使う構成が説明されています。別のクライアントやモデルを使う場合は、Dev Proxy の languageModel 設定を変更します。(Microsoft Learn)
languageModel では、次のような設定項目が用意されています。
| 項目 | 内容 | 既定値 |
|---|---|---|
enabled | ローカル言語モデルを使うかどうか | false |
model | 使用するモデル名 | llama3.2 |
url | ローカル言語モデルクライアントのURL | http://localhost:11434/v1/ |
client | 利用するクライアント種別 | OpenAI |
cacheResponses | 同じプロンプトへの応答をキャッシュするか | true |
ローカル言語モデルを使う場合は、Dev Proxy を起動する前にローカル言語モデルクライアントを起動しておく必要があります。公式手順では、既定構成を前提に ollama run llama3.2 を実行してから Dev Proxy を起動する流れが示されています。(Microsoft Learn)
ollama run llama3.2その後、Dev Proxy を起動します。プリセットを使う場合は、公式手順にある simulate-azure-openai プリセットを取得して利用できます。(Microsoft Learn)
devproxy config get simulate-azure-openai
devproxy -c "~appFolder/config/simulate-azure-openai/simulate-azure-openai.json"独自の devproxyrc.json をカレントディレクトリに置く場合は、通常どおり次のコマンドで起動できます。
devproxy対応エンドポイント：使っている API パスを必ず確認する
OpenAIMockResponsePlugin の技術リファレンスでは、サポートする OpenAI API エンドポイントとして Chat Completions と Responses API が示されており、その他の OpenAI API エンドポイントはサポートしないと説明されています。(Microsoft Learn)
ここで注意したいのは、Azure OpenAI の利用形態です。Azure OpenAI では、デプロイ名や API バージョンを含む Azure 固有のURL形式を使うことがあります。公式の Simulate Azure OpenAI API 手順では、https://*.openai.azure.com/openai/deployments/*/completions* という監視URL例が使われています。(Microsoft Learn)
そのため、管理者や開発者は次の順番で確認すると安全です。
| 手順 | 確認内容 |
|---|---|
| 1 | アプリが実際に呼び出している Azure OpenAI API のURLを確認する |
| 2 | urlsToWatch のワイルドカードがそのURLに一致しているか確認する |
| 3 | 対象APIが OpenAIMockResponsePlugin の対応範囲に入るか確認する |
| 4 | Dev Proxy 起動後、ログに対象リクエストが表示されるか確認する |
| 5 | 本番前に Azure OpenAI の実モデルでも再テストする |
よくある失敗は、urlsToWatch を設定したつもりでも、実際のアプリが chat/completions や別の API パスを呼んでいて捕捉されないケースです。Dev Proxy のログに対象リクエストが出ていない場合は、まず監視URLの不一致を疑うのが近道です。
移行期限：公式情報上、期限対応として読む変更ではない
2026年7月1日更新の公式ページでは、Simulate Azure OpenAI API – Dev Proxy について、移行期限、強制適用日、既存 Azure OpenAI リソースの廃止期限といった情報は示されていません。確認できる範囲では、これは「期限までに移行しなければならない変更」ではなく、開発・テストの選択肢として整理された手順です。(Microsoft Learn)
ただし、組織内で Dev Proxy を標準化する場合は、期限がないから後回しでよいという話ではありません。Azure OpenAI の利用が増えているチームでは、開発中の不要な API 呼び出しがコストやレート制限、検証待ち時間につながります。
次のような状況があるなら、早めに検証する価値があります。
| 状況 | Dev Proxy 導入を検討すべき理由 |
|---|---|
| 開発者が頻繁に Azure OpenAI を呼び出している | 開発中の不要な API コストを減らせる |
| UI テストで毎回AI応答を待っている | 表示確認や画面遷移確認を速くできる |
| APIキーを開発者PCに広く配布したくない | ローカルシミュレーションで一部テストを代替できる |
| プロンプト修正とアプリ修正が混在している | アプリ側の挙動確認とモデル品質評価を分離できる |
管理者が確認すべきポイント
Dev Proxy は便利ですが、ローカル端末のネットワーク通信に関わるため、管理者は利用ルールを決めておくべきです。特に、証明書、プロキシ、ローカルLLM、ログの扱いは事前に確認しておくとトラブルを減らせます。
| 確認項目 | 判断基準 | 失敗しやすいポイント |
|---|---|---|
| 利用範囲 | 開発・検証端末に限定する | 本番相当の検証結果として扱ってしまう |
| 証明書 | Dev Proxy CA を信頼する手順を理解する | 証明書未信頼でHTTPS通信を捕捉できない |
| ローカルLLM | 使用モデル、起動手順、必要スペックを決める | Ollama やモデルを起動せず Dev Proxy だけ起動する |
| APIパス | 実際の Azure OpenAI URL と urlsToWatch を合わせる | ワイルドカードが広すぎる、または狭すぎる |
| キャッシュ | cacheResponses の影響を理解する | 同じ応答が返り、変更確認を誤る |
| テスト方針 | シミュレーションと本番モデル検証を分ける | ローカルLLMの結果を本番品質と誤解する |
| データ管理 | 個人情報や機密情報を入力しないルールを作る | 開発ログやプロンプトに機密データが残る |
Microsoft の手順では、Dev Proxy はローカル HTTPS 通信を確認・変更するためにローカル証明書を使います。これは Dev Proxy の仕組み上必要な操作ですが、企業端末ではセキュリティポリシーに関わる場合があります。組織で使う場合は、開発者が個別判断で証明書を追加するのではなく、利用手順を明文化しておくのが安全です。(Microsoft Learn)
導入手順：まずは小さな検証アプリで試す
いきなり全チームに展開するより、Azure OpenAI を呼び出す小さなサンプルアプリや検証用ブランチで試すのがおすすめです。
Dev Proxy をインストールする
Windows では、公式手順で winget によるインストールが紹介されています。インストール後は PATH を反映するためにコマンドプロンプトの再起動が必要です。(Microsoft Learn)
winget install DevProxy.DevProxy --silentmacOS では Homebrew を使う方法が紹介されています。(Microsoft Learn)
brew tap dotnet/dev-proxy
brew install dev-proxyLinux ではセットアップスクリプトを使う方法が紹介されています。(Microsoft Learn)
bash -c "$(curl -sL https://aka.ms/devproxy/setup.sh)"初回起動で証明書とプロキシ動作を確認する
初回起動時は、Dev Proxy が通信を捕捉できるように証明書の信頼やファイアウォール許可が必要になる場合があります。起動後、Dev Proxy は既定では 127.0.0.1:8000 で待ち受ける動作例が示されています。(Microsoft Learn)
devproxy確認時は、Dev Proxy のログにリクエストが表示されるかを見ます。何も表示されない場合、アプリの通信が Dev Proxy を通っていない、または urlsToWatch が一致していない可能性があります。
Azure OpenAI API の監視設定を追加する
検証用の devproxyrc.json に、OpenAIMockResponsePlugin、Azure OpenAI API の urlsToWatch、languageModel を追加します。
{
"$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.1.0/rc.schema.json",
"plugins": [
{
"name": "OpenAIMockResponsePlugin",
"enabled": true,
"pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll"
}
],
"urlsToWatch": [
"https://*.openai.azure.com/openai/deployments/*/completions*"
],
"languageModel": {
"enabled": true
}
}ローカルLLMを起動してから Dev Proxy を起動する
ローカル言語モデルを使う場合は、Dev Proxy より先にローカルLLMクライアントを起動します。公式手順では、既定構成として Ollama の llama3.2 を起動する例が示されています。(Microsoft Learn)
ollama run llama3.2
devproxyその後、アプリを通常どおり操作し、Azure OpenAI API へのリクエストが Dev Proxy に捕捉されるかを確認します。
実務での使い分け：Dev Proxy で置き換えてよいテスト、置き換えないテスト
Simulate Azure OpenAI API – Dev Proxy は、すべての Azure OpenAI テストを置き換えるものではありません。使い分けを誤ると、開発効率は上がっても品質保証が弱くなります。
| テスト内容 | Dev Proxy で代替しやすいか | 理由 |
|---|---|---|
| 画面レイアウト確認 | 高い | 応答内容が厳密でなくても確認しやすい |
| 入力から応答表示までの流れ | 高い | アプリ側の制御を確認しやすい |
| APIキーや認証の疎通確認 | 低い | 実際の Azure OpenAI 接続確認が必要 |
| プロンプト品質評価 | 低い | 本番モデルの応答傾向で評価すべき |
| 業務回答の正確性確認 | 低い | ローカルモデルの回答は本番品質を保証しない |
| コスト削減目的の手動テスト | 高い | 不要な Azure OpenAI 呼び出しを減らせる |
| 障害時のUI確認 | 中〜高 | 失敗時の画面表示や再試行処理を確認しやすい |
おすすめは、テストを次の2層に分けることです。
| 層 | 目的 | 使うもの |
|---|---|---|
| 開発中の高速確認 | UI、フロー、例外処理、表示確認 | Dev Proxy + ローカルLLM |
| リリース前の品質確認 | 回答品質、業務精度、認証、実API疎通 | Azure OpenAI 本番相当環境 |
この分離ができると、開発中は素早く確認し、リリース前には必要なところだけ本物の Azure OpenAI で検証できます。
よくあるトラブルと対処法
Dev Proxy が Azure OpenAI API を捕捉しない
最初に見るべきなのは urlsToWatch です。設定例のURLパターンと、実際のアプリが呼んでいるURLが一致しているか確認してください。
特に、SDK経由で呼んでいる場合は、コード上で見えている設定値と実際のHTTPリクエストのパスが異なることがあります。Dev Proxy のログ、アプリログ、HTTPトレースを使って実URLを確認するのが確実です。
Dev Proxy 起動時にローカルLLMへ接続できない
ローカルLLMクライアントを先に起動しているか確認します。公式手順でも、ローカル言語モデルを使う場合は Dev Proxy 起動前にローカル言語モデルクライアントを開始するよう説明されています。(Microsoft Learn)
既定構成に近い形で確認するなら、まず次の順番で試します。
ollama run llama3.2
devproxy別のモデルや別のローカルLLMホストを使う場合は、languageModel.model、languageModel.url、languageModel.client を見直してください。
応答が思ったより遅い、または同じ応答が返る
ローカルLLMの速度は、端末のCPU、GPU、メモリ、モデルサイズに左右されます。また、Dev Proxy の languageModel 設定には cacheResponses があり、既定では同じプロンプトへの応答をキャッシュする設定です。(Microsoft Learn)
プロンプト修正の影響を細かく見たい場合は、キャッシュの影響を受けていないか確認してください。
ローカルでは動くが本番で期待どおりに動かない
Dev Proxy の応答はローカルLLMに依存します。本番の Azure OpenAI モデルとは、出力形式、応答傾向、厳密性、ツール呼び出しの挙動が異なる可能性があります。
そのため、Dev Proxy で確認した後も、少なくとも次の項目は本番相当環境で再確認してください。
| 本番前に確認すべき項目 | 理由 |
|---|---|
| 認証・認可 | Dev Proxy では本物の Azure OpenAI 認証を完全には検証できない |
| API バージョン | 実際の Azure OpenAI API 仕様に依存する |
| 応答品質 | ローカルLLMと本番モデルの出力は異なる |
| エラー処理 | 実APIのレート制限、認証エラー、タイムアウトを確認する必要がある |
| 監査・ログ | 本番運用時の記録要件を満たす必要がある |
企業利用でのおすすめ運用ルール
組織で Simulate Azure OpenAI API – Dev Proxy を使うなら、単に「便利だから各自で使う」ではなく、軽いルールを作ると安全です。
| ルール | 内容 |
|---|---|
| 用途を限定する | 開発・検証・教育用途に限定し、本番判定には使わない |
| 設定ファイルを共有する | チーム標準の devproxyrc.json をリポジトリや社内ドキュメントで管理する |
| APIパスを明記する | 対象の Azure OpenAI API パスと urlsToWatch の関係を説明する |
| 機密データを入れない | 本番データや個人情報をローカルテストに流さない |
| 本番検証を残す | リリース前チェックリストに Azure OpenAI 実APIでの確認を入れる |
| 証明書手順を統一する | Dev Proxy CA の扱いをセキュリティポリシーに合わせる |
特に、開発者が Azure OpenAI の API キーやエンドポイントを個人PCで扱う場合、Dev Proxy 以前に資格情報管理のルールが重要です。環境変数、シークレット管理、ローカル設定ファイルの .gitignore など、基本的な対策も合わせて確認してください。
まとめ：まずは開発環境のコスト削減とテスト効率化から始める
Simulate Azure OpenAI API – Dev Proxy は、Azure OpenAI API を使うアプリの開発効率を上げるための実用的な手段です。2026年7月1日更新の公式手順で確認すべきポイントは、OpenAIMockResponsePlugin を有効化し、Azure OpenAI API の監視URLを設定し、ローカル言語モデルを使って応答を模擬することです。(Microsoft Learn)
一方で、これは本番モデルの品質検証や Azure OpenAI Service の疎通確認を置き換えるものではありません。管理者は、開発・検証用の仕組みとして位置づけ、証明書、プロキシ、ローカルLLM、APIパス、テスト方針を確認してから導入するのが安全です。
次に取るべき行動はシンプルです。まず、Azure OpenAI を呼び出している開発中のアプリを1つ選び、検証用の devproxyrc.json を作成します。そのうえで、ローカルLLMを起動し、Dev Proxy のログに Azure OpenAI API リクエストが捕捉されるかを確認してください。そこで問題なく動くことを確認できたら、チーム標準の開発手順として展開する価値があります。
コメント