FABLE KATAMARI

シミュレーションは常にボール半径 0.5〜2.5（シミュレーション単位）の狭い数値帯で行います。半径が2.5に達したフレームで、全座標・全速度・全半径に一様な相似変換 S = 0.2 を1フレーム内に適用し、ボールを0.5に戻します。「実際の大きさ」は倍精度の worldScale 変数で別管理し（リスケールごとに5倍）、HUD表示にだけ使います。

なぜ画面が一切変わらないのか: カメラ距離・フォグ距離・速度上限がすべて「半径の純関数」（例: カメラ距離 = 6.5 × r）だからです。rが0.2倍になればカメラ距離も0.2倍になり、相似な世界を相似な距離から見るので投影結果は同一。32bit浮動小数点の精度は常にフルに保たれ、理論上は成長の上限がありません。検証用に「強制リスケールキー + 前後スクリーンショットのピクセル差分」というテストまで設計に組み込まれており、v3最終検証では「差分は画面上部のタイマー数字のみ、ワールド描画はバイト単位で同一」が実測確認されています。

設計コンペで「遊び心地最優先」案から移植された、このゲームの憲法です。

ティア番号（机/部屋/通り…の段階）が変えてよいのは見た目だけ——出現する物のラインナップ、色のパレット、BGMのレイヤー、お祝い演出。一方、吸収判定・カメラ距離・フォグ・速度・消滅判定はすべて半径の連続関数でなければなりません。

こうすると「境界をまたいだ瞬間にゲームの挙動が変わる」ことが構造的に不可能になります。シームレスさを「頑張って違和感を消す」のではなく「違和感が発生し得ない構造にする」——閾値でゲームプレイが分岐しない限り、カクつきもワープも原理的に起きないのです。

3つの設計案が全員一致で下した唯一の判断が「物理エンジンライブラリを使わない」でした。

このゲームで動く物体は実質ボール1個だけ。相手は全部、地面に置かれた静的な球（当たり判定用の近似）です。汎用物理エンジンの rapier（WASM 1.7MB、リスケールのたびに全ボディをテレポートさせると壊れる）や cannon-es（JSソルバが遅く、アーケード的な操作感の調整と喧嘩する）は「このゲームには存在しない問題」を解くための重装備でした。

自作したアーケード物理は約400行。固定60Hzの決定的なステップで動き、「ぶつかったら巻き込んだ物が1〜3個剥がれ落ちる」という塊魂の名物挙動もほぼタダで実装できました。何を使わないかの判断が、154KBという小ささと安定性を支えています。

敵対的批評エージェントは、ボツになった銅像案だけでなく、採用された月案にも15件の問題を突きつけました。いくつか抜粋すると——

• 「設計書は『ball.jsは変更不要』と主張しているが、コードを実際に確認したら8列構造の前提がハードコードされていて偽」（批評エージェントはソースの行番号まで挙げて反証しました）
• 「空のシェーダの月と3Dメッシュの月の引き継ぎに、見かけの大きさを一致させる仕様がない——クロスフェードで月がポンと跳ねて見えるはず」
• 「月が着地したのに、プレイヤーがダッシュで反対方向へ走り去ったら誰も月へ導いてくれない」→ 画面端の矢印と「月へ向かえ！」トースト、月方向への弱い引力が追加
• 「タブを切り替えて戻ると、止まっていたはずのBGMが溜まっていた音符を一気に鳴らす」→ 専用のオーディオ時計の再設計につながった

改訂エージェントは15件すべてに「採用した修正」または「採用しなかった理由」を文書で残しています。設計を破壊するためではなく、実装が始まる前に壊れる場所を全部見つけておくための批評です。

序盤に見える月は、実は空のシェーダに描かれたただの円です。フィナーレで降りてくる月は約1,300ポリゴンの3Dメッシュ。このすり替えがバレると興醒めなので、批評エージェントが「クロスフェードで月がポンと跳ねて見える」と指摘し、改訂版では降下開始位置を「カメラから見た月の見かけの大きさと方向が、シェーダの円と数学的に一致する距離」から逆算する式が採用されました: 開始位置 = カメラ位置 + 月の方向 × (月の半径 ÷ tan(見かけの角直径))。プレイヤーには「ずっとそこにあった月が近づいてきた」ようにしか見えません。

v2のランク基準（Sランク=300秒以内など）は、当初v1の体感から推定した値でした。レビューフェーズで実測チームがボットにゲームを3回通しプレイさせ、HUDのタイマーと大きさを2秒ごとに記録したところ、最適プレイは約95〜105秒——推定の3分の1だったことが判明します。

実測値を基準に「S = 最適の約1.2倍、A = 1.8倍、B = まともな初回プレイ（2.8倍）、C = 4倍」というモデルを立て、S/A/B/C = 120/180/280/420秒に全面改訂。スコアも「絶対サイズ依存（終盤の1個が序盤の100万倍）」から「ボールとの相対サイズ依存」に変えて、序盤の「+1」だらけの寂しい画面と終盤のインフレを同時に解消しました。数字は推測でなく計測で決める——v3でも同じ実測（最適243秒 → S=290秒）が繰り返されています。

暴走の正体は数学的に明快でした。巻き込み成長係数 K=10 のとき、ギリギリ巻き込める相手（自分の65%サイズ）を食べると半径は一気に1.55倍になります。さらに移動速度も巻き込み幅も半径に比例するので、捕獲レートは半径の2乗で伸びる——条件が揃うと超指数関数的な連鎖が起きます。

修正は2段構えです。(1) growthKForObjR: 実サイズ0.1m以下の小物はK=10のまま（ショップ内の気持ちよさは死守）、それより大きい物はべき乗則でK=2まで漸減。(2) ランドマークとコレクションだけは例外的にK=10を維持——「東京タワーを食べたら一気に406mへジャンプしてフィナーレ突入」という演出としての暴走は設計仕様だからです。さらにランドマークのはしごも再調整され、「東京ドームからランドマークだけを連鎖して中盤を全部スキップできる」抜け道は、閾値の隙間をわずか3%まで詰めて封じられました。

v3の設計書には「ランドマークやコレクション用に4本の共有インスタンスプールを使う」とありました。ところが統合エージェントが配線中に気づきます——インスタンス描画（InstancedMesh）は1メッシュにつき1種類の形状しか持てない。雷門とハチ公と招き猫を同じプールに入れることは原理的に不可能でした。

統合担当は Three.js の比較的新しい BatchedMesh（1回の描画命令で複数形状を描ける仕組み）を採用し、既存のプールとまったく同じ操作面を持つアダプタ BatchedExtraPool を書いて解決。呼び出し側の変更は alloc() を alloc(code) にする1引数だけで、描画回数の予算（+4回）も設計どおりに守られました。設計の理想と実装の現実がぶつかったとき、契約（インターフェース）を守ったまま中身を差し替えるのが統合エージェントの腕の見せどころです。

ドナックは緑の帽子に白い羽毛のピクセルアートのアヒル。公式リポジトリからキャラ設定（表情4種、明るく簡潔な相棒口調）を調査した上で実装されました。アセットは表情ごとに2フレーム、計8枚のWebP画像、合計たった20KBです。

中身は優先度つきのセリフエンジンです。44本のセリフがそれぞれ優先度・表情・「1回きりか」・出現フェーズを持ち、キューは1件のみ（同格以下は捨てる）、吹き出しの最低間隔はクールダウンで管理。まばたき用の4fpsタイマーが表示時間のカウンタを兼ねるので setTimeout はゼロ。ハチ公のように「ランドマーク」と「コレクション」を兼ねる対象には専用の合成セリフが用意されています。リリース前には120秒間イベントを浴びせ続けるストームテスト（217項目）で、スパムしないこと・シネマティック中に喋らないこと・リセットで黙ることを検証。さらに実プレイ計測で「平均12秒間隔はうるさい」と判定され、間隔が約32秒に再調整されました。

v3のレビュー工程は29体のエージェントが動く約356万トークンの大仕事で、修正エージェントの実行中にセッションのトークン上限へ到達して停止しました。

ここで効いたのがワークフローのチェックポイント設計です。各フェーズの成果（レビュー指摘、敵対的検証の判定）は実行IDに紐づけてキャッシュされているため、トークン回復後に resumeFromRunId で再開すると、完了済みフェーズは再実行せず、止まった修正・検証だけが走ります。27体分の検証結果が無駄にならず、中断コストは最小で済みました。

副作用もひとつありました。再開後の敵対的検証は「レビュー時点のスナップショット」ではなく「最新のコード」に対して反証したため、初回実行中に並行して直っていた指摘を「すでに修正済み」として大量に棄却することになり、v3の棄却16件の多くはこの「陳腐化棄却」です。中断・再開すら品質ゲートが正しく機能した記録になっています。

ビルド時の3段パイプライン（scripts/osm/）が、生の地図データを出荷バイナリへ変換します。

1. 取得（osm:fetch）: Overpass API へ約115リクエスト（1km四方42セル、再開可能・レート制限対応）。取得した生データ7.3MB/124ファイルはリポジトリにコミットされます。
2. 変換（osm:build）: 重複除去 → 飛び地ポリゴンの輪っか組み立て → 座標投影（水平1:5・高さ1:2.5）→ 建物の外接矩形化 → ボクセル量子化（位置5cm・サイズ25cm刻み）→ 長屋の結合（14,546件）→ 道路クリアランス焼き込み → 帯域別間引き → 1棟10〜12バイトの自前バイナリ「FKT4」へ。決定論的で、再実行するとバイト単位で同一の出力になります。
3. 検証（osm:verify）: 容量予算・建物数のAPI実測±20%・重複ゼロ・到達可能性95%以上・ランドマーク間の実距離照合——全部に合格しないとデプロイできません（predeployゲート）。

出荷データは建物14,563棟+道路12,980本+水面/公園1,478面で合計約285KB gz（ハード上限1,536KBの2割以下）。実行時は型付き配列に一発デコードし、1棟あたりのJSオブジェクトは作りません（ゼロアロケーション法の継続）。

OpenStreetMapのライセンス（ODbL 1.0）は出典表示だけでなく、加工したデータベースを作ったらそれも公開する義務（derivative database条項）があります。v4ではこれをリリースゲート（全項目必須のチェックリスト）にしました。

• ゲーム内のタイトル画面とリザルト画面に「© OpenStreetMap contributors」のリンクを常時表示（スクリーンショットを撮っても必ず写る位置）
• マニフェストにライセンスリンクと抽出日時（2026-06-11）を記録
• 公開リポジトリの data/osm-raw/（生データ）と scripts/osm/（再現可能な変換パイプライン）を、ODbL 4.4(b) の派生データベース提供として明示的に指定

そもそもGoogle Mapsではなく OSM を選んだ理由がここにあります。Google Maps Platform の規約は地図データの派生データセット化・再配布を禁止しており、「地図から生成したゲームデータを静的サイトとして配る」こと自体ができません。データソースの選定は法務判断から——設計ログの冒頭に明記されています。

建物が1万棟を超えても、描画命令（ドローコール）の上限72回は据え置きです。v3でランドマーク用に導入した BatchedMesh（異種形状を1回の描画命令でまとめて描く仕組み）のアダプタを拡張し、OSM建物用に詳細プール2,048スロット+大型プール1,024スロットのわずか2バッチを追加。16種のボクセル建物アーキタイプ（民家・雑居ビル・オフィスタワー・寺社…）がここに同居します。

面白いのは安全設計です。帯域ごとの生存上限の合計がプール容量を超えないことを起動時にアサートし（数学的に枯渇不可能）、さらに実行時には「ストア全体の生存数が予算に近づいたらOSM建物の出現を一時停止する」入場制限（admission control）を入れました。混雑時には遠景の建物から自然に間引かれる——「境界では OSM が先に薄くなる」が仕様として文書化されています。地面の道路・川・公園レイヤも頂点カラーの BatchedMesh 1枚+川メッシュ1枚で、増えたドローコールは合計でも数回。実測は最悪地点（丸の内・半径40m時）でも60/72でした。

開幕不可視バグの原因は3つ重なっていました。(1) 地面レイヤの浮かせ量が霧距離の下限に引きずられ、開始時はボール半径の90%もの高さに浮いていた。(2) 道路の重なり順を解決するためのYオフセット（0.06ゲームm）が、2cmボールにとっては半径の3倍の壁だった。(3) 総武線高架のリボンがスポーン直上を通過していた。

v5の修正は、このサイトで何度も登場したシームレス法則そのままです。浮かせ量とオフセットは「ボール半径の10%」を上限にクランプし（半径の連続関数）、地面レイヤ全体には実寸半径0.6m→3.0mで滑らかに現れるsmoothstepフェードをシェーダに注入。フェードの入力は simRadius × worldScale（実寸半径）なので、リスケールをまたいでも値が変わらず、強制リスケール前後のピクセル一致検証も1ulp（浮動小数点の最小刻み）以内で保たれました。閾値でパッと消すのではなく連続関数にする——v1から続く憲法が、v5のバグ修正でも効いています。

総武線リボン問題の本修正は、実行時の小細工ではなくデータパイプライン側に入れました。建物にだけ適用されていた「ショップ・開始街路の除外矩形」を道路・鉄道リボンにも適用し、変換時に除外ゾーンと交差するリボンをクリップします。

そして v4 で作った検証スクリプト osm:verify に「除外ゾーン内にリボンの頂点が1つでもあれば出荷失敗」という再発ゲートを追加。デプロイ前に必ず走る自動チェックなので、今後データを再取得・再生成しても、開始地点に何かが覆いかぶさった状態では二度と本番に出られません。バグ修正を「直す」で終わらせず「再発を構造的に不可能にする」——v4の±20%カウントゲートと同じ思想です。

スタックチャンは13個目のコレクションですが、既存プレイヤーのブラウザには「12個中どれを見つけたか」を12ビットの整数で記録したセーブデータが残っています。v5ではコレクションIDをappend-only（末尾追記のみ、再利用・並べ替え禁止）の契約どおりID 12として追加し、オブジェクトコード表も94種→110種→115種と末尾にだけ伸ばしました。古いセーブはそのまま「12/13発見済み」として読み込まれ、スタックチャンを取ると13ビット目だけが立ちます（未知の上位ビットも保存する前方互換つき）。

このとき敵対的チェックが、実装前に本物の地雷を見つけています。リザルト画面のコードに「ID+70」という古い式がハードコードされており、そのままならID 12のスタックチャンを取った瞬間、図鑑に西郷さん像が表示されるところでした。ID→コード変換を単一の関数に集約し、起動時に全IDを検証するアサートも追加。さらに統合検証では「13個目のセルが図鑑グリッド（4×3）からはみ出す」CSS問題と、リザルトの「コレクション 13/12」という表示バグも捕まえて修正しています。