第4回 OpenAIをMicrosoft Foundryで使う — Responses APIと2モデル構成の設計

連載：LLMのAPIと提供経路を選ぶ・第4回 ｜ 連載のまとめ

高速応答と複雑な処理の役割分担

Microsoft Foundry（以下、Foundry）のAzure OpenAIでチャットアプリを作る設計例として、GPT-5.5を調査や複数のツールを順に呼び出す処理の担当、GPT-5.4-miniを軽い応答や補助処理の担当に置きます。これは筆者が事前に行った調査を基にした設計提案です。

役割はchat-deepとchat-fastのようなアプリ設定で表し、実際のデプロイ名、モデルバージョン、パラメーターを対応付けます。どの程度の質問をGPT-5.5へ振り分けるかは、初めから割合を決めず、自社で実際に寄せられる質問を使って評価します。

チャットUIからアプリAPIを経由し、高速・推論用の2デプロイを呼ぶ構成。会話履歴と業務ツールはアプリ側で管理する。
筆者の事前調査を基にした構成図。図中のリクエスト比率は仮置きであり、実測値ではありません。モデルを切り替える際の推論状態の互換性は、別途確認が必要です。クリックでSVGを開けます。

Responses APIでの呼び出し例

Azure OpenAIでは、OpenAI公式のソフトウェア開発キット（以下、SDK）に/openai/v1/の接続先を設定し、デプロイ名で呼べます。推論の呼び出しだけなら、Foundryプロジェクトを操作するSDKの追加は必須ではありません。評価やエージェント管理などが必要になったとき、それらの機能を使うためのSDKを追加します。[1]

次は接続と1ターンの応答を示す最小例です。依存パッケージはopenaiとazure-identityです。環境変数に接続先とデプロイ名を設定し、利用権限を持つIDで認証します。本番ではマネージドIDを使い、ロールベースのアクセス制御（RBAC）で必要な権限を設定します。

import os
from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), "https://ai.azure.com/.default"
)
client = OpenAI(
    base_url=os.environ["AZURE_OPENAI_BASE_URL"],
    api_key=token_provider,
)
response = client.responses.create(
    model=os.environ["AZURE_OPENAI_DEEP_DEPLOYMENT"],
    input="社内FAQの回答を、提供された根拠に沿って作成してください。",
    reasoning={"effort": "medium"},
    max_output_tokens=8000,
    store=False,
)
if response.status != "completed":
    raise RuntimeError(f"回答未完了: {response.status}")
print(response.output_text)

出力上限の8,000は例示です。推論と回答本文に必要な量を実測して調整します。このコードは接続確認用であり、検索、ツールの呼び出しと結果の受け渡しを繰り返す処理、拒否判定、画面へのストリーミング表示は含みません。SDKの型と引数は採用バージョンで確認してください。この連載では、実APIでの動作検証は行っていません。

モデル更新時に変わるパラメーターと使用量

GPT-5.6系では、Chat Completionsで推論とツールを併用することに制約があります。またreasoning.contextの既定はGPT-5.5のcurrent_turnからGPT-5.6のall_turnsへ変わります。モデルを新しくするだけで、失敗する条件や複数ターンの会話で消費する量が変わる場合があります。[2]

対応可能なパラメーターはモデル別に管理します。「推論モデルならtemperatureを受け付けない」「最新モデルなら同じ値が使える」といった世代全体への一般化は避けます。新デプロイの評価では、品質だけでなくパラメーターの受理、使用量、終了状態も確認します。

会話履歴を引き継ぐ2つの方式

方式 メリット アプリが設計すること
previous_response_idで連結 前ターンの参照を簡単に書ける 保存条件、期限、復旧、削除、参照不能時の対応
自前の履歴を送信 保存と移行を自社で管理しやすい 全アイテムの再送、ツールIDの対応、暗号化推論の扱い

どちらの方式でも、利用者に見える発言と回答に加え、ツール呼び出しや推論アイテムをどう保存し、次のリクエストで渡すかが重要です。履歴をアプリ側から送るステートレス方式で推論を引き継ぐ場合は、対象APIの仕様に従って暗号化されたアイテムを保存・再送します。必要なAPIではinclude=["reasoning.encrypted_content"]も指定します。[1][3]

store=Falseを指定しただけで、ログや安全処理を含むすべてのデータが保持されないとは断定できません。応答状態を保存するかどうかの設定と、契約上のデータ保持条件を分けて確認します。

呼び出すモデルの選択と会話状態の引き継ぎ

社内FAQ、言い換え、タイトル生成は高速応答用のモデル、複数文書の比較や複数ツールを使う処理は複雑な処理用のモデルへ振り分ける、という初期ルールを置きます。呼び出すモデルを選ぶ処理をルーティングと呼びます。この判定自体に大規模言語モデル（LLM）を使うと、その呼び出しの費用と待ち時間も加わります。

モデルを切り替えるときは、利用者に見える会話履歴と確認済みの根拠を渡し、新しい会話として処理を開始する設計を基本にします。履歴が同じでも、内容を直接読めない推論状態を別モデルで同じように使える保証はありません。長い会話の圧縮結果も、異なるモデル・提供経路へ移す際は対応を確認します。

Foundryのmodel-routerを使う案もありますが、対象モデル、API、状態管理、パラメーターの制約をそれぞれ評価します。アプリでモデルを選ぶ判定が不要になっても、業務要件を満たしたかどうかの判定までルーターが代行するわけではありません。

APIの終了状態に応じたアプリの処理

状態 UIとバックエンドの扱い
完了 拒否や本文・根拠の検証後に回答を確定
出力上限などで未完了 未完了と表示し、続行・上限調整・新しい会話としての開始を検討
ツール呼び出し 許可と引数を検証して実行し、結果を対応するIDで返す
429・一時障害 上限付きの再試行、待ち時間の案内
拒否・コンテンツ制限 理由に応じて案内し、業務ルールに従って終了

高速応答用のモデルへ切り替えて処理を続けるフォールバックは、元の仕事を達成できる場合に限ります。詳しい分析の代わりに短い要約を返すなら、「簡略版」と明示し、完成した分析と同じ扱いにはしません。外部システムの操作が途中まで進んでいた場合は、再試行の前にどこまで完了しているかを確認します。

デプロイ名の固定とモデルバージョンの更新

デプロイ名を固定しても、自動更新ポリシーによって実際に使われるモデルは変わります。OnceCurrentVersionExpiredは退役時の更新であり、モデルを永久に固定する設定ではありません。NoAutoUpgradeでは退役時に停止する場合があります。[4]

本番で使う前に、新バージョンを別のデプロイで評価し、段階的に切り替える方針を提案します。旧デプロイは進行中の会話と業務処理が終わるまで保持し、退役期限より前に移行を終えます。更新ポリシーの適用条件は、Standard系とProvisionedなどで個別に確認します。

Azureへ配置する場合の構成例

ここまでの設計をAzureへ配置する例として、WebアプリとアプリAPIをAzure App Serviceで動かし、1つのAzure OpenAIリソースに2つのモデルをデプロイする構成を示します。会話履歴はAzure Cosmos DB for NoSQLに保存し、社内検索が必要な場合はアプリAPIからAzure AI Searchや既存の検索APIを呼び出します。これは筆者の構成例です。App ServiceからAzure OpenAIへマネージドIDで接続する方式は、公式の構築例でも説明されています。[5]

配置するリソース

リソース 名前・設定の例 この構成での役割
リソースグループ rg-chat-prod 同じ環境のリソースをまとめる
App Serviceプラン asp-chat-prod Webアプリを動かすための実行基盤
App ServiceのWebアプリ app-chat-prod-<suffix> チャット画面、モデルの振り分け、ツール実行、終了判定を実装したアプリを配置
Azure OpenAIリソース aoai-chat-prod-<suffix> アプリからモデルを呼ぶ接続先
高速応答用デプロイ chat-fast：GPT-5.4-mini FAQ、言い換え、タイトル生成などを担当
複雑な処理用デプロイ chat-deep：GPT-5.5 調査、比較、複数ツールを使う処理を担当
Azure Cosmos DB for NoSQL データベースchat、コンテナーconversations 会話履歴、推論・ツールのアイテム、確認済みの根拠をアプリから保存・取得
社内検索の接続先（任意） Azure AI Search、または既存の検索API アプリの関数ツールから検索し、結果をモデルへ返す

名前は例示で、<suffix>は実際に使える一意な文字列に置き換えます。モデルのバージョン、デプロイ種別、容量はデプロイごとに記録します。リージョンは、Responses APIと両モデルの対象バージョン・デプロイ種別が利用でき、保存・処理地域の要件を満たす場所を選びます。この例のように1リソースへまとめられるかも、配置前に確認します。[1]

アプリに渡す接続設定

App Serviceのアプリ設定には、次の値を渡します。AZURE_OPENAI_BASE_URLの<resource-name>は、実際に作成したAzure OpenAIリソースの名前へ置き換えます。接続先の/openai/v1/と、modelに渡すデプロイ名を対応づける点は、前段のPython例と同じです。[1]

AZURE_OPENAI_BASE_URL=https://<resource-name>.openai.azure.com/openai/v1/
AZURE_OPENAI_FAST_DEPLOYMENT=chat-fast
AZURE_OPENAI_DEEP_DEPLOYMENT=chat-deep

前段の最小コードが使うのは、接続先とAZURE_OPENAI_DEEP_DEPLOYMENTです。高速応答用の設定を使って呼び分ける処理は、アプリ側に実装します。Cosmos DBの接続先、データベース名、コンテナー名もアプリの設定として渡しますが、設定値を置くだけで会話履歴が自動保存されるわけではありません。保存・取得、利用者ごとのアクセス制御、保持期限と削除もアプリで実装します。

認証と配置後の確認

App Serviceのシステム割り当てマネージドIDを有効にし、そのIDにAzure OpenAIリソースを対象としてCognitive Services OpenAI Userを割り当てます。アプリは前段と同じDefaultAzureCredentialを使って接続し、この構成ではAzure OpenAIのAPIキーをアプリ設定へ置きません。利用者のサインインと、アプリからAzureサービスへ接続するための認証は、分けて設定します。[5][6]

Cosmos DBには、同じマネージドIDにデータ読み書き用のCosmos DB Built-in Data Contributorを、対象コンテナーなど必要な範囲で割り当てます。これはAzureリソースを作成・管理する権限とは別の、データへアクセスするためのロールです。社内検索を追加する場合も、検索先に応じた接続設定と権限を用意します。[7]

配置後は、次の順でアプリの動作を確認します。

  1. chat-fastとchat-deepをそれぞれ単独で呼び、接続先・権限・パラメーター・終了状態を確認する。
  2. 同じモデルで複数ターンの会話を行い、必要な履歴と推論・ツールのアイテムを保存・再送できるかを確認する。
  3. モデルを切り替える質問を使い、会話履歴と根拠の引き継ぎ、ツール結果の対応、回答の完成判定を確認する。
  4. 出力上限、429、外部ツールの失敗を発生させたテストで、未完了表示や再試行、重複実行の防止を確認する。

この構成を使う場合も、前段の接続確認コードに、Webアプリとしての処理や履歴管理を追加して配置します。Azure上にリソースを作ることと、会話・業務処理を正しく実装することの両方を確認します。

前回： 第3回 直接APIかMicrosoft Foundryか — 機能差と運用統一の価値を比較する

参考資料

参考資料の仕様確認日：2026年10月8日。配置例の接続設定・マネージドID・アクセス権限に関する資料は2026年10月23日に追加確認しました。構成・ルーティング・上限値は筆者の設計例です。

  1. Azure OpenAI Responses API（Microsoft Learn）
  2. Azure OpenAI reasoning models（Microsoft Learn）
  3. 直接APIの会話管理（OpenAI）
  4. Working with models（Microsoft Learn）
  5. Build and deploy an Azure OpenAI (Express.js) chatbot（Microsoft Learn）：App Serviceへの配置とマネージドIDによるAzure OpenAIへの接続。資料のアプリはNode.jsによる例で、本記事のPythonコードをそのまま配置する手順ではありません。
  6. Use Azure OpenAI without keys（Microsoft Learn）：Azure Identityによるキーレス接続とCognitive Services OpenAI Userの割り当て。
  7. Connect using role-based access control and Microsoft Entra ID（Microsoft Learn）：Cosmos DBのデータプレーンのロール、マネージドID、アクセス範囲。

You should also read: