Supabase Evals — 実バックエンドのエージェントベンチマーク
コーディングエージェントのリーダーボードはたいていプルリクエストの差分をテストスイートに対して測ります — SWE-Bench とその親戚です。それは有用ですが、Supabase ユーザーが実際に行うことではありません: スキーマを構築し、壊れた RLS ポリシーを修正し、失敗した Edge Function をデバッグし、認証を配線する。2026年8月1日、Supabase はコーディングエージェントを実際のタスクで、実際の MCP サーバーと実際の CLI で、実際のコンテナ化された Supabase スタックに対してグレードするベンチマークをオープンソース化しました。Apache-2.0 で、ラップトップ上でローカル実行でき、初期スコアはすでに異なるエージェントがドキュメントをどう使うかについて驚くべきことを言っています。このページはそれの実践的なフィールドガイドです。
- Supabase Evals が SWE-Bench 型ベンチマークとどう構造的に異なるかを理解する
- クロスエージェントの発見を正直に読む — Opus 5、Sonnet 5、Kimi K3、GPT-5 ラインが実際にどこで分岐するか
- 同じモデルでスキルをロードした効果を見る(前 vs 後)
- 自分のエージェントとモデルに対してベンチマークを1時間未満で自分で実行する
Supabase Evals が実際に何であるか
Supabase Evals は、ベンチマーク、評価ハーネス、公開リーダーボードを1つの Apache-2.0 リポジトリ github.com/supabase/evals にまとめたものです。存在する理由は、SWE-Bench 型のテストがバックエンド作業に対して間違った質問に答えているためです — それらは「このエージェントは Python テストスイートに対する GitHub イシューをクローズできるか」を測る — 一方でほとんどの実際の Supabase 作業は稼働中システムに対する ops に近い: RLS ポリシーが有効なリクエストを拒否し始めた、Edge Function が本番で 500 を返している、マイグレーションが適用されなかった。
以前のものと3つの点で異なります:
- モックではなく、実スタック。 すべてのシナリオはホストの Docker ソケットをマウントする新鮮な Docker サンドボックスを起動するため、
supabase startはローカルスタックを兄弟コンテナとして起動します。エージェントは Management-API 互換のサーフェス(@supabase/lite)および 実際の MCP サーバーと実際の Supabase CLI と対話します。何もスタブされていません。 - 決定論的チェック優先、必要な場合のみ LLM-as-judge。 スコアラーは結果のデータベースをクエリしたり、デプロイされた Edge Function にヒットしたり、生成されたファイルに対してリポジトリルート
vitestを実行できます。LLM ジャッジは自由形式回答(「エージェントの説明は実際の根本原因と一致したか?」)のバックストップであり、主要なグレードではありません。 - 1回のリトライで最終。 ベスト・オブ・N をチェリーピックしません。これだけで、数値はほとんどのエージェント PR ベンチマークよりも綺麗ではなくなります。
シナリオグリッド
2026年8月のリリースは evals/<id>/ の下に 38 の eval シナリオ を出荷します。それらは結果が意味的にスライスできるよう3軸で組織化されています:
- 9つのプロダクト — database、auth、storage、edge functions、realtime、cron、queues、vectors、data-api
- 9つのトピック — RLS、security、migrations、SQL、SDK、observability、self-hosting、tests、declarative-schema
- 4つのステージ —
build(新しいものを作る)、deploy(出荷)、investigate(何が悪いかを調べる)、resolve(修正)
各 eval は PROMPT.md(エージェントが見るタスク、frontmatter メタデータ付き)、EVAL.ts スコアラー、オプションの remote/(シードされたホストプロジェクト状態 — SQL、ログ、すでにデプロイされた関数)、local/(エージェントのサンドボックスワークスペースにコピーされる開始ファイル)を含むディレクトリです。シナリオは合成プロンプトではなく、実際のサポートチケットと GitHub イシューから来ています。
2つのランタイム、eval ごとに選択
すべての eval は2つのモードのいずれかで実行され、その形によって自動的に決定されます:
- Tools モード。 サンドボックスなし。エージェントは MCP/ツールサーフェス(Management API、SQL、storage など)を得て、結果のプロジェクト状態を検査してその回答がスコアリングされます。プラットフォーム内で完結する eval(
local/ディレクトリなし、interface: cliなし)に使われます。 - Local-stack モード。 実際の Supabase CLI がインストールされた新鮮な Docker サンドボックス。エージェントは
bashツールとファイルツールを得て、兄弟コンテナとして生成される実際のローカルスタックに対してsupabase init/start/db/testを実行できます。エージェントが停止した後、ハーネスはdocker cpでワークスペースを取り出し、ホストからvite/vitestを実行してスコアリングします。local/ワークスペースが存在するかinterface: cliが宣言されている場合に使われます。
賢い部分: ホストのツールチェーンがサンドボックスが生成したものをスコアリングします。 スコアラーはサンドボックスイメージの中に住む必要がありません。
クロスエージェントの発見 (2026年8月)
初期のリーダーボード実行は、ファーストパーティエージェント(Claude Code、Codex、Claude API executor 実験)を、Claude Opus 5、Claude Sonnet 5、Kimi K3、GPT-5.4/5.6 ラインアップにわたるモデル非依存の OpenCode と対戦させます。以下の数値は初期投稿が最も鋭い結果を報告している build ステージのものです。
| Agent + model | Build (no skills) | Build (with skills) |
|---|---|---|
| Claude Code + Opus 5 | 100% | 100% |
| OpenCode + Kimi K3 | 100% | 100% |
| Claude Code + Sonnet 5 | 78% | 100% |
| Codex + GPT-5.6 (Sol) | 89% | 100% |
| Codex + GPT-5.4 mini | 78% | 89% |
2つ際立っています:
- Opus 5 と Kimi K3 は
buildを助けなしで最大化します。 OpenCode 経由の Kimi K3 が Claude Code 経由の Opus 5 に匹敵するのは、オープンウェイトモデルがバックエンド型の作業で追いついていることについての本物のシグナルです — 一般的な SOTA の主張ではなく、具体的で再現可能なもの。 - スキルは小/中モデルで大きな乗数です。 Supabase スキルをロードすると Sonnet 5 は
buildで 78% から 100% になり、Postgres ベストプラクティスのスキルのヒット率はより広いスイートで ~10% から 60% になります。Sonnet 5(または任意の中モデル)を使っているなら、関連スキルをロードしないことは 20+ ポイントを床に残すことです。
誰も予期しなかった発見: モデルはドキュメントを非常に異なる方法で使う
リリースで最も興味深い数値はスコアではなく、行動です:
Codex / GPT-5.6 はシナリオあたり約8ページのドキュメントを読みます。Claude Code は約2ページ — そしてスキルがロードされていてもシナリオの40%未満でドキュメントを参照します。
2つのエージェントは同じタスク、同じ MCP ツール、同じスキルを見ていました。Codex は行動する前に反射的にドキュメントを引き出しますが、Claude Code はより頻繁に記憶から試み、壁にぶつかったときにのみドキュメントを読みます。どちらも「正しい」ではありません — Claude Code 経由の Opus 5 は依然として build で 100% を記録しました。しかし非常に異なる動作モードであり、2つのエージェントが違和感を持って感じられるという逸話的報告の多くを説明します。
★ Insight ─────────────────────────────────────
- ベンチマークレポートは通常エージェントを1つの数値に潰します。Supabase Evals は珍しく貴重で — エージェントの振る舞いを計装します — 何回ドキュメントを読むか、どのスキルをロードしたか、いくつのツールを呼んだか — そしてその振る舞いはスコアではなくストーリーであることが多い。
- ここでのギャップはモデルギャップではなく、ハーネスポリシーギャップです。同じベースモデルが異なるハーネスなら異なる振る舞いをする可能性が高い。ハーネスがモデルと少なくとも同じくらい重要である理由は Coding Agent CLIs Compared を参照。
- 決定論的スコアラー + 1回のリトライ(ベスト・オブ・N なし)が、ここでの数値をエージェント間で比較可能にするものです。ほとんどの公開エージェントリーダーボードは静かにリトライや自己一貫性を許可しており、それは遅い/弱いモデルを美化します。
─────────────────────────────────────────────────
すべてのエージェントで一貫する3つのつまずき
モデルに関わらず、テストされたすべてのエージェントは同じ3つのパターンでつまずきました:
- 宣言的スキーマの代わりに手書きのマイグレーション。 宣言的スキーマワークフローは新しく、学習データは古いスタイルの
create tableマイグレーションで重いため、プロジェクトが宣言的用にセットアップされていてもエージェントはそれらにデフォルトします。 @supabase/serverを使う代わりに手動での認証検証。 エージェントは、まさにこのために存在する新しいサーバーサイドヘルパーを使わず、Cookie 解析とセッションチェックを手で配線します。- 一貫性のないドキュメント参照。 上記の通り — 同じエージェントは1つのシナリオでドキュメントを見て、次のシナリオでは記憶から試み、どちらのケースかについて明らかなルールはありません。
これらは、合成ベンチマークの pass@1 には現れない類の失敗です。「間違っているが動作する」回答がグレードされないからです — コードはコンパイルされ、単に時代遅れのパターンを使うだけです。実コンテナ eval はそれらを捕まえます、なぜならスコアラーが生成されたプロジェクトを検査して「宣言的スキーマを使ったか、yes/no」をチェックできるからです。
ローカル実行
Docker、pnpm、グレードするプロバイダーの API キーが必要です。ポート 54321〜54329 が空いている必要があります(まずローカルの supabase start スタックを停止してください)。全体はラップトップで実行され、小さな実行は数分で終わります。
- スキルはサブモジュールに住んでいます — プレーンクローンでは Supabase エージェントスキルが欠けます。初回は --recurse-submodules を使ってください。
- `pnpm install`、次に `.env.example` を `.env` にコピーし、必要なプロバイダーキー(`OPENAI_API_KEY`、`ANTHROPIC_API_KEY` など)を貼り付けてください。
- 狭く始めます。単一のシナリオと単一のエージェント/モデル構成を選び、フルスイープにトークンや時間を費やす前にエージェントのターンを見てセットアップが機能することを確認してください。
- 1つの実行が機能したら、`--experiment` フラグを拡張して例えば Sonnet 5 のスキルあり vs なし、または同じシナリオでの Claude Code vs Codex を比較してください。
- `pnpm export-results` は `eval-results.json` を書き、`pnpm web` はターン単位のトレース付きのローカルビューアーを開いて、エージェントが*実際に何をしたか*を読めます — ここが本物の学びのある場所です。
Clone the repo with submodules
git clone --recurse-submodules https://github.com/supabase/evals.git cd evals pnpm install cp .env.example .env
Run a single eval against a single experiment
pnpm eval -- \ --eval resolve-dataapi-001-empty-results \ --experiment claude-code-sonnet-5
Head-to-head: same model, skills on vs off
pnpm eval -- \ --experiment claude-code-sonnet-5 \ --experiment claude-code-sonnet-5-no-skills \ --suite benchmark
Full benchmark sweep across all shipped experiments
pnpm eval -- \ --suite benchmark \ --experiment-suite benchmark,no-skills pnpm export-results pnpm web
実験の構造(自分のものを追加できるように)
experiments/<name>.ts の下の実験ファイルは、エージェント、ランタイム、モデルを1つの比較可能な構成に配線する場所です。この分離は意図的です: 「Claude Code + Sonnet 5 + スキルなし」は「Claude Code + Sonnet 5 + スキルロード」とは異なる実験であり、両方とも「OpenCode + Kimi K3」とは異なります。3軸のうち2つを一定に保ち、3つ目を変化させられます。
リポジトリで出荷される -no-skills バリエーション(例: claude-code-sonnet-5-no-skills.ts vs claude-code-sonnet-5.ts)は、「スキルが 78% から 100% に引き上げた」の主張を雰囲気ではなく測定可能にするものです。
カスタムエージェント — 自作ループ、内部フォーク、実験的ハーネス — を実行しているなら、パターンは: 自分のエージェントを宣言する実験ファイルを書き、サンドボックス eval もほしいなら localStack: localStackRuntime() をオプトインし、benchmark スイートに対して実行する。あなたの数値は他の誰もと同じ表に着地します。
遅延ロードされるスキル
両方のランタイムはスキルにプログレッシブディスクロージャを使用します: 各スキルの名前と説明だけが常にシステムプロンプトに座り、エージェントは要求に応じて完全な指示を引き出します。だから「スキルオン」はターンあたり数個の追加トークンしかかからず、スコアを 20+ ポイント引き上げられます — エージェントは、スキルが関連すると判断したときにのみそのスキルの本体を支払います。
2つのランタイムは本体のフェッチ方法においてのみ異なります:
- Local-stack (サンドボックス) モード。 スキルは Vercel の
skillsCLI(サンドボックスイメージに焼き込まれ、ローカルのskills/ディレクトリから取得 — ネットワークからではない)で.claude/skills/の下にサンドボックスにインストールされます。タスクがマッチすると、エージェントは.claude/skills/<name>/SKILL.mdとそれが参照するファイルをファイルツールで読みます。 - Tools モード。 ファイルシステムなし、なので
load_skillツールが名前で呼ばれるとスキルの完全な指示を返します。
これが使用する新興のクロスエージェントスキル標準についてのコンテキストは、SKILL.md as an Open Standard を参照してください。
AILmanac マップでのこのページの位置付け
- ベンチマーク自体 → このページ。 Supabase Evals が何を、どう測るか、そして何を見出したか。
- Evaluating Agents — 自分のスタックで任意のコーディングエージェントを測るための一般的なプレイブック。
- Coding Agent CLIs Compared — ストーリーのハーネス半分(Claude Code vs Codex vs OpenCode をプログラムとして、任意のベンチマークとは独立)。
- Claude vs GPT vs Gemini for Coding — モデル半分。
★ Insight ─────────────────────────────────────
- このようなベンチマークは方向的にこそ最も有用で、絶対的にはそうではありません。「Sonnet 5 は Supabase スキルをロードすると 22 ポイント増えた」はあなた自身のプロジェクトに転移しますが、「Sonnet 5 は
buildで 100% をスコアする」は必ずしもそうではありません。 - リーダーボードを読んだ後の正しい質問は「どのエージェントが勝ったか」ではなく、「このベンチマークは私の作業に似た何をテストしているか」 — そしてそれらのスライスの下位スコアだけが重要です。
─────────────────────────────────────────────────
クイック自己チェック
Check yourself
0/5フラッシュカード
ソース & さらなる読み物
- github.com/supabase/evals — リポジトリ(Apache-2.0)、このページが引用した完全な README を含む。
- Introducing Supabase Evals — 初期クロスエージェントリーダーボード付きの発表投稿。
- supabase.com/evals — ライブ公開リーダーボード。
- github.com/supabase/agent-skills — ベンチマークが固定するスキルサブモジュール。
- github.com/supabase/supabase-lite —
@supabase/lite、ハーネスが対して実行する Management-API 互換サーフェス。 - MarkTechPost — Supabase Releases Evals — 発表時の発見のサードパーティサマリー。
- AILmanac 内の関連: Evaluating Agents · Coding Agent CLIs Compared · SKILL.md as an Open Standard。