AIツール使用（Tool Use）とは？LLMが外部を呼ぶ仕組みと実装の判断基準を解説

AIツール使用とは、LLMに「どの関数をどんな引数で呼ぶか」だけを決めさせ、実際の実行はアプリケーション側が担う仕組みを指します。OpenAIが呼ぶFunction Callingと中身は同じで、Anthropicがtool useという語を使うため名前が二つ流通しました。実装で詰まるのは仕組みの理解ではなく、ツールの粒度と説明文、失敗したときの戻し方、危険な操作をどこで止めるかの三点です。この記事では主要3プロバイダで食い違う型、説明文の書き方で呼び出し率が動く理由、本番で出る5つの失敗型と復旧設計、そして見送るべき場面までを実装者向けに整理します。

まとめ｜AIツール使用の実体と実装前に決める3つの設計点

実体は役割分担です。モデルが出すのは「呼ぶツール名と引数」という構造化データだけで、通信も認証も実行もアプリ側に残ります。この境界を先に引いておくと、権限設計もエラー処理も置き場所が自動的に決まる。呼称はFunction Calling、Tool Use、Tool Callingのいずれも同じ仕組みを指し、MCPだけは層が違います。MCPはツールを配る側の標準規格で、モデルへ定義を渡して呼び出させる工程は残ります。

着手前に決めるのは3点です。第一に、ツールの粒度と説明文。説明文へ「いつ呼ぶか」まで書き切ったかどうかで呼び出し率は目に見えて変わる。第二に、失敗の戻し方で、実行に失敗した呼び出しもエラーとして会話へ返し、打ち切り条件は実行側のループに持たせます。第三に、危険操作の線引き。取り消せない操作には人の承認を挟み、認証情報はモデルの文脈へ一切載せません。この3点を決めずにPoCを本番へ持ち上げると、動くデモのまま費用と事故だけが積み上がります。

AIツール使用の定義とFunction Calling・MCPとの呼称と層の違い

同じものが三つの名前で語られ、層の違うMCPが同列に並べられているのが混乱の元です。

モデルが引数を決め実行はアプリ側が担う役割分担と1往復の流れ

ツール使用の1往復は4ステップで完結します。順番と、それぞれを誰が実行するかが要点です。

1. アプリがツール一覧（名前・説明・引数スキーマ）をリクエストへ同梱してモデルへ送る
2. モデルが呼ぶツール名と引数を構造化データで返し、応答は「ツール呼び出し待ち」の状態で止まる
3. アプリが引数を検証したうえで、実際の関数やAPIを自分の権限で実行する
4. 実行結果を同じ会話へ追記して再度モデルへ渡し、モデルが最終回答を書く

見落とされるのは、モデルが一度もネットワークへ出ていない点です。モデルの出力は「呼びたい」という宣言にすぎず、叩くかどうかを決めるのはアプリのコード。だからこそ権限も監査もアプリ側の責務になります。信用すべき対象は引数の中身であって、モデルそのものではありません。

Function CallingとTool Useは呼称違いで中身は同じ仕組み

2026年8月時点で流通している呼び名は主に三つ。OpenAIはfunction calling、Anthropicはtool use、実装フレームワークの多くはtool callingと書きます。指しているのは同じ仕組みで、モデルにJSON Schemaのツール定義を渡し、構造化された呼び出し要求を受け取る一点は共通。OpenAI APIに沿った具体的なコードはFunction Callingの実装解説で扱うため、本記事はプロバイダをまたいだ設計判断へ絞ります。

MCPは呼び出し規約ではなくツールを配る側の標準という層の違い

MCPをツール使用の代替と説明する記事がありますが、担当している層が違います。MCPはJSON-RPC上の規格で、サーバーが自分の持つツールを公開し、クライアントが tools/list で一覧を取り、tools/call で実行を頼む。つまり「どこからツール定義を仕入れるか」を標準化したものです。仕入れたあと、それをモデルのtools配列へ載せて呼び出させる工程は従来どおり残り、引数の検証も権限の判断も消えません。規格そのものの位置づけはMCPの解説にまとめています。

主要3プロバイダのツール定義と結果の返し方が食い違う具体箇所

概念が同じでも、書くコードは同じになりません。移植で確実に踏むのはフィールド名とロールの差です。

JSON Schemaで書くツール定義の必須項目と説明文の書き分け

どのプロバイダでも、ツール定義に入るのは実質4種類の情報です。

• 名前：動詞と対象で揃える。get_inventory のように、何をするかが名前だけで読める形にする
• 説明文：モデルが呼ぶかどうかを判断する唯一の材料。機能だけでなく呼ぶ条件を書く
• 引数スキーマ：JSON Schemaのオブジェクト型。各プロパティにも個別の説明を付ける
• 必須指定と追加禁止：required と additionalProperties を明示し、想定外のキーを塞ぐ

説明文は2種類を書き分けます。ツール自体は「いつ・何のために呼ぶか」、プロパティは「どんな値が入るか」。後者を省くと、日付の書式や識別子の桁数といった暗黙の前提をモデルが埋め合わせで補い、引数の幻覚の温床になります。

Anthropic形式とOpenAI形式で異なるブロック名と結果の返し方

2026年8月時点の主要な型を並べると、対応関係はこうなります。

移植で効くのは2箇所です。ひとつは引数の型で、Anthropic側の input はオブジェクトとして届く一方、OpenAI側の arguments はJSON文字列で届くため受け取り直後にパースが要ります。もうひとつは結果を返すロール。Anthropic系では tool_result ブロックをuserロールで返し tool_use_id で紐付けますが、OpenAI系は function_call_output という専用の型に call_id を添える形。抽象化レイヤを自作するなら、この2点を吸収すれば大半は共通化できます。

MCPサーバー経由で同じツールを配る場合に増える検査と監査の工程

MCP経由に切り替えると、ツール定義が自社コードの外から来ます。仕様2025-06-18版のツール定義は name・description・inputSchema に加え、outputSchema と annotations を任意で持ち、結果は content 配列と、構造化データを返す場合の structuredContent で構成されます。実行時のエラーは例外ではなく結果側の isError で示され、未知のツール名や引数不正はJSON-RPCのプロトコルエラーとして別経路で返る。この二段構えを取り違えると、失敗が握りつぶされて成功として先へ進みます。仕様自身も、クライアントは結果をモデルへ渡す前に検証し、タイムアウトを設け、呼び出しを監査ログへ残すべきだと書いています。接続の具体的な手順はMCPで外部ツールを接続する実装手順を参照してください。

並列呼び出しの結果を1つのメッセージに束ねて返す実装上の要点

対応モデルでは既定で、1回の応答に複数のツール呼び出しが同時に入ります。ここに落とし穴がひとつ。返すときは、すべての結果を1つのメッセージへまとめてください。呼び出しごとにメッセージを分けて返すと、モデルは「並列で呼んでも結果は別々に返る」と学習し、以後は1件ずつしか呼ばなくなります。往復が増え、遅くなり、費用も上がる。原因の見えにくい劣化なので、最初から束ねる実装にしておくのが安全です。

呼び出し精度を左右するツールの粒度と引数スキーマ設計の判断基準

精度はモデル選定より、定義側の変数でほぼ決まります。

ツールの説明文にいつ呼ぶかまで書き切ると呼び出し率が上がる理由

直近の高性能モデルは、コストの高い操作へ手を伸ばすことに慎重です。「本当に必要だと確信できるまで呼ばない」という振る舞いが既定のため、機能だけを書いた説明文では呼ばれません。効くのは、説明文にトリガー条件を直接書くこと。「在庫数を聞かれたとき、または見積書を作る前に呼ぶ」のように、呼ぶべき場面を名指しします。システムプロンプト側へ「必ずこのツールを使え」と書き足すより、ツール自身の説明文に条件を置くほうが素直に効く。ただし大文字で強調した命令を並べると、今度は呼ぶ必要のない場面まで呼びに行きます。強調は、実際に呼ばれなかった条件に対してだけ使ってください。

ツールを細かく割るか束ねて渡すかを決める判断軸と実務での件数の目安

粒度の判断は3つの軸で切れます。

• 引数の数：1ツールの引数が5〜7個を超えたら分割を検討する。分岐条件を引数で表現し始めた時点で粗すぎる
• 権限の単位：読み取りと書き込みを1つのツールへ同居させない。承認を挟む線引きができなくなる
• 往復コスト：細かく割りすぎると1タスクの往復が増える。連続して必ず一緒に呼ばれる操作は束ねる

実務では、1ツール＝1つの判断可能な操作、という粒度に落ち着くことが多くなります。

引数のスキーマ違反を厳密モードと列挙型で機械的に潰す設計手順

スキーマどおりの引数が返る保証は、主要プロバイダが機能として用意しています。ツール定義に厳密モードの指定を入れると、引数がスキーマへ確実に適合する。前提として、オブジェクトに additionalProperties の追加禁止指定と、全プロパティの required 指定が要ります。ただし再帰的な定義、数値の上下限、文字列の長さ制限などは扱えない場合があり、形は保証されても値域は保証されません。値域の検査はアプリ側に残す前提で設計してください。もっとも効果が大きいのは列挙型です。取りうる値が有限なら enum で列挙する。これだけで存在しない値を入れる余地が消えます。

ツール数が増えたときに定義を全部渡さず絞り込む方式とその判断

ツール定義はリクエストの先頭に置かれ、毎回入力トークンとして課金されます。数十個を常時渡す構成は、費用と選択精度の両方を削ります。対策は2方向。ひとつは遅延読み込みで、定義は登録しておくが文脈へは載せず、必要になった時点で差し込む方式。もうひとつは検索型のツール発見で、モデルが目的を問い合わせて該当するツールだけを受け取る方式です。ツール定義は前置きの先頭にあたるため、会話の途中で足し引きするとキャッシュ全体が無効になる点にも注意が要ります。会話中の増減を前提にするなら、キャッシュを壊さない仕組みがあるかを先に確認してください。

ツール使用が壊れる5つの失敗型と本番で効く復旧と打ち切りの設計

PoCでは出ず本番で必ず出る壊れ方には、型ごとに違う打ち手があります。

引数に存在しない値が入る幻覚と、アプリ側の検証層で止める設計

最も多いのがこれです。実在しない顧客ID、締め日のない日付、廃止済みの商品コードが引数に入る。原因は単純で、JSON Schemaは「文字列であること」は表現できても「その値が存在すること」は表現できないからです。厳密モードを入れても同じ。対策は、実行の直前に検証層を1枚挟むことです。存在しなければ実行せず、該当なしを結果として返してモデルに選び直させる。ここで例外を投げてアプリを落とすと、モデルは自力で修正する機会を失います。候補が有限なら列挙型で渡し、多いなら先に検索用のツールを呼ばせてIDを取得させてください。

呼ぶべきツールを取り違える選択誤りと説明文の書き直しで直す手順

似た名前と似た説明が並ぶと取り違えます。search_orders と list_orders が両方あり、説明文がどちらも「注文を取得する」なら、モデルに区別する材料はありません。直し方は3つ。名前を動詞と対象で揃えて重複を消す、説明文に「この場面では使わない」という排他の1行を入れる、役割が重なるツールは統合する。選択誤りの大半は、モデルの判断力ではなく説明文の情報不足に起因します。

同じ引数で呼び直し続ける無限ループを実行側で検知して止める方法

結果が空だったりエラーだったりすると、モデルは同じ判断へ戻り、同じ引数で呼び直します。放置すると数十回まで走り、プロンプトでは止まりません。実行側で直近の履歴を見て「同じツール名と同じ引数」の再送を検知し、その場で打ち切るのが確実です。あわせて、最大反復回数と費用の上限をループ側に持たせます。この打ち切り条件はツール使用の規定範囲ではなく、外側の制御構造が担う設計領域。反復と終了条件の設計はエージェントループの解説に、推論と行動を交互に並べる形式そのものはReActパターンの解説にまとめています。

結果をそのまま文脈へ戻して膨らむ問題と要約と退避の使い分け方

データベースの検索結果をそのまま返すと、数万文字が一気に文脈へ入ります。費用が跳ねるだけでなく、後続の判断も鈍る。効くのは3手です。まずツール側で返す列と件数を絞る。次に、大きな結果はファイルや一時ストレージへ退避し、モデルへはパスと要約だけ戻す。そして複数のツールを連鎖させる処理では、コード実行の中からツールを呼んで中間結果を文脈に載せない方式を検討します。3つ目は実装コストが高いので、1回の呼び出しで返る文字数の中央値を測り、前2つで足りるかを先に判断してください。

失敗した呼び出しをエラーとして返さないとモデルが直せない理由

ツール実行が例外で落ちたとき、結果を返さずに握りつぶす実装をよく見ます。モデル側から見ると呼び出しは成功したことになり、存在しない結果を前提に話が進む。正しい扱いは、失敗も結果として返すことです。エラーであることを示すフラグと、原因が読める短いメッセージを添える。「在庫APIが応答しませんでした」と返せば、モデルは別のツールを試すか、ユーザーへ状況を伝えます。並列呼び出しの一部だけが失敗した場合も同じで、失敗した1件を落とさず成功分とまとめて返してください。

危険操作を切り分ける権限設計と承認・監査をアプリ側に置く理由

事故が起きるのはモデルの判断ではなく、実行側の線引きが甘い箇所です。

操作が可逆かどうかでツールを分けて人の承認を挟む線引きの基準

基準は取り消せるかどうか、この一点で足ります。参照系は自動実行、書き込み・送信・削除・課金は人の承認を挟む。MCPの仕様も、安全性の観点からユーザーが呼び出しを拒否できる状態にすべきだと明記し、機微な操作では確認を求めるようクライアントへ推奨しています。承認画面には、ツール名だけでなく実際の引数をそのまま表示してください。「メールを送信します」では判断できず、宛先と本文が見えて初めて止められる。可逆性という単一の基準で機械的に振り分けるのが、運用が続く形です。

認証情報をモデルの文脈へ入れず呼び出しの外側で差し込む実装型

APIキーやトークンをシステムプロンプトや会話へ書く実装は避けてください。会話履歴として保存され、要約や圧縮にも取り込まれ、履歴取得のAPIから読み出せる状態になります。正しい型は、認証情報をアプリ側やプロキシ側に保持し、外向きのリクエストが出る直前に差し込むこと。モデルには「認証は済んでいる」という前提だけを渡します。この構造にしておけば、モデルが何を出力しても鍵は漏れません。

外部から来たツール定義と実行結果を信用しない前提で検査する範囲

MCPサーバーやサードパーティのツールを組み込むと、自社で書いていない説明文と結果がモデルの文脈へ流れ込みます。仕様は、ツールに付随する注記は信頼できるサーバー由来でない限り信用してはならないと定めている。実務ではもう一段厳しく、ツールの実行結果もユーザー入力と同じ扱いにして検査してください。検索結果やページ本文に「これまでの指示を無視して」という文字列が混ざる攻撃は実際に成立します。入力と出力の両方を検査する層の設計はAIガードレールの解説で扱っています。

呼び出し履歴を軌跡として残し障害時に原因へ辿り着くための設計

残すべきは5項目です。ツール名、引数、結果の要約、所要時間、失敗理由。これを1呼び出し1レコードで蓄積しておくと、障害時にどの引数で何が返ったかを追える。この軌跡はそのまま品質の測定にも使えます。呼び出しの正誤率、不要な呼び出しの割合、リトライ回数といった指標は、軌跡が残っていなければ計算できません。測定の設計はAIエージェント評価の解説に整理しています。ログは後付けが効かない領域なので、PoCの段階から入れておくほうが結局は安く済みます。

ツール使用を導入して効く業務と見送るべき場面を分ける採用条件

採用と見送りの境目を条件で言い切ります。

入力の揺れが大きく実行に副作用がある業務ほど効果が出る理由と例

効くのは3条件が揃う業務です。入力が自然文や書式のばらついた形で来ること、実行対象がすでにAPIとして叩けること、そして実行に副作用があること。たとえば問い合わせメールを起点に、在庫を照会し、条件を満たせば見積を作成して返信案まで用意する処理。揺れを吸収する部分はモデルが強く、確定した操作はAPIが確実にこなします。逆に副作用のない参照だけで完結するなら、検索と要約で足りることが多い。価値は「判断してから実行する」点にあり、実行が伴わないなら遅延と費用を払う理由が薄くなります。

手順を先に固定できる処理へツール使用を持ち込むと遅く高くなる

見送るべき場面もはっきりしています。第一に、手順が最初から確定している定型処理。帳票の変換、承認フローの進行、月次の集計。これらにツール使用を被せると、毎回モデルへ問い合わせる分だけ遅く高くなり、検証もしにくくなる。第二に、1〜2秒の応答が求められる画面。1往復ごとにモデル呼び出しが増えるため、体感速度は確実に落ちます。第三に、ツールが1つしかなく必ず呼ぶと決まっているケース。モデルに選ばせる意味がないので、アプリ側から直接呼んでください。「将来ツールが増えるかもしれないから」は採用理由になりません。増えた時点で入れれば済みます。

PoCから本番運用へ移す段階で外部へ相談すべき設計上の論点3つ

手元で動いたツール呼び出しを業務に載せる工程では、打ち切り条件と費用上限、権限と承認の設計、軌跡の保管と評価という3点が同時に必要になります。打ち切り条件をどこで判定するかは、計画をどの時点で作り直すかというAIエージェントのプランニングの設計と一体で決まります。いずれも対象業務の性質と既存システムの権限構造に依存する部分で、汎用のフレームワークが肩代わりしてくれる領域ではありません。社内に設計と運用の蓄積が薄いなら、AIエージェント開発の支援のように、業務のどの工程をモデルへ渡し、どの工程を確定した手順のまま固定するかの棚卸しから入ると、PoC止まりや過剰な自動化を避けられます。そもそもエージェントとして組むべきかという上流の判断は、AIエージェントとは何かの解説で全体像を押さえてから技術選定に降りると手戻りが減ります。

よくある質問

実装の相談で繰り返し挙がる質問へ答えます。

AIツール使用とFunction Callingは違うものですか？

同じ仕組みの別名です。ドキュメントを横断するときは名前で対応を取らず、tools配列に何を入れるか、モデルの出力がどのブロックに入るか、結果をどのロールで返すか、という3点で読み替えてください。

MCPを入れればツール使用の実装は不要になりますか？

不要にはなりません。仕入れた定義をモデルのtools配列へ載せ、返ってきた呼び出し要求を実行し、結果を会話へ戻す工程はそのまま残ります。楽になるのはツールの差し替えと再利用まで。むしろ外部サーバー由来の定義と結果を検査する工程が増えます。

ツールはいくつまで渡せますか？

プロバイダ上の上限は数十から百を超える水準まであり、実務で先に効くのは精度と費用のほうです。常時渡すのは10個前後までを目安にし、それを超えるなら遅延読み込みか検索型のツール発見へ切り替えるほうが安定します。

ツールの引数が間違っているときはどう返せばよいですか？

例外で処理を止めず、失敗を示すフラグを付けた結果としてモデルへ返してください。「顧客ID C-1234 は存在しません。検索用のツールで正しいIDを取得してください」のように次の一手まで示すと復旧が速くなります。

ツール使用にはどのモデルでも対応していますか？

主要プロバイダの現行モデルはおおむね対応しますが、小型モデルや古い世代では未対応か、精度が実用に届かないことがあります。出力書式をプロンプトで固定して解析する代替も取れるものの、書式崩れのリトライで結局は高くつきがちです。

関連記事

• ReActパターンとは？思考と行動を交互に回す仕組みと採用判断を実装目線で解説：呼び出しの前後に推論を挟む形式です。
• AIエージェントフレームワークとは？主要8種の比較と受託開発視点の選定基準【2026年版】：実装の土台を比較で整理しました。
• AIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】：MCP経由で配る場合の手順です。
• シングルエージェントとマルチエージェントの違い｜使い分けの判断基準とコスト・失敗モード【2026年版】：1体で捌けなくなった際の分割判断です。
• DSPy ReActV2とは｜ネイティブツール呼び出し前提の新ReActモジュール【2026年版】：呼び出し前提で作り直された実例です。