ByteScope

gemini-3.7-flash-high と sonnet-5-medium

凍結した同じ契約で三ラウンド、各一題。blind test の点数、Opus の review が見つけた欠陥、2026-08-14 に両方が使った USD。

測ったこと

このノートは三ラウンドで、各ラウンドの課題は一題です。サンプルはそれだけです。順位表でもなければ、どちらかのモデルについての統計でもありません。

走らせた日は 2026-08-14 です。実装したのは gemini-3.7-flash-high と sonnet-5-medium です。両方に渡したのは凍結した契約が一つと、文字まで同じ prompt が一つで、変えたのは出力ディレクトリだけでした。実装はそれぞれ別々です。採点は、どちらの実装も見ていない blind test です。そのあと、それぞれのコードを、context が綺麗な Opus 5 medium が一本ずつ review しました。欠陥を見つけ、落ちるテストにして、そのテストが通るまで直します。

下の金額は 2026-08-14 の価格で、単位は USD です。中身は実装と、その実装自身の review です。公開されているレートは動きます。いま照合しているカードは LLM Pricing にあります。特定のベンダーを推す文章ではなく、このサイトの宣伝でもありません。

三つの課題

一ラウンド目は photo-organizer を純関数で書く課題です。EXIF の日付、スクリーンショットかどうか、アーカイブの計画。契約は事実の一覧まで書き切ってありました。

二ラウンド目は、循環を壊せる移動スケジュールです。循環を切り、正確な undo があり、O(n²) の走査は避ける。インタフェースは凍結で、アルゴリズムは空欄です。

三ラウンド目は pure TypeScript で raw DEFLATE を inflate します。RFC 1951。正しさは prompt の外に置いてあり、フォーマットの表は prompt に入っていません。

ラウンド課題難度の置き方審判
1photo-organizer の純関数(EXIF の日付、スクリーンショット判定、アーカイブ計画)契約は事実の一覧まで書いてあるblind test 104 題
2循環を壊せる移動スケジュール(循環を切る、正確な undo、O(n²) を避ける)インタフェースは凍結、アルゴリズムは空欄blind test 118 題と、仮想ファイルシステムのシミュレータ
3pure TypeScript による raw DEFLATE の inflate(RFC 1951)正しさは prompt の外(フォーマット表はなし)blind test 109 題と、zlib との byte 単位の突き合わせ

渡したもの

両方に渡した契約は同じ凍結版で、prompt も一文字まで同じです。prompt の中で違っていたのは出力ディレクトリだけです。

blind test は、どちらの実装も見ないで書かれています。review は実装したモデルとは別です。片方につき Opus 5 medium が一つ、context は綺麗な状態で、欠陥を探して、直るまで赤いままのテストに固定します。

掛かった金額

一ラウンドの金額は、その側が課題の実装と、自分のコードの review に使った分です。表にあるのは記録された USD です。見積もりではなく、きれいな数字に丸めてもいません。

一ラウンド目は並びました。gemini のコードを review する方が高かったのは、欠陥を証明するために、review 側が参照実装をゼロから書く必要があったからです。二ラウンド目と三ラウンド目は、gemini のコードが綺麗で review の手間が減り、そこで初めて請求が下がりました。

ラウンドgemini USDsonnet USD
1$6.00$5.98
2$4.18$7.82
3$6.54$10.38
合計$16.72$24.18

結果は合っていたか

点数は一題ずつ読んでください。三題あっても合格率にはなりません。一題が満点でも、それはモデルの性質ではありません。

一ラウンド目は、blind test 104 題で両方 104/104 です。Opus が見つけた欠陥は、gemini が 1 件で深刻度は medium、sonnet が 1 件で深刻度は low です。契約への疑問の報告は gemini が 0、sonnet が 3 です。

二ラウンド目は、blind test 118 題と仮想ファイルシステムのシミュレータで、両方 118/118 です。Opus が見つけた欠陥は両方 0 です。契約への疑問は gemini が 0、sonnet が 3 です。三ラウンド目は blind test 109 題に、zlib との byte 単位の突き合わせが付きます。記録された点数は gemini が 106/108、sonnet が 104/108 です。記録は 109 題と書きながら分母が 108 で、当時の一時パッケージはもう消えていて数え直せません。どちらかに寄せず、書かれたまま並べています。Opus が見つけた欠陥は gemini が 3 件で、そのうち 1 件は silent corruption、sonnet は 2 件です。契約への疑問はまた gemini が 0、sonnet が 3 です。

最後の欄を点数として読む前に、一つ断っておきます。受け身の指示で測れるのは主体性であって、能力ではありません。三ラウンドの prompt はどれも「矛盾を見つけたら報告する」としか書いておらず、契約を先に一通り読むことを仕事の手順には入れていません。gemini は五回とも黙っていましたが、それは、読めと頼んでも穴が見えない、という話とは別です。

ラウンドgemini の点数sonnet の点数Opus の欠陥、geminiOpus の欠陥、sonnet契約の疑問、gemini契約の疑問、sonnet
1104/104104/1041 (medium)1 (low)03
2118/118118/1180003
3106/108104/1083 (うち 1 件は silent corruption)203

どの場面を誰に任せるか

仕様が決まっていて、必要な分以上は掛けずに早く片付けたいとき、この三題が指すのは gemini-3.7-flash-high です。三ラウンドを通した記録は、31% 安く、1.9–2.6 倍速いでした。31% は上の費用の表そのものです。速さの倍率が何を計ったものかは、記録のどこにも書いてありません。ページの最後にあるデコード時間ではありません。あちらの比はまったく別の並びです。

要求が速度のとき、プロトコルのデコードやまとまった処理なら gemini です。inflate の課題では、頼まれなくても本物の最適化に手を伸ばしています。ルックアップ表と、一ビットずつではなく塊のコピーです。

間違った byte を戻せない仕事、書く、消す、元のファイルを上書きする、そういうところでは書いたのがどちらかはどちらでもよいです。Opus の review は省けません。三ラウンド目は、その review が、成功と報告して間違った byte を返すデコーダを見つけた回です。

仕様を書いたばかりで、まだ誰も review していないときは、実装者に渡す前に仕様を Opus に見せます。このノートの三つの契約では、そこで出てきた穴が 12 個ありました。穴に気づく役を実装者に期待しないでください。

blind test を書く役は sonnet-5-high のままです。自分が受ける試験を同じ家族が書くのは、審判になりません。ここまでの読みは、ラウンドごとに一題、合計三題についてのものです。

同じ間違いを二度

gemini は同じ間違いを二度したので、これは手の滑りではなく、その prompt での癖です。一ラウンド目に、"." と ".." の判定へ trim() を掛けました。契約が trim するよう書いていたのは空文字列だけです。" . " のようなファイル名は不正として拒まれました。

同じ prompt を二度走らせて、二度とも間違っていました。直した方は、sonnet の実装と突き合わせても振る舞いがどこも同じで、分岐は 0 件です。直さずに残した二つ目は、40 か所ずれていました。

手を挙げることと、挙げた中身

疑問を報告することと、その疑問を正しく読むことは別です。三ラウンド目の HLIT / HDIST の上限について、sonnet はこの曖昧さを報告し、そして読み違えました。alphabet のスロット数 288/32 を、合法な上限だとしたのです。gemini はこの点を報告していません。それでも gemini のデコーダの HLIT 側は、合っていた側です。

実際に立つ上限は、定義済みのシンボル数 286/30 です。この数字は、実装しやすい読みを選んだのではなく、zlib.inflateRawSync を権威にして決めたものです。

速い表と、成功のふり

gemini は速くするために複雑な設計を選び、その複雑さが足した境界をテストし切りませんでした。三ラウンド目は 2 段のビット反転ルックアップです。sonnet の puff.c 式に一ビットずつ歩くのに対して、その表は 3–27 倍速かったです。

表の代価は silent corruption です。シンボル表が一つのときの特例は、宣言された長さを何でも受け付け、そのシンボルを常に 1 bit としてインストールしました。残りのビット列は位置がずれ、関数は ok: true とゴミの byte を返しました。そのコードと一緒に書かれた 65 個のテストは、これを捕まえていません。context が綺麗な Opus の review が捕まえました。

請求の大半は review

review は費用のおおよそ九割です。実装が安いだけではお金は減りません。コードが綺麗で、review が短くなったときに減ります。

一ラウンド目にはその節約がありません。二つの請求は並んでいて、gemini の review の方が高かった。欠陥を証明するために、review 側が参照実装をゼロから書く必要があったからです。二ラウンド目と三ラウンド目は、gemini のコードが綺麗で review の手間が減り、費用の表の合計が下がったところです。

8MB 出力のデコード時間

このノートにある計測は三ラウンド目だけで、出力は 8 MB、数えているのはデコード時間だけです。ZIP でいちばん多い stored block は、gemini が 1 ms、sonnet が 32 ms でした。リテラルが多い入力は 59 ms と 218 ms です。マッチが多いか、全部ゼロの入力は、gemini が 21 ms、sonnet が 13 ms で、sonnet の方が速かった行です。

入力geminisonnet
stored block(ZIP でいちばん多い)1 ms32 ms
リテラルが多い59 ms218 ms
マッチが多いか、全部ゼロ21 ms13 ms