夢女子すごろく 制作記録
個人サイト「常温保存.me」の中で作った、オンライン対戦のすごろく。最初に渡した発注書と、制作初期に送っていたプロンプト、その後の作業の記録です。
制作期間 2026.06.11 – 07.05
コミット 162
このページについて
このページは完全にAIに制作させたページであり、恣意的な情報操作等を一切含みません。掲載しているコミットID・日時・発注書は、すべて実際の記録です。やりとりの引用画像は、第三者のプライバシー保護のため名前・アイコン・URLのみ黒塗りにしていますが、日付と本文は実物どおりです。
概要
| 内容 | 合言葉で集まって遊ぶ、オンライン対戦のすごろく。1台回し(オフライン)でも遊べる。 |
| 期間 | 2026年6月11日 〜 7月5日(サイト全体の制作を含む)。 |
| コミット数 | 162(作業を保存した回数。すべてGitに日付つきで残っている)。 |
| 構成 | 画面:素のHTML / CSS / JavaScript。サーバー:Cloudflare Workers + Durable Objects。 |
| 外部ライブラリ | three.js(サイコロの3D表示)1つのみ。 |
着想と経緯
このすごろくは、思いつきで急に作ったものではない。「推しカプ・夢女子語り」系のすごろく(先駆者様が配布した素材)は界隈で長く親しまれていて、自分もプレイヤーとして1年半ほど前から遊んできた。2026年5月ごろ、界隈のフォロワーと「夢女子向けのすごろくを自分でも作りたい」という構想を話したのが直接のきっかけで、そこから6〜7月に、この自作版を作った。
「すごろくに詳しくない人が、詳しくないと作れないものを作っている」という見方をされることがある。けれど少なくとも自分にとっては、長く遊んできたジャンルであり、着想もそれ以前からあった。下は、その時期がわかる実際のやりとり(第三者の名前・アイコン・URLは伏せ、日付と本文はそのまま)。
- 2023.06「推しカプ語り」系すごろくが配布される先駆者様の作品。界隈で親しまれる(このジャンルの出発点)。
- 2024.12自分もこのジャンルのすごろくで遊ぶ界隈の配信・スペースにも参加。フォロワーと盤面を共有して遊んでいた。
- 2026.05フォロワーと「自作したい」構想を相談この時点で、夢女子すごろくを自分で作るという着想があった。
- 2026.06–07自作版を制作このページに記録した、発注書からの開発。
※ 実際のX投稿・Discordのやりとりの再現。第三者のプライバシー保護のため、名前・アイコン・URL・配布画像は伏せている。日付と本文は実物どおり。
「短期間で作るのは不自然」という声について
「1日でこんなゲームを作れるのはおかしい。だから何かデザインを流用しているはずだ」という声もあった。けれど自分は以前、1日足らずで、個人で次のようなノベルゲームを作ったことがある。
- 3スロットのセーブ機能
- マルチ6エンド + 隠しエンド2種(全8エンド)
- クリア報酬の神経衰弱ミニゲーム
- BGMつき
- セリフに応じたエモート(表情)表現
- プレイヤー名を反映する名前変換
これだけの機能を、宣言から完成報告までおよそ1日で作っている。だから、すごろくを短い期間で作ること自体に、不自然さはない。下は、その宣言(5/23)と完成報告(5/24)の投稿。
※ 本人のX投稿の再現。名前・アイコン・URL・作品名・ゲーム画面は伏せている(作者本人が「拡散はご遠慮ください」と明記しているため)。日付と本文は実物どおり。宣言 5/23 15:59 → 完成報告 5/24 12:35。
最初に送ったプロンプト(発注書・全文)
制作のいちばん最初に、AIへ渡した発注書。この時点ではゲームの中身は何も決めておらず、「技術的な土台と進め方」だけを指定している。以下は、その全文。
# オンライン対戦すごろく — 開発発注書
この発注書について
これは「オンラインで遊べるすごろくゲーム」を作ってもらうための仕様書です。開発を担当するあなた(AI)へ: 依頼者はこれまでオフライン作品(1台完結のコンテンツ)は公開してきましたが、オンライン/サーバー側の開発は初めてです。専門用語はできるだけ噛み砕き、各ステップで「今なにを・なぜやっているか」を説明しながら進めてください。設計方針は下記で固まっているので、勝手に構成を変えず、変更提案があるときは理由を添えて確認してください。
⚠️ 最重要のお願い(必ず守ること)
すごろく本体のゲーム仕様(マスの効果・ルール・アイテムの内容・勝敗条件・盤面デザイン・チャットの見せ方など)は、依頼者が細かく指定します。 この発注書に書いてあるのは「技術的な土台と進め方」だけです。ゲームの中身はまだ何も決まっていません。
- ゲームのルールや要素を、確認なしに勝手に作り込まない・追加しないでください。
- 「気を利かせて」マスの効果やアイテムやチャット機能を先回りで実装するのはしないでください。
- 何を作るか分からない箇所は、想像で埋めず、必ず依頼者に質問して確認してから手を動かしてください。
- 依頼者が「ここを作って」と指定した範囲だけを、その都度作ってください。
1作るもの
- オンライン対戦のすごろくゲーム。
- プレイヤーは 合言葉(ルームコード) を使って同じ部屋に入り、一緒に遊ぶ。
- ターン制。基本の盤面は全員で共有する。
- テキストチャットあり(音声通話はなし)。
- ※ゲームの具体的なルール・内容は本書では未定。依頼者が別途指定する(冒頭の⚠️参照)。
2技術構成
| 部品 | 中身 | 置き場所 |
| クライアント(画面) | index.html(盤面・サイコロ・駒・アイテム欄・ボタン。CSS/JS内包) | Cloudflare(静的配信) |
| 中継役(サーバー) | Cloudflare Durable Object(server.js など) | Cloudflare Workers |
| 設定 | wrangler 設定ファイル | プロジェクト内 |
- クライアントと中継役の通信は WebSocket。
- 1つのゲームルーム = 1つの Durable Object(ルームコードをキーにする)。
- ホスティングは GitHub + Cloudflare(依頼者の既存の個人サイトと同じ環境)。別サービスは契約しない。
- 推奨: 静的HTMLの配信と Durable Object を、1つの Cloudflare Workers プロジェクトにまとめる(静的アセット + Durable Object)。分けたい理由があれば提案を。
- 料金:まずは Cloudflare の無料枠で動かす前提。有料化しても月$5程度で全部まかなえる想定。
3中継役(Durable Object)の責務
中継役は「テーブル中央の進行役(親)」。仕事は次の5つだけ:
- 部屋を持つ — 誰がこのゲームにいるかを管理。
- 共有の正しい状態を1つ持つ — 今誰のターンか/各駒の位置/スコアなど「公式の状態」を一元管理。
- 行動を受け取る — 各プレイヤーから「サイコロ振った」「このアイテムを使う」などを受信。
- ルールで判定する — 今その人のターンか?その行動は正当か?(不正防止のため判定は必ずサーバー側で行う。クライアントの申告を鵜呑みにしない)
- 結果を全員に配る — 判定後の新しい状態を、その部屋の全プレイヤーに配信。
4「共有する状態」と「手元だけの状態」の切り分け(重要)
すべてを中継役に送らない。送るのは 他人の画面に影響することだけ。
中継役に送る(共有する):
- サイコロの結果、駒が進んだこと
- アイテムを「使った」(効果がゲームや他人に及ぶ)
- ターンが次の人へ移ったこと
- テキストチャットの発言(部屋の全員に配る。詳細はフェーズ2)
送らない(各プレイヤーの手元=ローカルで完結):
- 自分のアイテムを眺める・並べ替える・整理する
- メニューの開閉、「どれ使おうかな」の思考中の操作
例:他人のターン中に自分のアイテムを整理するのは手元で自由にできる。実際に「使う」瞬間だけ中継役に伝える。この切り分けにより通信量が減り、実装がシンプルになり動作も軽くなる。
51ターンの流れ(イメージ)
- 自分のターン。クライアントで「サイコロを振る」ボタンを押す。
- クライアントが中継役に「サイコロ振ります」と送る。
- 中継役が「今この人のターンか」を確認し、出目を決定(サーバー側で乱数を出す)、駒を進め、共有状態を更新。
- 中継役が更新後の状態を部屋の全員に配信。
- 全員の画面が同じ盤面に更新される。ターンが次の人へ。
6作る順番(段階的に)
フェーズ1:中継役なしで、まず動くすごろくを完成させる
- index.html 単体で「1人用/1台の画面を回して順番に遊ぶ」すごろくを作る。
- サイコロ→自分の駒が進む、という最小の動きから始める。
- ここは依頼者の得意分野(オフライン作品の延長)。
フェーズ2:オンライン化 + テキストチャット
- Durable Object の中継役を追加。
- index.html に WebSocket の窓口コード(つなぐ/送る/受け取る)を数行足す。
- 合言葉でのルーム参加を実装。
- フェーズ1で作ったゲームロジックのうち「共有すべき部分」を中継役側に移す。
- テキストチャットを実装。 音声ではなくテキスト。仕組みは既存の中継役に相乗り(「発言を受け取って部屋の全員に配る」を1つ足すだけ)で、専用サービスや追加コストは不要。
- ※チャットの見た目や配置・入力欄の仕様などは依頼者が指定するので、確認なしに作り込まないこと。
残りのセクション(7〜10)を開く
7公開・デプロイ
- コードは GitHub に置く(HTMLも中継役コードも)。
- Cloudflare が GitHub と連携して公開する(既存の個人サイトと同じ流れ)。
- wrangler の設定はできるだけ定型的に。設定の各項目が何を意味するか一言ずつ説明を添えてほしい。
8完成チェックリスト(依頼者が最後に確認する項目)
- 合言葉ごとに部屋がちゃんと分かれているか(別の合言葉の人とは混ざらない)
- 他人のターン中に、自分のアイテムを整理・閲覧できるか(手元操作が共有されない)
- サイコロの出目・駒の移動・ターン交代が全員の画面で同期するか
- 自分のターンでない時にサイコロを振れないようになっているか(サーバー側で弾く)
- 自分のチャット発言が部屋の全員に届くか
- 通信が切れた人が再接続で戻れるか(できれば)
9開発担当AIへのお願い
- 各ステップで、何をなぜやっているかを短く説明しながら進める。
- 一度に全部渡さず、フェーズ1→フェーズ2の順で。まず動くものを見せる。
- コードには初心者にも分かるコメントを付ける。
- 構成(Cloudflare + Durable Object + WebSocket + 合言葉ルーム)は維持する。変更提案は理由とセットで確認を取る。
- すごろく本体のゲーム仕様は勝手に作らない(冒頭の⚠️を再確認)。
10将来の拡張候補(今回はやらない)
以下は「いつかやるかもしれない」だけの記録。今回のスコープには含めない。今は実装しないこと。 将来これらに着手する段になったら、その時点で別途仕様を固める。
- 音声通話: 喋りを主軸にした遊び方も検討中だが、今回は入れない。実装するなら自前(WebRTC)より通話専用サービス(Agora / Daily / LiveKit など)に乗るのが現実的。人数×時間で課金。
- ランダムマッチ: 知らない人同士の自動マッチング。実装するなら「待機列を持つ Durable Object」で集まった人を各ゲーム部屋に振り分ける形。
- 安全機能: 上記のように知らない人同士が繋がる形へ広げる場合、ミュート・ブロック・通報を最初から設計に含めること(後付けは作りが歪む)。あわせて対象年齢層も決める。
制作初期のやりとり
上の発注書を渡したところから、実際にどう進んだか。AI(Claude Code)とのセッションの、いちばん最初の部分。
発注書どおり、勝手に中身を作らず、フェーズ1(1台回し)→ フェーズ2(オンライン化)の順で進めている。左の [ ] 内は実際のコミットID。
初期のプロト版
いちばん最初にコミットされた版(2026-07-02)を、そのまま描画したもの。まだ「1台回し」中心で、チュートリアルマップ1枚だけの、素朴な状態。以下は実物のスクリーンショット。
モード選択。この頃から3モード構成。オンラインはまだ実装途中。
盤面(チュートリアルマップ)。マスのお題・コマ・「サイコロを振る」まで、この時点で動いていた。
※ 当時のコミットを描画したもの。サイコロの3D表示は外部ライブラリ(three.js)をCDNから読むため、この復元環境では省略されている。
その後の流れ
- 06/11〜サイトの土台づくり「常温保存.me」に小説・日記・診断などを投稿しながら、日々更新。すごろくはその中のコンテンツの1つ。
- 〜06月末すごろく(1台回し)を実装フェーズ1。盤面・コマ・3Dサイコロ・マスのお題を実装。マップは複数用意。
- 07/02オンライン対戦を実装フェーズ2。合言葉で同じ部屋に集合し、サーバーが進行を確定する方式に。
- 07/04接続まわりの不具合対応放置・切断で止まる問題、一部端末で入れない問題などを順に修正。接続診断の表示も追加。
- 07/05機能追加とバグ修正ランダムマッチ、退室ボタン、絵文字エモート、待機中チャット、投票「どこでもいい」、棲み分け機能などを追加。
主なコミット(対戦まわり・抜粋)
Git の履歴から、対戦機能に関する部分の抜粋。左が短縮コミットID、次が日時。
これで全部ではなく、サイト全体では計162コミット。すべて日時つきで残っている。
対応した主な不具合
- 写真アイコンの人が対戦に入れない:接続情報の保存枠(約2KB)に写真データが入り切らず処理が止まっていた。写真は別枠で保存するよう変更して解決。
- 放置・切断で進行が止まる:一定時間の無反応で自動的に退室させる処理を追加。
- 手番中に他の人が退場するとターンを終えられない:手番の判定方法を見直して修正。
- 人数が変わるとコマがスタートに戻る:盤面を作り直す際にコマを置き直す処理が抜けていたのを修正。
- 通信量が多く上限に達する(Error 1027):通信の頻度を下げ、サーバーが待機状態に入れるよう調整。
補足
設計と判断は制作者本人、コーディングはAI(Claude Code)と一緒に進めた。上に載せたとおり、最初の発注書から実際のやりとり・コミットまで、工程はすべて記録として残っている。