結論から書きます。AIエージェントに社内の手順書を読ませれば必ず賢くなる、という前提は成り立ちません。Hugging Faceの実測では、手順書を同梱した構成で小型モデルの一致率が67%から43%に落ち、あるタスク単体では100%から0%になりました。効くかどうかは自社の実タスクで測るしかありません。
何が測られたのか（一次資料の実測）
Hugging Faceが公開した記事「Is it agentic enough? Benchmarking open models on your own tooling」は、AIコーディングエージェントを「成功したか失敗したか」だけでなく、「自社のツール上でどれだけ無駄なく仕事を終えられるか」で測ろうという趣旨の検証です。評価は3段階のティアで行われています。
| ティア | エージェントに与えた環境 | 位置づけ |
|---|---|---|
| bare | 対象ライブラリを pip でインストールしただけ | 最小構成。手がかりが少ない |
| clone | ソースコード全体をチェックアウトして渡す | 情報量は最大だが読む負荷も大きい |
| skill | 手順書をパッケージとして同梱する | 使い方を教えた構成 |
この3段階で同じタスクを走らせ、正解と厳密に一致したかどうか（match rate）と、生成された新規トークン量を比べています。主な実測値は次のとおりです。
- 1.3〜1.8倍（最大6倍）のトークン削減：新しいCLIとSkillを併用した場合の削減率。条件は hf CLI 上でのベースライン手法との比較で、対象は同一ハーネスで評価した複数のオープンモデル。期間・n数の明記はありません
- 67% → 43%：Qwen3-14B の一致率。bare構成（pipインストールのみ）から skill構成（手順書同梱）に変えた場合の、同一タスクセットでの比較
- 100% → 0%：Qwen3-14B の classify-sentiment タスク単体の一致率。clone構成（ソース全体をチェックアウト）から skill構成へ変えた場合の、単一タスクでの結果
- 約2,400トークン → 約23,000トークン：Qwen3-4B が生成した新規トークンの中央値。clone構成でCLI導入コミットを適用した際の変化で、中央値ベース
- 55.3%：テスト対象モデルにおけるCLIの採用率（実際にCLIを使った割合）。skill構成での集計で、対象モデル数の内訳は記載されていません
つまり、同じ「手順書を足す」という操作が、あるモデルではトークンを1.3〜1.8倍削減し、別のモデルでは正答率をほぼ半減させています。方向が逆に出ているというのがこの検証の中心的な事実です。
（出典：Hugging Face（本文中で自社ライブラリ transformers・hf CLI、および評価ツール agent-eval を扱う同社発信の公式ブログ）、2026-06-18、https://huggingface.co/blog/is-it-agentic-enough）
この数字は誰が出しているのか
読む前に押さえておくべき前提があります。この記事は Hugging Face 自身による発表であり、同社は評価対象である transformers ライブラリ・hf CLI、および評価ツール agent-eval の提供者そのものです。 自社製品を有利に見せる利害関係のある発信元が、自ら設計した評価軸で、自ら測って公開した数字です。
これは「だから信用できない」という話ではありません。むしろこの記事は、後述するとおり自社にとって不都合な結果も本文に書いています。ただ、評価の枠組み（3ティアという分け方、トークン量を主要指標に据えること）自体が発信元の製品設計に沿って作られている以上、その枠組みごと自社に持ち込んでよいかは読む側が判断する必要があります。発信元の立場を確認してから数字を読む習慣については、AIの回答品質と推論品質は別物か でも同じ論点を扱っています。
読者への意味：ベンチマーク上位は「うちで使える」を意味しない
中小企業の経営者・情報システム担当にとって、この実測が持つ意味は2つです。
1. 社内手順書を足しても、賢くなるとは限らない
「うちの業務マニュアルをAIに読ませれば精度が上がるはずだ」という期待は、実務でよく出ます。しかしこの検証では、手順書を同梱した構成で小型モデルの一致率が67%から43%へ落ちました。単一タスクでは100%から0%です。
原因として考えられるのは、手順書が増えることでモデルが処理すべき文脈が増え、小型モデルの処理能力を超えるという構造です。情報を足すことは、負荷を足すことでもあります。 大型モデルなら消化できる量が、小型モデルでは逆効果になる。安いモデルでコストを抑えつつ手順書で補う、という設計は、この結果を見る限り無条件には成立しません。
2. 同じ作業のトークン消費が10倍に振れうる＝料金が振れる
Qwen3-4B の例では、生成トークンの中央値が約2,400から約23,000へ変化しています。約10倍です。トークン量はそのままAPI料金です。同じ作業を頼んでいるつもりでも、構成が変われば請求額が一桁変わりうるということになります。
逆に言えば、条件が合えば1.3〜1.8倍（最大6倍）の削減も出ています。社内向けAI手順書の整備は、精度対策としてではなくコスト削減策として検証する価値がある、という読み方が実務的です。ただし検証してから、です。コストの見積もり方については AIの利用コストは何で決まるのか と コストを含めて評価する が参考になります。
結論として実務に落とすなら、PoCは自社の実タスク・実ツールで、小さく、実測ベースでやるしかありません。ベンダーのベンチマークで上位だから自社でも使える、という推論は、この記事の数字がまさに否定しています。自社基準での評価の組み方は 自社の評価基準を持つ で整理しています。
一次資料が自ら認めている限界
この検証には、記事自身が明記している制約が複数あります。都合の悪いものも含めて列挙します。
- 利害関係：前述のとおり、発信元 Hugging Face は評価対象のライブラリ・CLI・評価ツールすべての提供者です
- トークン増加は最悪ケースに近い：各実行はエージェントを毎回まっさらな状態として扱うため、計測されたトークン増加は「実運用で利用者が体感する値」ではないと本文が明言しています
- 決定論的タスクに限定：評価対象は正解が厳密一致で判定できるタスクのみです。要約や顧客対応のような、答えが一つに定まらない曖昧な業務タスクへ一般化することはできません
- モデル間の比較が難しい：モデルごとにタスクのカバー範囲が不揃いなため、公平な比較には「共通タスクのみ」に絞る操作が必要だと断っています
- セキュリティ上の注意：コード実行時に権限チェックを回避（bypassed permissions）しており、実行トレースにはプロンプト・出力・ローカルパスが含まれます。信頼できるローカル環境でのみ使うよう警告されています
- 効果がモデル規模に依存する：改善はモデル規模次第で、大型モデルでは処理時間の中央値が改善する一方、小型モデルでは悪化するという、発信元にとって不都合な結果が出ています
最後の項目は特に重要です。発信元が自社に不利な結果を消さずに書いているという点は、この記事の信頼性を上げる材料であると同時に、読者に対しては「あなたが使う規模のモデルでは効かないかもしれない」という直接の警告になっています。エージェントに与える道具や権限の設計については エージェントに渡すツールはどう進化してきたか も参照してください。
TOEの読み筋
ここからは株式会社TOEの見立てです。この検証と同じ手順をTOEでは未実施であり、以下は一次資料からの推論です。
第一に、社内AI導入の順番を変える材料になると見ています。よくある進め方は「モデルを決める → 手順書を書く → 展開する」ですが、この実測が示しているのは、手順書の効果がモデル規模に依存して逆転しうるということです。だとすれば、手順書を書き切る前に、候補モデル2つで最小の手順書を試して方向を確認するほうが手戻りが小さい。手順書の整備は工数のかかる仕事なので、書いてから効かないと分かるのが一番痛い。
第二に、トークン量を導入判断の指標に入れるべきだと考えています。多くのPoCは「できた／できない」で終わりますが、この記事の枠組みは「どれだけ無駄なく終えたか」を測っています。同じ結果に至るのに10倍のトークンを使うエージェントは、月次の請求書で差が出ます。PoCの評価シートに「所要トークン」の列を1本足すだけで、運用に入ってからの想定外がかなり減るはずです。
第三に、セキュリティの扱いです。一次資料が権限チェック回避を前提にしている点は、そのまま社内に持ち込めない条件です。エージェントにファイル操作やコマンド実行をさせる構成を検討する場合、実行トレースに社内パスや入力内容が残ることを前提にした保管ルールが要ります。ここは技術検証とは別に、先に決めておくべき部分だと見ています。
いずれもTOEでの実測結果ではなく、一次資料から導いた仮説です。実際に検証した際は、数字とともに改めて記事にします。
まとめ
- Hugging Faceの実測で、手順書（Skill）を同梱した構成に変えたところ Qwen3-14B の一致率が67%から43%へ低下し、classify-sentiment タスク単体では100%から0%になった（同一タスクセットでの比較）
- 同じ作業でも構成が変わればトークン消費は約2,400から約23,000（中央値）へ振れうる一方、条件が合えば1.3〜1.8倍（最大6倍）の削減も出ており、そのままAPI料金の変動になる
- この記事は Hugging Face 自身による発表であり、同社は評価対象の transformers・hf CLI・agent-eval すべての提供者である。数字の出どころとして前提に置く必要がある
- 一次資料は、トークン増加が実運用の体感値ではないこと、決定論的タスクに限定されること、小型モデルでは処理時間が悪化することなど、自社に不都合な限界も明記している
- TOEでは同じ検証を未実施だが、PoCの評価シートに「所要トークン」の列を足すこと、手順書を書き切る前に最小構成で方向を確認することを、実務上の打ち手として推している