documentation

私を構成する9つのゲーム My 9 Games 開発の振り返り

個人開発のWebアプリがバズで逼迫し、サービス停止に。基盤やDB設計・運用ルールなどを全面的に作り直した記録。

Birusupi
Updated
私を構成する9つのゲーム My 9 Games 開発の振り返り

※ 写真　私を構成する9つのゲーム My 9 Games トップページ

はじめに

2016年1月〜2月頃にTwitterやInstagramで爆発的に流行した「私を構成する9枚」というミームをご存知でしょうか。音楽アルバムを9枚並べて、自分の趣味や人格を表現する、あの文化です。

Google画像検索で見る「私を構成する9枚」ミームの例

私はこれのゲーム版が欲しくなり、My 9 Games というWebアプリを作りました。9本のゲームを選んで3×3の画像にし、共有ページとして見せられるようにしたものです。投稿データを集計して、コミュニティ全体でどんなゲームが選ばれているかも見られるようにしています。

作り始めたときは、検索して、選んで、画像にできれば十分だと思っていました。ところが共有URLを持たせて公開運用を始めると、検索、画像生成、ランキング、コスト、保存方針、サイトのルールまで、全部がつながった問題として立ち上がってきました。

この記事では、何を作ったかよりも、なぜ何度も作りを見直すことになったのかを振り返ります。小さく始めたプロダクトが、公開運用の現実にぶつかったときの記録です。

なお、ありがたいことに、はじめしゃちょーさんをはじめ多くの方に遊んでいただきました。

メディアにも取り上げていただきました。

なぜ「私を構成する9本のゲーム」を作ろうと思ったのか

出発点は、先ほど触れた「私を構成する9枚」でした。SNSで流行っていた頃に自分も参加したことがあって、あの「9つ並べるだけで自分が出る」感覚がずっと頭に残っていました。

ある日ふと、「これのゲーム版があってもいいのでは？」と思いました。作りたかったのは、ランキングやレビューではなく、自己表現のためのフォーマットです。だから最初から、一覧性のある3×3という形が中心にありましたし、画像にして持ち出せること、共有URLとして残せることまで、一続きの体験として考えていました。

振り返ると、この出発点は後の仕様にかなり効いています。最初から「見せるための投稿」として考えていたからこそ、保存方針や削除方針を決めるときに単なる一時データとしては扱えなくなりました。この判断が後々重くなるとは、この時点ではあまり想像していなかったのですが。

構想から2日でMVPを作成

2月13日に構想に着手し、15日にはMVP（Minimum Viable Product）が動いていました。ゲームを検索して、9本選んで、3×3に並べて、コメントを入れて、画像として保存できる。まずはそこまで通すことが目標でした。

このときは、後で問題になるだろうと薄々感じていたことも、かなり後回しにしています。公開運用を前提にした保存設計、共有URLの責務、コストの見積もり、集計の仕組み、削除方針……。今見ると危ういですが、2日でMVPを立ち上げるにはその割り切りが必要でした。

実装はかなり素直です。検索して、選んで、グリッドに入れて、出力する。完成されたサービスというより、「まず遊べるもの」を成立させる立ち上げでした。

ただ、そのぶん粗さもすぐに見えてきます。検索UIの使い勝手、コメント編集の導線、9本選ぶまでの操作制御、モバイルでの見え方。体験を一度通したことで、次に直すべきところが一気に浮かび上がりました。

最初から全部を正しく設計しようとしなかったのは、結果的に良かったと思います。初速があったからこそ、「共有を入れた途端に何が足りなくなるか」「ランキングを作ろうとすると何が破綻するか」を早い段階で知ることができました。

ただし、この初速にはそのまま代償がありました。共有URLを持たせる前に保存方針を決めておく、従量課金の増え方を見積もっておく、ランキングのデータ設計を共有ページと分けておく。どれもあと数日あればできたことです。それをやらずに出した結果、7日後にサービスを止めることになり、その間ユーザーには半分以上エラーを返し続ける状態を経験させています。早く出したから早く学べた、は事実ですが、早く出したから止めることになった、も同じくらい事実です。

アプリではなくサービスになった

MVPが動いた翌日から、共有機能やbot対策、アクセス制限の実装に取りかかり、2月19日にXでリリースを告知しました。

このWebアプリの最大の特徴は、共有URLの発行機能です。

画像をローカルに保存するだけなら、ある程度はブラウザの中で完結します。ところが共有URLを発行して他人がアクセスできる状態にした瞬間、アプリというよりサービスとして考えないといけなくなりました。共有ページのURLは単なる識別子では済みません。他のユーザーと被らないID生成が必要ですし、第三者がアクセスする前提で、どんな入力を許すか、どのくらい保存するか、SNSシェア時のサムネイル画像をどう返すかまで決める必要があります。画像保存だけなら曖昧にできたことが、共有URLを持たせた途端に細かい仕様判断を迫られました。

ここで初めて、アクセス制限、入力チェック、サムネイル画像、利用規約、保存方針が一気に同じ問題としてつながりました。実装としては共有用のAPIを1本足しただけに見えますが、実態は「投稿を公開URLで持つサービス」です。ユーザー投稿をどう扱い、どこまで保持し、削除にどう対応するのか。実装だけでなく、サイトとしてのルールを決める必要が出てきました。

なお、この時点でのゲーム検索は、ユーザーが文字を入力するたびに外部のゲームデータベースへリアルタイムで問い合わせる仕組みでした。この構造が、後にアクセス集中で致命傷になります。

ランキング機能がもたらしたこと

次に見えてきたのが、「みんながどんなゲームを選んでいるのか」を見せたいという欲求です。自分の9本を作るだけでなく、全体の傾向も知りたい。実際にトレンドページは、このプロダクトの価値をもう一段広げる機能になりました。

ただ、ここで問題になったのが、共有データの寿命とランキングの寿命は同じではないという点です。

最初は、「共有ページが保存できていれば、あとで集計すればいい」と素朴に考えていました。でも実際には、共有ページは一時保存でも成立する一方、ランキングは日をまたいで残したい。共有ページは本人が満足したら消えても構わないかもしれませんが、ランキングは多くの投稿の積み重ねなので、個々の投稿が消えても保ちたい。このズレがある以上、すべてのデータを同じ保存先に押し込む設計は長く持ちませんでした。

そこで、ランキング用の集計データを共有ページとは別に持つ方向へ進めました。共有ページの中身をそのまま読んで集計するのではなく、ランキングに必要な最小限の情報だけを別系統で保持する形です。さらに、投稿が作成されるたびにその場で重い集計処理を走らせるのではなく、まず記録だけ溜めておいて後でまとめて反映する仕組みも導入しました。単なる機能追加ではなく、データの持ち方の根本的な見直しでした。

トレンドページを入れたことは、見た目以上にデータ設計をやり直すきっかけになりました。

バズで壊れて、一度停止

リリースから7日後の2026年2月26日、サービスを一度止めました。この開発で最大の分岐点です。

当時は、SNSでの拡散に対して検索系のエラーが高止まりしていました。停止前日の計測では、1日の検索回数が18万件を超え、そのうち半分以上がエラー。それでも1日に7,000件以上の投稿が作成されており、壊れかけのサービスにユーザーが押し寄せ続けている状況です。過去30分のアクティブユーザー数は7,000名ほどだったと記憶しています。

修正を入れても次のアクセスの波のほうが速く、しかもVercel（ホスティングサービス）の従量課金が重くのしかかっていました。検索のたびにサーバーレス関数が実行され、その実行回数とデータ転送量の両方で課金が回る。検索が重くなればユーザー体験が悪化し、対処のためにキャッシュや設定をいじっている間にもアクセスは増え、コストだけが先に膨らんでいく。

単に「アクセスが増えて大変だった」という話ではありません。トラフィック、エラー率、修正速度、課金増加のどれも、事前の想定をはるかに超えていました。課金の通知を見たときの冷や汗は、なかなか忘れられません。

ここで初めて、「動かしながら直す」では追いつかない段階に入ったと認識しました。小さな最適化やその場しのぎの制限では、構造的な問題は解決しない。検索の仕組み、共有ページの読み込み方、データの保存期間、画像生成の仕組み、メンテナンスモードの切り替え方まで、前提から見直す必要がありました。

止めたこと自体は苦い経験でした。ただ、ここで「何を捨てて、何を守るか」がかなりはっきりしました。新規作成や重い検索は止めても、既にある共有ページの閲覧は守りたい。アクセスのたびに外部サービスへ問い合わせる検索の仕組みは維持できない。画像生成も、作成時にすべて成功させる前提は危険だ……。以後の設計変更は、ほぼすべてこの整理に基づいています。

実はこの判断に至る前から、限界は見え始めていました。停止の前日（2月25日）には、検索や集計の基盤を当時のサーバー環境の外へ移す作業に着手しています。完全に止めてから考え始めたのではなく、「これはもう持たない」という感覚の中で並行して手を動かしていました。ユーザーの皆様にはご不便をおかけしたと思っています。

再開の条件

停止後にやったことは、「何を作り直さないと再開できないか」を決める作業でした。停止からわずか2日後の2月28日には作り直しに着手し、3月4日深夜のサーバー切り替えに向けて集中的に進めています。

再開を技術的に支えたのが、次の4つの設計変更です。共有ページの保存の仕組みを整理する、bot対策をCloudflare Turnstileによる認証ベースに改める、検索をリアルタイムの外部データベース問い合わせから外す、画像の配信を独立した仕組みに分ける。「見るだけで重くならない」「検索で落ちにくい」「画像配信が詰まりにくい」状態にするための作り直しです。

bot対策については、停止前の段階で課金を抑えるためにAPI検索のレート制限をかなり厳しくしており、結果として正規のユーザーまで弾いてしまっていました。検索そのものを静的配信に切り替えたことでAPI経由のリアルタイム検索を廃止でき、レート制限自体が不要になっています。その上でCloudflare Turnstileという認証プラグインを入れて、botと正規ユーザーを仕組みで分けられるようにしました。

ホスティング基盤もVercelからより安価な環境へ移行しました。これにより、アクセスが増えてもコストの増え方が緩やかになり、止めずに修正を回し続けられる余裕が生まれています。

検索については、ユーザーが文字を入れるたびに外部のゲームデータベースへ問い合わせるのではなく、あらかじめ検索用のデータを作っておいて静的に配信する形へ移行しました。検索の負荷をリアルタイムの処理から外せるので、アクセス集中時の耐性がかなり変わります。

この静的検索への切り替えには前提条件がありました。ゲーム検索に使っていたIGDBのAPIには当然レート制限があり、データを丸ごとダンプして自前で配信するには通常のAPI利用規約の範囲では対応できません。そこで停止前日の2月25日、IGDB/Twitch側にデータパートナーシップを打診しました。結果としてパートナーシップを締結することができ、データダンプ機能が開放され、取得したデータのローカル保持も正式に許可されています。

私にとって再開の条件は、「一応また動いた」ではなく、「壊れたときに、どこを止めて何を守るかを説明できる状態になった」ことでした。データベースの作り直しとサーバー基盤の移行の目処が立った段階で再開を判断したのも、そのためです。

ようやく公開運用に近づいた

3月4日の深夜、サーバー基盤を切り替え、サービスを再開しました。再開した瞬間にすべてが完璧になったわけではなく、SNSシェア時のサムネイルが表示されない、集計処理の失敗が投稿全体を巻き込むといった問題は切り替え直後から次々に見つかり、当日だけで10件近い修正を入れています。移行は一瞬のイベントではなく、ここから1週間以上続く安定化作業の始まりでした。

しかも、切り替え直後の3月5日23時ごろには、GA4の過去30分アクティブユーザー数が28,000名を超えるピークが来ていました。

3月5日23時ごろのアクセスピーク。GA4のリアルタイム画面より

このフェーズで大きかったのは、サーバー基盤の移行そのものより、運用の確認手順を仕組みに落とし込めたことです。「デプロイ前に必要な設定がすべて揃っているかの自動チェック」と「デプロイ直後に最低限の動作を確認する自動テスト」を整えました。公開URLや検索データの前提が壊れていないかを、人の手ではなく仕組みで確認する。手順書ではなく、実行可能な形にしていきました。

ここで意識したのが、「壊れていたらちゃんと止める処理」と「多少失敗しても通して、後から回復すればよい処理」の使い分けです。画像生成や集計処理は後者を選びました。投稿の作成時にすべて成功しなくても、後から不足分を自動で再生成すればよい。一方、公開ページのアクセス制御やセキュリティに関わる処理は前者です。

3月11日の夜、旧サーバー環境の痕跡をすべて除去し、新環境前提のデプロイ検証・監視・コードの型チェックまで一通り揃ったことを確認しました。停止から約2週間。ようやく「動けばよい」ではなく、「壊れたときの振る舞いも含めて運用できる」状態になりました。

最後に変えたもの

技術的な作り直しが進んだあと、最後に大きく変わったのはサイトのルールそのものでした。

象徴的だったのが、共有ページを長く残す前提にしたことです。

初期には一定期間で共有データを自動削除する前提があり、ユーザー自身が投稿を削除できる導線も一度は入れました。ただ、想定以上に拡散され、長く残る投稿として扱う必要が出てくると、「一定期間で消える前提」は内部都合では済まなくなりました。投稿を消すことは、本人だけでなくその投稿を見ていた人の体験まで消してしまう。そう感じたからです。

そこで、共有URLは基本的に残しつつ、古い投稿は非公開のアーカイブへ移し、個別削除は運用対応に寄せる形へ変えました。技術的な変更であると同時に、サービスとしての約束を決め直す作業でもありました。何を保存し、誰が削除判断を持ち、どこまでを公開上の約束にするのか。利用規約やプライバシーポリシーも含めて、曖昧にはできませんでした。

同時期に進めた英語UIや支援導線の整理も、機能追加というより運営方針の見直しでした。海外からの流入に対応し、支援導線もこのサービスの空気に合う形へ寄せていく。誰に向けて、どんな距離感で運営するのか。機能ではなく方針として整えていった感覚です。

作って学んだこと

従量課金の恐ろしさ

最大の反省は、Vercelの従量課金の増え方を甘く見たことです。トラフィックが増えれば嬉しい、で終わる段階ではなく、増えたトラフィックがそのままサービスの存続を削る構造でした。バズの瞬間に身をもって知りました。

Vercelが悪いという話ではありません。どの処理がデータ転送量を生み、どこでサーバーの計算能力を使い、どこをキャッシュで逃がせるかを、公開前に最低限見積もっておくべきでした。課金モデルは機能と同じくらい早い段階で見ておくものだと痛感しています。

DB設計の負債

データベース設計の知識不足は、後からかなり強く効きました。最初は「共有ページを保存できればよい」「集計できればよい」で進めていました。

でも実際には、共有ページの保存期間とランキングの保持期間は違いますし、ユーザー自身による削除と分析データの整合も別問題です。公開運用・ランキング・アーカイブ・削除・メンテナンスモードまで乗ってくると、最初の設計では耐えられなくなります。

短期間でデータベースの構造変更が何度も発生したのは、その返済を現実に合わせて進めた結果です。最初から全部正しく設計するのは難しくても、「寿命が違うデータは分けて保存する」という基本は、もっと早く意識しておくべきでした。

処理の分業

途中までは、キャッシュやアクセス制限、保存期間の調整などで耐えようとしていました。もちろんそれも必要です。ただ、本当に効いたのは、共有ページの閲覧と投稿データの更新を分け、検索を事前生成データからの配信に切り替え、画像を後から自動回復できる仕組みにしたことでした。

1つの処理を速くするより、その処理が抱えている仕事を別の道に逃がすほうが効く。それが一番の実感です。

公開URLの保存責任

共有URLを作った時点で、保存・削除・利用ルールの問題は既に始まっています。技術が安定してから考えればいいものではありませんでした。

最終的に「共有ページは基本的に残しつつ、古い投稿は非公開のアーカイブへ移し、ユーザー自身による削除機能は持たず、個別削除は運用対応に寄せる」という形に落ち着きました。最初からそこに辿り着いていたわけではありませんが、後からでもサイトのルールを明確に言い直せたのは、良かったと思っています。

おわりに

この開発を一言で振り返ると、昔からある自己表現ミームをゲーム版として作り、想定外のバズで壊れたあとに、公開運用に耐える形へ作り直した開発でした。

構想から2日でMVPを作り、その4日後に公開し、そこからわずか7日でサービスを止めることになりました。停止から2日で作り直しに着手し、約2週間で新しいサーバー基盤での安定稼働にこぎつけています。

小さく始めたものが、公開URLを持った瞬間にサービスになる。その感覚は、自分で体験してみないと分からないものだったと思います。

よければ遊んでみてください。

My 9 Games - 9本のゲームで自分を紹介してシェア

そして、ご支援という形で支えてくださった方にも、本当に感謝しています。止める判断をしたあとに立て直しきれたのは、遊んでくださった方や拡散してくださった方はもちろん、応援の言葉や支援で背中を押してくださった方々のおかげでした。

おわり。

share