AIで作ったモックを、どう仕上げるか

経営層や企画者が、自分でAIを使ってモックを作るようになっています。僕がやっていることは、このモックを本番化してリリースする、いわゆる仕上げ屋です。

この仕上げ屋さんの仕事として今回、MURA大富豪（同期対戦&キャラ解放やガチャもある本格ソシャゲ）を仕上げています。

AIで作られたモックが僕のところに来た8月の時点では画面があり、ボタンを押せばゲームも進むところまでできていました。そのモックを本番で動くものにして、9月25日にリリースしました。そこまでに何があったのかと、次に同じことをするならどう進めるかを書いていきます。

モックの中身を確かめていくと、バックエンドも、画面からそこへつながる部分も、かなり作り直すことになりました。AIで作ると、まず動いているように見えるものが一番に出てくるようなので、一見動いているけれど実はつながっていない、というのはあるあるですよね、本当によくあることです。

本番に向けて大きく残っていた仕事は、（１）仮の仕組みを実際のデータにつなぐことと、（２）引き継いだ仕様の食い違いを整理することの二つでした。

画面の裏側を本番のデータにつなぐ、その前に。

画面がどの値を読み、操作した結果をどこへ保存しているのか、バックエンドを調べると、次のような状態でした。

残高や所持品が、ブラウザ内のlocalStorageに保存されている。
キャラや報酬の情報が、コードに直接書かれている（ハードコード）。
サーバーからデータを取れなくても、仮のデータでゲームが動いてしまう（フォールバック）。
管理画面で設定を変えても、ユーザー画面に反映されない。「保存できました」と出ても、読み直すと元に戻る箇所もある。

このまま本番に出すと、対戦ゲームなのに、自分の手札と相手の手札がずれます。アイテムもサーバーと連動していないので、自分では持っているつもりでも、データの上では持ってない。スマホを替えた人には所持品が引き継がれず、企画者が管理画面で報酬を変えても、遊んでいる人の画面はコードに書かれた値のままです。

キャラの情報は、画面用のコードとデータベースの初期データの両方に書かれていて、10キャラ以上が食い違っていました。つまり、いくら管理画面でキャラの修正をしても、ファイルに書き込まれて固定されているので修正されません。

「こ、これでは、全然あそべないぞ。。」と、当時の僕が思った率直な感想です。

そして、企画者自身は引き継ぐ前に、素材の入れ替えが残っているけどバックエンドはできているという認識と周知であり、まずここのズレの解消に努めました。コードの修正をAIでやるよりも先にやったのは、人側の認識の修正です。

ちょっとエラそうに聞こえるようなことなのですが、僕は人の判断のコストを重視しています。初期の認識がずれたまま進むと、その上で下した判断が後でまとめてやり直しになり、大きなダメージになって返ってきます。軌道修正は必須です。

企画者や経営層が作ったものなので進捗の実態を伝えるのは勇気のいることです。あなたが作ったものは一見うごいているように見えるけど、中身は全然できていないのでスケジュールと作業ボリュームの見直しをして欲しい、と。

（この記事の公開許可をして頂いた企画者に感謝いたします）

引き継いだ仕様を、実装と突き合わせる

さらに、仕様を確認するといくつか違和感がありました。

実装済みのコード
DBに入る値（初期値として入るもの、コードに直接書かれているものなど）
ゲームの仕様書
仕様ウィキ3種類（日付違いの版と、同じ日付のv2・コピー版）
運用マニュアル
管理画面の項目とユーザー画面で出ている項目
AIによるissueやPRのコメント

仕様がいっぱいある(；ﾟДﾟ)

この時点で違和感だらけだったものの、こうなってくるとやはり仕様の内容は一致しておらず、例えば同じ仕様書の中でも、ある章には「回数上限あり」別の章には「上限撤廃」と書かれていました。

AIで作った仕様書あるあるなんだと思います。コード修正が先行する時は仕様書側の更新がなされない、コード修正の方が後になると仕様書の方にあわせようとするのでコード実態が合わない。まあまあ地獄なループです。

この状況で考えたのが、仕様書を捨ててコード実態を一番の仕様書とするSSOT（Single Source of Truth）を目指すアプローチ、他には、仕様書の差分を把握して実装確定できそうなものを抽出して判断が必要なものを企画者にヒアリングするアプローチ。

今回は、前章の通り、コード実態がハチャメチャなので、後者の抽出&ヒアリング方式にしました。企画者が決めたことや、その後のissueのコメントを追いながら、三つに分けます。

足りない実装は、採用した仕様どおりに直す。
古い記述や直し終えた指摘は、今どうなっているかを書き残して、まだやることと分ける。
どちらの仕様にするか決まっていない項目は、企画者に決めてもらうものとして残す。

今のコードに合わせて仕様を書き換え、解決したことにするのは避けました。僕は仕様書そのものの修正は担当せず、企画者に確認して決まった内容を実装へ反映しました。

その間にも、企画者からは新しい案や画面の変更が毎日、届きます。変更を丸ごと取り込むと、直したはずのハードコードや古い仕組みまで戻ることがあるので、何を変えたい修正なのかを読み取り、必要な部分だけを今の実装に合わせて移していました。

僕自身も、ゲームとしてはこっちが楽しいだろうという実装自体は期待されていたように思うので、必要に応じて導入しています。

もはや、この何を変えたい修正なのか、ユーザーに何を届けたいか、どういう楽しい時間を過ごしてもらうか、こういった読み取る力こそが、これからの作業者に求められる力なのかもしれません。

方向性が見えたら、実装です。実装はCloudflare移行の記事でもお伝えしているように、やることを羅列、それが時にはissue一覧そのものではあるのですが、AIの長回しに耐えられるモデル（GPT-5.6 sol当時）で、セットしてGO、数時間後に確認。毎回20〜50項目ほどの修正が施され、ブラウザ確認して良さそうと思ったらgithubにpush、この繰り返しです。

終盤に気づいたこと、テストを先に書けばよかった

つなぎ直した箇所は、管理画面で値を変え、保存して読み直し、ゲーム側にも反映されるかを見る、という確認を直すたびに繰り返していました。途中からこの確認を自動テストにして、管理画面の保存からデータベース、ユーザー画面までを通して確かめ、見つけた不具合も再現できるものはテストに残しています。

例えばログインボーナスなら、1日目に来て2日目は休み、3日目に戻った人が2回目の報酬を受け取れるか、という行動もテストに入れました。3日目の報酬と、3回目に受け取る報酬は、毎日来る人だけを想定していると違いが見えません。期待する動きをテストに書こうとすると、日を空けた人をどう扱うかを、その時点で決めなければ書けません。

ここまで来て、仕様の食い違いを整理した段階で、先にテストを書いてから実装すればよかったと思いました。今回は、何を作るのかを決める作業と、できたかどうかを確かめる作業を、後から別々に追いかけていたからです。

9月18日に、作ったものとそこまでの確認結果をQAとインフラの担当に渡して、連休を挟み、MURA大富豪は9月25日にリリースされました。実装開始から約40日でのリリースです。

次にモックを仕上げるなら、この順番にする

いま振り返ると、実装はもっと短縮できたかもしれません。まだ試していない方法ですが、理想を書いてみます。実際にやった順番と違うのは、テストが実装より先に来ることと、モックの裏側を直さずに捨てることです。

モックを触って、ユーザーとして必要なものが満たせているかを確かめる。
ルールブック（仕様書）を1本だけ作り、更新するのもその1本だけにする。2本目にあたるものは作らず、確認が済む前の版は実装に回さない。
ルールブックにはシステムの作り方を書かない。書いてあると、そのとおりに作らなければいけないと読まれて、矛盾のもとになる。
ルールブックどおりに動くかを確かめるテストを、実装より先に作る。
テストができたら、モックからはデザインと導線だけを取り出し、裏側の仕組みは捨てる。デザインと導線は、企画者の意図どおりのものとして扱う。今回はハードコードやlocalStorage、フォールバックを一つずつ見つけて外していき、企画者から届く変更で直したはずの箇所が戻ることもあった。テストがあれば、裏側はテストに合わせて作るほうが、仮の仕組みを探して外すより手数が少ない。
デザインとテストに沿って、中身を作っていく。
お試し会やissueで出た改善項目は、AIでまとめて読み取ってから直す。1件ずつ読むと、重複や指摘どうしの関係が読み解けない。issueに実装方法は書かない。issueはできるだけ手書きにするか、簡素にやりたいことだけ書く。実装方法が書いてあると、間違った実装でもそのとおりに作るという判断が加わるため。
githubへの書き込みは、AIに自動でさせず人が行う。企画側でAIにpushやissueの書き込みを自動でさせていると、企画者の手元で起きたことと進捗がずれていき、整理されていないissueを人が判断するたびに余計な判断が増える。判断にかかる時間の話は、判断の時間を、できるだけ短くするに書いたとおり。
できあがったものを実機のブラウザで触って確かめ、テストと合わせて改善項目を洗い出して直す。

この方法で、管理画面の保存からユーザー画面まで、仕様どおりに動くかはテストで確かめられるようになるはずです。次の課題としては、遊んでおもしろいかどうかを確かめるテスト、リリースしてよいと判断する基準をどう決めるか、です。

ログインボーナスのテストは、人がどう行動するかを想定したものです。今後はもう一歩踏み込んで、そのとき人が何を考え、どう感じるかまで含めたテストを作れたら、なお良いなと思います。何にストレスを感じるか、ヘイトはどこに向かうか、アンチがうまれるとしたら、通信遅延、執着、みたいなことは実際に普通に起こり得るのに実装実態として持つことがあまり考慮されないので、こういったこともテスト化できればと思っています。

モックの仕上げを、引き受けます

ウルフアプリケーションでは、AIで作ったモックを引き継ぎ、本番で使えるサービスへ仕上げる仕事をお受けしています。仮の仕組みを本番のデータにつなぎ、食い違った仕様を整理し、動きをテストで確かめられるようにするところまでを、MURA大富豪ではやりました。

画面は動くけれどその先をどう作ればよいかわからない段階でも、仕様や修正が増えて何を正しいとして進めればよいのかわからなくなった段階でも、いまあるモックを見せてください。やりたいことを伺って、本番に向けて残っている仕事を整理するところから始めます。