アプリの開発は完了しました。ブラウザではスムーズに動作し、UIも整い、コアフローも安定しています。しかし、いざデプロイとなると、シンプルなIonicプロジェクトは、それぞれ異なるツール、署名ルール、レビュープロセス、更新戦略を持つ3つのリリース経路へと姿を変えます。
ここで多くの時間が失われがちです。機能の実装ではなく、Native Build、Webホスティング、リリース自動化、そしてリリース後の修正を、推測に頼らずに繰り返せる一つのプロセスとして統合する作業に時間がかかるのです。 Ionicアプリのデプロイメント iOS、Android、PWAへの配信を別々のプロジェクトとして扱うのではなく、異なるアウトプットを持つ一つのリリースシステムとして捉えることで、最も効率的に運用できます。
目次
- Ionicアプリのビルドが完了しました。次は？
- プロダクションに向けたプロジェクトの準備
- iOS と Android への Native Build
- Ionic アプリを PWA としてデプロイする
- CI/CDパイプラインによるビルドの自動化
- Capgoによる即時アップデート
- デプロイ時の共通課題とベストプラクティス
Ionicアプリのビルド完了、次は何をすべきか
多くの開発者が同じ壁にぶつかります。 ionic serve 見た目はよく、ローカルで API の呼び出しも動き、アプリは完成したように感じられます。でも完成ではありません。ブラウザでテストしただけで署名もなく、App Store 審査、Play の署名、本番 Web ホスティングの制約から切り離されているだけです。
本番デプロイでは、問いが変わります。アプリが描画されるかではなく、 bundle が再現可能か、ネイティブプロジェクトが同期されているか、環境変数がきれいに分離されているか、リリース後にストア再申請の慌ただしさなしにネイティブ以外のバグを直せるか、が重要になります。
この変化が重要なのは、Ionic がハイブリッドな領域にあるからです。アプリには Web レイヤーがありますが、インストール、署名、審査、アップデートの方法を決めるのは依然としてネイティブシェルです。デプロイを後回しにするチームは、プラットフォーム間の設定ドリフト、古いままのネイティブプロジェクト、もろい手動リリース手順に陥りがちです。うまくやるチームは、全ターゲット共通のリリースパスを1つ定義し、各プラットフォーム固有のステップを明示します。
クリーンなデプロイライフサイクルは通常次のとおりです：
- プロジェクトの準備 Capacitor の設定、アプリ識別子、アイコン、環境変数、本番ビルドに一貫性を持たせます。
- ネイティブリリース用アーティファクトの作成 Ionic のコマンドだけでなく、プラットフォームのツールを使って Android と iOS 向けに作成します。
- PWA ビルドの配信 ブラウザですぐにアクセスしたいユーザー向け。
- 定型作業は自動化しましょう ビルドが、チェックリストを覚えている一人の開発者に依存しないようにするためです。
- リリース後のアップデートを計画しましょう Webアセットの修正が、待つ必要のないApp Store審査で止まらないようにするためです。
もし現在のアプリが「スマホのシェルで動いているだけのWebアプリ」のように感じられるなら、まずはそこから改善しましょう。その移行に役立つガイドはこちら： Capacitor を使ってWebアプリをモバイルアプリに変換する方法.
最初のストア申請を成功させる鍵は、テクニックではなく規律にあります。
プロジェクトのプロダクション準備
ビルドを生成する前に、プロジェクトをリリース候補（RC）として扱いましょう。デプロイの失敗の多くは、ローカル開発では問題なかった小さな不整合が、本番環境で大きな問題になることから起こります。
まずは環境チェックから始めましょう
まずは基本から実行しましょう：
ionic doctor
npm ci
npx cap doctorionic doctor よくある CLI や環境の問題を検知します。 npm ci よりも優れています npm install は、コミットされた lockfile から正確にインストールするため、リリース作業に適しています。 npx cap doctor Xcode や Android Studio で解読困難なエラーが出る前に、プラグインやプラットフォームの不一致を特定するのに役立ちます。
可能な限り、クリーンな状態からリリースビルドを行ってください。ローカルでのパッチ適用、フォルダの削除、またはネイティブファイルの直接編集を行わないとビルドできない場合は、デプロイプロセスがまだ安定していません。
毎回行うべきチェック項目がいくつかあります：
- アプリIDを確認してください。変更を
appId後回しにすると、ストアや署名に関する混乱を招く可能性があります。 - プラグインの状態を確認してください。ネイティブプラグインの変更には、通常、再同期（sync）や、場合によってはプラットフォームの再オープンが必要です。
- 環境変数の注入を確認する. API のエンドポイント、キー、機能フラグは、インラインの定数ではなく、環境ごとの設定から取得すべきです。
リリース先によって何が異なるべきか、より詳細な解説については、こちらの記事が Capacitor アプリにおける開発環境と本番環境の違い 実用的なリファレンスになります。
Capacitor の設定を保護し、
開く capacitor.config.ts アプリのメタデータではなく、本番環境のインフラと同様にレビューしてください。
一般的なファイル構成は以下の通りです：
import type { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
appId: 'com.example.myapp',
appName: 'My App',
webDir: 'www',
bundledWebRuntime: false,
};
export default config;すぐに確認すべき3つのフィールド：
| 設定 | なぜ重要なのか | よくあるミス |
|---|---|---|
| appId | ストアや署名で使用されるネイティブパッケージ識別子 | スタータープロジェクトのプレースホルダーが残っている |
| appName | ネイティブシェル上でユーザーに表示されるアプリ名 | 開発用ラベルのまま変更し忘れている |
| webDir | Capacitor がネイティブプロジェクトにコピーされるディレクトリ | Capacitor が想定している出力フォルダと異なる場所にビルドしている |
開発中にローカルのdev serverを使用している場合、本番用設定がネイティブビルドでそれを参照していないか確認してください。この一つのミスが「開発環境では動くのに、リリース版では画面が真っ白になる」というトラブルの多くを引き起こします。
実践ルール: リリースビルドがローカルのライブサーバー設定に依存しているなら、それはリリースビルドとは言えません。
アセットの生成は一度だけでOK
アイコンやスプラッシュ画面を手動でリサイズしないでください。高品質なソースアセットを1つ用意し、そこから各プラットフォーム向けのアセットを生成しましょう。
現在のCapacitorワークフローでは、多くのチームがCLIエコシステムを通じて公式のアセットツールを使用しています。使用するパッケージはスタックのバージョンによって異なりますが、基本的な考え方は同じです。単一のマスターとなるアイコンとスプラッシュのソースをバージョン管理下に置き、出力を生成した後、ストアへ提出する前にXcodeやAndroid Studio内で結果を確認します。
これにより、「PWAのアイコンは最新なのに、Androidは古いフォアグラウンドアセットを使用しており、iOSはフォルダの更新漏れで古い起動画像が表示されている」といった、よくある失敗を防ぐことができます。
確実なプロダクションへの移行には、以下も含まれます：
- Webアセットをプロダクションモードでビルドする。
- ネイティブプロジェクトを同期する。
- 各ネイティブIDEを開き、アプリ名、アイコン、権限、署名設定を手動で確認する。
- ストア向けにパッケージングする前に、実機でテストする。
iOSおよびAndroid向けのNative Deployment
Native deploymentとは、Ionicアプリが「単なるWeb」であることをやめ、各プラットフォームのルールに従い始める段階を指します。Web bundleは共有できますが、署名、パッケージング、ストアの要件が関わってくると、AndroidとiOSのプロセスはすぐに分かれます。
まずはWebレイヤーをビルドする
ネイティブパッケージングを行う前に、必ず最新のWebアセットを生成してください：
ionic build
npx cap sync未だにこう言うチームもあります ionic build --prod それは習慣によるものです。現代のプロジェクトでは、実際の動作は使用しているフレームワークのツールに依存しますが、原則は変わりません。最適化されたリリースビルドを生成し、それをネイティブプラットフォームに同期させることです。
同期後、ネイティブプロジェクトを直接開きます：
npx cap open android
npx cap open iosここも確認しておくべきポイントです Capacitor アプリのAndroidセットアップ プロジェクトのネイティブ設定が不安定な場合は、ここを確認してください。
Androidのリリースワークフロー
Androidのリリースパスは通常iOSよりも予測しやすいですが、署名設定が不十分だと問題が発生します。
アップロード用のkeystoreを一度生成し、安全に保管してください：
keytool -genkeypair -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias uploadkeystoreファイル、エイリアス、パスワードは必ず安全なシークレット管理ツールに保管してください。リポジトリへのコミットや、チームチャットへの放置は厳禁です。「誰かが保存しているだろう」という思い込みも避けてください。
次に、Gradleに署名設定を組み込みます。チームの自動化の度合いに応じて、 build.gradle ファイルで設定するか、Android Studioの署名UIを使用します。一般的な構成では、 signingConfigs ブロックと、それを参照するreleaseビルドタイプを使用します。
Play Storeへの提出に必要なリリース用アーティファクトは、通常デバッグ用のAPKではなく、 AABです。Android Studioでは、メニューから署名済みバンドルを生成し、releaseバリアントを選択してapp bundleをエクスポートします。CLIでのビルドを好む場合は、署名設定さえ済んでいればGradleで実行可能です。
Android開発でよくある落とし穴には、以下のようなものがあります：
- keystoreパスワードの間違い これにより、実際よりも深刻に見える署名エラーが発生します。
- デバッグ署名の残存 ローカルにはインストールできるものの、ストアリリースには適さないビルドが作成されてしまいます。
- プラグインの同期ずれ は、ネイティブプラグインの依存関係が変更された際に、同期をスキップすると
npx cap sync. - パッケージ名の不一致 は、Play Consoleのアプリエントリが異なる識別子で作成されている場合に問題を引き起こします。
推奨されるパターンは以下の通りです：web code をコミットし、webレイヤーをビルド、ネイティブを同期、ネイティブプロジェクトからリリース用アーティファクトをビルドし、生成されたbundleと共に正確なコミットハッシュをアーカイブします。
iOSのリリースワークフロー
iOSはより厳格であり、デプロイに関するトラブルの多くは code の問題ではなく、署名（signing identity）の混乱に起因します。
Xcodeでプロジェクトを開き、直接以下へ移動してください： Signing & Capabilities選択されているチームが正しいこと、bundle identifierが配信予定のアプリレコードと一致していること、そして自動署名が期待通りに動作しているか、あるいは意図的に手動プロビジョニングに置き換えられていることを確認してください。
通常、以下の要素を扱うことになります：
| 項目 | 機能 | よくある落とし穴 |
|---|---|---|
| Bundle identifier | アプリをApp Storeのレコードやプロビジョニングに紐付けます | Appleの期待する値と一致していません |
| Certificate | 署名者を識別します | 誤った証明書がインストールされているか、期限が切れています |
| プロビジョニングプロファイル | 特定のアプリとコンテキストに対してビルドを許可します | プロファイルがApp IDまたはチームと一致していません |
ローカルでのリリース作業では、Xcodeでアプリをビルドし、実機または汎用iOSデバイスのターゲットを選択してから、以下を選択してください アーカイブ. アーカイブが完了したら、Organizerウィンドウを使用して検証を行い、App Store Connectへ配布します。
Xcodeで署名エラーが発生した場合は、設定を変更する前に、正確なbundle ID、チーム、プロファイル名を確認してください。証明書をむやみに再生成すると、状況が悪化することがよくあります。
Macを持っていない場合でも、実際のiOSリリース用アーティファクトを作成するにはmacOS環境が必要です。実務では、ローカルのMac、クラウド上のレンタルMac、またはmacOSビルドを実行できるモバイルCI/CDサービスを利用して解決します。
このガイドは、最初のアーカイブと申請を行う前の予習として役立ちます：
苦労して学んだ教訓をもう一つ：可能な限り、生成されたネイティブファイルを不用意に編集しないでください。再現可能な設定は、適切なプロジェクト設定、プラグイン設定、またはビルドスクリプトに記述しましょう。ドキュメント化されていない手動の編集は、一度はリリースに成功しても、別の開発者がプロジェクトを同期した際に失敗する原因となります。
IonicアプリをPWAとしてデプロイする
PWAという選択肢は、Ionicアプリをユーザーに届ける最短ルートです。ストアの審査も、署名の儀式も不要です。ブラウザからすぐにアクセスしたいユーザーにとって、インストールの手間もありません。
ネイティブアプリがメインのチャネルである場合でも、このスピード感は有用です。多くのチームが、社内ツール、ログイン前の体験、管理パネル、あるいはストア経由のインストールがハードルとなる市場向けに、並行した配布手段としてPWAを活用しています。
Web向けに意図的にビルドする
PWAは、本番用のWebビルドから始まります：
ionic build重要なのはコマンドそのものではありません。出力が最適化されているか、本番環境のサービスを指しているか、そしてリリース予定の最終的なアセットとマニフェストが含まれているかを確認することです。
デプロイ前に以下のファイルを確認してください：
index.html正しいコンパイル済みアセットを参照している必要があります。manifest.webmanifest希望する本番用の名前、アイコン、表示設定になっている必要があります。- Service workerファイル オフラインキャッシュを利用する場合のみ存在する必要があります。
- 環境出力（Environment output） ローカルやステージングではなく、本番のエンドポイントを参照している必要があります。
オフライン動作の設定は慎重に
IonicスタックでAngularを使用している場合、オフラインサポートとキャッシュには通常Angular service workerを使用します。強力ですが、設定ミスが起こりやすい側面もあります。
キャッシュが強すぎるとユーザーに古いデータが表示され続け、弱すぎると接続が不安定な時にアプリの堅牢性が損なわれます。最適な設定はアプリによります。マーケティング向けのシェルアプリなら強力なキャッシュが可能ですが、データが頻繁に更新されるダッシュボードでは、より控えめな戦略が必要です。
オフラインサポートは単なるチェックリストの項目ではなく、プロダクトとしての意思決定として捉えてください。キャッシュすべき画面もあれば、常に最新データを取得すべき画面もあります。
Lighthouse的な想定だけでなく、実際のシナリオでテストしてください。アプリを一度開いてデバイスをオフラインにし、再起動して何がまだ動くか確認します。その後再接続し、ユーザーを古いUIに閉じ込めることなくService Workerが更新されることを確認してください。
ワークフローに合わせてホスティングを選ぶ
Ionic PWAの場合、通常は静的ホスティングプラットフォームで十分です。チームがよく選ぶ主な選択肢は、Netlify、Vercel、Firebase Hostingです。
実用面のトレードオフは次のとおりです：
| プラットフォーム | 最適 | 注意点 |
|---|---|---|
| Netlify | シンプルな静的デプロイとプレビュー | リダイレクトの挙動は明示的に確認が必要 |
| Vercel | Gitベースのワークフローを活用しているフロントエンド中心のチーム | アプリのルーティング設定に調整が必要な場合があります |
| Firebase Hosting | すでにFirebaseサービスを利用しているチーム | Firebaseに多くの役割を持たせすぎると、プロジェクト構造が複雑化する可能性があります |
どのプラットフォームでも、デプロイフローは似ています。リポジトリを接続し、buildコマンドと出力ディレクトリを設定、環境変数を追加し、リフレッシュ時にクライアントサイドのルーティングが壊れないようrewriteルールを確認します。
ルーターベースのナビゲーションを使用するIonicアプリの場合、ホスティング設定で一致しないパスをアプリのエントリポイントに返す必要があります。このrewriteが設定されていないと、ホームページは表示されますが、ディープリンクが失敗します。これはPWAデプロイにおける最も一般的なミスの一つです。
CI/CDパイプラインによるビルドの自動化
手動でのリリース作業は一度限りなら許容されますが、それ以降はリスクになります。同期ステップの忘れ、不適切なブランチからのビルド、誤った設定での署名などが発生すると、生成されたアーティファクトの信頼性が失われます。
CI/CDは、リリース手順を code に変えることでこの問題を解決します。記憶に頼るのではなく、アプリがどのようにビルド、同期、テスト、パッケージ化されるかを毎回正確に定義できます。
パイプラインに含めるべき内容
Ionicプロジェクトにおいて、有用なパイプラインは通常、以下のジョブを順番に実行します。
- lockfileから依存関係をインストールします。
- Webアプリをビルドします。
- Capacitor プラットフォームを同期します。
- テスト、または最低限のバリデーションを実行します。
- ターゲットプラットフォーム用のNative Build成果物を生成します。
- ビルド成果物を保存または公開します。
このフローでは、優れたインフラ構成の習慣も重要になります。ビルドランナーや成果物の保存、デプロイ手順に不安がある場合は、こちらの 小規模ビジネス向けの必須クラウド最適化ガイド をぜひ読んでみてください。モバイルのデリバリーパイプラインにも、同様の運用規律が求められるからです。
実践的な GitHub Actionsの構成例
多くのIonicチームがすでに GitHub 上で code を運用しているため、GitHub Actionsはデフォルトとして最適です。以下のワークフローは、Androidのリリースビルドの全体像を示しています。
name: Android Release Build
on:
push:
branches:
- main
jobs:
build-android:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node
uses: actions/setup-node@v4
with:
node-version: 20
- name: Install dependencies
run: npm ci
- name: Build web assets
run: npm run build
- name: Sync Capacitor
run: npx cap sync android
- name: Setup Java
uses: actions/setup-java@v4
with:
distribution: temurin
java-version: 17
- name: Build Android bundle
run: cd android && ./gradlew bundleReleaseKeystoreの素材やGradleの署名設定を提供しない限り、これ単体ではリリース署名は行われません。これは意図的な仕様です。署名プロセスは、公開されるワークフローファイルとは切り離して管理すべきだからです。
モバイルに特化した実装方法をお探しなら、こちらの記事が Capacitor アプリの CI/CD セットアップについて解説しています。
シークレットと署名の管理について
モバイル CI/CD で最も難しいのは YAML を書くことではありません。将来のインシデントを防ぎつつ、いかにシークレットを扱うかです。
以下の項目には、リポジトリまたは組織のシークレットを使用してください：
- Keystore パスワード
- Key alias
- エンコードされた Keystore ファイル
- リリース時に使用する API トークン
- 環境ごとのビルド値
Android でよく使われるパターンは、Keystore を base64 エンコードしてシークレットに保存し、ワークフロー内で復元して Gradle にそのファイルを指定する方法です。これは他の署名情報にも共通する原則です。ビルド時に注入し、リポジトリには決して保存しないでください。
CI/CDの目的はヒューマンエラーを排除することであり、一部のメンバーしか知らない「属人的な知識」を蓄積することではありません。リリースの秘匿情報（secrets）の構成を一人しか理解していない状態では、パイプラインは依然として脆弱なままです。
実用的な推奨事項として、バリデーションとリリースを分離しましょう。プルリクエストでは install、lint、テスト、web build を実行します。保護されたブランチや手動承認ゲートをトリガーにして、署名済みのプロダクション用アーティファクトを作成するようにします。これにより、通常の開発時はパイプラインを高速に保ちつつ、実際の配信時には制御されたリリースが可能になります。
Capgo でアップデートを即時配信する
アプリのバイナリを変更する Native code の変更や権限の変更には、ストア経由のリリースが不可欠です。一方で、Webレイヤーのみに存在するテキストの修正やスタイルの調整、JavaScriptのバグ修正などは、ストアリリースで行うべきではありません。
だからこそ、 OTA アップデート Ionic や Capacitor プロジェクトにおいて非常に重要です。変更内容が既存のネイティブシェルでサポートされている範囲内であれば、ストアの審査を待つことなく、インストール済みのアプリに更新されたWebアセットを配信できます。
OTAアップデートで対応すべき内容
以下のような変更には OTA アップデートを活用してください：
- JavaScript のロジック修正 新しいネイティブプラグインを必要としないもの
- CSSの調整 レイアウト崩れの修正やブランド更新に。
- 変更内容のコピー 文言、ラベル、法的テキストなど。
- 静的アセットの差し替え アプリ側で読み込み方法が既知の場合。
ネイティブ層の変更の回避策として使わないでください。新しいネイティブ依存関係の追加、権限の変更、またはストア審査済みのバイナリに含まれるべき変更を行う場合は、通常のストアリリースを行ってください。
この境界線は重要です。OTAの目的は、プラットフォームのルールを無謀に回避することではなく、コントロールを維持しながらスピードを実現することだからです。
トラブルが発生する前にチャンネルを設定しておく
最適なOTAワークフローには channelsの活用が不可欠です。productionチャンネルはユーザーに安定したアップデートを提供します。stagingやbetaチャンネルは、まずアップデートを受け取り、内部テスターが実機アプリで検証できるようにします。
このパターンを使えば、修正を急ぐあまり全員に直接配信してしまうという、OTAにおける最悪のミスを防げます。緊急の修正であっても、ガードレール（安全策）は不可欠です。
一般的なセットアップは、プラットフォームのドキュメントに従ったプラグインのインストールとアプリの初期化から始まり、次に環境ごとのチャネル割り当てを行います。 App Storeでも安全なOTAアップデート に関する記事は、適切な境界線を設定するための良いリファレンスになります。
Native codeに触れることなく、小さな修正をプッシュしましょう
アップデーターを統合すれば、実用的なワークフローは非常にシンプルになります。更新されたWebアセットをビルドして対象のチャネルに公開し、あとはアップデートポリシーに従って、アプリ起動時にそれらを取得・適用させるだけです。
モバイルレイアウトの崩れに対するホットフィックスの具体例を紹介します：
- IonicアプリのCSSを調整します。
- 本番用のWebビルドを実行します。
- 生成されたbundleをstagingチャネルに公開します。
- インストール済みのビルドでテストします。
- 同じ修正をproductionへ昇格（Promote）または公開します。
このアプローチによって、インシデント対応のあり方が変わります。OTAがなければ、Webレイヤーのバグが発生した際、ストアの審査や新しいバイナリのユーザーへの普及を待つしかありません。しかしOTAがあれば、影響を受けるファイルを修正して対象のユーザーに配信し、コントロールされた状態でロールアウトを進めることができます。
高速なアップデートは、安全にターゲットを指定でき、必要に応じてロールバックできる場合にのみ真価を発揮します。
OTAの恩恵を最も受けているのは、無謀なチームではありません。明確なリリース境界、命名されたチャンネルを持ち、Webレイヤーの修正をネイティブリリースとは別のストリームとして扱う習慣がある、規律あるチームです。
デプロイにおける一般的な問題とベストプラクティス
デプロイに関する問題の多くは、特異なものではありません。締め切りのプレッシャーの中で同じミスが繰り返されるため、多くのチームで共通して発生します。
頻発する失敗例
Androidの署名エラーは、通常、リリース設定におけるパスワード、エイリアス、またはkeystoreファイルの誤りに起因します。このような事態に陥ったら、むやみに認証情報を回すのはやめましょう。まずはファイル、エイリアス、およびシークレットの値が正しいか確認してください。
iOSのビルド失敗は、bundle identifier、チーム選択、証明書、およびprovisioning profileの不一致に遡ることがよくあります。Xcodeのエラーメッセージは難解に感じることがありますが、多くの場合、原因は単純な不一致です。いずれかの値が他の値と一致していません。
インストール後に画面が真っ白になるのも、よくある問題です。主な原因は以下の通りです：
- 本番アプリが開発用サーバーを指している bundled assetsではなく
- Web assetsが再ビルドされていない 前に
npx cap sync - プラグインの変更が同期されない ネイティブプロジェクトへの反映
- ランタイム環境変数の欠落 実際のリリースビルド内での発生
手戻りを防ぐリリースの習慣
ベストプラクティスは退屈だが、だからこそ効果がある。
環境設定の信頼できる唯一の情報源（Single Source of Truth）を維持しましょう。クリーンなブランチからビルドし、リリースコミットにはタグを付けます。署名用資材はリポジトリの外で管理してください。シミュレーターやブラウザだけでなく、実機でインストール済みのビルドをテストしましょう。ストアのメタデータは早めに準備し、スクリーンショットやプライバシーに関する回答、テキストの不足でデプロイが止まらないようにします。
もう一つの習慣が、多くの苦労を減らしてくれます。自動化が進んだ後でも、書面によるリリースチェックリストを保持しておくことです。Pipelineはアーティファクトをビルドしますが、アプリの説明が最新か、サポートURLが正しいか、あるいは最新のネイティブ権限の文字列がアプリの挙動と一致しているかまでは確認してくれません。
チームで Capacitor アプリをリリースしており、公開後にウェブレイヤーの修正をより安全に配信したいと考えているなら、 Capgo を検討する価値があります。これを使えば、チャンネル、制御されたロールアウト、ロールバック機能を備えた構造化されたOTAワークフローが手に入ります。これにより、JavaScript、CSS、テキスト、アセットの更新を、小さな修正のたびにApp Storeへの再申請を行うことなく配信できます。
