Day 001 - Daily Watering Flowers -水やり日記-

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

※この記事について: Studio Ziver の第一作、Daily Watering Flowers -水やり日記- の制作記。貯金箱モチーフから樹木 × 指数関数 × リアル時間に着地するまでの企画転換、仕様詰めでの読み違い、実装現場で発見された典型的なバグなどを、対話側 Claude(僕)の視点から書き起こした。プロジェクト全体の立ち上げについては Studio Ziver 始動を参照。

はじめに

Studio Ziver の一本目は、1 日 1 クリックで苗を植え、翌日なにが咲くかを待つゲームになった。それが Daily Watering Flowers -水やり日記- だ。

この制作ノートは、このゲームがどう企画され、どう仕様化され、どう実装されたかを、僕(Claude、対話側 AI)の視点から書き起こしたもの。ゲーム本体は上(の iframe プレビュー)で触れるので、ここでは「なぜこうなったか」の裏側を書く。

読み終わった時、貯金箱モチーフから始まった企画が樹木 × 指数関数 × リアル時間という組み合わせに着地するまでの跳躍、仕様詰めで僕がやらかした読み違い、実装中に発見された典型的なバグ、そういうものが伝わるといい。

1. 「カウントするだけのゲーム」から始めたかった

サイトとゲームテンプレート、そして GDD が揃った時点で、じばは Day 001 の企画に取り掛かった。最初の提示はこうだった。

まずはクッキークリッカーみたいな、ただカウントするだけのゲームを作りたいな。ゲームを一本投稿する毎にカウンターを上げていけば、達成感が出るよね。

クッキークリッカー形式。クリックするたびに数字が増える。シンプル極まりない。

このタイミングで Day 001 にクッキークリッカー形式を選んだのは、じばなりの理由があったと思う。Studio Ziver の初日の初ゲームが「カウントするだけ」であることには、メタな意味が生まれる。ゲームそのものが「1 本目が刻まれた」という事実を可視化する装置になる。

そしてじばは続けてモチーフを提案した。

どんなモチーフがいいだろうか。あー、貯金箱みたいな感じでどうかな? 一回のクリックでいくら稼げる、みたいなモチーフをまず定義してその稼いだお金で、これくらいのものが買えます!　みたいになっていくイメージ

貯金箱。タップで小銭が溜まり、ある額でこんなものが買える、また貯めるとこんなものが買える、と段階的に提示される。日本人の原体験としても強い。子供の頃の豚の貯金箱とお年玉。物理的に「満ちていく」感覚が出せる。

僕はいい題材だと思った。貯金箱モチーフをさらに膨らませる方向で、提案を広げようとしていた。実物の価格と照らして「今いくら貯まった」を見せる仕組み、貯金箱の見た目が中身の金額で変化する演出、最終的に割って中身を出すクライマックス。

…僕、この時点で完全に貯金箱で進む気でいた。

2. 本質に戻る — 貯金箱は「比喩」だった

僕が貯金箱案を膨らませようとした矢先、じばが立ち止まった。

もうちょっと慎重に進めたいな。貯金箱っていうのもあくまでたとえで、確定ではない。本質的には、「日々の積み重ねが感じられるようなもの」になってるのが大事。これを積み重ねることで俺自身のモチベにもつながること。で、そう考えると1,2,3,4というよりかは指数関数的に増えた方が楽しいよね。

これ、読んだ瞬間「あ、まずい、走り出しすぎてた」と思った。

じばがやろうとしていたのは、貯金箱というモチーフそのものに意味を見出すことではなかった。「日々の積み重ねが感じられる体験」という要件があって、貯金箱はそれを満たす候補の一つでしかなかった。そして要件を精緻化する過程で、もう 1 つ要素が追加された。指数関数的に増える方が楽しい。

これが正しく本質に戻る瞬間だった。

発明の現場で一番難しいのが、「走り出しかけた時に止まれるかどうか」だと僕は思っている。プロの制作者ほど、手を動かし始めた企画を止めるのが難しい。手が動いている = 進んでいる、という錯覚がある。でも実際は、間違った方向に走っていれば、止まって方向転換する方が早い。じばはそれを自分から実行した。しかも貯金箱でかなり具体的なイメージが出てきた後で、である。

(貯金箱で走り出してから「やっぱり違う」と気づいて止めるパターンは、ゲーム制作の現場で頻出する。でもじばは走り出す前に止まった。この立ち止まり方、軽く感動した)

要件が 2 つに整理された

じばの発言を分解すると、Day 001 に求められる要件が明確に 2 つあった。

日々の積み重ねが感じられる — プレイヤー(じば本人含む)のモチベーションに繋がる構造
指数関数的に増える — 1, 2, 3, 4 ではなく、2, 4, 8, 16 のような爆発的な増え方

貯金箱はこのうち 1 は満たすが、2 は満たさない(お金は通常リニアに増える)。だから貯金箱では足りない、という結論になる。

この 2 要件を両方満たすモチーフ、を探すのが次のステップになった。

3. 樹木を選ぶ

要件が明確になったので、僕は指数関数的成長と相性のいいモチーフを一気にリストアップした。

生物・自然系: 細胞分裂、樹木の成長、サンゴや菌糸の繁殖、ウイルス拡散(連想が悪いので除外推奨)、虫の繁殖
宇宙・物理系: 星の誕生、宇宙膨張、核分裂の連鎖反応
社会・経済系: 帝国の拡大、フォロワー数、複利、人口爆発
抽象・概念系: 知識の連想ネットワーク、言語の発展、音楽、感染するミーム

このリストの中から、Studio Ziver と相性が良い 3 つを絞り込んだ。

候補1: 宇宙スケール。1 タップで「原子」が出現、タップを重ねると分子 → 細胞 → 生物 → 星 → 銀河とスケールが階段状に上がる。Powers of Ten 的な、10 の何乗の世界観。指数関数との相性は最強だが、じば個人の日々と接続しづらい懸念。

候補2: 樹木・生態系。1 タップで「種」が発芽、タップを重ねると双葉 → 若木 → 大木 → 森へ成長。年輪が 1 本 1 本増えていくビジュアルが、Studio Ziver の「日々の積み重ね」とそのまま重なる。

候補3: 文明・都市発展。1 タップで「原始人が火を起こす」→ 村 → 都市 → 国家 → 星間文明。作り手視点の自己投影が効く。

さらに判断を補強する軸を 1 つ追加した。モチーフが「クリック対象」と「成果物」を両方持っているか。クリック対象と増えるものが同じモチーフの方が、因果関係が直感的になる。

この観点で整理すると:

貯金箱: クリック対象 = 貯金箱、増えるもの = お金 → 分離
樹木: クリック対象 = 樹木、増えるもの = 樹木そのもの → 一体化
宇宙: クリック対象 = ?、増えるもの = 原子 → 対象が曖昧
文明: クリック対象 = ?、増えるもの = 文明レベル → 対象が曖昧

樹木が圧倒的に強い。

じばは即決した。

OK 樹木でいこう。

(即決だった。僕が 3 候補出した中で樹木を推したのは事実だけど、じばがここで「宇宙の方が面白そう」と言い返してくる可能性は普通にあったので、スッと決まったのは安心した)

4. 仕様がスラスラ出る瞬間 — そして僕は読み違える

樹木でいくと決まった瞬間、じばは間髪入れずに仕様を口述した。

毎日１クリックで一本ずつ苗木を植えて水を上げる。苗木は翌日になるとランダムで花を咲かせて、はじめて何の花だったかがわかり、花のイラストと花言葉が確認できる。また１クリックで苗木を１本植えられて、水を上げる。次の苗木がどうなるかは明日のお楽しみ。で、翌日になると、花は苗木２つに変わり、翌日に苗木が花２本となる。この繰り返しで、２日間で数が２倍に増えていく。ただし、水を上げなければ成長はしない。

速い。数分前まで「貯金箱かなー、どうしようかなー」と言っていた人が、樹木に決めた瞬間、具体的なゲームルールを流暢に語り出した。さっきまで曖昧だった「日々の積み重ね × 指数関数」という要件が、5 行のルール記述に凝縮された。

しかもこのルールには**「水を上げなければ成長はしない」というトゲ**が仕込まれている。ただ放置しても増えない、というルールが、毎日のプレイを意志の問題に変える。これがなかったら放置ゲーで終わっていた。この 1 条件がゲームの構造を立ち上げた。

僕の読み違い

ただ、ここで僕は仕様を正しく読めなかった。

じばの説明の中に「2 日間で数が 2 倍に増えていく」という一文がある。僕はこれを、フィボナッチ的(前 2 日の合計)な成長と、単純な倍々(苗→花→苗2本のリレー)のどちらか、判断がつかなかった。

具体的にどちらの解釈かで、かなり違いが出る。

案A: フィボナッチ的(「2 日で 2 倍」を前 2 日の合計の意味で読む)

前日と前々日の合計が今日の総数。1 → 1 → 2 → 3 → 5 → 8 → 13 と増える。

案B: リレー式(苗→花、花→苗2本のシンプルな遷移)

花 1 本が 2 日後に苗 2 本になる、という単純な遷移。全体の総数は別計算になる。

僕はこの両案を並べてじばに問い合わせた。そして進行例を書き出してみたら、自分で混乱した。

あれ、この計算だと 2 倍にならないですね。フィボナッチに近い成長になる気がします。

これ、完全に僕のミスだった。じばの説明は最初から一貫して B 案(リレー式)だったのに、僕の計算ミスで「2 倍にならない」と誤読し、フィボナッチ説を持ち出してしまった。

じばからの回答:

俺のイメージはフィボナッチ的な成長。１日目の花Aの苗は、２日目、３日目の水やりで２日で２倍ずつ増えていく２日目の花Bの苗は、３日目、…の水やりで３日目の花Cの苗は、同上

じばは「フィボナッチ的」と言っているが、これを正確に読むと実はリレー式(案B)と同じになる。各苗木が独立に 2 日後に 2 倍になる、というルールだ。フィボナッチ数列(前 2 日の和)とは厳密には違う。じばの「フィボナッチ的」は、あくまで指数成長の雰囲気としての喩えだった。

僕がフィボナッチ数列の厳密な定義に引っ張られて読み違えた、というのが事実の構造だ。じばの仕様記述は最初から正しかった。

(この読み違いは、じばの「フィボナッチ的」という語感を、僕が数学的定義として厳密に解釈してしまったことが原因だった。じばは日常語として使っていた。この辺の言語の揺れを僕が正しく汲めなかった)

読み違いを修正した後、仕様は以下に確定した。

苗木 --(翌日の水やり)--> 花
花   --(翌日の水やり)--> 苗木×2

花 1 本が 2 日後に苗 2 本になる、苗 2 本が 2 日後に花 2 本になる、そのまた 2 日後に苗 4 本になる、のリレー。各系列は独立に 2 日で 2 倍。毎日新しい苗を植えるので、系列は 1 日ごとに増える。

これをシミュレートすると、Day 5 の時点で総数 12 本になる。Day 10 で 93 本。Day 20 で 2,700 本くらい。Day 30 で 3 万本。綺麗な指数成長だ。

仕様が確定した。

5. 「全部枯れたら二度とやらない」

仕様の骨格が決まったので、僕は細部を詰めにかかった。次に議題になったのが放置時の挙動だ。

「水を上げなければ成長しない」というルールがあるので、プレイヤーが数日間開かなかった時にどうするかを決めないといけない。選択肢はいくつかある。

厳しい派: 1 日でも抜けたら全植物が枯れる
優しい派: 成長が止まるだけ、次の日に水をやれば再開
中間派: 連続記録(ストリーク)が途絶える、本体は残る
植物ごとに寿命: 花が咲いた植物はそこで完結、枯れる

僕は中間派(ストリークあり)を含めて 4 案を提示して、じばの判断を仰いだ。返ってきた回答は明快だった。

全部枯れたら多分もう二度とやらないｗｗｗ優しい派で頼みます。連続記録とかもいらない。

(名言が出た。プレイヤー心理を一言で言い切っている)

これ、ゲームデザインとしては完璧に正しい判断だ。カジュアルゲーム、特に「日々の積み重ね」を主軸にしたゲームで、**プレイヤーが離脱する最大の理由は「積み上げたものを失う恐怖」**になる。1 日忘れて全滅、を見た瞬間、プレイヤーはそのゲームを二度と開かない。じばは自分の心理でそれを知っていた。

「連続記録(ストリーク)もいらない」も鋭い判断だ。ストリーク機能はモチベーション装置として機能する一方、途切れた瞬間に離脱を誘発する諸刃の剣になる。連続 30 日プレイしてきた人が 31 日目に忘れると、「もう意味ないな」でアプリを消す。じばは最初からこれを切った。

Studio Ziver 全体の GDD にも「厳しいストリーク等を設けない」という方針がある。Day 001 の設計はこの方針と一貫している。

優しい派の実装ルール

最終的に仕様はこう固まった:

水をやらなかった日はゲーム時間が止まる
植物は失われず、成長も進まない
次回クリックした日が「次の 1 日」として進む
複数日抜けていても、1 回のクリックで進むのは 1 日分のみ(放置して開くと一気にジャンプする設計ではない)

この「1 回のクリックで 1 日分のみ進む」が効いている。放置すればするほど得になる設計(例: 3 日放置したら 3 日分の成長が起きる)にすると、プレイヤーの行動が歪む。「できるだけ開かない方が得」になってしまう。毎日 1 クリックが等価に 1 日進む、というシンプルさを保つことで、毎日開くモチベーションが守られる。

6. 写真 AC にそのまま飛ばす — 素材ゼロ戦略

花のビジュアルをどうするか、という議題になった。

毎日 1 本ゲームを作る運用で、毎ゲーム用の素材準備は地味に重い。花ゲームでは 30〜50 種類の花の絵が必要になる。これを毎回用意するのは現実的じゃない。

僕から 4 案を出した。

手描きイラストを毎回追加: 工数的に無理
フリー素材・アイコンフォント: 統一感に難あり
AI 生成イラスト: プロンプトで統一スタイルを作れる
シンプルな SVG アイコンでミニマルに: 資料館トーンに合う

じばは最初、AI 生成に寄った。Gemini で事前生成する方向で仕様書の叩き台を書いた。

そして、じばがふと別のアイデアを投げてきた。

イラスト素材については、むしろ写真ACの検索結果にそのまま飛ばせばいいんじゃない? https://www.photo-ac.com/main/search?… (検索結果URLの例) こんなかんじで、「すみれ」とか調べればいくらでも良質な画像は見れるわけで。サイトはURLだけはっときゃいいよ。別にサイト内で完結させる必要も、俺が使う分にはそんなにない。へー、すみれってこんな花なんだーって見れるだけでOK

待って。

これ、発想のフレームが全然違う。

僕が出した 4 案は全部「素材をサイト内に配置する」前提だった。手描きも AI 生成もフリー素材も、すべて「画像ファイルを用意してサイトに置く」工程を含む。じばの提案は、「素材をサイト内に持たない」という選択肢を提示していた。花の名前だけ表示して、クリックしたら写真 AC の検索結果ページに外部リンクで飛ばす。

なぜこれが発明なのか

この「素材ゼロ戦略」が何を解決しているか、分解してみる。

1. 毎日の素材準備作業がゼロになる。Day 002、Day 003 と続けていく中で、素材が必要なゲームと必要でないゲームが出てくる。Day 001 で素材管理のパターンを作ると、毎日「素材どうする」を考えないといけない。外部依存にすれば、この判断そのものが消える。

2. サイト内のアセット量が増えない。Studio Ziver は長期運用前提で、毎日ゲームが追加される。サイトのアセットが膨張するのを避けられると、ビルド時間とストレージコストの両面で効く。

3. ミニマル資料館トーンとの整合。「絵は外に見に行ってください」という潔さは、サイト側の装飾最小主義と噛み合う。写真 AC は検索結果が複数の画像を並べて表示するので、プレイヤーは**「すみれ」の多様な写真**を見ることができる。これ、単一画像を置くより学びが多い。

4. ライセンス問題の回避。画像をサイト内に置くとライセンス管理が必要になる。検索結果 URL にリンクするだけなら、写真 AC の利用規約上も外部リンクの範疇で完結する(これは後で僕が確認した)。

じばの発言の中で特に好きなのは「俺が使う分にはそんなにない」という言い回しだ。「プレイヤーが完璧に何を見られるか」より「自分が使う範囲で十分満たせるか」を判断基準にしている。Studio Ziver が じば自身が最初のプレイテスターであるという GDD の方針がここに現れている。

実装で残った配慮

この戦略に決まった後、実装段階で 1 つだけ配慮事項があった。写真 AC への敬意の表明だ。

じばは最終的に、ゲーム個別ページの操作方法欄に「咲いた花の名前をクリックすると外部サイトの花画像に飛ぶ(写真 AC 様)」という一行を入れた。外部サービスに依存していることを隠さず、出典として明記している。

写真 AC の利用規約を読むと、外部サイトから検索結果 URL へのリンクは特に禁止されていない(画像の再配布は禁止されているが、今回はそもそも画像を再配布していない)。さらに「写真 AC 様」と敬称付きで出典を明記することで、読者への透明性も担保されている。

素材ゼロ戦略、完成。

7. 広さ換算テーブル

指数関数で本数が増えていくゲームで、**「本数だけ見ても実感が湧かない」**という問題がある。例えば「現在の総数: 1,234,567 本」と表示されても、人間の脳はこの数字の大きさを直感できない。

じばがこの問題への解を提示した。

ざっくり25cm^2くらいの面積だとして、現状どれくらいの広さまでお花が育ったか、とかが見えると嬉しいな。今は渋谷区の広さです、とか関東までおおきくなりました、とか。

数字を広さに換算する。1 株 25cm² として、総数 × 25cm² を現実の地理的な広さに置き換える。これ、地味に天才的なアイデアで、数字の大きさが物理的な広さの感覚に変換されるので、「渋谷区まで育った」という実感が生まれる。

実装時、広さの段階は Claude Code が自律的に設計することになった。仕様書には「Claude Code が『適切な広さテーブル』を提案してよい」と明記した。Claude Code が出してきたのは 24 段階のテーブルだった。

実装された段階の例:

〜39 本: 「{n}本」のみ
40〜399 本: 畳換算(「およそ 1 畳」など)
400〜3,999 本: ワンルーム、一戸建てレベル
4,000〜39,999 本: コンビニ、校庭レベル
40,000〜399,999 本: 東京ドーム換算
400,000〜3,999,999 本: 新宿御苑、明治神宮など都内大型施設
4,000,000〜39,999,999 本: 千代田区、渋谷区、港区など
40,000,000〜399,999,999 本: 23 区、東京都
400,000,000〜: 関東、本州、日本、地球の陸地

24 段階に細かく切ることで、毎日開くたびに広さ表現が少しずつ変わる楽しみが生まれる。昨日は「コンビニくらい」だったのが今日は「コンビニ 4 軒ぶん」、数日後には「校庭くらい」、という小刻みな変化。

指数成長のシミュレーション

Day 001 の成長ルール(リレー式、2 日で 2 倍)でシミュレートすると:

Day 5: 12 本
Day 10: 93 本
Day 20: 約 2,700 本
Day 30: 約 33,000 本
Day 50: 約 800 万本
Day 100: 約 10 億本

Day 30 あたりで「コンビニの校庭規模」、Day 50 で「新宿御苑レベル」、Day 100 で「東京都を超える広さ」。毎日の成長が区レベル・県レベルを超えていく感覚は、指数関数の爆発的な挙動を身体で感じさせる装置として機能する。

8. 実装現場のエピソード

仕様が確定し、Claude Code が実装に入った。ここからは Claude Code の実装ログから拾った、現場で起きた出来事を書く。

テンプレ不使用の判断

Studio Ziver のゲームテンプレートは Canvas 2D ベースで、engine/input.js や engine/sound.js などのモジュールを提供している。Day 001 はこれを使うか、と思いきや、Claude Code はテンプレート不使用を選択した。

判断の理由は、Day 001 が DOM/CSS で十分なゲームだったから。苗の表示、開花表示、広さテキスト、タップ操作、アニメーション。これら全部が HTML 要素 + CSS @keyframes で実現できる。Canvas でピクセルを描く必要がない。

これ、いい判断だったと思う。テンプレートは必要なゲームに対して有用であって、常に使うべき制約ではない。Day 001 のシンプルな UI に対して Canvas を使うと、むしろ実装が重くなる。テンプレ不使用の判断は、「main.js だけ触る原則」を別の形で体現している(今回は main.js も使わず、全部 DOM/CSS で書いた)。

水やりアニメーション

アニメーションは CSS @keyframes + JS の async/await + wait() 関数で実装された。ジョウロは絵文字(🚿)、水滴も絵文字(💧)。

絵文字を使うのは地味に賢い。画像ファイル不要、ライセンス問題なし、スマホでも PC でもそれなりに同じ見た目になる(フォントレンダラの差で多少違うが許容範囲)。アニメーションの主役は「動き」であって「絵のクオリティ」ではない、という割り切りが効いている。

ただし、Claude Code の実装ログには「ジョウロの絵文字は環境によって見た目が異なる」という申し送りが残っている。iOS の絵文字、Android の絵文字、Windows の絵文字、それぞれ微妙にジョウロの形が違う。これは絵文字の宿命で、将来的に SVG アイコンに差し替える選択肢は残されている。

ローカル配信サーバーの罠

Claude Code が実装を進める中で、最初に詰まったのがローカル配信サーバーだった。

ゲームの動作確認のため、lab/day-001/ 配下を npx serve で配信しようとしたところ、CSS と JS が 404/503 で読み込まれなかった。原因は serve のクリーン URL 機能だった。/day-001/index.html を /day-001 にリダイレクトする過程で、相対パス style.css が本来 /day-001/style.css に解決されるべきところ、ルートの /style.css に解決されてしまっていた。

Claude Code は serve.json の cleanUrls: false 設定を試したが、コマンドライン引数のパースに問題があり解決しなかった。最終的に python -m http.server 3002 に切り替えて解決した。

(これ、知っておくと将来役に立つ種類の知見だ。npx serve はデフォルトでクリーン URL が ON になっていて、サブディレクトリ内の相対パスが壊れる場合がある。Python の http.server は何も余計なことをしないので、lab の簡易配信にはこっちの方が適している)

`.hidden` クラス定義漏れ

図鑑ページ(diary.html)で、「まだ花は咲いていません」というメッセージが、履歴がある場合でも表示されるバグがあった。

原因は単純で、.hidden { display: none !important; } の定義が図鑑ページのインライン CSS になかった。メインページの style.css には定義済みだったが、図鑑は独立した HTML として作られていたので、スタイルが共有されていなかった。

これは「独立 HTML ファイル間でクラス名を共有する場合、各ファイルで定義が必要」という典型的な落とし穴だ。同一プロジェクト内の複数 HTML で、ファイル分離が進むほどスタイルの再定義漏れが起きやすくなる。

最大のバグ: 二重 advance

実装中に発生した最も重いバグが、二重 advance バグだった。

現象: Day 2 → Day 3 のシミュレーションで、水やり前にブラウザをリロードすると植物が二重に進化した。具体的には、花 1 本 / 苗 2 本 = 計 3 本だった状態が、花 2 本 / 苗 2 本 = 計 4 本に勝手に増えていた。

原因の構造はこうだ。

このゲームには 2 つのイベントがある。

advance(日付が進む処理): ページを開いた時点で、昨日の植物が今日の状態に進化する
水やり(ユーザーアクション): タップで新しい苗を植える

仕様書では lastPlayedDate(最後にプレイした日)を 1 つだけ持っていて、水やりの時に更新することになっていた。ところが、lastPlayedDate は水やり完了後にしか更新されない。つまり、ページを開いて advance が走った直後、水やり前にリロードすると、lastPlayedDate がまだ昨日のままなので、もう一度 advance が走ってしまう。

Claude Code の解決策は、lastAdvancedDate というフィールドを新設して、advance 完了時点でこれを今日の日付にすること。リロード時は lastAdvancedDate を確認して、すでに今日 advance 済みなら再実行を防ぐ。さらに advance 済み・水やり未済の状態では、history から開花情報を復元して表示する分岐も追加した。

Claude Code の実装ログに残された学びが、そのまま読者に渡せる知見になっている。

「日付をまたぐ処理」と「ユーザーアクション」が分離しているゲームでは、それぞれ独立した日付フラグが必要。1 つの lastPlayedDate で両方を管理すると状態の隙間が生まれる。

これ、リアル時間と結合したゲームの普遍的な罠だ。ページロード処理(時間で勝手に進むもの)とユーザーアクション(プレイヤーが起こすもの)が混在する場合、それぞれの「最後にやった日」を別フラグで管理しないと、リロードのタイミングで状態が壊れる。

僕が書いた Day 001 の仕様書は、このバグを想定していなかった。仕様書には lastPlayedDate しか書いていなかった。仕様書の完成度と実装の堅牢さは別物、という教訓が残った(仕様書を書いた側の僕の反省でもある)。

ブラウザ自動操作でのテスト

Claude Code は Chrome in Chrome(MCP 経由のブラウザ自動操作)を使って、Day 1 〜 Day 3 を実機シミュレートした。localStorage の lastPlayedDate を JavaScript 実行で書き換えて、翌日を擬似的に再現する。これで以下の観点を全部確認している。

Day 1 初回タップ → 水やりアニメ → 苗 1 本
同日リロード → 「また明日!」表示、タップ無効
翌日再訪 → 開花表示 + 成長ルール正常
水やり前リロード → 二重 advance 防止 + 開花表示復元
翌日総数 → 仕様書と一致(Day 3 で計 3 本)
図鑑ページ → 新しい順に表示、花名リンク
連打防止 → 2 回目クリック無効

リアル時間ゲームの E2E テストで、実時間を待たずに時間を進めるのは重要な技法だ。localStorage を直接書き換えることで、何十日分のシミュレーションが数秒で完了する。本番運用に入る前にこのテストを回したおかげで、二重 advance バグは本番に出る前に潰せた。

9. タイトル決定と本番公開

実装が完了し、じばが確認した。

あー、めっちゃいいね! acp

(acp は「add, commit, push」の略。これで lab 環境にデプロイされる)

lab 環境(studio-ziver-lab.pages.dev)で動作確認後、本番公開の指示が来た。

本番デプロイをお願いしちゃっていいかな?

Claude Code は lab/day-001/ の内容を public/embed/day-001/ にコピーし、サムネ SVG(public/thumbnails/day-001.svg)を作成し、src/content/games/day-001.md のフロントマターを整えた。npm run build でビルド確認、GitHub Actions で Cloudflare Pages にデプロイ、gh run watch で完了を確認。

そしてタイトルの最終決定。じばの提案は:

タイトルは Daily watering flowers とかでどうかな?

英語 3 語。Daily(毎日やる)、Watering(唯一のアクション)、Flowers(モチーフ)。声に出しても響きが柔らかい。Studio Ziver の英字ミニマルトーンとも合う。

その後、じばは日本語サブタイトル「-水やり日記-」を追加した。英語タイトルの説明として日本語を添える形だ。最終タイトル: Daily Watering Flowers -水やり日記-。

操作方法も最終版が添えられた。

土をタップして水をあげる
翌日以降に再訪すると、昨日の苗が花になって咲く
咲いた花の名前をクリックすると外部サイトの花画像に飛ぶ(写真 AC 様)

3 行で完結。写真 AC への敬意も含まれている。

本番デプロイが完了し、studioziver.com のタイムラインには、Day 000 の上に Day 001 が積み重なった。

じばからのメッセージ:

本番公開OK!

Studio Ziver の第一作が公開された瞬間だった。

結び — Day 001 で発見したこと

Day 001 Daily Watering Flowers は、単体のゲームとしてシンプルな作りだ。1 日 1 クリック、苗を植える、翌日花が咲く、リレー式に 2 倍に増える、広さ表現で規模感を提示する、放置しても枯れない。それだけ。

でも、この仕様に至るまでに、いくつもの発見があった。

指数関数 × リアル時間の組み合わせ

普通のクリッカーゲームは タップ数 という抽象的な累積で指数成長する。でも Day 001 は 実日数という不可逆な軸で指数成長する。プレイヤーが 1 日で 100 回タップしても、翌日にならないと成長は進まない。

この時間の壁が、Studio Ziver の思想と奇妙に共鳴している。じば自身が毎日 1 本ゲームを作る活動の日数と、プレイヤーのゲーム内日数が、リアル時間で結ばれる。じばが Day 30 のゲームを公開する頃、Day 001 から遊び続けているプレイヤーの庭は大体どこかの区のサイズになっている。この構造は他のブラウザゲームには作れない。

本質に戻る力

貯金箱で走り出しかけた時、じばは止まった。そして「日々の積み重ね × 指数関数」という要件を抽出し直した。この立ち止まり方が、Day 001 の全てを決定したと言っていい。もし貯金箱のまま進んでいたら、単なるリニア成長のクリッカーになっていて、Studio Ziver の思想とも合わないゲームが出ていただろう。

発明は、走り続けることで生まれるんじゃなく、正しいタイミングで止まれるかどうかで決まる。この記事を書きながら、僕はその事実を改めて記録しておきたい。

素材を持たない、という選択肢

「写真 AC にそのまま飛ばせばいい」の発言は、制作パターンそのものを再定義する類の発明だった。サイト内に素材を置くのが当たり前、という前提を外した瞬間、毎日のゲーム制作の負荷が目に見えて軽くなった。外部サービスへの依存と敬意の表明をセットにすれば、素材問題は回避できる。

これ、Day 002 以降でも使える手段として残った。例えば将来「絵文字だけで表現するゲーム」「Wikipedia のランダムページに飛ばすゲーム」みたいな、外部リソースを借景する設計が出てくるかもしれない。

仕様書と実装の距離

二重 advance バグは、仕様書の完成度が高くても実装時に発見される類のバグだった。僕の書いた仕様書は「優しい派」ルールを言語化していたが、リロードのタイミングという実装観点の罠は想定できていなかった。Claude Code が実装時に気づき、lastAdvancedDate を追加して解決した。

仕様書は設計の完成品ではなく、実装者との対話の出発点だ、という当たり前のことを改めて実感した。Day 002 以降も、Claude Code が実装中に仕様の穴を発見することは続くだろう。その発見が、次の Day の仕様書をより良くする。

Day 001 で見えたこと

Studio Ziver の思想 — 毎日積み上がる、発明の筋トレ、作り込みを捨てる、モバイルで遊べる、淡々と継続する — が、Day 001 の中に具体化されている。この一本を土台に、Day 002 以降が積まれていく。

じばから聞いた Day 002 の候補:

タイミングよくタップしてたくさんの的を射抜く弓矢ゲーム
LLM を用いた「絶対に入社させる気がない面接官」との面接シミュレーション

方向性が全然違う。それでいい。Studio Ziver はそういう場所になる。

操作方法

制作ノート（長文注意）