混み合った一筆書きパズルで、前提を1つ反転して新作を作った話。App Store提出前に数字で確かめた6つの条件

課題

AIと一緒に、スマホのパズルアプリを個人で作っている。iPhone版はいくつか公開していて、10月に次の1本を作ることにした。

候補に残ったのは、一筆書きパズル。盤面のマスを、1本の線で全部通るあれ。なじみがあって、作りやすい。そのかわり、App Storeにはもう山ほどある。

8月には、別のパズルアプリが「ほかのアプリと似すぎている」という理由で、App Storeの審査に落ちている（なぜ、審査で却下されたパズルゲームを、直さず作り直すことにしたのか？）。混み合ったジャンルにそのまま出せば、同じことになりかねない。

じゃあ、何を変えれば「別のゲーム」と言えるのか。今回の悩みどころは、まさにそこだった。

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

混み合ったジャンルで新しいアプリを作るときに、「違い」を思いつきではなく手順で作り、提出の前に数字で確かめられるようにする。

持ち帰ってほしいのは、次の3つ。

• ジャンルの「当たり前」を書き出して1つだけ反転し、遊びの核を選ぶ手順
• 試作して出てきた数字から、核の弱点を見つけて直すやり方
• 提出の直前に、競合の調べ直しと自分のデータの集計で違いを確かめ、以前の失敗も一緒に点検するチェックリスト

先に結論

10月8日に調べ始めて、10月16日に審査へ提出し、10月22日にApp Storeで公開された。記録に残っている範囲では、審査からの追加の質問も却下も無く、1回の提出で公開まで進んでいる。

やったことを並べると、こうなる。

• 一筆書きの「当たり前」を9個書き出し、「番号は通る順番」を「番号は何歩目までに着くかの期限」に反転して、遊びの核にした
• 試作で問題を自動で作ってみると、期限に余裕が無い問題は、昔からある数字パズルと同じになると分かった。余裕と「順番の食い違い」がある問題だけを採るように、問題の作り方を直した
• 提出の直前に、日本とアメリカのストアで競合を調べ直し、全160問を集計して、その数字パズルとの違いを数字で示した
• 以前つまずいたこと（データが届いているか、使わない機能の説明文が残っていないか等）を、提出前の確認に入れておいた

ただし、審査に通った理由は分からない。審査に通っても、その理由は知らされない。この記事は「こうすれば通る」ではなく、「違いを自分で説明できる状態にしてから出す」ための手順の記録になる。

この記事でわかること

• 混み合ったジャンルで、遊びの核を「前提の反転」で探す具体的なやり方
• 試作の数字で核の弱点に気づき、問題の作り方の側で直した例
• 提出前に違いを数字で確かめる方法（競合の調べ直し、全問の集計）
• 以前の失敗を、次のアプリの提出前チェックへ持ち越すやり方

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

「違いを作って数字で確かめたから、1回で審査に通ったってこと？」

そこは言えない。審査の結果は知らされても、なぜ通ったかは分からない。8月の却下のときも問い合わせたけど、どこが似ていたのか具体的な説明はもらえなかった。言えるのは、提出した時点で「どこが違うのか」を自分の言葉と数字で説明できる状態になっていた、というところまで。

全体の流れは、こんな感じ。

一筆書きを選んだ時点で、「素のままでは出さない」と決めていた

10月8日、次に作るミニゲームの候補をAIに調べてもらった。作りやすさ、違いを足す余地、共通の部品として育つか、最近の流行の4つの観点で、7つの候補を5点満点で採点した。一番高かったのが「一筆書き＋日替わりの問題」で、20点中17点。

ただ、混み具合が問題だった。AIがAppleの検索API（iTunes Search API。ストアのアプリを検索できる公開の仕組み）で日本のストアを調べると、「一筆書き」で132件。評価が10万件を超えるアプリもあれば、番号の順に全マスを通るタイプの小さなアプリもずらっと並んでいた。

なので、調査のメモにも「素の一筆書きでは出さない」「核の仕掛けは必須」と書いてある。ここは最初から決めていたところ。問題は、その「仕掛け」をどう見つけるかだった。

ジャンルの「当たり前」を書き出して、1つだけ反転する

使ったのは、8月の却下の後に決めた「コードを書く前の発想の手順」。ざっくり言うと、こういう流れになる。

1. 基準にするジャンルの「当たり前の前提」を5〜10個書き出す（AIに手伝ってもらってOK）
2. そのうち1つだけを反転して、ゲームがどう変わるかを短く書く。これを2〜3個の前提で繰り返す
3. 遊びの中心になる動詞を言い換えて、勝ち負けの条件を一文で書く
4. ルール→遊び方→感じる面白さの順に（MDAという考え方）、競合と遊び方が本当に変わっているかを確かめる
5. 取り除く・減らす・増やす・付け加えるの4つ（ERRCという考え方）に当てはめて、ヒントややり直しのような便利機能が「付け加えるもの」に紛れ込んでいないかを見る
6. 見込みで採点して、最後は人間が選ぶ

一筆書きでは、AIが前提を9個書き出した。「線は1本で、全マスを1回ずつ通る」「番号の印は通る順番だけを決める」「何歩目か、という時間の考えが無い」「盤面はすべて見えている」……。並べてみると、普段は意識もしない「当たり前」が意外とある。

そのうち6通りを反転して、採るかどうかを決めたのが次の図。

不採用の3つも、理由が具体的なのがポイント。たとえば「霧で隠す」は、自分が作っている別のパズルアプリと同じ仕掛けになる。よそのアプリとの違いだけでなく、自分のアプリ同士で似ないかも、判断の材料にした。

AIの推奨は案1「期限の灯」。理由は、ルールの説明が短いことと、遊びの中心の判断が一番大きく変わること。番号の順に通る一筆書きだと、迷うのは道だけ。でも数字が「期限」になると、どの家から先に回るかという段取りを考えることになる。

自分は案1を選んだ。案2は、後の章で足せる発展案として残した。

正直に書いておくと、「期限」の方向は、この手順を通す前、候補を調べたメモの段階で、仕掛けの方向の1つとしてもう挙がっていた。手順を通したことで、ほかの反転と並べて比べた結果と、採らなかった理由まで記録に残った。後から「なぜこの仕掛けなのか」を説明するときに、ここが効いてくる。

試作の数字で、核の弱点が見えた

その日のうちに、AIが問題を自動で作る試作のプログラムを書いた。ランダムに全マスを通る道を作り、数字の付いたマスを1つずつ足して、答えが1つに決まったら余分な数字を外す。解く側は、「最短で歩いても間に合わないマスがあれば、その先は探さない」という見込みで探索を切り詰める。

盤面	1問を作る時間	数字のマス（平均）
6×6	約0.2秒	8.6
7×7	約6秒	12.1

7×7で1問6秒。アプリの中でその場で作るには遅いけど、先に作ってアプリに入れておく方式なら十分使える。

ここで、弱点が見えた。期限にまったく余裕が無い問題だと、数字は「ちょうど何歩目に着くか」を表すことになる。それは、Hidato（数字の順に1マスずつつないでいく、昔からある数字パズル）と同じ。せっかく反転したのに、余裕が無ければ既存のパズルに戻ってしまう。

実際、試作で6×6の問題を15問作ると、期限の順と回る順が食い違う問題は8問だけだった。残りの7問は、期限の早い順にマスを回る道がそのまま正解になっていた。

そこで、問題の作り方の側に条件を入れた。

• 答えが1つに決まる
• 期限の順と、正解で実際に回る順が食い違う組がある（期限の早いマスを後回しにするのが正解になる組）
• 期限に余裕のあるマスを一定数以上含める

ここ、地味だけど大事なところだったりする。「仕掛けを思いついた」で止めずに、数字で「その仕掛けが本当に効いている問題」だけを残すようにした。

その日のうちに、世界観も決めた。AIが出した3案から自分が選んだのは、雪深い村で、炉の火が消える前に家々を回る話。全マスを通る理由は雪かきで、家の札の数字は火が消えるまでの歩数になる。

遊んでみて、結果の表示も直した

8日と9日の2日で、テスト配信（TestFlight。Appleのテスト配信の仕組み）のビルドを4回作った。自分で遊んでみた感想は「ミニゲームとしてちょうど良い規模」。規模はそのままにして、見た目と遊びやすさを整えていった。

その途中で、もう1つ直したことがある。クリアしたときに出す結果を、最初は「歩数」にしていた。でも、全マスを1回ずつ通るルールなので、誰が解いても「マスの数−1」で同じになる。結果として出す意味が無かった。

そこで、「かかった時間」と「火を消した回数」に変えた。一度も火を消さずに解けたら、判が押される。自分で決めたルールの性質に、表示のほうが追いついていなかった、という話。

ほかにも、範囲を決め直したところがある。

• 候補の名前にあった「日替わりの問題」は、10月14日に入れないと決めた。結果として、毎日の運用が要らない形になった
• 土地ごとに、本編の中ほど以上の難しさのおまけ20問を足した。本編80問と合わせて160問
• 別のアプリのテスターからもらったBGMの要望を、同じ作りのこのアプリにも入れた

提出の直前に、6つの条件を採点し直した

10月16日、審査用のビルドを作って確かめたあと、提出の前に6つの条件を採点し直した。この6条件は、8月の却下の後に作った自己チェックの基準になる。

競合は、提出の直前にもう一度調べる

企画のときに調べたのに、なぜまた調べるのか。きっかけは9月の別のアプリ。作業の時間を計るタイマーアプリで、8月19日の時点では見つからなかった「AIで調整するポモドーロ」という打ち出しのアプリが、1か月足らずの9月8日には複数出ていた。それ以来、実装に入る直前と提出の直前にも、競合を調べ直すことにしている。

今回は、AIがAppleの検索APIで日本とアメリカのストアを調べ直した。

• 日本: 「一筆書き 期限」「一筆書き 歩数」「火を灯す パズル」、それにアプリ名の4語で0件。アプリ名に使っている語を名前に含むアプリも0件。「一筆書き」の上位は10月8日と同じ顔ぶれで、10月に入ってからの新作は無かった
• アメリカ: 「one stroke puzzle」「path puzzle deadline」「hidato」など13語。説明文に期限の言葉を含む経路パズルは、どれも「全体の制限時間」のもので、マスごとに歩数の期限を持つものは無かった

違いを、自分のデータで数える

もう1つは、全160問の集計。正解の道で各マスに何歩目で着くかと、そのマスの期限を比べて数えた。

数えたもの	結果
期限の順と回る順の食い違い	1問あたり1〜5組
期限に余裕がある家の割合	本編で約76%、おまけで約78%
余裕の幅	0〜8歩
余裕が全部0の問題	0問

余裕が全部0なら、Hidatoと同じになる。その問題が0問で、全問に食い違いがある。これで「Hidatoとは、どの家から先に回るかの段取りが加わる点で違う」と、言葉だけでなく数字で言えるようになった。

この記事の下書きのために、AIが同じ問題のデータを集計し直したところ、同じ数字になった（家は全部で1,697軒、そのうち余裕があるのは1,304軒）。

採点を甘くしなかったところ

6条件の1つ目、「遊びの中心の判断が変わるか」は、◎ではなく◯にしている。数字の付いた経路パズル自体はHidatoなど昔からあり、ルールそのものの発明ではないから。新しいのは「期限の余裕と回る順の段取り」のところ、と記録に書いた。

もう1つ、「画像1枚と1文で違いが伝わるか」は、コードではなくストアに載せる文言と画像で判定する。9月に、違いを実装しただけで安心して、ストアの説明文や画像が古いままだったことがあったから（アプリの審査対策チェックリスト、1項目直しただけで安心したら他に2つ見落としていた話）。今回は、ストアの説明文と、画像の1〜2枚目の見出し（「火が消える前に、ひと筆で家々を灯す」「家の数字は、火が消えるまでの歩数」）が、この仕掛けを伝えていることを確かめた。

結論は、6条件とも提出してよい水準。そのまま、自分の承認でAIがApp Store Connect（Appleの開発者向けの管理画面）に入力して、10月16日の深夜2時15分ごろに審査へ提出した。

以前つまずいたことを、提出前の確認に入れておいた

6条件とは別に、これまでのアプリでつまずいたことも、提出前に確かめた。

• データが本当に届くか: 以前、iOSアプリの設定ファイルがフォルダにあるのにアプリに組み込まれておらず、約1か月データが届いていなかったことがある（GoogleService-Info.plistは置いてあったのに、iOSアプリのFirebaseが約1か月動いていなかった話）。今回は設定ファイルをアプリに登録したうえで、審査に出すビルドそのものを自分がテスト配信で起動した。その直後に、Firebase（アプリの利用状況を記録するGoogleのサービス）のリアルタイムの画面に、利用者1人と出た
• 使わない機能の説明文が残っていないか: 以前、広告を止めた版にトラッキング許可の説明文が残っていて、App Store Connectに止められた（テストでは問題なかったのに、配るビルドだけ違っていた話。R8・マニフェスト・Info.plistの3つの実例）。今回の最初の版は広告の仕組みを起動しない形で出すので、この説明文は最初の雛形から入れず、ビルドの前の確認の記録にも「入っていない」ことを書いた
• ビルド番号: App Store Connectで確かめた最大の番号より大きいかを、ビルドの前に確かめた
• 審査メモと画面収録: 新しいアプリを出すと、Appleから同じ形の追加の質問（画面収録、アプリの目的、機能の開き方、外部サービス、地域差、規制業種）が来ることが続いていた。記録では、これまで4本で同じ文面を受けている。今回は6項目の答えを最初からメモ欄に書き、自分が撮った1分22秒の画面収録を添付した
• マーケティングURL: 公開した後は変えられないので、最初から紹介ページのURLにした（公開直後にAdMobの広告が出ないとき、待つか直すか。app-ads.txtとマーケティングURLの確かめ方）

審査メモについては、1つ注意がある。今回は記録上、追加の質問は来ていない。でも以前、6項目を先に書いておいたのに、翌日に同じ質問が来たことがある。なので「先に書いたから来なかった」とは言えない。ここも、効いたかどうかは分からないまま、やるべきことをやった、という扱いにしている。

1回の提出で公開。でも、理由は分からないまま

10月22日、App Storeで公開された。承認されたら自動で公開する設定にしていたので、公開の時刻は記録に残っているけど、承認された時刻は分からない。

記録に残っている範囲では、10月16日の提出から公開まで、追加の質問も却下も無かった。

ここで、もう1つ聞かれそうなことがある。

「じゃあ、6条件をやれば審査は通るの？」

答えは「分からない」になる。審査がどこを見て判断したかは知らされない。6条件で採点したのは自分たちで、Appleの基準そのものではない。この採点は、審査の結果を予測するものではなく、「違いを説明できない状態で出さない」ための自分用の歯止め、くらいに考えている。

4.3(a)の却下から2か月、同じ6条件を当て続けてきた

今回の一筆書きは、8月の却下から続けてきた取り組みの、いまのところ最新の1本になる。ここまでの流れを短くまとめると、こうなる。

時期	出来事
8月13日	ブロックパズルが、App Storeの審査ガイドライン4.3(a)（ほかのアプリと似すぎている）で却下
8月20日	Appleからの回答。具体的にどこが似ていたかは開示されないと分かり、6条件を並列のまま確定した。そのブロックパズルを6条件で採点
8月21日	色分けパズルを採点し直し、遊びの中心を作り直す方針に（パズルゲームの審査却下を受け、なぜ未提出の別アプリまで作り直すことになったのか）
9月5日	コードを書く前の発想の手順（前提の反転など）を加えた
9月6日	「違いを実装したら、6条件を全部採点し直す」を加えた
9月8日	「実装の直前と提出の直前にも、競合を調べ直す」を加えた
10月7日	数独アプリを6条件で採点
10月16日	今回の一筆書きを6条件で採点し、提出

並べてみると、6条件そのものは8月から変わっていない。変わってきたのは「いつ当てるか」。最初は却下された後に当て、次は作ったアプリを出す前に当て、9月からは「実装の後」「提出の直前」にも当て直すようになった。

これまでのアプリは、先に作ってから後で違いを足す形が多かった。今回は、コードを書く前に発想の手順を通し、提出の直前にもう一度、数字で確かめている。手順の「入口」と「出口」の両方を、1本のアプリで通した形になる。

ちなみに、この記事の下書きのためにAIが記録を検索した範囲では、8月の1回のあと、4.3(a)で却下された記録は見つからなかった。ただ、これも6条件のおかげかどうかは確かめようがない。

提出前のチェックリスト

今回やったことを、ほかのアプリでも使える形にまとめておく。

企画のとき

• ストアの検索で、ジャンルの競合の数と上位のアプリを見ておく
• ジャンルの「当たり前の前提」を5〜10個書き出す（AIに手伝ってもらってOK）
• 1つだけ反転した案を複数出し、採らない案にも理由を書く
• 自分の別アプリと同じ仕掛けになっていないかも見る
• 「一文で違いを言えるか」「画像1枚で伝わるか」を見込みで採点する
• 最後に選ぶのは自分。AIには案と推奨と理由まで出してもらう

試作のとき

• 核のルールが「何も変わらない」ケース（今回は余裕0）を探し、問題の作り方の条件で外す
• 結果の表示などの数字が、ルール上いつも同じ値になっていないか見る
• 毎日の運用が要る機能など、作り切れない範囲は削る

提出の直前

• 6条件を全部採点し直す（1つ直しただけで済ませない）
• 競合をもう一度検索する（ジャンルの語、仕掛けの語、アプリ名の語。英語でも）
• 違いを自分のデータで数える（全問の集計など）
• 名前・サブタイトル・キーワードに、競合アプリの名前や既存の変種の名前を入れていない
• ストアの説明文の冒頭と、画像の1〜2枚目が違いを伝えている

以前の教訓

• 審査に出すビルドそのもので、データが届くかを見る
• 使わない機能の説明文や権限が、ビルドに残っていない
• ビルド番号を、ストア側で確かめた最大値と比べる
• 審査メモに想定される質問の答えを書き、画面収録を添付する
• マーケティングURLは、最初から最終のURLにしておく

こんな人に向いている

AIと一緒にスマホアプリを個人で作っていて、パズルや脳トレのような混み合ったジャンルに出したい人に向いている。特に、「作ってみたけど、ほかのアプリとどこが違うのか自分でも説明しにくい」と感じている人には、反転の手順と、提出前に数字で確かめるところが使えると思う。

一度でも「似すぎている」系の理由で審査に落ちたことがある人なら、次のアプリを作るときの入口と出口の確認として、そのまま使ってもらえるはず。

まとめ

混み合ったジャンルでも、当たり前を1つ反転すれば、遊びの中心の判断を変えられる。ただ、反転しただけでは足りなかった。試作の数字を見ると、余裕の無い問題は既存のパズルに戻ってしまう。そこを問題の作り方で外し、提出の直前に競合の調べ直しと全問の集計で確かめて、やっと「どこが違うのか」を数字で言える状態になった。審査に1回で通ったことは事実だけど、それが違いのおかげだったかは分からない。

項目	内容
結論	当たり前を1つ反転して核を決め、試作の数字で弱点を外し、提出の直前に競合の調べ直しと全問の集計で違いを確かめてから出した。1回の提出で公開されたが、審査の理由は分からない
教訓	「違いがある」は、言葉だけでなく自分のデータで数えて確かめる。競合と6条件の確認は、企画のときだけでなく提出の直前にもやり直す
対象読者	AIと一緒にスマホアプリを個人開発していて、混み合ったジャンルに新作を出したい人

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

• 混み合ったジャンルを選んだら、素のままでは出さないと先に決め、当たり前を書き出して1つだけ反転する
• 反転した案は、採らない理由まで書いて残す。後で「なぜこの仕掛けか」を説明する材料になる
• 試作したら、核のルールが効いていない問題（今回は余裕0）が混ざっていないかを数字で見て、作り方の条件で外す
• 提出の直前に、競合を日本語と英語で調べ直し、6条件を全部採点し直す
• 以前の失敗は、教訓として書くだけでなく、提出前に確かめる項目として次のアプリに持ち込む
• 審査に通っても、通った理由を自分の手順の成果だと決めつけない

次に読むなら

違いを確かめて出せるようになったら、次は「審査に出すビルドそのもの」が、確かめたものと同じかも見ておくと安心できる。

• テストでは問題なかったのに、配るビルドだけ違っていた話。R8・マニフェスト・Info.plistの3つの実例 — 開発中のビルドや実機の動きで確かめても、配るビルドの中身が違っていた3つの例と、配る前に「配るものそのもの」を確かめる手順が分かる

この記事のパズルを遊んでみる

この記事で作った一筆書きパズルは、ブラウザでも遊べるようにした（2026年10月27日から）。インストールは要らず、スマホでもパソコンでも開ける。遊び方とアプリ版の案内は、説明のページにまとめている。

• ブラウザ版の説明と遊び方

---

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