![]()
BFCLとは?AIの関数呼び出し精度を比べるベンチマークの読み方 (2026年版)
この記事のポイント BFCLは、AIが「外部のツールを正しく呼び出せるか」だけを取り出して測る公開テストです。 スコアはOverall Accuracyという「小分類の単純平均」で、重みづけがありません。ここを知らないと順位を誤読します。 V1〜V4で問われる能力が別物です。単発の呼び出しか、会話をまたぐ複数ターンかで、得意なモデルは入れ替わります。 集計サイトによって同じモデルの数字が揃いません。順位そのものより、差の大きさと測定日を見るのが正解です。
AIエージェントを組もうとして、モデル選びの根拠が「なんとなく評判がいいから」で止まっている。この状態、かなり多いはずです。
そこで見るべき指標がBFCLです。BFCLとは、AIが外部のツールや関数を、正しい名前・正しい引数で呼び出せるかを測る公開ベンチマークです。 UCバークレーのGorillaプロジェクトが公開しています。
文章の読みやすさでも知識量でもありません。測っているのは一点だけ。「AIが道具をちゃんと使えるか」です。
BFCLとは?UCバークレーが公開する「道具の使い方」の共通テスト

BFCLはBerkeley Function Calling Leaderboardの略で、LLMの関数呼び出し能力を横並びで比較するために作られた評価基盤です。
関数呼び出し(function calling)は、AIが自分で文章を書く代わりに「この関数を、この引数で実行してください」という構造化された指示を返す仕組みを指します。天気を聞かれたら天気APIを呼ぶ、在庫を聞かれたら在庫DBを叩く。エージェントと呼ばれるものの土台は、ほぼこれです。
ここが崩れると何が起きるか。AIは自信満々に間違った関数を呼び、間違った結果を根拠にもっともらしい答えを返します。利用者からは正常動作と区別がつきません。 一番たちの悪い壊れ方です。
だからBFCLは、答えの「見た目のうまさ」を一切評価しません。関数名は合っているか。引数の型は合っているか。そもそも呼ぶべきでない場面で呼んでいないか。採点はこの三種類に集約されます。
会話の自然さを競うベンチマークとは目的が違う、という点をまず押さえてください。
なぜ関数呼び出しの精度が、業務システムでいちばん効くのか

社内でAIを動かすとき、事故が起きる場所は文章生成ではありません。外部システムに触れる瞬間です。
チャットで多少ぎこちない日本語が返ってきても、業務は止まりません。しかし「削除」の関数を「取得」だと思って呼ばれたら、それは障害です。
具体的にはこういう場面で効いてきます。
- 社内DBへの問い合わせをAIに任せるとき、検索条件の引数を取り違えると全件返る
- 承認フローを呼び出すとき、対象IDを一つずらすと別案件が承認される
- 外部SaaSのAPIを叩くとき、必須引数の欠落でリトライが積み上がり課金だけ増える
- 呼ぶ関数がそもそも用意されていない要求に、それらしい関数を捏造して呼ぶ
四つ目が地味に厄介です。「該当する関数がありません」と正直に言えるかどうか。BFCLはここを独立した項目として測っています。
社内でのAI利用を管理側の目線で点検する話は、社内監査向けのAIツールの選び方にまとめています。評価の話とセットで読むと、どこまで自動化を許すかの線引きがしやすくなります。
BFCLはV1からV4で何が変わった?

同じ「BFCL」でも、バージョンによって測っているものが違います。ここを混ぜて語ると議論が噛み合いません。
系列ごとの性格を整理したのが次の表です。
| 系列 | 中心テーマ | 設問の出どころ | 向いている判断 |
|---|---|---|---|
| V1 | 単発の関数呼び出し | 人手で設計した合成データ | 基礎的な構文の正しさ |
| V2 Live | 実利用に近い単発呼び出し | 利用者から寄せられた実際のプロンプト | 現場の言い回しへの耐性 |
| V3 | 複数ターンの対話 | 合成+敵対的に調整されたシナリオ | 会話をまたぐ文脈保持 |
| V4 | エージェント寄りの評価軸を追加 | 上記を包含し拡張 | 自律的に動く用途の下調べ |
つまり、単発のAPI連携ならV1やV2 Liveの数字、対話しながら作業を進めるアシスタントならV3以降、という読み分けになります。
V2のLiveデータセットは特徴的です。実際の利用者が投げたプロンプトが素材になっているため、設問が現実の相談ごとに寄っています。たとえば競合の価格を並べて自社のSaaS料金をどう設計するか、といった、業務そのままの文面が混ざります。
きれいに整えられた設問では出ない弱点が、ここで露出します。
V3は方向性がまた別です。複数ターンの対話のなかで、推論・文脈追跡・ツール呼び出しを同時に問う設計になっています。しかも設問は敵対的に調整されている、つまりAIが引っかかりやすい形にわざと寄せてあります。
V4はエージェント的な評価が加わった最新系列です。公式リーダーボードの表示上の最終更新は2026年4月12日でした。系列の細部は動きやすいので、実際に採用判断へ使うときは公式の Gorillaリーダーボード を直接見て、更新日を確認するのが確実です。
スコアの読み方 — Overall Accuracyは「平均の平均」

順位表でいちばん目立つOverall Accuracy。この数字の定義を知らないまま比べるのは危険です。
BFCLのOverall Accuracyは、すべての小分類の重みなし平均として計算されます。設問数の多い分類も少ない分類も、同じ重さで効きます。
これが何を意味するか。
自分の用途に直結する分類が全体のごく一部だった場合、総合点はあなたにとってほぼ無意味です。総合1位のモデルが、あなたの業務に該当する分類では3番手ということが普通に起こります。
順位表にはOverall以外の列も並びます。読むべき優先順位はこうです。
| 列 | 意味 | 実務での重み |
|---|---|---|
| 小分類ごとの精度 | 用途に対応する項目の実力 | 最優先。ここが本命 |
| Overall Accuracy | 全小分類の単純平均 | 参考。足切りに使う程度 |
| Cost | ベンチマーク全体を通した推定費用(USD) | 運用コストの相対比較に有効 |
| Latency | 応答までの秒数 | 対話型なら体感を左右する |
つまり、総合点で足切りして、そこから先は小分類とコストで決める。この二段構えが実務的です。
Costの列は見落とされがちですが、意味が明確です。ベンチマーク全体を走らせたときの推定費用をドル建てで示したもの。モデル間の「同じ仕事量あたりの費用感」を比べる材料になります。
FCとPromptの違いを見落とすと、選定を丸ごと間違えます
BFCLの表には、モデル名の横にFCまたはPromptという表記が付きます。ここ、初見では素通りしがちです。
意味はまったく違います。
- FC:モデルが関数呼び出しをネイティブに備えている場合の測定
- Prompt:ネイティブ対応がないモデルに対し、通常の文章生成能力で関数呼び出しを再現させた迂回策での測定
同じモデル名でも、FC版とPrompt版でスコアが並ぶことがあります。比較するなら同じ形式同士で。
自社の実装がどちらに当たるかも確認が必要です。
| 実装の形 | 対応する行 | 注意点 |
|---|---|---|
| APIのtools/functions引数を使う | FC | 本番構成と一致しやすい |
| プロンプトでJSONを書かせて自前でパース | Prompt | パーサの出来がスコアに乗らない |
| フレームワーク任せ | 要確認 | 内部でどちらを使うか読む必要あり |
要するに、自分たちの実装形式と違う行の数字を根拠にすると、本番で再現しません。
ワークフロー基盤を使っている場合はこの確認が特に重要です。DifyとLangChainの比較でも触れていますが、抽象化レイヤーが厚いほど、内部でどの経路を通っているかが見えにくくなります。
V3の4カテゴリが示す「壊れ方」の種類
V3では、複数ターンの設問が四つのカテゴリに分かれています。それぞれ、違う壊れ方を炙り出す設計です。
| カテゴリ | 問われること | 失敗したときの症状 |
|---|---|---|
| Base | 標準的な複数ターン処理 | 会話が進むと引数を取り違える |
| Miss Func | 必要な関数が提供されていない状況 | 存在しない関数を捏造して呼ぶ |
| Miss Param | 必要な引数が揃っていない状況 | 勝手に値を推測して埋める |
| Long Context | 長い文脈を抱えた状態での処理 | 前半の指示を忘れる |
見てのとおり、Miss FuncとMiss Paramは「呼ばない・聞き返す」が正解の設問です。
ここが弱いモデルは、業務で最悪の挙動をします。情報が足りないのに聞き返さず、それらしい引数をでっち上げて実行する。ログを見るまで誰も気づきません。
Long Contextも軽視できません。長い社内マニュアルを読ませたうえでツールを呼ばせる構成では、文脈の後半だけを見て動くモデルが出てきます。
自社の使い方がどのカテゴリに近いか、先に決めておくこと。それだけで順位表の見え方が変わります。
ここまでの整理:BFCLは「道具を正しく使えるか」だけを測る。総合点は小分類の単純平均なので、用途に対応する分類を直接見る。FCとPromptは別物として扱う。V3の4カテゴリは、それぞれ違う壊れ方に対応している。
2026年7月時点の公開スコアはどう並んでいる?
ここからは数字の話です。ただし、先に一つ注意を。
集計元が違うと、同じベンチマーク名でも数字が揃いません。 バージョンが違う、評価対象のモデル母数が違う、測定日が違う。この三つが重なるため、複数の集計を並べると矛盾して見えます。
まずBFCL v3の公開集計から。2026年7月30日時点で、23モデルが評価対象、平均スコアは58.5、標準偏差は17.5でした。上位はこう並んでいます。
| モデル | 提供元 | 入力$/M | 出力$/M | BFCL v3 |
|---|---|---|---|---|
| GLM 4.5 Thinking | Z AI | $0.600 | $2.200 | 76.7 |
| Claude Opus 4.7 | Anthropic | $5.000 | $25.000 | 76.6 |
| Gemini 3.1 Flash Lite Preview | $0.250 | $1.500 | 76.5 | |
| Qwen3 32B Thinking | Alibaba | $0.080 | $0.280 | 75.7 |
つまり、上位4モデルのスコア差は1.0ポイント以内なのに、入力単価は最大で60倍以上開いています。
この表が一番はっきり示しているのは順位ではありません。関数呼び出しという用途に限れば、最上位帯の実力差はもう価格差を説明しないところまで詰まっているということです。
V4系列の集計はまた別の顔をしています。オープンモデル側ではQwen3.5-397B-A17Bが0.729というスコアで、全体2位につけていました。同時期の集計では、上位から10%以内に収まるモデルのうち最も安いのがQwen3.5-27Bで、入力100万トークンあたり$0.30、スコアは0.685です。
別のV4集計(2026年7月30日更新、9モデル)では、Qwen3.7 Maxが75.0%で首位、Qwen3.7 Plusが72.9%、オープンモデルのLFM2.5-8B-A1Bが49.7%という並びでした。
数字の粒度も母数も揃っていません。だから、異なる集計の数字を1つの表に混ぜて順位を語るのは誤りです。 見るべきは同一集計内での相対差だけ。
オープンモデルの追い上げも傾向として明確です。2026年初頭の時点で、Qwen2.5 72B InstructやDeepSeek V3が多くの関数呼び出し分類でGPT-4oと互角以上、という評価が出ていました。Mistral Small 4やLlama 4 Scoutも候補に挙がる位置にいます。
オープンモデルの現在地はMeta AIとLlama系の解説でも整理しています。自社ホスティングを検討しているなら、そちらを先に読むと選択肢が絞れます。
コストとレイテンシの列こそ、意思決定を決める
スコアだけ見て決めた構成は、請求書で後悔します。
BFCLの順位表にはCostとLatencyが併記されます。Costはベンチマーク全体を通したときの推定費用(USD)、Latencyは秒単位の応答時間です。
エージェント用途では、この二つがスコア以上に効きます。理由は単純で、エージェントは1回の依頼で何度もモデルを呼ぶからです。
ユーザーの1リクエストが、内部では関数呼び出しの判断・実行・結果の解釈で3〜5往復になる。単価差もレイテンシ差も、そのまま倍率でのしかかります。
判断の目安を置くとこうなります。
- スコア差が1〜2ポイント以内なら、安いほうを選んで問題ない
- スコア差が5ポイント以上なら、価格差を飲んででも高いほうを検討する
- 対話型UIで待ち時間が見えるなら、Latencyを最優先にする
- バッチ処理で待ち時間が見えないなら、Costを最優先にする
先ほどの表で言えば、上位4モデルは1ポイント以内に収まっています。この帯域なら、単価$0.080のモデルを選ばない理由を探すほうが難しい。
もっとも、これは関数呼び出しに限った話です。長文の要約品質や日本語の自然さまで含めれば、判断は変わります。ChatGPTとClaudeの比較やClaudeとGeminiの比較で、用途別の得手不得手を確認してから決めてください。
BFCLのスコアが高いモデルを選べば、業務は回る?
回りません。ここははっきり言い切ります。
BFCLが測っているのは、あらかじめ用意された関数定義に対して、正しい呼び出しを組み立てられるかどうか。業務システムで実際に問題になるのは、その前後にあります。
ベンチマークが見ていない領域を挙げます。
| 実務で必要なこと | BFCLでの扱い |
|---|---|
| 関数定義そのものの設計品質 | 対象外(与えられた定義が前提) |
| 権限管理・実行可否の判断 | 対象外 |
| 失敗時のリトライとロールバック | 対象外 |
| 日本語の業務用語の解釈 | ほぼ対象外(設問は英語中心) |
| 社内固有の略語・商品名 | 対象外 |
つまりBFCLは、モデル選定の足切りには使えるが、最終判断には使えないということです。
現場で効くのは、多くの場合モデルの差ではなく関数定義の書き方です。引数名が曖昧、説明文が一行だけ、似た関数が3つ並んでいる。この状態ではどのモデルを持ってきても精度は出ません。
ベンチマークの数字を追う前に、自分たちの関数定義を人間が読んで迷わないか確認する。効果はこちらのほうが大きいです。
そもそも公開ベンチマークが存在しない領域も多くあります。画像生成まわりがその典型で、イラスト生成ツールの選び方やComfyUIとStable Diffusionの比較では、数字ではなく出力サンプルと運用のしやすさで判断せざるを得ません。数字がある領域は、むしろ恵まれています。
日本語の業務にBFCLの結果をそのまま当てはめていい?
そのままは危険です。BFCLの設問は英語中心で構成されています。
日本語で運用したときに追加で起きる問題は、だいたい三つです。
- 助詞の曖昧さで、どの引数にどの値を入れるかがぶれる
- 敬語や婉曲表現のせいで、依頼なのか確認なのか判定を誤る
- 全角数字・和暦・「先月末」のような相対表現の正規化に失敗する
三つ目が実務では一番多い。「先月末までの受注」を数値の日付に変換する処理で、モデルごとの差がはっきり出ます。
対策は単純で、日本語の実データで20〜30件のミニテストを自作すること。BFCLのカテゴリ構成をそのまま流用し、設問だけ自社の日本語に差し替えます。
日本語のAI検索や要約まわりの実力差を見たい場合は、Feloの解説記事が参考になります。日本語処理の癖はサービスごとにかなり違う、というのが実感できるはずです。
自社ユースケースでBFCL式に測り直す手順
公開スコアで候補を3つに絞ったら、あとは自分で測ります。手順はそれほど重くありません。
- 本番で使う関数定義をそのまま5〜10個持ってくる
- 実際のユーザー発話を30件集め、正解の呼び出し内容を人手で書く
- Miss FuncとMiss Paramに相当する設問を、全体の2〜3割混ぜる
- 候補モデルで実行し、関数名・引数の一致率を分類ごとに集計する
三つ目を省略しないでください。正常系だけで測ると、全モデルが高得点になって差がつきません。
集計は分類ごとに出します。総合点にまとめた瞬間、BFCLのOverall Accuracyと同じ落とし穴にはまります。
評価の実行環境としては、ワークフロー基盤の上に組むのが手早いです。n8nとZapier AIの比較で挙げているようなツールでも、簡易な繰り返し実行なら十分こなせます。より作り込むならLangChainとLlamaIndexの比較を見て、どちらの流儀が自社に合うか決めてください。
AI PICKS編集部の判定
BFCLは、AIエージェントを組む人にとっては目を通す価値の高いベンチマークです。関数呼び出しという一点に絞り込んだ設計が効いていて、総合的な賢さでは見えない差がきれいに出ます。特にV3のMiss Func・Miss Paramの発想は破格で、「呼ばない判断ができるか」を独立に測るという着眼点は他のベンチマークにあまりありません。
一方で、順位表をそのまま採用根拠にするのは正直イマイチです。Overall Accuracyが小分類の単純平均である以上、総合1位はあなたの用途の1位ではありません。加えて、集計サイトごとに数字が揃わない。2026年7月末時点でも、v3の集計とv4の集計では上位の顔ぶれが別物でした。
現実的な使い方は一つ。候補を3つに絞るための足切りとして使い、最終判断は自社データの30件テストでやる。 これが一番失敗しません。
そして上位帯のスコア差が1ポイント以内に収まっている今、関数呼び出しの精度だけで高額なモデルを選ぶ理由は薄くなりました。差が出るのは価格とレイテンシのほうです。
関連する比較・代替を見る
モデル選定は関数呼び出しの精度だけでは決まりません。用途ごとの比較も併せて確認してください。
- ChatGPT vs Claude — 汎用チャットとしての総合的な使い勝手の差
- Claude vs Gemini — 長文処理とコストのバランス
- DeepSeek vs Llama — オープンモデル同士の実力比較
- Dify vs LangChain — エージェント構築基盤の選択
- LangChain vs LlamaIndex — 検索連携まで含めた設計思想の違い
- Claude Code vs Cursor — 開発現場でのツール呼び出し体験の差
- GLM 5.2 vs Qwen3.6 Plus — スコア上位帯の実装候補
カテゴリ単位で探すなら、AIエージェントとLLMから入るのが早いです。
よくある質問(FAQ)
Q. BFCLは無料で使えますか?
はい。リーダーボードの閲覧も、評価データセットの取得も無料です。評価コードを自分の環境で動かす形式なので、社内データを外部に送らずに検証できます。かかるのは対象モデルのAPI利用料だけ。
Q. BFCLとMMLUは何が違いますか?
測っている能力が別物です。MMLUは幅広い分野の知識を問う選択式のテスト。BFCLは知識ではなく、外部の関数を正しく呼び出せるかという操作の正確さを見ます。エージェント用途の判断材料になるのはBFCLのほうです。
Q. FCとPrompt、どちらの数字を見ればいいですか?
自社の実装に合うほうです。APIのtools引数を使うならFC、プロンプトでJSONを書かせて自前で解析するならPrompt。混ぜて比較すると、本番で再現しない結論になります。
Q. スコアが数ポイント違うモデル、どちらを選ぶべきですか?
1〜2ポイント差なら安いほう、あるいは応答が速いほうで問題ありません。関数呼び出しの上位帯は差が詰まっていて、2026年7月末時点の公開集計では上位4モデルが1.0ポイント以内に収まっていました。5ポイント以上開いているなら、上位を検討する価値があります。
Q. 日本語の業務でもBFCLのスコアは参考になりますか?
候補を絞る段階までは参考になります。ただし設問は英語中心なので、日本語特有の曖昧さや和暦・相対日付の処理は測れていません。実運用前に日本語の実データで20〜30件の追試をしてください。
Q. オープンモデルでも関数呼び出しは実用レベルですか?
用途によっては十分です。2026年初頭の時点で、Qwen2.5 72B InstructやDeepSeek V3が多くの分類でGPT-4oと互角以上という評価が出ていました。自社ホスティングでコストを抑えたい場合の候補になります。
Q. V4だけ見ておけばいいですか?
用途次第です。単発のAPI連携ならV1やV2 Liveの分類のほうが実態に近く、対話しながら作業を進める構成ならV3以降を見ます。V4は最新ですが、あなたの使い方に一番近いとは限りません。
Q. ベンチマークの結果は、どのくらいの頻度で確認すべきですか?
四半期に一度で十分です。ただし新しいモデルを本番に入れる直前は、必ず自社の30件テストを流し直してください。公開スコアの更新日と、自社での最終検証日は別で管理するのが安全です。
関数呼び出しの精度を確かめたあとは、その上で動かす基盤の選定が待っています。次に読むならDifyとLangChainの比較。エージェントを内製するか、既製の基盤に乗るかの判断が、モデル選び以上に運用コストを左右するからです。
各ツールの公式サイト(一次情報)
料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。
- Claude — 公式サイト(AI PICKSの詳細)
- ChatGPT — 公式サイト(AI PICKSの詳細)
- Gemini — 公式サイト(AI PICKSの詳細)
- Dify — 公式サイト(AI PICKSの詳細)
- LangChain — 公式サイト(AI PICKSの詳細)
