ストア配布アプリを公開するまでに、発注側が用意するもの ── 開発者アカウント、規約、審査の往復

「開発は終わっているのに、公開日が決まらないんです」。アプリの話で、後半に出やすい言葉です。

止まっている理由を聞くと、コードの話ではありません。法人の登録確認が終わっていない。プライバシーポリシーのURLがない。審査で指摘が返ってきて、誰が答えるか決まっていない。どれも開発会社では代われない、発注側の手元にある作業です。

アプリにするかWebにするかの判断はスマホアプリで作るか、Webで作るかに書きました。この記事はその続きで、アプリと決めたあとに、発注側が何を用意するかだけを並べます。

開発者アカウントは、自社の名義で作る

ストアにアプリを出すには、Apple と Google のそれぞれに開発者として登録します。最初に決めるのは、この登録を誰の名義でやるかです。

私たちの答えは、御社の名義です。ストア上のアプリの所有者はアカウントの名義人なので、開発会社の名義で公開すると、その会社と関係が終わったときにアプリの移管が要ります。移管には相手の協力が必要で、ここで詰まる話はその開発会社が続けられなくなったらに書いた名義の問題と同じです。

法人として登録する場合、両ストアとも法人であることの確認が入ります。2026年時点の公開情報では、D-U-N-S番号という企業識別番号を求められ、持っていなければ取得から始めます。取得にも登録の確認にも日数がかかるので、ここが最初の待ち時間になります。

費用の話もしておきます。Apple は年ごとの更新で、Google は登録時に一度の支払いという形です。金額はストアの案内で変わるので書きませんが、「年に一度、更新の請求が来るアカウントがある」ことは社内で共有しておいたほうがいい。更新が切れると、公開中のアプリがストアから消えます。

登録の管理者は、退職しない人にしてください。個人のメールアドレスで作ったアカウントの管理者が辞めて、二段階認証の端末ごと持って行った、ということが起きます。代表者か、情報システムの担当者か。ここは会社によって違うので断定できませんが、担当者個人の Apple ID や Gmail で登録するのだけは避けたほうがいい。

プライバシーポリシーと利用規約は、URLが要る

両ストアとも、公開の申請時にプライバシーポリシーのURLを入力する欄があります。文書があるだけでは足りず、Webのどこかに置いてある必要があります。

中身は、アプリが何の情報を集めて、何に使うかです。位置情報を使うなら位置情報、写真を撮るならカメラと写真、ログインがあるならメールアドレス。使う機能と一致していないと審査で止まります。下書きはこちらで作れますが、会社としての文言の確認は御社側の作業です。

加えて、ストアの申請画面には「このアプリはどんなデータを集めるか」を項目ごとに答える質問があります。Apple では App のプライバシー、Google では データセーフティ と呼ばれる欄です。回答するのは開発者アカウントの側なので、こちらから回答案を出して、御社に確認していただく流れになります。

ひとつ、見落とされやすい条件があります。アプリ内でアカウントを作れるなら、アプリ内でアカウントを削除できる機能も求められます。両ストアとも、この点は審査の項目に入っています。画面が1つ増えるので、設計の段階で数えておく必要があります。

ストアに載せる素材は、8種類ほど

審査に出す前に、ストアのページに載せるものを揃えます。並べると、こうなります。

用意するもの	誰が	補足
アプリ名	御社	ストア内で他と重複できない。商標の確認も御社側
アイコン	御社（デザインが無ければこちらで案を出す）	複数サイズ。角丸や余白の規定がある
スクリーンショット	こちら	端末サイズごとに枚数が要る。実画面から作る
説明文	こちらが下書き、御社が確定	短い説明と長い説明の2種類
カテゴリ・年齢区分	御社	質問に答える形式。業務アプリはほぼ最低区分
サポート用のURLと連絡先	御社	問い合わせ先が公開される
プライバシーポリシーのURL	御社	前の節のとおり
審査用のテストアカウント	こちら	ログインが要るアプリでは必須

アプリ名の重複は、意外と引っかかります。社内で呼んでいた名前がすでにストアに存在していて、公開の直前に名前を変えた、という流れは想像しやすいと思います。名前は早めに検索しておくほうが安全です。

審査で止まりやすいところ

審査の基準は両ストアが公開していて、しかも定期的に変わります。ここでは、業務アプリで実際に指摘が入りやすい種類だけ挙げます。

よく起きるのは、審査する人がログインできないことです。業務アプリはログイン前提なので、審査用のアカウントを申請時に渡します。渡し忘れると、中身を見てもらえないまま差し戻されます。

次に、権限の説明です。カメラや位置情報を使うとき、なぜ使うのかを利用者に見せる文言が要ります。「カメラを使います」だけでは足りず、「納品書を撮影するために使います」のように用途を書きます。ここは開発側の作業ですが、用途の言い回しは御社の業務を知っている人が見たほうが正確になります。

もうひとつ、社内の数十人しか使わないアプリを一般向けのストアに出そうとすると、「誰のためのアプリか」を問われることがあります。両ストアには限られた利用者だけに配る非公開の配布方法があるので、社内利用ならそちらのほうが収まりがいい。どの方法が使えるかは端末の管理状況で変わるので、契約前に確認します。

指摘が返ってきたときに誰が答えるかも、決めておくと早いです。技術的な指摘はこちらで返します。「このアプリは何のためのものか」という説明を求められたときは、御社の言葉で返したほうが通りやすい。

期間は、断定できません

正直に書くと、公開までの日数は読めません。順調なら開発が終わってから1〜2週間。法人の登録確認で待たされ、審査の指摘で2往復すれば、1か月を超えることもあります。審査そのものより、その前後の待ちのほうが長い。

だから順番を変えます。アカウントの登録と法人の確認は、契約した週に始めます。プライバシーポリシーの下書きは画面構成が固まったW2に出します。開発の終わりに合わせて準備を始めると、その分だけ公開が遅れるからです。8週間の中で発注側に何が発生するかは発注したあと、自分たちは何をするのかに書きましたが、アプリの場合はここに名義と規約の作業が足されます。

公開したあとも、手続きは続きます。OSが新しくなるたびに動作確認が要り、ストアの規約が変わればアプリ側の対応を求められることがあります。年に一度は、アカウントの更新も来ます。リリース後に何が発生するかは運用・保守の中身を項目ごとにのほうで分解しました。

私たちが引き取れる部分、引き取れない部分

ニカゲツでストア配布のアプリを作る場合、Flutter と Firebase で作っています。スクリーンショット、説明文の下書き、審査用アカウント、権限の文言、審査で返ってきた技術的な指摘への対応は、こちらの作業です。

引き取れないのは、名義と、会社としての判断です。開発者アカウントの登録、法人の確認、プライバシーポリシーの確定、アプリ名の決定、サポート窓口の設置。ここは御社の名前で御社が行うものなので、画面を見ながら一緒に進めることはできても、代わりにはなれません。

そして、正直に書いておくと、社内の人だけが使うアプリなら、ここまでの手続きに見合わないことが多いです。ストアに出す理由が「スマホで使いたい」だけなら、Webで作ってホーム画面に置くほうが、この記事に書いた作業を丸ごと省けます。ストア公開の事務だけを専門に請ける会社もあるので、その部分だけを切り出して頼むほうが早い場合もあります。

地味な手続きの話ばかりでしたが、ここで止まりやすいと考えているので、先に書いておきました。アプリが本当に要るかどうかから相談したい場合は、初回の60分でそこからお答えします。