アプリの納品が決まったとき、最初に頭に浮かぶのは画面や機能のことだと思います。ところが、あとから一番手間がかかるのは「このアプリは誰のアカウントで公開されているのか」という点なのだと、公式ヘルプを読んで気づきました。
私自身は個人開発で、自分のアプリを自分のアカウントから出してきました。そのため、アプリを他人の名義へ移管した経験はありません。この記事は、その前提で書いています。Apple と Google の公式ヘルプを読み、手元のサンプルプロジェクトで確認できる部分だけ実際に試しました。移管の実体験ではなく、「最初に何を決めておけば迷わないか」の整理だと受け取っていただければ幸いです。
最初にお伝えしたいのは、結論です。納品先のアプリは、最初から相手の開発者アカウントで作るのが、一番後戻りの少ない選び方です。 私はそう考えています。
先に決める選択肢は 3 つです
Rork で生成したアプリを相手に渡すとき、公開アカウントの持ち方は大きく 3 通りに分かれます。
| やり方 | 向いている場面 | 手間が出る場所 |
|---|---|---|
| 最初から相手のアカウントで作る | 相手がすでに開発者登録を済ませている、または一緒に登録できる | 相手に招待を出してもらう手間が最初に一度かかる |
| 自分のアカウントで公開し、あとで移管する | 登録が間に合わない、まず審査を通したい | 移管の条件確認と、紐づく設定の付け替え |
| 自分のアカウントで公開し続ける | 運用まで任される契約の場合 | 責任の範囲と、相手が離れるときの出口を決めておく必要がある |
2 つ目を選ぶときは、「移管できること」ではなく「移管すると何が引き継がれ、何が切れるか」を先に知っておくと、見積もりの段階で説明がつきます。
Apple：移管の条件と、止まりやすい場所
Apple の App Store Connect ヘルプには、移管の基準が一覧で書かれています。読んで手が止まりやすいと感じた箇所は次のとおりです。
- 移管するアプリは、App Store に出した版が少なくとも 1 つ必要です。まだ一度も公開していないアプリは移管できません。
- 予約注文（プレオーダー）の対象になっていると移管できません。
- 「審査待ち」「審査中」「リリース待ち」などの状態にあるあいだは移管できません。申請の途中で動かしたくなる気持ちはわかりますが、いったん状態が落ち着くのを待つことになります。
- アプリ内課金のIDが、受け取る側のアカウントにある別のアプリのIDと重なっていると移管できません。
- 送る側と受け取る側の双方が、最新の契約に同意済みである必要があります。
引き継がれるものとして、ヘルプには次の記載があります。移管後もアプリは App Store に出たままで、レビューと評価、Bundle ID はそのまま残ります。一方で、Bundle ID は一度ビルドをアップロードしたあとは変更できません。 ここは納品の最初に決めておく項目です。
付け替えが必要になるものも明記されています。
- 自動更新サブスクリプション：アプリ固有の共有シークレットを、移管を始める前に送る側が生成して渡す必要があります。
- TestFlight：ベータ版のテストはすべて止め、ビルドとテスターを外してから移管します。
- Sign in with Apple、プッシュ通知、Apple Pay、iCloud、Game Center など：それぞれ移管後に受け取る側で設定し直す手順が決まっています。
Apple のヘルプは「移管後、アプリは送る側のアカウントから消える」とも書いています。控えを取ってから始める、というのは大げさではなく必須の手順です。
Google Play：引き継がれないものを先に知っておく
Google Play のヘルプでは、移管は送る側が依頼を出し、受け取る側の所有者が承認する流れです。審査は、Google のサポートが 2 営業日以内に返答すると記載されています。
引き継がれるのは、ユーザー、統計、レビューと評価、サブスクリプション、提出済みのアプリのコンテンツ申告などです。一方で、次のものは引き継がれません。
| 引き継がれないもの | 移管前にやっておくこと |
|---|---|
| 売上・支払い・一括エクスポートのレポート | 先にダウンロードして、自分の手元に保管する |
| 移管前に作られた注文 | 返金は元のアカウント側で対応することになるので、期間を相手に伝えておく |
| クローズドテストのテスターグループ | 受け取る側で作り直し、テスターに再参加をお願いする |
| Google アナリティクス・Firebase などの連携設定 | 移管後に付け替える前提で、連携の一覧を作っておく |
また、受け取る側のアカウントは登録が完了している必要があり、新規に作る場合は登録料がかかります。アプリ内課金だけのアプリは、移管後にいったん非公開になり、再公開が必要になる点にも注意が必要です。
手元のプロジェクトで「自分の名前に紐づく設定」を洗い出す
公式ヘルプを読んでも、実際のプロジェクトのどこに自分のアカウントが入っているのかは、見ないとわかりません。Rork から書き出した Expo プロジェクトで、移管のときに確認が要る設定を一覧にする小さなスクリプトを書きました。サンプルのプロジェクトで動かして、期待どおり出力されることを確認しています。
// audit.mjs — 使い方: node audit.mjs <プロジェクトのフォルダ>
import { readFileSync, existsSync } from "node:fs";
import { join } from "node:path";
const dir = process.argv[2] ?? ".";
const read = (f) =>
existsSync(join(dir, f)) ? JSON.parse(readFileSync(join(dir, f), "utf8")) : null;
const app = read("app.json")?.expo ?? {};
const eas = read("eas.json") ?? {};
const submit = eas.submit?.production ?? {};
const rows = [
["Expo owner（EAS のアカウント名）", app.owner],
["EAS projectId", app.extra?.eas?.projectId],
["iOS Bundle ID（移管しても変わらない）", app.ios?.bundleIdentifier],
["Android package（移管しても変わらない）", app.android?.package],
["Apple ID（submit 設定）", submit.ios?.appleId],
["Apple Team ID（submit 設定）", submit.ios?.appleTeamId],
["ascAppId", submit.ios?.ascAppId],
["Play サービスアカウント鍵", submit.android?.serviceAccountKeyPath],
["Firebase iOS 設定ファイル", existsSync(join(dir, "GoogleService-Info.plist")) ? "あり" : undefined],
["Firebase Android 設定ファイル", existsSync(join(dir, "google-services.json")) ? "あり" : undefined],
];
for (const [label, value] of rows) {
console.log(`${value ? "要確認" : "なし "} ${label}${value ? `: ${value}` : ""}`);
}なぜこう書いたかというと、app.json の owner と eas.json の submit 設定は、気づかないうちに自分の名義が入りやすい場所だからです。Bundle ID と package は移管しても変わらないので「変えるものリスト」ではなく「変えないと確認するリスト」に入ります。Firebase の設定ファイルは、アカウントが変わっても自動では差し替わらないため、相手のプロジェクトで発行し直したものを入れることになります。
出力された「要確認」の行が、そのまま引き継ぎ書の項目になります。
見積もりの前に、相手に 4 つ聞いておく
移管を前提にするなら、契約の前に次の 4 点を確認しておくと、後の行き違いを減らせます。
- 相手はすでに Apple Developer Program と Google Play のデベロッパーアカウントを持っていますか。
- 持っていない場合、個人登録か法人登録のどちらで進めるおつもりですか（登録名がストアに表示されます）。
- 売上や課金の管理は、いつから相手が担いますか。
- 公開後に不具合が出たとき、アカウントの権限は誰が持っていますか。
この 4 点が決まっていれば、公開アカウントの持ち主は「最初から相手」で足りることが多いはずです。
明日、最初にやること
いま進めている案件があれば、プロジェクトのフォルダで node audit.mjs . を一度回して、自分の名義が入っている行の数を数えてみてください。その数が、移管をするときの作業量の目安になります。
Apple と Google の手順は更新されることがあります。実際に移管するときは、必ず各社の最新のヘルプで条件を確認してください。私もこの原則だけは、案件ごとに読み直すようにしています。