クラウドのデフォルトを変更する場所 Capgo 新しいデバイスにはすぐに適用されます。既存のデバイスは、次にチェックインするまで古いチャネルのままになることがあり、これが Capgo のクラウドデフォルトチャネルが反映されない多くのケースの原因です。
以下の手順に沿って順番に確認してください。まずデバイスの割り当てを確認し、次にアプリのビルド、同期状態、ロールアウトルール、ログ、ロールバック設定を調べます。
目次
- ステップ 1: デバイスがデフォルトチャネルに割り当てられているか確認する
- ステップ2: アプリ、Native Runtime、アップデートの互換性を確認
- ステップ3: デプロイが実際にデフォルトチャネルに届いているか確認
- ステップ4: 強制同期を実行し、デバイス側のログを確認する
- ステップ 5: ロールアウトルール、バージョンゲート、自動ロールバックの確認
- ステップ6: リアルタイム分析で正確な失敗箇所を特定する
- ステップ 7: デフォルトチャネルが古いままになるのを防ぐ
- よくある質問
- まとめ
ステップ 1: デバイスがデフォルトチャネルに割り当てられているか確認する
目的は、現在どのルールがデバイスのチャネルを決めているかを特定することです。Cloud Default は、より優先度の高い割り当てがデバイスにまだ適用されていない場合にのみ有効になります。
Capgo ダッシュボードを開き、影響を受けているデバイスを確認してください。現在のチャネル、App ID、バージョン、最終チェックイン時刻を確認します。これらの値を、期待どおりにアップデートを受け取ったデバイスと比較してください。この比較で問題がすぐに分かることがよくあります。
チャネル選択には順序があります。まず強制チャネルが優先されます。次にダッシュボードまたは API のデバイスオーバーライド、続いてアプリで設定されたローカルチャネルです。その後 Capgo のチェックが行われます。defaultChannelネイティブアプリの設定内です。Cloud Default がフォールバックになります。
この順序では、デバイスが Cloud Default の変更を無視してもダッシュボードにエラーは出ません。例えば、テストビルドに以前のテストのローカルチャネルが残っていることがあります。クリアするまで、アプリはそのローカル値を使い続けます。
以下の Capgo アップデーターのデバッグガイド 解決されたチャネルが空、または想定外の場合です。アプリに使用可能なデフォルトがなく、デバイスにオーバーライドもないケースを扱います。
次に、Capacitor の設定を確認してください。一般的な構成では、次のようなチャネルを含めます：
const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}このフィールドは任意です。省略すると、デバイスは Cloud Default を継承できます。チャネルルーティングが Capgo Cloud に残るので、本番ビルドではこれで問題ありません。指定する場合は、実際にデプロイするチャネルと値が一致していることを確認してください。
次に、アプリケーション code のローカルオーバーライドを確認します。呼び出し:setChannel()ローカルキャッシュを変更します。バックエンドの Device Override は作成されません。そのため、アプリがローカルチャネルを使い続けていても、ダッシュボードにオーバーライドが表示されないことがあります。
デバイスを通常のルーティングに戻す場合は、そのローカル値をクリアしてください。デバイスのチャネル割り当てを削除するプラグインメソッドを使うか、チャネルを設定している code を削除してアプリを再インストールし、クリーンなテストを行ってください。
重要なポイント: 変更した Cloud Default では、デバイス、アプリ、ローカルチャネルのより強い割り当てを上書きできません。
ステップ2: アプリ、Native Runtime、アップデートの互換性を確認
目的は、インストール済みのアプリがアップロードした bundle を受け入れられることを確認することです。正しいチャネルでも、互換性のないネイティブランタイムにはアップデートを配信できません。
まずアプリ ID から確認してください。デバイスにインストールされたアプリは、bundle をアップロードしたプロジェクトと同じアプリ ID を使用する必要があります。不一致があると、デバイスが誤った Capgo アプリを確認するため、チャネルの問題のように見えることがあります。
次に、ネイティブランタイムのバージョンと bundle の互換性ルールを比較してください。Capgo のライブアップデートでは、JavaScript、CSS、Web アセットを変更できます。ただし、アプリのリリース後にネイティブプラグインを追加したり、ネイティブプロジェクトの code を変更したりすることはできません。ネイティブの変更には、引き続き新しいストアビルドが必要です。
ネイティブランタイムは、Web code を囲むフレームのようなものです。新しいバンドルがインストール済みアプリにないネイティブ API を必要とする場合、Capgo はそれを適用すべきではありません。そのバンドルをテストする前に、互換性のあるネイティブバージョンをビルドしてアップロードしてください。
インストール済みアプリのバージョンとプラットフォームを確認してください。まずAndroidでAndroid用バンドルを、iOSでiOS用バンドルをテストします。また、チャネルにバージョンゲートを使用している場合は、バンドルが正しいアプリバージョンをターゲットにしていることも確認してください。
変更後defaultChannel、プロジェクトルートからsyncコマンドを実行します:
npx cap syncこのステップでは、更新された設定がネイティブプロジェクトにコピーされます。capacitor.configsyncせずに編集すると、ネイティブアプリは古いチャネル設定のままになります。その古いネイティブプロジェクトからの新規ビルドは、同じ結果を再現し続けます。
クリーンなテストのため、sync後に新しいアプリをビルドしてください。スマートフォンにインストールされた古いバイナリに頼らないでください。キャッシュされたローカルチャネル状態を削除する必要がある場合はアンインストールし、新しいビルドをインストールしてチャネルを再確認してください。
この Capgo の更新動作ドキュメント は、アップデータがバンドルを確認するタイミングを説明しています。テスト時にそのタイミングを利用してください。アプリを起動するかフォアグラウンドに戻し、更新が失敗したと判断する前にチェックが完了するのを待ってください。
また、バンドルのネイティブバージョンゲートも確認してください。バンドルが正しいチャネルに存在していても、最小アプリバージョンがデバイスと一致しないため利用不可のままになる場合があります。最新のアップロードがすべてのインストールに適用されると決めつけず、ダッシュボードでリリース詳細を読み取ってください。
アプリがこれらのチェックを通過すれば、故障箇所が絞り込まれます。次の質問は、リリースが意図したチャネルに到達したかどうかです。
ステップ3: デプロイが実際にデフォルトチャネルに届いているか確認
目標は、デバイスが解決するチャネルにバンドルが存在することを確認することです。あるチャネルにバンドルをアップロードしても、すべてのチャネルで利用可能になるわけではありません。
Capgo Cloud でチャネルを開きます。アクティブなバンドル、そのバージョン、デプロイ状態を確認してください。チャネル名とアプリが返す値を比較します。以下のような小さな違いに注意してくださいproductionとprod。チャネル名は完全に一致する必要があります。
CI/CD 経由でデプロイしている場合、バンドルをアップロードした同じジョブのコマンド出力を調べます。CLI に渡されたアプリ ID とチャネルを確認してください。パイプラインはアップロードに成功しても、誤ってステージングチャネルを対象にしている可能性があります。
次にバンドルのステータスを確認します。ドラフトや非アクティブなリリースはダッシュボードに表示されていても、デバイスからは利用できない場合があります。チャネルに段階的ロールアウトが設定されている場合、対象のデバイスがロールアウトルールを満たしていない可能性があります。
既知のテストデバイスを 1 台使用します。明確な役割を与えてください。例えば、1 台のデバイスをテストチャネルに固定し、もう 1 台は Cloud Default に残します。無害な変更をアップロードし、それらのチェックイン記録を比較します。これにより、テストから推測を排除できます。
CapgoのライブOTAエンジンは、Webレイヤーの変更向けに設計されています。新しいストアレビューを待たずに、JavaScriptバンドル、CSS、アセットの更新を配信できます。この速さは、デバイスが確認するまさにそのチャネルでリリースが有効かどうかにかかっています。
Cloud Defaultをたった今変更した場合は、デバイス側のタイミングに注意してください。新規インストールではすぐに新しいルートが使われます。既存デバイスは通常、次回の更新チェック時に切り替わります。アプリを閉じて開き直すと、そのチェックのトリガーにはなりますが、ピン留めされたチャネルを上書きすることはできません。
次に、アプリ内で結果を確認します。呼び出します。getChannel()アップデーターの起動後に呼び出します。返されたチャネルを、アプリバージョンとバンドルバージョンの横にログとして記録してください。ダッシュボードだけを確認するより、デバイスが認識している内容が分かるため有用です。
アプリが起動時またはフォアグラウンド時のみチェックする場合、遅延が発生します。アップデーターが起動しない画面を開いてテストしないでください。短いテストビルドでは、既知の起動パスにチェックを配置し、リリース前に余分なログを削除してください。
返されたチャンネルが正しいのにbundleが届かない場合は、互換性とロールアウトのルールに進んでください。返されたチャンネルが間違っている場合は、ステップ1に戻り、Cloud Default に優先する割り当てをクリアしてください。
ステップ4: 強制同期を実行し、デバイス側のログを確認する
目的は、古いローカル状態とサーバー側の配信問題を切り分けることです。新たにチェックインすることで、新たな手がかりが得られます。
まず、デバイスにネットワークアクセスがあるか確認してください。アプリのセッションが正常でも、アップデーターがエンドポイントに到達できるとは限りません。企業のフィルター、VPNのルール、キャプティブポータル、セッション切れが更新リクエストをブロックしている可能性があります。
次に、アプリをフォアグラウンドに移動し、アップデーターのチェックが完了するまで待ちます。アプリで更新ステータスイベントを公開している場合は、現在のチャンネルと一緒にそのイベントをログに記録してください。「update started」だけをログに記録するのは避けてください。bundleが見つかったのか、ダウンロード、検証、インストール、拒否のどの段階まで進んだのかを知る必要があります。
Capgo のデバイスログを使って、最初に失敗したステージを特定します。最終的な「update failed」メッセージより、最初のエラーの方が役立つことがほとんどです。例えば、チャンネルが見つからない場合はルーティング、互換性による拒否はネイティブランタイムやバージョンゲート、ダウンロードエラーはネットワークアクセスやbundleリクエストの問題を示します。
| 確認内容 | 想定される確認ポイント | 次のアクション |
|---|---|---|
| チェックイン記録なし | アプリがアップデータに到達していないか、サービスに接続できません | 起動時の code、ネットワークアクセス、およびアップデータ初期化を確認してください |
| アプリ内のチャネルが誤っています | force、override、ローカル値、または設定値が優先されます | 優先度の高い割り当てをクリアし、呼び出してくださいgetChannel()をもう一度クリック |
| チャネルは正しいが、対象バンドルなし | リリース状態またはバージョンゲートが配信をブロック | バンドルのステータス、アプリバージョン、チャネルルールを確認 |
| バンドルは見つかったが、インストールが拒否された | 互換性、署名、またはローカルストレージの問題 | デバイス側の最初のエラーを確認し、互換性のあるbundleでテストする |
| インストールは完了しているが、古いcodeが動作し続けている | 新しいbundleがロードされていないか、以前のバージョンでアプリが再起動した | リロードの挙動、アクティブなbundleの状態、ロールバックイベントを確認する |
再インストールは有効なテストですが、証拠が変わってしまいます。再インストールによりローカルのchannel状態がクリアされる可能性があるため、現在のchannelとログをキャプチャした後に実行してください。
再現可能な確認を行うために、以下の値を1行のログに記録してください：
- App ID とネイティブアプリのバージョン
- channelの解決元
getChannel() - updaterの最終チェック時刻
- サーバーが検出したbundleバージョン
- インストールまたは拒否の結果
その小さな記録は、問題をオンデマンドで再現できないテスターのデバイスを調べるときに役立ちます。また、CIチームが自動スモークテストを回す際の明確なシグナルにもなります。
プラグイン API の挙動を確認する必要がある場合は、公式の Capgo Capacitor Updater ソースリポジトリを使用してください。特に、ローカルでのチャンネル変更とダッシュボードでのデバイス割り当ての違いに注意してください。
プロのヒント: クリアする前に、解決後のチャンネルを記録しておきましょう。そうしないと、状態を直した代わりに、失敗の理由を示す手がかりを失ってしまうかもしれません。
ステップ 5: ロールアウトルール、バージョンゲート、自動ロールバックの確認
目的は、Capgo が意図的にバンドルの配信を保留、または差し戻したかどうかを確認することです。アップデートが配信されないのは、セーフティルールが設計通りに機能している場合もあります。
チャンネル設定を開き、リリースに紐付いているすべてのルールを確認してください。最小アプリバージョン、ロールアウトのパーセンテージ設定、デバイスフィルター、リリースに関連付けられた条件をチェックします。ルールの対象外にあるデバイスは、チャンネルが正しくても現在のバンドルのままです。
バージョン形式も確認してください。Capgo はリリースの比較にセマンティックバージョニングを使用します。人間には正しく見えるバージョンゲートでも、アプリやバンドルが予期しない形式を使っていると挙動が変わることがあります。Native Build と OTA リリースで形式を揃えてください。
次に、ロールバックの動作を確認します。ヘルスチェックが失敗すると、自動ロールバックによってデバイスが以前のバンドルに戻されることがあります。ダッシュボードには古い方のアクティブな code が表示される一方、期待しているリリースは存在しているものの利用できない状態のままになっている場合があります。
疑わしいバンドルは、そのイベントを確認する前に削除しないでください。削除すると有用な証拠が失われます。まずバンドルバージョン、チャネル、ロールアウト状態、ロールバック理由を記録します。その後で、リリースを一時停止するか、動作確認済みのバージョンを公開するかを判断してください。
リスクのある変更にはステージングチャネルを使います。まず小さなテストグループにバンドルを配信し、適用状況とエラーシグナルを監視します。リリースが期待通りに動作したら、ロールアウトを進めます。これにより、問題のあるWebレイヤーの変更がすべてのアクティブなデバイスに一度に届くのを防げます。
ロールバックで修復できるのは、OTAで変更可能な code だけです。失敗の原因がネイティブプラグインの不足や互換性のないネイティブ API にある場合は、新しいストアビルドが必要です。古いJavaScriptバンドルを送信しても、アプリに欠けているネイティブの部分は追加されません。
ルールを調べるときは、次の3つの質問を投げかけてください：
- このデバイスはアプリバージョンの条件を満たしていますか？
- デバイスはロールアウトグループに入っていますか？
- ヘルスチェックや手動での操作によって、古いバンドルに戻されていませんか？
ここでは Capgo が役立ちます。同じチャネルモデルで段階的リリース、ロールバック、更新アクティビティの可視化を1つのワークフローで実現できるためです。ルールセットは最小限に保ちましょう。インシデント中に積み重なった例外の山よりも、短いポリシーの方が監査しやすくなります。
API ベースのチェックが必要な場合は、 Capgo 公開 API ドキュメント デバイス、チャンネル、bundleのリソースを説明します。サーバー側の表示とアプリが報告する内容を比較するのに使います。この比較で、古いダッシュボードフィルターや自動化によって作成されたデバイス割り当てに気づけます。
ロールバックはガードレールであり、テストの代わりではありません。本番チャンネルごとに、動作確認済みのbundleを1つ常に用意しておいてください。
ステップ6: リアルタイム分析で正確な失敗箇所を特定する
「更新されていない」を単一の失敗として扱うのはやめましょう。分析を使えば、デバイスが一度もチェックインしていないのか、条件を満たすbundleが見つからなかったのか、ダウンロード中に失敗したのか、後からロールバックされたのかを判別できます。
まず影響のあるデバイスグループから始めます。アプリのバージョン、プラットフォーム、チャンネル、bundleのバージョンでフィルタリングして、パターンを探してください。古いアプリビルドだけが失敗するなら、ネイティブ互換性ゲートが原因かもしれません。1つのチャンネル内の全デバイスが失敗するなら、チャンネルまたはデプロイを確認してください。
時間経過に伴う導入率を比較します。リリース後に横ばいなら、ルーティングか対象条件の問題が疑われます。上昇後に下降した場合は、インストールエラーやロールバックが考えられます。緩やかな上昇は、単にデバイスがまだアプリを開いていないだけかもしれません。
タイムスタンプの扱いに注意してください。ダッシュボード上のイベント時刻は、ユーザーのローカル時刻と異なる場合があります。アップデートイベントをデバイスの最終チェックイン時刻と照らし合わせてください。テスターが「アプリが実際にチェックインする前にアップデートが失敗した」と言う場合の切り分けに役立ちます。
Analyticsは、チャンネル変更を安全にテストするのにも役立ちます。一度に1つの変数だけを変更してください。ルーティングをテスト中はbundleを一定に保ち、新しいbundleをテスト中はルーティングを一定に保ちます。両方を変更すると、どの変更が問題を解決したのかデータから判断できません。
インシデントが発生した場合は、小さなエビデンスセットを保存してください:
- デバイス識別子または内部テストラベル
- 解決されたチャンネル
- ネイティブアプリのバージョン
- 期待されるbundleとインストールされたbundle
- 最終チェックイン時刻
- ロールバックまたは拒否イベント
Capgoのリアルタイムビューは、リリースプロセスでCI/CDを通じてアップデートを送信する場合に最も役立ちます。デプロイジョブがbundleをアップロードし、監視ステップがテストデバイスが意図したチャンネルとbundleを報告していることを確認できます。これにより、手動のクレームをリリースゲートに変えられます。
Analyticsデータをリリース記録と紐付けてください。デプロイノートにコミットまたはビルド参照を記載します。2つのbundleが類似したバージョンラベルを持っている場合、ビルド参照によってどのcodeが実際に変更されたかを知ることができます。
Cloud Default変更後に既存のデバイスだけが失敗する場合、設定をさらに変更する前に次のチェックインを待ってください。新規インストールは有用なコントロールです。古いローカル状態がないデバイスでデフォルトルートが機能するかを判断できます。
ステップ 7: デフォルトチャネルが古いままになるのを防ぐ
目標は、ユーザーに影響が出る前にチャネルのドリフトを可視化することです。小さなリリースチェックリストで、ほとんどの再発を防げます。
各アプリ環境でルーティングモデルを1つ選択してください。本番環境では、省略してdefaultChannelCapgo Cloudにデフォルトを制御させることもできます。テストビルドでは、明示的なチャネルを設定できます。危険な構成は、古いローカルオーバーライド、古いネイティブ設定、誰も検証しない新しいCloud Defaultの混在です。
これをnpx cap sync設定変更後のビルドパスに追加してください。同期ステップが失敗したらビルドも失敗させてください。コマンドはシンプルですが、スキップすると昨日のチャネルが今日のネイティブバイナリに焼き込まれる可能性があります。
デプロイ後にスモークテストを追加してください。テストデバイスはアプリを起動し、次を呼び出し、getChannel()期待されるバンドルを確認し、結果を記録します。検証は、OTAワークフローでよく抜けがちなステップです。アップロードだけでは、ほとんど何も証明できません。
ローカルチャネルcodeは、明確なフィーチャーフラグでガードしてください。テストヘルパーが次を呼び出す場合setChannel()、本番ビルドに誤って含まれないようにしてください。ローカルキャッシュはダッシュボードのオーバーライドとして表示されないことがあるため、UIだけではすべての問題を拾えません。
次のようなリリースチェックリストを使いましょう：
- アプリIDとネイティブバージョンを確認する。
- ターゲットチャネルを選択します。
- そのチャネルにバンドルをアップロードします。
- バンドルがアクティブであることを確認します。
- デバイスのスモークテストを実行します。
- 返されたチャネルを次で確認します
getChannel(). - ロールアウトを拡大する前に、導入状況を監視します。
本番リリースではロールバック保護を有効にしておきましょう。明確なチャネルやロールバック計画なしにデプロイするのはよくある失敗パターンです。そうなると、問題のあるバンドルを止める安全な手段がチームに少なくなります。
Capgo は組織ごとのサブスクリプション制で、14日間の無料トライアルがあります。トライアルはダッシュボードを見るだけでなく、実際のアプリビルドでリリースフローをテストする機会として活用してください。段階的デプロイ、ロールバックテスト、自動チャネルチェックを1回ずつ試してください。
セキュリティも同じチェックリストに入れておきましょう。CI/CDトークンを保護し、Cloud Defaultを変更できる人を制限してください。本番デプロイの認証情報はローカルスクリプトに置かないでください。不正なチャネル変更は、監査ログを確認するまで古いデバイスのように見えることがあります。
頻繁にリリースするチームは、プロセスを退屈なままにしておきましょう。デプロイは1コマンド。既知のテストデバイスは1台。明確なチャネルルールは1つ。追跡、導入、ロールバック。
重要なポイント: 設定を同期し、隠れたローカルオーバーライドを避け、解決後のチャネルをテストし、ロールバックを準備しておくことで、古いルーティングを防げます。
よくある質問
Capgo のクラウドデフォルトチャネルが既存デバイスに反映されないのはなぜですか？
既存のデバイスは、次の更新チェックまで古いチャネルを維持する場合があります。ローカルチャネル、ダッシュボードのオーバーライド、または強制割り当てが Cloud Default より優先されることもあります。デバイスの解決済みチャネルを確認するにはgetChannel()、より強い割り当てをクリアし、アプリをフォアグラウンドに移動してください。
Capgo の Cloud Default を変更すると、インストール済みのすべてのアプリに適用されますか？
いいえ、Cloud Default を変更しても、インストール済みアプリすべてのチャネルが即座に書き換えられるわけではありません。新しいデバイスはすぐに新しいデフォルトを使用できます。既存のインストールは、切り替え前にチェックインが必要であり、より強いチャネルルールやローカルオーバーライドが適用されている場合は切り替わりません。
Capgo のチャネル変更時に npx cap sync は何をしますか？
npx cap syncは、更新された Capacitor 設定をネイティブプロジェクトにコピーします。defaultChannelを変更して sync をスキップすると、次のネイティブビルドに古いチャネル設定が含まれる可能性があります。プロジェクトルートからコマンドを実行し、新しいテストバイナリをビルドしてインストールしてください。
setChannel を実行すると、Capgo にデバイスオーバーライドが作成されますか？
いいえ、setChannel()は、アプリがローカルに保存するチャネルを変更します。バックエンドの Device Override を作成しないため、Capgo ダッシュボードにデバイスがオーバーライド済みとして表示されない場合があります。デバイスがデフォルトルーティングに戻るべき場合はローカル割り当てをクリアし、結果をgetChannel().
Capgo は OTA bundle を通じてネイティブ code を更新できますか？
いいえ、Capgo の OTA アップデートが適用されるのは、JavaScript、CSS、アセットなどの Web レイヤーの code です。ネイティブプラグイン、権限、ネイティブ API の変更には新しいストアビルドが必要です。バンドルが、インストール済みアプリにないネイティブ code を要求している場合、チャンネルが正しくてもアップデートが拒否されることがあります。
まとめ
まずはダッシュボードのデフォルトではなく、解決済みのチャンネルを確認してください。割り当てを確認し、npx cap syncを実行して、ネイティブランタイムに対してバンドルを検証し、ロールアウトルールを変更する前にデバイスログを確認してください。その後、Capgo にデプロイ後の小さなテストを追加し、getChannel()を呼び出して、期待どおりのバンドルであることを確認します。
