Appearance
5. Fable 5 との比較
比較対象は Qiita 記事「Fable 5 による Katamari ゲーム開発」に記録された fable-katamari.pages.dev の実装記録。同じ「ブラウザ動作する 3D 塊魂風ゲーム」ブリーフの別モデル実装であり、マルチモデル能力ベンチマークの兄弟エントリにあたる。
前提: 規模が大きく違う比較であること
Fable 5 版は 5 バージョン（無限スケール → 月エンディング → 東京箱庭 → OpenStreetMap 実データ 14,563 棟 → エンディング強化）を積み上げた累計 約 148 エージェント・約 1,816 万トークン・17 時間超 のプロジェクト。Sonnet 5 版は 単一バージョン・22 エージェント・ワークフロー約 94.6 万トークン・約 71 分。総量比較は約 19 倍差があり、そのまま並べるのはフェアではない。
最も条件が近いのは Fable 5 の v1（初版、48 エージェント・約 377 万トークン・約 134 分）と Sonnet 5 のプロジェクト全体 の比較で、それでもトークンで約 4 倍、時間で約 2 倍の差がある。以下ではこの正規化を基本にしつつ、総量の数字も併記する。
定量比較
| 項目 | Sonnet 5（本セッション） | Fable 5 v1 | Fable 5 累計（v1–v5） |
|---|---|---|---|
| エージェント数 | 22 | 48 | 約 148 |
| トークン | 約 94.6 万（ワークフロー分） | 約 377 万 | 約 1,816 万 |
| 所要時間 | 約 71 分 | 約 134 分 | 17 時間超 |
| レビュー体制 | 4 次元 + 敵対的検証（16 体） | 4 次元検証 + 敵対検証（36 体） | 同左を版ごとに実施 |
| レビュー指摘の確定数 | 12 / 12（棄却 0） | 21 確定 / 偽陽性 9 棄却（棄却率 36%）、16 修正 | — |
| ヘッドレステスト | なし（フレームシミュレーション 10 万+ が代替) | あり | 約 3,000 アサート（v4 OSM 検証 2,376 件） |
| 実機ブラウザ検証 | claude-in-chrome + 本番検証 | あり | agent-browser 25 パス、スクリーンショット 27 枚 |
| 精度検証の深さ | 三乗成長モデルの理論カーブ一致確認 | — | KeyR リスケールで 1 ulp（1.7×10⁻¹⁶） 精度確認 |
| コード規模 | TS 1,469 行、554KB（gzip 141KB） | 28 モジュール、585.73KB（gzip 154.31KB） | + OSM 地図バイナリ 284KB gz |
| スコープ | 手続き生成ワールド 4km²、0.15m→300m | 無限スケール土台 | 実在東京 14,563 棟 + スカイツリー 634m |
テスト戦略の違い: 観測駆動 vs アサート駆動
両者の最も本質的な違いは量ではなくテスト資産の形にある。
Sonnet 5 = 観測駆動。本物の毎フレーム更新関数を dev 専用フックで 10 万フレーム以上駆動し、統計オーバーレイ（描画コール数、maxChunkParts 等）を観測して合否を判断する。検証のために観測メトリクス自体を新設する動きもあった。実プレイヤーと同一コードパスを通る点が強みだが、再実行可能な回帰テストスイートは残らない（ハーネスは dev ビルド限定のフックのみ）。
Fable 5 = アサート駆動 + 実機。約 3,000 件のヘッドレスアサートは仕様を機械検証可能な形で固定し、v2→v5 と版を重ねるたびに回帰を防ぐ資産として機能した。さらに批評エージェントが Overpass API を自律的に叩いて OSM 建物数の設計見積もりを検算し、1.5 倍のズレを発見するなど、コードの外の事実に対する検証まで踏み込んでいる。
この差は各セッションの性質と整合する: 単発 71 分のデモには観測駆動が速く、5 バージョン 17 時間の継続開発にはアサート資産が効く。ただし「どちらのモデルもその判断ができた」ことの証明にはならない点は留意が必要。
レビュー精度の違い: 12/12 と棄却率 36% をどう読むか
一見すると Sonnet 5 の「偽陽性 0」が優秀に見えるが、これは precision / recall のトレードオフの両端と読むべき。
- Sonnet 5（precision 型): 発見側が確度の高い 12 件だけを報告し、全件が検証を通過。無駄な修正コストはゼロだが、指摘の絶対数は小さく、広い網を張った場合に何件見つかったかは不明。
- Fable 5（recall 型): 発見側が約 30 件の広い網を張り、敵対検証で 9 件（36%）を構造的にふるい落とした。「フレーム 1 の大量吸収」のような一見もっともらしい指摘が反証で棄却された実例があり、検証段階が機能している証拠が棄却率として残っている。
Sonnet 5 側で検証段階が機能した証拠は棄却ではなく別の形で残った──検証中に既存修正の二次バグを新規発見したこと。どちらのセッションでも「発見を独立に疑う」構造そのものが価値を出しており、これは記事の主張「敵対的検証の有効性」を別モデルで再現した結果と言える。
見つけた不具合の質の比較
| 不具合のクラス | Sonnet 5 | Fable 5 |
|---|---|---|
| 上限到達後の無限成長（頭打ち条件が二度と真にならない） | ✅ 埋没間引きが最大半径で破綻 → チャンク肥大（検証段階で発見） | — |
| リソースライフサイクル | ✅ GPU リソース全リーク（three.js ソースまで遡って確認） | — |
| 数値・物理の実測ズレ | —（理論カーブ一致確認まで） | ✅ 終端速度キャップ不達（ACCEL_K=22、実機で発見）、1 ulp 精度検証 |
| 設計見積もりの検算 | — | ✅ OSM 建物数 1.5 倍ズレ（外部 API 検算で発見） |
| 状態リセット漏れ | ✅ リスタートでカメラ/HUD 未リセット | ✅ v3 ランドマークがティア帯外で不可視 |
| 人間プレイでのみ発見 | —（該当フェーズなし） | ✅ 開幕不可視バグ（JR 総武線高架が視界を塞ぐ。自動検証 0 エラーで通過、実機プレイで初発見） |
両者とも「もっともらしく動くが境界条件で破綻する」クラスのバグを自動で捕まえられている。Fable 5 の優位はコードの外（実測値・外部データ・人間の目)に検証を広げた点で、これは投下規模と多バージョン運用が可能にした幅でもある。
共有される盲点: 最後は人間が遊ぶ
Qiita 記事の結論の一つ「総武線高架バグは自動検証を 0 エラーで通過し、実機プレイで初めて見つかった──人間検証は代替不可」は、Sonnet 5 セッションにもそのまま当てはまる。本セッションのテストはすべて自動（シミュレーション + 自動化ブラウザ）で、人間プレイフェーズは記録されていない。リポジトリに後日 playdemo.mov が置かれていることから、実プレイは事後に行われたと見られる。「自動検証の網羅性はプレイフィールの検証を含まない」という限界は、モデルに依らず共通している。
コスト効率の粗い見積もり
厳密な比較は不可能（検出難度も検証深度も違う）だが、オーダー感として:
- Sonnet 5: 確定 14 件 / ワークフロー 94.6 万トークン ≒ 6.8 万トークン/件
- Fable 5 v1: 確定 21 件 / レビューフェーズ 255.3 万トークン ≒ 12.2 万トークン/件（ただし偽陽性 9 件の棄却コスト＝回帰防止の保険料を含む）
Fable 5 の単価には「広い網 + ふるい落とし」の保険料が乗っており、単価の差は性能差というよりも戦略の違いの反映と読むのが妥当。