Azure DatabricksでOpenAI GPT-5.6がGAに｜利用条件・データ境界・管理策を解説

2026年7月10日時点で、Microsoft Azureは「OpenAI GPT-5.6 on Azure Databricks」を一般提供として案内しています。今回の更新により、Microsoft Foundryで利用するGPT-5.6を、Azure DatabricksのModel Serving Endpointから外部モデルとして呼び出せるようになりました。

結論として、Azure Databricksをデータ分析やAI開発の共通基盤にしている組織では、GPT-5.6の認証情報、利用権限、利用量、ログ、レート制限をDatabricks側に集約しやすくなります。一方で、GPT-5.6がDatabricksワークスペース内で動作するわけではありません。Microsoft Foundry側のモデルデプロイ、クォータ、リージョン、ネットワーク経路、データ処理地域を事前に確認する必要があります。

既存システムに対する強制的な移行や設定変更はありません。Azure Databricks上で生成AIを本番運用したい組織が、新たなモデル候補として評価すべき更新です。(Microsoft Azure)

Azure DatabricksでGPT-5.6がGAになり何が変わるのか

今回の更新で重要なのは、GPT-5.6そのものだけではありません。Azure Databricksを生成AIへの統制された入口として利用できる点が実務上の変化です。

Azure DatabricksのExternal Modelsは、Databricks外部でホストされるモデルをModel Serving Endpoint経由で利用する仕組みです。アプリケーションやノートブックは、モデル提供元を直接呼び出す代わりに、Databricksの共通エンドポイントへリクエストを送信できます。

観点	今回の更新内容
利用するモデル	Microsoft Foundryで提供されるOpenAI GPT-5.6
呼び出し口	Azure Databricks Model Serving Endpoint
モデルの配置先	Microsoft Foundry側。Databricks内でモデルが実行されるわけではない
API	OpenAI互換APIとして統一して呼び出し可能
認証情報	Databricks側で集中管理可能
主な管理機能	アクセス制御、レート制限、利用量追跡、ペイロードログ、フォールバックなど

External Modelsでは、モデル提供元のAPIキーなどを一元的に保存できるため、利用者やアプリケーションごとに資格情報を配布する必要がありません。また、複数のモデル提供元を共通のOpenAI互換APIで扱えるため、モデル変更時のアプリケーション改修も抑えやすくなります。(Microsoft Learn)

GPT-5.6は3つのモデルIDで提供される

Microsoft Foundryの公式モデルカタログには、次のGPT-5.6モデルが掲載されています。

gpt-5.6-sol
gpt-5.6-terra
gpt-5.6-luna

3モデルとも、Responses API、Chat Completions API、構造化出力、テキスト・画像入力、関数呼び出し、ツール呼び出しなどに対応しています。公式カタログ上のコンテキストウィンドウは最大105万トークン、最大出力は12万8,000トークンです。

ただし、モデル名だけで業務への適合性を判断してはいけません。精度、応答速度、料金、ツール選択の正確性を、実際のデータとプロンプトで比較する必要があります。また、サブスクリプションのクォータ階層によっては、GPT-5.6のデプロイ前にクォータ申請が必要です。(Microsoft Learn)

「一般提供」の範囲を正しく理解する

Azure Updatesの「Launched」は、機能が正式リリースされ、本番利用を想定した状態であることを示します。ただし、今回の一般提供は、関連するすべての管理機能やSDKが同時にGAになったことを意味しません。(Microsoft Azure)

機能・経路	2026年7月時点の扱い	実務上の注意
GPT-5.6をAzure Databricksから利用する経路	一般提供	本番候補として評価可能
MLflow Deployments CRUD APIの掲載例	Public Preview	SDK依存部分の変更可能性を考慮する
AI Guardrails	Public Preview	補助的な防御として利用し、単独で安全性を保証しない
Unity CatalogのModel Provider Services	Beta	複数ワークスペースの集中管理に有効だが、導入前に制約を確認する

初期検証ではAzure DatabricksのUIまたは正式なREST APIを利用し、プレビュー中のSDKや機能への依存を必要最小限に抑えると、将来の仕様変更に対応しやすくなります。(Microsoft Learn)

GPT-5.6をAzure Databricksで利用するための条件

「GAになったため、すべてのワークスペースですぐ利用できる」とは限りません。少なくとも次の条件を確認する必要があります。

確認項目	必要な状態	見落としやすいポイント
Microsoft Foundry	GPT-5.6を利用可能なリソースとデプロイがある	モデル名だけでなく、デプロイ名が必要
モデルのリージョン	選択したGPT-5.6とデプロイ方式が対象リージョンで提供されている	モデルの提供地域はワークスペースの地域と別に確認する
クォータ	必要なトークン量やスループットが割り当てられている	一部のクォータ階層では事前申請が必要
Azure Databricks	External Modelsに対応したワークスペースである	リージョンごとの提供状況を確認する
接続設定	APIベースURL、APIバージョン、デプロイ名を用意できる	モデルIDとデプロイ名を混同しない
認証	APIキーまたはMicrosoft Entra IDのサービスプリンシパルを使用できる	ノートブックへの平文埋め込みは避ける
権限	Model Serving Endpointの作成・管理権限がある	一般利用者にはクエリ権限だけを付与する
ネットワーク	DatabricksからFoundry側エンドポイントへ通信できる	Private Linkの利用可否を事前に確認する

Azure OpenAI統合では、APIキー認証に加えて、Microsoft Entra IDのテナントID、クライアントID、クライアントシークレットを利用した認証にも対応しています。エンドポイントには、Foundry側のベースURL、APIバージョン、デプロイ名などを設定します。(Microsoft Learn)

認証情報はDatabricks Secretsなどから参照し、設定ファイルやノートブックへ平文で記述しないことが基本です。Databricksはエンドポイントに設定された資格情報を暗号化して保存し、該当エンドポイントの削除時に資格情報も削除します。(Microsoft Learn)

データ境界はDatabricksだけでは完結しない

今回の構成では、データの流れを次のように理解する必要があります。

利用者・業務アプリ・Databricks Job
            ↓
Azure Databricks Model Serving Endpoint
            ↓
Microsoft Foundry上のGPT-5.6デプロイ
            ↓
応答がModel Serving Endpoint経由で返却

External Modelsは、Databricksの外部でホストされているモデルを利用する仕組みです。そのため、プロンプト、検索結果、画像などの入力データは、DatabricksからMicrosoft Foundry側へ送信されます。

「Databricksのエンドポイントを使っているから、データがDatabricks内だけに残る」と判断してはいけません。

Foundry側ではOpenAIのサービスへデータが渡されるわけではない

Microsoft Foundryで「Models sold by Azure」として提供されるモデルは、MicrosoftのAzure環境でホストされます。Microsoftの公式説明では、プロンプトや応答はOpenAIなどのモデル提供元には提供されず、利用者の許可や指示なしに基盤モデルの学習へ使われないとされています。(Microsoft Learn)

ただし、次の2つは同じ意味ではありません。

モデル学習に利用されない
データが一切保存・処理されない

通常の推論モデル自体はステートレスですが、Responses APIなどのステートフル機能では、設定に応じてメッセージ履歴などが保存される場合があります。また、不正利用の検知では、条件に該当したプロンプトや応答が確認対象になる可能性があります。(Microsoft Learn)

処理地域はFoundryのデプロイ方式で変わる

データ処理地域は、Foundryで選択するデプロイ方式によって異なります。

デプロイ方式	プロンプトと応答の主な処理範囲
Standardなどの地域指定型	原則として顧客が指定した地理的範囲内
Global	対象モデルが展開されている複数の地理的範囲で処理される可能性がある
DataZone	指定したデータゾーン内の複数リージョンで処理される可能性がある

個人情報、医療情報、機密設計情報などを扱う場合は、Azure Databricksのリージョンだけでなく、Foundryリソースの場所、モデルのデプロイ方式、保存データの場所を一組として確認しなければなりません。(Microsoft Learn)

Private Linkを前提とする環境は特に注意する

Model Serving Endpointへの入口では、ワークスペースに設定されたIPアクセスリストやPrivate Linkなどのネットワーク制御が適用されます。

一方、Model ServingからAzure OpenAIなどの外部エンドポイントに接続する経路では、Private Linkが標準で利用できるとは限りません。Microsoftの資料では、外部エンドポイントへのPrivate Link対応はリージョン単位で評価・提供されると説明されています。

「利用者からDatabricksまでが閉域である」ことと、「DatabricksからFoundryまでが閉域である」ことは別です。閉域接続が必須の組織は、PoCを始める前にAzure Databricks担当者へ対象リージョンの対応状況を確認する必要があります。(Microsoft Learn)

管理者が設定すべき統制

GPT-5.6を本番利用する場合、モデルの精度評価より前に、誰がどの経路で利用できるかを決める必要があります。

エンドポイント作成権限を一般利用者に渡さない

Model Serving Endpointを作成した利用者には、初期状態でCAN MANAGE権限が付与されます。管理権限を持つ利用者は、エンドポイントの設定やAI Gatewayの制御を変更できるため、エンドポイント作成とCAN MANAGEはAI基盤管理者に限定するのが安全です。

一般利用者、アプリケーション、サービスプリンシパルには、承認済みエンドポイントへのクエリ権限だけを付与します。これにより、利用者が独自エンドポイントを作り、レート制限やガードレールを回避する事態を防ぎやすくなります。(Microsoft Learn)

推奨する管理設定

管理項目	推奨設定
エンドポイント管理	プラットフォーム管理者だけに`CAN MANAGE`を付与
認証	Microsoft Entra IDのサービスプリンシパルを優先
資格情報	Databricks Secretsまたは集中管理された接続情報を利用
利用権限	業務アプリ・利用グループ単位で最小権限を付与
レート制限	エンドポイント全体とユーザー・サービスプリンシパル単位の両方を設定
利用量追跡	本番環境では有効化し、トークン数と費用を継続監視
ペイロードログ	データ分類、保持期間、閲覧権限を決めてから有効化
ガードレール	Foundry側の安全機能と組み合わせて多層化
障害対策	タイムアウト、再試行、フォールバック先を設定

レート制限は「全体」と「利用者別」を併用する

Unity AI Gatewayでは、次の単位でQPMまたはTPMの制限を設定できます。

エンドポイント全体
ユーザーのデフォルト値
個別ユーザー
サービスプリンシパル
ユーザーグループ

例えば、社内チャットには1ユーザー当たりの上限を設定し、夜間バッチには専用サービスプリンシパルの上限を設定します。さらにエンドポイント全体の上限を設ければ、設定ミスや無限ループによる想定外の大量利用を抑えられます。初期状態ではレート制限が設定されていないため、本番公開前の明示的な設定が必要です。(Microsoft Learn)

ペイロードログは便利だが、無条件で有効化しない

Payload Loggingを有効にすると、モデルへ送ったリクエストと応答をUnity Catalog管理下のDeltaテーブルへ記録できます。障害調査、品質評価、監査には有効ですが、プロンプトに含まれる個人情報や機密情報も保存される可能性があります。

有効化する前に、少なくとも次の項目を決めます。

ログを保存するカタログとスキーマ
閲覧できる管理者と監査担当者
データ保持期間
個人情報や認証情報のマスキング方法
開発・検証・本番環境の分離
削除手順と監査証跡

また、1MiBを超えるペイロードはログに記録されません。Payload Loggingだけを完全な監査証跡として扱うのは危険です。(Microsoft Learn)

Usage Trackingの閲覧権限にも注意する

Usage Trackingを有効にすると、リクエストごとのトークン数などがシステムテーブルに記録されます。ただし、関連するシステムテーブルは、初期状態ではアカウント管理者だけが参照できます。

運用担当者やFinOps担当者に監視を任せる場合は、システムテーブルへの参照権限を別途設計する必要があります。Payload LoggingとUsage Trackingは有料機能であり、権限管理やレート制限などは無料機能として提供されています。(Microsoft Learn)

複数ワークスペースではModel Provider Servicesも選択肢

複数のAzure Databricksワークスペースから同じFoundryリソースを利用する場合は、Unity CatalogのModel Provider Servicesを使う方法もあります。

接続先や資格情報をUnity Catalogの管理対象オブジェクトとして登録し、GRANTとREVOKEで利用権限を制御できます。利用者は資格情報を参照せずにモデルを呼び出せます。

ただし、2026年7月時点ではBetaであり、アカウント管理者によるプレビュー機能の有効化が必要です。最初から全社本番基盤へ採用するのではなく、仕様変更を許容できる環境で評価するのが適切です。(Microsoft Learn)

業務や開発で効果が出やすい使いどころ

Azure DatabricksからGPT-5.6を使う価値が高いのは、Databricks上のデータ処理と生成AIを一つのワークフローにまとめたい場合です。

Lakehouse上の社内データを使ったRAG

Unity Catalogで管理している文書やテーブルから、利用者が閲覧できる情報だけを検索し、必要な部分だけGPT-5.6へ渡します。

具体例は次のとおりです。

社内規程やマニュアルへの質問応答
製品仕様書を根拠にしたサポート回答案の作成
障害記録や運用ログを使った原因候補の整理
営業資料や契約資料の比較
研究報告書や技術文書の横断検索

GPT-5.6は大きなコンテキストウィンドウを持ちますが、データレイク全体をそのままプロンプトへ詰め込む設計は適切ではありません。コスト、応答時間、情報漏えいの範囲が拡大するため、検索、権限確認、絞り込みをDatabricks側で行い、必要最小限のデータだけを送信します。

SQL・Python・データパイプラインの開発支援

GPT-5.6へテーブル定義、エラー、処理要件を渡し、次の作業を支援させる使い方です。

SQLの生成と修正
PySparkコードの説明
スキーマ変換案の作成
ETLエラーの原因整理
テストケースの生成
データ品質ルールの候補作成

生成されたSQLやPythonを本番環境で自動実行する場合は、読み取り専用環境での検証、危険なSQL文の検出、人による承認を組み合わせます。コード生成精度だけでなく、「不正な更新や削除を実行しないか」を評価指標に含めることが重要です。

文書・画像からの構造化データ抽出

GPT-5.6はテキストと画像の入力、構造化出力に対応しています。そのため、PDFから切り出したページ画像や帳票を解析し、JSON形式で項目を抽出する処理に利用できます。(Microsoft Learn)

活用例としては、次のようなものがあります。

請求書や申込書の項目抽出
設備点検写真からの状態説明
グラフや表を含む報告書の要約
手書きメモを含む文書の分類
製品画像と説明文の整合性確認

完全自動化する前に、項目単位の正解率、未抽出率、誤抽出率を測定し、信頼度が低い結果だけ人が確認する運用にします。

ツール呼び出しを使ったAIエージェント

GPT-5.6は関数やツールの呼び出しに対応しているため、Databricks内外の処理を組み合わせたエージェントを構築できます。

例えば、ユーザーから「先月の売上低下の原因を調べて」と依頼された場合に、次の処理を順番に実行できます。

売上テーブルを検索する
前月・前年同月と比較する
商品や地域別に変動要因を分析する
関連する在庫やキャンペーン情報を取得する
根拠付きの説明を生成する

ただし、エージェントへ管理者権限を渡してはいけません。ツールごとに入力値を検証し、更新・削除・外部送信を伴う操作には承認処理を設けます。

大量データの分類・要約

問い合わせ、アンケート、障害記録、自由記述などの大量データを、Databricks JobからGPT-5.6へ送り、分類や要約を行う用途にも利用できます。

一方、単純なラベル付けや定型変換では、より小型で安価なモデル、従来の機械学習、SQLルールの方が適する場合があります。GPT-5.6を採用する前に、1,000件当たりの費用、処理時間、正解率を比較してください。

導入前に測定すべき評価指標

モデルの評価を「回答が自然だった」という印象だけで終わらせないことが重要です。

利用目的	主な評価指標
RAG	根拠の正確性、引用一致率、回答不能時の拒否率、誤情報率
SQL・コード生成	テスト通過率、実行成功率、危険な処理の生成率
文書抽出	項目別正解率、未抽出率、誤抽出率、人手修正率
AIエージェント	ツール選択正解率、不要な呼び出し回数、無許可操作率
要約・分類	人手評価との一致率、カテゴリ別の再現率
運用性能	平均・95パーセンタイル応答時間、タイムアウト率、429エラー率
コスト	1リクエスト、1文書、1業務処理当たりの費用

GPT-5.6への切り替えは、旧モデルより新しいという理由だけで決めるべきではありません。現在のモデルと同じ評価データを使い、品質向上分が追加費用や応答時間に見合うかを判断します。

対応が必要かを判断する基準

現在の状況	推奨する対応
Azure Databricksをデータ・AI基盤として利用している	限定的なPoCを開始する価値が高い
FoundryとDatabricksを別々に管理している	認証・利用量管理を統合できるか検証する
機密情報を扱い、処理地域に厳しい制約がある	デプロイ方式とデータ境界を確認してから判断する
外部エンドポイントへのPrivate Linkが必須	対象リージョンの対応状況を先に確認する
現行モデルで品質とコストの要件を満たしている	直ちに移行せず、比較評価だけ実施する
Azure Databricksを利用していない	Foundryを直接利用する方が構成は単純になりやすい
高リスクな判断を完全自動化したい	人による確認と承認を組み込めない限り見送る
単純な大量分類だけを行いたい	小型モデルや従来手法と費用を比較する

今回の更新は、すべてのAzure Databricks利用者に即時対応を求めるものではありません。Azure Databricksを生成AIの統制ポイントとして使いたい組織ほど、導入効果が大きくなります。

Azure DatabricksでGPT-5.6を導入する手順

利用目的と対象データを決める

最初から全社チャットを作るのではなく、評価しやすい業務を一つ選びます。

候補としては、社内文書検索、問い合わせ分類、SQL生成、報告書要約などが適しています。使用するデータを「公開情報」「社内情報」「機密情報」「個人情報」などに分類し、PoCでは可能な限り匿名化データを使います。

Foundryのリージョン、デプロイ方式、クォータを確認する

gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-lunaの提供状況を確認します。

同時に、Standard、Global、DataZoneなどのデプロイ方式を選び、データ処理地域が社内規程を満たすか確認します。クォータが不足している場合は、Model Serving Endpointを作る前に申請します。

認証方式を決める

本番環境では、個人に紐づくAPIキーではなく、業務アプリ専用のMicrosoft Entra IDサービスプリンシパルを優先します。

APIキーを使う場合も、Databricks Secretsから参照し、ノートブック、Gitリポジトリ、環境設定ファイルへ平文で保存しないようにします。

External Model Serving Endpointを作成する

Azure Databricks側で、OpenAIプロバイダーを使用するExternal Model Serving Endpointを作成します。

主な設定項目は次のとおりです。

GPT-5.6のモデル名
Foundry側のデプロイ名
APIベースURL
APIバージョン
APIキーまたはMicrosoft Entra ID認証情報
LLMのタスク種別

モデル名とデプロイ名は別の値です。Foundryで任意のデプロイ名を設定している場合、公式モデルIDをそのままデプロイ名として入力すると接続エラーになる可能性があります。

権限とAI Gatewayを設定する

エンドポイント作成後、管理権限をプラットフォーム管理者へ限定し、利用者にはクエリ権限だけを付与します。

続いて、次の設定を行います。

エンドポイント全体のレート制限
ユーザーまたはサービスプリンシパル別のレート制限
Usage Tracking
必要に応じたPayload Logging
ガードレール
フォールバック
複数モデルを比較する場合のトラフィック分割

External Model Endpointでは、権限管理、レート制限、ペイロードログ、利用量追跡、ガードレール、フォールバック、トラフィック分割を利用できます。ただし、AI GuardrailsはPublic Previewです。(Microsoft Learn)

品質・コスト・障害時動作を検証する

本番移行前に、少なくとも次のテストを実施します。

正常な入力への回答品質
不完全な入力や曖昧な質問への挙動
プロンプトインジェクションへの耐性
機密情報を要求された場合の拒否動作
タイムアウトと再試行
クォータ超過時の挙動
利用量ログの記録
フォールバック先への切り替え
1業務処理当たりの費用
ピーク時の応答時間

旧モデルから切り替える場合は、同じ評価データを使った並行比較を行います。新モデルへ一括で切り替えず、一部のトラフィックから段階的に移行する方が安全です。

導入時に失敗しやすいポイント

GPT-5.6がDatabricks内で実行されると思い込む

Model Serving Endpointは統一された入口です。実際の推論処理はMicrosoft Foundry側で行われます。データ境界、ネットワーク、処理地域はFoundryを含めて確認してください。

GAなら関連機能もすべてGAだと判断する

GPT-5.6の利用経路がGAでも、AI Guardrails、Model Provider Services、MLflowの一部API例などにはプレビューまたはBetaの機能があります。機能ごとのライフサイクルを確認する必要があります。

APIキーをノートブックへ直接記述する

ノートブックの共有、エクスポート、Git連携によって資格情報が漏えいする可能性があります。Databricks SecretsまたはMicrosoft Entra IDを利用してください。

大きなコンテキストへデータを詰め込みすぎる

最大コンテキストが大きくても、常に大量データを送る必要はありません。検索とフィルタリングで対象を絞らなければ、費用、応答時間、情報漏えいリスクが増大します。

Payload Loggingを監査ログとして過信する

大きなペイロードが記録されない場合があり、ログ自体にも機密データが含まれます。Azure側の操作ログやアプリケーションログと組み合わせ、保持・削除方針も決めてください。

クォータと429エラーを確認せず本番化する

開発環境では正常でも、複数利用者やバッチ処理を追加するとクォータへ到達する可能性があります。レート制限、指数バックオフ、再試行上限、フォールバックを事前に実装します。

まず確認すべき3つの項目

OpenAI GPT-5.6をAzure Databricksで利用する場合は、次の順序で確認すると判断しやすくなります。

Foundry側でGPT-5.6をデプロイできるリージョンとクォータがあるか
DatabricksからFoundryまでの通信経路とデータ処理地域が社内要件を満たすか
エンドポイント権限、レート制限、ログ、費用監視を管理者が統制できるか

3項目を満たす場合は、匿名化した実データに近い評価セットを用意し、現行モデルとGPT-5.6を比較します。Azure Databricksをすでにデータ基盤として利用している組織では、モデル性能だけでなく、生成AIの入口を一元化できることが導入の大きな利点です。

反対に、閉域通信や厳格なデータ所在地要件を満たせない場合は、GAであることだけを理由に導入してはいけません。モデルの新しさではなく、データ境界、管理可能性、業務効果、費用の4点を確認してから本番採用を判断することが重要です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。