Databricks Certified Generative AI Engineer Associate 教科書
第4章 アプリケーションの組み立てとデプロイ(Assembling and Deploying Applications, 22%)
🎯 この節の学習目標
組織でLLMやエージェントの利用が広がると、モデルの性能とは別次元の課題が噴出します。「あるチームが大量にクエリを投げてコストが暴走した」「誰が何をどれだけ使ったか分からない」「有害な出力が出ないか不安」「プロバイダ障害でアプリごと停止した」——。これらに答えるのがUnity AI Gateway(旧 Mosaic AI Gateway)です。
Unity AI Gatewayは、2026年6月のData + AI Summitで発表され、2026年8月4日にGA(一般提供)となった、Unity Catalog上に構築されたランタイムガバナンス層です。従来のAI GatewayがModel Servingエンドポイント(=モデルの入口)への統制だったのに対し、Unity AI Gatewayの統制対象はAgents(エージェント)・Models(モデル)・MCPサーバー・Tools(ツール)にまで広がっています。エンドポイントやエージェントを通るすべてのリクエスト/レスポンスに対して、制限・記録・フィルタ・ルーティングといった統制を一元的にかけられます。
図:Unity AI GatewayはAI利用の「関所」。モデルもエージェントもツールも、同じガバナンス層を通す
AI Gateway(Mosaic AI Gateway)として、Model Servingエンドポイントに付加するガバナンス機能——レート制限・使用状況トラッキング・ペイロードロギング(推論テーブル)・ガードレール・トラフィックルーティング、および外部モデルへの統一適用——が問われることがあります。本節の第2〜4節がこの範囲です。
現行名称はUnity AI Gateway(2026年8月4日GA)。従来機能を土台に、統制対象がagents / models / MCPサーバー / toolsのランタイム全体へ拡大し、ハードなスペンドキャップ(コスト上限の強制)やスマートルーティング、全エージェント活動の統合トレーシングが加わっています。
📝 試験のポイント
問題文に「複数チームのLLM利用を統制したい」「利用量を制限したい」「組織横断でLLMの使い方を管理したい」という表現が出たら、答えの軸はほぼUnity AI Gateway(出題名はAI Gatewayの場合あり)です。個々のプロンプト改善やモデル変更ではなく、ガバナンス層の話だと見抜けるようにしましょう。
まず、従来のAI Gateway時代から提供され、Unity AI Gatewayの土台になっている5機能を整理します。試験対策としてはここが中心です。
| 機能 | 内容 |
|---|---|
| ①レート制限(Rate Limiting) | ユーザー単位・エンドポイント単位で一定時間あたりのクエリ数を制限する。特定ユーザーの暴走や意図しない大量呼び出しを防ぐ |
| ②使用状況トラッキング(Usage Tracking) | 誰が・どのエンドポイントを・どれだけ使ったかをシステムテーブルに記録する。コスト配賦やチャージバック、利用分析の基盤 |
| ③ペイロードロギング(Payload Logging / 推論テーブル) | リクエストとレスポンスの本文をDeltaテーブル(推論テーブル)に記録する。監査、デバッグ、品質評価(第5章)、ドリフト監視(第6章)の元データになる |
| ④ガードレール(Guardrails) | 入力・出力に対するセーフティフィルタ。有害コンテンツのブロックやPII(個人識別情報)検出、話題の制限などをエンドポイント側で強制する |
| ⑤トラフィックルーティング/フォールバック | 複数モデルへのトラフィック分割(A/Bテスト・段階移行)や、プライマリモデル障害時のフォールバック(自動切替)で可用性を高める |
💡 例:ガードレールとレート制限の設定イメージ
エンドポイント作成・更新時にゲートウェイの設定として宣言的に指定します(UI/APIとも可)。
ai_gateway = {
"usage_tracking_config": {"enabled": True},
"inference_table_config": {
"catalog_name": "prod", "schema_name": "genai_logs", "enabled": True
},
"rate_limits": [
{"calls": 100, "key": "user", "renewal_period": "minute"}
],
"guardrails": {
"input": {"safety": True, "pii": {"behavior": "BLOCK"}},
"output": {"safety": True}
},
}
このように、アプリ側のコードを一切変えずに、エンドポイント側で統制を後付け・変更できるのがポイントです。
エージェントが普及すると、「1つのユーザーリクエストが裏で多数のモデル呼び出し・ツール実行に増幅される」「エージェントがどのツールを何のために呼んだのか追えない」という新しい統制課題が生まれます。Unity AI Gatewayは、5機能の土台の上にこれらへの答えを積み増しました。
| 機能 | 内容 |
|---|---|
| ハードなスペンドキャップ(Spend Caps) | コストの上限そのものを強制する。レート制限が「回数」の制限であるのに対し、スペンドキャップは「金額」で歯止めをかけ、上限到達で利用を止められる |
| スマートルーティング | リクエストをモデル間で自動的に振り分け、障害時はフォールバックする。コスト・品質・可用性のバランスをゲートウェイ側で最適化する |
| コンテキストに応じたサービスポリシー | 誰が・どのワークロードで使うかという文脈に応じて、適用する統制(使えるモデル・上限・ガードレール)を切り替える |
| 組み込みガードレール | PII露出やプロンプトインジェクションへの対策を、ゲートウェイ側の組み込み機能として提供する |
| 統合トレーシング | 全エージェント活動(モデル呼び出し・ツール実行・MCP呼び出し)を横断的にトレースし、「何がどう動いたか」を追跡可能にする |
| 利用状況・コストの一元可視化 | Databricksホストモデル、外部のフロンティアモデル、コーディングエージェント、カスタムエージェントまで横断して利用量とコストを1か所で見る |
📝 試験のポイント
「回数の上限」→レート制限、「金額の上限を強制」→スペンドキャップという区別を押さえましょう。また「エージェントがどのツールを呼んだか追跡したい」→統合トレーシング、「プロンプトインジェクション対策をアプリ側でなく基盤側で」→組み込みガードレールが対応します。
Unity AI Gatewayの大きな強みは、対象がDatabricks上のモデルに限らないことです。4-2で見た外部モデルエンドポイント(OpenAIなど外部プロバイダへのプロキシ)にも同じガバナンスを適用できるため、次が実現します。
💼 例:複数チーム・複数プロバイダの統制
マーケ部は外部プロバイダのモデル、開発部はDatabricks上のLlama系モデルを使いたいとします。それぞれをModel Servingのエンドポイント(外部モデル/Foundation Model API)として定義し、Unity AI Gatewayで「チームごとのレート制限とスペンドキャップ」「全リクエストのロギング」「共通のセーフティガードレール」を有効化すれば、どのプロバイダを使っていても統制は一元化されます。各チームがバラバラにAPIキーを持って直接呼ぶ構成と比べ、コスト管理・監査・安全性のすべてで優位です。
試験のシナリオ問題は「課題を読んで、それを解くゲートウェイ機能を選ぶ」形が典型です。次の対応表を確実に頭に入れてください。
| 課題(問題文のシグナル) | 対応する機能 |
|---|---|
| 「特定ユーザー/チームの過剰利用を防ぎたい」「クエリ数に上限を設けたい」 | ①レート制限 |
| 「部署ごとの利用量を把握してコストを配賦したい」「誰がどれだけ使ったか見たい」 | ②使用状況トラッキング(システムテーブル) |
| 「監査のためリクエスト/レスポンスを記録したい」「本番の入出力を後で品質評価に使いたい」 | ③ペイロードロギング(推論テーブル) |
| 「有害な出力を防ぎたい」「個人情報の混入を検出/ブロックしたい」「プロンプトインジェクション対策を基盤側で」 | ④ガードレール(セーフティ・PII・インジェクション対策) |
| 「プロバイダ障害でも止めたくない」「2つのモデルを比較しながら段階的に移行したい」 | ⑤トラフィックルーティング/フォールバック(スマートルーティング) |
| 「予算超過を構造的に起こさせたくない」「コストの上限額を強制したい」 | スペンドキャップ(Unity AI Gateway) |
| 「エージェントが何を呼んだか追跡したい」「AI利用のコストを横断的に1か所で見たい」 | 統合トレーシング/一元可視化(Unity AI Gateway) |
📝 試験のポイント
紛らわしい選択肢として「プロンプトで『個人情報を出力しないで』と指示する」「アプリ側で呼び出し回数を数える」などが並びます。プロンプト指示は強制力がなく、アプリ側実装は複数アプリに散らばって統制になりません。ゲートウェイ側で強制できるUnity AI Gatewayが常に優位、というのが解答の軸です。
✅ この節のまとめ
問1. 社内の複数チームがそれぞれLLMエンドポイントを利用しており、ある月に特定チームの大量クエリでコストが急増した。今後、ユーザー単位のクエリ数制限に加えて、チームごとの利用コストに上限額を設けて強制したい。最も適切な手段はどれか。
正解:B
クエリ数の制限はレート制限、コスト上限額の強制はスペンドキャップで、いずれもUnity AI Gatewayがゲートウェイ側で強制できます。Aは各アプリに実装が散らばり強制力・保守性に欠け、Cはプロンプトが利用者の行動を制限できないため無意味、Dは正当な利用まで止めてしまい課題に対応していません。
問2. コンプライアンス部門から「本番RAGボットの全リクエストとレスポンスを監査可能な形で保存せよ」と要請された。最も適切な方法はどれか。
正解:A
推論テーブル(ペイロードロギング)は、エンドポイントを通る入出力をDeltaテーブルへ自動記録する仕組みで、監査だけでなく第5章の品質評価・第6章の監視の元データにもなります。B・Cは網羅性・改ざん耐性・集中管理のいずれも満たさず、DはLLMに永続記録の機能がないため誤りです。
問3. 顧客向けチャットボットで、ユーザーが入力に含めてしまう個人識別情報(PII)への対策と、プロンプトインジェクションを含む有害な入出力の防止を、アプリのコードを変更せずに実現したい。最も適切なのはどれか。
正解:B
ガードレールはゲートウェイ側で入出力を検査・ブロックする強制的な仕組みで、アプリのコード変更は不要です。Unity AI GatewayではPII露出やプロンプトインジェクションへの対策が組み込みで提供されます。Aのプロンプト指示は強制力がなくインジェクションで回避され得ます。Cはユーザーの行動を保証できず、Dのモデル変更はPII・有害性対策の解決策ではありません。
問4. あるチームは外部プロバイダのモデルとDatabricks上のオープンソースモデル、さらに自作エージェントを併用している。これらすべての利用について、共通のレート制限・ロギング・コストの可視化を一元的に適用したい。適切なアプローチはどれか。
正解:B
Unity AI Gatewayの強みは、外部プロバイダのモデルも外部モデルエンドポイント経由で同じガバナンス層に載せられること、さらにエージェントやツールの活動まで横断して可視化・統制できることです。Aは統制が分断されて管理コストと抜け漏れが増え、Cは不必要に選択肢を狭め、Dはキーの分散と自己申告という統制の放棄でありセキュリティ・コスト管理の両面で不適切です。