Nonobench

Nonobench

さまざまなサイズのグリッドを使ったノノグラム（ピクロス）パズルの解答を通じて、LLM の推論能力を評価するベンチマークスイートです。結果は nonobench.com で公開しています。

マウリス・クライネが開発しました。

ノノグラムとは？

ノノグラム（ピクロス、グリドラー、またはペイント・バイ・ナンバーズとも呼ばれます）は、各行と各列の数字のヒントをもとに、グリッド上のマスを塗りつぶすロジックパズルです。ヒントは、塗りつぶされたマスが連続するグループを示し、グループ同士は少なくとも1つの空白マスで区切られます。こうしたパズルを解くには、論理的な推論と制約の充足が必要となるため、LLM の推論能力を試す優れた課題です。

プロジェクト構成

nonobench/
├── bench/          # Benchmark runner, results database and exporter
└── visualizer/     # TanStack Start dashboard on Cloudflare Workers (nonobench.com), also home of the puzzle set

前提条件

• Bun ランタイム（v1.4 以降）
• Node.js v24 以降（ビジュアライザー用）
• OpenRouter API キー

クイックスタート

1. リポジトリをクローンする

git clone https://github.com/mauricekleine/nonobench.git
cd nonobench

2. 環境変数を設定する

bench/ ディレクトリに .env ファイルを作成します（bench/.env.example を参照）。

OPENROUTER_API_KEY=your_openrouter_api_key_here

必要な変数はこれだけです。ビジュアライザーは変数なしでビルドできます。

3. ベンチマークを実行する

cd bench
bun install
bun run bench                       # prints the plan and exits, no API calls
bun run bench --model <name>        # run one model (repeat --model for more)
bun run bench --all-missing         # run every configured model with missing work
bun run bench --model <name> --sizes 20x20  # opt in to the extended tier

実行は差分追加のみです。すでに成功結果があるモデルとパズルの組み合わせは再実行されず、データベースも上書きを拒否します。失敗した実行は次回の起動時に再試行されます。結果は bench/results.db（SQLite）に保存されます。

便利なフラグ：

• --max-cost <usd>：このセッションの支出が指定額に達すると、新しいパズルの起動を停止します。すでに実行中のリクエストは完了するため、選択したモデルごとに最大で --parallel 件分、上限を超えることがあります。上限には OpenRouter キー自体に設定した制限を使用してください。
• --parallel <n>：モデルごとの同時リクエスト数を設定します（デフォルトは10）。レート制限のあるプロバイダーでは値を下げてください。
• --limit <n>：各サイズの最初の n 個のパズルのみを実行します。スクラッチ用データベース（NONOBENCH_DB=/tmp/copy.db）を使った試験実行に便利です。

出力モード

新しい実行では、厳密な構造化出力（JSON スキーマ。構造化出力を強制するエンドポイントにのみルーティング）で回答を求めるため、モデルがグリッドを文章で囲むことはできません。一部のモデルでは、スキーマを強制するエンドポイントによって回答の品質が大幅に低下するため、テキストモードで実行します（ベンチマークのプロンプトを使った5x5の A/B テストで選定し、bench/constants.ts の outputMode: "text" で指定）。各実行ではモードが記録されますが、採点方法はどちらも同じです。回答はすべてのヒントを満たす必要があります。また、構造化出力で5x5のパズルを1つも解けないモデルや、序盤の実行で推論トークン数がほとんどの場合ゼロと報告されるモデルについては、問題がモデルではなくハーネス側にある可能性を示すため、ランナーが実行を停止します。

ベンチマークの実行後、ビジュアライザー用に結果を書き出します。

bun run export

これにより、visualizer/app/results.json（集計結果）と visualizer/public/results-raw.json（プロンプトや出力を含むすべての実行）が作成されます。

その他のスクリプト：

• bun test - パーサー、採点機能、データベースポリシー、パズルのチェック
• bun run typecheck - TypeScript の型チェック
• bun run regrade - 保存済みの採点結果を現在の採点機能と読み取り専用で比較

ローカルモデルで実行する

ランナーは、自分でサーバーを立ち上げたモデルをベンチマークできます。OpenAI 互換の /v1 エンドポイントを備えたサーバーであれば利用できます。vLLM、SGLang、llama.cpp、LM Studio、Ollama に対応しています。

この構成では2台のマシンを使います。モデルサーバーはモデルを提供するワークステーションです。ベンチマークマシンはベンチマークを実行するノート PC です。

1. ワークステーションでモデルを提供する

サーバーをすべてのネットワークインターフェースにバインドします。デフォルトのバインドアドレス 127.0.0.1 では、モデルサーバー自身からの接続のみを受け付けます。

vLLM：

vllm serve Qwen/Qwen3-32B --host 0.0.0.0 --port 8000

Ollama：

ollama pull qwen3:32b
OLLAMA_HOST=0.0.0.0:11434 ollama serve

llama.cpp：

llama-server -m ./qwen3-32b-Q4_K_M.gguf --host 0.0.0.0 --port 8080

SGLang：

python -m sglang.launch_server --model-path Qwen/Qwen3-32B --host 0.0.0.0 --port 30000

LM Studio：Developer タブを開き、Start Server を選択します。Network Server スイッチをオンにし、サーバーがすべてのネットワークインターフェースで待ち受けるようにします。

注意：ポートをインターネットに公開しないでください。ほとんどのローカルサーバーには認証がないため、ポートに到達できる人なら誰でもモデルを実行できます。

2. モデルサーバーのポートを開く

ルールの対象を自分のサブネットに限定します。ローカルネットワークからポートへの TCP トラフィックを許可します。

sudo ufw allow from 192.168.1.0/24 to any port 8000 proto tcp

macOS では、「システム設定」でサーバーアプリの着信接続を許可します。

3. ノートパソコンから接続を確認する

モデルサーバーの LAN アドレスを確認します。Linux では ip -4 addr show を実行します。macOS では ipconfig getifaddr en0 を実行します。

ノートパソコンからモデル一覧をリクエストします。

curl http://192.168.1.20:8000/v1/models

応答にモデルが表示されていることを確認します。id の値を正確にコピーしてください。この値は NONOBENCH_LOCAL_MODEL に必要です。

リクエストに失敗した場合は、手順 1 のバインドアドレスを確認します。次に、ファイアウォールのルール、アドレス、ポートを確認します。

ネットワーク経由でモデルサーバーに接続できない場合は、代わりに SSH トンネルを作成します。その後、アドレス http://127.0.0.1:8000/v1 を使用します。

ssh -N -L 8000:127.0.0.1:8000 [email protected]

4. ベンチマークを実行する

cd bench
bun install
NONOBENCH_LOCAL_BASE_URL=http://192.168.1.20:8000/v1 \
NONOBENCH_LOCAL_MODEL=Qwen3-32B \
bun run bench:local --model Qwen3-32B

まずはパイロット実行を行います。次のコマンドは、5x5 のパズルを 2 つスクラッチデータベースに実行します。

NONOBENCH_LOCAL_BASE_URL=http://192.168.1.20:8000/v1 \
NONOBENCH_LOCAL_MODEL=Qwen3-32B \
NONOBENCH_DB=local-pilot.db \
bun run bench --model Qwen3-32B --sizes 5x5 --limit 2

プランにモデルが [local, text] として表示されていることを確認します。

ローカルモデル用の環境変数

変数	意味
NONOBENCH_LOCAL_BASE_URL	サーバーの /v1 エンドポイントです。Ollama はポート 11434 を使用します。
NONOBENCH_LOCAL_MODEL	GET /v1/models に対してサーバーが返すモデルの id です。
NONOBENCH_LOCAL_NAME	表示名と --model の値です。デフォルトはモデルの id です。クラウドモデル名と一致してはいけません。
NONOBENCH_LOCAL_EFFORT	サーバーに設定されている推論の強度です（none、low、xhigh、…）。ラベルのみで、ランナーがローカルサーバーに推論設定を送信することはありません。デフォルトは none です。
NONOBENCH_LOCAL_API_KEY	サーバーで必要な場合に使用するベアラートークンです。デフォルトは local です。

NONOBENCH_LOCAL_BASE_URL と NONOBENCH_LOCAL_MODEL の両方を設定した場合にのみ、ランナーはローカルモデルをプランに追加します。

ローカル実行に関する注意事項

• ローカル実行の費用は $0 です。公開データセットには含めないでください。bun run bench:local を使って実行します。これは NONOBENCH_DB=local-results.db を指定して bun run bench を実行するものです。bench/results.db は共有データセットであり、エクスポート契約テストでは、これとコミット済みのエクスポートが照合されます。ランナーは、ローカルモデルを共有データベースに書き込もうとすると拒否します。
• 実行を開始する前に、ランナーはモデルの id をサーバーの GET /v1/models の一覧と照合します。入力ミスがある場合、サーバーが実際に提供しているモデルの一覧とともにエラーになります。また、サーバーに接続できない場合は、実行が記録される前にエラーになります。
• ローカルモデルではテキストモードがデフォルトです。多くのローカルサーバーは JSON スキーマリクエストを受け付けても、それを無視します。サーバーがスキーマを適用する場合は、NONOBENCH_OUTPUT_MODE=json_schema を設定してください。
• まずは --parallel 1 で実行してください。1 台の GPU が同時に処理できるリクエスト数は、クラウドプロバイダーより少なくなります。
• 20x20 ティアでは、128,000 個の出力トークンが要求されます。サーバーのコンテキストがそれより小さい場合は、コアサイズのみを実行してください。
• ランナーはローカルモデルに対して、推論トークンのサーキットブレーカーを適用しません。一部のローカルサーバーは、すべての実行で推論トークン数をゼロと報告します。
• 毎回プレフィックスを付けずに済むよう、同じ変数を bench/.env に設定してください。
• ベンチマークの実行時にローカルモデルが bench/local-models.json に登録されます（名前、サーバーモデル ID、ファミリー、サーバー URL）。そのため、後で bun run export を実行すると、環境変数なしでビジュアライザーにも反映されます。すでにベンチマークを実行したモデルを登録するには、次のエントリーを追加してください："<name>": { "baseURL": "http://host:port/v1", "modelId": "<server model id>", "family": "<name>" }。名前がサーバーの ID と同じ場合は、modelId を省略してください。

4. 結果の表示

cd visualizer
bun install
bun run dev

次に、http://localhost:3000 を開いて、インタラクティブなダッシュボードを表示します。

自分の実行結果は別のデータベースに保存されます。次のコマンドで配信してください。

cd visualizer
bun run dev:local

dev:local は bench/local-results.db をダッシュボードのデータファイルにエクスポートして開発サーバーを起動し、停止時にコミット済みファイルを復元します。実行中、ダッシュボードに表示されるのはそのデータベース内のモデルのみです。つまり、公開リーダーボードではなく、自分のローカル実行結果が表示されます。別のデータベースを配信するには NONOBENCH_LOCAL_DB を設定してください。

このサーバーの実行中は、bench での bun test が 1 つのテストに失敗します。エクスポート契約テストがダッシュボードのデータファイルと bench/results.db を照合しますが、dev:local によって実行結果がデータファイルに書き込まれているためです。サーバーを停止し、スクリプトによるコミット済みファイルの復元を待つと、テストスイートは再びパスします。

5. デプロイ

ビジュアライザーは Cloudflare Worker（visualizer/wrangler.jsonc）です。ページはビルド時に事前レンダリングされ、静的アセットとして配信されます。Worker は API、MCP サーバー、エージェントのルートを配信し、アセットバインディングを通じてエクスポート済みの JSON を読み込みます。Workers Builds が、main へのマージ時に本番デプロイを担当します。Cloudflare の認証情報を使い、visualizer/ から bun install --frozen-lockfile && bun run build を実行した後、bunx wrangler deploy を実行します。ローカルのデプロイスクリプトと Wrangler のログインは廃止されており、エージェントは Cloudflare へのアクセスに cf を使います。visualizer/ から次のコマンドを実行します。

• CLOUDFLARE_ENV=beta bun run build は、ローカルプレビュー用に beta Worker をビルドします。既存の beta.nonobench.com Worker には Workers Builds のトリガーがないため、このコマンドではデプロイされません。
• bun run deploy:verify <sha> は、本番環境で main 上のそのコミットを含むビルドが実行されるまで待機します。DEPLOY_VERIFY_URL に別途デプロイしたターゲットを指定しない限り、ブランチ上のコミットは直ちに失敗します。リポジトリのルートでも同じスクリプトが実行されるため、どちらのディレクトリからでも bun run deploy:verify <sha> を実行できます。

エージェントからのアクセス

nonobench.com は、認証なしでエージェントにベンチマークデータを公開しています。

• REST API は /api/v1 配下にあります（リーダーボード、モデル、パズル、解答チェッカー、個別の実行）。仕様は /api/openapi.json にあり、/.well-known/api-catalog（RFC 9727）から参照できます。

• MCP サーバー は /mcp にあります（ステートレスな Streamable HTTP、MCP 2026-07-28、2025 クライアント互換）。詳細は /.well-known/mcp/server-card.json をご覧ください。claude mcp add --transport http nonobench https://www.nonobench.com/mcp でクライアントに追加できます。ブラウザーからのリクエストでは、サイトのオリジンまたは HTTP の localhost/127.0.0.1 オリジンを使用できます。 Claude Connectors Directory、MCP Registry（io.github.mauricekleine/nonobench）、Smithery、Glama、mcpservers.org に掲載されています。

  

• ブラウザーで navigator.modelContext を介して登録される WebMCP ツール。

• Markdown：/ と /puzzles は、Accept: text/markdown を指定すると Markdown を返します。/llms.txt には概要が記載されています。

• ディスカバリー：robots.txt（Content Signals を含む）、sitemap.xml、ホームページの Link ヘッダー、/.well-known/agent-skills/index.json のエージェントスキル、/.well-known/ai-catalog.json の ARD マニフェスト。

これらはすべて、ダッシュボードと同じエクスポート済みファイル（visualizer/app/results.json と visualizer/public/results-raw.json）から読み込まれるため、bun run export を実行すると、こちらも更新されます。

採点

各モデルには、同じシステムプロンプトとパズルの行および列の手掛かりが与えられます。標準モードの解答は、1 と 0 を並べた1つの文字列です。ハードモードの解答は1行につき1行分です。400マスでは、ほとんどのモデルが1つの文字列のマス数を間違えるためです（LEARNINGS.md を参照）。すべての行と列の手掛かりを満たす解答が正解です。

30個のパズルのうち10個（5x5が1個、10x10が4個、15x15が5個）には複数の有効な解答があるため、保存された解答と比較するのではなく、手掛かりに照らして解答を判定します。正誤判定はエクスポート時に保存済みの生の出力から導出され、データベースは書き換えられません。パズルのテストスイートでは複数解のあるパズルを特定しており、新しいパズルには一意の解答が必要です。

パズルデータ

コアティアには、visualizer/components/puzzles/ で定義され、ランナーとダッシュボードで共有されている30個のパズル（5x5、10x10、15x15が各10個）があります。これらは nono-dataset から取得されました。ハードモードには、生成された20x20のパズルが10個あります。パズルの ID は解答のハッシュ値であるため、解答を変更すると新しいパズルになります。

ティアと生成

デフォルトのベンチマーク実行では、3 つのコアサイズ（Standard）が対象です。モデルを選択して --sizes 20x20 を指定すると、Hard モードを実行できます。カンマ区切りで複数のサイズを指定することもできます。ランナーの計画では、不足している 20x20 の作業が別途報告されます。全体の精度と最良のバリアントの選択には Standard の実行結果のみが使用されます。Hard モードの結果は別に扱われます。Hard モードのリクエストには 128,000 トークンの回答上限が設定されますが、エンドポイントの最大値（bench/max-output-tokens.json）を超えることはありません。

bench/ から bun run generate-puzzles を実行すると、固定シードで 20x20 のセットを再生成します。グリッドはランダムに埋められ（画像はないため、モデルが画像から推測することはできません）、各行と列に少なくとも 3 つのブロックがあり、鏡映対称性が少ないものが保持されます。また、厳密なソルバー（NONOGRAM_SOLVER）で一意性を確認します。このセットには、行と列の伝播で解けるパズルが 5 問と、残り 20～200 マスで行き詰まるパズルが 5 問含まれます。bun test では、ヒント、一意性フラグ、行の可解性が検証されます。元の曖昧性リストは固定されたままです。

設定

bench/constants.ts を編集して、次の項目を設定します。

• MODELS - モデル設定の配列（OpenRouter のモデル ID、表示名、推論設定）
• MAX_PARALLEL_RUNS_PER_MODEL - モデルごとのパズル同時実行数（デフォルト：10）
• REQUEST_TIMEOUT_MS - リクエストごとのタイムアウト。タイムアウトしたリクエストは失敗した実行として保存されます（デフォルト：30 分）

NONOBENCH_DB、NONOBENCH_RESULTS_JSON、NONOBENCH_RESULTS_RAW_JSON を使うと、データベースとエクスポート先のパスを上書きできます。コピーに対してテストする場合に便利です。

技術スタック

ベンチマークランナー

• Bun - JavaScript ランタイムおよび SQLite
• AI SDK - 統一された LLM インターフェース
• OpenRouter - LLM API ゲートウェイ
• TypeScript

ビジュアライザー

• TanStack Start - React フレームワーク、事前レンダリングされたページ
• Cloudflare Workers - 静的アセットを使用したホスティング
• React 19 - UI ライブラリ
• Tailwind CSS 4 - スタイリング
• shadcn/ui - コンポーネントライブラリ
• Recharts - チャート
• Zustand - 状態管理

コントリビューション

コントリビューションを歓迎します。お気軽に次のことに取り組んでください。

• 新しい LLM モデルのサポートを追加する
• ベンチマーク手法を改善する
• ビジュアライゼーションダッシュボードを強化する

ライセンス

MIT