かんたんに言うと: MakoBenchは、言語モデル用の公開スコアボードです。各モデルは同じテストに答えます。コード部門は10点、チャット部門も10点で、合計点はその2つを足した値になります。各パートで90％以上の得点を達成したモデルには、さらにポイントが加算される難易度の高いボーナスセットが開放されます。このページでは、各ステップが図解で示されています。
GitHub で CrucibleForge を開く
要約です
- 共通のテストが1つだけあります。 すべてのモデルが同じ標準的なケースに答えます。コード部分は10点、Chat部分も10点となり、標準テスト全体での合計点は20点です。
- コードは実行され、Chatは評価されます。 コードの回答は隠されたテストにも対応します。評価用モデルがChatを採点し、その根拠となる証拠も引用する必要があります。
- 各得点には許容範囲があります。 互いの得点がその範囲内にある場合、順位に関係なく引き分けとなります。
- ボーナスセットでは10点を超えることもあります。 あるセクションで90％以上の得点を獲得すると、より難易度の高いボーナスセットが解除されます。各セットで最大1点が加算されます。
- 拒否した場合には一切点は与えられません。 このテストは、モデルが求められた際に何を行うかを測定するものです。
- エンジンはオープンソースです。 GitHub上のCrucibleForgeが全体の処理を実行しており、皆様も自身で実行することが可能です。
解説例では、2026年11月7日に公開されたスイート4.0の仕様を使用しています。スイート4.1では正答率が修正され、すべてのモデルの得点が再計算されています。採点基準やボーナスセットのルールは変わっていません。スイート4.1で何が変更されたかに詳細と新しい得点が記載されています。
MakoBenchとは何か
すべてのモデルが同じ6つのステップを経ます。
MakoBenchは、ローカルで利用可能なモデルやホスティングされているモデルを対象とした公開用の順位表であり、すべてのモデルが同一の方法で評価されます。このシステムでは、実際に動作するコードを作成することと、役割演技や対話形式の会話を行う能力の2点が測定対象となります。MakoBenchが何をテストし、何をテストしないかに詳細な内容が記載されております。
この評価エンジンは CrucibleForge という無料かつオープンソースのツール（MIT-0ライセンス）です。CrucibleForgeをご自身のモデルで利用するための手順に従えば、自分の環境でも実行可能です。
スコアの算出方法
一度に一つのケースのみ
実際のケース例：ツール利用ケースTZ19におけるClaude Sonnet 4.5の応答、スイート4.0です。
一つのケースとは一つの課題を指します。例えば書くべき関数や予測すべきプログラムの出力、ツールを用いた対話、あるいは長時間にわたるロールプレイセッションなどです。各ケースは隠されたテスト群や対話の各ステップといった小さな単位で採点されるため、ほぼ正しい答えであれば大部分の得点を獲得できます。標準的なケースはそれぞれ一度だけ実行されます。
詳細については、評価対象となるケースの一覧および採点用コード（graders.py）をご覧ください。
審査員がチャットの返答をどう採点するか
審査員は必ず根拠を示さなければなりません。実際の引用文がない「はい」は「いいえ」とみなされます。
コードには判断を下す必要がありません。しかしチャットにはそうした判断が求められますので、別の言語モデルである審査員モデルが各返答に対してはい／いいえで答えるのです。この例では私たちのGPU環境上でGemma 4 31B（検閲なしの「異端派」ビルド、Q8版）を使用しています。Q8とは重み情報が8ビット形式で保存されていることを意味します。「はい」という回答が有効となるためには、返答文中から正確な引用文も提示されなければならないのです。なぜなら審査員モデルは「はい」と答えやすい傾向があるからです。各バッチ処理の前に、審査員モデルはあらかじめ正しい返答を正しく認識し、間違った返答も正しく見分けられる必要があります。そうでなければそのバッチ処理は中断されます。
ある質問が単独で判定を失敗させる可能性がある場合、その質問は3回繰り返されます。過半数の「はい」回答が得られたときのみ合格となり、同数の場合は「いいえ」とみなされます。
詳細については、審査員モデルのコード（judge.py）およびチャットセッションの仕組みをご覧ください。
コードとチャットを合わせて総得点が決まります
各バーはそれぞれの項目を表し、得点の割合に応じて描かれています。
各項目はそれぞれの得点の割合に応じた点数を獲得します。例えば「関数」は76％に相当し、5点中3.8点となります。これらの得点を合計することでコードおよびチャットの得点が算出されます。別途用意されている成人向けテストもありますが、こちらは本総得点には含まれません。
詳細につきましては、設定ファイル（bench.yaml）に各項目やその得点、課題内容が記載されております。
±マージンについて
この±の値は、どのケースがセットに含まれるかによって総合スコアがどの程度変動するかを示しています。ヒストグラムの形状はあくまで例示です。
少しだけ異なるケース群を用いれば、総合スコアも若干異なった値になる可能性があります。このマージンがその変動幅を示しているのです。マージンよりも近い数値を持つ2つのモデルは統計的には同等とみなされます。ただしこのマージンでは実行ごとの誤差までは考慮されていませんので、1～2ポイント程度の差がある場合も同等と見なして構いません。
詳細：マージン算出のコード（headline.py）。
スコア表の読み方
クラスとは大まかな区分です。マージン値がクラスの境界線をまたぐ場合、そのモデルのクラス判定は微妙な状態となります。数値は4.0版のスコア表から引用したものです。
| 記号 | 意味 |
|---|
| クラス | 16以上でS、13以上でA、10以上でB、それ未満はCとなります。 |
|---|
| 傾向 | スコア表上のチャットおよびコードの平均値と比較して、一方が他方より1.5ポイント以上高い場合「チャット寄り」または「コード寄り」となります。そうでなければ「バランス型」です。 |
|---|
| 部分実施 | すべてのテストが完了していない状態です。数値は表示されますが、総合スコアやクラス、順位は算出されていません。 |
|---|
| 暫定値 | 検証環境のチェックに失敗したため、テスト結果が正確でない可能性があります。再実行まで順位やクラスは判定されません。 |
|---|
| (セット1) | ボーナスポイントが含まれる部分です。数値は獲得した最高レベルのボーナスを示します。 |
|---|
| MAX | 特定のパートにおける標準問題およびすべてのボーナスセットで90％以上の成績を収めた状態です。これ以上難しい課題は存在しないため、新たなセットが用意されることになります。 |
|---|
実行コストやBuilt onといったその他の項目については、MakoBenchドキュメントページおよびREADME内のスコア表に関する説明をご覧ください。
例：標準セットにおけるClaudeの成績
各棒グラフがそれぞれの評価項目を表しており、塗りつぶされた部分がそのモデルが獲得した得点、点線が90％を示しています。この結果は2026年11月7日に公開されたSuite 4.0ボードに基づくものです。
Claude Sonnet 4.5は標準セットのみを対象として評価を受けました。以下が各項目の得点算出方法となります。
| 項目 | 判定基準となるケース | 得点 |
|---|
| 関数 | 隠されたテストグループでの正解率：CL3が1.00、CL4が0.69、CL5が0.40、CL6が0.89、CL7が0.77、CL8が0.79。平均値は0.76です。 | 0.76 × 5 = 3.8 |
|---|
| 予測およびバグ探し | 出力を予測する課題が2つ（CB-C5、CB-C6）あり、正解率は31％で重みは2となります。バグ探し課題も1つ（CB-F1）ありますが、得点は0で重みは1です。（2 × 0.31 + 0）÷ 3 = 0.21となります。 | 0.21 × 2.5 = 0.5 |
|---|
| ツール使用 | 正解した手順数：TZ16では6中3、TZ19では11中7、TZ20は全問正解です。平均値は0.71となります。 | 0.71 × 2.5 = 1.8 |
|---|
| チャット関連項目 | 各項目につき2回の評価セッションが行われました。 | 2.0 + 2.0 + 1.3 + 1.4 = 6.7 |
|---|
総合得点は6.1 + 6.7 = 12.8 ± 1.1点で、クラスBとなります。最も高い成績を収めた「関数」でも76％にとどまり、ボーナスセットが解放される90％には達していません。そのためすべてのボーナスセットはロックされたままで、得点は標準セットのみに基づくものとなります。このボード上にあるほとんどのモデルも同様の状況です。
ボーナスセット
ボーナスセットが解除される仕組み
上から下へと進む一つのパートの流れです。CodeおよびChatでは各パートごとにこのようなフローが存在します。
ボーナスセットとは、あるパート用に用意された難易度の高い問題群で、通常は3問から成ります。CrucibleForgeではこれらを「ラダーパック」と呼んでおり、そのルールは以下の通りです。
- 解除条件。 あるレベルのセットは、そのパートの標準的な問題およびそれより低いレベルのすべてのセットにおいて90％以上の得点を獲得した場合にのみ解除されます。
- ロック中・解除済み・保留中。 ロック中：まだ獲得していない状態。解除済み：獲得済みで実際に実行される状態。保留中：獲得済みだがまだ実行または判定されておらず、現時点では0点としてカウントされる状態です。
- 1セットあたり最大1点。 各セットの問題群はその1点を共有し、部分的な正解も加点されます。例えば3問中2問正解で約0.67点が加算されます。同一問題が2回実行された場合は、その得点の平均値が採用されます。
- レベル制。 同じレベルのすべてのセットがまとめて解除され、それぞれがパートの得点に加算されていきます。
バージョン4.1現在ではすべてのセットがレベル1となっており、Codeには各パートごとに3つのセット、Chatには5つのセット（「Deep role-play」には2つ）が存在するため、Codeでは最大13点、Chatでは15点まで得点を伸ばすことが可能です。また、標準的なケースがまだ用意されていないパートでは、そのセットは一切解除されません。
詳細情報としては、ボーナスセットのルール、解除処理を担うコード（ladder.py）、および公開されているボーナスセット一覧をご参照ください。
例：ボーナスセットが解除されるモデル
スイート4.0用ボードから得られた実際の数値および記録された解答内容です。
DeepSeek V4 Flashは6つの標準Functionsプログラムすべてを無事にクリアしたため、「Functions」用のボーナスセットが解除されました。このセットにはゼロから作成された3つの難易度の高い問題があり、それぞれ2回ずつ実行されます。そのうち1問は、6つのテストグループ中4つを1回目で正解しましたが、2回目では0点だったため得点は0.33となります。このセット全体の平均値は（0 + 0 + 0.33）÷ 3 = 0.11となります。その他の「Code」および「Creative writing」用のセットもそれぞれ解除されました。「Code」の得点は11.2に達し、10を超える結果となり、最終的な総得点は19.2 ± 0.8となりました。
一方で「Deep role-play」の部分では74％という結果に終わったため、関連するボーナスセットは解除されず、そのままの状態です。各セクションはそれぞれ独立して解除される仕組みとなっております。
テストの作り方
ケース内容を常に最新に保つ方法
すべての保存済み回答には、それが対応するケース内容の情報が付与されています。これによりシステム側は現在の回答と古い回答を区別できるのです。
すべての保存済み回答には、それが対応するケース内容の情報が付与されております。ケース内容に変更がある場合、その変更の影響を受ける部分のみが再処理されます。古い回答と新しい回答が混在することはありません。詳細につきましては、ケース情報の管理仕様（version.py）をご参照ください。
スイート4.1における正解例のレビュー
スイート4.1の作成手順です。詳細は4.1に関する記事をご覧ください。
正解例には誤りが生じる可能性があります。不適切な答えを認めてしまったり、課題の要求以上のことを求めることで適切な答えを却下してしまったりする場合もあります。スイート4.1では、2名のモデルレビュアーがそれぞれ独立してすべての公開正解例を確認し、何らかの変更を行う前に各記述内容を保存済みの正解例と照合しました。また拒否行為にも加点されることはありませんでした。どのケースにおいても拒否することで得点が加算されることはないからです。スイート4.1：変更点一覧にすべての修正内容が記載されております。
最初のスイートから新しいパックまで
上段：これまでのスイートの歩み。下段：新しいパックが作成される手順です。
3.9版からは最も優秀なモデルばかりが満点を取らないようにボーナスセットが導入されました。スイートの歴史には従来の仕様がそのまま記録されており、各エンジンのリリース内容はCrucibleForgeの変更履歴に記載されています。
モデルたちが特定の項目で満点を取れるようになると、より難易度の高いボーナスセット（新しいパック）が必要になります。そしてすべての新しいパックは上記の手順に従って作成されます。中でも判定チェックが最も重要です。判定者が良質な正解例と微妙に悪い答え、あるいは質が劣る答えを見分けられない場合、そのパックを公正に評価することは不可能だからです。
なぜこれを作ったのか
さまざまなモデルを区別できないことにうんざりしていました。誰でも、どのモデルに対しても簡単にベンチマークを実行でき、自分で数値を確認できるような仕組みが欲しかったのです。そうすれば価値があるだろうと考えたのです。
もしこのプロジェクトに価値を感じていただけたなら、寄付をしていただくことで、更新作業の維持にご協力いただけます。また、次にテストするモデルに投票することも可能です。
関連記事：CrucibleForgeの仕組みについて
