MakoBenchの仕組み:オープンなLLMベンチマークの解説

公開日
2026年11月5日
更新日
2026年11月8日
著者
Jacob Lloyd — プロジェクト完了後、AIの支援を受けて執筆
読了時間
約17分で読めます

かんたんに言うと: 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とは何か

モデルから評価結果まで

  1. モデル自社の環境に配置されたもの、またはホスティングされているAPIです
  2. 標準的なテストケースすべてのモデルに対して同じ質問が用意されています
  3. 回答内容保存されるため、後から再評価も可能です
  4. 採点処理コードの場合は隠されたテストや正確な出力結果と照合します。チャットの場合は自社環境にある判定用モデルおよびテキストルールを用いて評価します
  5. スコアコードとチャットの得点を合算し、全体スコアが算出されます。誤差範囲も併記されます
  6. 評価結果の掲示板ランキングやカテゴリ、傾向などが表示されます
すべてのモデルが同じ6段階のプロセスを経て評価されます。

MakoBenchは、ローカル環境で動作するモデルやホスティングされているモデルなど、あらゆる言語モデルを同じ基準で評価する公開用の掲示板です。コードを正しく書けるか、また役割演技や対話が適切に行えるかという2つの側面を測定します。MakoBenchが何をテストし、何をテストしないのかのページに詳細が記載されています。

評価エンジンとしてはCrucibleForgeが使用されており、これは無料かつオープンソース(MIT-0ライセンス)です。また、CrucibleForgeのインストールガイドに従えば、ご自身のモデルでもこのエンジンを利用することが可能です。

スコアの算出方法

ケースは1つずつ評価されます

1つのケースがどのようにして得点につながるか

  1. そのケース内容ツールを利用するための11段階からなる予約用チャット。トラップも仕込まれています。
  2. モデルの返答モデルが何を述べ、どのツールを呼び出すか
  3. 段階ごとのチェック内容適切なツールか?正しい引数か?ユーザーに直接答えるべきか、それともツールを呼び出すべきか?
  4. 7段階は合格、4段階は不合格得点:7 / 11 = 0.64
実際のケース例:ツール利用ケースTZ19、スイート4.0におけるClaude Sonnet 4.5の動作です。

1つのケースとは、書くべき関数や予測すべきプログラムの出力、ツールを使ったチャット、あるいは長時間にわたるロールプレイセッションなど、ひとまとまりのタスクのことです。各ケースは、隠されたテスト群やチャットの各ステップといった小さな単位で評価されるため、ほぼ正しい答えでも大部分の得点を獲得できます。標準的なケースはそれぞれ1回だけ実行されます。

詳細については、評価対象となるケース一覧および評価用コード(graders.py)をご覧ください。

審査員がチャットの返答をどう採点するか

審査員がチャットの返答をどのように評価するか

  1. 返答内容チャットセッションにおける一回分の返答です
  2. 質問内容「そのキャラクターは約束を守ったか?」という質問です
  3. 審査モデル「はい」または「いいえ」のいずれかで答えます
  4. 「はい」+正確な引用文コードがその引用文をチェックします。文字数は12文字以上であり、返答内容の中にそのまま含まれている必要があります
  5. 最終結果条件を満たしていれば「はい」とみなされます。条件を満たさない場合は「いいえ」となります
  6. テキストのルール、審査モデル不要単語数や禁止フレーズ、事前に設定された事実などはコードによってチェックされます。条件を満たさない場合は失敗とみなされます
審査員は証拠を示す必要があります。「はい」と答えたにもかかわらず実際の引用文がない場合は「いいえ」となります

コードには判断が不要です。しかしチャットには判断が必要なため、審査モデルという別の言語モデルが各返答に対して「はい」または「いいえ」で回答します。今回使用しているのはGemma 4 31B(検閲なしの“異端”ビルド、Q8)で、自社製のGPUマシン上で動作しています。Q8とは重みパラメータが8ビットで表現されていることを意味します。「はい」と答えるためには、返答内容と全く同じ引用文が存在する必要があります。なぜなら審査モデルは「はい」と答えすぎる傾向があるからです。各バッチ処理の前に、審査モデルは正しい返答を見分けられ、間違った返答も見破れる必要があります。そうでなければそのバッチ処理は中断されます。

一つの質問だけでケース全体が失敗となる可能性がある場合には、その質問を3回繰り返します。過半数の回答が「はい」となって初めて合格となり、同数の場合は「いいえ」となります。

詳細については、審査モデルのコード(judge.py)およびチャットセッションの仕組みをご覧ください。

コードとチャットの合計点が総得点となります

コード:10ポイント

  • 関数の使用56つのプログラム
  • 予測およびバグ探し2.53つのタスク
  • ツールの利用2.53回のチャット

チャット:10ポイント

  • 深い役割演技32回のセッション
  • 会話能力32回のセッション
  • キャラクター表現22回のセッション
  • 創作執筆能力22回のセッション
各バーがそれぞれの評価項目を表し、得点の割合に応じて描かれています。総得点はコードとチャットの合計で20ポイントとなります。ボーナスセットを利用すればさらに得点を加算することも可能です。

各項目はそれぞれの割り当てられたポイントを獲得します。例えば「関数の使用」は76%に相当し、5ポイント中3.8ポイントとなります。これらが合算されてコードおよびチャットの得点となります。別途用意されている成人向けテストは独自のタブで管理され、総得点には加算されません。

詳細については、ボード設定ファイル(bench.yaml)に各項目やそのポイント、評価基準が記載されております。

±マージンについて

マージンがどのようにして算出されるか

  1. ケースを1,000回ランダムに再描画する同じケースが2回出ることも、全く出ないこともあります
  2. 各再描画結果のスコアを算出するこうして1,000個の合計値が得られます
  3. その1,000個の合計値のうち中央90%の範囲を取り出すその範囲をハイライト表示します
  4. ±マージン = その幅の半分Claude Sonnet 4.5:12.8 ± 1.1
この±マージンは、どのケースがセットに含まれるかによって合計値がどの程度変動するかを示しています。ヒストグラムの形状はあくまで例示です。

少し違うケースを選んだ場合、合計値も若干異なってきます。このマージンがその変動幅を示しているのです。2つのモデルのマージンよりも差が小さい場合、統計的には同程度と見なされます。また、マージンは実行ごとのノイズを考慮していませんので、1〜2ポイント程度の差も同程度とみなして構いません。

詳細:マージン算出のコード(headline.py)

スコア表の読み方

クラス帯

  • クラスC10未満最も低い帯域です
  • クラスB10以上10から13までの範囲です
  • クラスA13以上13から16までの範囲です
  • クラスS16以上16から20まで。ボーナスセットを取得した場合のみそれ以上になります

合計点:0から20の範囲で評価されます

  • Claude Sonnet 4.512.8 ± 1.1クラスB
  • DeepSeek V4 Flash19.2 ± 0.8クラスS
クラスは大まかな帯域分けです。境界線をまたぐ数値の場合、クラスの判定が微妙な状態となります。数値は4.0版のスコア表から得られたものです。
記号意味
クラス16以上でクラスS、13でクラスA、10でクラスB、それ未満でクラスCとなります。
傾向スコア表のチャット・コードの平均値と比較して、1.5ポイント以上差がある場合に「チャット寄り」または「コード寄り」となります。そうでなければバランス良好です。
部分的すべてのテストケースが完了していません。数値は示されますが、合計点やクラス、ランクはありません。
暫定的設定チェックに失敗したため、テストコードが正しく測定できていない可能性があります。再実行までランクやクラスは判定されません。
(セット1)ボーナスポイントが含まれる部分です。数値は獲得された最高レベルのボーナスを示します。
MAX標準的な問題およびすべてのボーナスセットにおいて90%以上のスコアを達成した状態です。これ以上難しい問題は残っていないため、新たなセットが必要となります。

実行コストや使用基盤その他の項目については、MakoBenchドキュメントページおよびREADME内のスコア表の説明をご覧ください。

例:標準セットにおけるモデルの成績

コード部門:10点満点中6.1点

  • 関数処理能力3.8/5点満点
  • 予測およびバグ探し0.5/2.5点満点
  • ツール利用能力1.8/2.5点満点

チャット部門:10点満点中6.7点

  • 深いロールプレイ2.0/3点満点
  • 会話能力2.0/3点満点
  • キャラクター表現力1.3/2点満点
  • 創作能力1.4/2点満点
各バーはそれぞれの評価項目を表しており、塗りつぶされた部分がモデルが獲得した得点です。点線は90%の基準値を示しています。Suite 4.0の評価表は2026年11月7日に公開されました。どの項目も90%に達していないため、すべてのボーナスセットはロックされた状態です。合計得点は6.1+6.7=12.8±1.1で、Bクラスとなります。

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%という基準には達していません。そのためすべてのボーナスセットはロックされたままで、得点も標準セットのみに基づくものとなりました。評価表上のほとんどのモデルも同様の状況です。

ボーナスセットについて

セットがどのように解除されるか

あるパートにおいて、ボーナスセットがどのように解除されるか

  1. 標準的な問題例えば「関数」というパートにおける問題です。
  2. 90%以上か?いいえ:解除されず、0ポイント。そのパートの通常ポイントが維持されます。はい:レベル1のセットが解除され、各セットは1ポイントとなります。
  3. 保留中すでに解除されたもののまだ実行されていないセット:現時点では0ポイントです。
  4. 各セットがポイントを加算する実行されると、各セットは0から1ポイントを加算します。3問中2問正解で約0.67ポイントとなります。
  5. すべてのレベル1セットで90%以上か?いいえ:処理は停止し、ポイントは維持されます。はい:レベル2のセットが解除され、以降も同様にレベルごとに解除されていきます。
  6. パートのスコア通常ポイント+実行された各セットからの加算分です。
上から下へと進む様子を示しています。CodeおよびChatの各パートにはそれぞれ専用の「ラダー」があります。

ボーナスセットとは、あるパート用に用意された難易度の高い問題群で、通常は3問から成ります。CrucibleForgeではこれらを「ラダーパック」と呼んでいます。ルールは以下の通りです。

  • 解除条件。 あるレベルのセットは、そのパートの標準問題およびそれより低いレベルのすべてのセットで90%以上の成績を収めた場合にのみ解除されます。
  • ロック状態・解除済み・保留中。 ロック状態:まだ獲得していない。解除済み:すでに獲得し実行可能な状態。保留中:獲得済みだがまだ実行または採点されておらず、現時点では0ポイントとなります。
  • 1セットにつき最大1ポイント。 各セットの問題群でそのポイントを共有し、部分正解も認められます。例えば3問中2問正解で約0.67ポイントとなります。同一問題が2回実行された場合はその平均値が用いられます。
  • レベル制。 同じレベルのすべてのセットが一緒に解除され、それぞれがパートのスコアに加算されます。

バージョン4.1現在では、すべてのセットがレベル1となっています。Codeには各パートごとに3つのセットがあり、Chatには5つ(Deepロールプレイ用に2つ)ありますので、Codeは最大13ポイント、Chatは15ポイントまで得られることになります。標準的なケースがまだ未実施のパートでは、そのセットは一切解除されません。

詳細については、ボーナスセットのルール、解除処理用コード(ladder.py)、および公開されているボーナスセット一覧をご参照ください。

例:セットが解除されるモデルのケース

DeepSeek V4 Flashがボーナスセットを解除する様子

  1. 関数:標準プログラム6問すべて正解で100%となり、5.0ポイントが得られます。
  2. 100%は90%以上なので解除される「関数」用のレベル1ボーナスセットが解除されます。
  3. 難易度の高い問題3問、それぞれ2回ずつ実行問題1:0と0 → 0.00;問題2:0と0 → 0.00;問題3:6グループ中4グループで正解し、その後0 → 0.33となります。
  4. セットの加算分:0.33 ÷ 3 = 0.11「関数」パートのスコアは5.0 + 0.1で5.1ポイントとなります。
  5. Deepロールプレイ:74%90%未満なので該当するボーナスセットはロックされたまま。得点は3問中2.2ポイントとなります。
  6. Codeの合計スコア:11.2 = 5.1 + 2.7 + 3.3ボーナスセットなしでは10ポイントを超えられません。
バージョン4.0のテスト結果および保存された解答データに基づく実際の数値です。

DeepSeek V4 Flashは「関数」パートの標準プログラム6問すべてを正解したため、「関数」用のボーナスセットが解除されました。このセットにはゼロから作成する必要がある3つのプログラムがあり、それぞれ2回ずつ実行されました。そのうち1つの問題については6グループ中4グループで正解し、もう一方では全く正解できなかったため、その問題の得点は0.33となりました。したがってセット全体での加算分は(0 + 0 + 0.33)÷ 3 = 0.11ポイントです。その他のCodeパートやクリエイティブライティング用パートでもそれぞれセットが解除されました。こうしてCodeの合計スコアは11.2に達し、10ポイントを超えることになりました。全体のスコアも19.2 ± 0.8となっています。

一方でDeepロールプレイパートでは74%しか得られなかったため、該当するボーナスセットはロックされたままでした。各パートはそれぞれ独立して解除されます。

テストの作り方

ケース情報を最新の状態に保つ

ケースが変更された際の処理内容

  • 質問やそのテスト内容が変更された場合新しい回答が生成されるすべてのモデルが再び回答を出します
  • 採点用の質問内容が変更された場合再採点される採点者が保存されている回答を再確認します
  • テキストチェックや回答内容が変更された場合再採点される再度採点され、モデルは呼び出されません
  • 何も変更がない場合そのまま維持される保存されている回答は有効なままです
保存されている各回答には、それが対応するケース内容の情報が付与されています。これにより、システムは最新の回答と古い回答を区別できるのです。

保存されている各回答には、それが対応するケース内容の情報が付与されています。ケースが変更された際には、変更の影響を受ける部分のみが再処理されます。古い回答と新しい回答が混在することはありません。詳細については、ケース情報の管理方法(version.py)をご覧ください。

スイート4.1の正解データ検証について

スイート4.1の正解データ検証手順

  1. すべての公開正解データ合計63件
  2. 2名のレビュアーレビュアーAとレビュアーBがそれぞれ全件を確認します。
  3. 各回答内容の検証コードの場合は参照実装およびテストを実行。チャットやツールの場合は各モデルに保存されている正解データと照合します。
  4. 回答内容の分類確認済みが約190件(スコア変更が生じた場合は修正も行う)。却下されたものが約95件で、それぞれに理由が記載されています。
  5. 修正内容の再確認「拒否すること自体にポイントはない。難しい課題は依然として難しいままだ。」
  6. 再実行・再判定・再採点修正が行われたすべてのケースを対象とします。
スイート4.1がどのように作られたか。詳細は4.1に関する記事をご覧ください。

正解データには二通りの誤りがあり得ます。悪い回答を正しいと認めてしまう場合や、課題の要求範囲を超えて多くの情報を求めてしまい、良い回答を誤って却下してしまう場合です。スイート4.1では、2名のモデルレビュアーがそれぞれ独自にすべての公開正解データを確認し、何らかの変更を行う前に各回答内容を保存されている正解データと照合しました。また「拒否」に対してもポイントは与えられません。どのような修正が行われたかはスイート4.1:変更点一覧に記載されています。

最初のスイートから新しいパックまで

これまでのスイートの状況

  1. 3.0100点満点中の得点
  2. 3.9ボーナスセットが追加されました
  3. 4.0コードおよびチャット用の課題が各10問ずつ
  4. 4.1正解例が見直されました

新しいボーナスパックの作成手順

  1. ライト複数のモデルが問題文を作成します
  2. アタック別のモデルが各正解例を破ろうと試みます
  3. ジャッジチェック良い答えも、微妙に悪い答えも、質が低い答えも検証されます
  4. パイロットいくつかの優秀なモデルがその課題に取り組みます
  5. ハードニングパイロット段階で明らかになった問題点を修正します
  6. ステージ見直しが終わるまで保留状態となります
上段:これまでのスイートの状況。下段:新しいパックがたどる手順です。

3.9版でボーナスセットが追加され、最も優秀なモデルであっても満点を取れなくなりました。スイートの履歴には従来の課題群がそのまま記録されており、各エンジンの更新内容はCrucibleForgeの変更履歴に記載されています。

モデルが特定の課題で満点を獲得し始めた場合、より難易度の高いボーナスセット(新しいパック)が必要になります。そして新しいパックは必ず上記の手順を踏みます。中でもジャッジチェックが最も重要です。もし判定者が良い答えと微妙に悪い答えを見分けられない場合、そのパックを公平に評価することは不可能だからです。

なぜこのツールを作ったのか

さまざまなモデルを区別できないことにうんざりしていました。誰でも、どのモデルに対しても簡単にベンチマークを実行でき、自分で数値を確認できるような仕組みがあれば良いと思ったのです。そうすれば価値があるだろうと考えました。

もしこのツールに価値を感じていただけたなら、寄付をしていただくことで、更新作業の維持にご協力いただけます。また、次にテストするモデルに投票することも可能です。

関連記事:CrucibleForgeの仕組みについて


← AIとローカルLLMをもっと見る More MakoBench articles →