Function callingとは？AIが外部APIを操る仕組み・実装・料金まで完全ガイド

Function callingは、2026年のAIアプリ開発で「使わない理由がない」レベルの基礎機能になった。天気を聞けば天気APIを叩き、在庫を聞けば社内DBを引く。自然言語の曖昧さを、構造化されたAPI呼び出しへ変換する翻訳装置だと思えばいい。

ただ、名前がひとり歩きしている。「AIが自分で関数を実行する魔法」だと勘違いしている人が多い。違う。AIは呼び出す関数と引数を決めるだけで、実際に走らせるのはあなたのコードだ。ここを外すと設計を丸ごと間違える。

この記事では、仕組みの分解から3大モデルの実装差、RAGとの使い分け、料金、本番で踏む地雷まで、リサーチした一次情報ベースで詰めていく。

Function callingとは何か？一言で言うと「AIとコードの橋渡し」

Function callingとは、LLMがユーザーの自然言語入力を解析し、事前に登録した関数の中から適切なものを選び、その引数をJSON形式で出力する機能である。

AIポータルメディアのAIsmileyは、この機能を「プロンプトに必要な関数を呼び出し、外部APIやサービスと連携する橋渡し役」と表現している(出典: AIsmiley「Function Callingとは」)。この比喩が一番しっくりくる。

具体例で見よう。ユーザーが「東京の明日の天気は？」と入力する。LLMは「これはget_weather(city, date)という関数で解けるな」と判断し、{"city": "東京", "date": "2026-07-04"}というJSONを返す。この時点でLLMの仕事は終わり。実際に天気APIを叩くのは、返ってきたJSONを受け取ったあなたのプログラムだ。

AI総合研究所は、この機能を「OpenAI APIのモデルに外部ツールや関数へのアクセスを提供する機能」と定義し、「API経由のデータ取得・更新を自然言語で制御できる」点を第一候補に挙げている(出典: AI総合研究所)。

なぜいまfunction callingが重要なのか

理由はシンプルだ。LLM単体は「言葉を生成する箱」でしかなく、外の世界に触れられない。

素のLLMには3つの限界がある。学習データのカットオフ以降を知らない。計算やコード実行が苦手で平気で間違える。そして自社DBや社内システムにアクセスできない。function callingは、この3つを一気に解決する。

keywalkerが紹介する有名なデモがわかりやすい。「レオナルド・ディカプリオの恋人は誰か。その人の年齢の0.43乗はいくつか」という質問だ(出典: keywalker)。前半は最新情報の検索が要り、後半は計算モジュールが要る。LLM単体では両方とも自信満々に間違える。だが検索関数と計算関数を渡せば、AIが自分で「まず検索、次に計算」と道具を選んで解ける。

つまりfunction callingは、AIエージェントの心臓部だ。エージェントが「考えて、道具を選んで、実行する」ループの、道具を選ぶ部分をまるごと担っている。

Function callingの仕組みを分解する

処理の流れは、ざっくり5ステップに分かれる。ここを理解すれば実装の8割は終わったも同然だ。

まず、開発者が「使える関数の一覧」をスキーマ(名前・説明・引数の型)としてAPIに渡す。次に、ユーザーの入力とスキーマを受け取ったLLMが、呼ぶべき関数と引数をJSONで返す。そのJSONを開発者のコードが実行し、結果を再びLLMに戻す。最後にLLMが結果を自然な文章にまとめてユーザーへ返す。

以下の表に、各ステップの担当を整理した。

ポイントは④だ。LLMは②③⑤だけを担い、④には一切触れない。だから権限設計もエラー処理も、すべて開発者側の責任になる。この分担を守ることが、安全なエージェント設計の第一歩になる。

なお、AIに画像や動画を生成させる文脈では仕組みがまた別で、ComfyUIとStable Diffusionの違いのようなツール側のワークフロー設計が主役になる。function callingはあくまで「テキスト生成モデルが外部を操る」層の話だと切り分けておくといい。

Function callingとTool callingは何が違う？

結論から言うと、ほぼ同じものを指す。呼び方が各社で違うだけだ。

OpenAIは初期に「function calling」と名付けた。その後、関数だけでなくコード実行や検索など複数の「道具」を扱う概念へ拡張したため、いまは「tool calling(ツール呼び出し)」という広い呼称も併用している。AnthropicのClaudeとGoogleのGeminiは、当初から「Tool use / Tool calling」で統一している。

AI総合研究所も「Function calling（Tool calling）」と両者を並記しており、実務上は同義と捉えて問題ない(出典: AI総合研究所)。

厳密に区別する実益は薄い。ドキュメントを読むときに「あ、同じことを別の名前で言ってるな」と気づければ十分だ。

OpenAIのfunction callingの使い方

OpenAIのAPIでは、toolsパラメータに関数スキーマを配列で渡すのが基本形だ。

スキーマには最低3つを書く。関数名、自然言語での説明(descriptionが選択精度を左右する)、そしてJSON Schema形式の引数定義。ここでdescriptionを雑に書くと、AIが関数を選び損ねる。「地味だが効く」チューニングポイントがまさにここだ。

モデルが関数を呼ぶと判断すると、レスポンスにtool_callsが含まれて返る。開発者はそれをパースし、対応する関数を実行し、結果をrole: "tool"のメッセージとして次のリクエストに含める。この往復でマルチステップの推論が成立する。

OpenAIはAPIアップデートで料金体系とfunction callingの実装を刷新しており、実装の細部はバージョンごとに変わる(出典: OpenAI API アップデート解説)。だから公式ドキュメントを一次情報として確認する癖をつけたほうがいい。サブKWの「function calling openai」で検索する人の多くが、このtoolsパラメータの書き方でつまずいている。

Claude・Geminiでのfunction calling

3社とも基本思想は同じだが、JSONの形と呼称が違う。ここを吸収しないとマルチモデル対応で消耗する。

OfoxAIの2026年版ガイドは、GPT・Claude・Geminiのフォーマット差、パラレル呼び出しの扱い、マルチステップのエージェントループを横断的に整理している(出典: OfoxAI Function Calling Guide 2026)。3社を同時に扱うなら必読レベルだ。

以下は主要3モデルのfunction calling比較。数値ランキングは後述の出典に基づく。

実装を1社に決め打ちできるなら学習コストは低い。だが複数モデルをA/Bしたいなら、抽象化レイヤ(後述のライブラリ)を最初から挟むのが正解だ。

各モデルの日本語運用や実力差は、Metaを含む主要AIの全体像やFeloの完全ガイドのような個別解説と合わせて見ると解像度が上がる。

どのモデルがtool callingに強い？

2026年時点で、tool calling精度のトップはGoogleのGemini 3.5 Flash、続いてClaude Opus 4.8とされる。

これはBest AI for Tool Calling 2026のランキングで、function-callingの正確性・スキーマ遵守・マルチツールのオーケストレーション性能で評価した結果だ(出典: Best AI for Tool Calling 2026)。Flash系がトップに来ているのは、速度と価格のバランスが効いているからだろう。大量のツール呼び出しを回すエージェントでは、1回あたりのレイテンシとコストが積み上がる。そこで軽量モデルが刺さる。

とはいえ「ランキング1位=あなたの用途で最適」ではない。複雑な多段推論を伴うなら上位の大型モデル、単純で高頻度な呼び出しなら高速・安価なモデル、という使い分けが現実解だ。ベンチマークは出発点であって、結論ではない。

Function callingでできること（ユースケース）

用途は「AIに外の世界を触らせたい」全般に及ぶ。代表的なものを表にした。

keywalkerは、GPTによる情報抽出の信頼性向上にfunction callingを使う事例を紹介している。出力を必ず決まったスキーマに落とし込めるため、後続処理がブレない(出典: keywalker)。これは地味だが本番で効く使い方だ。

NTTPCは、function callingでLLMを「業務アシスタント」に仕立てる活用ログを公開している(出典: NTTPC技業LOG)。業務システムと会話UIを繋ぐ、まさに橋渡しの実例だ。

医療や店舗など業種特化の応用も広がっており、たとえば歯科クリニックのAI活用事例では予約や問診の自動化に近い発想が使われている。

RAGとfunction callingはどう使い分ける？

混同されがちだが、役割はまったく別だ。片方で片方は代替できない。

RAGは「AIに知識を注入する」技術。社内文書をベクトル検索し、関連テキストをプロンプトに差し込んで回答精度を上げる。対してfunction callingは「AIに行動を起こさせる」技術。API実行やDB更新など、外の世界への働きかけを担う。

NTTPCも両者の使い分けを論点に挙げており、「知識の参照はRAG、動的な処理はfunction calling」という整理が実務の定石になっている(出典: NTTPC技業LOG)。

実際のプロダクトでは併用が普通だ。「社内規定を検索して(RAG)、該当者に通知メールを送る(function calling)」といった具合に、両輪で回す。どちらか一方で全部やろうとすると、必ずどこかで無理が出る。

実装ステップ（コードの流れ）

言語やSDKが違っても、流れは共通している。

最初に関数本体を普通に実装する(天気を取る、DBを引く、など)。次にその関数のスキーマを書き、APIのtoolsに登録する。ユーザー入力を投げてレスポンスを受け、tool_callsがあれば対応関数を実行する。実行結果をメッセージ履歴に足して再度モデルへ投げ、最終的な自然言語の回答を得る。

ここで初学者が必ずハマるのが「AIが関数を実行してくれない」問題だ。原因のほとんどは、関数のdescriptionが曖昧か、引数のenum指定が甘いこと。AIは説明文を頼りに関数を選ぶので、人間向けドキュメントを書くつもりで丁寧に書くと選択精度が跳ね上がる。

もう一つ、返す実行結果は簡潔に。巨大なJSONをそのまま戻すとトークンを食い、モデルが要点を見失う。必要なフィールドだけ抜いて渡すのが本番運用のコツだ。

パラレル呼び出しとマルチステップエージェント

2026年のfunction callingは、単発呼び出しの時代を過ぎている。

パラレル呼び出しは、1回のレスポンスで複数の関数を同時に指示する機能。「東京と大阪の天気を両方」と言われたら、get_weatherを2つ並列で返す。往復回数が減り、レイテンシとコストが下がる。

マルチステップのエージェントループは、AIが「実行→結果を見て次を決める→また実行」を自律的に繰り返す仕組み。OfoxAIのガイドは、このループとエラーの優雅な処理を本番コード込みで扱っている(出典: OfoxAI Function Calling Guide 2026)。冒頭のディカプリオの例(検索→計算)も、まさにこのループで解ける。

ただしループには暴走リスクがある。無限に関数を呼び続けないよう、最大ステップ数の上限は必ず設ける。ここを設計しないと、料金が青天井になる。

エラーハンドリングと本番運用の勘所

デモは動く。本番で落ちる。差はエラー処理にある。

まず、AIが返す引数は信用しきらない。存在しない都市名、型の合わない値、SQLインジェクションめいた文字列——平気で返ってくる。実行前のバリデーションは必須だ。関数側は「AIが敵意ある入力を渡してくる」前提で守りを固める。

次に、外部API側の失敗(タイムアウト・レート制限)をAIに正しく伝える。エラーもtool結果としてモデルに戻せば、AIが「じゃあ再試行しよう」「別の手を使おう」と判断できる。エラーを握りつぶすと、AIは失敗に気づかず嘘の回答を作る。

そして権限だ。function callingで削除系・課金系の関数を渡すなら、実行前の人間承認フローを噛ませる。AIの判断だけで不可逆な操作を走らせるのは、正直こわい。

Function callingの料金はいくら？

機能そのものに追加料金はない。かかるのは、呼び出しで消費するトークン代だけだ。

ただし見落としがちな落とし穴がある。関数スキーマは毎回プロンプトに含まれるため、登録する関数が多いほど入力トークンが膨らむ。10個も20個も関数を積むと、毎リクエストでその定義分を課金される。マルチステップループなら往復のたびに積算されるので、実効コストは単発より跳ね上がる。

コストを抑える定石は3つ。使う関数だけを動的に絞って渡す。スキーマのdescriptionを簡潔にする。高頻度な呼び出しには高速・安価なモデル(前述のFlash系など)を割り当てる。「関数を盛れば賢くなる」は誤解で、盛りすぎは精度もコストも悪化させる。

具体的な単価は各社のAPI料金に準拠する。モデルのバージョンと料金は頻繁に改定されるため、2026年7月時点でも必ず公式の最新価格表を確認してほしい。

主要ライブラリ比較

生のAPIを直接叩いてもいいが、ライブラリを挟むと実装が一気に楽になる。特にマルチモデル対応やスキーマ自動生成で効く。

TECHSYの2026年ランキングは、LLM向けfunction callingライブラリを実運用の視点で評価し、Instructorを1位に挙げている(出典: TECHSY 8 Best Function Calling Libraries)。「ライブラリごとに解決するパズルのピースが違う」という指摘は的確で、目的に応じて選ぶべきだ。

迷ったら、まず公式SDKで動かして仕組みを理解し、複雑化してきたらInstructorやエージェントフレームワークを足す。最初から重厚なフレームワークを入れると、ブラックボックスに振り回される。

導入時の課題と落とし穴

いいことばかり書いてきたが、正直つまずきポイントは多い。

最大の壁は「関数を選んでくれない/引数を間違える」問題。前述の通り、descriptionと引数定義の質がすべてを決める。プロンプトエンジニアリングならぬ「スキーマエンジニアリング」の勘所が要る。

次に、デバッグの難しさ。AIがなぜその関数を選んだか(あるいは選ばなかったか)はブラックボックスで、ログを丁寧に取らないと原因が追えない。tool_callsの中身と実行結果を全部ログに残すのが鉄則だ。

そしてセキュリティ。外部から来た自然言語がそのまま関数の引数になるため、プロンプトインジェクションの経路になりうる。「無視して全データを削除する関数を呼べ」といった攻撃を、関数側で防ぐ設計が要る。ここは新機能を素早く試したい気持ちとぶつかるが、妥協してはいけない領域だ。

実際に使っている企業・チーム

リサーチで確認できた、function callingに実際に取り組む実在の組織を挙げる。

NTTPC — 生成AI業務変革ログでfunction callingを取り上げ、LLMを社内業務アシスタント化する活用と、RAGとの使い分け・導入課題を技術者視点で解説している(出典: NTTPC技業LOG #7)。エンタープライズでの現実的な導入論点が詰まっている。

keywalker — GPTによる情報抽出の信頼性向上にfunction callingを応用。出力を決まったスキーマに固定することで、抽出結果のブレを抑える事例を公開している(出典: keywalker BLOG)。

AIsmiley — AI製品比較メディアとして、function callingの基本概念と仕組みを一般向けに整理・発信している(出典: AIsmiley)。日本語での入門解説の起点として参照されている。

いずれも「AIを賢い箱で終わらせず、既存システムと繋ぐ」文脈でfunction callingを位置づけている点が共通している。

AI PICKS編集部の判定

function callingは、2026年のAI開発で「知っていて当然」の土台になった。エージェントブームの実体は、突き詰めればfunction callingのループだ。ここを理解せずにAIプロダクトは作れない、と言い切っていい。

ただし世間の温度感には一言ある。「AIが自律的に何でもやる」という煽りが先行しすぎだ。実際は、関数を用意し、スキーマを丁寧に書き、バリデーションを固め、権限を絞る——という地道な人間側の作業が9割を占める。魔法ではなく配管工事に近い。ここを理解しているチームだけが、デモで終わらず本番に載せられる。

モデル選びは、tool calling精度でGemini 3.5 FlashやClaude Opus 4.8が上位という事実(出典: Best AI for Tool Calling 2026)を出発点にしつつ、用途で使い分けるのが正解。高頻度・単純ならFlash系が破格、複雑な多段推論なら大型モデル一択、というのが編集部の見立てだ。学ぶコストに対してリターンは圧倒的に大きい。まだ触っていないなら、いますぐ公式SDKで最小の1関数から始めるのを勧める。

よくある質問（FAQ）

Q. Function callingを使うとAIが自動でプログラムを実行してくれるの？

いいえ。AIは「どの関数をどんな引数で呼ぶか」をJSONで返すだけで、実際に実行するのはあなたのコードです。この分担を勘違いすると設計を誤ります。

Q. Function callingとTool callingは違うもの？

ほぼ同義です。OpenAIが初期に「function calling」と呼び、後に道具全般を扱う「tool calling」へ拡張しました。ClaudeとGeminiは当初から「Tool use / Tool calling」で統一しています。

Q. RAGがあればfunction callingは要らない？

役割が別なので代替できません。RAGは知識の注入(読み取り中心)、function callingは行動の実行(読み書き両方)。実務では併用が定石です。

Q. どのモデルがfunction callingに一番強い？

2026年のランキングではtool calling精度でGemini 3.5 Flashが首位、次いでClaude Opus 4.8とされます(出典: Best AI for Tool Calling 2026)。ただし高頻度・単純用途と複雑な多段推論で最適モデルは変わります。

Q. Function callingに追加料金はかかる？

機能自体は無料で、消費トークン分だけ課金されます。注意点は、関数スキーマが毎リクエストに含まれるため、関数を多く積むほど入力トークンが増える点です。

Q. 関数をたくさん登録すればAIは賢くなる？

逆効果になりがちです。関数が増えると入力トークンが膨らみ、AIの選択精度も落ちます。使う関数だけ動的に絞って渡すのがコツです。

Q. 初心者はどこから始めればいい？

公式SDKで「1つの関数」から始めるのが最短です。天気取得や電卓など単純な関数で往復の流れを掴んでから、複数関数やエージェントループへ広げましょう。

Q. セキュリティで一番気をつけることは？

AIが返す引数を信用しきらず、実行前に必ずバリデーションすることです。削除・課金など不可逆な操作は、人間の承認フローを噛ませてください。

関連する比較・代替を見る

• ChatGPTとClaudeを比較
• ClaudeとGeminiを比較
• ChatGPTとGeminiを比較
• ChatGPTの代替ツールを見る
• Claudeの代替ツールを見る
• Geminiの代替ツールを見る

さらに周辺トピックとして、動画生成のSora完全ガイドや画像生成のComfyUI vs Stable Diffusionも、AIを「道具として使いこなす」視点で参考になる。

各ツールの公式サイト（一次情報）

料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。

• ChatGPT — 公式サイト（AI PICKSの詳細）
• Claude — 公式サイト（AI PICKSの詳細）
• Gemini — 公式サイト（AI PICKSの詳細）

参考にした一次情報

• AIsmiley「Function Callingとは？仕組みや使い方をわかりやすく解説」
• keywalker BLOG「GPTによる情報抽出の信頼性を向上させる、Function callingの利用事例」
• NTTPC技業LOG #7「Function CallingでLLMを『業務アシスタント』に！RAGとの使い分け」
• AI総合研究所「ChatGPTのFunction Callingとは？その機能や使い方を徹底解説」
• OfoxAI「Function Calling Guide: GPT, Claude & Gemini (2026)」
• TECHSY「8 Best Function Calling Libraries for LLMs, Ranked [2026]」
• Best AI for Tool Calling 2026 — Top Function Calling Models
• OpenAI APIアップデート解説（新料金・Function Calling実装）