Azure DatabricksでOpenAI GPT-5.6が一般提供されたものの、「既存環境ですぐ使えるのか」「データはどこで処理されるのか」「管理者は何を設定すべきか」と判断に迷う担当者も多いでしょう。
結論から言えば、今回の更新により、Azure Databricks上のデータ処理、RAG、AIエージェントから、GPT-5.6シリーズをModel Serving経由で利用しやすくなりました。ただし、一般提供されたからといって、すべてのワークスペースで自動的に利用可能になるわけではありません。
本番利用には、ADI Servicesの利用資格と有効化、データ処理地域、エンドポイント権限、料金、ログ保存、モデル固有の利用条件を確認する必要があります。Databricksに業務データやAI処理を集約している組織は検証優先度が高い一方、Microsoft Foundryだけで完結している既存システムを急いで移行する必要はありません。
Azure DatabricksとMicrosoft FoundryでGPT-5.6が一般提供
2026年7月10日に更新されたDatabricksのリリースノートでは、OpenAI GPT-5.6 Sol、GPT-5.6 Terra、GPT-5.6 Lunaが、Databricks-hosted modelとしてModel Servingに追加されています。機能項目自体は2026年7月9日付で、Foundation Model APIsの従量課金方式から利用できます。
リリースは段階的に反映されるため、初期公開日から1週間以上経過してから対象アカウントに表示される場合があります。モデルが見つからないときは、設定ミスと決めつけず、段階展開の状況も確認しましょう。(Databricks Documentation)
同時期にMicrosoft FoundryでもGPT-5.6シリーズが一般提供されました。Microsoft Foundry ModelsとFoundry Agent Serviceの両方が対象で、Global Standard、Data Zones Standard、Global Provisionedなどの提供形態が案内されています。(マイクロソフト アジュール)
今回の更新を実務的に言い換えると、次のようになります。
- Azure DatabricksのModel Servingを、GPT-5.6の統一された呼び出し口として使える
- Databricksのノートブック、ジョブ、アプリ、RAG、エージェントからモデルを呼び出しやすい
- モデルごとに異なるAPI管理を増やさず、エンドポイント単位で権限や利用量を管理できる
- Microsoft Foundry側のモデル提供、リージョン、処理方式と組み合わせて運用できる
単に外部のOpenAI APIを呼び出せるようになったという更新ではありません。Databricksのセキュリティ境界とModel Servingの管理機能を利用しながら、GPT-5.6を業務システムに組み込みやすくなった点が重要です。
GPT-5.6 Sol・Terra・Lunaの違い
GPT-5.6は単一モデルではなく、性能、速度、料金の異なる3モデルで構成されています。すべての処理に最上位モデルを使うのではなく、用途に応じて使い分けることが前提です。
| モデル | 主な特徴 | 向いている用途 | コンテキスト長 | Databricksのエンドポイント名 |
|---|---|---|---|---|
| GPT-5.6 Sol | 複雑な推論、長時間のエージェント処理、コード生成に強い | 複雑な障害解析、コード移行、複数ツールを使うエージェント | 105万トークン | databricks-gpt-5-6-sol |
| GPT-5.6 Terra | 性能、速度、料金のバランスを重視 | 社内RAG、文書分析、業務支援、一般的なエージェント | 105万トークン | databricks-gpt-5-6-terra |
| GPT-5.6 Luna | 高速かつ低コスト | 大量の分類、抽出、要約、低遅延が必要な処理 | 40万トークン | databricks-gpt-5-6-luna |
3モデルともテキストと画像を入力でき、最大出力は12万8,000トークンです。公式ドキュメントでは、Solは長時間推論や複雑なツール利用、Terraは日常的な推論処理、Lunaは大量・低遅延処理向けと位置付けられています。(Databricks Documentation)
モデル選定で迷う場合は、まずTerraを基準モデルにすると判断しやすくなります。
- Terraで品質が不足する複雑な処理だけSolへ切り替える
- Terraで品質が十分な大量処理はLunaへ切り替える
- 1つの業務フロー内でも、工程ごとにモデルを分ける
例えば、問い合わせ文の分類にはLuna、社内文書を使った回答生成にはTerra、複雑な障害原因の分析にはSolを使う構成です。この方法なら、品質を維持しながらトークン費用と応答時間を抑えられます。
公表価格はDatabricks経由の請求額と分けて考える
Microsoft FoundryのStandard Globalについては、100万トークン当たりの公表価格が次のように案内されています。
| モデル | 入力 | 出力 |
|---|---|---|
| GPT-5.6 Sol | 5米ドル | 30米ドル |
| GPT-5.6 Terra | 2.5米ドル | 15米ドル |
| GPT-5.6 Luna | 1米ドル | 6米ドル |
これはMicrosoft FoundryのStandard Globalに対する公表値です。Azure Databricks経由の契約、リージョン、提供方式、割引条件によって実際の請求は異なる可能性があります。Databricks側の公式文書も、利用資格と料金の詳細についてアカウントチームへの確認を求めています。見積もりでは、公表単価をそのまま採用せず、自社契約の単価を使用してください。(マイクロソフト アジュール)
利用にはADI Servicesの資格と有効化が必要
Azure DatabricksでGPT-5.6を使うには、ADI Servicesの利用条件を満たす必要があります。一般提供は「誰でも設定なしで即利用できる」という意味ではありません。
公式ドキュメントでは、GPT-5.6シリーズへのアクセスにADI Servicesの利用資格と有効化が必要とされています。対象ワークスペースでは、アカウント設定にある「Integration with ADI Services」を有効にします。利用資格や料金が不明な場合は、Azure Databricksのアカウントチームに確認します。(Databricks Documentation)
利用前に確認すべき条件は次のとおりです。
| 確認項目 | 判断内容 |
|---|---|
| ADI Servicesの利用資格 | 自社契約と対象ワークスペースが利用条件を満たすか |
| ワークスペース設定 | Integration with ADI Servicesが有効か |
| Model Servingの提供地域 | 対象ワークスペースのリージョンで利用できるか |
| モデルの表示状況 | 段階展開が完了し、対象エンドポイントが利用可能か |
| 課金方式 | 従量課金、予約容量、Foundry側のデプロイ方式をどう選ぶか |
| 利用規約 | OpenAIの利用ポリシーや高リスク用途の要件を満たせるか |
| データ処理地域 | Global、Data Zone、Regionalのどれを利用するか |
| 運用権限 | 誰がエンドポイントを管理し、誰が問い合わせできるか |
ADI Services経由のモデルは、特記がない限り、リアルタイム推論とバッチ推論に利用できます。Function CallingとStructured Outputにも対応しているため、単純なチャットだけでなく、外部ツールを実行するエージェントや、JSON形式で結果を返す文書処理にも利用できます。(Databricks Documentation)
データ境界は「保存場所」「推論場所」「ログ」を分けて確認する
Azure Databricks上にエンドポイントがあるからといって、すべてのデータ処理がワークスペースと同じリージョン内で完結するとは限りません。
データ境界を確認するときは、次の3点を分けて考える必要があります。
Databricksのセキュリティ境界
GPT-5.6の各エンドポイントは、Databricksのセキュリティ境界内でホストされるDatabricks-hosted endpointとして案内されています。また、ADI Servicesには標準のデータ所在地設定が適用されます。(Databricks Documentation)
これは、利用者が個別にOpenAIのAPIキーをソースコードへ埋め込み、外部APIを直接管理する構成とは異なります。ただし、「Databricks-hosted」という表現だけで推論処理地域まで判断してはいけません。
Microsoft Foundryでの推論処理地域
Microsoft Foundryでは、デプロイ方式によって推論データの処理場所が異なります。
| デプロイ方式 | 推論データの処理範囲 | 注意点 |
|---|---|---|
| Global | モデルが配置された任意のAzureリージョン | ワークスペースと同一リージョンとは限らない |
| Data Zone | 米国、EU、APACなど指定データゾーン内 | APACは日本国内限定ではない |
| Regional | デプロイに関連付けられたリージョン | モデルや提供方式ごとの対応確認が必要 |
保存時のデータは指定されたAzureの地域内に残りますが、推論時のプロンプトと応答はデプロイ方式に従って処理されます。APAC Data Zoneはアジア太平洋地域内での処理を意味し、日本国内だけでの処理を保証する表現ではありません。(Microsoft Learn)
社内規程が「日本国内での処理」を求めている場合、「APAC対応」という理由だけで承認してはいけません。Regionalの提供可否、対象リージョン、契約上のデータ所在地を個別に確認する必要があります。
RAGでモデルへ送られる情報
RAGを利用しても、モデルへデータが送られなくなるわけではありません。
例えば、Unity Catalogで管理する契約書を検索し、関連する3段落をプロンプトに追加した場合、元の契約書ファイル全体はDatabricksに残っていても、その3段落は推論リクエストの一部としてモデルへ送信されます。
そのため、RAGでは次の設計が必要です。
- 検索結果に含める列や文書範囲を最小化する
- 個人情報、認証情報、機密コードを送信前に除去する
- ユーザーの権限に応じて検索対象を絞る
- プロンプトへ付加した文書IDや分類区分を監査可能にする
- 回答に参照元を表示し、根拠を確認できるようにする
長いコンテキストを利用できるからといって、文書やテーブルを無制限に投入するのは適切ではありません。費用が増えるだけでなく、不要な機密情報が推論対象に含まれる可能性も高まります。
プロンプトと応答のログ
AI GatewayのInference Tablesを有効にすると、Model Servingへのリクエストと応答をUnity CatalogのDeltaテーブルへ記録できます。障害調査や品質評価には便利ですが、プロンプトに個人情報や機密情報が含まれている場合、ログ側にも同じ情報が保存されます。(Microsoft Learn)
ログを有効にする前に、次の項目を決めておきましょう。
- 保存するプロンプトと応答の範囲
- マスキングや匿名化を行う場所
- ログテーブルを閲覧できる担当者
- 保存期間と削除方法
- 開発環境と本番環境での設定差
- 監査目的とモデル改善目的のデータを分離するか
「監視のためにすべて保存する」という方針は、情報漏えい時の影響範囲を広げる可能性があります。トークン数やエラー率だけを保存する運用と、本文を含むペイロードログを分けて設計することが重要です。
OpenAIの保持条件も確認する
ADI Servicesの文書には、gpt-5.5、gpt-5.5-proおよび将来のモデルについて、コーディングやルーティングに関係する一部の顧客コンテンツが、利用ポリシー違反の可能性を検知した場合に保持される可能性があると記載されています。
GPT-5.6をコード生成、第三者向け開発サービス、複数モデルを仲介するサービスに利用する場合は、この条件が自社用途へどう適用されるかを契約・法務担当者と確認してください。(Databricks Documentation)
管理者が設定すべきアクセス制御とコスト管理
GPT-5.6の有効化だけで運用を始めると、誰でも高額なモデルを利用できる状態や、管理機能を回避したエンドポイントが増える状態になりかねません。
エンドポイント作成権限を利用者へ広く付与しない
Model Servingのエンドポイントには、管理用のCAN MANAGEと問い合わせ用のCAN QUERYがあります。
公式ドキュメントでは、ガードレールやスループット制限の回避を防ぐため、エンドポイント作成とCAN MANAGEを管理者に限定し、一般利用者には承認済みエンドポイントへの問い合わせ権限だけを付与することが推奨されています。(Microsoft Learn)
実務では、次のように役割を分けると管理しやすくなります。
| 担当 | 主な権限 |
|---|---|
| プラットフォーム管理者 | ADI Servicesの有効化、エンドポイント作成、共通制限の設定 |
| AI基盤運用者 | モデル変更、レート制限、監視、障害対応 |
| アプリケーション | 承認済みエンドポイントへのCAN QUERY |
| 開発者 | 開発環境のエンドポイントへの問い合わせ |
| 監査・FinOps担当 | 使用量、費用、監査ログの閲覧 |
本番アプリからの認証には、個人ユーザーのトークンではなくサービスプリンシパルを使用します。Azure Databricksでは、無人処理やREST APIからのアクセスにOAuth 2.0を利用する方法が案内されています。(Microsoft Learn)
使用量とペイロードログを分ける
AI Gatewayでは、エンドポイントごとの使用量追跡を有効にできます。system.serving.endpoint_usageにはリクエストごとのトークン数、system.serving.served_entitiesには基盤モデルの情報が記録されます。(Microsoft Learn)
一方、Inference Tablesはリクエスト本文と応答本文を記録する機能です。
- 費用分析だけが目的なら、まず使用量追跡を有効にする
- 品質評価や障害調査が必要な場合に限り、ペイロードログを検討する
- 本番の機密データでは、マスキング後の内容だけを記録する
- 開発環境と本番環境でログ設定を分ける
この順序にすると、監視のために不要な機密情報を保存するリスクを抑えられます。
レート制限と予算上限を設定する
AI Gatewayでは、エンドポイント全体、ユーザー、グループ、サービスプリンシパルごとにQPMやTPMの制限を設定できます。初期状態ではレート制限が設定されていないため、本番公開前に上限を決める必要があります。(Microsoft Learn)
特に注意したいのは、エージェントのループ処理です。ツール実行に失敗したエージェントが自動再試行を続けると、短時間で大量のトークンを消費することがあります。
次の制御を組み合わせると効果的です。
- 1リクエスト当たりの最大入力トークン数
- 1回の処理で許可するツール実行回数
- 最大再試行回数
- ユーザーまたはアプリ単位のTPM
- 日次・月次の予算アラート
- 一定額を超えたときの利用停止
- Solを利用できるアプリや部署の限定
Databricksでは、Unity AI Gatewayを対象とした予算設定により、利用者ごとのしきい値、通知、利用停止を構成できることも案内されています。(Databricks Documentation)
業務や開発で効果を出しやすい活用例
Databricks上の業務データを使ったRAG
最も相性がよいのは、Databricksに保存された文書やテーブルを検索し、回答の根拠としてGPT-5.6へ渡すRAGです。
例えば、次のような用途があります。
- 製品マニュアルと障害履歴を使ったサポート回答
- 社内規程を参照する人事・総務向けチャット
- 契約書から更新条件や解約条項を抽出する業務
- データカタログの説明や定義を回答する分析支援
- 過去のインシデントから類似障害を検索する運用支援
この用途では、まずTerraを試すのが現実的です。回答の正確性が不足する複雑な文書分析だけSolへ切り替え、大量の事前分類や検索クエリ生成にはLunaを使います。
GPT-5.6も誤った情報を生成したり、必要な事実を省略したりする可能性があります。Databricksも、正確性が重要な用途ではRAGを利用するよう案内しています。RAGを導入した後も、回答根拠の表示と人による確認は必要です。(Databricks Documentation)
データパイプラインやコードの分析
Solは、長時間の推論、複雑なツール利用、エージェント型のコード処理に向いています。
具体的には、次のような場面が考えられます。
- 複数のノートブックをまたぐ障害原因の調査
- SQLやPythonコードの移行計画作成
- ジョブログとソースコードを使った原因候補の整理
- レガシー処理をLakeflowや新しい実装へ移行する際の補助
- テストコードやデータ品質チェックの作成
ただし、生成されたコードを自動的に本番へ反映する構成は避けるべきです。テスト、静的解析、権限チェック、レビューを通したうえで適用します。
大量の文書分類と構造化抽出
Lunaは、請求書、申請書、メール、問い合わせ履歴などを大量に処理する用途に向いています。
Structured Outputを使えば、次のようなJSON形式で結果を統一できます。
{
"category": "契約変更",
"priority": "high",
"customer_id": "masked",
"requires_human_review": true
}出力形式を固定しても、値の正しさまで保証されるわけではありません。日付、金額、契約番号などの重要項目は、正規表現、マスターデータ、業務ルールによる後段検証を追加します。
ツールを実行する業務エージェント
Function Callingを利用すると、GPT-5.6に単なる回答ではなく、検索、チケット作成、承認依頼、SQL実行などのツール選択をさせられます。
ただし、ツール権限はモデルではなく実行基盤側で制御します。
例えば、問い合わせ対応エージェントには次のような段階を設けます。
- Lunaで問い合わせを分類する
- Terraで社内文書を検索して回答案を作る
- 返金や契約変更が必要な場合は人へ承認を依頼する
- 承認後だけ業務システムの更新ツールを実行する
- 複雑な例外案件だけSolで再分析する
モデルに管理者権限を与えるのではなく、用途別の限定されたツールを用意することが重要です。
自社で対応が必要かを判断する基準
すべてのAzure Databricks利用組織が、直ちにGPT-5.6へ移行する必要はありません。
| 現在の状況 | 対応優先度 | 推奨する対応 |
|---|---|---|
| RAGやAIエージェントのデータがDatabricksにある | 高い | Terraを基準に小規模な検証を始める |
| 複雑なコード解析や長時間推論が課題 | 高い | Solを既存モデルと比較する |
| 大量処理のトークン費用が高い | 高い | LunaとTerraで品質・費用を比較する |
| Microsoft Foundryだけで既存アプリが安定稼働 | 低い | 急いで移行せず、次回更改時に比較する |
| GPT-5.4やGPT-5.5で品質と費用に問題がない | 中程度 | 代表データで回帰評価し、差がある場合だけ移行する |
| 日本国内だけでの推論処理が必須 | 保留 | APACではなくRegionalの可否を確認する |
| 機密情報や規制対象データを扱う | 保留 | 保持条件、ログ、利用規約を審査してから検証する |
| エンドポイント管理者が決まっていない | 保留 | 権限設計と費用管理を先に整備する |
特に、Microsoft Foundryで既に安定したアプリを運用している場合、Azure Databricks版が登場したことだけを理由に移行する必要はありません。
一方、次の条件に当てはまるなら検証価値があります。
- モデルへ渡すデータの準備をDatabricksで行っている
- Unity Catalogの権限とAIアクセスをまとめて管理したい
- バッチ処理とリアルタイム推論を同じ基盤から実行したい
- モデル利用量をDatabricksのシステムテーブルで分析したい
- RAG、評価、ジョブ、監視を分断せずに運用したい
導入時は小さな評価セットから始める
GPT-5.6への対応は、既存モデルを一括置換するのではなく、代表的な1業務で比較検証するのが安全です。
利用条件とデータ分類を確認する
最初に、次の情報を整理します。
- 利用するワークスペースとリージョン
- ADI Servicesの利用資格
- 入力するデータの機密区分
- 個人情報や顧客情報の有無
- 必要なデータ処理地域
- OpenAIの利用条件に抵触しないか
- プロンプトと応答をログへ保存できるか
この確認が終わるまでは、実データではなく匿名化した評価データを使います。
100〜300件程度の正解付きデータを用意する
モデル比較には、実際の業務を反映した評価データが必要です。
例えば、問い合わせ回答なら次の情報を用意します。
- 入力された問い合わせ
- 参照すべき社内文書
- 期待する回答
- 回答してはいけない内容
- 人への引き継ぎが必要か
- 重要度やカテゴリの正解
平均点だけでなく、重大な誤回答の件数を個別に確認します。90％の質問に正解しても、残り10％で契約条件や金額を誤るなら、そのまま本番には出せません。
品質以外も同時に測定する
評価では、次の指標を記録します。
| 評価項目 | 確認内容 |
|---|---|
| 正確性 | 正解や参照文書と一致しているか |
| 根拠性 | 回答の根拠を提示できるか |
| 安全性 | 機密情報や禁止内容を出力しないか |
| 構造化成功率 | 指定したJSON形式を守れるか |
| ツール成功率 | 適切なツールと引数を選べるか |
| 応答時間 | 平均だけでなくP95、P99を確認する |
| トークン量 | 入力、出力、再試行を含めて測る |
| 1件当たり費用 | 実際の利用単価で計算する |
| エラー率 | タイムアウト、429、形式エラーを確認する |
| 人手削減効果 | 作業時間や確認時間がどれだけ減るか |
品質がわずかに高いだけで費用が数倍になる場合、全件をSolで処理する必要はありません。LunaまたはTerraで一次処理し、信頼度が低い案件だけ上位モデルへ送る設計が有効です。
段階的に本番へ展開する
検証後は、次の順番で利用範囲を広げます。
- 開発者だけが使う評価環境
- 社内の限定ユーザー
- 人が回答を確認する業務
- 読み取り専用のツールを使うエージェント
- 承認後に更新処理を行うエージェント
モデル名をアプリへ直接埋め込まず、設定やルーティング層から切り替えられるようにしておくと、品質問題や費用増加が発生した際に旧モデルへ戻しやすくなります。
失敗しやすいポイント
一般提供された時点で全ユーザーへ開放する
GAは、本番利用を検討できる提供状態を示すものであり、自社の審査が不要になるという意味ではありません。まずADI Services、データ境界、契約、権限を確認します。
APAC Data Zoneを日本国内処理と解釈する
APACはアジア太平洋地域を意味します。日本国内限定の要件がある場合は、Regionalの利用可否を確認してください。
最大コンテキストまでデータを詰め込む
105万トークンを扱えることと、105万トークンを毎回送るべきことは別です。検索精度を高め、必要な情報だけをプロンプトへ追加した方が、費用、速度、情報管理の面で有利です。
最上位モデルを全処理に使う
Solが高性能でも、分類や定型抽出までSolで処理すると費用が膨らみます。Terraを基準にし、Lunaへの置き換えとSolへの昇格を検討します。
ログを無条件ですべて保存する
プロンプトと応答の保存は品質改善に役立ちますが、機密情報の複製にもなります。使用量の記録とペイロードの記録を分け、必要なログだけを残します。
RAGを導入すれば誤回答がなくなると考える
RAGは根拠を追加する仕組みであり、正解を保証する仕組みではありません。検索漏れ、古い文書、権限設定ミス、モデルによる読み違いは残ります。
エージェントへ強い更新権限を与える
モデルが誤ったツールや引数を選ぶ可能性を前提に、読み取り、下書き、承認、更新を分離します。削除、支払い、契約変更などの処理には、人による承認を設けるべきです。
まず確認すべきこと
今回の更新で最も恩恵を受けるのは、Databricksに業務データがあり、RAG、文書処理、コード分析、AIエージェントを同じ基盤で運用したい組織です。
対応を始める際は、次の順番で進めると判断しやすくなります。
- ADI Servicesの利用資格とワークスペースへの反映状況を確認する
- Global、Data Zone、Regionalのどれが自社要件を満たすか確認する
- 管理者だけに
CAN MANAGEを付与し、アプリにはCAN QUERYを付与する - Terraを基準に、SolとLunaを同じ評価データで比較する
- 使用量、ペイロードログ、レート制限、予算上限を設計する
- 実データを投入する前に、保持条件と利用ポリシーを確認する
- 1つの低リスク業務から段階的に本番展開する
既存環境を直ちに置き換えるのではなく、実際の業務データに近い評価セットを使い、品質、速度、費用、データ境界を数値で比較することが重要です。その結果、Databricksとの統合によって運用が簡素化される、または明確な品質・費用改善が得られる場合に、本格導入へ進むとよいでしょう。
コメント