終了ゲームへの思い入れで新アプリ仕様は固まるか

課題
1. この記事でわかること
解決できるようにすること
本文
まとめ

課題

自分はいくつかのモバイルアプリを個人開発していて、その一環で「都市建設×攻め込みゲームを作るための学習ロードマップ」という目標のもと、「学習Track」という技術検証を進めていた。パスファインディングとか、複数ユニットが群れで動く処理とか、戦闘のシミュレーションとか。ジャンルの土台になる技術要素を、1つずつミニアプリとして検証していく取り組みだった。

ただ、Stepを1つずつ進めている間、正直、その全体像をいちいち見返していたわけではなかった。そんな中でふと、「あのゲーム、もう一度自分の手で作れないだろうか」と思った。サービスがとっくに終了している、昔好きだったスマホゲームの話。

「好きだったから作りたい」という気持ちだけでは、当然ながらアプリの企画にはならない。思い入れは動機にはなっても、仕様書にはならない。それに、そもそも自分が目指しているものの全体像を、ちゃんと把握できていたのかも怪しかった。ここから実際に「作れる形」まで持っていくには、何をどう詰めていけばいいのか。

この記事でわかること

サービス終了した好きな製品を「作り直したい」と思ったときの、企画の始め方の一例
もともと計画していた技術検証を、具体的な新企画の仕様へ落とし込んでいく考え方

解決できるようにすること

漠然とした目標のまま進んでいた技術検証を、AIとの対話を通じて少しずつ具体的な仕様（名称、経済システム、戦闘の仕様など）へ変換していく手順が分かるようになる。

ここまで読んで、こう思う人もいるかもしれない。

「思い入れだけで、本当にアプリの仕様なんて決まるの？」

実は、決まる。ただし決め手になったのは思い入れそのものより、その後にAIと1つずつ積み上げた地道な確認作業のほうだった。

本文

実は、最初から目標はあった

学習Track（技術検証のためのミニアプリを1つずつ作っていく取り組み）には、実は最初から「都市建設×攻め込みゲームを作るための学習ロードマップ」という明文化された目標があった。ただしそれは別の場所に置いていたメモ1つにしか残っておらず、実際に手を動かす作業場所には引き継がれていなかった。だから、序盤のStepを進めている間、その全体像をいちいち見返しながら作業していたわけではない。

「このジャンルへ展開するのに必要な技術を、ちゃんと先取りできているのか」。ふと気になって確認を頼んだところ、AIが元のメモを読み直し、「目標は最初から明文化されていたが、実際の作業では参照されないまま埋もれていた」と報告してきた。「決めていたはずなのに、見失っていたのか」というのが正直な感想。目標自体は明確だったので、その場で自分たちの計画書に正式に書き写した。この見直しの過程で、初期Stepの「タップで目的地指定」という操作方式が、最終形で想定している「敵が自律的に街を目指す」とは違う暫定インターフェースだったことも判明した。

あのゲーム、もう一度作れないか

目標を仕切り直したあと、この抽象的な計画に、もっと具体的な手触りを与えたくなった。きっかけは単純で、「リトルノア」というスマホゲーム（2015年から2019年まで配信されていたRTS系のゲーム）が個人的に気に入っていて、「復活させたい」という思い入れがあった。

ただしキャラクターの絵柄や世界観をそのまま真似ることはできない。そこは当然の話。なので、狙いは「ゲームシステムを再現しつつ、今の自分だからできる付加価値を足して、正式にアプリとしてリリースする」という方向に決めた。

まず調べたのは「なぜあのゲームは終わったのか」

思い入れだけで突っ走らず、AIに手伝ってもらって当時のゲームシステムと、サービス終了に至った経緯を調べてみた。

拠点の構築、ユニットをタップで配置すると自動で動いて戦うバトルの流れ、対人要素。ここまでは「懐かしいな」で済む話。でも気になったのは終了の理由のほうで、外部の記事によると、ストーリーが弱くて世界に入り込む実感が薄かったこと、施設のレベルアップ待ち時間が長くて課金を迫られる圧力が強かったこと、ランキングが実質「課金額・時間投資ランキング」になっていたこと、技術的な不安定さ、チュートリアル不足あたりが指摘されていた。

「あ、これは結構ちゃんとした構造的な問題だったんだな」と思った。なかでも皮肉に感じたのが、「ガチャが無い＝無課金でも公平」という、本来なら美点のはずの特徴が、結果的に運営側のマネタイズを弱くしてしまった可能性がある、という指摘。良いところが弱点にもなり得る、というのはちょっと考えさせられる話だった。

学習Trackの各Stepが、そのままリトルノアに使えた

ゲームシステムを調べ終えたところで、改めて学習Trackの各Stepを見直してみた。すると、リトルノアに必要な技術要素とほぼ1対1で対応することが分かった。生産施設の放置生産、街並みの構築、施設のレベルアップ演出、タップで配置すると自動で移動して攻撃する仕組み、複数ユニットの同時召喚、防衛施設と攻め込みユニットの戦闘。もともと「都市建設×攻め込み」という広い目標に沿って進めてきた技術検証が、リトルノアという具体的なゲームに当てはめても、そのまま使える形になっていた。

「ゼロから全部作らないといけない」と身構えていたわけではなく、「目標どおりに積み上がっていたことが、具体的な参考ゲームで裏付けられた」という感覚のほうが近い。しかも、既存のアプリで実績のある「オフライン蓄積上限に達したらレワード広告で時短できる」という収益化の型が、リトルノアの弱点（ガチャが無くてマネタイズが弱い）を補いつつ、強み（無課金でも公平）を壊さずに済むかもしれない、という組み合わせにも気づけた。

世界観をゼロから作り直す

リトルノアの舞台は「方舟」で、これは宗教的なモチーフが入っているので、そのまま真似るのは避けたかった。代わりに選んだのが、今のファンタジー作品でよく見かける「ダンジョンコア」という類型。主人公が過去に手に入れたダンジョンコアを、ただの大きな岩に埋め込んだのが空中都市の始まり、という設定にした。

この設定を作ってから面白い発見があった。「ドワーフが掘っても掘っても尽きない鉱脈」とか「主人公のレベルが上がるほど施設を置ける面積が広がる」といった、実はすでに実装済みだったゲームの仕組みが、この世界観でちゃんと説明できるようになったこと。後付けの設定のはずが、既存の仕組みの意味付けまで兼ねてくれた。

ただし、ここは慎重になった部分でもある。「尽きない」という設定はあくまで世界観上の言い回しであって、実際の数値設計まで文字通りの無限にはしない。既存アプリで確立済みの「途中までは有限の上限、そこから先は伸び幅を抑えた緩やかな成長」というパターンをそのまま踏襲することを、ここは念のため確認しておいた。

「攻める」だけじゃなく「守る」も必要だと気づいた

技術検証のStepは、自分のユニットが敵の拠点を攻めに行く方向でずっと考えていた。でも、実際のゲームを組み立てているうちに、「あれ、自分の都市が逆に攻め込まれる場面も要るのでは」と気づいた。

物語のつじつまも考えた。「モンスターや悪い魔術師の街を討伐して回っている主人公への、報復」という位置づけにすれば、攻める理由と守られる理由が1本の筋でつながる。一方的に嫌がらせされているのではなく、討伐して回っているから、たまに反撃を受ける、という自然な流れになる。

これは技術的にも地味に効いた発見で、「敵の防衛施設を攻略する」ための戦闘シミュレーションは、実は「自分の防衛施設が迎撃する」場合にもそのまま使える汎用的な作りにしておく必要がある、と分かった。1つの技術検証Stepの完了条件を、後から書き直すきっかけになった発見だった。

対人戦は、あえて今回は見送った

リトルノアの中核要素だった「他プレイヤーの拠点を襲う」非同期対戦は、今回は最初から見送ることに決めた。

理由は2つ。1つは、バランス調整で考えないといけないことが単純に多すぎること。もう1つは、他人の都市を壊すことに納得感のある理由を付けるのが難しいこと。対人戦を外せば、マッチングやデータ同期、不正対策といったサーバー側の仕組みが要らなくなり、これまで検証してきた技術だけで完結できる、小規模開発向きの現実的な範囲に収まる。将来的に追加する余地は残しつつ、今回は「まずは自分対NPC」で割り切ることにした。

既存アプリのキャラを出演させる

個人開発している2本のパズルアプリ「晶脈録」（鉱石を集めて消していくパズルゲーム）と「月灯り調合所」（ポーションを調合するパズルゲーム。どちらも執筆時点ではApp Store審査中で、まだ一般公開はしていない）のブランドキャラクターを、この新しいゲームにも出演させることにした。「知っている人はそこも楽しめる」という狙い。

このとき、既存アプリで決めていた「顔や横顔は描かず、必ず後ろ姿で表現する」というブランドの約束事は、新しいゲームでもそのまま引き継ぐことにした。ここを崩すと、既存アプリとの一貫性が失われてしまう。

「オリジナルキャラを1人作るたびに専用のミニアプリまで作るべきか」という論点も出てきたが、これは結局見送った。代わりに、まだ着手していなかった技術検証のStep（群集AIと戦闘シミュレーション）を、そのまま新しいオリジナルキャラのお披露目会場として使うことにした。技術検証とキャラクターの登場を同時にこなせるので、一石二鳥という判断。

出演させるキャラの比率についても、あらかじめ原則を決めておいた。「既存アプリからのクロスオーバーキャラは、あくまでボーナス的な追加要素であって、ゲームの土台にはしない」というもの。理由は3つ。装飾を外しても独自性が残る状態を保ちたいこと、他のアプリとの結びつきを強くしすぎないこと、そして「クロスオーバー要素を無理やり埋めるために逆算でキャラを後付けする」というやり方を避けたかったこと。クロスオーバーキャラが1人もいなくても、このゲームとして成立する状態を常に保つ、という原則。

名前が決まる: Nestria

企画を積み重ねていく中で、この都市育成×攻め込みゲームの正式名称を「Nestria（ネストリア）」に決めた。「居場所・巣」を意味するNestを核に、「物語・歴史」の余韻を残すStory/Historyと、地名っぽい響きの-iaを組み合わせた造語。サブタイトルは「浮かぶ世界の開拓録」とした。

数字を1つずつ、AIとの一問一答で詰めていく

ここから先は、かなり地道な作業だった。魔力という資源をどのくらい持たせるか、回復にどのくらい時間をかけるか、戦闘や施設の強化にどのくらい消費させるか。1つの数字を決めるたびに、次の関連する数字が決まっていく、という一問一答の繰り返し。

たとえば「最大魔力は100、フル回復に5時間」という数字は、「1日3〜4回チェックインする遊び方」という前提から逆算して決めた。魔力を結晶に変える仕組みの額面（100→500→2,500→12,500）も、主人公のレベルアップに合わせて段階的に解放する形にした。戦闘の仕様、Questの仕様、データの保存方法も、同じように1つずつ確認しながら積み上げていった。

正直、この作業だけを取り出すと地味そのもの。でも、もともとの計画に思い入れで具体性を与えた企画が、こういう細かい数字の積み重ねを経て初めて「実際に作れる仕様」になっていくんだな、というのは実感として残った。

審査リスクは「世界観の見た目」だけで判断しない

既存アプリの1本が、実際にApple App Storeの審査で「他のアプリと似すぎている」という理由で却下された経験があった。この経験から、「提出前に自分でチェックする6条件」という基準をすでに作っていたので、これを新しい企画にも予備的に当てはめてみた。

ここで気づいたのが、「世界観が似ているアプリがあるから審査に落ちる」という理解は正確ではない、ということ。実際に問題にされるのは「型にはめて量産しやすく、似たアプリがストアに極めて多いジャンルで、仕組みそのものの差別化が無いこと」であって、世界観の見た目が似ているかどうかではない。

念のため競合を調べてみたところ、名前だけ似ている別のアプリが1本見つかった。ただし中身を確認すると、そちらは純粋な防衛特化型のゲームで、都市運営や複数キャラのクロスオーバーといった要素は無く、名前が似ているだけで中身は別物と確認できた。今の時点で大きな赤信号は無いが、正式な判定は実際に提出する前に、あらためてきちんとやる必要がある。

まとめ

2026年9月2日時点で、このNestriaという企画はまだ構想段階。技術検証のStepはかなり進んだものの、Nestria自体の実装にはまだ着手していない。次に判断すべきタイミングは、残っている技術検証Stepが完了した時点で、正式にストアへ出すかどうかを改めて相談すること、というところまで決まっている。

もともと計画していた技術検証に、「好きだったゲームを作り直したい」という思い入れで具体的な参照点を与えた話が、目標の掘り起こし、調査、技術検証との突き合わせ、世界観の作り直し、キャラクター構想、細かい数字の積み上げを経て、ここまで具体的な形になった。振り返ってみると、思い入れそのものよりも、その後の1つずつの詰め作業のほうが、実際には時間もボリュームも大きかった。

項目	内容
結論	もともと計画していた技術検証に、終了済みゲームへの思い入れで具体的な参照点を与え、AIとの一問一答で新企画の仕様へ変換できた
教訓	明文化したはずの目標も、実行中に参照する仕組みが無いと埋もれてしまう。定期的な見直しが「決めていたのに見失っていた」を防ぐ
対象読者	個人開発でモバイルアプリ・ゲームを作っている人、思い入れのある既存作品からの着想を形にしたい人

同じ状況に陥ったときの回避策