Tool Callingとは？AIに外部ツールを使わせる仕組みを解説

AIをWebアプリに組み込むとき、最初は文章生成や要約だけでも十分に見えます。しかし、実務で使おうとすると、AIが外部データを調べたり、アプリ側の処理を呼び出したり、検索やファイル参照を使ったりする場面が出てきます。

このときに出てくる言葉がTool Callingです。Tool Callingは、AIに「使える外部機能」を渡し、必要に応じてモデルがその機能を呼び出す仕組みです。

ただし、Tool Callingという言葉は少し広く使われます。OpenAI APIのFunction Calling、built-in tools、remote MCP server、AIエージェントのツール利用などが近い場所にあるため、どこまでが同じで、どこから違うのかが混乱しやすいです。

この記事では、Tool Callingの意味、Function Callingとの違い、Structured OutputsやMCPとの関係、Web開発での使いどころ、実装前に確認することを整理します。実装手順を先に知りたい場合は、Function Callingの使い方｜AIに関数を選ばせて実行する基本 も参考にしてください。

この記事の内容は、2026年7月9日時点のOpenAI API公式ドキュメントと、Model Context Protocolの2025-11-25仕様をもとにしています。tools、Function Calling、MCP、Connectors、Tool Searchなどの仕様は変わることがあるため、実装時には必ず公式ドキュメントを確認してください。

結論：Tool CallingはAIに外部機能を使わせるための全体概念

Tool Callingとは、AIモデルに外部機能を渡し、必要に応じてその機能を呼び出させる仕組みです。

ここでいうtoolは、単なる関数だけではありません。次のようなものも広い意味ではtoolとして扱えます。

• アプリ側で定義した関数
• Web検索
• ファイル検索
• コード実行環境
• remote MCP server
• Google WorkspaceやDropboxのような外部サービス接続

OpenAIのUsing toolsドキュメントでは、モデルの能力を拡張する方法として、built-in tools、Function Calling、Tool Search、remote MCP serversなどが扱われています。つまりTool Callingは、AIが外部機能を使うための広い地図です。

一方、Function Callingはその中の1つです。アプリ側で関数を定義し、AIに「どの関数を、どんな引数で呼ぶか」を選ばせます。

ざっくり分けると、次のようになります。

用語	意味	この記事での扱い
Tool Calling	AIに外部機能を使わせる全体概念	この記事の中心
Function Calling	自前関数をAIに選ばせる具体的な実装方式	別記事で実装を深掘り
Built-in tools	OpenAI側で用意されたWeb検索やコード実行など	代表例として紹介
MCP	外部ツールやデータを接続するための共通プロトコル	概念として触れ、詳細は後続記事へ分離

Tool Callingを理解すると、AIアプリを「文章を返すだけのチャット」から、「外部データやアプリ機能を使って回答するチャット」へ広げられます。

Tool Callingとは？

Tool Callingは、AIモデルに外部機能の一覧を渡し、モデルが必要に応じてtool callを返す流れです。

たとえば、ユーザーが次のように質問したとします。

注文番号 A-1024 の配送状況を教えてください。

AIが配送状況を自分の学習済み知識だけで知ることはできません。そこで、アプリ側が get_order_status のようなtoolを渡します。モデルは「この質問に答えるには注文状況を調べる必要がある」と判断し、tool callを返します。

その後、アプリ側が実際の関数やAPIを実行し、結果をモデルに返します。モデルはその結果をもとに、ユーザー向けの自然な回答を作ります。

つまり、Tool Callingは次の分担です。

担当	役割
モデル	どのtoolが必要かを判断し、tool callを返す
アプリ	tool callを検証し、許可された処理だけを実行する
外部システム	DB、API、検索、ファイル、業務システムなどの結果を返す
モデル	toolの結果を使って最終回答を作る

ここで大切なのは、AIが勝手に何でも実行するわけではないことです。AIに見せるtoolは、アプリ側が選びます。さらに、実行前の検証や権限確認もアプリ側の責任です。

Tool Callingが必要になる場面

Tool Callingが必要になるのは、AIの学習済み知識だけでは答えられない場面です。

代表例は次のとおりです。

場面	必要なtool	例
最新情報を調べたい	Web検索	今日のニュース、最新の仕様変更
社内情報を参照したい	ファイル検索、社内DB検索	FAQ、議事録、契約書、ナレッジベース
アプリ機能を呼びたい	Function Calling	注文検索、在庫確認、予約候補取得
計算や変換をしたい	コード実行、専用関数	CSV集計、グラフ作成、数値計算
外部サービスと接続したい	MCP、Connectors	Google Drive、Slack、Dropbox、独自業務システム

普通の文章生成だけなら、Tool Callingは不要です。たとえば「メール文を丁寧に書き換えて」「記事の見出し案を出して」といった処理は、モデルへのプロンプトだけで十分なことがあります。

一方、現在の注文状況、社内ドキュメント、ユーザーごとの権限、外部APIの結果などが必要な場合は、Tool Callingを検討します。

Function Callingとの違い

Function Callingは、Tool Callingの代表的な実装方式です。

OpenAIのFunction Callingドキュメントでは、functionはtoolの一種として扱われています。関数はJSON Schemaで引数を定義し、モデルはその関数名と引数を返します。アプリ側は、その引数を検証して関数を実行します。

たとえば、Function Callingでは次のような関数をAIに渡します。

{
  type: "function",
  name: "get_order_status",
  description: "注文番号から配送状況を取得する",
  parameters: {
    type: "object",
    properties: {
      order_id: {
        type: "string",
        description: "注文番号"
      }
    },
    required: ["order_id"],
    additionalProperties: false
  },
  strict: true
}

このような自前関数を定義する実装は、Function Callingの使い方 で詳しく扱いました。

この記事で押さえたいのは、Function CallingはTool Callingの一部だという点です。Tool Callingという大きな概念の中に、Function Calling、Web検索、ファイル検索、MCP、Code Interpreterなどが含まれる、と考えると整理しやすいです。

Structured Outputsとの違い

Structured OutputsもJSON Schemaを使うため、Tool CallingやFunction Callingと混同しやすいです。

違いは、何を構造化するかです。

機能	構造化するもの	使いどころ
Structured Outputs	AIの返答そのもの	分類結果、レビュー結果、構成案をJSONで返す
Function Calling	呼び出す関数と引数	注文検索、在庫確認、予約候補取得
Tool Calling	外部機能の呼び出し全体	検索、関数、MCP、コード実行を含む広い設計

たとえば、問い合わせ文をカテゴリ分類して、次のようなJSONで返すだけならStructured Outputsが向いています。

{
  "category": "billing",
  "priority": "high",
  "needs_human_review": true
}

一方、問い合わせ文から「注文検索APIを呼ぶ必要がある」と判断し、注文番号を引数として渡すならFunction Callingです。Function Callingを含む広い外部機能利用の考え方がTool Callingです。

Structured Outputsの使い方は、Structured Outputsの使い方 で詳しく整理しています。

Built-in toolsと自前toolsの違い

Tool Callingを理解するときは、built-in toolsと自前toolsを分けるとわかりやすいです。

OpenAI APIでは、Web検索、ファイル検索、コード実行、MCP接続など、OpenAI側で用意されたtoolが案内されています。こうしたtoolは、開発者がゼロから検索エンジンや実行環境を作らなくても使えるのが利点です。

一方、自前toolsは、アプリ側で定義する関数やAPI接続です。たとえば、注文状況確認、会員情報取得、在庫確認、チケット作成などは、アプリごとの業務ロジックに合わせて作ります。

比較すると、次のようになります。

種類	例	向いていること
Built-in tools	Web search、File search、Code Interpreter、MCP	汎用的な検索、ファイル参照、計算、外部接続
自前tools	get_order_status、search_faq	自社アプリや業務ロジックに合わせた処理

最初に試すなら、読み取り専用の自前関数が扱いやすいです。外部APIやDBにアクセスする場合でも、まずは「取得するだけ」の処理に絞ると安全に検証できます。

MCPとの関係

MCPはModel Context Protocolの略で、AIアプリと外部ツールやデータをつなぐための標準的なプロトコルです。

MCP仕様では、サーバーがtoolsを公開し、言語モデルがそれらを呼び出せるようにする考え方が説明されています。toolsは、DB問い合わせ、API呼び出し、計算などの外部システムとのやり取りに使われます。

OpenAIのMCP and Connectorsドキュメントでも、Function Callingで渡すtoolsに加えて、connectorsやremote MCP serversを使うことで、モデルに新しい能力を与えられると説明されています。

ただし、MCPはTool Callingそのものと同義ではありません。関係は次のように整理できます。

用語	役割
Tool Calling	AIが外部機能を呼ぶ全体の考え方
Function Calling	アプリ側の関数をtoolとして渡す方法
MCP	外部ツールやデータを共通インターフェースで接続する仕組み

MCPを使うと、1つのアプリに閉じた関数だけでなく、外部サービスや複数のツール群を共通形式で扱いやすくなります。反面、認証、権限、確認UI、ログ、ツールごとの安全性設計がより重要になります。

最小構成で考える処理の流れ

Tool Callingの基本的な流れは、Function Callingと似ています。

1. アプリ側が、モデルに使わせるtoolを決める
2. ユーザー入力とtoolsをモデルに渡す
3. モデルが必要なtool callを返す
4. アプリ側またはプラットフォーム側がtoolを実行する
5. toolの結果をモデルが受け取る
6. モデルが最終回答を作る

自前関数の場合、toolの実行はアプリ側が行います。Web searchやFile searchのようなbuilt-in toolsでは、OpenAI側の仕組みが実行を担う場合があります。remote MCP serverでは、MCPサーバー側のtoolが呼び出されます。

違いはあっても、基本は「モデルが必要な外部機能を選び、その結果を使って回答する」という流れです。

Web開発での使いどころ

Web開発でTool Callingが役立つのは、AIとアプリ機能を接続したい場面です。

たとえば、次のような使い方があります。

• 問い合わせ文から関連FAQを検索して回答する
• 注文番号から配送状況を調べて回答する
• 管理画面で顧客情報を検索する
• 社内ドキュメントを検索して要約する
• CSVを読み込んで集計する
• ユーザーの希望条件から予約候補を探す

Webアプリとして考えるなら、Tool Callingはサーバー側の機能とつなげるのが基本です。ブラウザにAPIキーを置いたり、ユーザー入力から直接危険な処理を実行したりしないようにします。

クライアントとサーバーの役割を整理したい場合は、クライアントサーバーシステムとは も参考になります。

実装前に確認すること

Tool Callingを導入する前に、まず次の点を確認します。

• その処理は本当に外部toolが必要か
• 読み取り専用か、状態変更を伴うか
• ユーザーごとの権限確認が必要か
• toolの結果をどこまでログに残すか
• 失敗時にどうフォールバックするか
• AIがtoolを誤って選んだときに止められるか
• 料金やレート制限に耐えられるか

特に、状態変更を伴うtoolは慎重に扱います。メール送信、注文キャンセル、決済、削除、ステータス更新などは、AI判断だけで実行しないほうが安全です。

MCP仕様でも、toolの公開や呼び出しではユーザーに見えるUI、実行時の確認、拒否できる仕組みが重要だとされています。Tool Callingは便利ですが、AIが使える機能が増えるほど、誤実行時の影響も大きくなります。

よくある誤解と注意点

Tool Callingには、よくある誤解があります。

AIが自由にツールを作れるわけではない

モデルが使えるtoolは、基本的に開発者やプラットフォームが渡したものです。AIがその場で勝手に本番DBへ接続したり、未知のAPIを実行したりできるわけではありません。

tool callは実行そのものではない

自前関数の場合、モデルが返すのは「この関数をこの引数で呼びたい」というリクエストです。実際に実行するかどうかは、アプリ側が判断します。

Tool Callingだけで正確性は保証されない

toolの結果が正しくても、モデルの説明が誤ることがあります。逆に、モデルが適切でないtoolを選ぶこともあります。実務では、ログ、検証、テスト、UI上の確認が必要です。

権限管理は別に必要

ユーザーAがユーザーBの注文を見られるような設計にしてはいけません。Tool Callingの前後で、ログインユーザー、対象データ、操作権限を確認します。

巨大なtools一覧は扱いにくい

最初から大量のtoolsを渡すと、モデルがどれを使うべきか迷いやすくなります。よく使うtoolsだけ渡す、機能ごとに分ける、Tool Searchを検討するなど、段階的に整理します。

Tool CallingとAIエージェントの違い

AIエージェントという言葉も、Tool Callingと一緒に出てきます。

Tool Callingは、外部機能を呼ぶ仕組みです。一方、AIエージェントは、目標に向かって複数の手順を計画し、必要に応じてtoolsを使い、状態を管理しながら進めるアプリケーション全体の考え方です。

つまり、Tool Callingはエージェントを作るための部品の1つです。

用語	中心になるもの
Tool Calling	外部機能を呼び出す仕組み
AIエージェント	目標、計画、状態管理、tool利用を含むアプリ設計

AIエージェント全体のイメージは、AIエージェントとは？できること・仕組み・使い方をわかりやすく解説 で整理しています。

まとめ

Tool Callingは、AIに外部機能を使わせるための全体概念です。Function Calling、built-in tools、remote MCP servers、ファイル検索、Web検索、コード実行などは、このTool Callingの地図の中にあります。

重要なポイントは次のとおりです。

• Tool Callingは、AIが外部データや機能を使うための仕組み
• Function Callingは、自前関数をtoolとして渡す具体的な方法
• Structured Outputsは、返答そのものをJSON Schemaで固定する機能
• MCPは、外部ツールやデータを共通プロトコルで接続する仕組み
• tool callを実行するかどうかは、アプリ側の検証と権限確認が重要
• 最初は読み取り専用の小さなtoolから始めると安全

次に進むなら、まずFunction Callingで自前関数を1つ呼ぶ流れを実装し、その後にMCPやAIエージェント設計へ広げるのが自然です。AIアプリ開発全体の入口としては、AIとは？エンジニアがWeb開発で押さえるべき基本 もあわせて読むとつながりやすくなります。

参考リンク

• OpenAI API: Using tools
• OpenAI API: Function calling
• OpenAI API: MCP and Connectors
• Model Context Protocol: Tools
• Model Context Protocol: Architecture