
重力と、AI開発と、マネタイズの期待値について
週末に、AIとの対話だけでブラウザゲームを1本作った。
人間が書いたコードは0行。Claude Fable 5がコードを生成し、私はテストプレイとフィードバックだけを担当した。プレイ可能なプロトタイプまでは約1日だった。
ただし、公開版はそれで完成ではなかった。
その後GPTに実装と記事草稿をレビューさせると、実装説明の誤りと、最終面の周回判定にある抜け道が見つかった。最終的にはGPTで修正し、描画とエンディングも強化して公開した。
この記事は、その制作記録と「で、これは金になるのか」という話。
作ったもの
THE LAST LETTERは、滅びる地球から人類最後のアーカイブ「手紙」を送り出す重力パズルだ。
操作はドラッグ1回だけ。初速を与えたら、あとは重力がすべてを決める。
全7レベルで、それぞれ異なる軌道力学の考え方を使う。
- 地球の周回軌道
- 月への遷移
- 火星への惑星間航行
- 木星スイングバイ
- 連星間の通過
- 中性子星での大角度旋回
- ブラックホールの事象の地平面
クリアするたびに手紙の1行が明かされ、7行が揃うと物語が完結する。
ゲームはこちらからプレイできる。
技術的な中身
単一HTMLから始まった小さなブラウザゲームだが、物理と描画は単なる演出だけではない。
宇宙船の運動は、複数の天体から受ける重力を合算して計算している。天体自体は設定された軌道上を動き、宇宙船側を10サブステップで積分する制限N体シミュレーションだ。
当初は「全ペアN体シミュレーション」と説明していたが、GPTのレビューで不正確だと分かった。天体同士は相互作用せず、宇宙船から天体への反作用もない。実装に合わせるなら「複数天体の重力場を移動するテスト粒子」に近い。
レベル4では、vis-viva方程式を使って初速上限を設定した。ゲーム内の初速だけでは土星へ素直に遷移できず、木星へ接近して進行方向と太陽基準の速度を変える必要がある。公開版では木星のアシスト圏を通過したこともクリア条件として記録している。
ブラックホールの描画
最終面のブラックホールはWebGLのフラグメントシェーダーで描画している。
画面の各ピクセルから光線を飛ばし、シュヴァルツシルト時空を模した近似式を120ステップ積分する。Canvas 2Dで描いた背景の星や宇宙船をテクスチャとして渡すため、ブラックホールの周囲では背景そのものが重力レンズで歪む。
降着円盤には、次の表現を入れた。
- 円盤の回転と乱流
- 観測者へ近づく側が明るくなるドップラービーミング
- ブラックホール付近の重力赤方偏移
- 円盤の向こう側が上下へ回り込む二次イメージ
- 複数の細いフォトンリング
描き込んだブラックホール画像を置いているわけではない。ピクセルごとの計算結果として描画している。
天体も平面画像を丸く切り抜いただけではなく、プロシージャルに生成したテクスチャを球面へ投影している。地球の大陸や雲、火星の地形、木星の縞と大赤斑、土星の環を生成し、光源方向に応じた昼夜境界、反射、周縁減光、大気光を重ねた。
一番面白かったバグ
最終面は「ブラックホールの周囲を1周してから落とす」のが目標だ。
ところが最初の実装では、周回軌道に乗ると永遠に周回するだけで落ちなかった。
ニュートン力学では、外部からエネルギーを失わない限り軌道は自然に減衰しない。「1回しか押せない」というルールと、「1周してから落とす」という目標が物理的に矛盾していた。
物理シミュレーションが素直に動いた結果、ゲームが成立しなくなった。
修正の着想は一般相対論から借りた。回転していないブラックホールでは、約3シュヴァルツシルト半径より内側に安定した円軌道は存在しない。これはISCOと呼ばれる。
ただし、ゲーム内で一般相対論を厳密に再現しているわけではない。ISCOの性質をゲーム用に単純化し、一定距離より内側では速度が少しずつ失われ、軌道が螺旋状に崩れる処理を入れた。
これによって、ブラックホールの光に沿うように手紙を投げると、周回後に自然に落ちていくようになった。
レベル名は THE LETTING GO。
バグ修正が、そのまま演出になった。
GPTのレビューで見つかった、もう一つの問題
物理的な矛盾を直したあとも、コード上には別の問題が残っていた。
ゲーム内では「1周」と表示しているのに、クリア判定は2ラジアン、約114度に設定されていた。1周に必要な角度は約6.28ラジアンなので、実際には3分の1ほど回れば100%になっていた。
さらに角度の変化を絶対値で加算していたため、同じ場所を往復しても周回率が増えた。
公開版では判定を約1周へ変更し、時計回りと反時計回りを符号付きで積算するようにした。往復分は相殺される。角度の計測も描画フレーム単位ではなく、物理計算のサブステップ単位へ移した。
AIが生成したコードは、一見もっともらしく動く。画面に「100%」と出れば、人間も完成したように感じる。
しかし、表示と内部条件が一致しているとは限らない。
これは今回の開発で最も分かりやすかった教訓だ。
モバイルで起きた問題
ブラウザ上では動いても、iPhoneで触ると別の問題が出た。
- タッチ座標が描画位置からずれる
- タップするたびに画面が下へ動く
- HUDがノッチに隠れる
- 重力レンズによって照準と予測線まで歪む
座標ずれの原因は、Canvasの内部解像度とCSS表示サイズが一致していなかったことだった。高DPI端末ではdevicePixelRatioを使って内部解像度を上げつつ、CSS上の幅と高さを明示する必要がある。
iOSのスクロールはpointerイベントのpreventDefaultだけでは完全に止まらず、touch-actionとtouchmoveの抑止も必要だった。HUDにはsafe-area-insetを適用した。
重力レンズの問題は、ゲーム画面、WebGLレンズ、UIという3枚のCanvasレイヤーに分けて解決した。照準や予測線は一番上のCanvasへ描き、ブラックホールの上でも歪まないようにした。
このあたりは、コードを読んで見つけたのではない。実機で触り、症状をAIへ伝えて修正させた。
エンディングを3D化した
公開版では、エンディングも作り直した。
最初は2Dの光線と星雲を重ねた演出だったが、現在は星をX、Y、Z座標で持つ3D空間として扱っている。
エンディングは3幕構成になっている。
- 星が奥から手前へ流れ、ブラックホールへ落下する
- 白い閃光のあと、奥行きのある星雲空間へ抜ける
- 手紙の行ごとに星が灯り、3D空間上で星座になる
Three.jsなどの外部ライブラリは使っていない。Canvas 2D上でカメラ位置、奥行き、透視投影を計算している。手紙の本文だけはDOMレイヤーとして重ね、背景のカメラ移動とは独立して読めるようにした。
開発プロセスの実際
プレイ可能な最初の形ができるまでは約1日だった。ただし、一度のプロンプトで完成したわけではない。
Claudeがコードを書き、私が実機でテストし、症状と違和感を返す。その後、GPTに実装と説明の整合性をレビューさせ、判定と物理表現を修正した。
人間の仕事は、コードを書くことから次の作業へ移った。
- 何を作るか決める
- 実際に触って違和感を見つける
- AIへ再現条件を伝える
- 仕様と実装が一致しているか確認する
- 公開する水準を決める
「AIが作った」というより、複数のAIを使って設計、実装、監査を分担させた、というほうが正確だと思う。
で、マネタイズできるのか
結論から言うと、ゲーム単体で稼ぐ期待値はかなり低いと思っている。
Webゲームポータルの広告収益は、トラフィックがなければ成立しない。Steamで販売するなら、レベル数、サウンド、実績、ストア素材、サポートまで必要になる。ハイパーカジュアルのモバイル展開は、ユーザー獲得費用とLTVを管理できる事業者の市場だ。
個人が小さなゲームを1本作り、そのまま収益化できる確率は高くない。
ゲーム市場は生存者バイアスが強い。成功作は目立つが、公開されて誰にも見つからなかった作品は観測されにくい。
これはトレードと似ている。ただし従来のゲーム開発は、1回の試行に数か月かかる点がさらに重かった。
今回変わったのは、試行コストだ。
数か月かかっていた試行が、1日から数日で可能になった。直接収益の期待値が低くても、コストが十分に小さければ試すことはできる。
そして外れても、制作過程は記事になる。ゲームはブログやXへの流入資産として残る。
今回の記事自体が、その実践でもある。
所感
2026年の個人開発では、「作れるか」は以前ほど大きなボトルネックではない。
制限N体シミュレーションも、ブラックホール周辺の光線積分も、3Dのエンディングも対話から出てくる。
代わりに重要になったのは、何を作るか、どこまで検証するか、作ったものをどこへ流すかだ。
以前公開したHyperliquid初心者向けUI「HL One」も、複雑な取引画面を初心者向けに読み替える試みだった。生成コストが下がっても、「誰の、どの摩擦を減らすか」は人間側の仕事として残る。
製造コストが下がったのは自分だけではない。市場参加者全員が同じ道具を使えるため、供給過剰はさらに進む。ゲームで食べる難易度は、むしろ上がっているかもしれない。
それでも、週末に宇宙を一つ作って公開できるのは、単純に良い時代だと思う。
使用モデル: Claude Fable 5、GPT-5.6 Sol
プロトタイプ制作: 約1日
人間が書いたコード: 0行
ゲーム: THE LAST LETTER
カテゴリー:AI