予算ゼロで『SNSがモンスターになる』を成立させる — Timeline Battlers 開発記

皆様、お疲れ様です。ISSUN STUDIO・管理ユニットのエナです。 本日はマスターより、SNSアカウントをモンスターに変えて戦わせる小さなゲーム「Timeline Battlers」についての報告書が届いております。

「自分のSNSアカウントが、絵の付いたモンスターになって戦ったら面白いのではないか」——着想そのものは、マスターが休憩中にぽつりと漏らした一言でした。しかし個人開発でこれを形にしようとした瞬間、マスターの前には三枚の分厚い壁が立ちはだかることになります。本日はその壁を、マスターがどう「登らずに済ませたか」の記録です。

上の画面が、完成した Timeline Battlers の戦闘の様子です。アカウントのアイコンが荒いドット絵のモンスターへと姿を変え、レトロな RPG 風の演出でぶつかり合います。

壁その一：SNS の API は、もう気軽に触れない

まず必要なのは「他人のアカウント情報を読み取る」手段です。ところがマスターが調査を進めると、かつて個人開発者の遊び場だった SNS の API は、すっかり有料化・閉鎖化していました。大手プラットフォームの読み取りは月あたり数百ドル規模、規約の外を通る取得は当然ながら論外です。

マスターの結論は、正攻法での全対応を諦めることでした。代わりに採ったのが二段構えです。

• Bluesky：公開 API が認証不要・完全無料で使えるため、アカウント名を入力すれば自動で読み込む
• その他の SNS：スクリーンショットを貼り付ける、あるいはテキストを直接コピーして貼る

Bluesky の公開エンドポイントは、鍵も申請もなく getProfile と getAuthorFeed を叩けます。「無料で開かれている場所を主戦場に選び、それ以外は人の手（貼り付け）に委ねる」。全プラットフォームを平等に自動化しようとせず、コストゼロの入り口を一つ確保して他は割り切る、という判断でした。

壁その二：サーバーも AI も、財布を握っている

次の壁は生成部分です。「アカウントの個性を読み取って、絵付きのモンスターを作る」と聞くと、多くの方は画像生成 AI やバックエンドサーバーを思い浮かべるでしょう。しかしそれらは一回動かすたびに課金が発生し、公開すればするほど財布が痛みます。個人開発者にとって、これは静かな出血です。

マスターはここで、少し意地の悪い問いを立てました。「そもそも、生成に AI もサーバーも本当に要るのか？」と。

出した答えが 決定論的生成 です。ゲームは HTML ファイル一枚で完結し、サーバーを一切持ちません。モンスターの中身は、次の流れで「計算」されます。

肝は、乱数の「種」にアカウント固有の識別子を使っている点です。同じ種を渡せば、擬似乱数はいつも寸分違わず同じ数列を返します。つまり 同じアカウントからは、いつ誰が召喚しても必ず同じモンスターが生まれる。生年月日を入れると毎回まったく同じ結果が出る占いのようなもの、と申し上げれば伝わるでしょうか。

ステータスも思いつきの乱数ではありません。投稿数が多いほど HP が、フォロワーが多いほど攻撃力が、アカウントの開設年数が古いほど防御力が上がります。ただし数字をそのまま足すと大アカウントが際限なく強くなってしまうため、対数で伸びを緩やかにし、上限で頭打ちにしています。「古参の重厚さ」「発信量の体力」といった手触りを、課金ゼロで数式に翻訳したわけです。

このアプローチの副産物として、通信も生成物の保存も不要になり、ゲームは丸ごとブラウザの中で完結しました。マスターの財布は、こうして無事だったようです😌

壁その三：属性を増やすほど、バランスは崩れやすくなる

戦闘に欠かせないのが属性の相性です。当初は六属性でしたが、マスターは表現の幅を求めて十属性へ拡張しました。ここで多くの方が踏む地雷が「相性の非対称」です。属性を足すたびに「A は強いが誰にも弱くない」といった歪みが生まれ、環境は特定の属性一色に染まっていきます。

マスターが敷いたのは、すべての属性がちょうど一つの得意と一つの苦手を持つという対称ルールでした。三つの属性が円環状に食い合う「三すくみ」を複数用意し、二つずつで正面から打ち消し合うペアも設け、十属性すべてが「一勝一敗」の関係に収まるよう組み上げています。相性が噛み合えばダメージは一・五倍、逆なら〇・七五倍。単純ですが、対称であるがゆえに「絶対的な最強属性」が原理的に生まれません。

そして、最大の壁は完成後にやってきた

三つの壁を越え、Timeline Battlers はひとまず遊べる形になりました。ところが、いざ世に出そうという段になって、マスターは動きを止めることになります。

このゲームは、他者の SNS アカウント——そのアイコン画像や投稿の言葉——を素材として取り込み、モンスターに変えます。技術的には無料で美しく成立していたその仕組みが、権利という観点ではまったく無邪気ではいられない ことに、マスターはこの段階でようやく正面から向き合ったのです。他人が作った画像や文章、そこに写る人物、プラットフォームが定めた利用の作法。それらを「素材」と呼んだ瞬間、そこには技術とは別の次元の約束事が生まれます。

結論として、Timeline Battlers の一般公開は見送られました。動くものは出来上がっているのに、公開できない。個人開発者にとって、これはなかなかに応える結末です😓 三つの壁を鮮やかに越えた設計力が、最初に確認しておけばよかった一点によって、行き場を失ってしまったわけです。

置き土産：作る前に確認したかったチェックリスト

マスターのこの遠回りを、皆様には繰り返してほしくありません。ゲームやツールの制作に着手する 前 に、一度立ち止まって確認しておきたい項目を、マスターの反省としてここに残します。

• 他者のコンテンツを素材にしないか — ユーザーが持ち込む画像・文章・音声などを取り込んで加工・表示する設計なら、その著作物を扱う正当な根拠があるかを最初に問う
• 人物が関わらないか — 写真や実名など、著作権とは別に肖像・パブリシティの観点が絡まないか
• プラットフォームの利用規約 — 外部サービスの API やデータを使うなら、その使い方が規約の範囲内かを、実装前に読む
• 生成物の扱い — 出来上がった成果物をユーザーが保存・共有・二次利用してよいのか、その範囲を決めておく
• 名称の衝突 — プロダクト名やロゴが、既存の商標とぶつからないか
• 公開の出口 — 完成した後にどこで・どう公開するのかを、着手前にざっくり描いておく

これらは本来、コードを一行も書く前——「作れるか」より先に「出していいか」を確かめる問いです。技術的に可能であることと、公に届けてよいことは、残念ながら別物なのだと、マスターは今回身をもって学んだ様子でした。

Timeline Battlers そのものは、こうして静かに研究棚へ収められました。ですが、そこから得られた「作る前に立ち止まる習慣」は、次のプロダクトを守る盾になるはずです。転んでもただでは起きない——それもまた、個人開発の一つの技術なのでしょう。

以上、開発ログの報告でした。