チャンネル

Live Updateチャンネルは、そのチャンネルに対してアップデートを待ち受けるように設定された全てのデバイスと共有される、特定のJSバンドルビルドを指します。アプリにCapgo Live Updates SDKをインストールすると、そのチャンネルに設定された全てのネイティブバイナリは、アプリ起動時に利用可能なアップデートを確認します。チャンネルが指すビルドはいつでも変更でき、必要に応じて以前のビルドにロールバックすることもできます。

デバイスがチャンネルを選択する方法（優先順位）

デバイスがアップデートを確認する際、Capgoはこの厳密な順序でどのチャンネルを使用するかを決定します（最高優先度から）：

強制デバイスマッピング（ダッシュボード） – 特定のデバイスIDを手動でチャンネルにピン留めします。緊急のデバッグや単一の実ユーザーとの制御されたテストに使用します。これが常に優先されます。
ダッシュボードまたはAPIを介したクラウドオーバーライド（デバイスごと） – ダッシュボードやAPIでデバイスのチャンネルを変更したときに作成されます。フィーチャー/PRチャンネル間を切り替えるQAユーザーや、ユーザー問題を再現するために使用します。バイナリの再インストールでは消えません。デバイスエントリの削除で消えます。

プラグインバージョン5.34.0、6.34.0、7.34.0、または8.0.0以降（メジャーバージョンによる）、setChannel()は異なる動作をします：バックエンドに接続してチャンネルが許可されているかを検証し（そのチャンネルでセルフアサインメントが有効かをチェック）、その後チャンネルをdefaultChannelとしてデバイスにローカルに保存します。これは、新しいチャンネルが次のアップデートチェックで即座に有効になることを意味します—レプリケーションを待つ必要はありません。

以前、setChannel()はチャンネルオーバーライドをバックエンドデータベースに保存していました（ダッシュボードやAPIの変更と同様）。デバイスは新しいチャンネルが認識される前にデータレプリケーション（最大2分）を待つ必要がありました。新しい動作はバックエンドから読み取り（検証用）のみを行い、ローカルに保存するため、チャンネル切り替えが即座になります。

注意: ローカルに設定された後にチャンネルが許可されなくなっても、バックエンドはアップデートチェック時にチャンネルを検証するため、セキュリティは維持されます。

重要: ダッシュボードやAPIを介してチャンネルの変更が行われた場合、すべてのエッジサーバーが変更を反映するまで最大2分のレプリケーション遅延があります。即時のチャンネル切り替えには、アプリコードからsetChannel()を使用してください—バックエンドで検証し、ローカルでチャンネルを設定して即座に効果を得ます。

Capacitor設定 defaultChannel（テストビルドのデフォルト） – capacitor.config.*に存在し、force/overrideがない場合、アプリはこのチャンネルで開始します（例：beta、qa、pr-123）。テスターが自動的にプリリリースチャンネルに着地するよう、TestFlight/内部ビルド用に設計されています。本番ビルドは通常これを未設定のままにします。
クラウドデフォルトチャンネル（メインパス～99%のユーザー） – ダッシュボードでデフォルトチャンネルをマークすると、通常のすべてのエンドユーザー（force、override、configのdefaultChannelなし）がここに接続されます。即座にロールアウトまたはロールバックするために変更します—新しいバイナリは不要です。プラットフォーム固有のデフォルトがある場合（iOS専用1つ、Android専用1つ）、各デバイスはそのプラットフォームに一致するデフォルトに着地します。クラウドデフォルトを未設定のままにすることも許可されています。その場合、デバイスはアップデートを受け取るためにステップ1-3で一致する必要があります。

ベストプラクティス：

1-3を例外/テストレイヤーとして扱います。クラウドデフォルトを設定すると、実際のユーザーはそこに流れるべきです。設定しないことを選択する場合は、ユーザーがどのように接続されるかを意図的に決定してください（通常、configのdefaultChannelまたはデバイスごとのオーバーライドを介して）。
テスターに明示的に配布するバイナリにのみdefaultChannelを設定します。未設定のままにすると、本番ロジックがダッシュボードで一元化されます。
本番環境ではsetChannel()を控えめに使用してください—主にQAやターゲット診断用。

チャンネルがプラットフォームで無効になっている場合（iOS/Androidトグル）、選択されるはずのときに選択プロセスはそれをスキップしてリストを下に続けます。

要約: Force > Override > Config defaultChannel > クラウドデフォルト。

デフォルトチャンネルの動作

クラウドデフォルトの設定はオプションですが、通常は新しいデバイスのキャッチオールパスとして機能します。これがないと、強制マッピング、オーバーライド、またはCapacitor設定のdefaultChannelで一致するデバイスのみがアップデートを受け取ります。デフォルトをマークする場合は、これらのパターンを覚えておいてください：

単一のデフォルト（最も一般的） – チャンネルにiOSとAndroidの両方が有効になっている場合、それが唯一のデフォルトになります。オーバーライドのないすべてのデバイスがここに接続されます。
プラットフォーム固有のデフォルト – プラットフォームごとにチャンネルを分ける場合（例：iOSのみ有効なios-productionとAndroidのみ有効なandroid-production）、それぞれをそのプラットフォームのデフォルトとしてマークします。iOSデバイスはiOSデフォルトに、AndroidデバイスはAndroidデフォルトに行きます。

クラウドデフォルトとcapacitor.config.*のdefaultChannelは両方とも同じ決定レイヤーを占めることを覚えておいてください。クラウドデフォルトを設定する場合、Capacitor設定で値を複製する必要はありません—本番ビルドではdefaultChannelを空のままにしてください。クラウドデフォルトが異なっていても非本番チャンネルで開始させたい場合、テスターやQAに意図的に配布するバイナリのためにdefaultChannelを予約してください。

ダッシュボードでいつでもデフォルトを変更できます。デフォルトを切り替えると、新しいデバイスは即座に新しいルーティングに従い、既存のデバイスは次のチェックイン時に通常の優先順位ルールに従います。

チャンネルの設定

オンボーディング中に最初のチャンネルを作成します（ほとんどのチームは「Production」と名付けます）が、何もロックされていません—いつでもチャンネルの名前を変更したり削除したりできます。後で追加のチャンネルを追加するには：

Capgoダッシュボードの「Channels」セクションに移動します
「New Channel」ボタンをクリックします
チャンネル名を入力して「Create」をクリックします

チャンネル名は任意のものを設定できます。一般的な戦略として、開発段階に合わせてチャンネルを設定することがあります：

Development - ローカルデバイスやエミュレータでライブアップデートをテストするため
QA - QAチームが広範なリリース前にアップデートを検証するため
Staging - 本番環境に近い環境で最終テストを行うため
Production - エンドユーザーがアプリストアから受け取るアプリのバージョン用

アプリでのチャンネルの設定

チャンネルを作成したら、適切なチャンネルを監視するようにアプリを設定する必要があります。この例では、Developmentチャンネルを使用します。

capacitor.config.ts（またはcapacitor.config.json）ファイルを開きます。pluginsセクションで、テストビルド（内部/QA）用にdefaultChannelをオプションで設定します。本番ビルドでは、明示的にオーバーライドされない限り、デバイスがクラウドデフォルトを使用するように省略することを推奨します。

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // QA/TestFlightビルド用 – テスターは自動的にDevelopmentチャンネルで開始します。
      defaultChannel: 'Development',
      // 本番ビルドは通常これを省略して、ユーザーがクラウドデフォルトチャンネルに接続されるようにします。
    },
  },
};

次に、Webアプリをビルドし、npx cap syncを実行して更新された設定ファイルをiOSとAndroidプロジェクトにコピーします。このSync手順をスキップすると、ネイティブプロジェクトは以前に設定されていたチャンネルを使い続けます。

チャンネルオプションと戦略

チャンネルには、誰がアップデートを受け取れるか、どのようにアップデートが配信されるかを制御するいくつかのオプションがあります。最も重要なものは以下の通りです。Webアプリ、CLI、またはPublic APIから設定できます。

デフォルトチャンネル: 新しいデバイスが接続するチャンネルまたはプラットフォーム固有のチャンネルをオプションでマークします。ルーティングシナリオについては「デフォルトチャンネルの動作」を参照してください。
プラットフォームフィルター: チャンネルごとにiOSおよび/またはAndroidデバイスへの配信を有効または無効にします。
ネイティブ未満での自動ダウングレードを無効化: デバイスのネイティブアプリバージョンがチャンネルのバンドルより新しい場合にアップデートの送信を防ぎます（例：デバイスが1.2.3でチャンネルが1.2.2の場合）。
開発ビルドを許可: 開発ビルドへのアップデートを許可します（テストに便利）。
エミュレータデバイスを許可: エミュレータ/シミュレータへのアップデートを許可します（テストに便利）。
デバイスのセルフアサインメントを許可: アプリがsetChannelを使用してランタイムでこのチャンネルに切り替えることを許可します。無効にすると、このチャンネルへのsetChannelは失敗します。

自動アップデート無効化戦略

チャンネルが自動的に配信するアップデートの種類を制限するために使用します。オプション：

major: メジャー間のアップデートをブロック (0.0.0 → 1.0.0)。マイナーおよびパッチアップデートは引き続き許可されます。
minor: マイナー間のアップデート (例: 1.1.0 → 1.2.0) とメジャーをブロック。パッチアップデートは引き続き許可されます。注意: 0.1.0 → 1.1.0はブロックしません。
patch: 非常に厳格。同じメジャーとマイナー内で増加するパッチバージョンのみを許可します。例: 0.0.311 → 0.0.314 ✅、0.1.312 → 0.0.314 ❌、1.0.312 → 0.0.314 ❌。
metadata: 各バンドルに最小アップデートバージョンのメタデータを要求します。CLIで--min-update-versionまたは--auto-min-update-versionを使用して設定します。欠落している場合、チャンネルは誤設定とマークされ、設定されるまでアップデートは拒否されます。
none: semver互換性に従ってすべてのアップデートを許可します。

詳細と例については、/docs/cli/commands/#disable-updates-strategyのアップデート無効化戦略を参照してください。

例（CLI）：

# Productionチャンネルでメジャーアップデートをブロック
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# デバイスがBetaチャンネルにセルフアサインすることを許可
npx @capgo/cli@latest channel set beta com.example.app --self-assign

アプリからsetChannel()を使用する

setChannel()メソッドを使用すると、アプリはランタイムでプログラム的にチャンネルを切り替えることができます。これは特に以下に便利です：

テスターがチャンネル間を切り替えられるQA/デバッグメニュー
ベータプログラムのオプトインフロー
フィーチャーフラグの実装
A/Bテストシナリオ

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

// ベータチャンネルに切り替え
await CapacitorUpdater.setChannel({ channel: 'beta' });

// オプションで切り替え後に即座にアップデートチェックをトリガー
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

setChannel()が呼び出されると：

バックエンド検証（読み取り専用）: Capgoバックエンドにリクエストを送信してチャンネルが許可されているかを検証します（セルフアサインメント権限をチェック）
ローカルストレージの更新: 検証が成功すると、チャンネルはデバイスのローカルストレージにdefaultChannelとして保存されます
即時効果: 次のアップデートチェックは新しいチャンネルを即座に使用します（レプリケーションを待つ必要なし）

これが重要な理由: 古いバージョンでは、setChannel()はチャンネルオーバーライドをバックエンドデータベースに保存していました（ダッシュボードやAPIの変更と同様）。デバイスはチャンネル変更が有効になる前にバックエンドのレプリケーション（最大2分）を待つ必要がありました。現在、setChannel()はバックエンドから読み取り（検証用）のみを行い、ローカルに保存するため、チャンネル切り替えが即座になります。

セキュリティに関する注意: ローカルに設定された後にチャンネルの権限が変更されても（例：セルフアサインメントが無効になった）、バックエンドはアップデートチェック時にチャンネルを検証し、セキュリティを確保します。

チャンネル変更方法の比較：

方法	効果時間	保存場所	ユースケース
プラグインの`setChannel()`	即時	デバイスのみ（ローカル）	アプリ内でのユーザー主導のチャンネル切り替え
ダッシュボードのデバイスオーバーライド	最大2分	バックエンドデータベース	特定のデバイスに対する管理者主導の変更
APIチャンネル割り当て	最大2分	バックエンドデータベース	自動化されたバックエンド統合

チャンネル切り替えUIを構築する際の最高のユーザー体験のために、常にプラグインのsetChannel()メソッドを使用してください。

ローカル専用チャンネル切り替えの最小バージョン: 5.34.0、6.34.0、7.34.0、または8.0.0（メジャーバージョンによる）。各マイナーバージョン番号は、すべてのメジャーバージョンで同じ機能セットに対応しています（例：X.34.0はXが5、6、7、8のいずれでも同じ機能を含みます）。バージョンタグについてはプラグインのインストールを参照してください。

チャンネルへのバンドルの割り当て

ライブアップデートをデプロイするには、新しいJSバンドルビルドをアップロードし、それをチャンネルに割り当てる必要があります。Capgo CLIを使用して1つのステップでこれを行うことができます：

npx @capgo/cli@latest bundle upload --channel=Development

これにより、ビルドされたWebアセットがアップロードされ、新しいバンドルがDevelopmentチャンネルのアクティブビルドとして設定されます。そのチャンネルを監視するように設定されているアプリは、次回のアップデートチェック時に更新を受け取ります。

Capgoダッシュボードの「Bundles」セクションからもチャンネルにビルドを割り当てることができます。ビルド横のメニューアイコンをクリックし、「Assign to Channel」を選択してそのビルドのチャンネルを選択します。

バンドルのバージョン管理とチャンネル

Capgoでは、バンドルは個々のチャンネルに特有ではなく、アプリ全体でグローバルであることに注意することが重要です。同じバンドルを複数のチャンネルに割り当てることができます。

バンドルのバージョン管理では、チャンネル固有のビルドにはプレリリース識別子を使用したsemverセマンティックバージョニングを推奨します。例えば、ベータリリースは1.2.3-beta.1のようにバージョン管理されます。

このアプローチには以下の利点があります：

ビルド間の関係を明確に伝えます。1.2.3-beta.1は明らかに1.2.3のプレリリースです
チャンネル間でバージョン番号を再利用でき、混乱を減らせます
明確なロールバックパスを可能にします。1.2.3からロールバックする必要がある場合、1.2.2が前の安定リリースであることがわかります

典型的なチャンネル設定でのバンドルバージョンの例：

Developmentチャンネル：1.2.3-dev.1、1.2.3-dev.2など
QAチャンネル：1.2.3-qa.1、1.2.3-qa.2など
Stagingチャンネル：1.2.3-rc.1、1.2.3-rc.2など
Productionチャンネル：1.2.3、1.2.4など

プレリリース識別子を使用したsemverは推奨されるアプローチですが、厳密に必要というわけではありません。重要なのは、ビルド間の関係を明確に伝え、チームの開発プロセスに合ったバージョニング方式を見つけることです。

ライブアップデートのロールバック

バグを導入するライブアップデートをデプロイした場合や、その他の理由で元に戻す必要がある場合、簡単に以前のビルドにロールバックできます。ダッシュボードの「Channels」セクションから：

ロールバックしたいチャンネル名をクリックします
戻したいビルドを見つけ、クラウンアイコンをクリックします
アクションを確認します

選択したビルドは即座にそのチャンネルのアクティブビルドになります。アプリは次回のアップデートチェック時にロールバックされたバージョンを受け取ります。

デプロイメントの自動化

より高度なワークフロー向けに、CI/CDパイプラインの一部としてライブアップデートのデプロイメントを自動化できます。Capgoをビルドプロセスに統合することで、特定のブランチへのプッシュや新しいリリースの作成時に、自動的に新しいバンドルをアップロードしチャンネルに割り当てることができます。

Capgoライブアップデートの自動化についての詳細は、CI/CD Integrationドキュメントを参照してください。

デバイスへのデプロイ

チャンネルについて理解したところで、実際のデバイスへのライブアップデートのデプロイを開始する準備が整いました。基本的なプロセスは：

アプリにCapgo SDKをインストールする
希望のチャンネルを監視するようにアプリを設定する
ビルドをアップロードしそのチャンネルに割り当てる
アプリを起動してアップデートを待つ！

より詳細な手順については、Deploying Live Updatesガイドを参照してください。ハッピーアップデート！

高度なチャンネル使用法：ユーザーセグメンテーション

チャンネルは開発段階以上のものに使用できます。以下のような機能を可能にするユーザーセグメンテーションのための強力なツールです：

異なるユーザーティアのためのフィーチャーフラグ
A/Bテスト
段階的な機能ロールアウト
ベータテストプログラム

これらの高度なユースケースを実装する方法については、ガイドを参照してください：How to Segment Users by Plan and Channels for Feature Flags and A/B Testing。