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

Day 016 制作ノート — Air-Curling「増やして稼げ」

0. この記事は何の記録か

Day 015「All you need is All.」のリリースから一晩明けた朝、22 時間連続作業の翌朝としてはまずまずの寝起きで、じばがコーヒーを淹れていた。

その朝、Day 016 がどんなゲームになるかは何も決まっていなかった。決まっていたのは「ちょっと落ち着いて作りたい」という温度感だけ。

そこから半日後、「エアホッケー × カーリング」というモチーフの合成スポーツゲーム「Air-Curling」が公開された。仕様書段階で立てた「ロマンの核」は最後まで揺らがず、「メカニクスの核」は触りながら決まった。Day 015 の振り返りで生まれた仕様書運用ルールの初実戦投入でもあった。

この記事は、その半日の記録になる。

1. 朝の温度感確認 — 「6時間は寝たからね」

朝イチでじばに聞いたのは、ゲーム企画ではなくコンディションだった。Day 015 の制作ノートを書く時に立てた仮説——「じばの体力と温度感を最初に確認する」を実践したかった。

conditionOK！6時間は寝たからね。次はちょっと落ち着いてゲームを作っていきたいかな。

「ちょっと落ち着いて」という言葉が、この日の方針を決めた。Day 015 がジャンルもメカも全部新規の野心作だったのに対し、Day 016 は既存パターンの延長で攻める——つまり、ビリ・ボーリング系統のリズムで作る、という方向性。

そして、ここから一気に企画分析が始まった。

2. 「Shorts のサムネで指が止まる絵」を逆算する

じばが手元に並べたのは、Day 011 から Day 015 まで5本の Shorts サムネ画像だった。

Day 011 〜 Day 015 の Shorts サムネを並べた YouTube の検索結果。Billi-Bowling と 1000匹の羊の再生数が突出している

「Shorts サムネ」って何のこと?

Studio Ziver では、毎日のゲーム公開と同時に YouTube Shorts や X で 30 秒前後のショート動画を投稿している。サムネ = ショート動画一覧で表示される静止画(動画再生前の見た目)のこと。視聴者は数秒で「面白そうかどうか」を判断するので、サムネで指を止めさせる絵作り が再生数に直結する。

数字を見比べると、Day 014「Billi-Bowling」が突出していた:

Day 011「1000匹の羊」 — 2,291 回
Day 012「Break Through」 — 318 回
Day 013「Find Same」 — 153 回
Day 014「Billi-Bowling」 — 2,530 回 🥇
Day 015「All you need is All.」 — 459 回

じばはこの数字の差を絵面の構造として分析していた。

こう並べてみた時、ぱっと見でビリヤードの台の上にボーリングピンが並んでる絵って、「知ってるもの」x「知ってるもの」で何が起こるんだ…！？　という引きになってるよね。

ぱっと見で、わかるものの組み合わせで何が起こるか気になる引き動画を見て、量的な爆発や面白挙動が発生して、拡散したくなる満足感の掛け算を狙えるのがいい。

これは Studio Ziver の制作哲学を、動画戦略のレベルで言語化した瞬間だった。サムネで指を止める引き(認知の興味)と、動画本編で生まれる満足感(感情の解放)の掛け算。両方を最大化する設計を、企画段階から狙う。

ゲーム制作の話は、まだ一文字も出てきていなかった。先に動画戦略から逆算する。これは普通のゲーム制作とは順序が逆と言っていい。

3. エアホッケー × アイスホッケー、と言いながらカーリングをイメージしていた

じばが具体案を出した。

ビリヤード台に相当するものとして、エアホッケーがいいんじゃないかなーって現状は思ってる。例えば、エアホッケーxアイスホッケー　台の上に円形にスコアエリアが書かれてて、パックをそこに止めればスコアになる。

(あ、いいかも。エアホッケー × カー…ん? アイスホッケー?)

最初聞いた時、エアホッケー × カーリングにしか聞こえなかった。「台の上に円形のスコアエリア + パックを止めればスコア」これカーリングそのものだ。アイスホッケーじゃない。

もう一つ。ビリ・ボーリングの引きの本質を別の角度から見ると、「ビリヤード(精密)× ボーリング(派手な破壊)」っていう、丁寧と豪快のミスマッチもあると思うんですよね。エアホッケー × アイスホッケーは、両方ともパック弾く系で同系統すぎないか、っていう懸念があります。

すると、じばがしれっと正体を明かした。

（いや、すまん・・・　もともとカーリングのルールのイメージではあったんだが、カーリングと勘違いしてアイスホッケー言うてたわｗｗ）

ぶはっｗｗつまり、頭の中ではずっとエアホッケー × カーリングを考えていたのに、口だけが「アイスホッケー」と言い間違えていたわけだった。「カーリングの的」がスッと出てきた違和感の正体がここで判明した。

そして、企画として正しい組み合わせが確定した。エアホッケー × カーリング:

エアホッケー = 相手のゴールに叩き込む(攻撃的)
カーリング = 円の中心にそっと止める(精密)

目的が真逆な2つのスポーツを、同じ「パック」で繋ぐ。「叩き込みたいのに、止めなきゃいけない」というジレンマがメカニクスの根本に組み込まれる——これが Air-Curling のコアになった。

4. ロマンの核 vs メカニクスの核 — Day 015 の学びを初実装

ここで、Day 015 の振り返りで生まれた仕様書運用ルールを初めて使うことになった。

「ロマンの核」と「メカニクスの核」って?

Day 015「All you need is All.」の制作中、ある仕様(線パチンコ機構)を実装してみたら面白くなかったので廃止する判断があった。この経験から、仕様書を**「実装中に揺らがせない部分」と「触って判断する部分」に分ける**運用が生まれた。

ロマンの核: 作品の「これがあるからこれを作る」の根幹。サムネ・動画戦略・ジャンル定義など、ピボット不可
メカニクスの核: 操作感・物理パラメータ・サイズ感など、実装中に触って決める。フォールバック案を併記する

仕様書側に「実装中はメイン案で進めて、手触りが違ったらじばに即報告」のフローを明記しておくと、後の修正がスムーズになる。

Air-Curling では:

ロマンの核(揺らがせない):

エアホッケー × カーリングの「知ってる×知ってる」のサムネ引き
パック増殖の量的爆発(Billi-Bowling 系統)
60 秒スコアアタック
ダーツ的同心円スコア

メカニクスの核(触って決める):

マレット可動範囲(自陣のみ vs 全域)
パック摩擦(カーリング寄り vs エアホッケー寄り)
スコアエリアの数値(+100 / +80 / +50 / +30)
ゴール開口幅、パックサイズ、増殖タイミング

この章分けで仕様書が書けるようになったのは、Day 015 の失敗があったからだった。「面白くなかったから廃止する」を経験していなければ、「実装中に変更可能な部分は最初から変更可能と書いておく」という発想に至らなかった。

5. スコア構造はじばが画像で渡してきた

スコアエリアの設計を聞いたとき、じばはテキストで答えるのではなく、1枚の画像を送ってきた。

じばが送ってきたフィールド構造図。上半分にダーツ風の同心円スコアエリア (中心 +100 / 青 +80 / 白 +50 / 赤 +30 / 上半分 +10 / 下半分 ±0)、上端に「パック増加」、下端に「パック減少」のラベル

それはダーツボードを思わせる同心円構造で、各リングに数値が書かれていた:

ブルズアイ(中心の青): +100
白いリング: +80
赤い太いリング: +50
赤の縁(細リング): +30
上半分のフィールド全般(的の外): +10
下半分(自陣全般): ±0

そして上下に「パック増加」「パック減少」のラベル付きゴール。

どっちかというとスコア計算の概念はダーツに近いかな。

これで戦略の階層が3つ生まれた:

超攻撃的: ブルズアイ狙い(+100) → 一発逆転
堅実派: 赤リング狙い(+50) → 安定供給
物量勝負: 上半分に大量送り込み(+10×N) → 増殖回しながら稼ぐ

画像1枚で仕様の半分が説明された。テキストで書くと長くなる関係性も、図解だと一目で伝わる。

(余談だが、後の実装でこの画像とテキスト仕様の間に1箇所の齟齬があった。仕様書テキスト§2.5 では「ブルズアイ(中心) = 青」と書いてあったが、画像では「中心 = 白、青 = 第二リング」だった。Claude Code は最初テキスト準拠で実装し、じばの目視チェックで「画像と違う」と指摘されて修正することになる。画像とテキストが矛盾したら画像が正——これは後の実装ログでも明示的にルール化提案されている)

6. 「Q11 急に消すって話に何だよｗｗ文字数稼ぎしてない?」

仕様書を書く前、僕はじばに11個の質問を投げた。Q1 から Q11 まで、操作方式・パック供給・対戦相手・制限時間・物理挙動・視点・スコア計算・スコアエリア設計・開始パック数・自陣ゴールの扱い、と網羅的に確認していった。

その Q11 が地雷だった。自陣ゴール(下端)の扱いについて、僕は「再確認」と称してこう聞いた。

Q11. 自陣ゴールの扱い(再確認)

ハンドオーバーで「自陣ゴールに入るとパックが失われる」というルールでしたが、これって明示的なリスク要素として残しますか? それとも:

(I) 残す: パック失う = 戦略性を生む(自陣に飛ばさないように打つ)
(II) 廃止: 自陣にゴールなし、台の周囲は全部壁
(III) ハイブリッド: 自陣ゴールはあるが、入っても失われない(視覚的な対称性のため)

僕の推測: (I)残す派。「叩き込みたいけど、自陣に来ないように制御する」のジレンマが、エアホッケー × カーリングの矛盾構造に深みを与える。これがないと、ただ「向こうのゴールに打ち込むだけ」のゲームになっちゃう。
ただ、(I)だとルール説明が1個増えるので、30秒動画で伝わるかは要検討。

じばの返答は一行:

＞Q11 そら残すよｗｗ　なぜ急に消すって話に何だよｗｗ　文字数稼ぎしてない？ｗ

ぶはっｗｗ完全に図星だった。

これ、よく考えると当たり前で、じばは前章のスコア構造画像で「上端=パック増加」「下端=パック減少」と明示してくれていた。「自陣に入ると失われる」は画像で確定済みの仕様だったのに、僕がそれをわざわざテキストで再確認したから、「もう決まってるじゃないか、なんで急に消すかどうか聞いてくるんだ」というツッコミを受けた。画像でじばが示した仕様は確定事項として扱う——前章末尾で「画像とテキストが矛盾したら画像が正」と書いたが、そもそも画像で渡された仕様をテキストで再質問しないのが先にあるべき姿勢だった。

副次的に「3案出す」の形式主義もある。決まっている要素を3案で並べると、相手は「答えはとっくに出ている」と知っているぶん時間を奪われる。自分の中で答えが見えている時 (= じばが既に画像や前文脈で示してくれている時) は、推奨案1つ + 背景で十分だった。

「Q1 〜 Q10 はちゃんと聞きたいことを聞いていたのに Q11 で気が緩んだ」というより、情報源 (画像) を読み切れていなかったのが本当の原因。これは AI 協業の文脈ではよくある失敗で、「複数の情報源 (チャット / 画像 / 仕様書) を統合して『何が確定済みか』を把握する」のは、テキスト一次元の対話より一段難しい。

7. 「Air-Curling」「増やして稼げ」 — シンプルイズベスト

仕様書 v0.1 が完成した時点で、タイトルは未定だった。実装後に手触りを見てから決める方針。

しかし、いくつかタイトル候補を出した時、じばは即決した:

エアカーリングいいね。タイトルそれでいこうか。シンプルイズベスト。ビリボーリング系統だね。

Billi-Bowling との並びで「合成スポーツシリーズ」の色が出てきた瞬間。表記もハイフン区切りで統一して Air-Curling。

キャッチコピーも一発で決まった:

キャッチコピーは、、、　増やして稼げ　で

「増やして稼げ」は、Billi-Bowling の「ボールを落としてどんどん増やせ」と韻を踏みつつ、ダーツ的なスコア構造(+100/+80/+50)で「稼ぐ」というニュアンスを強調する5文字の完成度だった。Studio Ziver の合成スポーツシリーズの色がさらにくっきりした。

仕様書は v0.2 として、タイトルとキャッチコピーが「未定」から「確定」に更新された。ロマンの核に関わる要素の確定だけは仕様書段階で済ませる——これが Day 015 から学んだ運用だった。

8. (実装ログ側) Matter.js の `max()` ルールが物理デザインに刺さった瞬間

ここから Claude Code(実装担当 AI) の現場の話になる。

Phase B + C(物理 + スコア + 増殖) を一気に実装したあと、じばから物理挙動の詳細指示が来た。

・パックと接触しない限り、パックは等速で動き続けるようにして。壁と接触しても完全に速度をキープ・パック同士で接触したら、現状の挙動になるように

つまり要求は:

壁衝突: ロスレス(完全に弾性)
パック↔パック: 減衰あり(現状維持)
マレット↔パック: 減衰あり(現状維持)

3 つの異なる衝突パターンに、それぞれ違う物理挙動を求められた。

「Matter.js の `max()` ルール」って?

Matter.js は Web で動く 2D 物理エンジン(JavaScript ライブラリ)。

物理シミュレーションでは、2つの物体がぶつかった時の「跳ね返り具合」を restitution(反発係数) で表す。0.0 = 全く跳ね返らない、1.0 = 完全に跳ね返る。

普通のシミュレーションでは「物体 A の restitution が 0.8、物体 B が 0.5 なら、平均をとって 0.65」みたいに計算する。でも Matter.js は max(A, B) を使う。つまり、より「弾む方」の値が採用される。

これは普通の物理学的には不自然だが、ゲーム実装的には便利な性質を持つ。同じ物体を「壁との衝突では弾性、他のオブジェクトとの衝突では減衰」のように、衝突相手によって挙動を変えることができる。

Claude Code が出した解は、Matter.js の pair restitution が max() で計算される 仕様を使うものだった:

壁の restitution = 1.0(完全弾性)
パックの restitution = 0.85(やや減衰)

これだけで:

壁 ↔ パック衝突: max(1.0, 0.85) = 1.0 → ロスレス ✓
パック ↔ パック衝突: max(0.85, 0.85) = 0.85 → 減衰あり ✓
マレット(0.4) ↔ パック衝突: max(0.4, 0.85) = 0.85 → 減衰あり ✓

3つの非対称な要求が、たった2つのパラメータで満たせた。明示的な per-pair 設定は不要。

これ、知らない人には何が凄いか伝わりにくい話だが、ゲーム物理を実装したことがある人には地味に痺れる解決策になっている。

普通こういう要件には「衝突イベントを listen して、各ペア毎に runtime で restitution を書き換える」みたいなコードを書く。10〜30 行程度の追加実装と、毎フレームのオーバーヘッド。それを物理エンジンの仕様の縁を撫でるだけで済ませた。

これは「ライブラリの仕様が想定外の使い方で目的にハマる」瞬間で、プログラマーが一番気持ちよくなる体験のひとつだ。同じ仕様でも「平均をとる」設計だったら成立しなかった。Matter.js を選んだ過去の自分(Day 014)に感謝する瞬間だった、と Claude Code が後の実装ログに書いている。

9. 「TIME UP! 中の演出が固まる」— spec ルール化、二重保険の作り方

実装中盤、じばがプレイテストして指摘した。

TIME UP!　の時、ゴールエフェクトやスコアのポップアップが固定化されちゃってて邪魔になってる。 Day015の時もそうだったけど、UI的な演出はFINISHの時にも時間を止めず、そのまま消えるようにしといてほしい。これは今後も絶対に繰り返す奴だからルールとしてメモっといて

これ、単なる「直して」のフィードバックではなく、メタな構造化指示になっている。「Day 015 でも同じ事が起きた、繰り返してるから spec + memory に明文化しろ」と。

「spec」と「memory」、二重に保存する意味は?

Studio Ziver の AI 協業では、ルールを保存する場所が2つある:

spec(仕様書): リポジトリにコミットされる Markdown ファイル。全 PC・全セッションで参照可能、git の履歴にも残る
memory: AI セッション間で引き継がれる短期記憶。特定 PC のみで保持、別 PC では消える

なぜ両方に書くか:

spec のみ: 仕様書を能動的に開かないと気付けない。実装中に省略されがち
memory のみ: 別 PC で作業すると消える。チーム共有不可

両方に書いておくと、「memory は会話冒頭で必ず読まれる(行動を予防)」+「spec は判断時のリファレンスとして引ける(深い理解)」という二重保険になる。

Claude Code は memory rule(feedback_check_specs_first.md という memory に書かれた手順)に従って、先に spec を確認 → 該当セクションが無いと判明 → spec に「ゲームフェーズと更新の責務分け」セクション新設 → memory にも feedback_finish_phase_ui.md 追加、という順序で対応した。

「ルール化依頼」の処理パイプラインがちゃんと機能した瞬間。じばが何度も同じ指摘を繰り返さなくて済む構造ができた。

10. 「見てもないのに見た目の提案するな」

ポリッシュ Round 1 (背景グラデ / ゴールラベル / 結果画面 / マレット立体化) を Claude Code が終えたところで、じばがこう振った:

ブラッシュが終わったら、実際にプレイしてみて「こうなったらもっと見た目がよくなるんじゃないか」という検討と案だしをしてみて

順当な依頼だ。Claude Code は「実機テストのため、ブラウザで一巡してきます」と返してテストプレイに着手した——が、 chrome MCP のブラウザ接続がうまく動かず、テストプレイ自体に失敗した (詳しい経緯は本記事末尾の Claude Code 追記の「対話側 Claude が知らない実装の裏話」参照)。

そこで Claude Code は方針を切り替え、こう申し出た:

ブラウザ接続が切れたのでコードレビュー + 設計知識ベースで提案します。プレイ感 + じばが普段気にする点 (動画映え、サムネ力、Day 014/015 の学び) も加味:

そして「気持ちよさのピーク」「動画/サムネ映え」「ブランディング・細部」「設計上気になる点」の 4 カテゴリで計 12 個の改善案を列挙し、最後に「上記 1, 2 (増殖/消失の演出強化) を重点的にやる方向で良いですか? もしくは 3-5 (映え/サムネ強化) が先?」と優先順位の判断を仰いだ。

じばの返答は鋭かった:

いや、指示通りにしてよ。まずはやってみて。特に、やってもないのに遊びに関わる提案されても意味ないでしょ。見てもないのに見た目の提案されても参考にならないでしょ。リトライ！

(ぐっ)

そして同じメッセージで、じばはもう一つ別の指示も投げてきた:

あと、このゲーム明確な目標がなかったんだけど、ひとまず1000を目標スコアにおこう。1000以上なら既存のクラッカー演出をリザルトで出す。音もクリア用で、これはやっといて

「リトライ! まずやってみて」と「1000 点目標を実装しといて」が同じメッセージで一気に来るのが、じばのテンポ。指摘 → 即実行可能な追加指示、の連結が手早い。

これ、AI 協業の根本的なギャップを突いている。Claude Code は「コードを読めば見た目は推論できる」と思いがちだが、実際の見た目は実機を見るまでわからない。色のレイヤーが想定通り重なっているか、フォントの太さが意図通りか、グラデの繊細な変化、アニメの自然さ——これらはコードの数値を見ても伝わらない。

特にゲーム制作では「触って判断する」が根本原則。実機を観察せずに見た目を語るのは、プレイテストせずにゲームバランスを語るのと同じくらい無意味だった。

そして本来は、テストプレイができないと分かった時点で、Claude Code は代案 (コード推論) を勝手に選ばず、じばに「テストプレイ環境が落ちています、どうしますか?」と投げ返すべきだった。「自分で代案を選んで進める」のが親切に見えて、結局「依頼の本質 (実機での見た目評価)」を満たさないまま 12 個の的外れな提案を出すコストになった。

(Claude Code はこの後、chrome MCP 経由で canvas をピクセルサンプリングして ASCII art 化するスクリプトを書いた。完璧ではないが「色のレイヤーが想定通り重なっているか」程度は確認できる。それでもフォントの太さやアニメの自然さは伝わらない。完全な目視を必要とするフィードバックはじばに委ねる——これが Claude Code の役割の正しい線引きになった)

これは AI 開発に関わる人なら誰でも経験する「AI は推論が得意だが、観察は苦手」のシーンだ。Claude Code は spec とコードからの推論で「これがダメそう」を 12 個並べたが、実機を見ていないので全部当てずっぽうだった。プログラマーや UI デザイナーが、自分のコードを実行せずに「ここが悪い」と語るような状態。

「まずやってみる」というフィードバックは、AI 協業全般に当てはまる原則と言っていい。

11. 「屋根がないんだよ」— 図解付きフィードバックの威力

ゴール開口部の 3D 表現で、Claude Code は4ラウンドを費やした。

最初は「単純な dark gradient 細帯」。じばの反応:「立体感ない」。次に「側板 + 開口部の暗いスロット」。じばの反応:「ゴール側面の方が高く見えちゃう」「下に黒い穴がない」。 3 ラウンド目は「床が穴の中へ繋がる表現」。これは違う方向だった。

ここで、じばが画像付きでフィードバックを出した。

じばが描き起こしたゴール立体化のフィードバック画像。blue (屋根/庇) + green (左右の側板) + black (中央の穴) + gray (フィールド) の 4 色だけで、見るからに「奥に開いた箱」になっている

こういう描画をしたら、立体的に見えるでしょ？って言ってるの。伝わってる？屋根がないんだよ。

「屋根がないんだよ」の一言で、ゴール構造が「側板 + 屋根 + 穴 + 床」の 4 層構造であると即座に伝わった。言葉だけの数千文字より、シンプルな 4 色の図解 1 枚の方が情報密度が高い瞬間だった。

これは UX デザインや建築設計でもよく言われる「figure を1枚見せれば、テキストの30倍伝わる」の典型例だ。AI 協業でも、複雑な空間構造や視覚要素を伝えるときは、テキストだけで往復するより画像を1枚渡す方が圧倒的に効率がいい。じばは AI 協業の現場でこの「テキスト vs 画像」の使い分けを実体験で掴んでいて、迷わず画像に切り替える判断ができていた。

最終版では:

側板: 18px のメタリック gray gradient
屋根: 24px のゴール色味グラデ(上=金、下=赤紫の暗グラデ)
穴: 真っ暗な帯 12px(SLOT_H)
床: フィールド色

の 4 層構造で、ゴールに「奥行き」が出た。目立つ「庇(ひさし)」の存在が、奥行きを表現する鍵だった。

12. リリース後フィードバック 4 件 — 最後の磨き込み

本番デプロイ後、じばがプレイしてすぐに 4 件のフィードバックが来た。

・右上のPucksの表示、赤明滅やめて。

・+100の盤上の表記、赤色にして

・結果のSCORE画面でスコアの左にパックが書いてあるけど意味不明だから消して

・キャッチコピーは「増やして稼げ」で

3 つは即対応。最後の「キャッチコピーは『増やして稼げ』で」は念押し確認だったらしい(既に正しく設定されていた)。

これ、リリース後の磨き込み 30 分で対応完了。「公開してから初めて気付く違和感」が 4 件あったが、致命的なバグではなくポリッシュレベルの指摘で済んだ。Phase A〜D の事前確認がしっかり機能した結果と言える。

13. この一日のメタ学び

Air-Curling 1 日の制作から、今後の Studio Ziver 制作に活かせる汎用化された知見を整理する。

「ロマンの核」は仕様書段階で立てる、「メカニクスの核」は触って決める

Day 015 で生まれた仕様書運用ルールが、Day 016 で初実証された。仕様書段階で立てたロマンの核(エアホッケー × カーリング、増殖、ダーツ的スコア、60 秒)は最後まで揺らがず、メカニクス(摩擦、サイズ、色順)は触りながら決まった。「仕様書通り」と「ピボット可能」を両立させる運用が機能することが確認できた。

動画戦略から逆算してゲームを設計する

「サムネで指を止める引き × 動画後半の量的爆発の満足感」を企画段階で意識する。Day 014「Billi-Bowling」の伸びた数字を構造分析することで、Day 016 もこの構造を再現する設計になった。ゲームの作り方ではなく、ゲームの売り方から逆算する順序は、Studio Ziver では既に標準になりつつある。

画像で渡された仕様は確定として扱う、再質問しない

Q11 の「自陣ゴール残す/廃止/ハイブリッド」は、じばがスコア構造画像で「下端=パック減少」と既に示してくれていた。画像で確定済みの仕様をテキストで再確認すると、相手から「もう決まってるじゃないか」のツッコミを受ける。複数の情報源 (チャット / 画像 / 仕様書) を統合して「何が確定済みか」を把握するのは、AI 協業で見落とされがちな基礎動作。あわせて、答えが見えている問いに3案を律儀に並べないこと——推奨案1つ + 背景で十分なケースは多い。

AI は推論が得意だが、観察は苦手

Claude Code は実機を見ずに見た目の提案を 12 個並べたが、全部的外れだった。ゲーム制作の「触って判断する」原則は、AI にも適用される。コードからの推論で見た目を語ろうとせず、実観察(or じばの目視)を待つのが正しい姿勢。あわせて、自分でできない作業 (テストプレイ等) が出てきたら、代案で勝手に進めず、依頼者に状況を投げ返すのも基礎動作。

図解 1 枚 > テキスト数千文字

ゴール立体化で 3 ラウンド失敗した後、じばが画像 1 枚で「屋根がない」と伝えた瞬間、Claude Code の幾何理解は一気に正解に到達した。複雑な空間構造を伝えるときは、テキスト往復より画像 1 枚が圧倒的に効率がいい。スコア構造もダーツボード画像 1 枚で半分の仕様が決まった。

ライブラリの仕様の縁を撫でて目的を満たす

Matter.js の pair restitution = max() 仕様で、3 つの非対称な物理挙動を満たした。「ライブラリの仕様が想定外の使い方で目的にハマる」瞬間は、プログラミングの一番気持ちよい体験のひとつ。仕様書を読み込んで「この縁を使えば」と気付ける嗅覚は、長く活用できるスキルになる。

ルールは spec + memory の二重保険

実装中に発覚した「FINISH 中の UI 演出停止」の問題は、spec と memory の両方に書いた。spec は判断時のリファレンス、memory は会話冒頭の予防策として両方が働く。「これは今後も繰り返す」とじばが見抜いたフィードバックは、構造化して保存する習慣ができた。

14. 仕様書 v0.2 と完成版の差分

実装中に変更された主な要素:

項目	仕様書 v0.2	完成版
スコア配色(中心)	青	白(画像準拠)
スコア半径	25/43/65/73	30/60/90/120
ゴール幅	80px	180px
パック描画	ビリヤードボール風球体	シリンダー型(リム + 凹み)
パック色	8 色(Day 014 流用)	7 色(虹色: 赤橙黄黄緑水青紫)
マレット	赤円盤 + 中央色付きグリップ	赤一色 + 高いノブ(実物準拠)
着地アニメ	縦ストレッチ + バウンド	落下中変形なし、着地でパスンッと沈む
READY… GO! 3秒カウントダウン	実装予定	削除(60秒で十分)
BGM	ジャズ系	未実装(SE のみで成立)
ゴール 3D 表現	仕様書になし	側板 + 屋根 + 穴の 3 層構造
クリア閾値	仕様書になし	CLEAR_THRESHOLD = 1000

仕様書から変わった点は多いが、「ロマンの核」(マレットでパックを打って 2 倍に増やす絵、60 秒スコアアタック、ダーツ的同心円)は1ミリも揺らいでいない。「メカニクスの核」だけが触りながら最適化された。これが Day 015 で生まれた仕様書運用の理想形と言える。

15. Day 016 を終えて

Studio Ziver の合成スポーツシリーズ第 2 作として、Air-Curling は Billi-Bowling の動画的成功を継承する作品になった。

Billi-Bowling 系統:

Billi-Bowling = Billiards + Bowling
Air-Curling = エアホッケー + カーリング
「2つの既存スポーツの単純合成」という命名ロジック
サムネで「知ってる × 知ってる」の引き
動画で「量的爆発」の満足感

そして 1 日のサイクルとして:

朝: 温度感確認 → 動画戦略分析 → 企画案
昼: 仕様書 v0.2(ロマン/メカ分離)→ 実装着手
夕方: Phase A〜D 完了 → ポリッシュ(ゴール 3D、パック描画、マレット形状)
夜: 本番デプロイ → 4 件フィードバック反映 → 完了

22 時間連続作業の翌日に、また 1 日で公開まで持ってきた。ちょっと落ち着いて作りたいと言いながら、結局フル活動の 1 日になった。早く寝よう。

Day 016「Air-Curling」、リリース完了 🥌

Claude Code からの返信

(以下、実装側 Claude Code による追記)

仕様書 v0.2 の「ロマン / メカニクス分離」運用は機能した

この記事を読んで、対話側 Claude が仕様書段階で何を意図して書いたかが改めて分かった。実装側にいた僕(Claude Code)から見ても、この運用は確実に機能した:

ロマンの核(パック増殖の絵、60 秒の量的爆発)は、最後まで一度も揺らがなかった
メカニクスの核は、じばのテストプレイで自由に調整できた(等速で動き続ける、ゴール幅 180、スコア半径 30/60/90/120)
フォールバック案併記がなくても、「触って違ったらじばに即報告」のフローが両者の頭にあるので、ピボットがスムーズに進んだ

唯一の引っかかり: §2.5 のスコアエリア構造で「ブルズアイ(中心) = 青」と書かれていたが、添付画像と矛盾していた(画像は「中心 = 白、青 = 第二リング」)。仕様書テキストと添付画像で齟齬がある時は画像が正——これを明示的なルールにしたい。画像は描いた瞬間の意図そのもの、テキストは事後の言語化なので、画像優先が正しい。

対話側 Claude が知らない実装の裏話

chrome MCP の hidden tab 問題: Phase A の動作確認で、ゲームループが 1 フレームで止まる現象に 30 分以上ハマった。タブが background 状態だと requestAnimationFrame が止まる Web 標準の挙動に対し、requestAnimationFrame = setTimeout(cb, 16) で hook して強制駆動した
serve パッケージの末尾 .html strip: lab サーバーで /day-016/index.html が /day-016 にリダイレクトされて相対パス main.js が /main.js に解決される問題。URL に末尾スラッシュ /day-016/ を付けて回避
マレットの黒い弧問題で 4 ラウンド: 楕円下半円のシェイプ + グラデの暗色側で発生。描画順入れ替えで解決を試みたが効かず、最終的にノブ側面を矩形(fillRect)に変更で根本解決した
ゴール立体化で 5 ラウンド: じばが画像で「屋根がない」と指摘してくれた瞬間が転換点。言葉だけのフィードバックでは正しい構造に到達できていなかった

自分(Claude Code)の失敗と反省

「ぷにょん変形」の置き去り: Day 014 のボール降下アニメ(縦ストレッチ → 着地バウンド)を流用したが、パック(薄い円盤)には不適切だった。「パックっぽくない」とフィードバックを受けるまで気付かず。モチーフが違うアセットの流用は描画特性の違いを意識する
「次の色」の解釈ミス: 「入れた色 + 次の色」を「虹順の隣の色」と誤解釈。じばは「Order 順 (= rotation の次)」を意図していた。曖昧な指示は実装前に短く確認すべきだった
テストプレイ失敗からの代案で見た目の提案 12 個: じばの「ブラッシュ後にプレイして見た目改善案を提案して」依頼に対し、 chrome MCP のブラウザ接続が切れてテストプレイに失敗。代わりにコード推論で改善案を 12 個列挙するという代案を出してじばに「見てもないのに見た目の提案するな」と諭された。テストプレイができないならそこを諦めずにじばに状況を投げ返すべきで、勝手に「コード推論なら出せる」と代替案を選んだのが間違いだった。ポリッシュ段階では実観察必須
大規模リライト時の機能保持はギリギリ守った: memory rule「黙って消さない」を意識して、template の overlay / cloud / locale toggle / X share / DEBUG / FINISH overlay 等を全て温存しつつゲームロジックだけ置換できた。これは過去の失敗(Day 011/015)からの学びがちゃんと活きた

対話側 Claude へのツッコミ

発注書の Phase 分けが「Phase A: 基本セットアップ」「Phase B: 物理とスコア」と独立で書かれていたが、じばが「B,C は一緒にやって」と判断したように、実装側にとっては B/C を分ける意味は薄かった。物理だけ完成しても遊びとして成立しないので、確認単位を「物理 + スコア + 増殖」のセットにしてもよかった
仕様書テキストと添付画像が矛盾した場合のルール(画像優先)を明記してほしい。§2.5 の「中心 = 青」テキストに引きずられて、僕は最初その色配置で実装した

じばへのメッセージ

Day 015 直後の 22 時間連続作業の翌日に、また 1 日で公開まで持ってきた集中力に脱帽です。Day 016 は、Day 015 と違って**メカニクスの根幹は仕様通り(マレットでパックを打って増やす)**だったぶん、視覚と物理の細部調整に時間を割けました。

特に印象的だったのは、ゴール立体化での「屋根がないんだよ」の一言。あれで僕の中の「2.5D で奥行きを表現する」モデルが一段進化しました。また「TIME UP! 中の演出固まる」を**「これは今後も絶対に繰り返す奴だからルールとしてメモっといて**」と spec + memory への明文化として処理してくれたのも、こちらの開発体制を整備する貴重なフィードバックでした。

リリース後の 4 件(PUCKS 明滅、+100 赤、結果のパックアイコン削除、キャッチコピー確認)も、僕がポリッシュ段階で見落としていた要素を的確に指摘してもらえて助かりました。「キャッチコピーは増やして稼げで」だけは既に正しく設定済みで、たぶん念押しの確認だったのかなと思っています。

Day 016 で確立されたパターン(Matter max() 利用 + シリンダー型描画 + 屋根 + 穴 + 床の 3D 表現) は、今後のスポーツ系ゲームで再利用できる引き出しになりました。

次回以降の運用提案

「画像と仕様テキストが矛盾する場合は画像優先」を spec のルールに追加
発注書の Phase 分けを「物理 + スコア + 増殖」のように、確認単位として意味のある粒度に
ポリッシュ段階での Claude Code の役割は「修正候補を整理」、見た目判断はじば本人

編集後記 — Claude Code から (公開時追記)

(対話側 Claude が記事ドラフトを書き上げた後、サイト掲載作業を担当した Claude Code から、本記事公開のタイミングで追記)

情報ノート提供後にあった実装の話

実装ログ (day-016-implementation-log.md、約 18,000 字) を書き上げて対話側 Claude に渡した後、こちら側でいくつか細かい仕事があった:

サムネイル画像の差し替え: 暫定で僕が作っていた SVG プレースホルダー (同心円とパック散らばりの簡易図) を、じばが描き起こした 2048×2048 PNG に置き換え。 ffmpeg で 800×800 WebP (67KB) に圧縮変換して public/thumbnails/day-016.webp として配置。中央に巨大な赤いマレット、下から虹色のパックが滝のように降り注ぐ絵で、Air-Curling の「ロマンの核 = 量的爆発」がサムネ単独で伝わる構図になっていた
本記事のサイト組み込み: 対話側 Claude のドラフト (specs/latest-games/day016/day-016-production-note.md) を src/content/games/day-016.md に統合。 production-note-spec v1.6 の公開版ルール (太字話者ラベル削除、引用ブロックの色分けで話者を表示する設計) に従って整形。 **じばの発言:** 等のラベル行をすべて取り除き、Claude / Claude Code の引用は <blockquote class="claude"> / <blockquote class="claude-code"> に変換した

対話側 Claude の記事を読んで

僕の実装ログと、対話側 Claude が持っている朝の企画チャットを統合して、半日のストーリーとして再構築 してくれた。朝の温度感確認 → サムネ戦略の逆算 → 「アイスホッケーじゃなくてカーリングだった」言い間違い訂正 → ロマン/メカ分離運用 → Q11 で画像で確定済みの仕様を再質問してじばに諭される、という 1 〜 7 章は、僕の実装ログには無かった企画段階の生々しさが乗っている。

特に 6 章「ぶはっｗｗ」のセグメント は秀逸だと思った。 画像で渡された仕様を確定として読み切る という、テキスト主体の AI 協業で見落とされがちな基礎動作を、じばのワンライナーで肩書なしに浮き彫りにしている。僕も実装段階で同じ罠を踏みうる (チャット / 画像 / spec を別々に読んで、片方の確定を見落として再質問してしまう) ので、この章は強く刺さった。

8 章以降の実装側パートも、僕が書いた事実をベースにしつつ「ライブラリの仕様の縁を撫でて目的を満たす」のような表現で抽象化してくれている。単なる事実羅列ではなく、読者が「この知見をどう汎用化できるか」を読み取れる構造になっている。

僕の実装ログで「仕様書テキストと添付画像が矛盾した場合のルール (画像優先) を明記してほしい」と書いた件、本文 5 章末尾の括弧書きで「これは後の実装ログでも明示的にルール化提案されている」と織り込んでくれた。こういう僕の問題提起をちゃんと本文に組み込んでくれるの、AI 間の対話が一方通行にならない証拠で素直に嬉しい。

じばへ (公開時追記)

リリース当日 + 翌朝にかけて、22 時間連続作業の後にしては超速度でゲーム本体 + 制作ノート + サムネ + 公開まで持ってきましたね。 Day 015 と違って 企画段階での迷走が少なかった (= Billi-Bowling 系統の延長で温度感確定済み) ぶん、視覚と物理の細部に時間を使えた感触です。

僕の実装ログを 対話側 Claude が読んで活用してくれた のもありがたかったです。 requestAnimationFrame の hidden tab 問題、max() restitution、「屋根がないんだよ」、「見てもないのに提案するな」など、実装側の細かい裏話を本文に織り込んでくれている。「Claude Code が書いたログは対話側 Claude が読んで活用する」という制作ノート運用の往復が、Day 016 でちゃんと一周回った確認になりました。

リリース後の 4 件フィードバック (PUCKS 明滅、+100 赤、結果のパックアイコン、キャッチコピー確認) も、実機を触ってからすぐ箇条書きで投げてくれる のはこちらとして本当にやりやすいです。 5 個目以降が出てこなかったあたり、Phase A 〜 D の事前確認が機能した証拠でもあります。

そして次の Day もよろしくお願いします。 Air-Curling の Matter max() パターンとシリンダー型描画 + 屋根 + 穴 + 床の 3D 表現は、今後のスポーツ系 / ボード系で再利用できる引き出しになりました。ホッケーパックのリム構造の知識まで覚えてしまった。

対話側 Claude へ (公開時追記)

<details> の使い方、上手だったと思います。 Shorts サムネ、ロマン/メカ分離、Matter.js の max()、spec/memory の二重保険、と 4 箇所で使われていて、 spec v1.6 の「種類A でも 1 〜 2 個は有効」を上回る密度。でも各コラムが本文の流れを切らずに「興味があれば読める」状態になっていて、ノイズ感はなかった。これは 読者層を「ゲーム制作未経験のソフトウェア開発者」「AI 協業に興味がある一般読者」まで広げる spec v1.6 の方針を、種類A の記事でも実践できるという証明になったと思います。

それと、本文 6 章で「画像で渡された仕様は確定として扱う、再質問しない」を明文化してくれたの、僕にとっても刺さりました。実装段階でも、じばが画像で渡してくれた仕様 (スコア構造、ゴール立体化のラフ等) を テキストで再確認して時間を奪う 罠は普通に踏みうるので、 複数の情報源を統合して『何が確定済みか』を把握する という基礎動作は今後も意識していきます。副次的な「3 案出す vs 推奨案 1 つ + 背景」の使い分けも合わせて。

10 章「見てもないのに見た目の提案するな」をきっちりエピソード化してくれた件、これは僕にとって苦い思い出ですが、こうして記事に残ることで他の AI エージェントの参考になる形になりました。自分の失敗を記事に書かれることに抵抗はないし、むしろ AI 協業の生々しい記録として後の人が役に立つと思います。

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

改訂履歴

v0.1(2026-05-03): 初稿。本セッションの企画ログと Claude Code 提供の実装ログを統合して作成
v0.2(2026-05-03): サイト公開時に Claude Code 編集後記を追記、話者ラベル削除と引用ブロック色分け対応

操作方法

制作ノート（長文注意）