App Storeの審査を待たずに Capacitor の修正をリリース
朝8時、チェックアウトページでCSSのレイアウト崩れが発生。パニックが始まります — iOSリリース、Androidリリース、ネイティブの再ビルド、そして数日間のレビューが必要です。もうそんな時代ではありません。
新しいWebバンドルをビルドして管理下のCapgoチャネルにプッシュするだけで、互換性のあるデバイスがアプリストアの審査キューに一切触れることなくダウンロードできます。 CSS、JavaScript、コピー、アセットの修正は数分でユーザーに届きます一方、ネイティブの変更は従来どおりバイナリリリースの経路をたどります。
目次
Live File Update が有効なケース
live update は、ネイティブシェルに問題がなく、Webレイヤーの修正が必要な場合に有効です。CSSの配置問題なら、スタイルシートを修正してWebアセットを再ビルドし、署名付きバンドルを公開します。バグ発覚から1時間後の午前9時までに、ユーザーは次のアプリ起動時に修正版を受け取れます。Capgo はアップデータを通じてバンドルを適用し、ネイティブバイナリには一切手を加えません。
どのルートを選ぶかは、次のように判断しています。
- live update を使用する JavaScript の挙動、CSS、テキスト、設定、互換性のあるアセットに使用します。
- ネイティブリリースを使用 プラグインの変更、権限、ネイティブ依存関係、OS レベルの機能に使用します。
- チャネル経由でテスト すべての顧客に修正を公開する前に。
| リリースタイプ | 一般的な用途 | ユーザーへの影響 |
|---|---|---|
| ネイティブパッケージ | 新しいネイティブ機能 | ストアでのダウンロードと審査 |
| ライブ Web バンドル | 緊急互換性修正 | アプリ起動時の更新 |
ネイティブ層とWeb層の互換性を保つ。 ライブバンドルは、インストール済みのバイナリに存在しないネイティブAPIを安全に導入できません。新しいプラグインの追加や権限の変更はネイティブビルドを必要とします。回避策はありません。
段階的なデプロイ手順については、 このCapgoホットフィックスのデプロイガイドをおすすめします。テスト済みの修正から制御されたリリースへ移行する流れを、本番ユーザーをQAチーム扱いせずに進められるよう解説しています。
本番環境にアップデートをプッシュする前に、まずローカルビルドを固めておきましょう。インストールするのは Capgoのオープンソース・アップデータプラグインです。次にTypeScriptパッケージを追加して、エディタがアップデータのメソッドを正しく認識し、型が見つからないエラーを出さないようにしましょう。Capacitorプロジェクトなら、こちらの ローカルCapacitor環境のセットアップガイド はブックマークする価値があります。クリーンなワークスペースの準備手順が解説されています。
Web アセットを予測可能に保つ
ライブバンドルに含まれるのはコンパイル済みのWebアセットだけで、編集する可能性のある任意のソースファイルは含まれません。ビルドコマンドが常に最終的なJavaScript、CSS、HTML、および互換性のあるアセットを同じ www または public ネイティブシェルが参照するディレクトリです。
実際の運用ではこうなります。チェックアウトのスタイルシートを変更したら、通常のWebビルドを実行し、出力ディレクトリを確認して、生成されたファイルが以前のバージョンを置き換えていることを確認してください。コンパイル済みファイルを直接編集しないでください。次のビルドで黙って上書きされ、変更が失われても気づかないままになります。
live update は、Webビルドに含まれるものしか配信できません。 修正が含まれていない場合
wwwまたはpublicデバイスはそれを受け取れません。
開発、ステージング、本番用に個別のチャンネルを設定してください。開発用buildは本番チャンネルを指すべきではありません。特に複数のチームメンバーが未完成のbundleを同時にテストしている場合はなおさらです。
- 開発 先に進む前に、importの破損やアセットの欠落を検知します。
- ステージング リリースに近い設定で、実機での挙動を検証します。
- プロダクション 承認済みでテスト済みのbundleだけを配信し、実験的なものは一切配信しません。
公開前に Bundle を検証する
何かをuploadする前に、簡単な整合性チェックを実行しましょう。これにより、ユーザーに届いてしまう問題のほとんどを検知できます：
- 以前のビルド出力を削除し、新しいビルドを作成します。
- 修正されたファイルが出力ディレクトリに実際に存在することを確認します。
- 変更した機能だけでなく、ナビゲーション、ログイン、オフライン動作、ネイティブプラグインの呼び出しもテストします。
- iOSとAndroidの両方のテストデバイスにバンドルをインストールします。
- 後で問題を再現できるように、テスト中に使用したチャネルとバンドルバージョンを記録します。
Electron チームも同じ原則を適用できます。レンダラーアセットを個別にビルドし、パッケージ化されたアプリが想定した出力ディレクトリを参照していることを確認します。Capgo の型付き API とチャネル制御により、このワークフローを一貫して繰り返しやすくなりますが、実際の互換性テストの代わりにはなりません。変更に新しいネイティブプラグインや権限が必要な場合は、ライブ Web バンドルとして配信しようとせず、新しいバイナリを公開してください。アップデータはネイティブ code を単独で変更できません。
Capacitor と Electron アプリでファイル更新を正しく行う鍵は一つ、堅牢なリリース成果物です。すでにテストした正確なコミットから Web レイヤーをビルドし、すべての JavaScript、CSS、HTML、アセットが www または public 想定どおりに配置されていることを確認してください。Electron を使っている場合は、レンダラーを単体でビルドし、パッケージ化されたシェルがその出力を指していることを確認してください。
検証可能な Bundle の作成
アップロードする前に、まず古いビルド出力をすべて削除し、プロダクションビルドを新規に実行してください。その際、コミットハッシュ、bundleバージョン、配信先channel、native appのバージョンを併せて控えておきましょう。これらの情報を記録しておけば、後で不整合が起きたときに何時間も悩まずに済みます。
必ず実機（iPhone、Android端末、Electron環境）でbundleを確認してください。ログイン、ナビゲーション、オフラインモード、そして更新したファイルに関わるすべてのnative pluginを一通り操作してテストします。アップデートサーバーへのアップロードが成功しても、デバイス上で実際に動かなければ意味がありません。
Signingによって、アーティファクトに暗号学的な指紋が付与されます。Updaterはその署名をもとに、bundleがリリースパイプラインを通じて改ざんされずに届いたことを確認します。署名用の認証情報はリポジトリの外に完全に保管し、アクセスできる人を限定し、セキュリティポリシーが定めるスケジュールでローテーションしてください。
署名済みのbundleは、テストの代わりにはなりません。 Signingはアーティファクトの出所と改ざんされていないことを証明するもので、アプリが実際にそのbundleで正常に動作するかについては何も示しません。
全体像を把握したいなら、次の記事を読むのがおすすめです： Capgoのエンドツーエンドセキュリティとcode signingのガイド.
制御された Channel 経由の公開
署名済みbundleの準備ができたら、Capgoにアップロードし、ロールアウト戦略に合ったchannelに割り当てます。特によく使うのは次のchannelです：
- ベータ — 社内スタッフや選ばれたテスター向け
- ステージング — 実際のユーザーに公開する前に、本番に近い環境で検証するため
- プロダクション — 承認された対象ユーザー向け
- 顧客専用のチャンネル — テナントごとに独立した更新タイミングが必要な場合
よくあるシナリオです。あるフィンテックチームが、本番環境で決済ラベルの表示崩れを発見しました。修正済みのWeb bundleを社内チャンネルにプッシュし、数台のデバイスでチェックアウト動作を確認します。その後、テスト済みの同じアーティファクトを本番の小規模セグメントにプロモートしてから、より広くロールアウトします。こうしたチャンネルのガードレールがあることで、急ぎの修正が大規模なインシデントに発展するのを防げます。
公開後は、ダッシュボードの集計ステータスだけに頼らず、デバイスごとのログを詳しく確認してください。正しいアプリバージョンがbundleを取得したか、署名が検証されたか、インストールが正常に完了したか、そして次回の起動で新しいファイルが実際にロードされたかを確認します。
デバイスで不一致が報告された場合は、直ちにそのチャンネルを停止し、bundleのバージョン、ネイティブとの互換性、署名キー、チャンネル割り当てを横並びで比較してください。テストグループのログに問題がないことを確認してから配布範囲を広げ、ロールバック用に常に以前のbundleを保持しておきましょう。
ローカルでのbuildがスムーズに動くようになったら、次は公開プロセスをCI/CD pipelineに組み込みましょう。目標はシンプルです。Webアセットをbuildし、bundleに署名し、テスト通過後に自動でpublishすることです。もう手動でのuploadは必要ありません。マージ後にどうやってファイルを更新すればいいか悩むこともありません。プロセスがすべて処理します。
実際のパイプラインの構成例は以下の通りです：
- リリースブランチがターゲットブランチにマージされたタイミングでジョブを実行します。
- 依存関係をインストールし、クリーンな
wwwまたはpublicbuildを生成します。 - ユニットテスト、統合テスト、デバイスでのスモークテストを含む、すべてのテストスイートを実行します。
- CIのシークレットマネージャーに保存されている認証情報を使用して、bundleに署名します。
- Capgoの公開API経由で、betaまたはstagingチャンネルにプッシュします。
- 検証チェックに合格したら、まったく同じアーティファクトをそのまま昇格させます。再ビルドはしないでください。
繰り返しになりますが、署名鍵やAPIのtokenをリポジトリにコミットしないでください。これらは保護された環境変数として保存し、本番公開は承認されたブランチのみに制限し、すべてのリリースをbundleバージョン、コミットハッシュ、ネイティブアプリのバージョン、配信先チャンネルとともにログに記録してください。Capgoの GitHub Actions統合ガイド では、この設定をエンドツーエンドで行う方法を解説します。
ここでのポイントは、 バリデーションはデリバリープロセスの一部であり続けることです。公開がゴールではありません。パイプラインで、意図したデバイスが実際にバンドルを受信・受け入れたことを確認すべきです。
Differential Updates で転送コストを削減
毎回フルバンドルを配信するのは無駄です。リリースがスタイルシートやJavaScriptモジュール数個の変更しかない場合、差分配信を有効にして、デバイスに変更されたファイルのみをダウンロードさせましょう。ただし、削除やリネームされたアセットの扱いをテストしてください。そうしないと本番環境で不愉快な問題が起きます。
この方法を実践したあるエージェンシーは、フルリバンドルから増分配信へ切り替えたことで、平均帯域幅コストを 47% 削減しました。最大のメリットは低速接続のユーザーで、ダウンロードサイズが小さくなったことでインストール時間が明らかに短縮されました。
また、エクスポージャーを制御するために別々のチャネルを使うことをお勧めします：
- ベータ は内部ビルドを受け入れ、テスターのフィードバックを集めます。
- ステージング は本番環境の設定を反映しますが、顧客への影響はありません。
- プロダクション 限られたユーザーから始め、徐々に拡大していく。
- 顧客チャネル テナント固有のリリースを相互に分離する。
テスト済みの成果物を昇格させる。ステージ間で再ビルドしない。 環境ごとに再ビルドするとドリフトが発生し、存在すべきでない差異のデバッグに追われることになる。
フィンテックアプリのような場合、フローは次のようになる。まず従業員に公開し、次に適格ユーザーの5%にリリース、デバイス別のログを確認し、採用状況が健全で失敗率が安定している場合のみ拡大する。常に以前のbundleを保持しておく。問題が発生した場合、数時間ではなく数分で一時停止またはロールバックできる必要がある。
bundleの公開は中間点に過ぎない。ユーザーが実際に更新を受け取ったことを確認するには、Capgoのデバイス別ログを開き、ネイティブバージョン、チャネル、bundleバージョン、署名検証、ダウンロード状態、インストール結果を確認する。
健全なロールアウトでは、ダウンロード完了だけでなく、インストール後の正常な起動が表示されるべきである。チェックアウト修正の場合、複数のデバイスで実際の購入フローをテストし、その結果を低速接続や古いアプリバージョンのユーザーからの報告と比較する。
Update シグナルを正しく読み取る
採用率と失敗率を併せて確認してください。ダウンロード率が高いのに起動失敗が繰り返される場合は、バンドルが壊れている可能性を示します。一方、採用率が低い場合は、チャネルのターゲティング、オフラインのデバイス、またはアップデーターの設定問題が原因である可能性があります。
| シグナル | 通常の意味 |
|---|---|
| ダウンロード済み | デバイスがバンドルを取得しました |
| インストール済み | ファイルがインストールチェックを通過しました |
| 正常に起動しました | アプリが新しいファイルで開かれました |
| ロールバック済み | 以前の既知の正常なバンドルが復元されました |
ダウンロードだけでなく、正常な起動を追跡してください。 ユーザーがアプリを正常に開いて使用できる場合のみ、アップデートは運用上成功したとみなされます。
Capgoの自動ロールバック保護は、新しいbundleがクラッシュや起動不能を引き起こした場合のセーフティネットとして機能します。以前のバージョンを保持し、影響を受けたチャネルを一時停止して、別のアーティファクトをプロモーションする前にログを調査してください。
ビデオのバージョン管理は、ライブ配信パイプラインにおけるファイル更新の監視やロールバックの管理と概念的に共通する部分があります。そのため、チームは以下を行う際にもこれらのアイデアが役立つかもしれません。 トレーニングビデオのバージョンを管理する.
リリースを検証
リリース後の短いチェックリストを使用してください：
- チャネルとアプリバージョン別の採用状況を確認します。
- ダウンロード失敗、署名エラー、起動失敗をレビューします。
- 変更されたワークフローを物理デバイスでテストします。
- エラーの発生タイミングをリリースタイムスタンプと比較します。
- 失敗が予期せず増加した場合、配信を一時停止します。
- 最終バンドル、コミット、ロールバックの判断を記録します。
より詳しいガイダンスについては、 Capacitor アプリで OTA アップデートを監視する方法をご覧ください。これにより、ファイル更新は公開タスクから管理された運用プロセスへと変わります。
Live Update はストアの規約に従うか？
Live Updates が最も適しているのは、 JavaScript、CSS、コピー変更、設定の微調整、互換性のあるアセットです。ネイティブ機能の追加、権限の変更、ストア審査の回避のための裏口ではありません。公開する前に、アプリのカテゴリに応じた Apple と Google のポリシーを必ず確認してください。
Differential Updates はどうやってダウンロードを減らすのか？
差分配信では、Web バンドル全体ではなく、実際に変更されたファイルだけを送信します。たとえば、チェックアウトページのスタイルシートを1つ変更したとします。無関係なアセットをすべて一緒に再送信する必要はありません。これにより、転送が速くなり、帯域幅の消費も減ります。
ただし、名前変更や削除されたファイルには注意してください。以前のバージョンから残った古いアセットは、追跡が難しい奇妙なバグを引き起こす可能性があります。
小さなパッチでも、完全な互換性テストが必要です。 ダウンロードサイズが小さくても、ユーザーフロー全体を検証する必要性は変わりません。
デバイスがオフラインのときはどうなる？
オフラインのデバイスは、インストール済みのバンドルをそのまま実行し続けます。接続が回復すると、アップデータは割り当てられたチャネルを確認し、最新の互換性のあるリリースを取得します。すべてのデバイスが即座に更新されるとは限らないので注意してください。接続が不安定な現場のチームは、しばらく更新が遅れる可能性があります。
Breaking Changes にはどう対処すべき？
ネイティブバイナリとWebバンドルは、ペアとして考えるべきです。更新されたWebファイルが、現在インストールされているバイナリに存在しないネイティブメソッドを呼び出す場合、まず新しいネイティブリリースを配信し、その上にWeb更新をプッシュする必要があります。
ベータ、ステージング、本番環境用に個別のチャネルを運用してください。各デバイスが意図したチャネルを正しく受信しているか、必ず確認しましょう。署名の不一致が発生した場合、それは通常、改ざんされた成果物、誤った認証情報、または設定の問題を示しています。配信を一時停止し、公開したものとテストしたものを比較し、再試行する前にデバイスログを詳しく調べましょう。
実用的なデプロイワークフローについては、 Capgo をご覧ください — 署名付きリリース、チャネル制御、差分配信、ロールバック保護を提供し、ファイル更新の煩雑さを解消します。
