Databricks Certified Generative AI Engineer Associate 教科書
第4章 アプリケーションの組み立てとデプロイ(Assembling and Deploying Applications, 22%)
🎯 この節の学習目標
RAGボットやエージェントを作っても、利用者に届けるには「アプリケーション」としての置き場所が必要です。チャットUI、業務ロジック、複数エンドポイントの組み合わせ——これらを外部のクラウドやウェブサーバーに持ち出すと、認証・権限・監査をデータ基盤の外でもう一度作り直すことになります。
Databricks Appsは、この問題への答えです。Databricksワークスペースの中で、ウェブアプリ(UI付きアプリやエージェントのバックエンド)をサーバーレスにホストする機能で、次の特徴を持ちます。
2026年時点で、Databricksはエージェントの配置先としてDatabricks Appsを推奨しており、Model Serving上にデプロイ済みの既存エージェントをAppsへ移行するための公式ガイドも提供しています。
エージェントのデプロイはModel Serving + agents.deploy()を中心に出題されることがありえます(4-2)。「UC登録済みエージェントをエンドポイント化し、Review Appと推論テーブルが自動セットアップされる」という流れは引き続き答えられるようにしておきましょう。
現行のDatabricksは、エージェントのホスティング先としてDatabricks Appsを推奨しています。エージェント本体をAppsに置き、内部からFoundation Model API・AI Search・Genie・MCPを呼ぶ構成が基本形で、Model Serving上の既存エージェントをAppsへ移行する公式ガイドも提供されています。
両者は競合するものではなく、担当する層が異なります。判断軸は「配信したいものはモデルか、アプリケーションか」です。
| 観点 | Model Serving | Databricks Apps |
|---|---|---|
| 配信するもの | モデル推論エンドポイント(RESTでモデルを配信) | アプリケーション(UI・カスタムロジック・複数エンドポイントの統合を含む) |
| 典型例 | Foundation Model API、外部モデル、UC登録済みカスタムモデルの推論(4-2) | チャットUI付きRAGボット、エージェントのバックエンド、社内向け業務アプリ |
| 呼び出し方 | REST(/invocations)、SDK、ai_query() | ブラウザからのアクセス、アプリのAPI |
| エージェントの位置付け | 従来はagents.deploy()でエンドポイント化 | 現行の推奨ホスティング先。エージェントは内部からServingエンドポイントを呼ぶ |
重要なのは、Appsを使う構成でもModel Servingが不要になるわけではないことです。LLMそのものの推論はFoundation Model API等のServingエンドポイントが担い、Apps上のエージェントはそれを呼び出す側に立ちます。「モデルの配信=Model Serving、アプリケーションのホスト=Apps」という役割分担で覚えてください。
📝 試験のポイント
「モデルをREST APIとして公開したい」→ Model Serving。「対話UIを持つアプリや、複数のエンドポイント・ツールを組み合わせるエージェントをホストしたい」→ Databricks Apps。配信対象が「モデル」か「アプリケーション」かで切り分けるのが判断の軸です。
エージェントをAppsでホストする場合の全体像は次の通りです。エージェント(3章で見たResponsesAgent等のインターフェースで実装)がAppsの上で動き、必要なリソースを内部から呼び出します。
図:Databricks Appsを中心とした現行推奨のエージェント構成。ホストはApps、推論はModel Serving、記録・統制はMLflowとUnity AI Gatewayが担う
この構成のポイントは、各層の役割がきれいに分かれることです。
認証・権限(4-3の復習):Appsにデプロイしたアプリは、開発者本人ではなくサービスプリンシパルとしてリソースにアクセスします。したがって、エージェントが使うAI Searchインデックス、Servingエンドポイント、UC関数などへの権限(USE CATALOG / USE SCHEMA / SELECT / EXECUTE)を、サービスプリンシパルに対して付与する必要があります。「開発中は動いたのにデプロイしたら権限エラー」という定番のつまずきは、実行主体の変化を見落とすことが原因です。外部サービスのAPIキーが必要な場合はSecretsで管理します。
コスト(4-7の復習):Appsのホスティングはサーバーレスですが、コストの主役は依然として内部から呼び出すLLM推論です。Foundation Model APIのpay-per-token/Provisioned Throughputの選択、プロンプト長・max_tokensの制御、キャッシングといった4-7の打ち手はAppsの構成でもそのまま適用されます。組織的な統制(レート制限・スペンドキャップ)はUnity AI Gatewayに集約します。
💼 例:社内文書QAエージェントをAppsで公開する
社内規程に答えるエージェントを公開するとします。エージェント本体(AI Searchで検索し、Foundation Model APIで回答を生成するResponsesAgent)とチャットUIをDatabricks Appsにデプロイし、アプリのサービスプリンシパルにインデックスへのSELECTとエンドポイントへのEXECUTE権限を付与します。利用者はブラウザからワークスペース認証でアクセスするだけで、権限のない文書は検索段階で見えません。動作の記録はMLflowのトレーシングに残り、利用の統制はUnity AI Gatewayでかけられます——インフラ管理は一切不要です。
✅ この節のまとめ
問1. チャットUIを持ち、社内文書の検索(AI Search)と構造化データへの質問(Genie)を使い分けるエージェントアプリを、インフラを管理せずにDatabricks上でホストしたい。2026年時点で最も適切な配置先はどれか。
正解:B
UI・カスタムロジック・複数リソースの統合を含む「アプリケーション」のホスティングはDatabricks Appsの役割で、サーバーレスかつUC・認証・ガバナンスと統合されます。Aはインフラ管理と認証・監査の作り直しが発生し、Cは利用者体験・統制の両面で本番公開に不適、DはAI Searchが検索インデックスの機能でありアプリのホスティング先ではありません。
問2. Model ServingとDatabricks Appsの使い分けの説明として最も適切なものはどれか。
正解:B
役割分担は「モデルの配信=Model Serving、アプリケーションのホスト=Apps」です。Appsを使う構成でもLLM推論はFoundation Model API等のServingエンドポイントが担うため、Aは誤りです。Cのバッチ/リアルタイムという軸の分担ではなく、Dの名称変更でもありません。
問3. 開発中は動作していたエージェントアプリをDatabricks Appsにデプロイしたところ、AI Searchインデックスへのアクセスで権限エラーが発生した。最も可能性の高い原因はどれか。
正解:B
Appsにデプロイしたアプリは開発者本人ではなくサービスプリンシパルとしてリソースにアクセスします。開発中は本人の権限で動いていても、デプロイ後は実行主体が変わるため、サービスプリンシパルへの権限付与(4-3)が必要です。A・C・Dはいずれも権限エラーの原因ではありません。
問4. Databricks Appsでホストしたエージェントアプリについて、運用フェーズのコストとガバナンスの考え方として最も適切なものはどれか。
正解:B
ホスティングがサーバーレスでも、LLM推論のコストは呼び出した分だけ発生します。pay-per-token/Provisioned Throughputの選択やプロンプト長の制御(4-7)は引き続き有効で、レート制限・スペンドキャップなどの統制はUnity AI Gateway(4-4)で一元化します。Aは推論コストを見落とし、Cは統制がアプリごとに散らばるアンチパターン、Dはアプリの機能自体を失わせます。