Capgo 環境のベストプラクティス：1つのMobile App IDでステージング

モバイル環境の構築には、通常以下の3つのアプローチのいずれかが選択されます：

2つのアプリID（本番用 + プリプロダクション用）
1つのアプリID + ランタイムでの動的な環境切り替え
1つのアプリID + Capgo チャンネル

最初の2つの方法も可能ですが、長期的な摩擦を生みます。実際の開発チームでは、Capgo の channel モデルが最もクリーンな解決策となります。

アプリIDの重複が問題になる理由

活用 com.myapp と com.myapp.beta 一見シンプルですが、すぐに以下のような重複が発生します：

2つのリリースパイプライン
2組の push ID、ディープリンク、および entitlement マッピング
2つの分析およびクラッシュ解析用ID
環境間での設定の乖離と動作の不一致

ストアコンソール、チーム、社内QAの手順において、実質的に2つの製品を管理することになります。

ランタイムでの設定切り替えが複雑になりがちな理由

「1つのアプリID + ランタイム切り替え」パターンは、通常、アプリ起動時に環境変数やフラグを読み込み、API、キー、および update の挙動を動的にルーティングすることを意味します。

以下のような問題が発生するまで:

設定が古いために、QAが意図しないフローをバイパスしてしまう
本番環境で誤ったエンドポイントが使用される
環境の差異（drift）により、再現困難なバグが発生する
ユーザー端末で「このバイナリはどの設定バージョンを使用しているか？」をデバッグする必要がある

リリースごとに複雑さが増し、開発スピードが低下する原因となります。

Capgo の手法：1つのApp ID、複数のチャンネル

Capgo は、チャンネルを通じて環境制御を明確にします：

App Store / Play ストアには、1つの本番用App IDを維持します。
「シェル」として1つのNative Buildを配信します（ネイティブの変更で再ビルドが必要になるまで）。
App IDを複製するのではなく、チャンネルによって挙動をルーティングします。

具体的には、以下のようになります：

production: 全ユーザー
staging: 社内QAおよびリリース候補
beta: 招待されたテスター
hotfix: 緊急パッチ用トラック

TestFlightやPlayの内部テスト用アプリを staging そのまま使い続けることができます。新しいNative Buildを公開することなく、Capgo を通じてJS/CSS/アセットのアップデートを繰り返し適用できます。

実践的な推奨構成

1) Nativeリリースのベースライン

最新のNativeバイナリを維持したまま、何度もJSのイテレーションを回せます：

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

Native側のコードを変更した場合のみ、Nativeバイナリを再ビルドします。

2) 環境ごとに専用のチャンネルを使用する

チャンネルを使用してアップデートを公開：

bun run build
bunx @capgo/cli deploy --channel staging

QAでテスト、修正、そしてプロモート：

bunx @capgo/cli promote vX.Y.Z --channel production

明示的なバージョニングを好む場合：

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) TestFlightを「常にプリプロド」に保つ

iOSのワークフローでは、TestFlightビルドをプリプロダクションのアップデートに関連付けたままにできます：

JSの変更のたびに、頻繁にNative Buildを提出する必要はありません。
QAはstagingチャネルを通じて、本番に近いcodeを常に検証できます。
本番ユーザーは、プロモートされたproductionチャネルのbundleのみを受け取ります。

4) 管理されたワークフローにのみチャネル切り替えを使用する

高度なチーム向けに、QA/管理者ユーザー向けに制御されたチャネル切り替え機能を公開します：

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

これは任意です。ほとんどのチームはダッシュボードからチャネルを割り当て、全顧客ではなく内部ユーザーに対してのみチャネルを切り替えます。

運用チェックリスト

App IDは1つのみ（productionとstagingのIDを重複させない）
単一のベースライン Native Build パイプライン
Channel マッピングのドキュメント化 (staging, beta, production, hotfix)
CI/CD によるプロモーションパスの強制
ネイティブ変更時のみ Native Build を実行
ロールバックの定期的なテスト

実用的なメリット

このアプローチにより、環境の乖離を防ぎ、ビルドの無駄を減らし、修正を迅速化できます：

QA は実機に近いバイナリを使用可能（偽の「ステージング用アプリ」ではない）
TestFlight のパスが安定する
「2つのアプリID」による技術負債を回避できる
Capgo を通じて、JSのみの修正を迅速にデプロイできる

結果として、アーティファクトの削減、テレメトリの整理、リリース作業の予期せぬトラブルの防止など、ガバナンスが簡素化されます。

Capgo 環境のベストプラクティス：1つのモバイルApp IDでStagingを実現する

以下を使用している場合： Capgo 環境のベストプラクティス：1つのMobile App IDでステージング チャネルのルーティングと段階的ロールアウトを計画するには、それを次と接続しますチャネル Channelsの実装の詳細については、チャネル Channelsの実装の詳細については、チャネル Channelsの実装の詳細については、ベータテスト・ソリューション Beta Testing Solutionのプロダクトワークフロー向けに、またバージョン指定ソリューション Version Targeting Solutionのプロダクトワークフロー向けに。