Tool Useとは
Tool Use(ツールユース)とは、LLM(大規模言語モデル)が自身の「頭の中」だけで回答を完結させず、外部の関数・API・データベースなどを必要に応じて呼び出して処理を実行する仕組みのことです。天気予報の取得、社内データベースの検索、電卓の計算、メール送信など、モデルが苦手な正確な計算や最新情報の取得を外部ツールに委ねることで、実用的なAIエージェントを構築できます。
身近な例えで言うと、料理人がレシピ(LLMの知識)だけでは作れない料理に、電子レンジやオーブン(外部ツール)を使うのと同じです。レシピを知っているだけでは作れない料理があるように、LLMも「今日の天気」「社内の売上データ」「最新のニュース」を直接知ることはできないので、ツール(API)を呼び出して情報を取得するのです。
Tool Useの読み方
ツールユース
ツール ユース(スペース入り)
Function Calling(ファンクションコーリング)— ほぼ同義で使われる別名
日本のエンジニアの間では「ツールユース」と読まれるのが一般的です。OpenAIの界隈では「Function Calling(ファンクションコーリング)」という別名で呼ばれることが多く、両者はほぼ同義として使われています。ここが重要なポイントですが、Anthropicは「Tool Use」、OpenAIは「Function Calling」と名称を使い分けており、現在のAPIではどちらも内部的に同じ機能を指していると考えて差し支えありません。
Tool Useの仕組み
Tool Useは、LLMが「自分が回答するのに必要なツール」を判断し、そのツールの実行を要求し、実行結果を受け取って最終回答を作るという複数ターンの対話で成立します。実務では、このサイクルを理解しないとデバッグできません。
Tool Useのライフサイクル
(name, input_schema)
+ 質問
(引数JSON生成)
(外部API呼び出し)
(tool_result)
(自然言語)
ステップ①〜②: ツール定義とリクエスト
開発者はまず、LLMに使わせたいツールをJSON Schema形式で定義します。ツール名・説明・入力スキーマを明確に書くことが精度に直結します。「何をするツールなのか」「いつ呼ぶべきか」をdescriptionに書かないと、LLMは適切に選べません。
ステップ③: tool_use応答
LLMが「このツールを使いたい」と判断した場合、通常のテキスト回答ではなく、tool_use(Anthropic)またはtool_calls(OpenAI)ブロックを返します。中には呼び出したいツール名と、引数(JSON)が含まれます。
ステップ④〜⑥: 実行とフィードバック
アプリ側でツールを実行し、結果をLLMにtool_resultとして返します。LLMは結果を受け取って自然言語の最終回答を生成します。エージェントが複雑な場合は③〜⑤を複数回繰り返すことも多く、Claude Code等のエージェントは数十回以上のツール呼び出しをこなします。
Tool Useの使い方・実例
ここでは実際にAnthropic APIでTool Useを使う最小構成を示します。気象データを返す架空のget_weatherツールを定義し、ユーザーの質問に応じてClaudeが呼び出す例です。
import anthropic, json
client = anthropic.Anthropic()
tools = [
{
"name": "get_weather",
"description": "指定された都市の現在の天気を取得する。日本国内の主要都市のみ対応。",
"input_schema": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "都市名(例: 東京、大阪)"}
},
"required": ["city"]
}
}
]
messages = [{"role": "user", "content": "東京の天気を教えて"}]
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
tools=tools,
messages=messages,
)
# Claudeがツールを使いたい場合、stop_reason="tool_use"が返る
if resp.stop_reason == "tool_use":
tool_use = next(b for b in resp.content if b.type == "tool_use")
tool_name, tool_input = tool_use.name, tool_use.input
print(f"Claudeは{tool_name}を{tool_input}で呼び出したい")
# ここで実際のAPI呼び出しを行う(略)
result = {"city": tool_input["city"], "temp_c": 18, "condition": "晴れ"}
# 結果をClaudeに返す
messages.append({"role": "assistant", "content": resp.content})
messages.append({
"role": "user",
"content": [{
"type": "tool_result",
"tool_use_id": tool_use.id,
"content": json.dumps(result, ensure_ascii=False)
}]
})
final = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
tools=tools,
messages=messages,
)
print(final.content[0].text)
OpenAIでの書き方との比較
OpenAIでは「Function Calling」または「Tools」として同じ機能を提供しています。JSON Schemaでツールを定義する点は共通ですが、レスポンスのブロック構造が少し異なります。フレームワーク(LangChain、LlamaIndex等)を使えばこの違いを吸収できます。
Tool Useのメリット・デメリット
メリット
- 最新情報の取得: 学習データ以後の情報(株価、天気、ニュース)にアクセス可能
- 正確な計算: LLMが苦手な数値計算を電卓APIや数式処理ライブラリに委譲
- 実行可能なエージェント: メール送信、ファイル操作、DB更新など「動作」ができる
- ハルシネーション低減: 公式データソースを参照させることで根拠ある回答になる
デメリット・注意点
- 遅延とコスト: 複数ターンの通信でAPI利用料と応答時間が増える
- セキュリティリスク: 外部に副作用を起こすツール(送金等)は特に検証が必要
- 引数の取り違え: LLMが誤った引数を渡す場合があり、アプリ側でバリデーションが必須
- プロンプトインジェクション: ツールの出力に悪意ある命令が混じるとLLMが誤動作する可能性
Tool UseとRAG(検索拡張生成)の違い
どちらも「LLMに外部情報を使わせる」技術ですが、動く仕組みが違います。技術選定ではこの違いが重要です。
| 項目 | Tool Use | RAG |
|---|---|---|
| 呼び出し主体 | LLM自身(判断して呼ぶ) | アプリ側(事前に検索) |
| 対象 | 任意の関数・API | ドキュメント・埋め込み検索 |
| 代表用途 | エージェント、自動化 | 社内ナレッジQ&A |
| 相互関係 | RAG検索をツール化して組み合わせ可能 | Tool Useから呼ばれる一機能になりうる |
よくある誤解
誤解1: Tool Useを使うとLLMが直接APIを叩いている
違います。LLMは「このツールをこの引数で呼んでほしい」というJSONを返すだけで、実際のAPI呼び出しはアプリ側で行います。安全性はアプリ側の責任です。
誤解2: Function CallingとTool Useは別物
ほぼ同じです。OpenAIは歴史的経緯で「Function Calling」と呼び続けていますが、機能としてはAnthropicの「Tool Use」と同等。最近はOpenAIもtools引数を使うため、境界は薄れています。
誤解3: ツール定義を書けばLLMが必ず呼ぶ
違います。LLMは「今はツールが不要」と判断すれば呼ばずに回答します。強制したい場合はtool_choiceパラメータで指定します。
実務での活用シーン
- AIエージェント: Claude Code等がファイル操作・シェル実行を行う基盤
- カスタマーサポート: 顧客情報DB検索ツール、返品申請ツールを呼ぶボット
- 社内ワークフロー自動化: Slack通知・Googleカレンダー登録・Notion更新をAIが実行
- データ分析アシスタント: SQL実行ツールや可視化ツールを呼び出す分析補助AI
- 調査エージェント: Web検索ツール・PDF読み込みツールで論文要約を行う
- IoT・ロボット制御: センサー値取得・アクチュエータ制御をツールとして公開
Tool Useに関するよくある質問(FAQ)
Q1. Tool Useは全てのClaudeモデルで使えますか?
A. Claude 3以降の主要モデル(Haiku/Sonnet/Opus)で利用可能です。最新の対応状況は公式ドキュメントを確認してください。
Q2. 料金はどう計算されますか?
A. ツール定義はプロンプトの一部として入力トークンに含まれ、通常の料金が適用されます。複数ターンの会話は各ターンが課金対象です。
Q3. 並列で複数ツールを呼べますか?
A. はい。ClaudeもOpenAIも1回のアシスタント応答で複数ツールを同時に呼び出せます(parallel tool use)。
Q4. ツールのdescriptionはどれくらい書くべきですか?
A. 短すぎるとLLMが誤用します。用途・呼ぶべきタイミング・呼ばないケースを明記し、100〜500字程度を目安にしてください。
Q5. 悪意ある入力でツールを誤実行しない対策は?
A. アプリ側で引数バリデーション、書き込み系ツールには承認ステップ、ログ監視、権限制限(最小権限原則)を組み合わせて使います。
まとめ
- Tool UseはLLMが外部の関数・APIを呼び出して応答を完成させる仕組み
- OpenAIの「Function Calling」とほぼ同義
- LLMは呼び出し要求(JSON)を返すだけで、実行はアプリ側の責任
- 最新情報取得・正確な計算・エージェント構築に必須
- セキュリティとバリデーションはアプリ設計で担保する
Tool Useの実装パターンとエンタープライズ運用
スキーマ設計の勘どころ
Tool Useの精度は、ツール定義のJSON Schema品質に強く依存します。
実務では、パラメータ名をドメイン語彙と揃え、descriptionに「いつ呼ぶべきか/いつ呼ぶべきでないか」を両方書くことがポイントです。
注意しなければならないのは、description を曖昧に書くとLLMが誤った状況でツールを呼び出してしまう点です。
覚えておきたいのは、enum型を使える場面では積極的に使い、フリーテキスト入力は最小化することで誤作動を減らせるということです。
重要です。スキーマは一度書いたら終わりではなく、実運用ログを見て継続的に改善するものだという認識を持つべきです。
エラーハンドリングとリトライ戦略
外部APIを叩くツールは必ず失敗します。
実務では、LLMに「失敗メッセージを分類して、リトライ可能ならリトライ、不可ならユーザーに報告する」という行動方針を学習させる必要があるポイントです。
具体的には、tool_use_result にHTTPステータスコードとエラー本文を構造化して返し、LLMが状況を判断できるよう設計します。
注意しなければならないのは、無限リトライでコストが膨張するリスクで、実務では最大リトライ数(3〜5回)をツール側で強制するのが扱いやすいです。
並列ツール呼び出しとレイテンシ削減
Claudeのparallel tool useは、独立したツール呼び出しを同時に行うことでレスポンス時間を大幅に短縮できる機能です。
実務では、顧客情報検索・注文履歴取得・在庫確認を同時に走らせてから最終回答を生成するような構成が扱いやすいポイントです。
覚えておきたいのは、並列化できるのは「互いに依存しないツール呼び出し」に限られる点です。
重要です。逐次実行が必要な業務ロジックを無理に並列化するとデータ不整合の原因になるため、依存関係の整理を最初に行うべきです。
コストとセキュリティの両立
Tool Useはトークン消費が大きい処理です。tool_useとtool_resultでやり取りするたびに入出力トークンが積み上がるため、ツール応答のサイズを抑える設計が重要です。
実務では、巨大なデータを返すツールは要約付きの縮約フォーマットで返し、必要時のみ詳細版を再取得する2段構成にするのが扱いやすいです。
注意しなければならないのは、個人情報や機密データをツール応答に含める場合は、PII検出・マスキングを必ずツール層で行うべきだという点です。
参考文献・出典
📚 参考文献・出典
- ・Anthropic「Tool use (function calling)」 https://docs.anthropic.com/claude/docs/tool-use
- ・OpenAI「Function calling」 https://platform.openai.com/docs/guides/function-calling
- ・Google「Gemini API Function Calling」 https://ai.google.dev/docs/function_calling
- ・Anthropic「Model Context Protocol」 https://docs.anthropic.com/claude/docs/model-context-protocol
🌐 English version available
This article is also available in English for global readers.





































コメントを残す