Skip to Content
Docs01. 基礎概念ツール使用(Tool Use / Function Calling)
初級tool-usefunction-callingmcp更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

ツール使用(Tool Use / Function Calling)

この記事の目的

ツール使用の仕組みを正しく説明できるようになります。特に「モデルはツールを実行しない」という事実の設計上の意味を理解し、ツールの粒度と結果の返し方を自分で設計できる状態がゴールです。

対象読者

  • ツール使用型の Agent を初めて実装するアプリケーションエンジニア
  • ツールの設計(何をツールにするか、結果をどう返すか)に責任を持つエンジニア

前提知識

本文

概要: モデルはツールを「実行しない」

ツール使用(tool use)とは、LLM に利用可能な機能の一覧(名前・説明・入力スキーマ)を渡し、モデルが「この機能をこの引数で呼びたい」という構造化された要求を出力し、実行はアプリケーション側が行って結果をモデルに返す仕組みです。関数呼び出し(function calling)とも呼ばれ、同じ機構を指します。

「モデルは実行要求を出すだけで、実行しない」— この一点が安全設計の土台です。以下のアプリ実行型では、実行の手前に自社のコードが挟まるため、検証・権限チェック・人間の承認を置けます。プロバイダー実行型にも同じ制御点があるとは限りません。

ツール使用(Tool Use / Function Calling): 概要: モデルはツールを「実行しない」の図ツール使用(Tool Use / Function Calling): 概要: モデルはツールを「実行しない」の図
ツール使用(Tool Use / Function Calling): 概要: モデルはツールを「実行しない」の図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

ツール使用(Tool Use / Function Calling): 概要: モデルはツールを「実行しない」の図ツール使用(Tool Use / Function Calling): 概要: モデルはツールを「実行しない」の図

実行主体と制御点を区別する

方式実行主体制御点
アプリ実行型(function calling・自社 MCP クライアント)自社アプリが要求を検証して実行引数・実効権限・承認を自社コードで強制
プロバイダー実行型(組み込みツール・API 経由のリモート MCP)プロバイダー基盤がツールや接続先を呼ぶ許可ツール・承認設定・資格情報スコープ・送信先を製品機能で制限

OpenAI のリモート MCP は allowed_tools と require_approval による制御を提供し、承認要求への応答をアプリが返せます(2026-10-03 確認)。設定の有無を確認せず独自の承認ゲートを置けると仮定しません。必要な承認を実行直前に強制できない副作用はアプリ実行型へ置きます。資格情報の最小化と外部送信の制限はどちらの方式にも必要です。

詳細: ツール定義の 3 要素

要素役割設計のポイント
名前モデルが要求で指定する識別子動詞 + 対象で具体的に(search_expenses)
説明文モデルが「いつ使うか」を判断する唯一の材料プロンプトの一部として書く。用途・制約・使わない場面まで
入力スキーマ引数の構造(JSON Schema)各引数に説明と形式例を付ける

説明文の質がツール選択の精度を直接決めます。定義例:

{
  "name": "search_expenses",
  "description": "社員の経費精算履歴を検索します。精算の状況・金額・日付の照会に使います。経費の新規申請や修正はできません(照会専用)。",
  "input_schema": {
    "type": "object",
    "properties": {
      "employee_id": { "type": "string", "description": "社員 ID(例: E12345)" },
      "month": { "type": "string", "description": "対象月。YYYY-MM 形式(例: 2026-06)" }
    },
    "required": ["employee_id", "month"]
  }
}

詳細: 結果の返し方も設計対象

ツールが返す内容は、そのままモデルの「観測」になります。

  • 成功時: モデルの判断に必要なフィールドに絞って返します。生 API レスポンスの全文ダンプはコンテキストを圧迫し、重要な値を埋もれさせます
  • 失敗時: 「何が悪かったか」「どうすればよいか」を含めます(例: 「month は YYYY-MM 形式で指定してください」)。エラーは例外で握りつぶさず観測として返します(Agent ループ 参照)
  • 大きい結果: 件数制限・要約・ページングを用意します。「検索ヒット 1 万件を全部返す」はツール側の設計ミスです

詳細: 自前実装と標準プロトコル(MCP)

ツールを 1 つずつ自前で定義する方法に加えて、2026 年時点では MCP(Model Context Protocol) のような標準プロトコルで既存のツールサーバーに接続する形態が広く使われています。概念上はどちらも「ツール」であり、自社 MCP クライアントでは本記事のアプリ実行型の仕組みが当てはまります。API 経由の MCP 接続はプロバイダー実行型となるため、承認・許可ツールと実行主体を別に確認します。

接続の実務は ツール接続標準(MCP とエコシステム)、外部ツールサーバーをどこまで信頼するかという安全性の論点は ツール権限設計とサンドボックス で扱います。

設計判断: 何をツールにするか(粒度)

  • 細かすぎる場合: 低レベル API を 1:1 で 30 個並べると、モデルは毎回呼び出し順序を推論することになり、選択ミスとトークン消費が増えます
  • 粗すぎる場合: do_anything(action: string) のような万能ツールは、スキーマによる制約が効かず検証もできません
  • 指針: 「モデルに判断させたい境界」でツールを切ります。決定論的にできる処理(整形・集計・入力検証)はツール内部のコードで済ませ、モデルには判断だけをさせます
  • ツール数: 多いほど選択ミスと定義のトークン消費が増えます。タスクに必要なセットへ絞り込むこと自体が設計です

実務での注意点

アンチパターン

チェックリスト

  • 各ツールの実行主体と、実行直前に権限・承認を強制する制御点を確認した
  • 各ツールの説明文に「いつ使うか」「何ができないか」が書いてある
  • 引数スキーマの各項目に説明と形式例がある
  • 失敗時に、モデルが次の手を判断できるエラーメッセージを返す
  • 大きい結果に件数制限・要約の仕組みがある
  • 副作用のあるツール(送信・削除・購入)を照会系と区別し、権限・承認を設計した
  • ツール呼び出し要求の引数をアプリ側で検証している

関連トピック

参考資料

TODO・未確認事項

本文の未確認事項を参照してください。

Agent ループメモリと状態管理