生成AIを開発に使って、ブラウザゲームを4本作りました。共通のテーマは、遊んで終わるのではなく、自分が選んだ一手を振り返り、その局面からもう一度試せることです。
完成したのはLink52、Minesweeper Review、FreeCell Review、そして「こむの牌路」Mahjong Solitaire。いずれもこむのくつ GAMESで動いています。この記事では4作品の狙いと共通の設計を紹介し、この記事とあわせて、Mahjong Solitaireの探索と実測を扱う技術記事も用意しました。
4作品の比較：遊ぶ → 振り返る → Retry
負けたときに「運が悪かった」と思うこともあれば、「あそこで別の手を選べばよかった」と感じることもあります。しかし結果だけを見ても、その二つは分かりません。
そこで、プレイした履歴を残し、終了後に判断の材料を返す構成にしました。さらに、解析結果を読むだけで終わらないよう、同じ盤面や確認できた局面へ戻るRetryを用意しています。別の一手を実際に試すところまでが、一つの体験です。
ただし、4作品で「振り返る」の意味は同じではありません。
| 作品 | 振り返りに使う情報 | プレイヤーへ返すもの |
|---|---|---|
| Link52 | 実際に使った山札の順序も含む完全情報 | 解析が完了した範囲で、別のカードなら最大何枚まで到達できたか |
| Minesweeper | 選ぶ直前に見えていた数字と総地雷数など | その時点での地雷確率と最低リスクの候補 |
| FreeCell | その局面の全カード配置 | 検証できた勝利ルートと、最後に勝てたと確認した局面 |
| Mahjong Solitaire | 牌配置と取得・Undoなどの履歴 | 確定した勝利可能性、未確定区間、再挑戦できる局面 |
この違いを曖昧にすると、未来を知った解析で人間の判断を責めたり、探索の打ち切りを敗北と呼んだりしてしまいます。画面の言葉を決める前に、各解析が何を知っているか、何を証明したかを決めました。
Link52：実際の山札で別の道を見る
実際に動くLink52は、52枚のトランプから配られた5枚の手札を使い、場札と同じ数字かスートをつなぐゲームです。最初の1枚は自由に選び、出した場所へ次のカードを補充します。
プレイ中の継続率アシストは「次のターンにも出せるか」を見ます。終了後の解析は、実際の山札順を知ったうえで「その後も最善に進めたら何枚まで到達できたか」を調べます。
たとえば今回の撮影用プレイでは10枚で終了し、完全情報解析の最大到達は13枚でした。この差は実プレイの結果と、未来を知った探索結果との差です。人間が当時知り得た情報での判断の良し悪しを、そのまま測る数値ではありません。
探索が上限に達した場合は未解析として残し、全手順の解析が完了するまで「最大のミス」は断定しません。
Minesweeper：爆発した場所ではなく、選ぶ前の情報を見る
実際に動くMinesweeper Reviewでは、終了後に各クリックの直前の盤面を復元します。隠れた地雷配置を正解として渡すのではなく、その時点の数字などと両立する配置を数えて確率を求めます。
安全なマスがあるのに危険なマスを選んだのか、安全な選択肢がなく推測が必要だったのか。勝敗とは別に、選択時のリスクを振り返れるようにしました。計算上限までに確率を確定できない場合は、未解析として区別します。
FreeCell：確認できた勝ち筋から再挑戦する
実際に動くFreeCell Reviewでは、外部solverやWASMを使わず、自前の探索と別実装のcheckerを組み合わせました。
勝利ルートを検証できたらWINNABLE、完全探索で解けないと確認できたらUNSOLVABLE、上限までに決まらなければUNKNOWNです。未確定があることを隠さず、確認済みの局面からやり直す体験を中心にしました。UNKNOWNは負けの証明ではありません。
Mahjong Solitaire：全問解析を約束しない製品判断
実際に動く「こむの牌路」は、Classic Turtle 144牌とShort Bridge 72牌の2モードです。対戦麻雀の役や点数を扱うゲームではありません。
144牌では、探索の正しさだけでなく、限られた時間で履歴全体を解析できるかが問題になりました。profilerで候補の順序付け処理を調べ、1回の重点最適化を実施しても、厳しい完了率の基準には届きませんでした。
その後、全履歴を必ず確定するという約束を外し、確認できた範囲とUNKNOWNを分けるbest-effort Reviewとして製品化しています。これは基準を達成したことにする判断ではありません。144牌ソルバーの失敗・改善・製品判断に、母数を含めた実測をまとめました。
共通の構成：静的配信とWorker
MicrogamesはTypeScriptのブラウザ実装をViteでビルドし、Cloudflare Pagesで配信する構成です。説明ページの本文とmetadataはビルド時にHTMLへ出力します。ゲームの解析はブラウザ側で行い、重い探索や確率計算はWeb Workerへ分離しています。
Workerに出せば計算量が減るわけではありません。入力を絞り、計算予算を設け、失敗やキャンセルを画面へ戻す必要があります。特にRetryやNew Gameのあとに古い解析結果が届いても、現在の盤面に混ざらないようにすることが大切でした。
また、同じseedだけで永続的な再現性が保証されるわけでもありません。ルールや生成器が変われば配置の意味も変わります。実装側ではゲームごとのversionや完全な局面snapshotを扱い、今回の画面撮影でもseedと操作手順を記録しました。
生成AIはどこに使ったか
生成AIは、実装、テスト作成、リポジトリ調査、性能計測の補助、検証レポートの作成に利用しました。ただし、ソルバーや確率計算の正しさを、AIの回答だけで判断したわけではありません。勝利ルートは独立checkerで再生し、確率は独立oracleと照合し、性能はbenchmarkと実測で確認しました。生成AIに作業を助けてもらうことと、結果を検証することは別の工程です。
分かったこと：画面に出す主張には証拠が必要だった
4作品を通して難しかったのは、ゲームが動くことから、解析の説明を信用できることへ進む部分です。勝利ルートは別の合法性判定で再生し、確率は独立oracleと比較し、性能は決めた入力集合で測りました。生成AIを使ったこと自体を、正しさの根拠にはしていません。
今回の検証の限界
この連載では、開発に使ったモデルの優劣や開発時間の削減率は比較しません。保存された検証資料には、その比較を支える測定がありません。実際に作った画面、検証したアルゴリズム、測定で残った制約を中心に扱います。
4作品を作って難しかったのは、解析結果を出すこと以上に、「どこまで分かったか」を正しく表示することでした。確定した事実、条件付きの評価、まだ分からないことを分けて初めて、振り返りが次の一手を試す材料になります。ReviewからRetryへつなぐために必要だったのは、この説明の境界を実装と画面の両方で守ることでした。