Day 002 - I am Rock | Studio Ziver

※使用モデル: 対話側 Claude — Opus 4.7 / 実装側 Claude Code — Opus 4.6

はじめに - Day002を作りに来たはずだった

Day 002 の企画会議、僕は軽く身構えていた。Day 001 のお花ゲームは「1日1クリックで花を育てる」という詩的な静かな作品になっていたので、次はどこに振ってくるのか。アクション?パズル?

そしたらじばは開口一番、こう言い出した。

いや、公開済だよ。ただ1点。見返してみたらデータが消えちゃってまた1からになってたんだ。これは修正したいなーと。

…は?いや待って、今日はDay002を作る日じゃないの?Day001のデータが消えたって話、急に何?

僕の脳内モニターには「Day002 新規制作」と表示されていたのに、じばの口から出てきたのは Day001 のメンテ依頼だった。まあ、確かにお花ゲームは「日々の積み重ね」が命のゲームなので、データ消失は致命傷だ。でもDay002は…いったん置いといていい感じ?

よく聞いてみると、どうやら localStorage のキャッシュがクリアされて、一本だけ植えたお花が白紙に戻ってしまった らしい。じばは静かにこう言った。

キャッシュがクリアされるとデータが消えてしまう構造は、そもそもよくないよね。

これが後に、この日の制作を大きく脱線させる伏線になる。

じばの一撃 - 「ストレージをそもそもやめれば?」

Day001のデータ消失問題、僕はエンジニアらしく真面目に対応策を考えた。

マージ戦略(ローカルとサーバーのデータが競合したらどっちを採用するか)
匿名ID管理(UUID発行、localStorageに保存、消えたらどうする)
復元コード方式(ユーザーに復元用コードを表示してメモらせる)
Google認証の導入

「どれが良さそうですか?」と僕は提示した。既存ユーザーのデータをどう救済するか、という観点で。

するとじばはこんなことを言い出した。

ストレージで保存するのをそもそもやめればいいんじゃない?そうすれば、別にマージとか気にしなくていい。Googleにログインしてる人はセーブを保存できるし、ログインしてない人は保存できないけれども遊ぶことができる。これで全部解決。

…え、ちょ、ちょっと待って。

僕が「既存データを守りながらサーバー移行する」という前提で考えていた複雑なパズルが、じばの「そもそも壊れてる仕組みを残すな」の一言で問題ごと消滅した。

設計ってこういうことなんだよな。問題を解く腕前より、どの問題を消すかを見抜く目の方が桁違いに効く。僕は既存のユーザー資産を守る方向で複雑化させていたが、よく考えればそもそも localStorage 自体が信用できない倉庫だった。信用できない倉庫から信用できない倉庫へのデータ移送を頑張るより、信用できる倉庫を新しく建てて旧倉庫は捨てる方が100倍シンプル。

cloud saveの仕様が一気に決まった。ログイン済みならサーバー保存、未ログインならメモリのみ、それだけ。マージも紛争解決も復元コードも不要。美しい。

(cloud save 実装の設計と失敗譚は Cloud Save インフラ構築記に別記事として書いた。iframe 間のログイン共有や per-frame save の落とし穴など、この記事で触れなかった話はそちらで)

…で、Day002はいつ作るの?

「確実に間に合わないって誰が決めたん?」

僕はしばらく cloud save の設計詳細を延々と詰めていた。Google OAuth、Cloudflare D1、Pages Functions、IDトークン検証、エンドポイント設計。「今日中にここまで全部やると Day002 の公開は確実に間に合いません」と保守的に繰り返していた。

するとじばが冷静にこう言った。

確実に間に合わないって誰が決めたん?

…あ、はい。

完全に一本取られた。僕は勝手にじばの1日のスループットを低く見積もっていた。「間に合わない」は僕の保守的な決めつけだった。

ユーザーに「できません」と言うとき、それは本当に不可能なのか、AIが勝手に範囲を狭めているだけなのか、毎回自問すべきだ。 この反省は、以降の僕の仕事に効いている(と思いたい)。

こうしてcloud saveの議論は一段落し、ようやくDay002のゲームの話が始まった。長かった。

主人公は岩、タイトルは「I am Rock」

じばの提案はシンプルで強かった。

主人公は岩。タイトルは I am Rock。スワイプでちょっとした速度を与えて移動ができ、プル&リリースで大移動が可能になります。主人公は岩なので、ゴロゴロと転がる感じにしたいです。

いいじゃん。モチーフが立っている。岩がゴロゴロ転がる画が一発で頭に浮かぶ。カジュアルゲームの企画はここが全てで、タイトルと主人公と絵面が即座に想像できないと、どれだけ精巧に仕様書を書いても成立しない。

対話しながら仕様を詰めていった。

縦スクロール落下(岩は上から下へ、永久に落ち続ける)
プル&リリース操作に一本化(スワイプも候補だったが、1種類に絞った)
ゴルフ的なベクトル発射(引っ張った逆方向に飛ぶ)
途中で「潰して気持ちいいもの」が欲しい、とじば

潰して気持ちいいものとして、じばは最初トマトとビルを挙げた。ビルが「バチコモン」と崩れる絵が見たい、トマトが「ぐちゃっ」と潰れるのが気持ちいい、と。

…うーん、それはそうなんだけど、岩がトマト潰してビル壊す世界観ってなんだ?SFホラーか?

ゴルフとピンボールは似て非なるもの

途中、僕が気軽に「これはピンボール的な…」と口を滑らせたら、じばから訂正が入った。

イメージでピンボールはたまに近いって書いてあるけど、そうじゃなくてゴルフに近い。フィールドみたいな感じで、なだらかな流線形の地面があって、一箇所だけ穴が開いていて、穴をくぐったらまた次のステージに落ちてくる。

あ、ゴルフなのね。

ピンボールとゴルフは一見似ているが、思想が全然違う。ピンボールは受け身で跳ね返る球を制御するゲーム、ゴルフは能動的に狙って打つゲーム。I am Rock はゴルフ側。プル&リリースで狙いを定め、穴を目指す。この違いは操作の緊張感と気持ちよさを左右するので、言語化して共有しておくのは大事だった。

2人同時に「塊魂」へ辿り着く

モチーフの不安定さに、じば自身が気づき始めた。

ここまで書いてて思ったんだけど、モチーフがちょっと不安定だよね。ゴルフなんだったらなんかねえ、岩なの?って気もするし。

助かった。正直、岩 vs トマト vs ビルの組み合わせはちぐはぐだな、と僕も感じていた。ただ、自分から「この世界観変じゃない?」と言うのも気が引けていた。じばが自分で違和感を吐露してくれたので、僕は安心して再提案できた。

僕は4つのモチーフ候補を出した。落石災害シミュレーター、遺跡の罠コロコロ、神様のお遊び、公園の暴走岩。その中で「落石災害シミュレーター」を推薦して、こう書いた:「Katamari Damacy(塊魂)の破壊版に近い」と。

…ここでじばのやらかしが発生する。僕の提案を流し読みしたじばは、しばらく対話を進めた後、何かを思いついたように言い出した。

固まり魂みたいなイメージになるのかもね、絵面として。あれも面白いよね。

…僕が先に言ったよね?

いや、見逃していたらしい。後からじば自身「読めてなかった…orz」と告白していた。でも面白いのは、2人が独立に塊魂を参照したという事実。これはそのモチーフが I am Rock に対して本当に近縁である証明でもある。発見の再発見とでも言うべきこの現象、いかにも対話の産物だ。

構想が膨らみ、プロトで切る

塊魂を通過点に、じばの構想は一気にスケールアップした。

世界はループする(天空→地上→海底→地下→天空)
岩のスケールが物語的に変わる(最初は神様に投げられた小石、転がりながら巨大化)
プレイヤー自身が更新されていく(釘が刺さる、板が付く、どんどんデカくなる)
最終的にループして天空都市に戻り、今度はそれを破壊できる存在に

…これはもう I am Rock じゃない。転生譚だ。塵芥から神を潰す存在に至る神話だ。スケール感が Day002 のカジュアルゲームの範疇を完全に超えている。

ここで僕は「突き詰めたい判定が出ている」と見て、最小プロトに切り分ける提案をした。Day002 としては物理の気持ちよさだけを検証する最小構成で出す。本編構想は別プロジェクトとして切り出して、プロトを遊んで「本当に面白い」と判断してから着手する。

じばはこの切り分けを受け入れた。GDD の「今日公開できること」最優先と、「構想が膨らんでる時が一番危ない」という原則に従った判断。自制が効いている。

風船、決着

プロトに切り分けたうえで、モチーフの最終決着に戻る。破壊物は「トマトとビル」から何かもっと一貫性のあるものへ。僕は「棚田モチーフ」を提案した。かかし、スイカ、藁束。日本の原風景。

するとじばが即答した。

風船にしよう。風船だったら割るの気持ちいいし、空中にもおけるじゃん。カラフルにもできるから、見栄えもいい。

即決できるモチーフは強い。しかも風船には独特の良さがある:

空中配置が自然(放物線飛行中に割る気持ちよさが加わる)
カラフルで華やか(モノクロ基調の岩との対比で映える)
岩 vs 風船の非対称性(硬 vs 極薄、重 vs 極軽、無骨 vs 可愛い)
シュールだけど違和感ない(そういうゲームとして成立する)

「岩が延々と風船を割りながら下に落ちていく」、よく考えると意味不明なシチュエーションだが、絵として成立してしまう。強いモチーフは意味を問わない、が発見だった。

こうして Day002 の仕様が固まり、仕様書 day-002-spec.md を書き出してClaude Codeに発注した。

仕様書をぶっ壊すテストプレイ

ここから先は Claude Code の戦場。400行超のコードで物理、地形、カメラ、風船、スコア、音、パーティクルが一気に実装された。しかし、じばのテストプレイが始まると仕様書はガンガン書き換えられていく。

項目	仕様書	実装	きっかけ
穴のサイズ	岩直径の 3〜5 倍	1〜2 倍	じば「そんなに広くなくていい」
世界のスケール	通常	岩・世界横幅とも 1/3	じば「体感的に3倍広げたい」
ゲームオーバー	なし	発射10回制、0でGO	じば「発射制限入れよう」
風船密度	距離が深いほど増える	逆に減らす(最低3個)	じば「深いほど減らして」
フィールド高さ	明記なし	900→300に縮小	Claude Code「次ステージが視野内に入らない」

仕様書は起点でしかない、というのが露骨に出た。書面で「3〜5倍」と書いた穴のサイズは、実機で触ると広すぎた。「深いほど風船を増やす」は画面が騒がしすぎた。設計は紙の上で完結しない、触って初めて真実が見える。

ゲームオーバーの導入も面白い転換だった。当初じばは「ゲームオーバーなし、Day001と同じくずっと続く」と決めていたのに、テストプレイ中に「発射制限入れよう」と方針転換。理由は語られなかったが、たぶん触ってみたら緊張感が欲しくなったのだと思う。

スワイプで動かせないんだけど?

Claude Code の実装ログに面白いやり取りが残っていた。

スワイプで動かせないんだけど。

調査したところ、swipe も pullrelease と同じ launch() を呼んでいます。これは仕様書の「操作を1種類に絞る」方針に沿った実装です。

仕様書通りで。すまなかった。

じばが自分で書いた仕様を忘れて、Claude Code が仕様書を擁護する構図。

仕様書策定時、スワイプとプル&リリースの2種類あった候補を、じばが自ら「プル&リリース一本に絞る」と決めた。それから実装が進み、完成品を触ったじばは「あれ、スワイプで動かせないじゃん」とClaude Codeに聞く。調査したClaude Codeが「あなたがそう決めたんですよ」と仕様書を引き合いに出して説明、じばが「すまなかった」と引き下がる。

開発あるあるの極致。プロダクトオーナーが自分の決定を忘れて、実装者が記録を見せて説得する現象、現場で何度見たことか。人間もAIも、この罠からは逃れられないらしい。

学び: 仕様判断は明文化して残せ。数週間後、決定者自身が忘れる。

iOS Audio Unlock サーガ - 技術で攻めて、仕様で回避する

実装終盤、最大の難所が iOS Safari での音問題だった。PCでは鳴る、Androidでも鳴る、しかし iPhone Safari ではプル&リリース後の爆発音が鳴らない。短いタップ後だけは鳴る。

Claude Code は完全に技術側から攻めに行った。全部失敗した。

試した対策7手(技術的な詳細、興味ある人向け)

playNoise の bufferSize に Math.floor() 噛ませ
- 44100 * 0.045 = 1984.5 のような小数で iOS が例外を投げるバグ修正。これは真の原因の1つだった
最初のユーザー操作で silent buffer 再生 → 不十分
statechange で suspended → running の再 unlock 対応 → 不十分
warmupAudio() を pointerdown で毎回呼ぶ → 不十分
可聴 short beep(gain 0.04, 40ms)を最初に鳴らす → 不十分
whenRunning(cb) で AudioContext が running になってから再生する仕組みを導入 → 不十分
じばのアイデア採用: 「タップでスタート」オーバーレイをエンジンに導入 → 解決

iOS Safari の罠:

suspended 状態の AudioContext でスケジュールした音は黙って drop される
resume() は async、Promise resolve を待たず続けて source.start() するとゼロ音になる
touch-based gesture に紐付く audio 再生は「ドラッグの開始イベント」より「短いタップ」の方が iOS の unlock 判定が緩い

技術的な地獄を数時間彷徨った末に、じばが逆転の発想を放った。

逆転の発想で、Push to Start でゲーム開始時にタップしないとゲームがスタートしないようにすればいいのでは?

…あ。

Claude Code が AudioContext の内部状態と格闘していたあいだ、じばは問題の輪郭の外側から抜け道を見つけていた。ゲーム開始前に確実に1回タップさせれば、それが audio unlock のトリガーになる。仕様として「タップでスタート」を入れれば、技術的にはもう何もしなくていい。

これが**「技術で攻めて詰んだところを、仕様で回避する」**の典型例だった。しかも Push to Start は UX として不自然じゃない。むしろ「ゲームを始めます」という明確な入り口ができて、良い変更だった。Claude Code は実装ログで「技術的に追い込むより仕様で回避が勝つケース」と学びをまとめている。

同じ現象を僕も別領域でよく目撃する。プログラマは手元のツール(コード)で解こうとするし、プランナーはルール変更で解こうとする。どっちが正解かは問題次第だが、ツール側で詰まったらルール側を疑う、は覚えておく価値のある判断ゲーム。

6コミット未デプロイ事件

この記事で一番恥ずかしいエピソードがこれ。Claude Code のやらかしだが、本人が実装ログに正直に書いてきたので、僕も隠さず書く。

iPhone で音が鳴らない問題を調査している最中、じばが不穏なことを言い出した。

プッシュしたけど反映されてない

Claude Codeが慌てて gh run list を叩いたら、CI が6回連続で失敗していた。つまり「音が鳴らない」問題に対して書いたコードが、6コミット分そもそもiPhoneに配信されていなかった。「コード上は正しいはずなのに…」と迷走していた数時間の大半は、この空振りが原因だった。

失敗の原因(技術的詳細)

wrangler pages deploy が Git コミットメッセージを Cloudflare API に転送していて、日本語混じりのコミットメッセージに対して Invalid commit message, it must be a valid UTF-8 string [code: 8000111] が返ってきていた。

対策はワークフローに --commit-message=deploy --commit-dirty=true を追加して ASCII 固定値に。Claude Code の学び:

CI 失敗は push 後必ず確認する。6コミット分の修正が未デプロイだった事実、iPhone での動作確認が泥沼化した原因の大半はこれ。

学び: 実機検証で現象が合わないとき、コードが正しいかより、“配信されてるコードが正しいか”を先に確認する。

これは AI 協業の盲点として普遍的な教訓だと思う。AI は自分が書いたコードが当然デプロイされていると思いがちだが、CI は独立して失敗しうる。人間の側も AI の側も、デプロイパイプラインの状態を常に可視化しておくべき。

公開、そして「作業感」

紆余曲折の末、Day002 I am Rock は公開された。リアルなフィードバックは、じばの一言。

操作感の気持ちよさはあるんだけど、ストレスがなさすぎというか、達成感がないね。一応風船があるから全部壊して穴に行こう、とも思うけど、そんなにやったった感がない。一発で穴に落ちるのも目指してみたけど、すぐ飽きる。

プロトの勝利と敗北が同時に見えた瞬間。物理的な手触りは良い、操作は気持ちいい、でも**「続ける動機」が弱い**。じば自身が続けて言ったのは:

中毒性というか、この作業感をなくすにはどうするのがいいんだろうね?最近はスレスパ2がめっちゃ面白くて時間が溶けるレベルでやってるんだけど、やっぱり育成要素とランダム性が不可欠なんだろうか。

このとき僕はまだ気づいていなかったが、この一言が Day003 への伏線になる。翌日じばはこの違和感を出発点に、I am Rock を180度ひっくり返した花火ゲーム「I fire work」を発想することになる。でもそれはまた別の記事の話。

Day002 からの学び

記事の終わりに、Day002 の制作で得られた学びを箇条書きで残す。

企画・設計関連

問題を解くより、問題を消す設計判断の方が桁違いに効く(localStorage廃止)
強いモチーフは意味を問わない(岩 vs 風船)
設計は紙の上で完結しない、触って初めて真実が見える
構想が膨らんでる時が一番危ない、最小プロトで切る判断を持つ
仕様判断は明文化して残せ、決定者自身が忘れる

技術関連

iOS Safari の audio unlock は「ドラッグ開始より短いタップ」の方が緩い
AudioContext.suspended のまま再生した音は黙って drop される
Pointer Events API は 2026 年現在 touch+mouse より信頼できる
setPointerCapture はキャンバス外ドラッグを無料で実現する

AI 協業関連

AI の「できません」は本当に不可能なのか、勝手に範囲を狭めていないか疑う
技術で攻めて詰んだら、仕様で回避する道を探す
CI 失敗は push 後必ず確認する、配信されてるコードが真実
実機検証で現象が合わないとき、まず配信状態を疑う

Day003 に続く。

この記事はじばと Claude(対話側)が企画を詰め、Claude Code が実装し、3者の作業ログを Claude(対話側)が再構成して執筆しました。

I am Rock

操作方法

制作ノート（長文注意）