友人のWebゲームを、AIとスマホアプリへ移植した。ルールは移せても、遊びやすさは移らなかった

課題

友人が、ブラウザで遊べる花札のゲームを作っていた。題名は「花あわせ」。CPUと「こいこい」を打つゲームで、ちょっと変わった仕掛けがある。毎月の天候で、役の値打ちが変わる。

これを、AIと一緒にiPhoneのアプリにしたい。2026年10月20日、自分はAIにこう頼んだ。

「Flutterで動くように改修してモバイルアプリとしてリリースしたいです。まず解析をお願いします。キーワードは『天候』です」

Flutterは、1つのコードからiPhoneとAndroidのアプリを作れる仕組み。自分のほかのアプリも、これで作っている。

使う許可は、友人からもらっていた。ただ、人が作ったゲームを、自分のアプリとしてストアに出すことになる。何をどこまで使っていいのか。ブラウザで動いているものを、スマホでどう動かすのか。似たアプリだらけの花札で、審査をどう考えるのか。考えることは、コードの外にもいくつもあった。

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

友人など、ほかの人が作ったゲームやツールを、AIと一緒にスマホアプリへ移したい人が、次の3つをできるようにする。

1. 使ってよい範囲を文面で確かめ、クレジットを載せてから審査に出す
2. Webのまま包むか、書き直すかを、審査と品質の面から決める
3. ルールの説明に書かれていない「見せ方」を、移す前に洗い出す

先に結論

10月20日に解析を始めて、10月23日に審査へ提出し、10月30日にApp Storeで配信されているのを確認した。アプリ名は「天気守の花暦（てんきもりのはなごよみ）」。天気で役が変わる、花札（こいこい）のアプリになる。

• 原作から使ったのは、天候で役の値打ちが変わる仕組み、ルール、3人の対局相手。元のコードはJavaScriptだったので、ルールはDart（Flutterで使う言語）へ書き直して、テストで固めた
• Webページをアプリの枠の中でそのまま表示する案（WebViewで包む案）は、AIの解析が、審査と品質の面から採らない方がよいとした
• 使ってよい範囲は、改変・ストア公開・広告・クレジットなどを、友人と文面で確かめた。クレジットの記載が取り決めの条件だったので、載ったビルドができるまで審査に出さないと決めた
• 移し方は、Appleの審査の「似たアプリ」の項目（ガイドライン4.3(a)）を前提に決めた。自分たちの採点でも、新しさは土台のこいこいではなく、原作の天候の仕組みにある、と書いている
• 抜けていたのは、ルールの外にあった見せ方だった。PCで遊ぶと、マウスを乗せた札が大きくなり、取れる札が光る。スマホには、その「乗せる」操作が無い。自分の提案で、タップで選んで、もう一度タップで出す形にした
• これとは別に、友人に遊んでもらった感想が3つあり、それぞれ直した
• 絵・声・音は作り直し、Web版には無かった記録と、遊んだ局数で開くおまけを足した

この記事でわかること

• 友人の作品をアプリにするとき、使ってよい範囲とクレジットをどう確かめ、いつ審査に出すか
• WebViewで包まず、ルールを書き直してテストで固めた理由
• ルールの外にある見せ方が移植で抜ける例と、PCのマウスオンをスマホのタップに置き換えたやり方
• 移植するときのチェックリスト

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

「ルールをテストで固めたなら、同じゲームになっているのでは？」

ルールについては、テストで固めた。でも、それで言えるのは「ルールの説明どおりに動く」ところまで。遊んだときの手ざわりは、ルールの説明の外にもあった。マウスを乗せたら札が浮く、みたいな見せ方は、ルールの説明には書かれていない。マウスオンの見せ方が抜けていたのに気づいて直したのは、移し始めてから3日後の10月23日だった。

まずAIに解析させた。核は「天候で役の値打ちが変わる」こと

10月20日、AIが原作を読んで、解析のメモを書いた。ゲームの中身、天候ごとのボーナス、スマホへの移し方、審査の見込み、権利、競合まで書いてある。

こいこいを知らない人向けに、ざっくり説明しておく。花札は、12か月の花の札が4枚ずつ、全部で48枚。手札を場に出して、同じ月の札があれば取れる。取った札で「役」ができたら、そこで「あがる」か、もっと点を伸ばすために「こいこい（続ける）」かを選ぶ。

原作には、ここに天候が加わる。月の始めに9つの天候から1つが選ばれて、その月にあがった側に、天候ごとのボーナスが付く。たとえば、こんな具合。

天候	ボーナスの付き方（あがった側だけ）	狙いが変わること
晴れ	雨札を持っていなければ+4	雨札を避ける
雨	雨札を持っていれば+3	雨札を取りにいく
雪	その月のこいこいが多いほど大きい（3回以上で+5）	こいこいを重ねる
霰	その月のこいこいが少ないほど大きい（0回で+3）	早くあがる

AIのメモには、評価としてこう書いてある。天候は見た目が変わるだけではなく、月ごとに狙う役・取るべき札・こいこいの判断を変えるルールになっている。特に、「あがるか、続けるか」というこいこいの中心の判断そのものが、天候で変わる。

つまり、ここがこのゲームの核になる。アプリにしても、ここは変えない。逆に言えば、それ以外のところは、スマホに合わせて作り直してもいい。あとから見ると、この線引きがそのあとの判断の土台になっていた（ここは記録をもとにした、あとからの整理）。

同じ日に、AIが名前と世界観の案を3つ出し、自分は「天気守の花暦」を選んだ。山あいの社で、天気守の見習いが、花の精と札を合わせる。対局相手の3人は、原作のCPUの名前と色をそのまま使って、紫陽花・彼岸花・藤の花の精にした。

使ってよい範囲を文面で確かめ、クレジットを入れるまで審査に出さなかった

使う許可は、10月20日の時点で友人からもらっていた。

ただ、AIの解析メモには「許可の範囲を文面で残す」という項目があった。改変してストアに出してよいか、広告を入れてよいか、クレジットをどう書くか。許可をもらうことと、どこまで使っていいかを確かめることは、別のことになる。

10月21日までに、改変・ストアへの公開・広告・クレジットの記載などの範囲を、友人と文面で確かめた。取り決めの中に、クレジットを載せることが入っていた。

そこで、次の3つを決めた。

• アプリの「遊び方」のいちばん下に「原作とクレジット」の節を作り、原作の題名と、原作者として友人の名前を載せる
• クレジットがストアに出るビルドに入るまで、ストアに提出しない
• 提出前の確認リストに「原作者のクレジットの記載」を足し、遊び方の下にクレジットが出ることを、テストでも確かめる

翌22日のテスト配信（TestFlight。Appleのテスト配信の仕組み）のビルドには、クレジットが入っている。

ルールはDartへ書き直してテストで固めた。WebViewで包む案は採らなかった

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

「ブラウザで動いているなら、そのままアプリの中で表示すればいいのでは？」

WebViewは、Webページをアプリの枠の中でそのまま表示する仕組み。

でも、AIの解析メモは、この案を4.3（似たアプリの審査の項目）と品質の面から採らない方がよい、としていた。元のコードはJavaScriptなので、ルールをDartへ書き直す。これが、解析の段階で出ていた結論だった。

書き直しは、画面と切り離して進めた。札48枚と特別な「天気雨札」、役、9つの天候のボーナス、1局の進み、対局全体の進み。それぞれを別々のコードにして、テストで固めていく。

10月20日の時点で、テストは38件成功した。役、天候ごとのボーナス、配り、取り、こいこい、流局、倍付け、対局、そしてCPU同士で最後まで打てること。

ルールは、原作どおりの「かんたん」と、こいこい返しなどを入れた「標準」を切り替えられるようにした。標準でも、天候のボーナスは倍にせず、足すだけ。ここは自分が決めた。

天候を見て打つCPUは「足したもの」

対局相手には、天候を見て打つCPUを足した。強さは3段階で、「ふつう」は天候を見て札の値打ちとこいこいの判断を変える。晴れなら雨札を避け、雨なら取りにいき、霰ならすぐあがり、雪ならこいこいを重ねる、という具合。「つよい」は、さらに見えていない札の多い月を捨てない。

強さの差は、CPU同士を12局×400回打たせて確かめた。

対戦	結果
ふつう 対 よわい	247勝143敗
つよい 対 よわい	271勝123敗
つよい 対 ふつう	222勝170敗

ただし、これはCPU同士の数字。人と打ったときにどれくらい強いかは、測っていない。

実際、自分が遊んでみて直したところもある。最終局で自分が10文、相手が0文のとき、相手はこいこいを続けないと勝ち目が無いのに、あがってしまっていた。最終局では、いまあがっても相手に届かないならこいこいを続け、勝てるならすぐあがるようにした。CPU同士の勝ち負けの数字は、こういう場面の判断までは見せてくれない（ここは記録をもとにした整理）。

移し方を「似たアプリ」の審査基準で決めた。新しさは原作の仕組みにある

ガイドライン4.3(a)は、Appleの審査の項目で、ほかのアプリと似すぎたアプリを断るもの。8月に別のアプリがこれで却下されて以来、6つの条件で自分たちで採点してから出すようにしている。その経緯と6条件の中身は、混み合った一筆書きパズルで、前提を1つ反転して新作を作った話に書いた。

花札・こいこいは、App Storeにとても多い。AIの解析メモも、最初から「密集したジャンル」としていた。そこで、移し方を次のように決めた。

• WebViewで包まず、書き直す（前の節）
• 天候を主役にする。アプリ名に「花札」「こいこい」を入れない。「花札」は、サブタイトル「天気で役が変わる花札」で1回だけ使う
• 原作の題名「花あわせ」は、こいこいとは別の花札の遊び方の名前でもあり、すでにあるアプリも使っている。アプリ名にも検索の語にも使わず、説明文の原作の記載でだけ使う
• 天候の無い「ふつうのこいこい」も遊べるようにしたが、支度の選択肢として脇に置く

10月23日、提出の準備の中で6条件を採点した。

条件	判定（10月23日）	メモ
① 遊びの中心の判断が変わるか	◯	天候で、狙う札とこいこいの判断が月ごとに変わる。ただし土台のこいこいは伝統のルールで、新しさは天候のボーナスの仕組み（原作の仕組み）にある
② 一文で違いを言えるか	未達	一文は言える。ストアの文言の承認とスクリーンショットの作成までは、満たしたと判定しない
③ 飾りを外しても違いが残るか	◎	天候のボーナスは点数の計算なので、景色の絵を外しても残る
④ 少人数で作り切れるか	◎	ルールは原作から移し、天候ごとの加点をテストで固めた
⑤ 広告が遊びを壊さないか	◯	最初の版は広告なし
⑥ 名前や説明文が混み合っていないか	◯	名前に「花札」「こいこい」を入れない。ほかのアプリの名前も使わない

①のメモによれば、このアプリの新しさは、自分たちが考えたものではなく、友人が作った仕組みにある。自分たちがやったのは、それを壊さずに移して、スマホで遊べる形にすることだった。

競合も調べた。10月20日にWeb検索で、10月23日に日本のApp Storeの検索とWeb検索で調べた範囲では、天候で役の値打ちが変わる花札は見つからなかった。ただ、2026年7〜10月に初めて公開されたこいこいのアプリが8件あり、混み具合は10月20日より進んでいた。

ルールの外にあった見せ方が、抜けていた

10月23日、自分はAIにこう提案した。

「PCではマウスオンで選択中の札が大きくなったり候補が光ったりして遊びやすかった。スマホではタップで強調表示し、場のどの札が候補になるかも強調表示したい」

マウスオンは、マウスのカーソルを札の上に乗せること。PCで原作を遊んだときは、乗せただけで、選んでいる札が大きくなり、取れる札が光った。どの札を出せば何が取れるのかが、押す前に分かる。

スマホには、この「乗せる」操作が無い。指で触れたら、それはもう押したことになる。

タップで選んで、もう一度タップで出す

その日のうちに、こう作り替えた。

• 手札を1回押すと、選ぶだけになる。選んだ札は大きく浮いて前に出て、重なっていた部分も見える
• 取れる場札は浮いて金色に光り、ほかの場札は薄暗くなる。取れる札が無ければ、全部薄暗くなる
• 同じ手札をもう一度押すか、光っている場札を押すと、出す
• 別の手札を押すと選び直し、盤面の何もない所を押すとやめる
• 山からめくった札で、2枚のどちらを取るか選ぶ場面も、候補を浮かせてほかを薄暗くした

自分が決めたのは、3つ。操作を切り替える設定は作らず、この形にそろえる。めくった札の場面もそろえる。最初の版（1.0）に入れる。案内の文と、はじめての説明の1枚目の文も、この操作に合わせて直した。

スワイプで出す案は、入れなかった

出し方には、もう1つ案があった。自分はAIに、こう聞いている。

「もう一度タップするのと、タップした後上にスワイプするのではどちらが良いか」

スワイプは、指で画面をはじく操作。札を選んで、上にはじいて出す形になる。

でも、決めたのは「もう一度タップ」。記録に残っている、スワイプを入れない理由は4つ。

• 知られにくい（はじけば出せると、遊ぶ人が気づきにくい）
• 2枚から選ぶ場面に使えない
• 重なった手札で、誤操作しやすい
• 押しやすさへの配慮

入れるとしても、あとの版で「上にはじくとそのまま出す」近道として足す案、としてある。

なぜ抜けたのか

AIの解析メモには、原作のルールの説明文がそのまま仕様書になる、と書いてあった。テストも、ルールを確かめるものだった。

マウスを乗せたら札が浮く、という見せ方は、ルールの説明には書かれていない。しかもスマホには、マウスを乗せる操作そのものが無い。仕様書にしたのがルールの説明文だけだったから、そこに無い見せ方は、移す対象に入らなかった。記録から推すと、抜けた理由はここにありそう（ここは記録からの推論）。

実は、同じ種類の抜けは、その前にもあった。10月21日、最初のテスト配信を遊んだ自分は、11個の感想をAIに伝えている。その中に、光札（いちばん点の高い種類の札）を取ったときの演出を、元のゲームのように再現したい、というものがあった。取った光札を中央に大きく出し、金の光の筋を入れる形で足している。

どちらも、ルールの説明には無い。でも、遊ぶ人にとっては「このゲームらしさ」の一部だった。ルールを確かめるテストが全部通っていても、ここは引っかからない。気づいたのは、原作を遊んだことのある自分だった。

友人に遊んでもらった感想を、3つ直した

これは、上の話とは別。10月22日、友人に遊んでもらった感想が届いた。自分は、3つともそのとおりに直すと決めた。

1. 取った札が分かりにくい: 札が一瞬で場から消えて、取り札に表示されてしまう。元のWebゲームでは、重ねて見せていた
   • 直し方: 取る前に、出した札を取る場札に少しずらして重ね、0.8秒見せてから取り札へ移す。3枚まとめて取るときは、3枚を光らせて1枚目に重ねる。その間、案内には「〇〇を出しました」と出す
2. 花の精が親だと、間髪入れずに打ち始める
   • 直し方: 局の最初の手番が花の精なら、打ち始めるまで2.5秒待つ。2手目からは0.9秒のまま
3. 支度の画面の「初月の親」「初月の天候」は、開発用の設定ではないか（リリースのときは消してもいいかも、という感想）
   • 直し方: 配るビルドでは出さない。親は札を引いて決め、初月の天候はおまかせにする。開発中のビルドでは、今までどおり出す

3つ目は、開発中に便利な設定が、そのまま配る版に出ていたということ。

テストを2件足し、81件成功した。

絵・声・音は作り直し、Web版に無かった記録とおまけを足した

絵

絵は、世界観に合わせて新しく作った。AIが画像生成の指示文を書き、自分が別の画像生成AIで作った。アイコン、ホームの背景、天候ごとの盤面の背景9枚、見習い、花の精3人、札の裏。

盤面の背景でいちばん大事にしたのは、小さく暗くしても、どの天候か見分けられること。霰は雪とほとんど見分けられないとAIが気づき、花曇りは「ぱっと見は曇りに見える」と自分が指摘して、どちらも描き直している。札の表の絵も、画像生成で作った絵を切り分けて使った。

声と音

花の精の声は、別の作業の場のAIに頼んで、AIの音声合成で作ってもらった。対局中のひと言31本と、花の精と過ごす画面のひと言78本で、合わせて109本。3人とも別々の声になっている。BGMも、別の作業の場でAIの音楽生成を使って作ってもらった。効果音は、出す・取る・光札・こいこい・あがり・負けの6つを合成した。

声は、アプリの大きさを減らすために形式を変えている。

• WAVの109本（31MB）を、FLAC（音を劣化させずに縮める形式、13MB）へ変えた。109本とも、中身がWAVと1サンプルも違わないことを照らし合わせた
• m4a（3.3MB）も試したけど、声に入っている電子透かしが、読み取れなくなるものがあった（96kbps・128kbpsでも同じ）。なので見送った

大きさだけなら、m4aのほうが小さい。決め手になったのは、大きさではなく、透かしが読めるかどうかだった。

Web版に無かった記録と、おまけ

Web版には無かったものも足した。

• 花暦帳: 花の精ごとの対局の記録、49枚の札と取った回数、9つの天候の景色と出会った局数
• 花の精と過ごす画面: 時計、毎時ちょうどの時報、ひと言
• 遊んだ局数で開くおまけ: 3人の合計の局数（10・20・40・60・80局）で札の裏3種と札の縁2色、その花の精と50局で、その花の精の新しい姿

おまけは見た目と声だけで、打ち方・点数・広告とは結びつけていない。遊びの公平さは変えない、というのが決めごとだった。

提出から配信まで。分からないこと

10月23日の14時半ごろ、審査へ提出した。審査に出すビルドは、自分がテスト配信で確かめた。審査の担当者向けに、3分29秒の画面収録を添付し、審査メモは3,975文字に収めた。承認されたら自動で公開される設定にしている。

提出の作業でぶつかったApp Store Connectの落とし穴は、App Store Connectで、URLを1つ変えるだけのはずが新しいバージョンが必要になったの追記にまとめた。

10月30日、App Storeの公開ページが開けて、配信されていることを確認した。

今のアプリの姿は、天気守の花暦の紹介ページで見られる。

ここから先は、分かっていないこと。

• 承認された日時: 自動で公開する設定のため、記録にあるのは10月30日に配信を確認したことまで
• ②の採点のやり直し: 10月23日の採点で②は「未達」だった。提出の直前に採点し直した記録は、読んだ範囲には見つからなかった
• FLACの声がiPhoneで鳴るか: 審査に出すビルドを自分がテスト配信で確かめた記録はある。ただ、FLACの声について個別に書いた記録は、読んだ範囲には無い
• タップで選ぶ操作が、遊ぶ人にとって遊びやすいか: 自分の提案で作ったもので、ほかの人の感想はまだ記録に無い
• CPUの強さ: 数字はCPU同士のもの。人と打ったときの強さは測っていない
• 見せ方が抜けた理由: ルールの説明文だけを仕様にしたから、というのは記録からの推論

移植するときのチェックリスト

今回やったことと、やってみて分かったことを、ほかの移植でも使える形にまとめておく。

使ってよい範囲

• 許可をもらったら、範囲（改変・ストア公開・広告・クレジットなど）を文面で確かめる
• クレジットの書き方を決め、アプリの中に載せる
• クレジットが入ったビルドができるまで、審査に出さない
• 提出前の確認リストに「クレジットの記載」を入れ、テストでも確かめる

移し方

• そのまま包む（WebView）か、書き直すかを、審査と品質の面から決める
• ルールは画面と切り離して書き直し、テストで固める
• 原作の何が新しいのかを一文で言い、名前と説明文でそこを前に出す
• 原作の題名が、別の遊びや既存のアプリと重なっていないか調べる
• 競合は、作る前と提出の前の両方で調べる

ルールの外

• 原作を、元の環境（PCなど）で実際に遊び、ルールの説明に無い見せ方を書き出す（マウスを乗せたときの反応、取った札の見せ方、演出、相手が打ち始めるまでの間など）
• スマホに無い操作（マウスオンなど）は、何に置き換えるかを決める。複数の案を、知られにくさ・誤操作・使えない場面で比べる
• 原作者に遊んでもらい、感想をもらう
• 開発用の設定が、配るビルドに出ていないか確かめる

足すもの

• 足すものが、原作の核（今回は天候の仕組み）を変えていないか確かめる
• おまけなどは、遊びの公平さや点数に効かせない

こんな人に向いている

友人や知り合いが作ったゲームやツールを、AIと一緒にスマホアプリにしたい人に向いている。特に、元がブラウザやPCで動くもので、「ルールはそのまま移せばいい」と考えている人。ルールの外にある見せ方の洗い出しと、使ってよい範囲の確かめ方が、そのまま使えると思う。

人の作品でなくても、自分が昔作ったWebのゲームをアプリにしたい人にも、同じことが当てはまるはず。

まとめ

友人のWebの花札ゲームを、AIと一緒にiPhoneアプリへ移植した。核の「天候で役の値打ちが変わる」仕組みはそのまま移し、ルールはDartへ書き直してテストで固めた。WebViewで包む案は採らず、使ってよい範囲は文面で確かめ、クレジットを入れてから審査に出した。それでも、PCで遊んだときのマウスオンの見せ方は抜けていた。ルールの説明に書かれていない見せ方は、原作を遊んだ人が触って、初めて抜けに気づけた。

項目	内容
結論	ルールは書き直してテストで固めれば移せた。ルールの説明の外にある見せ方（マウスオンで札が浮く等）は移らず、タップで選ぶ形に作り直した
教訓	移植の仕様は、ルールの文だけでは足りない。原作を元の環境で遊び、ルールの外にある見せ方を書き出しておく。使ってよい範囲とクレジットは、審査の前に文面と実物で確かめる
対象読者	友人など、ほかの人が作ったゲームやツールを、AIと一緒にスマホアプリへ移したい個人開発者

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

• 許可をもらったら、範囲を文面で確かめ、クレジットが入るまで審査に出さない
• WebViewで包む前に、審査と品質の面から、書き直すべきかを確かめる
• ルールはテストで固めつつ、テストでは見つからない見せ方の一覧を別に作る
• 原作を元の環境で遊んだ人に、スマホ版を触ってもらう
• 開発中に便利な設定が、配る版に残っていないかを確かめる

次に読むなら

移し終えたら、次は混み合ったジャンルで「どこが違うのか」を、提出の前に自分の言葉と数字で確かめておくと安心できる。

• 混み合った一筆書きパズルで、前提を1つ反転して新作を作った話。App Store提出前に数字で確かめた6つの条件 — 今回の採点に使った6つの条件の中身と、提出の直前に競合の調べ直しと自分のデータの集計で違いを確かめた手順が分かる

---

この記事は、筆者が実際に個人開発しているモバイルアプリの開発記録（2026年10月20日〜30日）を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。