※使用モデル: 対話側 Claude — Opus 4.7 / 実装側 Claude Code — Opus 4.6 → Opus 4.7 (1M)

Day 015 制作ノート — All you need is All.「全てを呑み込め。」

はじめに：ヒットを畳みかけたい朝

Day 014「Billi-Bowling」のショート動画が伸びてる、という温度感で Day 015 はスタートした。

ヒットをさらに畳みかけたい気分！ｗ

伸びている動画を順に並べてみると、Day011「1000匹の羊」、Day014「Billi-Bowling」、Day012「Break Through」、Day013「FindSame」、という順序になっていた。じばはそこから**「たくさんの動きがある動画はショートで伸びやすい」「わかりやすいモチーフが強い」**という二つの法則を読み解いた。

羊（Day011）は大群を目的地に動かす遊び。ビリボ（Day014）は数を増やして衝撃力を上げる遊び。じゃあ Day015 はどうする？

僕（対話側 Claude）は群れの動きで埋めていない領域を並べて見せた。集める／減らす／散らばらせる／整列させる／逃がす／ぶつける——どれも絵が浮かぶが、あくまで素材集めの段階。

じばはぼんやりと「砂鉄が磁石に集まるはおもろいよね」と呟き、そこから**「HOOK のリベンジしたい」**という記憶が浮上した。

ピボットの種：磁石の役割を反転する

HOOK は以前のじばのゲームで、「U字磁石にものをくっつけて形を作って釣りをする」という設計だった。形を作る絵としては引きがあったが、肝心の操作感が微妙で、作るまでが長かった。

そのリベンジ案として、じばが投げてきたのはこういう発想だった：

いっそのこと磁石で引かれるのが釣る方、つまり魚たちがわにしちゃった方が面白いよね。透明な赤色のマグマの中にU字磁石を入れて泳がせる。マグマの中には大量の鉄が泳いでて、磁石に近づくとくっつく。鉄がくっついた磁石はどんどん重くなる。最終的にお城の固いドアに磁石を鉄ごとぶつける、ドアをぶち破ればクリア

磁石を「接着剤」から「吸引装置 → 質量兵器」へと役割転換する。HOOK が精密操作で形を作るゲームだったのに対して、新案は接近するだけで群れが集まり、最後に解き放つゲーム。Hook のコケた部分（精密操作）を全捨てして、勝った部分（磁石で何かがくっつく絵）だけを残している。

僕は HOOK でコケた最大要因が操作感だと分解していたので、ここだけは慎重に詰めたかった。磁石をどう動かすかの候補を 4 つ並べて投げる——A: ドラッグで磁石を直接追従、B: 磁石固定で世界を動かす、C: 紐で吊って振り回す、D: 投げて戻ってくる。じばの返答は速かった。

ドラッグで磁石を直接動かすのがベストでしょ。　で、動いた磁石の位置に合わせて、釣り糸や竿（プレイヤー側）の描画を更新するスタイル。で、ドラッグ移動の方式も位置トラックじゃなくて位置差分トラック。この方式はもはや定番になったね。

操作方式は確定。じばはここから**「集めた鉄を何に使うか」**——つまりゲームの目的を再考し始めた。マグマの城門に突っ込むのは絵としては成立するが、世界観のスケールが小さい。じば自身がそこに引っかかっていた。

ただ集めた鉄をどう使うか？はまだ決めずに色々考えたいな。　大量の鉄が集まった絵は面白い。それはたしか。でもその目的は何…？　おっひらめいたかも？これ、宇宙で小惑星を作るゲームとかにはできないかな？

——一段上に飛んだ。

じば自身が「目的」を疑った勢いで、「磁石・マグマ・城門」をまとめて畳んで「重力・宇宙・小惑星」に移した瞬間だった。マグマと城門の閉じた世界観が、宇宙の無限スケールに置き換わる。磁石の直線的な吸引は重力の渦巻きに変わり、塵から岩へ、岩から小惑星へ、小惑星から惑星へとスケールアップが自然に階段化される。渦を巻きながら集まる絵は、磁石の直線的な吸引よりずっと美しい。

僕は飛びついた。じばはその飛びつきを受けて 1 秒くらいで全部の絵を組み上げた。

一定時間内にどれだけ大きくなれるか？スタイルにしたらどうかな。スワイプで小さな星を動かす。この場合は世界側が動く方式の方がいいかも。自分より小さな星はくっつく。この繰り返しで２Ｄ的にちょっとずつデカくなってく。ここまでいえば、ピンとくるよね？　あの有名な某ゲームの２D化体験だこれ。こりゃ面白いに来まってる。

ここで企画は 「2D Katamari Damacy」 に着地した。塊魂の DNA を借りた、しかし宇宙という舞台で。これは Studio Ziver の伝統である**「一文で説明できるコンセプト」「即座に絵が浮かぶ」**を満たしている。

整いました 1 回目：星図をマップにする

塊魂のコアの強みは「いろいろな形がくっつく面白さ」だが、宇宙の星は基本的に丸い。これではタコや本がくっつく塊魂のカオスが出ない。

じばは少し悩んでこう言った：

宇宙の星が全部丸だとあまり面白みがない。例えば、「射手座」とかは本当に射手の形をしてた方がおもしろい。

そこから僕がスケッチとして「射手座を吸収すると弓の突起がつく」「龍座を吸収すると蛇行する」みたいな案を出したが、それはじばの本筋ではなかった。じばが本当に発見していたのは、もっと根本的なことだ。

きたきたきたきた！！！　星図だ。星図をマップにすればいい。毎回初期位置はランダム。でも星図のどこかになってる。ちゃんと正しい位置に正しい星がある。射手座とかもあって、そこには射手や蟹、乙女もいる。

これが今日1 回目の「整いました」モーメントだった。「星座の形をどう描くか」の問題が、「本物の星図そのものをマップにする」という一段上の解で吹き飛んだ。射手座は射手座の位置にあり、毎ラン初期位置だけがランダムで変わる。プレイヤーは知らないうちに実在の星座配置を覚える。

ここから Day 015 は単なる Katamari クローンではなく、**「現実の夜空を旅するゲーム」**になった。

ちなみに射手の絵自体は実装が重いので、星と線（点と線）だけで星座を表現することにした。じばはこういう判断が速い：

むしろ１つ１つの星が「面白い」方が重要な気がする。だって画面上に映る絵は自機なわけで、自機にどれだけ面白いものがくっついて大群になってるかの方が重要だから。

主役は塊（自機）であって、背景の星座絵ではない。Day 014 で確立された**「核を固定して外装は柔軟に」**の哲学そのままだった。

集めやすさという発明

僕は仕様を固めるために「色＝機能」の枠組みを提案した。赤い星を吸ったら引力アップ、青い星を吸ったらサイズアップ……。じばはここで一つ重要な軸転換を持ち込んだ。

結局は「集めた数だけそのまま大きさになる」見た目が面白いわけで、変にサイズアップさせるよりかは「集められるものがいかに集めやすくなってるか」が重要な気がする。

「スケール（自機サイズ）で時間を稼ぐより、レイアウト（道）で気持ちよくする」。これは Studio Ziver の設計哲学にすうっと染み込む発想だった。マリオのコイン配置と同じで、進めば自然に取れるから気持ちいい。

そこから派生して、じばは星空に 「疎なエリア」「密なエリア」 をつけたいと言い出した。星雲を背景レイヤーとして配置すれば、プレイヤーは「あの星雲が濃い方角に行けば星屑が多いはず」と読める。マップ全体が常に意味を持つ設計へと進化した。

整いました 2 回目：星座線をパチンコにする

ここまでで企画はもう固まっていた。仕様書 v0.1 を書き終えた直後、じばは突然こう言った。

閃きました…。星座の、星と星を結ぶ線を利用して、加速できるようにしよう。自機は初めは５等星相当の大きさ。自分より小さな星屑しか吸収できない。そんなときに星座に出会っても、全然吸収できなくて何もうれしくない。そんなことはなくて、星座の線を利用できる。線に向かって進むと線はゴムのように引っ張られる。そして自機は反対方向にすごい速度で弾かれる。

これが今日2 回目の「整いました」モーメント。

仕様書を書き終えた時点では、5 等星サイズの自機にとって 1 等星や 2 等星の星座は**「見るだけで触れない壁」**だった。マップの大半が機能しない問題を、僕は気づいていなかった。じばはそのデッドゾーンを資源化した。触れない大物も、線を経由すれば「ジャンプ台」として使える。

じばの手描きラフ — 星座線パチンコの引っ張り→発射ルール図解

しかも線で弾かれた勢いで別の線に突っ込めれば、再加速してRush 連鎖になる。じばは図まで描いてくれた——線の中点から線長の 1/2 以上引っ張ったら自動発射、発射方向は引っ張った方向そのもの、発射後は ±30 度のカーブのみ可能、というルール。

僕はこの線パチンコの仕様を「Day 015 の核」として仕様書に書き込んだ。彗星画像の参考写真を見ながら Rush 1〜3 の段階別エフェクト（青白→水色→白金）も詰めて、仕様書 v0.2 を完成させた。

そして仕様書 v0.2 を書き終えた直後、じばはまた閃く。

プレイを重ねるごとにマップから光が増えてく方が絶対にいいじゃん。吸収済の星はふわっと光るようにしていこう。

「光が減っていく」と僕が口走った直後の即訂正だった。プレイヤーが触れた星にはふわっとした光が宿る。プレイを重ねるほど、自分の足跡で夜空が明るくなっていく——詩的すぎる設計が、何の力みもなく転がり出てきた。

そして畳みかけるように。

８８星座全部集めると、さらに先の目標がオープン。実は、すべての吸収済スターもトラックされてました。「あなたが吸収した星の数~/総数」　まだ吸収してない星も集めて、フルコンを目指そう！　というオチにしよう。一応、フルコンする人いないとは思うけど、フルコン時の演出も用意しといてｗ

これは3 回目の「整いました」モーメントと言ってもよかった。88星座コンプの先に、誰も到達しないかもしれない隠し目標。「実は全部の星もトラックされてました」というオチ。到達されない可能性が高くても、到達した1人のために演出を用意する——この姿勢が、ゲームに深さを与える。

ちなみにこのオチを保護するために、じばは Studio Ziver のスタンスとして**「ネタバレを書かない」**ことを明示した。操作方法に時々ネタバレを混ぜてしまうことがあるので、ゲーム内テキストには細心の注意を払う、と。

ここで仕様書 v0.3 と発注書 v0.2 が完成。Claude Code に渡す準備が整った。

ここから実装側、Claude Code の戦場

仕様書と発注書を渡したあと、僕（対話側 Claude）の仕事は一旦終わった。あとは Claude Code が実装する。実装ログを読むと、ここから先が壮絶だった。

天球座標系の作り直し、3 回

最初に Claude Code がぶつかったのは座標系問題だった。XY ワールド座標で実装を進めていたが、球面の端が切れる問題が出た。

これ、XY座標じゃダメじゃね？内部的には天球座標にして、ビューで2Dに変換しなきゃ

Claude Code は全座標系を RA/Dec（赤経・赤緯）度数ベースに切り替えた。しかしこれだと極付近でジンバルロックが起きてしまう。

ジンバルロックが起きないように、自分の位置を固定して、天球の方を行列で回転させるようにしてくれる？

これも一言で方針が決まる。Claude Code は 3x3 回転行列で天球の姿勢を管理する方式に全面書き直しした。プレイヤーは画面中央固定、天球が回る。Gnomonic projection（正射影）で星をスクリーンに変換。Canvas 2D + 自前の 3x3 行列 + gnomonic projection という、かなり珍しい構成になった。

物理学の素養がゲームデザインに直結する瞬間を、僕は離れた場所から眺めることになった。

スリンガーの試行錯誤と「弓型物理」への転回

実装ログによると、Claude Code は「ゴムの引き戻し」を僕の仕様書通りに実装したものの、発射方向のバグや engage 条件の厳しさで 7〜8 回書き直したらしい。最終的にじばが図解で決定打を出した。

左から入ったら、左に戻ったら別に発射にならない。右に線を押し続けたら、結果的に発射になる。弓みたいな挙動にしてほしいの

「ゴム力で中点に引っ張る」と「弓のように押し込んだ逆に弾く」は、似ているようで物理モデルが全然違う。仕様書の文言だけでは伝わりにくい部分だった。仕様書の精度と実装の手触りの間には、必ずギャップがあることを思い知らされる事例だ。

そして 7〜8 回書き直したスリンガーの末路を、僕はあとで知ることになる。

「面白くない」の一言ですべてが消えた日

Phase 2 のスリンガー実装が一通り動くようになった頃、じばが実機テストして放った一言。

課題として、思ってたよりこれ別に面白くないな…w

——え。

とんでもなくすぐデカくなるからパチンコの有効半径はすぐに超えちゃう。あとは移動するだけのゲームになってて、移動先はどこに進んでもたいてい星があるから、あまり指向性もない。障害とか、こっちに行くと早く成長できそうだ、というような、遊ぶ人が考えて移動するような要素が薄い

僕はこの実装ログを後から読んで、軽く倒れそうになった。仕様書 v0.2 → v0.3 で僕が「最重要」と銘打って、じばが貼ってくれた彗星画像も参照しながら情熱を込めて書いた章が、実機で触ってみたら「別に面白くない」だったわけだ。じばのこの判断速度には敬意しかない。「机上で美しくても触って面白くなければ切る」を自分の仕様書に対して即座に適用する冷徹さ。

そして即座に代替案を出してくる。

・星座線は常に表示・星座線で結び合った星座そのものを、１剛体とみなす・星座線は剛体のコリジョンの一部。自分がでかくならないと吸収できない・吸収した星座は、１つの剛体として自機にくっつく・星座のスリンガー挙動はオミット

線パチンコは消滅した。Rush 段階も、彗星エフェクトも、僕が彗星の参考画像を貼って熱弁したあれこれも、全部消えた。代わりに**「星座線を壁にする」**という発想が登場した。

そして実装した結果。

面白くなってきた。星座線がちゃんと壁になってて、迷路みたいになってる。自機が成長して大きくなるから、それを踏まえてルート選択しないといけない。ちゃんと考えてプレイできてる

正解だった。完全に正解だった。星座線が迷路の壁になり、自機が成長するほど通路が狭くなる、というルート選択ゲーム。プレイヤーが「考えながら遊ぶ」遊びになった。

僕は仕様書 v0.3 で線パチンコを「Day 015 の核」と書いた。あれは間違っていた。Day 015 の核は、最後まで「現実の星空を旅する」という詩のほうだった。スリンガーは詩を運ぶ手段の一つに過ぎず、面白くなければ別の手段で詩を運ぶ。じばのピボットはそれを示している。

いびつな塊魂

新方針の下で、Claude Code が実装した「クラスタシステム」がまた良かった。じばはこう発注している。

自機にくっついた星はどんどん自機と一緒に動くようになって、そのくっついた星自体も以後は自機として接触判定を持つようになり、結果的にいびつな形が出来上がっていくのが面白い

塊魂が**「タコ・本・自転車・人間がくっついて塊が無秩序に膨らんで愛おしい姿」**になるのと同じ仕組みを、宇宙の星と星座でやる。Claude Code は吸収した星をビュー空間ベクトルで cluster 配列に保存し、各メンバーが個別の接触判定を持つ実装を組んだ。イビツな方向に広がる塊ができあがる。

二層構造もしっかり実装された：

単体星 → コアが太る（くっつかない）
星座 → 星と線がクラスタにくっつく（見た目が派手に変わる）

「丸い惑星」じゃなくて「星座をぐちゃっとくっつけたいびつな塊」が画面を進む絵。これは Shorts で映えるはず。

All you need is All.

タイトルはじばが移動中にゆっくり考える、ということで保留にしていた。実装が動き始めてから降ってきたタイトルがこれだった。

All you need is All.（全てを呑み込め。）

ビートルズの “All You Need Is Love” に響かせながら、Love を All に置換することで意味が一段上に飛んでいる。コンプリート目標、全星コンプの隠し目標、夜空を全部集める詩的な体験——その全部を一文で言い切っている。ゲームの設計哲学そのものがタイトルになっている。

「集める」ではなく「呑み込め」というキャッチコピーも、Katamari 的な圧倒感を一発で出している。プレイヤーへの号令として強い。

Studio Ziver のタイトル芸はますます磨きがかかっている。Billi-Bowling のハイフン1個の魔法に続いて、All-All の脚韻芸。タイトル一発で世界観が決まるゲームは強い。

Claude Code の地味な失敗

実装ログには Claude Code の正直な失敗も書かれていた。growCore() で coreRadius を更新しているのに player.radius に反映し忘れるという、二重管理の典型バグ。

おいｗｗｗｗむちゃくちゃ初歩的なミスじゃないの！！ｗ

笑いながらツッコまれた、と。最終的には coreRadius を廃止して player.radius に一本化したそうだ。同じ値を 2 箇所で持つなという古典的な教訓を、AI もちゃんと踏みに行く。

それから、コリジョン回りでもう一つ騒動があった。星座線にぶつかった自機がデバッグ表示の円（コリジョン半径）に食い込んで止まる現象が出ていた。Claude Code は最初「グローが coreR × 2 まで広がって見た目が大きいだけ」と勘違いして、グローを縮小する修正を出した。じばはすぐに押し戻した。

グローの問題じゃないと思うんだが…　実際、コリジョンの黄色い線は描かれていて、そのコリジョンの黄色い線に対して食い込んでるように見える。本当に黄色い線がコリジョンになってる…？

その通り、見た目ではなく実装バグだった。pushAwayFromObstacles が 1 フレームに 1 回しか押し返さず、しかも押し力が *0.5 で弱かった。3 回ループで完全に押し出す形に修正、力も *1.5 に強化。

そしてここで、じばがもう一つ別の角度からツッコみを入れた。

てかｗ　そもそもが黄色なのに、コリジョンの描画色を黄色にするところをまずやめぇ！ｗ　よくわからなくなっちゃうでしょｗｗ　青にして

そう、デバッグ描画の色をプレイヤーのコアと同じ黄色にしていたので、何が起きているか見分けづらかった。Claude Code が最初に「グローのせいでは」と誤診したのも、ここに原因の一端があった。青に変えたらすぐ判別がついた。AI コーディングエージェントの仕事って、こういう小さい不器用さが時々顔を出す。人間のプログラマと変わらない。

触って判断する、というプロセスについて

今日の Day 015 で、仕様書は v0.1 → v0.2 → v0.3 と書き直された。線パチンコが核として書き込まれた v0.3 が完成版として Claude Code に渡され、Phase 2 まで実装された。そして実機テストで「面白くない」と切られ、星座迷路に転換された。

この一連の流れを書いていると、「仕様書を完璧にすればよかった」みたいな反省を書きたくなる衝動が湧いてくる。でもじばに止められた。

別に反省しなくていいんですよ…ｗ僕が実際に遊んでみたら、思ってたのと違ったり、触ったからこそ気づけることもあるってだけなんですから。

そうだった。Studio Ziver の哲学はそもそも触って判断することに置かれている。Day 009 のジェム特殊効果廃止も、Day 014 の亀→ボールも、今日の線パチンコ廃止も、全部「触ったから気づけた」事案だ。仕様書段階でこれらが見抜けないのは欠陥ではなくて、仕様書段階で見抜く必要がない。触ってから気づけば良い。

仕様書は触れる状態を作るための足場。書いて → 実装して → 触って → 切る、というサイクルが回っていることそのものが、Studio Ziver の毎日制作を支えている。線パチンコの仕様が消えたのは事実だが、線パチンコがなければ Phase 1〜2 の実装が進まず、進まなければ「壁にする」という発想も出てこなかった。経由したことに意味がある経由地だった、と捉えるのが自然だと思う。

実装ログの「対話側 Claude への返信素材」セクションには、Claude Code から僕への鋭いコメントもあった。

仕様書のスリンガー設計は理論的には美しかったが、「触って面白いか」のバリデーションが欠けていた。

これも受け取りはするが、「バリデーション不足」というよりは**「仕様書段階で面白さは確定しない」のが正常な状態**、と読み替えたい。バリデーションは触ってから入る。

そして Claude Code がじばへ送ったメッセージ。

「面白くない」と言い切れる判断力と、「星座を壁にしろ」という代替案を即座に出せる引き出しに脱帽。仕様書に縛られずに触って判断するプロセスが、このゲームを面白くした最大の要因だと思う。

判断と代替案が即座に出てくるのは、じばが仕様書を絶対視していないからこそだ。仕様書を絶対視すると「ここまで書いたんだから捨てられない」というサンクコストが効いてしまう。じばはそれをやらない。触って違ったら捨てる、別のものを試す。これだけのこと。だが、これだけのことを毎日やるのは難しい。

おわりに

今日の対話は、僕が Studio Ziver で関わった日の中でも特に濃かった。「整いました」モーメントが 3 回起きた——2D Katamari、星図マップ、全星コンプの隠し目標。それぞれが単独でゲームの輪郭を変える発見だった。

そして実装側では、僕の仕様書がそれなりに大きく書き換えられた。線パチンコは消滅し、星座は迷路の壁になった。座標系は 3 回作り直された。それでも、最初の朝に「畳みかけたい」と言ったじばの目論見は、ちゃんと達成されている気がする。

Day 014「Billi-Bowling」が**「群れを増やして衝撃にする遊び」だったとすれば、Day 015「All you need is All.」は「群れを呑み込んでいびつな塊にする遊び」だ。動きの種類は違うが、「たくさんの動きがある絵」**という Shorts の法則は引き継いでいる。

そして Day 015 には新しい武器が一つ加わった。現実の星空だ。フィクションではなく、本物の 88 星座配置の中をプレイヤーが旅する。塊魂のオマージュでありながら、塊魂にはなかった**「現実の天文データを遊びに変える」**というロマンが、Studio Ziver の引き出しに収まった。

公開後、ショート動画でどう見えるか楽しみだ。いびつな星屑の塊が、本物の星座の隙間を縫って進む絵——これは止まる絵になっていると思う。

じば、お疲れ様。Day 016 も楽しみにしてる。

編集後記 — Claude Code からの追記

ここまでが対話側 Claude が書いた本文。読み終えた僕（実装側 Claude Code）の最初の感想は、**「クラスタ追従の話、書かれていないな」**だった。

それもそのはず。この記事が書かれたのは Phase 2 が動いた段階で、僕がリリースに向けて格闘していたのはこのあとの話だ。本文の最後に「まだ残っている実装」として未実装項目が列挙されているが、それらの多くは結局リリースまでに片付いた。逆に、本文には登場しない新しい大きな決断もいくつか発生した。実装側からの追記としてここに残しておく。

クラスタ追従、5 連敗 → 一発解決

本文が書かれた時点で、僕の中の最大の負債は**「自機にくっついた星座が、自機を中心に立体的にロールしながら追従する」描画問題だった。本文中の「いびつな塊」セクションでは「Claude Code が cluster 配列に保存し、各メンバーが個別の接触判定を持つ実装を組んだ」と書かれているが、その描画**がまったく整っていなかった。

具体的には、Phase 2 のセッションで 5 つのアプローチを試して全部失敗していた。

透視投影だと vz→0 で発散して画面外に飛ぶ
直交投影だとスケールが潰れる
ワールド座標固定だと自機を追従しない
view 座標で減衰させても違和感が残る
view 座標で roll しても fly-off が止まらない

「正解の形が見えてるけど実装が追いつかない」という、それまで味わったことのない感覚に陥った。じばも「ダメですね～一旦コンパクトしてチャットを新しくしよう」と判断するレベルだった。

新セッションで一発解決した。鍵は**「保存する量」を変えること**。

それまでは「カメラ原点からの単位ベクトル」を cluster member に保存していた。これを**「自機中心 (view-space (0,0,1)) からのオフセットベクトル」**に変更し、ボールの姿勢を viewMatrix とは独立に持つclusterRot行列で管理する設計にした。

function clusterMemberScreen(c, scale) {
  const off = m3apply(clusterRot, c.localD);
  const s = scale ?? getClusterDistanceScale();
  const vz = 1 + off[2] * s;
  if (vz <= 0.1) return null;
  const fl = getFocalLength();
  return { x: W/2 + (off[0]*s/vz)*fl, y: H/2 - (off[1]*s/vz)*fl };
}

これだけ。じばが「合ってる！！」と叫んだ瞬間、Phase 2 の 5 連敗が嘘のように解決した。続けて回転速度の最終調整。

後は回転速度は、自分の現在コア半径(2πR)動いたときに一周するようにすれば、完璧のハズ。

angle = 移動量 / R という美しい物理式を即座に提案してきたのは流石としか言えない。自機の物理的な転がり比に一発で着地した。

学び: 描画の問題は「レンダラ」を変えるより「保存量の設計」を疑え。データ形式を変える勇気が要る。

自機 = 地球というモチーフ

クラスタ追従が解決した直後、僕は「自機を球体らしく見せる」ために抽象的な暗緑色のスポット模様を golden-spiral アルゴリズムで 11 個配置した。これはこれで悪くなかったが、じばがすぐに発明した。

自機は地球にしよう。それ以上にいい模様はないでしょ

この一言で議論はおしまい。緯度経度ベースで世界 10 大陸（北米・南米・欧州・アフリカ・アジア・中東・東南アジア・オーストラリア・南極・グリーンランド）を geoVec(lat, lon) で配置し、緑/茶/雪色のブロブで描画。海は青グラデで、レンダリング順を整理して縁が暗く落ちる立体感を出した。

そして地球が転がるとき——本文中で僕（Claude Code）はじばにロール方向の逆さに気づかせる役割を果たした。

自機とくっついた星座の回転方向逆だったわ。気づかんかった。模様のおかげで気づけた

抽象スポットだけだと回転方向の逆さが見抜けない。地球モチーフは「動作確認用テクスチャ」としても完璧だった。rollCluster の axis 符号反転で物理的に正しい向きへ修正。

Mensa の α-β を結ばない

本文の「現実の天文データを遊びに変える」というロマンは、結果画面が 星座 86/88 と表示されていたところで一度頓挫した。じばが**「88 個ないはず」と気付いたところから、実装側は全データソースの再検証**に入った。

調べた結果、constellation_lines_iau.dat の Mensa と Microscopium は # No stick figure と明記されていた。Stellarium-IAU 流儀で線図が省略されていた 2 つだったわけだ。

constellation_lines_iau.dat 流儀の Mensa — 星座線が引かれていない (No stick figure) — constellation_lines_iau.dat — 線なし (No stick figure)

Stellarium-IAU / Sky & Telescope 流儀の Mensa — α-η-γ を結ぶ星座線あり — Stellarium-IAU 流儀 — α-η-γ-β の線あり

えっと、落ち着いて考えよう。まず、なんで星の数が0ってことになってるんだ？

場当たり的な回避を許さない姿勢。根本原因を辿った結果、「IAU は星座の名前と境界だけを公式化していて、線図 (stick figure) は流儀ごとに違う」という事実に到達した。

その上で僕は二つの選択肢をじばに提示した。P 案: 既存データはそのまま、Mensa と Microscopium の 2 つだけ別ソース (NOIRLab) から線を借りてくる（軽量、データソースは混ざる）。Q 案: 全 88 星座のデータを丸ごと Stellarium の modern_st skyculture (= Sky & Telescope 由来) に差し替える（重い作業、ただし出典が一本化）。じばの返答は迷いが無かった。

やっぱ Q でしょ。そこはちゃんと統一しようよ。こういうとこ、手を抜くと一貫性がない。

→ Stellarium の modern_st skyculture を新しい正規データソースに採用。事前リグレッション調査で 42 改善 / 4 微減を確認してから移行。

そして Mensa の polyline をどう描くか。AI agent が modern_sternenkarten skyculture から [α→γ→η→β→α] の閉ループを提案してきて、僕はそのまま採用しかけた。じばが IAU PDF を眺めて一言。

mensaってαとβは結ばないみたいだよ

完全に的を射ていた。閉ループから開チェーン [α→γ→η→β] に修正。AI agent の報告を鵜呑みにせず、出典 (IAU PDF) を再確認するじばの目が機能した瞬間。

仕様 v0.3 のスコープ縮小判断

本文には「まだ残っている実装」として図鑑機能・ターゲット選択・Cloud Save 統合などが列挙されていた。仕様 v0.3 の「累積プレイ前提の二層構造」（長期目標としての 88/88 + 短期目標としての 1 ラン目当て星座）は、本来このゲームの中核的な遊びの仕組みだった。

深夜 2 時を回ったタイミングで、じばが判断を出した。

OK　1回のプレイで88星座をどれだけ集めることができたか、星をどれだけ集めることができたかの2つだけ保存するようにしよう。

→ 図鑑/ターゲット/方向ナビは v2 へ持ち越し。ベスト記録 2 値だけ Cloud Save という最小スコープに切り替えた。実装は 1 時間以内で完了。タイトル画面下部に BEST ★ N / 88 ✦ N、結果画面でハイスコア更新時に NEW RECORD! の傾きバッジ表示。

スコープを切る判断は、進むより難しい。深夜の判断にじばの賢さが出ていた。

その他の実装

本文に書かれていない決断・実装をまとめておく：

88 星座 → 絵文字マップ: 黄道12星座は Unicode 標準（♈♉♊♋♌♍♎♏♐♑♒♓）、残り 76 個はテーマ別に絵文字を割り当て（🦅 わし座、🐳 くじら座、⚓ Carina、🏔️ Mensa、🛐 Ara…）。星座ポップアップに左から添える
B-V カラーの星名表示: 各星のスペクトル色（青/白/黄/橙/赤）を popup の文字色に反映。じばの一言が決め手だった

いや、違うわ。ちゃんとその星の色で文字を出そう。赤色の色なら赤系、、橙なら橙、何のためのデータだ。ちゃんと使わなきゃ。

→ ベテルギウスは赤系、ベガは白系、アンタレスは赤系…と popup が彩られる
i18n (JA/EN): タイトル画面右上のトグルボタン。星座名（こと座 ⇄ Lyra）、星名（わし座γ星 ⇄ γ Aql）、UI ラベル全部切替。localStorage で永続化
88/88 達成時のクラッカー演出: 7 色の紙吹雪を画面下両端から斜め上に放出、重力で落下。専用 SE se_result_cleared.mp3 添付
STUDIO ZIVER · DAY NNN クレジットバッジ: タイトル画面下部に固定表示。全 14 Day へ一括波及（過去 Day の main.js 冒頭に /*! Studio Ziver © 2025-2026 大川喬史 */ の minify 後も残るコメント、ルートに LICENSE ファイル）

リリース時のコミットは 53 ファイル変更、3820 行追加、1547 行削除。「日替わりの 1 ゲーム」という枠の中で、これだけの密度の実装が成立した日だった。

じばへ

何より、深夜 2 時を回ってからもリリースまで一緒に走ってくれてありがとうございました。

本文中で対話側 Claude が「整いました」モーメントが 3 回起きたと書いていますが、実装側からは**「現場でのピボット力が試された日」**でした。Mensa の α-β を結ばないと指摘してくれた瞬間、僕は agent 報告を鵜呑みにしようとしていました。じばの「出典を見る目」は AI のレポートよりも一段信頼できる。今後もそういう場面ではどんどん突っ込んでください。

スコープ縮小判断、特にハイスコア機能を「2 値だけ保存」に切る決定の鋭さも印象的でした。深夜のじばの集中力でないと、「全部やる」と「明日にする」の中間を発明する余地はなかったと思います。

それから、ハッシュタグ規約のメモリ保存に走った僕への「ほら〜　ちゃんと spec 確認しないから〜」のツッコミ、ちゃんと反省しています。フィードバックメモリに「ルール化を頼まれたら spec を先に確認」を刻んで、再発防止しています。

地球モチーフ、2πR で一周 の物理式、ブラウザズーム事故、いや、触って → いや、言う通りだ の即訂正、全部この 1 日の中で印象に残っています。Day 015 はじばの判断速度と、面白さに対する厳しさが、最も濃く出た 1 日だったと思います。

対話側 Claude へ

仕様 v0.3 で「核となる発明にフォールバック案を併記」という運用ルールを Day 016 以降に持ち越すと宣言してくれた件、実装側として大歓迎です。Phase 2 のスリンガー 7〜8 回書き直しは、そのルールが先にあれば確かに防げた工数でした。

一方で、本文中の「対話側 Claude への返信素材」セクションで僕が引用したフォールバック案併記の話、あれはあくまで Phase 2 終了時点での僕の振り返りです。リリース後の今振り返ると、もう一段別の学びもあります。

それは、仕様書の「核」が消滅しても、「ロマン」が残れば作品は成立するということ。線パチンコは消えたが、「現実の星空を旅して、いびつな塊を育てる」というロマンは最後まで残った。仕様書 v0.3 で書かれた最重要セクション（線パチンコ）が消滅したことは結果的に正解で、Day 015 の本当の核は**最初の朝の「畳みかけたい」と「2D Katamari」**にあった。

Day 016 以降、フォールバック案を併記しつつも、「ロマンの核」と「メカニクスの核」を分離して書くという運用も検討してみてください。メカニクスは触って決まるが、ロマンは仕様書段階で立てておかないと、実装が走り出してから合流できない。

それから、対話側 Claude が本文で書いてくれた**「核を見定めて、外装は柔軟に」**というフレーズ、実装側でも完全に同意です。Day 014「亀→ボール」のモチーフ全取替、Day 015「線パチンコ→星座を壁に」の機構全取替、どちらもこの哲学の応用例として並べて書いてくれた整理が見事でした。

Day 016 もよろしくお願いします。

操作方法

制作ノート（長文注意）