全くゲーム開発をしたことがない私が、たった11日間、スキマ時間にほぼスマホから指示を出しただけで、ゲームを作ることができた。
そのゲームがこれだ。
実際にプレイしてみてほしい。
gacha-survivor.sho-shimauchi.workers.dev
以下はPC版のスクリーンショットだが、モバイルにも対応している。
国際化対応もしていて、英語や中国語など8か国語でもプレイ可能だ。
ゲームとして面白いかと言われると微妙だろう。
レイアウト崩れなどのバグもまだまだある。
しかし、単なる思いつきをここまで形にできるなんて想像もしなかった。
Claude Code + Opus 4.5 は、ITエンジニアのライフスタイルを激変させるほどの革命的なプロダクトかもしれない。
ちょっとした新機能などにも「革命的」なんていう宣伝文句が乱発されるようになった昨今、「革命的」などと言ってしまうと返って安っぽく聞こえてしまうからあまり使いたくはなかった。
しかし、今回ばかりは言わざるをえない。
Claude Code + Opus 4.5 は革命的だ。
実は、この年末までClaude Codeはまともに触ったことがなかった。
普段の業務では GitHub Copilot のみを使っていて、しかもメインで使えるのは GPT-5 / GPT-5 mini のみだった。
これでも従来に比べて十分生産性は上がっていて、そこまで不満はなかった。
以前少しだけClaude Codeを触ったことがあったが、Copilotの延長でわずかに使った程度で、そのときは大した価値を感じなかった。
Claude Codeをきちんと触ってみようと思ったのは本当に気まぐれだ。
師走の忙しい日々が終わり、ようやく年末年始の休みに入ったときに、さあ何を勉強しようかと考えたときに、思いつきで「せっかくだからClaude Codeを使ってみるか」と思った程度である。
まさか、これほどの衝撃になるとは思わなかった。
題材に選んだのはゲーム開発だ。
なぜゲーム開発なのかというと、理由は三つある。
一つは、細かく仕様を決める必要がないということだ。
商業ゲームならともかく、個人でゲームを作る程度なら別にきちんと仕様を決めなくても思いつきで作ることができる。
もう一つは、自分が全く知識のない分野だということだ。
ゲーム開発については本当に触り程度の知識しかなく、どういう風に設計すればいいかも何もわからない。
この状態でも開発がまともにできるのかを試したかった。
そして三つ目は、すぐに自分が試して確認できることだ。
他のテーマに比べ、作った成果をすぐテストできるというのは大きい。
それ以外にも、法的制約が少ない、DBなどのバックエンドの仕組みを導入しなくてもクライアントサイドのみで完結できる、などいろいろメリットが多かったというのもあった。
実際に作業にとりかかる。
まず、ゲームのコンセプトを決めた。
私のネタ帳の奥底にあった、「ガチャを回すバンサバクローン」という文字が目についたのでそれを使うことにした。
いきなりClaude Codeに投げるのではなく、最初は通常のClaudeに上記のコンセプトでプロンプトを生成させた。
条件として、「クライアントサイドで完結する、ブラウザゲーム」というのを追加しておいた。
そして、Claude Codeを起動。
上記のプロンプトを入力し、しばし待つ。
あっという間にできた。
ハリボテレベルではあるが、一応動くものができている。
使っているゲームフレームワークはPhaserというものだが、私は使ったことがないどころか、名前すら知らなかった。
github.com
そしてさらに指示を出す。
「敵を追加して」
「ステージを追加して」
「ゲームオーバー時にリザルトを表示して」
Claude Codeは次々と実装していく。
たった1.5日で4000行のコードが生成された。
私の普段の業務でも、この速度でまともにコードを書くことなんてとてもじゃないが不可能だ。
そしてさらに驚くべきことに、
ここまでコードは一切手を入れてない。
コードに関する指示は「コードを整理して」と指示出した程度で他は機能面の指示しか行ってない。
Copilot Agent + GPT-5 のときは、細かいコードの実装に手を加えなくてもコードの設計そのものはかなり人間が考えないとどうしようもなかった。
ゲーム開発における基本的な構造すら理解してないレベルでも、Claude Code + Opus 4.5 だと人間はほぼプロダクトマネージャーに徹することができる。
単にほしい機能や要望リストだけ管理して、優先度の高い方から順に投げつけているだけである。
こう書くとさも快適に思うかもしれないが、
実際には想像するようなリラックスした開発とはだいぶ遠い。
これを同時並行で延々とこなしていく。
AIがたくさん動くとそのマネジメントで普通に忙しい。
特に、自分自身による動作確認が一番のボトルネックになる。
ちょうどこのタイミングで友人数名だけにこのゲームを共有して感想をもらったが、これによるフィードバックは開発効率に大きな影響を与えた。
作ったものの何が問題かがすぐに分かるようになった。
ここで私が学んだことは、
他のユーザーを巻き込めるレベルまで最速で持っていく
ということである。
たくさんの目があればそれだけバグも見つかるし、要望の優先度も定めやすい。
しかし、ただ公開すればいいというものでもない。
「もっと触ってみたい」と思わせるだけの魅力がないといけないし、フィードバックを投げやすい仕組みもないといけない。
そして、フィードバックを投げたらすぐに対応してもらえるという体験も提供しないといけない。
実際に他の人に触ってもらうというのは簡単なことではないのだ。
そこで次に着手したのが、音楽である。
BGMとSEを追加することにしたのだ。
まずBGMだ。
最初に、ゲームの世界観を書き出す。
これは私の頭で思いつきで適当に並べたものだ。
これを入力としてClaude Codeでゲームのコンセプトテキストを生成する。
そのコンセプトを使い、Sunoのプロンプトを書いてもらう。
そして、Sunoにプロンプトを投げて曲を生成する。
並行してClaude CodeでBGM再生機能を追加してもらう。
こんな感じで、あっという間にBGMができた。
次にSEだ。
SEはClaude Codeだけで簡単に生成できた。
「SE作って」
と指示を出しただけだ。
BGMとSEはユーザーたちに好評で、一気にゲーム体験を向上させることができた。
そうこうしているうちに、年末の旅行の日が近づいてきた。
旅行中はPCは持ち歩かないのでスマホだけになる。
なので、Claude Codeで遊ぶのもしばらくお休みか、と思ったがふと気づいたことがあった。
ClaudeのモバイルアプリからCodeを起動できる。
しかし、本当に使い物になるのか？
半信半疑だったが、他に選択肢もないし、ダメならダメでいいやと思い、これを使うことにした。
といってもただモバイル版を使うだけではダメだ。
ゲーム自体を常に最新版を使える必要がある。
そこで、GitHub Pagesにデプロイする仕組みをGitHub Actions上に設定することにした。
GitHub Pagesは容量制限が厳しいが、自分（と数名）が少し遊ぶ程度なら問題ないだろう。
そしてこのモバイル版こそが、私が革命的と感じたものだった。
正直、モバイル版はClaude Codeに比べて使い勝手がいいとはいいがたい。
セッションはたびたび落ちるのにクレジットは消費する。
プランモードは全く動かないのに、指示が複雑だと勝手にプランモードに入ろうとする（そしてこれもまたクレジットを大きく消費する）。
毎回コードをpullするためか、クレジット消費量はClaude Codeにくらべて大きい（気がする）。
デフォルトがSonnetになっていてOpusに設定できないのも気に入らない。
しかし、スマホでゲームを開発できるのだ。
新幹線に乗っているときでも、
除夜の鐘をつきにお寺まで行っているときでも、
初詣に神社にお参りに行っているときでも、
雪山にスキーに行っているときでも、
遊び疲れて寝てしまった子供を抱っこして電車に揺られているときでも、
スキマ時間に開発ができるのだ。
「頭に火がついている人は、たとえ泥水でも金を出して買いたがる」というたとえから「バーニングニーズ」という言葉が生まれたらしい（きちんと調べていないので違うかもしれない）が、どんなにまだ機能不足だろうが、モバイル版ClaudeアプリのCode機能はまさしくこのバーニングニーズを満たすプロダクトである。
そしてようやく昨晩帰宅した。
11日間で43,000行のコードが生成された。
3900行/日のペースである。
うち6日間は年末のClaudeクレジット倍増キャンペーンもあってリクエストできる要望の数が多かったのもあるので、それを差し引いて考えた場合、1日あたりのコード執筆量は2,500行。
これだけのコードを、旅行の片手間にスマホ一つで作り上げたのだ。
これを革命的と言わずしてなんと言おうか。
3年前に生成AIに初めて出会った衝撃にはさすがにかなわないものの、それに匹敵するような体験を得られるとは全く思っていなかった。
そしてこのスマホでの開発、忙しいは忙しいが、開発そのものをゲーム感覚でできるというのも楽しい。
クレジットのリセットが5時間ごとに行われるので時間管理も必要になってくるが、これもソシャゲのログインボーナスのようなものだと思えば楽しめる。
開発体験そのものが一変するのだ。
さて、旅行から戻り、現実に立ち返る。
今回試したのは個人のゲーム開発であり、この体験をこのまま業務のソフトウェア開発に適用するのは難しいだろう。
要件や仕様の管理はもちろん、チーム開発としてのワークフローについても考えるべきことは多い。
単一コンポーネントで完結するような業務アプリケーションは今時ほぼ存在しないだろうから、複雑なコンポーネント間の接続を考慮した設計が必要になる。
今のままであらゆる業務開発に持ち込める、などというつもりは全くない。
それでも、やはりこの体験はこれからのソフトウェア開発を激変させると確信させるものだった。
