Appearance
1. セッション概要
何をやったセッションか
2026年7月2日、「Sonnet 5 の性能を見るためにブラウザ動作する 3D 塊魂風ゲームを作る」 というブリーフで実行されたセッション。オブジェクトを取り込んで大きくなるボール、スケール遷移のシームレスさ、スケールが伸びても重くならない仕組み、Cloudflare Pages への公開、そして全作業ログの記録が要件だった。
成果物は公開済み: sonnet-katamari.pages.dev
セッションの基本数値
| 項目 | 値 |
|---|---|
| 実施日 | 2026-07-02 |
| 所要時間（初回コミット→最終コミット） | 約 71 分（11:31 → 12:42） |
| コード規模 | TypeScript 1,469 行（+ HTML/CSS） |
| コミット数 | 8 |
| ワークフロー実行 | 2 回（アーキテクチャ判定・コードレビュー） |
| サブエージェント数 | 22 体（判定パネル 6 + レビュー 16） |
| ワークフロー消費トークン | 945,733 トークン（メインループ分は別途） |
| 発見した不具合 | 14 件（プレイテスト 2 + レビュー 12） |
| 本番バンドル | 554 KB（gzip 141 KB） |
タイムライン（コミットベース）
| 時刻 | フェーズ | 内容 |
|---|---|---|
| 11:31 | 開始 | リポジトリ初期化 |
| 11:34 | スキャフォールド | Vite + TypeScript + Three.js セットアップ |
| （この間） | アーキテクチャ判定 | judge panel ワークフロー: 3 案の独立提案 + 独立採点 |
| 11:50 | 実装 | コアシステム一括実装（物理・ストリーミング・吸収・シェル・カメラ・HUD） |
| 12:09 | テスト & バグ修正 | ブラウザ自動化プレイテスト → 不具合 2 件発見・修正 + テストハーネス追加 |
| 12:13 | 機能追加 | タッチ操作・フォグのスケール追従 |
| 12:39 | レビュー & 修正 | 4 次元レビューワークフロー → 12 件確定 → 全件修正 |
| 12:41 頃 | デプロイ | Cloudflare Pages 公開 + 本番検証 |
| 12:42 | 完了 | devlog 最終化 |
アーキテクチャの決め方（judge panel）
実装に入る前に、3 つの独立した設計案（perf-first / simplicity-first / seamlessness-first）を互いを知らないエージェントに提案させ、別の独立審査員が 4 軸（性能・シームレスさ・実装容易性・見た目）で採点するワークフローを実行した。
| 案 | 中心アイデア | 合計点/40 |
|---|---|---|
| perf-first | 10 の累乗で 8 段の離散ティア、切替をズーム+ブラーで隠す | 22 |
| simplicity-first | リスケールなし、固定 800m ワールド | 24 |
| seamlessness-first | 半径の連続関数のみ（ティア変数を一切持たない） | 29 |
最終設計は勝者をそのまま採用せず、敗者の審査コメントから最良の指摘を移植したハイブリッドにした点が特徴的:
- simplicity-first の審査員による「float32 の相対誤差 ~1.2e-7 なら 4km ワールドの絶対誤差は ~0.5mm。フローティングオリジン機構はそもそも要らないのでは」という指摘を採用し、全提案が最大リスクと認めていた機構を丸ごと排除した。
- 3 案が独立に「物理エンジン不使用」で一致したことを、判断の確からしさの裏付けとして採用した。
この「独立提案の収束を確信度として扱う」やり方は、Fable 5 版の Qiita 記事が「独立な提案が収束する価値」として挙げているものと同じ構造であり、両モデルのセッションで同一のパターンが再現されている。
このサイトの読み方
本サイトの主題はユーザーの関心である デバッグ性能 ── どれくらいのテストを行い、どんな不具合を見つけられたのか。
- 2. テストの実態 — テストの量と手法。rAF スロットリング問題の切り分けを含む
- 3. 発見した不具合カタログ — 14 件全件を深刻度別に解説
- 4. レビューワークフローの仕組み — 4 次元レビュー + 敵対的検証の構造
- 5. Fable 5 との比較 — Qiita 記事の実装記録との定量・定性比較
- 6. 総合評価 — まとめ