__CAPGO_KEEP_3__

Live Update チャネルは、任意のデバイスがそのチャネルに接続して更新を待っている場合に、特定のJSバンドルビルドのアプリケーションを指します。 Capgo Live Updates SDK をアプリケーションにインストールすると、チャネルに接続されている任意のネイティブバイナリは、起動時にアプリケーションが利用可能な更新をチェックします。必要に応じて、チャネルが指すビルドを変更することもできます。また、必要に応じて前のビルドに戻すこともできます。 チャネルは機密性を提供しない

暗号化は更新の配信パスと実証性を保護しますが、配信されたバンドルは、クライアントの公開鍵が含まれているため、十分な努力を払えば、配布されているアプリケーションから逆アセンブルできます。

Channels control update eligibility, not bundle secrecy. Even if a channel is private or self-assignment is disabled, any unencrypted bundle uploaded to Capgo should still be treated as a public asset delivered to clients. Encryption protects the delivery path and authenticity of updates, but shipped bundles can still be reverse engineered from the distributed app with enough effort because the public key is part of the client. See デバイスがチャネルを選択する順序 (優先順位) __CAPGO_KEEP_0__

__CAPGO_KEEP_1__

デバイスがアップデートを確認するとき、Capgoは、次の順序（優先順位が高い順）でチャンネルを選択します:

1. デバイスのマッピング（ダッシュボード） – 重要なデバッグや制御テストに使用するために、特定のデバイスIDをチャンネルに固定します。
2. Cloud override (per‑device) via Dashboard or API Cloud override (per‑device) via Dashboard or API
3. – ダッシュボードまたは__CAPGO_KEEP_0__でデバイスのチャンネルを変更すると作成されます。QAユーザーが機能/PRチャンネル間で切り替えたいときやユーザー問題を再現したいときに使用します。バイナリを再インストールしても消去されませんが、デバイスエントリを削除すると消去されます。 setChannel() プラグイン ローカルチャンネル setChannel() – アプリが呼び出し、バックエンドがターゲットチャンネルが自己割り当てを許可していることを検証した場合に作成されます。選択されたチャンネルは、デバイス上でローカルに保存され、即座に効果を発揮し、デバイスオーバーライドUIに表示されません。

setChannel()を使用した即時チャンネル切り替え

バージョン 5.34.0、6.34.0、7.34.0、または 8.0.0 からプラグインを開始すると、 (あなたのメジャーバージョンに応じて)、 setChannel() 異なる動作になります: バックエンドに接続して 有効かどうかを確認し、 チャンネルが許可されているかどうかを確認し、 チャンネルがローカルに保存されます defaultChannelチャンネル チャンネル チャンネル

チャンネル setChannel() saved the channel override to the backend database (like Dashboard or API changes), and devices had to wait for data replication (up to 2 minutes) before the new channel was recognized. The new behavior only reads from the backend (for validation) and stores locally, making channel switches instant.

なぜなら、ローカル専用なので、__CAPGO_KEEP_0__ ダッシュボードにデバイスオーバーライドエントリを作成しないためです。デバイスオーバーライドUIは、ダッシュボードまたはパブリック__CAPGO_KEEP_1__から作成されたオーバーライドのみを表示します。 setChannel() 注意: チャンネルがローカルに設定された後でも、バックエンドはアップデートチェック中にチャンネルを検証するため、セキュリティは維持されます。 create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

チャンネル変更がダッシュボードまたは__CAPGO_KEEP_0__から行われた場合でも、エッジサーバー全体が変更を反映するのに最大2分のリプリカシオンボグが発生します。即時チャンネル切り替えには、 アプリから__CAPGO_KEEP_0__を使用してください—itはバックエンドと検証し、ローカルにチャンネルを設定して即時効果を得ます。

__CAPGO_KEEP_0__設定 When channel changes are made via the Dashboard or API, there is still a replication lag of up to 2 minutes before all edge servers reflect the change. For instant channel switching, use setChannel() from your app code—it validates with the backend, then sets the channel locally for immediate effect.

4. Capacitor defaultChannel __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ capacitor.config.* と、強制/オーバーライド/ローカルチャネルが存在しない場合、Appはこのチャネルで起動します (例えば、 beta, qa, pr-123）。テストフライト/内部ビルド用に設計されており、テスターは自動的にプレリリースチャネルに到達します。生産ビルドは通常、この値を未設定にします。
5. Cloud Default Channel (主なパス ~99% のユーザー) – ダッシュボードでデフォルトチャネルをマークすると、すべての通常のエンドユーザー (強制なし、ダッシュボード/API オーバーライドなし、プラグインローカルチャネルなし、config defaultChannelなし) にアタッチします。変更すると即座にロールアウトまたはロールバックできます—新しいバイナリなし。プラットフォーム固有のデフォルト (例えば、iOSのみ、Androidのみ、Electronのみ) を持っている場合、各デバイスは対応するプラットフォームのデフォルトにアタッチします。Cloud Defaultを未設定にすると許可されます。そうすると、デバイスはステップ 1–4 にマッチする場合にのみ更新を受け取ります。

ベストプラクティス:

• ステップ 1–4 を例外/テストレイヤーとして扱い、Cloud Defaultを設定した場合、実ユーザーはそれに流れ込むようにします。Cloud Defaultを設定しない場合は、ユーザーがアタッチする方法については、明確に意識してください (通常は defaultChannel configまたはデバイスごとのオーバーライドを使用します。
• Only configure defaultChannel テスターに明示的に配布するバイナリのみに設定します。Cloud Defaultを未設定にすると、生産ロジックはダッシュボードに集中するので、生産環境では
• sparingly使用してください—主にQAまたはターゲットされた診断用です。 setChannel() チャネルがプラットフォーム (iOS/Android/Electron) で無効になっている場合 (トグル)、選択プロセスはそれをスキップし、リストの次の項目に進みます。

]}

概要: Force > ダッシュボード/API Override > プラグイン setChannel() ローカル チャネル > 設定 defaultChannel > Cloud Default.

デフォルト チャネル ビハビアー

クラウド デフォルトを設定することは任意ですが、通常は新しいデバイスのキャッチオール パスとして機能します。 1 つがなければ、強制マッピング、オーバーライド、または「__CAPGO_KEEP_0__」設定にマッチするデバイス以外のデバイスは更新を受け取りません。 1 つを選択する場合、次のパターンを考慮してください: defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

• – iOS、Android、および Electron が有効になっているチャネルが 1 つだけの場合、デフォルトになります。 オーバーライドなしのデバイスはここにアタッチされます。 プラットフォーム固有のデフォルト
• – プラットフォームを分割する (例えば、iOS のみが有効になっている場合、 Platform-specific defaults ios-production – If you split channels by platform (for example, with only iOS enabled, android-production Androidのみ有効にし、 electron-production Electronのみ有効にした場合、それぞれのプラットフォームのデフォルトとしてそれぞれをマークします。 iOSデバイスはiOSデフォルトに、AndroidデバイスはAndroidデフォルトに、ElectronアプリはElectronデフォルトにアクセスします。

Cloudflareのデフォルトを思い出してくださいが、 defaultChannel 両方とも同じ決定層を占めます。Cloudflareのデフォルトを設定すると、__CAPGO_KEEP_0__の設定に値を複製する必要がなくなります—生産用ビルドの場合に空白のままにします。 capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel プロダクションチャンネル以外の非生産チャンネルで始める場合にCloudflareのデフォルトが異なる場合でも。 defaultChannel デフォルトをいつでもダッシュボードで変更できます。デフォルトを入れ替えると、新しいデバイスは新しいルーティングに即座に従い、既存のデバイスは次回チェックインするときに通常の優先順位ルールに従います。

チャンネルの設定

チャンネルの設定

ダッシュボードの「チャンネル」セクションに移動してください

1. Capgo
2. Click the “New Channel” button
3. New Channelボタンをクリックしてください

Channel names can be anything you’d like. A common strategy is to match channels to your development stages, such as:

• Development - ローカルデバイスまたはエミュレータでライブ更新をテストする
• QA - QAチームが広範なリリース前にアップデートを検証する
• Staging - プロダクション環境に似た環境で最終テストを行う
• Production - アプリストアからユーザーが受け取るアプリのバージョン

Configuring the Channel in Your App

With your channels created, you need to configure your app to listen to the appropriate channel. In this example, we’ll use the Development channel.

Open your capacitor.config.ts (または capacitor.config.jsonセクションの下、オプションで設定 plugins for defaultChannel テストビルド (内部 / QA)。生産ビルドの場合、デバイスが Cloud Default を使用するようにするには、明示的にオーバーライドする必要があります。 コピー

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

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

を実行して、更新された設定ファイルを iOS、Android、Electron プロジェクトにコピーします。設定の同期をスキップすると、以前の設定のままのネイティブ プロジェクトが使用され続けます。 npx cap sync 注意

チャネル選択順序：Force > Dashboard/__CAPGO_KEEP_0__ デバイスオーバーライド > プラグイン

Channel selection order: Force > Dashboard/API device override > Plugin setChannel() ローカル チャネル > 設定 defaultChannel > Cloud のデフォルト設定。

使用 defaultChannel テスト/内部ビルドでのみ使用してください; これは、ユーザーがデフォルトの Cloud 設定 (設定されている場合) に従うのではなく、ネイティブの設定でルーティングを複製するのを避けるようにします。

デバイスを強制 (固定) したり、オーバーライドを適用したりすることはまだできます。これらは、設定値を即座に上書きします。

チャネル名は大文字と小文字が区別されます。

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

チャネルには、更新を受け取ることができるユーザーと、更新が配信される方法を制御するオプションが複数あります。重要なものは以下のとおりです。Web アプリ、CLI、または Public API からこれらの設定を構成できます。

• デフォルト チャネル: 新しいデバイスが接続するチャネルまたはプラットフォーム固有のチャネルをオプションでマークします。ルーティング シナリオについては、「デフォルト チャネル ビヘイビア」を参照してください。
• プラットフォーム フィルタ: を有効または無効にします。 iOS, Android, または Electron デバイスあたりチャンネルあたり。
• ネイティブ下での自動ダウングレードを無効にする: デバイスのネイティブアプリのバージョンがチャンネルのバンドルバージョンよりも新しい場合 (例: デバイスが 1.2.3 であるのに対し、チャンネルが 1.2.2 である場合)、アップデートを送信しないようにします。
• 開発用ビルドを許可する: 開発用ビルドへのアップデートを許可します (テストに便利)。
• エミュレータデバイスを許可する: テストに便利なエミュレータ/シミュレータへのアップデートを許可します。
• デバイスの自己割り当てを許可する: アプリが実行時、このチャンネルに切り替えることができます。 setChannel無効にすると、 setChannel このチャンネルでは失敗します。

段階的ロールアウト

チャンネルは安定したバンドルを維持しながら、固有のデバイスコホートに別のロールアウトターゲットを段階的に公開することができます。ロールアウトを一時停止、再開、昇格、ロールバック、自動失敗応答の自動設定を行うことができます。ただし、すべてのユーザーにチャンネルを切り替える必要はありません。詳細は “段階的ロールアウト” を参照してください。 段階的ロールアウト ロールアウトモデル、ダッシュボードワークフロー、API フィールド、CLI コマンドについては “段階的ロールアウト” を参照してください。

自動更新戦略の無効化

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

• メジャー: デバイスのネイティブ基準よりもメジャー バージョンが高いターゲット バンドルのブロック (version_build)。例えば: 1.2.3 -> 2.0.0 はブロックされます。 1.2.3 -> 1.9.0 は許可されます。
• マイナー: メジャーまたはマイナー バージョンが異なるターゲット バンドルのブロック ( version_build)。例えば: 1.2.3 -> 1.3.0 はブロックされます。 1.2.3 -> 1.2.4 は許可されます。
• パッチ: 最も厳密なモード。メジャー、ミニ、パッチ番号の変更はすべてブロックされ、サフィックスの変更のみ許可されます。 MAJOR.MINOR.PATCH targetLanguage":"Japanese","protectedTokens":["Cloudflare","Capacitor","GitHub","Capgo","code","API","SDK","CLI","npm","bun"],"texts":["","は同じままです。例えば","は許可されます","はブロックされます。", 1.0.0-beta.1 -> 1.0.0-beta.2 metadata: 最小のアップデートバージョンのメタデータを各バンドルに必要とします。__CAPGO_KEEP_0__ を使用して設定します","または","。チャネルが不正設定とみなされ、更新が拒否されるまで設定されていない場合","none: すべての更新を","semver互換性" 1.0.0+build.1 -> 1.0.0+build.2 これらの戦略は、チャネルのターゲットバンドルを、送信されたネイティブのベースラインと比較しますが、ダウンロードした現在のバンドルは送信された","詳細と例については、/docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy を参照してください。"]} 1.0.0 -> 1.0.1 ]} ]}
• metadata: Require a minimum update version metadata on each bundle. Configure via CLI using --min-update-version ]} --auto-min-update-version]}
• ]} ]} .

]} version_build]} version_name.

Learn more details and examples in Disable updates strategy at /docs/cli/commands/#disable-updates-strategy.

例 (CLI):

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

アプリ内でsetChannel()を使用する

この setChannel() メソッドは、実行時でアプリがプログラム的にチャンネルを切り替えることを可能にします。この機能は、以下のようなシナリオで特に便利です。

• QA/デバッグメニューでテスターがチャンネルを切り替える
• ベータプログラムへの参加フロー
• 機能フラグの実装
• A/Bテストシナリオ

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

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

How setChannel() Works (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

When setChannel() は呼ばれる:

1. バックエンドの検証 (読み取り専用): Capgo バックエンドにリクエストが送信され、チャンネルが許可されているかどうか検証されます (自己割り当ての権限を確認します)
2. ローカル ストレージの更新: 検証が成功すると、チャンネルはデバイスのローカル ストレージに保存されます defaultChannel
3. 即時効果: 次の更新チェックでは、新しいチャンネルが即座に使用されます (再生時は待機しません)

なぜこれが重要か: 古いバージョンでは setChannel() 保存されたチャンネルオーバーライドはバックエンドデータベースに保存されます (同等のダッシュボードまたはAPIの変更)。デバイスは、チャンネル変更が有効になるまで、最大2分間待機する必要があります。現在、 setChannel() バックエンドからのみ読み取り (検証用) して、ローカルに保存するため、チャンネル切り替えは即時になります。

ダッシュボードの可視性: プラグインで設定されたチャンネルは、Capgo UI上でデバイスオーバーライドとして表示されません。ダッシュボードまたはパブリックAPIからのみ作成されたチャンネル割り当てのみがリストされます。ダッシュボードまたはAPIを使用する必要がある場合は、管理者が表示できるオーバーライドを使用してください。

セキュリティに関する注意: チャンネルの権限がローカルに設定された後 (たとえば、自己割り当てが無効化された場合) でも、バックエンドは更新チェック中にチャンネルの検証を実行し、セキュリティが維持されるようにします。

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

方法	効果時間	保存先	デバイスオーバーライドUIで表示	使用ケース
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の場合でも同じ機能を含みます)。 プラグインのインストール バージョンタグについて参照してください。

チャネルにバンドルを割り当てる

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

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

This will upload your built web assets and set the new bundle as the active build for the Development チャンネル。アプリがそのチャンネルに接続されている場合、更新は次回アプリが更新をチェックするときに受け取れます。

You can also assign builds to channels from the “Bundles” section of the Capgo dashboard. Click the menu icon next to a build and select “Assign to Channel” to choose the channel for that build.

バンドルバージョニングとチャンネル

It’s important to note that bundles in Capgo are global to your app, not specific to individual channels. The same bundle can be assigned to multiple channels.

When versioning your bundles, we recommend using シーケンスベージョニングと Capgo の Semver Tester とプレリリース識別子でチャンネル固有のバージョンを指定します。たとえば、ベータ版リリースはバージョンとして "1.2.3-beta.1" と指定できます。 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.2channel:
• Staging チャンネル: 1.2.3-rc.1, 1.2.3-rc.2、など。
• Production チャンネル: 1.2.3, 1.2.4、など。

Capgoを使用して semverを使用することで、前リリース識別子を含むバージョンを指定することができます。このアプローチは推奨されていますが、厳密には必要ではありません。重要なのは、ビルド間の関係を明確に伝え、チームの開発プロセスと一致するバージョニングスキームを探すことです。 ライブアップデートのロールバック

「ライブアップデートのロールバック」のセクション

ロールバックしたいチャンネルの名前をクリック

1. ロールバックしたいビルドを探し、王冠アイコンをクリック
2. __CAPGO_KEEP_0__
3. このアクションを確認します

選択したビルドはすぐにそのチャンネルで有効なビルドになります。アプリは、更新をチェックするときにロールバックしたバージョンを受け取ります。

デプロイを自動化する

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

自動化の詳細については、 CI/CD統合 docs to learn more about automating Capgo live updates.

最小権限のPRプレビュー

使用する App Preview API key when CI needs one temporary channel per pull request but must not manage existing main/default channels. The key remains bound to the owning organization and selected app; it simply has no organization-wide role. Each non-public preview channel it creates receives its own automatic, channel-scoped lifecycle permission.

1. Have an organization administrator create a secure API key limited to the preview app and select App Preview. See API Keys.
2. Use a unique, non-public channel such as pr-123. Do not pass --default, --self-assign, rollout options, or --delete-linked-bundle-on-upload.
3. Upload and promote the PR bundle in one command, then delete the owned channel and bundle when the PR closes:

APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"

npx @capgo/cli@latest bundle upload "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "$PREVIEW_CHANNEL" \
  --bundle "$BUNDLE_VERSION"

npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found

bundle upload --channel 1つのフローで、欠落しているチャンネルを作成し、バンドルをアップロードし、プレビューを促進します。クリーンアップは原子的で所有権をチェックします: キーは、自身が作成したチャンネルとその関連する、共有されていないバンドルをのみ削除できます。既存のメイン/デフォルトチャンネル、別のプレビューキーが作成したチャンネル、または別のキーが作成したバンドルを変更、プッシュ、または削除することはできません。

レビューアがQR code またはプレビューURLが必要な場合、管理者はアプリに対してプレビューを一度だけ有効にする必要があります:

npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

App Preview キーはプレビューを有効にすることができません。なぜなら、App Settings の権限がないからです。GitHub Actions で、シークレットを含むプレビュー ジョブを pull_request, not pull_request_target, and restrict them to same-repository PRs with github.event.pull_request.head.repo.full_name == github.repository.

Deploying to a Device

デバイスにデプロイする

1. Install the Capgo SDK in your app
2. チャンネルを理解したので、実際のデバイスにライブアップデートをデプロイする準備ができました。基本的なプロセスは:「アプリに__CAPGO_KEEP_0__ __CAPGO_KEEP_1__をインストールする。アプリを、自身が望むチャンネルにリスニングするように設定する。
3. アップロードしたビルドをそのチャンネルに割り当てます。
4. アプリを起動し、更新を待ちます!

詳細なガイドについては、 ライブアップデートのデプロイ を参照してください。更新を楽しみましょう!

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

チャンネルは、開発段階のみに使用するのではなく、より多くの用途に使用できます。ユーザー セグメンテーションを可能にする強力なツールです。

• 異なるユーザー層向けの機能フラグ
• A/B テスト
• 機能の段階的なロールアウト
• ベータ テスト プログラム

これらの高度な用途を実装する方法を、以下のガイドで学びます: 機能フラグとA/Bテストのためのユーザーをプランとチャンネルで分割する方法.

チャンネルから続けて

__CAPGO_KEEP_0__がCapgoを使用している場合 チャンネル チャンネルを使用してチャネルルーティングとステージドロールアウトを計画し、チャンネルと接続する チャンネル チャンネル チャンネル ベータテストソリューション チャンネル Betaテストソリューションにおける製品ワークフローについて バージョン対象ソリューション バージョン対象ソリューションにおける製品ワークフローについて、 Capgo環境ベストプラクティス：1つのモバイルアプリIDでステージング Capgo環境ベストプラクティス：1つのモバイルアプリIDでステージングの実用的な背景について