LLMにおけるツール使用とは、言語モデルがデータベースの検索、計算の実行、メッセージの送信などの外部操作を要求し、その返された結果を応答で利用できる仕組みです。通常、モデルがツールを選択して入力候補を提示し、呼び出しを実行するかどうかはモデルの周辺にあるソフトウェアが判断します。
これは、ツール呼び出しまたは関数呼び出しとも呼ばれます。これらの名称は、同じ仕組みを指すことが多いです。ただし、一部のプラットフォームでは、ツールを、開発者が定義した関数に加えて、ホスト型検索、コード実行、ファイル取得、コンピューター制御なども含む、より広いカテゴリーとして扱います。
役に立つメンタルモデル
モデルを、作業を実行する機械ではなく、呼び出し元だと考えてください。
モデルは、「get_order_statusを注文ID4821で呼び出す」のような構造化されたリクエストを生成できます。しかし、その出力は依然としてモデルの応答です。それだけでデータベースを検索することはありません。
周辺のアプリケーションがそのリクエストを受け取り、次に何をするかを制御します。呼び出しを拒否したり、ユーザーに確認を求めたり、権限を確認したり、コードを実行したり、エラーを返したりできます。ツールを実行する場合は、その結果を新しいコンテキストとしてモデルに返します。モデルはその結果を説明したり、別のツールを要求したりできます。
この分離が、ツール使用における中心的な事実です。
User request
↓
Model selects a tool and proposes inputs
↓
Application validates, authorizes, and executes
↓
Tool result returns to the model
↓
Model answers or requests another toolプロバイダーによっては、自社サーバー上で実行するホスト型ツールも提供しています。APIがループの一部を隠す場合でも、論理的な段階は変わりません。モデルが操作を要求し、実行システムがそれを実行し、結果が会話に入ります。
ツール使用の仕組み
1. アプリケーションが各ツールを記述する
ツール定義には通常、次の内容が含まれます。
- 名前（例：
get_order_status - いつ使用するかを説明する自然言語の説明
- 受け付ける入力
- 各入力の形式と型に関するルール
これらの入力ルールは、JSONスキーマで表現されることが多いです。スキーマは、order_idが必須の文字列であることを指定できます。説明はそのツールの意味をモデルに伝え、スキーマは呼び出しの形式を伝えます。
2. モデルがリクエストとツール定義を受け取る
モデルは、利用可能なツールの説明とともにユーザーのメッセージを検討します。通常どおり回答することも、1つのツールを要求することも、APIとアプリケーションが許可していれば複数のツールを要求することもあります。
ツールの選択は予測であり、保証された計画ではありません。モデルは間違ったツールを選んだり、必要な呼び出しを省略したり、形式は正しいが不適切な引数を提示したりする可能性があります。
3. モデルが構造化されたツール呼び出しを返す
通常の文章の代わりに、または文章とともに、機械可読な呼び出しが応答に含まれます。簡略化すると、次のようになります。
{
"name": "get_order_status",
"arguments": {
"order_id": "4821"
}
}プロバイダーのAPIは、これを異なるメッセージ型で表現し、後で返される結果を正しい呼び出しに対応付けられるよう識別子を付けます。正確なエンベロープは変わりますが、名前と入力という考え方は主要なAPIに共通しています。
4. アプリケーションが実行するかどうかを判断する
ここで、提示されたアクションが実際のアクションになるかどうかが決まります。
アプリケーションは引数を解析し、スキーマだけでなく、それ以上の条件も確認します。ログイン中のユーザーを検証し、アクセス規則を適用し、値を制限し、副作用に対する承認を要求し、利用できないツールを拒否することがあります。その後に初めて、ツール実行器がデータベース、API、計算機、ファイルシステムなどのシステムを呼び出します。
厳格なスキーマは構造上の信頼性を高められますが、認可システムではありません。"order_id": "4821"は有効なJSONであっても、他人の注文を指している可能性があります。
5. ツールの結果がモデルに戻される
アプリケーションは、元の呼び出しに関連付けた結果メッセージで出力を送信します。出力には、データ、エラー、または権限が拒否されたという記述が含まれる場合があります。
モデルはその結果を追加のコンテキストとして利用します。最終回答を生成したり、以前の仮定を修正したり、別のツール呼び出しを行ったりできます。複数ステップのAIエージェントは、停止条件に達するまでこのループを繰り返すことがあります。
具体例：注文を確認する
ある店舗が、読み取り専用のツールを1つ公開しているとします。
Name: get_order_status
Purpose: Return shipping information for an order the current user owns
Input: order_id (required string)ユーザーが次のように尋ねます。
注文4821はどこにありますか？
モデルは次のように要求します。
{
"name": "get_order_status",
"arguments": {
"order_id": "4821"
}
}何かを検索する前に、アプリケーションは現在のセッションを確認します。ユーザーが注文4821の所有者であれば、検索を実行して次を返します。
{
"status": "shipped",
"estimated_delivery": "Friday"
}これでモデルは、「注文4821は発送済みで、金曜日に到着する予定です」と回答できます。
所有者の確認に失敗した場合、アプリケーションは検索を実行したり、ステータスを明らかにしたりしてはいけません。権限エラーを返し、モデルは非公開データを露出させずにそれを説明できます。
モデルの呼び出しは、所有権を証明するものではありません。ツールスキーマは有効なリクエストを記述し、実際のルールを適用するのはアプリケーションです。
ツール使用が重要な理由
ツール使用により、言語モデルはテキスト生成だけでは得られない能力に、制御された形でアクセスできます。
- 最新または非公開のデータ：ツールは、現在の情報や、モデルの学習データに一度も含まれていなかったデータを取得できます。
- 正確な処理：計算機、データベースクエリ、プログラムは、もっともらしい推測に依存すべきでない作業を実行できます。
- 実際のアクション：ツールは、レコードの作成、メッセージの送信、予定の登録、その他のソフトウェアの操作を行えます。
- 既存システム：ツールは、自然言語のリクエストを既存の業務APIへの呼び出しに変換できます。
- 複数ステップの作業：ある呼び出しの結果が、次の呼び出しを導くことがあります。
ツール使用によってモデルの限界がなくなるわけではありません。一部のタスクを、それに適したシステムへ移し、確率的な意思決定と決定論的なソフトウェアとの間にインターフェースを作るのです。
信頼性と安全性は周辺システムに依存する
モデルの出力がスキーマに適合しているからといって、信頼できる命令の発信元になるわけではありません。本番環境でのツール使用には、モデルの周囲に制御機構が必要です。
形だけでなく意味を検証する。識別子、範囲、必要な状態、業務ルールを確認します。構造検証だけでは、提案された取引がユーザーの依頼に合っているかどうかを判断できません。
実行時に認可する。アプリケーションが保持する身元情報と権限を使います。ユーザーIDやロールをツール引数に入れることで、モデル自身にアクセス権を付与させてはいけません。
各ツールの権限を制限する。範囲を限定したget_order_statusツールは、汎用データベースツールより制御しやすくなります。リスクが異なる場合、読み取り専用ツールと書き込みツールは分けるべきです。
ツールの出力を信頼できないデータとして扱う。外部コンテンツは誤っている可能性があり、モデルの誘導先を変えようとするテキストを含むこともあります。返された文書は検査すべき情報であり、ユーザーの依頼やシステムのルールに取って代わる新たな権威ではありません。
副作用を意図的に扱う。メッセージの送信や返金の実行は、ステータスの検索とは異なります。機密性の高いアクションには、確認、重複実行を防ぐ冪等性の保護、監査記録が必要になる場合があります。
失敗を明確に返す。タイムアウト、利用できないサービス、拒否された権限、無効な引数は、明示的なツール結果にするべきです。そうしないと、モデルが空白を埋めるために成功を捏造する可能性があります。
よくある誤解
「LLMが私のAPIを呼び出した」
通常は、LLMがリクエストを生成し、アプリケーションがAPIを呼び出しています。モデルがツールを「呼び出した」という表現は簡便な略称ですが、実行とセキュリティの境界を隠してしまいます。
「関数呼び出しとツール呼び出しは常に異なる」
開発者が定義した関数については、プロバイダーやフレームワークが両方の用語を同義に使うことがよくあります。違いが現れるのは、プラットフォームがツールを、関数に加えて検索やコード実行などの組み込み機能も含む包括的な用語として使う場合です。普遍的な区別を仮定せず、プラットフォームの分類を確認してください。
「有効なスキーマなら正しい呼び出しになる」
スキーマは、文字列、数値、リスト、オブジェクトを要求し、形式が不正な出力を拒否できます。しかし、モデルが正しいツールを選んだか、正しい値を推測したか、業務ルールを守ったかは保証できません。
「ツールを追加すればエージェントになる」
ツール使用は能力です。エージェントは、意思決定、実行、結果の観測、関連状態の保持、ループの反復、停止を行える、より大きなシステムです。単発の構造化された呼び出しは同じ仕組みを使っていても、自律的なワークフローになるわけではありません。
「ツールの結果は必ず真実である」
モデルは誤った結果を忠実に要約することもあります。ツールの信頼性、データの鮮度、アクセス制御、悪意あるコンテンツへの耐性は、言語モデルだけでなくシステム全体の特性です。
ツール使用のAIシステムにおける位置付け
ツール使用は、言語モデルとその周辺システムとの境界に位置します。
モデルは言語を解釈し、構造化された次のステップを提案します。アプリケーションはツール定義を提供し、会話状態を保持し、呼び出しを検証し、権限を管理し、操作を実行し、観測結果を返します。ツールは限定された能力を提供します。エージェントはこの構成を繰り返し利用して、より大きなタスクを遂行できます。
このため、ツール使用の品質はモデルだけの特性ではありません。明確なツール説明、区別しやすいスキーマ、実行制御、有用なエラーメッセージ、適切な停止ルールのすべてが、システムが機能するかどうかに影響します。
次に読むもの
「AIエージェントとは？」では、ツール呼び出しが状態と停止ルールを備えた、計画・実行・観測の反復ループの一部になる仕組みを説明します。「AIハーネスとは？」では、呼び出しを検証して実行するソフトウェアを説明します。その後、「AIモデル・チャットボット・ハーネス・エージェントの違い」を読んで、より広いシステムの中でツール使用がどこに位置するかを確認してください。