Gorilla (ShishirPatil/gorilla) を採用すべきか: BFCL と関数呼び出し評価の実務的な見取り図

Gorilla が解こうとしている問題は、API 呼び出しの構文と意味の両方を外さないこと

自然言語の問いから API を選ぶとき、モデルは2種類の間違いをする。存在しない関数名や引数名をでっち上げる構文エラーと、実在するが要求と合わない API を選ぶ意味エラーだ。README は Gorilla について「semantically- and syntactically- correct API to invoke」と説明しており、この2つを同時に扱うことを狙っている。対象読者は、LLM にツールを呼ばせる仕組みを自前で組むエンジニアと、その能力を測る必要がある評価担当者だ。APIBench は学習と評価に使える API の集合として提示され、リポジトリには推論コード、評価コード、データセットが同居する。ただし現在の重心は明確に評価側へ移っている。README の Latest Updates は BFCL のバージョン更新、Agent Arena、GoEx、RAFT といった周辺プロジェクトの告知で占められ、初期の Gorilla モデル自体の更新告知は 2023 年前半で止まっている。ここを読み違えると、古い前提でモデルを選ぶことになる。

BFCL の採点は文字列一致ではなく、実行可能な AST と状態遷移で判定する

BFCL の評価は、モデルが返した関数呼び出しをそのまま正解文字列と比較する方式ではない。README が V3 について述べているのは「state-based evaluation system」で、複数ターンにわたる関数呼び出しとサービス状態の遷移を追跡する。つまり会話の途中で呼ばれた関数の結果が次のターンの状態に反映され、その一連の流れが妥当かどうかを見る。V4 Agentic ではさらに、Web 検索を伴うマルチホップ推論とエラーからの回復、エージェントのメモリ管理、プロンプト形式への感度という3つの観点が追加された。形式感度の評価は地味だが実務では効く。同じモデルでもプロンプトの書き方で関数呼び出しの成功率が変わるなら、モデル単体の順位だけでは導入判断を誤る。データの流れは、テストケースを読み込み、モデルに投げ、返ってきた呼び出しを解析し、カテゴリごとの正誤を集計する、という素直な構成だ。コストとレイテンシの指標が 2024 年 4 月にリーダーボードへ追加された点も、選定の実務では見逃せない。

動かすまでの手順は berkeley-function-call-leaderboard ディレクトリに集約されている

README は BFCL の変更履歴を /berkeley-function-call-leaderboard/CHANGELOG.md に置き、コードも同ディレクトリ配下にあると示している。導入時の入口はここだ。リポジトリ全体は Python で書かれ、ライセンスは Apache-2.0。推論側のコードは /gorilla/inference、評価側は /gorilla/eval、データは /data という配置が README に記載されている。GoEx は /goex にあり、LLM が生成したコードや API 呼び出しを実行時に検証し、取り消しと被害の局所化を行うランタイムとして説明されている。ただし README の抜粋には、pip install や python スクリプトの具体的なコマンド行、API キーを入れる設定キー名、モデルを指定する環境変数が含まれていない。したがって「このコマンドを打てば動く」という形でここに書くことはできない。実際のセットアップは BFCL ディレクトリの README と CHANGELOG を直接読む必要がある。設定キーやモデル指定の方法を確認せずに導入計画を立てるのは避けたい。

評価基盤としての限界は、テストケースの分布が自社の障害モードと一致するか保証されないこと

BFCL は汎用的な関数呼び出し能力を測る。V2 で企業提供データと実世界シナリオが入り、V4 でエージェント的文脈が加わったとはいえ、自社の API 群、自社の認証フロー、自社のエラー応答形式をそのまま反映しているわけではない。手元の API が BFCL の想定するスキーマ表現に落ちない場合、点数は出ても意思決定には使えない。もうひとつの制約は、モデルの世代交代の速さだ。リーダーボードは特定時点のモデル群を測った結果であり、新しいモデルが追加されれば順位は動く。自社の評価を固定したいなら、テストケースと採点ロジックをリポジトリから取り出して自前の CI に組み込む必要がある。逆に、Gorilla の初期モデルを関数呼び出しの実行エンジンとして使い続けるのは、README の更新履歴を見る限り想定外だ。学習コードとデータセットは残っているが、モデル本体の継続的な更新は告知されていない。ここは率直に、評価基盤として使うか、過去の研究成果として参照するかに分かれる。

代替としてのネイティブの tool use 機能との違いは、採点の透明性にある

多くのモデル提供者は、独自の関数呼び出し機能とその評価方法を持っている。違いは検証の粒度だ。提供者側の評価は、自社モデルにとって有利な条件で設計されうるし、採点ロジックは公開されないことが多い。BFCL はテストケース、カテゴリ、採点の考え方をリポジトリで公開し、複数モデルを同じ土俵で測る。だから「A モデルと B モデルを同じ条件で比べたい」という用途では BFCL が向く。一方で「自社の本番 API を確実に呼ばせたい」という用途では、提供者のネイティブ機能のほうが、認証やリトライ、ストリーミングといった周辺の作り込みが進んでいる可能性がある。BFCL はあくまで能力の測定であり、実行時の信頼性や運用機能を提供するものではない。GoEx はその運用側に踏み込む試みだが、README の説明は「post-facto validation」と「undo」「damage confinement」という抽象度の高い概念にとどまり、具体的な統合方法は示されていない。ここは過度な期待をしないほうがいい。

ライセンスと保守コスト: Apache-2.0 の範囲で何ができるか

リポジトリ全体は Apache-2.0 で提供され、README には 2023 年 6 月に「Commercially usable, Apache 2.0 licensed Gorilla models」をリリースしたと記されている。商用利用を含む形で使えるライセンスだが、これは法的助言ではない。自組織の利用形態が許諾範囲に入るかは、法務担当者に確認するべきだ。特に、学習済みモデルの重みを再配布する場合や、APIBench のデータを自社の学習に混ぜる場合は、ライセンス表示と帰属の扱いを個別に確認する必要がある。保守コストの観点では、BFCL の CHANGELOG が継続的に更新されている点は安心材料だ。ただし更新はデータセットとモデル追加が中心で、評価基盤の API が安定しているという保証はない。CI に組み込むなら、バージョンを固定して CHANGELOG を追う運用が現実的だ。

どのモデルをどのカテゴリで測るかを先に決めるのが、Gorilla 導入の実質的な第一歩

Gorilla の価値は、単一のモデルや単一の数値ではなく、関数呼び出しという能力を分解して測る枠組みを提供している点にある。単純な単一ターンの呼び出し、複数ターンの状態遷移、エージェント的文脈での検索とメモリ、プロンプト形式への感度。これらは別々の失敗モードであり、ひとつの総合スコアに潰すと判断を誤る。導入を検討するなら、まず自社のユースケースがどのカテゴリに当たるかを決め、そのカテゴリのテストケースだけを BFCL から取り出して回すのが現実的だ。全カテゴリを回すのは比較目的が明確なときだけでいい。リポジトリの構成は推論、評価、データ、GoEx が分かれているため、評価部分だけを切り出して使うことも構造上は可能だ。ただしその場合も、テストケースの形式と採点ロジックの依存関係を CHANGELOG で確認しておく必要がある。

編集部の結論

採用判断は「モデルが欲しいのか、評価基盤が欲しいのか」で分かれる。BFCL の採点ロジックを自前のツール呼び出しテストに組み込みたいチーム、あるいは複数モデルの関数呼び出し能力を同一条件で比較したいチームは、berkeley-function-call-leaderboard ディレクトリを起点に導入する価値がある。逆に、Gorilla の初期モデルをそのまま本番の関数呼び出しエンジンとして使い続ける想定なら、README の最新アップデートが BFCL と Agent Arena に集中している事実を重く見るべきで、別の手段を検討したほうがいい。導入前に確認すべきは、自分の API スキーマが BFCL の想定する形式に落ちるかどうか、そして採点に使うカテゴリが multi-turn や agentic のどこまでを要求するかだ。この2点が噛み合わないと、点数は出ても自社の障害モードを捉えない。

公式情報源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ShishirPatil/gorilla on GitHub