6月18日、Hugging Faceが「Is it agentic enough? Benchmarking open models on your own tooling」と題した記事を公開した。この記事では、オープンモデルを使ったエージェントが自前のツールをどれだけ効率よく使えるかをベンチマークする手法について詳しく紹介されている。CLIで操作できるツールであれば何にでも適用できる汎用設計が特徴で、Hugging Faceは自社ライブラリ transformers を題材に選ぶことで、エージェントの振る舞いをライブラリ改善のフィードバックループに直接つなげようとしている。
なぜ transformers を題材に選んだのか
Hugging Faceがこのベンチマークを構築した動機は明確だ。transformers に新しいCLIやSkillドキュメントを追加したとき、それがエージェントの動作を実際に改善しているかを定量的に確認したい。つまり自社ライブラリへの変更がエージェント活用に与える影響を測る、改善フィードバックループとしてこのハーネスを位置づけている。
同様の課題は、CLIを持つあらゆるツールの開発者が直面しうる。そのためハーネスはtransformers専用ではなく、どんなCLIで操作できるツールにも転用できる汎用設計になっている点が重要だ。
「正解したかどうか」だけでは見えないもの
コーディングエージェントがライブラリを使ってMLタスクを解くとき、「最終的に正解を出したか」だけを見ていると、重要な情報を見落とす。
たとえば、感情分類タスクで2つのエージェントがどちらも POSITIVE (0.9999) という正解を出したとする。しかし一方は：
# 40行のPythonスクリプトを書き、shapeエラーをデバッグし、2回再実行してようやく出力
python - <<'PY'
from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch
import torch.nn.functional as F
model = AutoModelForSequenceClassification.from_pretrained("distilbert/distilbert-base-uncased-finetuned-sst-2-english")
tokenizer = AutoTokenizer.from_pretrained("distilbert/distilbert-base-uncased-finetuned-sst-2-english")
inputs = tokenizer("I absolutely loved the movie, it was fantastic!", return_tensors="pt")
with torch.no_grad():
logits = model(**inputs).logits
probs = F.softmax(logits, dim=1)
idx = torch.argmax(probs, dim=1).item()
print(model.config.id2label[idx], probs[0][idx].item())
PY
もう一方は：
# 1コマンドで完了
transformers classify \
--model distilbert/distilbert-base-uncased-finetuned-sst-2-english \
--text "I absolutely loved the movie, it was fantastic!"
コスト、レイテンシ、トークン消費量、エラー発生率はまったく異なる。最終文字列だけを見るEvalでは、ライブラリへの変更（CLIの追加、エラーメッセージの改善など）がエージェントの動作を改善したかどうかを検証できない。
Hugging Faceはこの問題意識から、transformers を題材にしたエージェント向けベンチマークハーネスを構築・公開した。
ハーネスの設計：3つのティアと複数の評価軸
各タスクは以下の3つの「ティア」で実行される：
| ティア | 内容 |
|---|---|
bare |
pip install transformers のみ |
clone |
transformersのフルソースをワーキングディレクトリに配置 |
skill |
CLI向けにキュレートされたドキュメント＋タスク例をコンテキストに注入 |
この3つは入れ子関係にない。skill は clone を含まず、それぞれ異なる種類のヒントをエージェントに与える独立した条件だ。clone はソースコード全体を参照できる環境、skill はCLIの使い方に特化した情報をコンテキストとして渡す環境であり、情報の性質が根本的に異なる。そのため skill ＋ clone を組み合わせた場合と比較することで、「ソースを見せるか、使い方を教えるか」のどちらが有効かを切り分けられる設計になっている。
評価軸は以下の通り：
- **match %**：最終回答が期待結果を含むか（サブストリング／正規表現／完全一致）
- median time および median tokens（新規／キャッシュ済み／生成済みの内訳）
- **runs with error %**：出力がゼロのいわゆる「サイレント失敗」（エラーメッセージすら返さず処理が終わってしまう失敗）も検出する
- marker adoption：ツール側があらかじめ定義した振る舞い（例：CLIコマンドを使うこと）をエージェントが実際に採用した割合。match%が高くても marker adoption が低ければ、エージェントはツールを迂回して正解にたどり着いているにすぎない
実行基盤には Hugging Face Jobs を使い、モデル × リビジョン × タスク の全組み合わせを並列実行。全ランが同一ハードウェアで動くため比較が公平になる。トレースは agent-traces viewer で確認できる。
Hub上のagent-traces viewer：MiniMax-M2.7によるanswer-questionタスクの実行トレース
大規模モデルで見えたトレードオフ
大規模モデルはほぼ必ず正解にたどり着くため、match率ではなく「そこに至るコスト」を測るのが有意義だ。手法としては、モデルを固定してtransformersのリビジョンを変えていく。
CLIとSkillを導入したコミット前後で比較すると、Skillコミットはタスク完了時間を短縮した。
ティア別・リビジョン別の中央値時間：Skillコミット（緑点）が最速
一方で clone ティアでは、CLIを導入したコミット以降にトークン消費が増加した。
ティア別・リビジョン別の中央値新規トークン数：cloneバリアントはCLI導入後に急増
原因はトレースを読むと明快だ。CLIのコミットはコマンドだけでなく、cli/agentic/*.py の使用例もリポジトリに追加する。clone ティアでは約3分の1のランがこれらのファイルを読み込んでからCLIを呼ぶため、中央値インプットトークンが約4kから約6.4kに増加した。
つまり「時間は短縮、トークンは増加」というトレードオフが存在する。ただしこのトークン増はワーストケースに近い。現在の設定はワンショット実験用で、毎回新鮮なエージェントがCLIを再発見する。実際の利用ではエージェントはインターフェースを一度学習すれば同一セッション内で複数タスクをこなせるため、発見コストは分散される。
小規模モデルではmatch率が指標になる
小規模モデルではリビジョンを固定してモデルを変えるのが有効だ。モデルサイズ・量子化・トレーニングの違いが、特定ツールでのタスク遂行率にどう影響するかを測れる。
bare 環境（pip install transformers のみ）で「transformers を使ってXを実行せよ」と指示された小規模モデルは、CLIやSkillのような足場なしには正解率が大きく下がる。ここでtool surfaceの設計が直接match%に影響する。大規模モデルでは「コストの差」として現れていた問題が、小規模モデルでは「できるかどうか」という二値の差として現れる点が興味深い。
自分で試す方法
このハーネスは、CLIで操作できるツールであれば何にでも適用できる設計になっている。元記事には実装の詳細と、自前ツールに適用するためのセットアップ手順が記載されている。
また、hf CLIをエージェント向けに最適化した事例では、エージェントのトークン使用量が1.3〜1.8倍（最大6倍）削減された。今回のハーネスはその知見が他のツールにも適用できるかを検証するために構築されたものでもある。
詳細はIs it agentic enough? Benchmarking open models on your own toolingを参照していただきたい。
