私のAIエージェントが、私のAIエージェント用のベンチマークツールを作りました

かんたんに言うと: 私のAIコーディングエージェントが、ローカルで動作するモデルの処理速度や簡単なタスクをこなせるかどうかをテストするためのPythonファイル「bench-llm」を作成しました。このツールは今でも利用可能で、無料でダウンロードできます。しかし2週間もするとあまりにも簡単すぎるようになったため、私はこれをより大規模な無料ツールであるCrucibleForgeに置き換えました。CrucibleForgeでは251個の質問が用意されており、モデルが生成したコードを実際に実行して検証することができます。

自分の環境で実装したい? おすすめの方法: 下のファイルを手元にコピーして、LLM(Claude、ChatGPT、ローカルモデルなど)に渡し、あなたの環境に合わせて実装してもらってください。 LLMアシスタントが初めての方は、セットアップガイド(Claude Code、Cowork、Reasonix、DeepSeek)をどうぞ。

自分で用意するもの

Python 3.8以降とpip（またはuv）
LM Studioがローカル環境で実行されており、少なくとも1つのモデルがlocalhost:1234上に読み込まれている状態です。
Pythonのパッケージ2つ：pip install openai requests

LLMに任せられること

bench-llmをダウンロードし、2つの依存ライブラリ（openai、requests）をインストールした後、--listを実行してモデルが表示されることを確認してください。
各モデルに対して--quickスモークテストを実行し、その後比較したい2～3つのモデルについて完全なベンチマークを実施します。
~/benchmarks/にあるJSONの結果を読み込み、速度、能力、エージェントの適性の面でどのモデルが勝っているかを要約してください。

コピペで使えるプロンプト:

まず https://www.laserlloyd.com/ja/projects/bench-llm-ai-agent-built-benchmarking-tool/ を取得して読んでください。このプロジェクトの詳細な手順・設定・注意点がすべて載っています。 私のマシン上にbench-llmをセットアップし、LM Studioに保存しているモデル群に対して実行したいと思います。必要な2つのPythonパッケージ（openai、requests）をインストールし、保有しているモデルの一覧を確認します。その後、各モデルに対して--quickオプションを適用し、最も性能が良い3つのモデルについては完全なベンチマークも実行します。得られたJSON形式の結果を確認し、最も速いモデル、汎用的に最も優れたエージェントとして機能するモデル、そしてツール呼び出し用途には不向きなモデルはどれかを教えていただきたいです。最後に、比較表もご提示ください。

2026年8月11日、私は自身のコーディングエージェントに対し、私のエージェントスタック内で利用可能なローカルモデルをベンチマークするツールを作ってほしいと依頼しました。するとエージェントは bench-llm というツールを提示してくれました。これは1,660行からなるPythonコードで、LM Studioにおける処理速度を測定したり、モデルが生成したコードを実際に実行したり、そのモデルが簡単なエージェントタスクに対応できるかどうかも確認します。2週間もしないうちに、私が気にしていたすべてのモデルがこのテストで5点満点を獲得したため、私はそれを CrucibleForge として再構築しました。現在では251種類のテストケースがあり、そのうち158個が難易度の高いものです。このツールは現在GitHubにてオープンソースとして公開されています。本ページでは両方のツールについて解説しています。まずは5分程度でモデルの性能を把握したい場合は bench-llm をご利用ください。簡単なテストをすべてクリアしたモデル同士を比較・ランキング付けしたい際には CrucibleForge をご利用ください。

要約

bench-llm：単一のPythonファイルで、無料でダウンロード可能です。速度（最初のトークンが出るまでの時間やトークン生成速度）、能力（コード生成・論理的推論・JSON処理・指示の理解・要約作成という5つのテスト）、そしてエージェントとしての適性（システムログ処理に関する3つのチェック）を測定します。Python 3.8以降、pip install openai requests および LM Studio が必要です。
廃止理由：能力テスト5種類とエージェントチェック3種類だけでは、優秀なモデルがすべてをクリアした時点でそれ以上の差別化ができなくなるためです。
CrucibleForge：251種類のテストケースがあり、うち158個は難易度が高いものです。コードはサンドボックス内で実行され、その結果に基づいて採点されます。OpenAI互換の任意のエンドポイントに対応しており、WebベースのGUIも備えています。MITライセンスで配布されており、github.com/LaserLloyd/CrucibleForge から入手可能です。
難易度の高いテストでの結果：DeepSeek V4 Proは客観的評価が必要な難易度の高いケースのうち93%をクリアしました。私の環境で使用している27B規模のローカルモデル群でも88%のクリア率でした。

更新履歴：2026年8月26日に bench-llm は廃止され、その結果データは後継スイートへ移行しました。2026年9月16日には CrucibleForge の説明部分を書き直し、保存済みの実行ログからランキング表を再構築し、表紙画像も新しく描き直しました。

最終的に得られるもの

1つのコマンドを1つのモデルに対して実行すると、次のような出力が得られます（実行例を要約したものです）：

$ bench-llm gemma-4-31b-it

  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Size:     16.5 GB     Quant: Q4_K_M

  ⚡ SPEED BENCHMARKS
    short_50    TPS: mean=84.2   TTFT: mean=0.231s
    medium_200  TPS: mean=85.7   TTFT: mean=0.312s
    long_800    TPS: mean=82.1   TTFT: mean=0.541s
  🔍 Validating speed plausibility...  Confidence: HIGH

  🧠 ABILITY TESTS
    Code Generation (median_of_list)... PASS
    Logic Puzzle (Pet Ownership)....... PASS
    JSON Compliance.................... PASS
    Instruction Following.............. PASS
    Summarization (Key Facts).......... FAIL
    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
    Task Acknowledgment / Format Adherence / Conciseness: PASS
    Agent Fitness Score: 3/3

  📄 Results saved: ~/benchmarks/gemma-4-31b-it-2026-08-11.json

このJSONファイルには、すべての処理時間のデータや各モデルの応答内容、そして要約情報が含まれています。このファイルをエージェントに渡して、「どのモデルが大量のJSON処理を行うのに適しているか？」と尋ねることも可能です。

bench-llmがテストする項目

速度

まず、約50文字、200文字、800文字の3種類のプロンプトを送信し、ウォームアップ処理を行った上で、3つの指標を測定します。TTFT（最初のトークンが出るまでの時間）は、テキストが表示されるまでにどれくらい待つ必要があるかを示します。500ミリ秒を超えるとチャットが遅く感じられます。スループット（トークン/秒）は、処理が開始された後の出力速度です。プリフィル速度は、プロンプトの読み込み速度を表します。

また、既知のハードウェア制限に基づいた妥当性チェックも実施します。例えば、30GB規模のモデルが7900 XTX上で200トークン/秒という数値を記録した場合、bench-llmはその数値を異常値として警告します。これは、投機的デコードやキャッシュの影響で数値が歪んでいる可能性があるためです。

能力

コード生成： median_of_list(numbers)という関数を、各種境界条件も考慮して記述します。bench-llmはテキスト内容を読むだけでなく、6つのテストケースに対してその関数を実際に実行します。
論理パズル： 4人がそれぞれペットを飼っているという状況に関する問題です。チェッカーは返答から4人の飼育状況をすべて抽出します。
JSON準拠性： 指定されたキーを持つオブジェクトを返す必要があります。これはツール呼び出しを行うための最低限の要件です。
指示の遵守： 1から10までを列挙し、偶数のみに印を付けてその合計値を求めます。計算自体は簡単ですが、フォーマットがテストのポイントとなります。
要約作成： 内容が詰まったパラグラフを要約し、6つの重要な事実を保持させます。ほとんどのモデルでは少なくとも1つは情報が失われてしまいます。

エージェントとしての適性

モデルには現実的なエージェントタスクが与えられます。具体的には、syslogからERROR行を検索し、サービスごとにグループ化した上でJSON形式のレポートを返すというものです。この1つの返答に対して3つのチェックが行われます：

タスクの理解度： 対処法を説明し、自分ではできないことも明示しているかどうかです。架空のsyslog行を作り出すようなモデルは不合格となります。
フォーマットの遵守： servicesという配列や、total_errorsという整数値、scan_periodという文字列が含まれているか確認します。
簡潔さ： 出力量と入力量の比率をチェックします。1,300文字程度のプロンプトに対して20,000文字もの返答がある場合は「冗長」として判定されます。エージェントが余計な内容を述べすぎると、各ステップでコンテキストウィンドウが埋まってしまうためです。

どのようにして作られたか

私がコーディングエージェントに出した指示はたった一言でした。「LM Studio上でローカルモデルのベンチマークを行い、処理速度や性能をテストし、JSON形式および表形式の結果を出力するツールが必要だ。」するとそのエージェントは午後のうちに4回の作業を経てそのツールを作成してくれました。まずLM Studioが提供するOpenAI互換のストリーミングAPIを使った速度テスト、次に機能面のテスト、さらにエージェント用タスクの実装、最後に細部の調整（ディスク上からGGUFファイルを探し出す処理や妥当性チェック、--quick、--list、--checkといったオプションの実装）を行いました。すべてのコードはエージェントが書いたものです。私がしたことは、実際のモデル上でそのツールを実行し、フィードバックを返すことだけでした。妥当性チェック機能があるのは、123B規模のモデルではあるスループット値が物理的に不可能だとエージェントに伝えたからです。

自分のツール作りにも参考にすべき設計上のポイントは以下の通りです：

ポーリングではなくストリーム処理を使う。 トークンごとの処理時間を計測するのが、正確なTTFT（最初のトークンが返されるまでの時間）を得る唯一の方法です。
コードは必ず実行してみる。 見た目は完璧そうでも実際に動作しないコードは失敗であり、合格とは言えません。
チェックを行う前に答えを抽出する。 チェッカーは「もちろんです！答えは以下の通りです：」といった前置き部分を取り除きます。そうすることで、テストでは前置きではなく内容自体が評価されるのです。
各実行時には必ずGPUを空状態にする。 前回のモデルのキャッシュが残っているとTTFTの数値が歪んでしまいます。bench-llmがこれをどう実現しているかが、下記の注意点第一項となります。

セットアップ

# 1. Install both dependencies (requests reads LM Studio's model metadata;
#    without it every model shows as "not found")
pip install openai requests

# 2. Start LM Studio with at least one model; it listens on localhost:1234

# 3. Run it
./bench-llm --list                         # what's available
./bench-llm gemma-4-31b-it --quick         # smoke test
./bench-llm gemma-4-31b-it                 # full benchmark

設定用のファイルやデータベースは存在しません。LM Studioでは、任意の文字列をAPIキーとして受け付けます。処理結果は ~/benchmarks/ に保存されます。どこからでもスクリプトを実行したい場合は、PATHに含まれるフォルダーにそのスクリプトをコピーしてください。

注意点

llama-serverが停止してしまいます。 各実行の前に pkill -f llama-server を呼び出し、LM Studioから「読み込まれているモデルがゼロ」という報告があるまで待機します。そのため、マシン上で動作中の他の llama-serverもすべて停止してしまいます。他のサービスも稼働しているマシンでは実行しないか、その処理を省略してください。
コーディングテストでは exec() を使ってモデルの出力を実行します。 新しい名前空間が使用されますが、これはサンドボックスではありません。失っても問題ないユーザー権限で実行するか、--speed-only オプションを使って機能テストをスキップしてください。
推論用モデルは動作が遅く見えます。 TTFTの計測では、思考内容を含むあらゆる種類の最初のトークンがカウントされます。JSONではそれが ttft_reasoning_s と ttft_content_s に分けられて記録されます。
要約機能のみ失敗している状態でスコアが4/5というのは優秀な結果です。 ほとんどのモデルは少なくとも1つは事実を正しく認識できていません。
1つのモデルにつき完全なテストには2〜5分かかります。 多数のモデルを比較したい場合は --quick オプションを使い、最終的に残ったモデルだけで本格的なテストを行ってください。
LM Studioは事前に起動済みである必要があります。 bench-llmは localhost:1234 に接続するだけで、自ら何かを起動することはありません。

結果：私のラグとミニPCにおけるベースモデルの性能

これらの数値は、bench-llmに続いて実施された中間テストスイートから得られたものです（速度測定方法は同じで、より多くのテストを行い、2026年8月18日に報告されました）。「ラグ」とは、RTX 5090を2基およびRTX 3090を2基搭載したヘッドレス仕様のGPUボックスです。「APU」とはミニPCに内蔵されている統合型GPU（ローカルモデルサーバーがまだ動作していた時期のもの）を指します。速度の比較は、同一デバイス内でのみ行ってください。Code、Tools、Instruct、Reasonはそれぞれパス率を示しています。

モデル	デバイス	トークン生成速度	TTFT	Code	Tools	Instruct	Reason
Gemma 4 26B-A4B (QAT, Q4)	ラグ	229.0	110 ms	88%	100%	50%	95%
Nemotron 3 Nano 4B (Q8)	APU	18.5	175 ms	92%	70%	94%	95%
Gemma 4 12B	APU	10.1	633 ms	—	—	—	—

Gemma 4 26Bのミックスド・オブ・エキスパーツモデル（実際に使用されるのは4Bのみ）は、ラグ上で日常的に利用されているモデルです。トークン生成速度は229 T/s、最初のトークンが出るまでの時間は110 msであり、ツール呼び出しの成功率も100%と優れています。ただし、指示の遵守という点ではやや弱く、これは無監督エージェントループにおいて最も重要な要素です。一方でミニPC上の4B版Nemotronは指示の遵守率が94%と高く（50%に対して）、性能は約12倍遅いものの（18.5 T/s対229 T/s）別のデバイス上で動作します。したがって、最も速い数値だけでなく、ご自身のワークロードにおいてどの項目が重要かを基準にモデルを選ぶべきです。

後継品：CrucibleForge

bench-llmは成功のあまり役目を終えてしまいました。5つの能力テストだけでは、すべてのモデルが5/5や3/3という高得点を取ってしまうため、もはや評価する余地がなくなってしまうのです。CrucibleForgeはその後継品です。Pythonで書かれており、コード行数は約9,400行ほどです。その設計原則としては「難しい問題であっても、採点は容易でなければならない」というものがあります。

難易度の高いケースが158件。 整数で答えが出る競技用数学問題、一意な解を持つ論理パズル、適切な計算量を満たすかどうかをチェックするコーディング問題（例：O(n²)の逆順数計算は時間切れとなる）。また、偽のツールやプロンプトインジェクションを仕掛けた利用法のテスト、12,000～24,000トークンに及ぶ長文文脈の検索問題、複数の制約条件を含む指示も用意されています。
コードは実際に実行して採点される。ネットワーク接続が不可で読み取り専用のシステム環境下において、bwrap サンドボックス内でコードを実行します。実行時間は15秒までです。合格条件としては標準出力に特定の文字列が含まれている必要があり、ゼロ終了コードを返すだけでは成功とみなされません。bwrap が利用できない環境（macOSやWindowsなど）では、--allow-unsandboxed オプションを指定しない限りモデルコードの実行は拒否されます。
文章形式の回答には正解例が存在する。判定用モデルは正解例を見て、応答内容がそれと同じ意味を持つかどうかだけを判断します。優秀な指示適応型モデルであればこれくらいは実行可能なため、判定部分が弱点になることはなくなります。
OpenAI互換の任意のエンドポイントに対応。LM Studio、Ollama、llama.cpp、vLLM、DeepSeek、OpenRouterなどが利用できます。ホスティング型モデルであれば複数のケースを並列実行し、トークン使用量も報告されます。APIキーは環境変数からのみ取得します。
思考型モデルが見失った回答も回復可能。思考に全計算リソースを費やしてしまい空の回答しか返さないモデルも存在します。このツールではそうしたケースを検知し、思考機能をオフにして再度問いかけ、その頻度を記録します。recover コマンドを使えば、過去の実行結果から該当する行だけを再実行できます。
GPU資源も適切に共有される。私が所有する StudioForge マシンでは、実行処理が必要なGPUを専有し、終了時には他のプロセスへそのリソースを返却します。これに対して bench-llm では pkill を用いて全モデルを強制終了させることで同じ目的を達成していました。
Web GUIも備わっている。127.0.0.1:8777 からアクセス可能なGUIでは、モデルやカテゴリの選択、ログの閲覧、失敗したケースの詳細（プロンプト、応答内容、思考過程、判定コメントなど）を確認できます。ループバック以外からの接続を受け付けるには事前に認証用トークンが必要です。

試してみる

git clone https://github.com/LaserLloyd/CrucibleForge.git crucibleforge
cd crucibleforge
uv sync
uv run crucibleforge config --init      # writes models.yaml; add your provider and model
uv run crucibleforge status             # is the provider up? how many cases?
uv run crucibleforge all --profile standard --models my-model --yes
uv run crucibleforge gui                # http://127.0.0.1:8777

standard プロファイルは、27B規模のモデルで約70トークン/秒の速度であれば1時間以内に終了できるよう設計された56件のテストケースから成ります。繰り返し実行しても問題ない規模です。さらに coding 用と chat 用に分かれており、前者には判定用モデルが不要、後者には判定処理が含まれます。その他のコマンドとしては run、judge、recover、report、pairwise、models、import-openclaw、cases が用意されています。

私が最も信頼しているコマンドは、問題自体を検証するものです。このコマンドでは各参照用ソリューションをサンドボックス内で実行し、数学問題の答えは全件ブルートフォース法で再導出し、長文文脈処理用のデータも再構築します。2026年9月16日時点でのその出力結果は次の通りです：

$ uv run crucibleforge cases verify
251 cases checked, 0 with problems (36 reference solutions executed, 35 answers re-derived)

合計335件からなるテストスイートでも同様の検証が行われるため、問題に不備があってもすべてのモデルで静かに失敗し、難易度の高い層でも合格してしまうような事態は起こり得ません。

レポートの例

report コマンドによりMarkdown形式およびJSON形式のファイルが生成されます。各モデルごとに要約行とカテゴリ別の集計行が作成されます。以下は DeepSeek V4 Pro におけるカテゴリ別の集計行です：

| Model        | Coding      | Math        | Tool use    | Instruction  | Reasoning    | Long-context |
| deepseek-pro | 89% (54/61) | 95% (21/22) | 94% (31/33) | 100% (31/31) | 100% (37/37) | 97% (29/30)  |

失敗したケースはその理由と共に一覧表示されます。コーディング関連で失敗した7件はすべて下記の最初の行のような状態です。2番目の行はツール利用に関する2件の失敗例のうちの1つです：

- deepseek-pro [coding] CZ01-prime-census: TRUNCATED at 32768 tokens (32768 reasoning tokens); no code in response
- deepseek-pro [tooluse] TZ06-three-parallel-one-turn: 1 calls, expected 3

ここが最も有益な点です。このモデルは悪いコードを書いたわけではなく、32,768トークンという制限に達するまで思考を続けた結果、結局何も記述しなかったのです。計算リソースや思考努力度を増やせば得点も変わるでしょう。単なる合格率だけではこの事実を知ることはできません。

難易度の高いケースにおける結果

これらは全251ケース、あるいはほぼ全てのケースを対象としたテスト結果です。「Hard %」とは、難易度の高い154個のケースに対する合格率を示しています（全158ケース中4つは評価不能）。「Code」「Math」「Tools」はそれぞれ該当カテゴリー内の全ケースにおける合格率です。56ケースのみを対象としたテスト結果は、難易度の高いケースにたった38個しか対応しておらず比較が難しいため掲載していません。また、エージェント作業には関係ないロールプレイや成人向けコンテンツに関するスコアも本報告からは除いています。

モデル	利用場所	Hard %	Code	Math	Tools	生成速度 tok/s	コスト $
DeepSeek V4 Pro	API	93%（154中143件）	89%	95%	94%	61.6	1.10
DeepSeek V4 Flash ¹	API	90%（154中138件）	87%	91%	91%	82.2	0.331
Qwen3.8 27B (Q5_K_S) ¹	ローカル環境	88%（154中135件）	85%	91%	88%	143.5	—
dark-scarlett-27b-v2	ローカル環境	88%（154中135件）	80%	86%	91%	65.7	—
dark-scarlett-31b	ローカル環境	86%（154中133件）	90%	86%	91%	43.1	—
MiniMax M3 ²	API	85%（153中130件）	82%	77%	85%	212.1	1.07
qwen3.8-27b-abliterated	ローカル環境	79%（154中122件）	62%	77%	91%	97.0	—
joyfox-35b-rp	ローカル環境	75%（154中116件）	72%	77%	76%	319.1	—
gemma-e4b-uncensored ³	ローカル環境	69%（140中97件）	61%	64%	88%	221.6	—
muse-glimmer-30b	ローカル環境	57%（154中88件）	57%	64%	76%	71.9	—
Qwen2.5 1.5B ¹	ローカル環境	29%（154中45件）	28%	5%	58%	624.1	—
Qwen2.5-VL 7B	ミニPC	18%（154中28件）	15%	0%	12%	18.8	—
SmolVLM 256M ³	ローカル環境	3%（140中4件）	0%	0%	6%	959.2	—

小文字で記載されているモデル名はコミュニティによる微調整版や改変版であり、登録名のまま掲載しています。印のない行は2026年9月16日に保存済みのテストデータから再計算した結果です。各テストは複数のバージョンのケースセットを対象としているため、1〜2ポイント程度の差は誤差と見なして構いません。¹ 2026年8月25日付の報告に基づきます。その後実施された56ケースのみを対象としたテストでこれらのモデルの全セット結果が置き換えられました。以前のバージョンではV4 Flashのスコアが272/308と記載されていましたが、これは2回分のテスト結果が同一ラベル下にまとめられていたためです。上記の0.331ドルは1回分の実行コストです。² MiniMax M3はMiniMax社が提供するホスティング型モデルです。1つのケースは評価不能であり、コストも参考値にすぎません。私は定額制プランを利用しているため、登録ファイル内の仮定レート（入出力トークン100万個あたり0.255ドル／1.02ドル）を用いて算出しています。MiniMax社の公表価格（0.60ドル／2.40ドル）で計算すると約2.4倍になりますが、現在実施中の半額キャンペーンを適用すれば約1.2倍となります。³ これらのモデルは154個中140個の難易度の高いケースを処理できました。残りのケースには十分なコンテキスト情報が含まれていなかったためです。

私がこの結果から得た知見は以下の通りです：

ホスティング型モデルは1回の実行に約1ドルのコストで済みます。 V4 Proは154個中143個の難易度の高いケースをクリアし、そのコストは1.10ドルでした。この金額であれば、ローカル環境での結果が良すぎると感じた際にも再実行するのに十分安価です。
27B規模のモデルでもほぼ同等の成績が得られます。 Qwen3.8 27Bは135個をクリアし、V4 Flashから2ポイント差でしかありません。また生成速度も1.7倍速いです。
速度と能力は必ずしも比例しません。 MiniMax M3は212 tok/sという最速の生成速度を誇るホスティング型モデルですが、全体のスコアは85%にとどまり、特に数学分野では77%と弱さが見られます。またjoyfox-35b-rpは319 tok/sで動作しながらも75%のスコアしか得られていません。
モデルの改変にはプログラミングの手間が伴います。 調整済みのQwen3.8 27Bでは、コーディング分野のスコアが62%まで低下してしまいました。一方で元のモデルでは85%を記録していました。
長いコンテキスト処理能力だけでは実力は判断できません。 1.5B、7B、256Mといった規模の小さいモデルでも、コーディングや数学分野での成績が著しく低下した後でも、それぞれ83%、80%、56%という高い精度で目的の情報を抽出できています。

ダウンロード

ダウンロードできるのはbench-llmという、現在は使われていない元々のバージョンです。CrucibleForgeではありません（CrucibleForgeはGitHub上に存在します）。ZIPファイルには2つのファイルが含まれています：1,660行からなるスクリプトであるbench-llm、そして設定方法が簡潔に記載されたREADME.mdです。これら2つのファイル以外にビルドやインストールの必要はなく、解凍して実行するだけです。両ファイルとも本エージェントによって作成され、MITライセンスが適用されています。依存パッケージはopenaiおよびrequestsです。他のサービスも同時に稼働しているマシン上で実行する前には、注意点を必ずお読みください。

関連情報：StudioForge（これらのモデルがGPUリソースを借りているサーバー）、AIエージェントの実際のコスト（なぜローカルでの処理速度が重要か）、DeepSeek Harness（これらのモデルを支援するコーディングエージェント）、およびローカルAIエージェントスタックです。

ダウンロード

Download bench-llm, the original single-file script (zip — retired, still works) 18 KB

個人利用は無料です。役に立ったら、コーヒーをおごってもらえると嬉しいです。