Capgo 環境のベストプラクティス：1つのモバイルアプリIDでステージング

Capacitor アプリでステージング、QA、本番向けに Capgo チャンネルを使い、アプリIDの重複や壊れやすいランタイムフラグを避けるための実践ガイド。

モバイル環境では、通常3つのアプローチのいずれかを選びます：

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

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

アプリIDの重複がノイズを生む理由

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

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

ストアコンソール、チーム、社内 QA 指示書など、実質的に2つの製品を管理することになります。

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

「1つの app ID + ランタイムスイッチ」パターンでは、通常、アプリが起動時に環境変数やフラグを読み取り、API、キー、update の挙動を動的にルーティングし直します。

以下のような事態が起こるまで:

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

リリースごとにこの複雑さは増大し、チームの開発速度を低下させます。

Capgo流：1つのアプリIDで複数チャンネル

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

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

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

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

TestFlight/Playの内部テスト用アプリはそのまま staging 使い続けられます。新しいネイティブアプリを公開せずに、Capgo 経由でそこでJS/CSS/アセットの更新を繰り返し行えます。

実践的な推奨構成

1) ネイティブリリースのベースライン

直近のネイティブバイナリはそのままに、JSのイテレーションを何度も回せます：

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

ネイティブ側を実際に変更したときだけ、ネイティブバイナリを再ビルドすればOKです。

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を「常にpre-prod」に保つ

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

JSの変更のたびに頻繁にネイティブビルドを提出する必要はありません。
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つのモバイルアプリIDでステージング チャンネルルーティングと段階的ロールアウトを計画するには、次と組み合わせてください：チャンネル Channelsの実装の詳細については、チャンネル Channelsの実装の詳細については、チャンネル Channelsの実装の詳細については、ベータテストソリューションベータテストソリューションのプロダクトワークフロー向け、およびバージョンターゲティングソリューションバージョンターゲティングソリューションのプロダクトワークフロー向け。