Databricks Certified Generative AI Engineer Associate 教科書
第3章 アプリケーション開発(Application Development, 30%)
🎯 この節の学習目標
3-1 以降で扱ってきたチェーンは、処理の順序が開発者によって固定されています。これに対してエージェント(agent)は、LLM自身が「次にどのツールを使うか」を実行時に判断します。あらかじめ決められない多様なリクエストに対応できる反面、判断を誤るリスクもあるため、判断材料となるツール定義の品質が決定的に重要になります。
ツール(tool)とは、LLMが呼び出せる外部機能のことです。代表的な例:
ツールをLLMに提示するときの定義は、次の3要素で構成されます。
| 要素 | 役割 | ポイント |
|---|---|---|
| 名前(name) | ツールの識別子 | 機能が伝わる簡潔な名前(例:search_product_docs) |
| 説明(description) | LLMが「いつこのツールを使うべきか」を判断する材料 | 最重要。何をするか・いつ使うか・何を返すかを具体的に書く。説明の質がエージェントの精度を決める |
| 引数スキーマ(parameters) | 渡すべき引数の名前・型・説明を JSON Schema で定義 | 各引数にも説明を付け、LLMが正しい値を構成できるようにする |
💡 コード例:ツール定義(JSON Schema)
tools = [{
"type": "function",
"function": {
"name": "search_product_docs",
"description": "製品マニュアルから関連情報を検索する。"
"製品の仕様・使い方・トラブルシューティングに関する"
"質問に答えるときに使う。関連文書の抜粋を返す。",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "検索クエリ。ユーザーの質問の要点を表す短い文"
}
},
"required": ["query"]
}
}
}]説明が「ドキュメントを検索する」だけだと、LLMはこのツールを使うべき場面を判断できません。「いつ使うか」まで書くのが良い定義です。
📝 試験のポイント
「エージェントが適切なツールを選択できない。まず何を改善すべきか?」という問題では、ツールの説明(description)を具体的に書き直すが正解の軸になります。モデルの変更やファインチューニングより先に、判断材料である説明の改善を検討します。
エージェントの実行は、function calling(tool calling)を使った次のループで進みます。推論(Reasoning)と行動(Acting)を繰り返すことから ReAct パターンと呼ばれます。
search_product_docs を {"query": "..."} で呼べ」という構造化された指示。LLMがツールを直接実行するわけではないポイントは、LLMの役割は「どのツールをどの引数で呼ぶか」の判断とJSON出力までであり、実行の主体はアプリケーション側だということです。だからこそ、実行前のバリデーションや権限チェック(ガードレール)を挟み込めます。
Databricks では、Unity Catalog に登録した関数(UC Functions)をそのままエージェントのツールとして利用できます。SQLまたはPythonで定義した関数が catalog.schema.function_name の3レベル名で管理され、次の利点があります。
💡 コード例:UC関数の定義とツール化
-- 1. Unity Catalog に関数を登録(SQL)
CREATE FUNCTION main.tools.convert_temp(temp_f DOUBLE)
RETURNS DOUBLE
COMMENT '華氏温度を摂氏に変換する'
RETURN (temp_f - 32) * 5 / 9;# 2. Python側でエージェントのツールとして読み込む
from databricks_langchain import UCFunctionToolkit
toolkit = UCFunctionToolkit(
function_names=["main.tools.convert_temp"]
)
tools = toolkit.tools # LangChainエージェントにそのまま渡せる関数の COMMENT や引数定義が、ツールの説明・スキーマとしてLLMに提示されます。ここでも「説明の質」が効いてきます。
1体のエージェントに多数のツールを持たせると、ツール選択の精度が下がっていきます。そこで、役割別のエージェントに分割し、上位のエージェントが振り分ける構成が使われます。
Databricks では、Agent Bricks の Multi-Agent Supervisor がこのスーパーバイザーパターンをマネージドに構成する機能として提供されています。各担当エージェント(Genieスペースや既存のエージェントエンドポイントなど)を束ね、振り分けを自動化します。
| 指針 | 理由 |
|---|---|
| ツールは少数精鋭にする | 選択肢が多いほどLLMの選択精度が下がる。似た機能のツールは統合する |
| 説明を明確に書く | 説明はLLMの判断材料そのもの。「何を・いつ・何が返るか」を具体的に |
| 最小権限にする | ツールはエージェントに与えた実行能力。データ削除など危険な操作は持たせず、必要最小限のアクセス権で動かす(セキュリティは第6章) |
✅ この節のまとめ
問1. エージェントに検索ツールとSQL実行ツールを持たせたが、データ集計の質問に対しても検索ツールばかりが選択されてしまう。最初に行うべき改善はどれか。
正解:B
ツールの説明はLLMがツール選択を判断する唯一の材料であり、選択ミスの第一の疑いどころです。「集計・件数・数値の質問にはSQL実行ツールを使う」のように使いどころまで書き分けます。Aのモデル変更はコストが大きく、説明改善より後の手段です。Cは要件(データ集計への対応)を放棄しています。Dはランダム性を上げるだけで、正しい判断に導く根拠を与えません。
問2. function calling におけるLLMの役割として正しいのはどれか。
正解:B
LLMの出力はあくまで「このツールをこの引数で呼びたい」という構造化データ(JSON)であり、実際の実行はアプリケーション(エージェントのランタイム)が担います。この分離があるからこそ、実行前の検証や権限制御を挟めます。Aは実行主体の誤解、C・Dは function calling の仕組みとは別の話です。
問3. 組織内の複数のエージェントから共通のツール(為替換算などのビジネスロジック)を、アクセス権限の管理と監査が効いた形で再利用したい。Databricks 上で最も適切な方法はどれか。
正解:B
Unity Catalog 関数は3レベル名で一元管理され、権限制御・監査・再利用がガバナンス下で実現できます。Aはコードの重複で保守性が下がり、権限管理もできません。CはLLMがコードを実行できないうえ、セキュリティ的にも不適切です。Dは社内ロジックの公開リスクがあり、アクセス権限・監査の要件も満たしません。
問4. 「社内文書の検索」「売上データの分析」「議事録の要約」という性質の異なるリクエストを1つの窓口で受けるアシスタントを作る。ツールが増えて単一エージェントの精度が落ちてきた場合の適切な設計はどれか。
正解:B
ツールが多く役割が異なる場合は、役割別エージェント+スーパーバイザーのマルチエージェントパターンが定石です(Databricks では Agent Bricks の Multi-Agent Supervisor が該当)。Aはツール選択肢の過多という根本原因を解消しません。Cは外部データへのアクセスができず要件を満たせません。Dはユーザー体験を損ない、「LLMが判断する」というエージェントの利点を放棄しています。