審査で「コードを送るとエラー」は無料サーバーの自動停止だった。提出前の確認8項目

審査官から返ってきた指摘は「確認コードを送るボタンを押すとエラーになる」でした。

直したのは、コード0行です。同じビルドのまま、出し直しました。原因は、ログインに使っていた無料の外部サーバーが「7日間使われていない」として自動で止まっていたことでした。

停止の予告メールは、数日前に届いていました。目にもしていました。それでも、その時は今の審査と結びつけられなかったのです。

想定読者: ログインやデータの保存に、無料枠の外部サーバー(データベースやログインの仕組みを貸してくれるサービス)を使っている個人開発者。

1. 何が起きたか

ログインは「メールアドレスを入れる → 確認コードが届く → 入力する」形でした。コードを送る処理は、自前の中継を挟まず、外部サーバーのログイン機能に直接つないでいました。

そのサーバーが止まっていたので、コードの送信が全員分失敗します。審査官が押したのは、ちょうどそのボタンでした。

却下の連絡には、ほかの指摘も並んでいました。ただ、よく読むと、課金の項目の差し戻しは、アプリ本体が却下されたことに引きずられて一緒に出ていただけでした。直す必要があった本題は、サーバーの停止1点です。

復旧は、サーバーの管理画面で「再開」のボタンを押すだけでした。同じ画面には「有料プランに上げる」ボタンもありますが、これはお金の判断なので、その場では押さず別に考えることにしました。

2. なぜ気づけなかったか

予告メールの名前が、アプリの名前と違った

サーバー側のプロジェクトには、作り始めの頃につけた英語の仮の名前が残っていました。ストアに出しているアプリの名前とは違います。

予告メールが来たとき、AIに相談すると「今の審査対応とは関係なさそうです。心当たりはありますか」と返ってきました。私もその場で結びつけられませんでした。そして、そのメールの対象こそが、審査中のアプリでした。

公開前のアプリは、自分が触らないと「使われていない」

公開前のアプリには、利用者がいません。自分で触らない日が続けば、サーバーから見れば「誰も使っていない」状態です。審査の待ち時間は、自分の手が止まる期間でもあります。

エラー文が原因を語らない

アプリのエラー表示は、サーバーから返ってきた内容をそのまま出す作りでした。「サーバーが止まっています」とは書かれません。審査官の報告も「エラーになる」以上の情報はありません。

3. 実際にやった切り分けの順番

ここが、この記事でいちばん持ち帰ってほしい部分です。コードを疑う前に、5分で白黒がつく確認があります。

手順1: ログインがどこにつながっているかを確かめる

助っ人のAI(サブエージェント)に、ファイルを変更しない読むだけの調査を頼みました。結果は「ログインは外部サーバーの機能に直接つながっている。サーバーが止まると、届いた返事をそのままエラーとして出す」。これで、疑う先がサーバーに絞れました。

頼んだ中身は、次のような形です。ポイントは「原因ごとに、利用者に何が見えるか」を、コードの場所つきで答えさせることです。審査官の報告は短いので、画面に出る言葉から逆にたどれるようにします。

ファイルは変更しないこと。調べて報告するだけ。

1. ログイン(確認コードの送信)が、どのサーバーのどの機能につながっているか
2. 次の場合に、利用者の画面に出るエラー文と、その処理の場所(ファイル名と行番号)
   (a) サーバーが止まっている・つながらない
   (b) 回数制限にかかった
   (c) そのほか考えられる原因

3. 使ったことのないメールアドレスで操作したとき、どこで失敗しうるか
報告は400語以内で。

報告では、止まっているときは、届いた返事の中身や番号をそのまま見せる汎用の文になる、とのことでした。審査官が「エラーになる」としか書けなかったのも、これで説明がつきます。

手順2: サーバーの「住所」が引けるかを確かめる

ネットの住所(ドメイン)は、電話帳のような仕組みで実際の行き先に変換されます。この変換を確かめるコマンドが nslookup です。

nslookup <サービス本体のドメイン>
nslookup <自分のプロジェクト専用のドメイン>

結果はこうでした。

• サービス本体のドメインは、普通に引けた

• 自分のプロジェクト専用のドメインは「そんな住所は無い」(NXDOMAIN)と返ってきた

サービス全体は動いているのに、自分の分だけ電話帳から消えている。私の場合、これが自動停止の症状でした。ここで原因が確定しました。

手順3: 管理画面で再開し、住所が戻るのを確かめる

再開ボタンを押したあと、同じ nslookup をもう一度打ちます。住所が引けるようになるまで、再提出はしません。

手順4: コードを変えていないなら、同じビルドで出し直す

直したのはサーバーの状態だけで、アプリの中身は1行も変えていません。新しいビルドは作らず、そのまま再提出しました。

4. 提出前の確認8項目(コピーして使えます)

審査に出す直前と、審査の待ちが長引いたときに見ます。

□ サーバーを使う機能を書き出した(ログイン・保存・送信・同期など)
□ サーバー側のプロジェクト名と、アプリ名の対応をメモした
□ サーバーの事業者からのメールを「停止」「一時停止」「pause」「inactive(使われていない、の意味)」で検索した
□ 管理画面で、プロジェクトの状態が「動いている」になっている
□ nslookup で、自分のプロジェクト専用のドメインが引ける
□ 審査官と同じ操作を1回やった(使ったことのないメールアドレスでコードを送る、など)
□ 審査待ちが長引いたら、上の2つをもう一度やる
□ 「有料プランに上げる」は、再開とは別の判断として分けた

2つ目の対応メモが、地味に効きます。私が予告メールを流したのは、名前が違って自分ごとに見えなかったからです。

5. 審査官が「サーバーを使う操作でエラー」と言ってきたときの判断フロー

審査官の指摘が、ログイン・送信・保存など
サーバーを使う操作のエラーか?
 ├ いいえ → 普段どおりコードと画面を調べる
 └ はい → 自分のプロジェクト専用ドメインを nslookup
      ├ 引けない → 管理画面を見る
      │    └ 停止中 → 再開 → 引けるのを確認
      │         → コード未変更なら同じビルドで再提出
      └ 引ける → 使ったことのないアドレスで同じ操作を再現
           └ 再現する → ここで初めてコードを疑う

却下の連絡に複数の指摘が並んでいても、まず「根っこが1つではないか」を見ます。私の場合、並んだ指摘のうち、この回に手を動かして直す必要があったのはサーバーの停止でした。

6. 限界

• 自動停止の条件(何日で止まるか、予告が来るか)は、事業者とプランで違い、変わることもあります。この記事は、執筆時点で私が使っていた1つの無料枠での話です

• 「住所が引けなくなる」のは、私が見た1件の症状です。止まり方が違う事業者もあり得ます

• この確認をしても、ほかの理由で却下されることはあります。審査に通ることは保証できません

• 審査中にサーバーを触り続ける仕組み(定期的に自動でアクセスするなど)は、私は作っていません。効くかどうかも確かめていないので、ここでは勧めません

サーバーの停止は、審査の待ち時間に起きる事故の1つにすぎません。審査に通ったあとに見つかった事故(別の物の値を出していた、課金のキーがビルドに入っていなかった、検査が空振りしていた など)と、提出前・公開当日のチェックリストは有料記事にまとめています。→ 審査に通ったのに壊れていた。個人アプリで踏んだ10の事故と、提出前14項目・公開当日8項目のチェックリスト