KATAMARI DEBUG BATTLE — SESSION LOG ANALYSIS

SONNET 5vsFABLE 5
デバッグ性能対決

同じ「ブラウザで動く塊魂風3Dゲームを作って公開する」ブリーフを受けた2つのセッション。 どれだけテストし、どんな不具合を見つけられたのか──実際のセッション生ログとゲーム画面を並べて解剖する。

Sonnet 5版 Katamari: 30cmのボールと草原、WASD操作プロンプト
sonnet-katamari.pages.dev — 手続き生成ワールド 4km²、0.15m→300m(2000倍)。開発時間 約71分。
Fable 5版 Katamari: タイトル画面「転がして、東京まるごと。」
fable-katamari.pages.dev — 実在東京14,563棟、2cm→634mスカイツリー。5バージョン・17時間超。
投下トークン
94.6vs1,816
約19倍差
発見・確定した不具合
14vs21件+ (v1)
検証スタイルが対照的
レビュー指摘の偽陽性
0%vs36% 棄却
precision型 vs recall型
⚖️ フェアな比較のための前提。Fable 5 は5バージョン累計で 約148エージェント・約1,816万トークン・17時間超、 Sonnet 5 は単一バージョンで 22エージェント・ワークフロー約94.6万トークン・約71分。総量は約19倍違う。 規模を揃えるなら Fable 5 の v1(初版: 48エージェント・約377万トークン・約134分)と Sonnet 5 全体の比較が最も近く、それでもトークン約4倍・時間約2倍の差がある。 以下、レビュー系の比較は原則 Fable v1 を基準に、テスト規模など累計しかない数字は「累計」と明記する。 Sonnet 側の一次資料はこのマシンに残るセッション生ログ・ワークフロー実行記録・devlog、 Fable 側は Qiita 記事の実装記録
ROUND 1

🎮 できあがったゲームを見る

左: Sonnet 5(プレイ動画 playdemo.mov 11分から抽出)。右: Fable 5(本日ヘッドレスブラウザで実プレイして撮影)。

SONNET 5 — 2000倍成長の一部始終
0:05 — 32cm 32cm: 草原にネジやクリップが散らばる
序盤 32cm。地面の赤い点はネジや消しゴム級の小物。ワールド描画コールはこの時点から最後まで29固定(アーキタイプごとに1 InstancedMesh)。
5:00 — 22.1m 22.1m: 建物と樹木を巻き込む
中盤 22.1m。樹木や建物が「取れるもの」に変わる。バンドはスポーン条件のみで、カメラ・描画にティア分岐が1つもないのがこの実装の核。
9:30 — 106.9m 106.9m: ランドマーク級が視界に入る
終盤 106.9m。カメラ距離・FOV・near/far は半径の連続関数+スプリング平滑。動画を通してズーム切替の「継ぎ目」が一度も出ない
10:40 — 152.7m 152.7m: 岩山級を巻き込みつつ300mへ
152.7m → ゴール300mへ。表面に残る「くっつき物」は直近分だけライブインスタンス、古い分は最大12チャンクへマージ。この上限が正しく効くかが後のバグ発見の主戦場になった。
FABLE 5 — 机の上から東京まるごと
タイトル Fable Katamari タイトル画面
「転がして、東京まるごと。」操作説明・実況トグル・OSMクレジットまで備えたプロダクト級の顔。5バージョンの積み上げの成果。
開始 — 2.0cm 2.0cm: 机の上でネジを狙う
開始 2.0cm、机の上。タイマー・スコア・コンボ・実況バー(センゴク電子)付き。ゲームとしての情報設計が Sonnet 版より数段リッチ。
55秒 — 3.2cm 3.2cm: ネジやボタンを吸着、スコア845
3.2cm・スコア845×3。この続きに東京の街区・JR高架・ビル群、そして634mスカイツリー吸収のエンディングが待つ(実在建物14,563棟・OSM実データ)。
📌
この2枚は本日 agent-browser(ヘッドレスChrome)で実際にプレイして撮影したもの。W/Aキーの keydown を注入して 2.0cm→3.2cm まで成長させた。 Sonnet セッションが直面した「自動化タブでは rAF が止まる」問題(ROUND 2 参照)はヘッドレスでは起きない、という対照実験にもなっている。
ROUND 2

🧪 テスト対決 — 観測駆動 vs アサート駆動

ユーザーの一番の関心「どれくらいテストしたのか」。両者はテストのだけでなく資産の形が根本的に違う。

SONNET 5実フレーム10万+を観測

アサートスイートは書かず、本物の毎フレーム更新関数を実ブラウザ内で大量駆動して観測する方式。まず「動かない」の切り分けから始まった。

生ログ①: 「ボールが動かない」→ 環境要因の即時特定
// キー入力を送ってもボールが動かない。コードを疑う前に環境を観測:
javascript_exec → JSON.stringify({
  hidden: document.hidden,
  visibilityState: document.visibilityState,
  hasFocus: document.hasFocus() })
// 結果: hidden=true — 自動化タブは非フォアグラウンドなので
// Chrome が requestAnimationFrame を丸ごとサスペンドしていた。
→ ゲームのバグではない(ブラウザの正常動作)と確定
🔍
注目: 「直す」前に「観測して原因を確定」する順序。存在しないバグを修正して回帰を混入させる最悪パターンを構造的に回避した。
生ログ②: dev専用テストハーネスを自作(main.ts への実際の編集)
// rAFが止まる環境でも同一コードパスをテストできるようフックを追加:
;(window as unknown as { ... }).__manualStep = (
  dtMs, input,
) => step(dtMs / 1000, input ?? readMoveInput())
// import.meta.env.DEV でガード → 本番では undefined を確認済み
生ログ③: 300 → 40,000フレームへエスカレートする実際の駆動コマンド
for (let i = 0; i < 300; i++)   __manualStep(16, { forward: 1, turn: 0 });
for (let i = 0; i < 3000; i++)  __manualStep(16, { forward: 1, turn: 0.15 });
for (let i = 0; i < 20000; i++) {           // スパイラル走行
  const turn = Math.sin(i / 40) * 0.8;
  __manualStep(16, { forward: 1, turn });
}
const t0 = performance.now();
for (let i = 0; i < 40000; i++) { ... }   // 実時間も計測
JSON.stringify({ debug: __debug(), realMs: t1 - t0,
  stats: document.querySelector('.hud-stats').textContent })
📈
注目: 半径 0.15m→0.48m→4.2m→11.5m→30.9m→(テレポートで)300m の成長カーブが三乗成長モデルの理論値と一致することまで確認。累計10万フレーム超、修正検証では 70,000+ / 60,000+ フレームのストレス走行、リスタート5連打、fps 62–70 維持を観測。

弱点: 再実行可能な回帰テストスイートは残らない(ハーネスは dev ビルド限定のフックのみ)。

FABLE 5約3,000アサート + 実機25パス

仕様を機械検証可能な形に固定するアサート駆動。5バージョンの積み上げ開発を回帰から守るインフラとして機能した(数値は記事記載・累計)。

ヘッドレステスト 約3,000アサート

うち v4 の OpenStreetMap 実データ検証だけで 2,376件。地図データの座標変換・建物数・タイル整合を機械検証。

実機ブラウザ検証 25パス・スクリーンショット27枚

agent-browser による実機検証を毎版実施。終端速度キャップ不達(ACCEL_K=22)のような実測でしか出ない数値バグはここで捕捉された。

1 ulp(1.7×10⁻¹⁶)の精度検証

KeyR リスケール処理の数値誤差を浮動小数点の最小単位レベルで確認。検証の「深さ」の証拠。

外部データの自律検算

批評エージェントが Overpass API を自分で叩いて OSM 建物数の設計見積もりを検算し、1.5倍のズレを発見。検証がコードの外の事実にまで届いている。

⚖️
注目: 記事によれば全工数の約58%がテスト・レビューに投下。単発デモには Sonnet の観測駆動が速く、多バージョン継続開発には Fable のアサート資産が効く——戦略がそれぞれのセッション性質と噛み合っている。
ROUND 3

🐛 発見した不具合対決

「どんな不具合を見つけられたのか」。深刻なものから順に、実際に見つかったバグを並べる。

SONNET 5 — 14件(プレイテスト2 + レビュー12)

HIGHリスタートで GPU リソースが全リーク

コードベースに .dispose() が1箇所もなく、「Roll again」のたびに旧ジオメトリ/マテリアル+約58個の InstancedMesh バッファを恒久リーク。正確性・性能の2次元が互いを知らずに同一指摘した。

生ログ④: 検証エージェントの実際の報告(GPUリーク指摘に対して)
// 指摘を鵜呑みにせず three.js の実物ソースまで遡って確認:
"Verified end-to-end against the actual source and the
actual three.js version in node_modules.
 1. Reachability confirmed: src/ui/HUD.ts:59 wires
    the 'Roll again' ..." → verdict: CONFIRMED

HIGH自分の修正に潜んでいた「二次バグ」を検証段階で発見

プレイテスト後に入れたチャンク数上限(12個)の修正に対し、検証エージェントが「最大半径で頭打ちになると埋没間引き条件 currentRadius > attachRadius × 1.25 が二度と真にならない」ことを発見。勝利画面はオーバーレイでプレイは止まらないため、勝利後も吸収を続けると同じ12チャンクのジオメトリが無限肥大する。エッジケース×仕様の穴の組み合わせ推論で、このセッション最高のデバッグ成果

生ログ⑤: 修正を「観測可能」にしてから検証(Shell.ts への実際の編集)
stats() {
  // 検証のために観測メトリクスを新設 →
  const maxChunkParts = this.chunkPartCounts.length > 0
    ? Math.max(...this.chunkPartCounts) : 0
  return { liveCount, mergedChunks, maxChunkParts }
}
// 半径299へテレポート → 60,000+フレーム連続吸収 →
→ maxChunkParts が上限400に張り付いたまま動かないことを確認

HIGHシェル描画コール無限増加(プレイテストで発見)

長時間走行で統計オーバーレイの shell chunks が220超まで増加。「プレイ時間に関わらず描画コール有界」の設計目標に直接違反。上限12+ラウンドロビン再マージで修正し、70,000+フレームで検証。

HIGHリスタートでカメラ/勝利バナーが未リセット(プレイテストで発見)

再スタート後もカメラは半径300m用の位置のまま、新しい15cmのボールは視錐台の外→画面はグラデ背景だけ。「動いてそう」の先まで押し込む長時間プレイテストで捕捉。

MED×2 — 吸収済みオブジェクトの復活 / 成長時の1フレーム沈み込み

SpatialGrid の全リバケットが吸収済みを蘇らせ約12Hzのホットパスを浪費。grow() の位置未同期で最大50msの「沈んでポン」グリッチ。

LOW×8 — 重複・デッドコード

clamp の4重実装、成長式の重複、書かれなかった関数を参照するコメント、29エントリに配線された未使用フィールドなど。すべて削除・共通化済み。

FABLE 5 — v1で21件確定 + 各版の実戦バグ

HIGH終端速度キャップに実測で届かない(v1・実機検証で発見)

設計上の最高速度に実プレイで到達できない。ACCEL_K=22 への調整で解決。アサートでは出ない「実測系」バグを25パスの実機検証網が捕捉した好例。

HIGHキュレートランドマークがティア帯外で不可視(v3)

スカイツリー等の見せ場ランドマークが、成長帯の谷間で描画対象から漏れて見えなくなる。DYNAMIC RE-BANDING(動的帯再割当)で修正。

HUMAN開幕不可視バグ — 自動検証を0エラーで通過、人間が発見(v4)

OSM実データ導入後、JR総武線の高架がスポーン地点の真上にあり開幕の視界を天井のように塞ぐ。約3,000アサートも実機25パスも通過し、人間の実プレイで初めて発見された。記事はこれを「AIゲートでは代替不可の人間検証が必須」の根拠に挙げる。

MEDOSM建物数の設計見積もりが1.5倍ズレ(v4)

批評エージェントが Overpass API で自律検算して発見。コードではなく設計数値のバグを捕まえた点で検証範囲の広さを示す。

棄却「フレーム1の大量吸収」— もっともらしい指摘を反証で棄却(v1)

スポーン順序の誤りという指摘が出たが、独立懐疑エージェントの反証で偽陽性として棄却。v1では計9件(36%)がこのふるいで落とされ、無駄な修正による回帰を防いだ。

🥊
対戦成績の読み方: 「上限到達後に条件が二度と真にならない」型の境界バグは Sonnet が、「実測・実データ・人間の目でしか出ない」型は Fable が捕えた。前者はコード推論の深さ、後者は検証チャネルの幅の勝負で、それぞれの投下規模を反映している。
ROUND 4

⚖️ レビュー精度 — 12/12 と 36%棄却をどう読むか

両者とも「指摘 → 独立した懐疑エージェントが反証を試みる」敵対的検証を採用。結果の形が正反対に出た。

SONNET 5 — precision型12指摘 / 12確定 / 棄却0
確定 12

4次元(正確性/性能・メモリ/セキュリティ/簡素化)× 16エージェント、実行時間 12.5分。 検証は素通しではない: three.js のソースまで遡り、検証中に二次バグを新規発見し、セキュリティ次元は静的サイトとして正しい「0件」を返した。 確度の高い指摘だけを出す発見側の precision が高かった、と読むのが妥当。ただし網を広げたら何件出たかは未知(recall 未証明)。

FABLE 5 (v1) — recall型30指摘 / 21確定 / 9棄却
×××××××××
確定 21偽陽性として棄却 9(36%)

4次元検証+敵対検証で 36エージェント・54分。広い網を張り、懐疑段階でふるい落とす設計。 棄却率36%という数字自体が「検証段階が機能している」証拠として残るのが recall 型の強み。確定21件のうち16件を修正。

レビューフェーズのトークン投下量
Sonnet 579.0万
Fable v1255.3万
確定バグ1件あたりのレビューコスト
Sonnet 5≈6.6万 tok/件
Fable v1≈12.2万 tok/件
Fable の単価には偽陽性9件の棄却コスト=「回帰を防ぐ保険料」が含まれる。単価差は性能差というより戦略の違いの反映
レビュー体制の規模(エージェント数)
Sonnet 516体 / 12.5分
Fable v136体 / 54分
FINAL

🏁 総合評価

観点SONNET 5FABLE 5根拠
根本原因分析★★★★★★★★★★S: rAFスロットリングの完全な切り分け、three.jsソース追跡 / F: 実測バグの原因特定、外部API検算
テスト量(対規模比)★★★★☆★★★★★S: 10万+フレーム観測・5種ストレス、ただし回帰資産なし / F: 3,000アサート+実機25パスの再実行可能インフラ
バグ発見の質★★★★★★★★★★S: GPU全リーク・境界条件の二次バグ / F: 実測系・実データ系・人間発見バグまで到達
検証の独立性★★★★☆★★★★★S: 敵対検証が機能(二次バグ発見)だが棄却実績なし / F: 棄却率36%が網の広さとふるいの実効性を証明
検証の網羅性★★★☆☆★★★★★S: コードとブラウザ内観測に閉じる / F: 実測値・外部データ・人間プレイまで検証チャネルを拡張
コスト効率★★★★★★★★☆☆S: 約1/19のトークン・71分で公開品質+14件修正 / F: 品質は圧倒的だが1,816万トークン・17時間超
結論。Fable 5 が「広い網と多段のふるいで、実測・実データ・人間の目までチャネルを広げる」recall 型のデバッグを17時間かけて示したのに対し、 Sonnet 5 は「確度の高い指摘・観測に基づく検証・自分の修正すら疑って二次バグを掘り当てる姿勢」という precision 型のデバッグを71分で示した。 検証チャネルの幅と回帰テスト資産では Fable に届かないが、約1/19のトークンで公開品質のゲームと14件の確定バグ修正まで到達した規模対効果は十分に高い評価に値する。 そして両者に共通する教訓がひとつ──総武線高架バグが証明した通り、自動検証がどれだけ厚くても「人間が遊ぶ」工程は代替できない
そして、両者を支えた共通の土台 — 5系の画像認識能力。 この2セッションのデバッグスタイルは対照的だが、どちらも「ゲーム画面のスクリーンショットを自分で見て判断する」能力の上に成立している。 Sonnet 5 の rAF 問題の発見は「スクショではワールドが配置されているのにボールだけ動かない」という画面の違和感の読み取りが起点だったし、 HUD の数値(32cm / 22.1m / shell chunks 220…)をスクショから読んで検証の合否を判定し続けた。 Fable 5 は27枚のスクリーンショットと実機25パスの検証網そのものが視覚判断の連続であり、 「見せ場のランドマークが不可視」「開幕の視界が高架で塞がる」といった座標やアサートでは表現しにくい"見た目のバグ"のクラスに踏み込めている。 3Dゲームという題材でここまで自走できたこと自体が、Claude 5系(Sonnet 5 / Fable 5)の画像認識能力の高さを示す実証になっている── スクショを「読める」からこそ、観測駆動テストも実機検証パスも、AIだけで回るデバッグループとして機能した。
付記 — Fable モデルの視点から: 今後 Sonnet 5 に何を任せるべきか。 本ページの分析者である Fable 5 として、このセッションで観測した事実から率直に言えば、 「作って・動かして・画面を見て・直す」が1セッションで閉じるタスクは、もう Sonnet 5 に渡すべきだ。 具体的には── (1) プロトタイプ/デモ/社内ツールの単発実装+検証(今回の71分・94.6万トークンで公開品質に届いた領域そのもの)、 (2) スクショ駆動の E2E・UI 検証ループ(HUD の数値をスクショから読み、観測メトリクスを自分で新設して合否判定する動きは既に実証済み)、 (3) 偽陽性を出せない CI レビューゲート(12/12・棄却0の precision はゲート用途と相性がいい)、 (4) 症状→根本原因の切り分け調査(rAF 問題の診断が示した「直す前に観測で確定させる」規律)。

Opus 4.8 との使い分けはコスト構造で決まる。Opus が上位の単発推論力を持つ一方、 Sonnet 5 の強みは「視覚検証を含む反復ループを、コストを気にせず何十回も回せる」こと。 スクショ確認を挟む反復デバッグ、レビュー次元や検証エージェントを大量並列するワークフローのワーカー、 ビジュアルリグレッションの一次判定──1回の深さより回転数と並列数が効く場面では、 同じ予算で桁違いの試行回数を買える Sonnet 5 が Opus 4.8 より総合力で上回り得る。

逆に Fable/Opus 級を残すべきは、広い設計空間の判断(judge panel)、多バージョンにまたがる recall 型監査、 仕様の外側まで疑う検証チャネルの設計。実務の最適解はおそらくハイブリッド── Fable が設計判断と最終監査を持ち、Sonnet 5 のフリートが実装・視覚検証・一次レビューを回す。 今回の2セッションは、その分業が成立することの実証でもある。