第3章 アプリケーション開発 / 想定学習時間:30〜40分 / 最終確認:2026年8月

3-7. Foundation Model APIによるモデル呼び出し

🎯 この節の学習目標

1. Foundation Model API とは

Databricks の Model Serving は、自分で学習・登録したモデルだけでなく、基盤モデル(Foundation Model)をAPIとしてすぐに呼び出せる仕組みを提供しています。GPUのプロビジョニングやモデルのダウンロード・デプロイ作業なしに、ワークスペース内のエンドポイントとしてLLMを利用できるのが最大の利点です。しかも Unity Catalog の権限管理、監査ログ、Unity AI Gateway(旧 Mosaic AI Gateway)(4-4)といったガバナンス機構と統合されています。

提供形態は次の3つに大別されます。この区別は試験でもよく問われます。

提供形態内容向いている場面
pay-per-tokenDatabricks が運用する共有エンドポイントを、処理したトークン数に応じた課金で利用する。Meta Llama 系などの主要オープンモデルが最初から使えるPoC・検証、低頻度・不定期なワークロード。すぐ試したいとき
Provisioned Throughput専用のスループット(処理能力)を確保したエンドポイント。性能が保証され、ファインチューニング済みモデルもホストできる本番運用、高負荷・安定したトラフィック、レイテンシ/スループット保証が必要な場面
External ModelsOpenAI や Anthropic など外部プロバイダのモデルを、Databricks のエンドポイント経由で統一的に呼び出す。APIキーは Databricks 側で集中管理外部の商用モデルを使いつつ、認証・ガバナンス・レート制限を Databricks に集約したい場面

📝 試験のポイント

「PoC を素早く始めたい/たまにしか呼ばない → pay-per-token」「本番の高トラフィックで性能保証が必要 → Provisioned Throughput」「OpenAI などの外部モデルをガバナンス下で使いたい → External Models」という対応付けを即答できるようにしてください。コスト最適化の観点(4-7)とセットで問われます。

2. 呼び出し方法①:OpenAI互換クライアント

Databricks の Foundation Model API は OpenAI 互換の REST API を提供しているため、広く使われている openai パッケージのクライアントをそのまま使えます。base_url をワークスペースの serving-endpoints に向けるだけです。

💡 コード例:OpenAIクライアントでの呼び出し

from openai import OpenAI

client = OpenAI(
    api_key=DATABRICKS_TOKEN,  # Databricksのアクセストークン
    base_url="https://<workspace-host>/serving-endpoints"
)

response = client.chat.completions.create(
    model="databricks-meta-llama-3-3-70b-instruct",  # エンドポイント名
    messages=[
        {"role": "system", "content": "あなたは簡潔に答えるアシスタントです。"},
        {"role": "user", "content": "RAGとは何ですか?"}
    ],
    temperature=0.1,
    max_tokens=500
)
print(response.choices[0].message.content)

model には Databricks 上のサービングエンドポイント名を指定します。既存のOpenAI向けコードを最小の変更で移行できるのがこの方式の利点です。

3. 呼び出し方法②:SQL の ai_query() 関数

SQLから直接LLMを呼び出せるのが ai_query() 関数です。Delta テーブルの各行に対してバッチでLLM処理(要約・分類・抽出など)を適用する場面で特に便利で、データエンジニアリングのパイプラインに自然に組み込めます。

💡 コード例:ai_query() によるバッチ推論

SELECT
  review_id,
  ai_query(
    'databricks-meta-llama-3-3-70b-instruct',
    CONCAT('次のレビューを positive / negative / neutral のいずれかに分類してください: ',
           review_text)
  ) AS sentiment
FROM main.reviews.customer_reviews;

第1引数がエンドポイント名、第2引数がプロンプトです。テーブル全行への一括適用が1つのSQLで書けるため、「SQLだけでLLMをデータに適用したい」という要件の正解選択肢としてよく登場します。

4. 呼び出し方法③④:MLflow Deployments SDK と LangChain

4-1. MLflow Deployments SDK

MLflow の Deployments クライアントを使うと、Databricks のサービングエンドポイントを統一的なインターフェースで呼び出せます。

from mlflow.deployments import get_deploy_client

client = get_deploy_client("databricks")
response = client.predict(
    endpoint="databricks-meta-llama-3-3-70b-instruct",
    inputs={
        "messages": [{"role": "user", "content": "RAGとは何ですか?"}],
        "max_tokens": 500
    }
)

4-2. LangChain の ChatDatabricks

3-1〜3-2 で学んだ LangChain のチェーンに Databricks のエンドポイントを組み込むには、ChatDatabricks を使います。

from databricks_langchain import ChatDatabricks

llm = ChatDatabricks(
    endpoint="databricks-meta-llama-3-3-70b-instruct",
    temperature=0.1,
    max_tokens=500
)
answer = (prompt | llm | parser).invoke({"question": "RAGとは?"})

チェーン内のLLM部品としてそのまま差し込めるため、RAGチェーンやエージェント(3-9)の構築ではこの方式が標準的です。

呼び出し方法主な用途
OpenAI互換クライアント汎用。既存のOpenAI向けコードからの移行、アプリケーションコード
MLflow Deployments SDKMLflow中心のワークフロー、エンドポイントの統一的な操作
SQL ai_query()テーブルデータへのバッチ推論、SQLパイプラインへの組み込み
LangChain ChatDatabricksLangChainのチェーン・エージェントの部品として

5. 主要な推論パラメータ

どの呼び出し方法でも共通して指定できる主要パラメータを押さえます。1-4 のプロンプト設計と合わせて、出力の品質・形式・コストを制御する基本手段です。

パラメータ意味実務での指針
temperature出力のランダム性。低いほど決定的、高いほど多様分類・抽出・RAGの事実回答は低め(0〜0.2)、創作的な文章生成は高め
max_tokens生成する最大トークン数出力の上限を制御しコストと途中切れを管理。短い分類タスクでは小さく設定
top_p累積確率によるサンプリング範囲の制限temperature とどちらか一方を主に調整するのが一般的
stop生成を打ち切る文字列決まった区切りで出力を止めたいときに使用

📝 試験のポイント

「回答の一貫性・再現性を高めたい → temperature を下げる」「回答が途中で切れる → max_tokens を増やす(またはコンテキスト長を確認)」という対応はよく問われます。逆に「temperature を上げると事実性が上がる」といった選択肢は誤りです。

✅ この節のまとめ

練習問題

問1. チームが RAG アプリケーションの PoC を始めようとしている。呼び出し頻度は低く、まずは Llama 系モデルで検証したい。最も適切な提供形態はどれか。

  1. Provisioned Throughput エンドポイントを作成する
  2. pay-per-token の共有エンドポイントを利用する
  3. GPUクラスタを起動してモデルを手動でホストする
  4. External Models で OpenAI のモデルを登録する
解答と解説を見る

正解:B

PoC・低頻度のワークロードには、セットアップ不要でトークン数に応じた課金で使える pay-per-token が最適です。Aは専用スループットを常時確保するため低頻度の検証にはコスト過剰です。Cはインフラ管理の手間が大きく、Foundation Model API の利点を捨てています。Dは「Llama系で検証したい」という要件に合いません(External Models は外部プロバイダのモデル向け)。

問2. 本番環境で安定した高トラフィックが見込まれ、レイテンシとスループットの保証が必要なチャットアプリケーションをデプロイする。最も適切な提供形態はどれか。

  1. pay-per-token の共有エンドポイント
  2. Provisioned Throughput エンドポイント
  3. ノートブック上でモデルを直接ロードして推論する
  4. SQLの ai_query() をアプリから毎回呼び出す
解答と解説を見る

正解:B

Provisioned Throughput は専用の処理能力を確保するため、高負荷・本番ワークロードでの性能保証に適しています。Aの共有エンドポイントは手軽ですが、専用の性能保証が必要な本番高負荷には不向きです。Cはサービングインフラとしてスケーラビリティ・可用性を欠きます。Dの ai_query() はバッチのSQL処理向けであり、対話型アプリのリアルタイム呼び出し経路としては不適切です。

問3. Delta テーブルに保存された100万件の顧客レビュー全件に感情分類を適用したい。データエンジニアはSQLパイプラインの中でこれを完結させたい。最も適切な方法はどれか。

  1. Python でループを書き、1件ずつ OpenAI クライアントで呼び出す
  2. SQL の ai_query() 関数でエンドポイントを指定し、SELECT文で全行に適用する
  3. レビューを手動でエクスポートし、チャットUIに貼り付けて分類する
  4. LangChain の ConversationBufferMemory を使う
解答と解説を見る

正解:B

ai_query() はSQLからサービングエンドポイントを呼び出す関数で、テーブル全行へのバッチ推論をSQLだけで実現できます。Aは実装・運用の手間とスループットの面で非効率です(バッチ用途にはSQL/Spark経由が定石)。Cは規模的に非現実的です。Dは会話履歴の保持のための部品であり、バッチ分類とは無関係です。

問4. RAGアプリケーションの回答が呼び出しのたびに大きく変わり、事実に基づく一貫した回答が得られないという苦情がある。最初に調整すべきパラメータとして最も適切なのはどれか。

  1. temperature を下げる(例:0〜0.2)
  2. temperature を上げる(例:1.0以上)
  3. max_tokens を増やす
  4. stop パラメータを削除する
解答と解説を見る

正解:A

temperature は出力のランダム性を制御します。事実性・一貫性が求められるRAGの回答では低い値に設定するのが定石です。Bは逆効果で、多様性が増して回答のブレが大きくなります。Cのmax_tokensは出力の長さの上限であり、一貫性には直接影響しません。Dのstopは生成の打ち切り位置の制御で、回答のブレとは無関係です。