Databricksで学ぶSystem Prompt・モデルパラメータ・Structured Output・Tool Callingの基本

2026年9月7日 19:09

📚 参考書籍

※この記事は書籍の一部をベースに再構成しています。もう少し踏み込んだ内容（設計や具体例）は書籍の中でまとめているので、気になる方はそちらもどうぞ。

Databricksでのプロンプト設計・RAG構築・モデル管理・ガバナンスを扱うAIエンジニアの入門決定版。
生成AIとデータエンジニアリングの橋渡しに必要な“実務の型”を体系化しています。
資格本ではなく、実務基盤としてAIを運用する力を育てる内容です。

AI Gatewayでつなぎ、Agent Skillsで企業の仕事を標準化し、Pipeline Factoryで量産し、MLflowで評価・改善する。
その一連のライフサイクルを、データパイプライン開発という具体的な題材を通して理解することが本書のゴールです。

Databricksで学ぶSystem Prompt・モデルパラメータ・Structured Output・Tool Callingの基本

System Promptとモデルパラメータ

生成AIの回答は、利用するモデルだけで決まるわけではありません。同じモデルを利用しても、System PromptやTemperature、最大出力トークン数などの設定によって、回答の内容や安定性は大きく変わります。

AI Playgroundでは、モデルを切り替えるだけでなく、System Promptやパラメータを変更しながら応答を比較できます。設定が固まった後は、その内容をNotebookやAPI実装へ移行します。(Databricks Docs)

System Promptでモデルの役割を定義する

System Promptは、モデルに対して役割、回答方針、制約などを与える上位の指示です。

ユーザーが入力する質問よりも前に、アプリケーション全体で共通するルールを設定します。

例えば、社内規程を回答するアシスタントでは、次のような内容を指定します。

社内文書に基づいて回答する
根拠がない場合は推測しない
回答には参照文書名を付ける
個人情報を出力しない
丁寧で簡潔な日本語を使用する

System Promptを設定することで、利用者ごとに異なる質問が入力されても、一定の役割と回答方針を維持しやすくなります。

ただし、System Promptだけでセキュリティを完全に担保できるわけではありません。データやToolへのアクセスはUnity Catalogの権限で制御し、入出力の検査やガードレールも組み合わせる必要があります。

Temperatureで回答の多様性を調整する

Temperatureは、モデルが次の単語を選択するときのばらつきを調整するパラメータです。

値を低くすると、可能性の高い表現が選ばれやすくなり、回答の一貫性が高まります。一方、値を高くすると、異なる表現やアイデアが選ばれやすくなります。

利用場面の目安は次のとおりです。

分類、情報抽出、JSON生成：低め
FAQ、社内問い合わせ、RAG：低めから中程度
キャッチコピー、企画案、文章作成：中程度から高め

業務システムで同じ入力に近い回答を求める場合は、Temperatureを低めに設定します。反対に、複数のアイデアを出したい場合は高めに設定します。

ただし、Temperatureを低くしても、生成結果が常に完全一致するとは限りません。モデルや提供方式によって挙動が異なるため、実際の評価データで確認する必要があります。

最大出力トークン数で回答量を制御する

最大出力トークン数は、モデルが1回の応答で生成できる長さの上限です。

値を小さくすると、応答時間やコストを抑えられますが、回答が途中で終了する可能性があります。値を大きくすると長い回答を生成できますが、レイテンシやトークンコストが増加します。

例えば、分類結果だけを返す処理と、詳細な調査レポートを作る処理では、必要な出力量が異なります。

Yes／No判定：小さく設定
JSONによる情報抽出：必要な項目数に合わせる
FAQ回答：数百トークン程度を起点に検証
長文要約やレポート：大きめに設定

最大出力トークン数は、文章の長さを正確に指定するものではありません。「200文字以内」といった業務上の条件は、System Promptでも明示し、出力後の検証を組み合わせます。

入力と出力の合計量に注意する

モデルが扱えるトークン数には上限があります。長い会話履歴や多数の検索結果を入力すると、出力に利用できるトークン数が少なくなる場合があります。

特にRAGでは、検索結果を大量に渡すのではなく、関連性の高いチャンクへ絞り込むことが重要です。

また、入力と出力が長くなるほど、レイテンシとコストも増加します。そのため、会話履歴の要約、不要な検索結果の除外、プロンプトの簡潔化などを検討します。

パラメータは組み合わせて評価する

モデルパラメータは、個別ではなく組み合わせて評価します。

例えば、Temperatureを高くし、最大出力トークン数も大きくすると、多様で長い文章が生成されやすくなります。一方、Temperatureを低くし、出力量を制限すると、定型的で簡潔な回答になりやすくなります。

AI Playgroundでは、同じ質問に対して設定だけを変更し、回答品質、形式の安定性、レイテンシ、トークン数を比較します。

実務では、まずSystem Promptで役割と制約を明確にし、その後にTemperatureと最大出力トークン数を調整するのが基本です。モデルの性能だけに頼らず、用途に合った設定を評価し、MLflowなどでプロンプトとパラメータのバージョンを記録することが重要です。

Structured OutputとTool Calling

生成AIの回答を業務システムへ組み込む場合、自由な文章だけでは扱いにくいことがあります。

例えば、問い合わせ内容から顧客名、商品名、問い合わせ種別を抽出してデータベースへ保存する場合、毎回異なる文章で返されると、後続処理で正しく読み取れません。

このような場面ではStructured Outputを利用します。一方、モデルに検索、計算、SQL実行などの外部処理を選択させる場合はTool Callingを利用します。

両者を簡単に整理すると、次のようになります。

Structured Output：モデルの回答形式を決める
Tool Calling：モデルが利用する処理を選ぶ

Structured Outputとは

Structured Outputは、あらかじめ定義したJSON Schemaに沿って、モデルの回答をJSON形式で生成させる仕組みです。

例えば、問い合わせから次の情報を抽出するとします。

{
"customer_name": "山田太郎",
"category": "配送遅延",
"priority": "high"
}

JSON Schemaでは、項目名だけでなく、データ型、必須項目、許可する値などを定義できます。

例えば、priorityにはhigh、medium、lowのいずれかだけを許可するといった制約を設定できます。

プロンプトに「JSONで回答してください」と書くだけでもJSONが返る場合はあります。しかし、括弧が不足したり、説明文が追加されたり、項目名が変わったりする可能性があります。

Structured Outputを利用すると、対応モデルに対してスキーマ準拠を要求できるため、通常のプロンプト指定よりも安定した構造化データを取得できます。(Databricks Docs)

Structured Outputの主な用途

Structured Outputは、モデルの結果を後続システムで処理する場面に向いています。

文書から氏名、日付、金額を抽出する
問い合わせをカテゴリや優先度に分類する
契約書から当事者や契約期間を取得する
商品説明を決められた項目へ分解する
APIのレスポンス形式を統一する

ただし、JSONとして正しいことと、内容が正しいことは別です。

モデルがスキーマに沿った値を返しても、抽出内容そのものが誤っている可能性があります。そのため、必須項目の確認、値の範囲チェック、元文書との照合などを組み合わせます。

Tool Callingとは

Tool Callingは、モデルに利用可能な関数やToolを提示し、ユーザーの要求に応じて必要なものを選択させる仕組みです。

例えば、Agentに次のToolを登録したとします。

search_documents：社内文書を検索する
get_sales_data：売上データを取得する
calculate_tax：税額を計算する

ユーザーが「先月の売上を教えてください」と質問すると、モデルはget_sales_dataが必要だと判断し、実行に必要な引数を構造化して返します。

Tool Callingでは、関数名、説明文、引数をJSON Schemaでモデルへ伝えます。Databricksの関数呼び出しはOpenAI互換形式に対応しており、Foundation Model APIsや外部モデルのServing Endpointで利用できます。(Databricks Docs)

モデル自身が処理を実行するわけではない

Tool Callingで重要なのは、モデルが外部処理を直接実行するわけではないことです。

基本的な流れは次のとおりです。

1. アプリケーションが利用可能なToolをモデルへ伝える

2. モデルが必要なToolと引数を選択する

3. アプリケーションやAgentがToolを実行する

4. 実行結果をモデルへ返す

5. モデルが最終回答を生成する

モデルが担当するのは、主に「どのToolを、どの引数で利用するか」という判断です。

そのため、Toolの説明文が曖昧だと、誤ったToolを選択する可能性があります。「データを取得するTool」ではなく、「指定した年月の商品別売上を取得するTool」のように、用途と引数を明確に定義します。

Structured OutputとTool Callingを組み合わせる

Structured OutputとTool Callingは、どちらか一方だけを選ぶものではありません。

例えば、問い合わせ対応Agentでは、次のように組み合わせられます。

1. Tool Callingで顧客情報検索Toolを選択する

2. Toolから顧客情報を取得する

3. モデルが回答案を生成する

4. Structured Outputで回答、参照情報、重要度をJSONとして返す

AI Playgroundでは、Tool Callingに対応したモデルを選択し、Unity Catalog Functionsなどを登録してAgentの動作を試せます。検証後はNotebookへエクスポートし、Agentとして実装・評価できます。(Databricks Docs)

整理すると、Structured Outputは「回答をどの形式で返すか」を制御し、Tool Callingは「どの処理を実行するか」をモデルに判断させる仕組みです。

両者を組み合わせることで、生成AIの柔軟な判断能力を活かしながら、業務システムで扱いやすい安定した入出力を実現できます。