ストア提出の下ごしらえ：Android（Play Consoleとサービスアカウント）
Androidでは、まずGoogle Play Consoleでアプリを作成し、EAS Buildで生成するAABの受け皿を用意します。このとき、提出するAABのパッケージ名がapp.jsonのandroid.packageと一致していることも確認しておきます。
Google Playへ提出する操作を行うのは、開発者本人ではなくEASです。そのため提出の認証には、個人のGoogleアカウントではなく、プログラムからの操作専用の「サービスアカウント」を用意します。サービスアカウントはGoogleのクラウド基盤であるGoogle Cloudの機能で、リソースの入れ物である「プロジェクト」の下に作成します。業務でGoogle Cloudを使っていなければ、この提出用に新しいプロジェクトを1つ作ってしまって構いません。
準備の流れは大きく3ステップです。（1）Google Cloud Consoleの「IAMと管理」でサービスアカウントを作成し、JSON形式のキーを発行する、（2）同じプロジェクトでGoogle Play Developer APIを有効化する、（3）Google Play Consoleの「ユーザーと権限」からサービスアカウントのメールアドレスを招待し、対象アプリのリリースを管理できる権限を付与する、という順です。JSONキーを作っただけでは提出できず、（3）の権限付与まで完了させる必要がある点に注意してください。
ダウンロードしたJSONファイルには、サービスアカウントの秘密鍵が含まれています。eas submitはこのファイルを認証情報として参照しますが、プロジェクト直下に置く場合は.gitignoreに追加して、リポジトリへ含めないようにします（リスト1）。
# Google Play Consoleへの提出用サービスアカウント google-service-account.json
なお、Googleまわりの手順は変化の速い領域です。かつて必須だった初回AABの手動アップロードは現在のEAS Submitでは不要になり、以前の「APIアクセス」ページでのリンク作業も「ユーザーと権限」からの招待方式に置き換わりました。古い解説記事とは手順が食い違うことがあるため、実際に設定する際は、Expo公式のAndroid提出ガイドと、Google Play Developer APIの利用開始ドキュメントを一次情報として参照してください。
iOSはApp Store Connect API Keyという認証情報の準備が主であるのに対し、AndroidはGoogle Play Developer APIから操作するロボット用アカウントの発行と権限付与が主になります。受け皿と認証情報を一度整えれば、提出はiOSもAndroidも同じEAS CLIの操作体系に寄せられます。
eas.json のsubmitプロファイル
前回（第10回）では、各プロファイルの詳細なカスタマイズは第11回で扱うと予告しました。この章ではその予告通り、ビルド成果物の性質を決めるbuild.productionと、完成した成果物の提出先を決めるsubmit.productionを順に見ていきます。
ビルド番号やストアごとの認証情報をコマンド実行のたびに手作業で指定すると、提出先を間違えたり、チーム内で手順がばらついたりしがちです。これらをeas.jsonにまとめておけば、ビルドから提出までの設定をプロジェクトと一緒に管理できます。
productionビルドプロファイルを読み解く
まず、第10回で作成したeas.jsonのうち、productionに関係する部分を再掲します（リスト2）。build.productionに設定したautoIncrement: trueが、ストア提出用のビルドで重要になります。
{
"cli": {
"version": ">= 18.6.0",
"appVersionSource": "remote"
},
"build": {
"production": {
"autoIncrement": true
}
},
"submit": {
"production": {}
}
}
autoIncrement: trueを指定すると、EAS Buildのたびに、iOSのビルド番号やAndroidの versionCodeを自動で繰り上げます。さらにappVersionSource: "remote"によって、その番号をEAS側で管理します。手元のapp.jsonを毎回書き換えて番号を合わせなくても、EASが管理する番号を基準に更新できるため、複数人でビルドする場合にも向いています。
このproductionプロファイルでビルドすると、Androidでは.aabを、iOSではApp Store用の .ipaを生成します。previewで使う内部配布向けの成果物とは異なり、ストアへ提出することを前提にした最終成果物です。3つのプロファイルの違いは、「最初に誰へ届けるか」で整理すると分かりやすくなります（表1）。
| プロファイル | 最初に届ける相手 | 主な目的 |
|---|---|---|
| development | 開発者の手元 | Metroと接続しながら実装を確認する |
| preview | 社内テスター | 本番に近い構成でレビューや受け入れテストを行う |
| production | ストア | 利用者に配布する最終成果物を提出する |
EAS Buildでは、同じアプリでも配布先に合わせたプロファイルを選ぶだけで、ビルドの目的を切り替えられます。ローカルで署名や配布方法を切り替える手順を個別に用意するより、チームで同じeas.jsonを参照できる点が便利です。productionで作った.aabや.ipaを、次はsubmitプロファイルの設定に従ってストアへ送ります。
submitプロファイルを書く
ビルドプロファイルが「どのような成果物を作るか」を定めるのに対し、submitプロファイルは「どこへ、どの認証情報で、どの状態で提出するか」を定めます。iOSとAndroidではストアの認証方式が異なるため、プラットフォームごとに設定を分けます（リスト3）。
{
"submit": {
"production": {
"ios": {
"ascAppId": "1234567890",
"appleTeamId": "ABCDE12345",
"ascApiKeyPath": "./AuthKey_ABC123XYZ.p8",
"ascApiKeyIssuerId": "01234567-89ab-cdef-0123-456789abcdef",
"ascApiKeyId": "ABC123XYZ"
},
"android": {
"serviceAccountKeyPath": "./google-service-account.json",
"track": "internal",
"releaseStatus": "draft"
}
}
}
}
iOSのascAppIdには、App Store Connectの「アプリ情報」に表示される「Apple ID」の数字を指定します。appleTeamIdはApple Developer ProgramのチームIDです。App Store Connect API Keyを使う場合は、前章で用意した .p8ファイルのパスをascApiKeyPathに指定し、Issuer IDはascApiKeyIssuerIdに、キーIDはascApiKeyIdに指定します。API Keyの実体や.p8ファイルをリポジトリに含めない点は、前節で説明したとおりです。
AndroidのserviceAccountKeyPathには、前章のリスト1で.gitignoreに追加したgoogle-service-account.jsonを指定します。trackは提出先のトラックで、internal、alpha、beta、productionの4種類があります。最初の提出では、まずinternalから始めることを推奨します。限られたテスターに配布して動作を確認してから、段階的に公開範囲を広げられるためです。
releaseStatusはトラック内でのリリース状態を指定します。リスト3ではdraftとして、Play Console側で内容を確認してから次の操作へ進める例にしています。提出先と認証情報がeas.jsonに揃っていれば、ストアごとに異なるアップロードツールへ持ち替えず、iOSとAndroidを同じeasコマンド体系で扱えます。
ビルドプロファイルとsubmitプロファイルはproductionのように名前で対応します。この対応関係は、次回扱う予定のeas build --auto-submitで重要になります。まずは対応関係を押さえたうえで、次の章から実際に成果物をストアへ提出してみましょう。
