よくある質問

インストール手順と、このプラグインの完全なMarkdownガイドを含むセットアッププロンプトをコピーします。

ここにない質問があれば、お気軽にどうぞ！Issueを立てることも、 Discord で質問することもできます。

「code push」とは何ですか？

「Code push」（別名「OTA（Over-The-Air）アップデート」）は、Capacitor 開発者が本番環境のアプリにアップデートをデプロイできるクラウドサービスです。Capgo は現在、Android、iOS、Electron で動作します。

「Code Push」は、 Microsoft と Expo、どちらも Capacitor をサポートしていません。

Capgo CLI のメジャーバージョンは、プラグインや Capacitor のバージョンと一致させる必要がありますか？

いいえ。常に最新の Capgo CLI を使用してください（npx @capgo/cli@latest）。CLI と Capgo コンソールは独自のバージョン管理に従い、サポートされているすべてのアップデータプラグインのメジャーバージョンと互換性を保ちます。Capgo プラグインは Capacitor のメジャーバージョンに従います。詳細は Capgo のバージョニングの LTS タグ（例： @lts-v7.

bundle と release の違いは何ですか？

「リリース」という用語は、アプリストア向けにバイナリを準備することを指します。後でバンドルを生成するために、Capgo はアプリストアに配信された正確なバイナリを知る必要があります。

「バンドル」という用語は、リリースを新しい code に更新するために適用できるパッチを指します。 npx @capgo/cli@latest bundle upload このコマンドは、ローカルの新しい code からバンドルを生成し、ユーザーに配信するために使用されます。

Delta update のファイルパスに制限はありますか？

はい:

ゼロバイトファイル: CLI のログ Ignoring empty file... 空のファイルを Delta ファイルから除外します。アップロードは失敗しないため、空のファイルが含まれていてもデプロイは停止しませんが、結果的なバンドルが変更される可能性があります。Delta バンドルのパスにゼロバイトファイルを含めないでください。
スペースを含むパス: バンドルパスにスペースが含まれている場合、Delta アップロードは明確なエラーとともに早期に失敗します。Delta update をアップロードする前に、ファイルやディレクトリ名からスペースを削除してください。

詳細は差分アップデートセットアップの詳細はこちら。

ロードマップを教えてください。

プロジェクトボードも公開しており、以下から確認できます： https://github.com/orgs/Cap-go/projects

チームも公開環境で活動しているため、いつでも作業内容を確認できます。ロードマップや優先事項に関するご質問は、Github の issue または Discord.

チームで Capgo を利用できますか？

はい！すべてのプランで開発者数は無制限です。制限するのは組織ごとのアプリ指標（MAU、ストレージ、帯域幅）のみです。

詳細はチーム詳細はこちら。

Capgo はソース code を保存しますか？

いいえ。Capgo のサーバーがソース code を参照することはありません。次を実行すると npx @capgo/cli@latest bundle upload、Capgo は minify/コンパイル済みの code のzipファイルを保存します。これはブラウザが受け取るのと同じ code であり、ソース code ではありません。

セキュリティをさらに高めるには、2つのオプションがあります：

エンドツーエンド暗号化：アップロード前にbundleを暗号化すると、ストレージ上および転送中のbundleを保護でき、秘密鍵がなければ第三者が有効な暗号化アップデートを生成することもできません。ただし公開鍵は配布されたアプリに含まれるため、配信済みのWebアセットのリバースエンジニアリングを不可能にするものではありません。
外部URLからのアップロードバンドルを独自のサーバーに保存し、ダウンロードリンクのみをオプション付きでCapgoに提供します --external <url>

プライバシーポリシーもご覧ください: https://capgo.app/privacy

bundle ファイルは非公開データですか？

いいえ。バンドルファイルはアプリユーザーがダウンロードすることを前提とした公開Webアセットです。バンドルURLを知っている誰でもこれらのファイルを取得でき、Capgoはセットアップ時とドキュメントでユーザーにこれを通知します。

バンドルファイルへのアクセスはデータ漏洩とはみなされません。シークレット、認証情報、個人データ、規制対象データをアプリバンドルに含めないでください。高セキュリティ用途でより強い機密性が必要な場合はエンドツーエンド暗号化を使用しますが、セキュリティ報告の観点からは、配布されたアプリのcodeとアセットは公開情報として扱ってください。

CI システムから Capgo を利用できますか？

はい。CapgoはCIシステムから使用することを前提としています。ガイドを公開しています Android と Github Actions と iOSと、および GitLab。他の CI システムも同様です。

問題が発生した場合は、GitHub の issues または Discord で遠慮なくご連絡ください。

Firebase Remote Config や Launch Darkly との違いは何ですか？

Code push は、デバイスに新しい code を追加したり、code を置き換えたりできます。Firebase Remote Config と Launch Darkly はどちらも設定システムです。新しいバージョンをリリースせずにアプリの設定を変更できますが、code の代替として設計されたものではありません。

依存関係のフットプリントはどのくらい増えますか？

最近測定していませんが、code push ライブラリは Capacitor アプリに 1MB 未満の増加をもたらすと予想しています。優先度が高まった場合、これをさらに小さくする方法がいくつかあります。サイズがボトルネックになっている場合は、お知らせください！

Capgo は iOS 18.4 Simulator で動作しますか？

いいえ。iOS 18.4 シミュレータに影響を与える上流の問題により、Capgo はそこで確実に動作しません。実機でテストするか、別の iOS シミュレータバージョンを使用してください。

React Native の問題の詳細はこちら: facebook/react-native#50510

code の push は大規模なアプリでも動作しますか？

はい。code pushで更新できるアプリケーションのサイズに制限はありません。前述の通り以下、Capgo はサイズに関係なく、アプリケーション内のJS code をすべて変更できます。

注意点: サイズが大きすぎると、ユーザーが更新をダウンロードしにくくなります。アプリはできるだけ小さく保つことをお勧めします。

Capgo code push はどのような用途に使えますか？

以下のような多様な用途を確認しています:

本番環境のアプリへの緊急修正。
旧バージョンのアプリを使用しているユーザーへのバグ修正の配信。
頻繁な配信（例: 毎時）。

ほとんどのアプリストアでは、アプリの動作を大幅に変更するcode の配信は禁止されています。詳細は以下詳細はこちら。

Capgo における「MAU」の定義は？

MAU とは Monthly Active Device（月間アクティブデバイス）のことです。30日間のローリング期間中に Capgo と通信した個別のデバイスが、その native app ID における 1 MAU としてカウントされます。同一の物理デバイスが 2 つの異なる native app ID で使用されている場合、それぞれの app ID で 1 回ずつカウントされます。app ID 間での重複排除は行われません。

flavours の違いが web レイヤーやアップデートのルーティングのみである場合は、単一の native app ID とチャンネルを使用してください。これにより、flavours を 1 つの Capgo アプリにまとめたまま、リリースが簡単になります。flavour ごとに別の bundle ID、署名 ID、エンタイトルメント、ストア掲載情報が必要な場合は、個別の native app ID を使用してください。

iOS では、 v7.25.0以降 を使用することで、Keychain を介して通常の再インストール後もアプリ固有のランダムなデバイス ID を保持します。Android の場合は、 v7.50.1+ (または v5.50.1+ と v6.50.1+ これらのリリースラインでは); ID は Android Backup/Restore がアプリの設定を保持している場合にのみ復元されます。バックアップを無効にしたり、これらの設定を除外したり、アプリデータを消去したりすると、新しいデバイス ID が生成されます。アプリを更新しても新しいデバイス ID は作成されません。

テストおよび開発ビルドでは、本番チャネルで開発ビルドとエミュレータへの配信をオフにしてください。これは配信を制御するもので、MAU は制御しません。デバイスが Capgo に接続すると、引き続きカウントされる可能性があります。本番利用に含めないようにするには、Live Updates を無効にし、本番の Capgo エンドポイントを呼び出さないでください。詳細については Live UpdatesなしでNative Buildをテスト正確な設定を参照してください。

Capgo code のプッシュは何に使えませんか？

Capgo では、Java、Kotlin、Objective-C、Swift、native plugin、native configuration などの native の code を変更できません。これらの変更には、新しい native アプリのリリースが必要です。ストア審査の範囲については、以下を参照してください： App Store および Google Play のポリシー.

Capgo 経由で capacitor.config.ts の変更内容を更新できますか？

いいえ。簡単に言うと、Capgo が送信できるのは、HTML、CSS、JavaScript、アセット、およびその出力に bundle された純粋な JavaScript パッケージの変更を含む、生成された web build フォルダのみです。変更が必要なのは、 capacitor.config.tsnative plugin の設定、native パッケージのインストールやアップグレード、および iOS または Android プロジェクトを更新する必要があるものには npx cap sync または npx cap copy native アプリのリリースが必要です。

Capacitor の設定ファイルは native build 時に読み込まれ、native アプリのバイナリにコンパイルされます。Capacitor の設定を変更する必要がある場合は、以下を実行する必要があります：

アップデート capacitor.config.ts ローカルで
ネイティブアプリの再ビルド（npx cap sync その後にネイティブビルド）
新しいバイナリをアプリストアに提出

Capgo はストアへの提出を代行してくれますか？

Capgo Buildは、準備済みのネイティブiOSまたはAndroidプロジェクトをコンパイルして署名し、設定に応じて署名済みの成果物をApp Store ConnectやGoogle Playに提出できます。プライベート依存関係、Webビルド、Capacitor の同期、カスタムのネイティブ準備には既存のCIをそのまま使えます。Capgo は、ネイティブビルドステップ用に準備されたネイティブプロジェクトを受け取ります。

詳細は Capgo のビルドおよびビルド設定のリファレンスワークフローとストア提出オプションについて。

Capgo はディスクのどこに何を保存しますか？

Capgo updater（アプリのビルド時にアプリへ組み込まれるもの）は、capacitor が code のロードを許可している唯一のディレクトリに、最後にダウンロードした bundle をキャッシュします。Android では次の場所です： /data/user/0/com.example.app/code_cache/capgo_updater ただし、このパスのベース部分は Android システムが提供するもので、実行時に動的に変わる可能性があります。iOS デバイスでは、データは次の場所に保存されます： Library/Application Support/capgo.

Capgo CLI ツール（例： npx @capgo/cli@latest bundle upload）はディスク上の npm キャッシュにインストールされます。ログイン情報はホームディレクトリの次の場所に保存されます： ~/.capgo.

Capacitor Hot Reload との関係は？

Capacitor の Hot reload は開発時専用の機能です。本番環境向けは Code push です。

Hot reload は、開発中にデバイス上の code を変更できる Capacitor の機能です。利用するには、ローカルマシンに接続するためのプロキシを指定して Capacitor アプリをビルドする必要があります。

Code pushは、本番環境のデバイス上でcodeを変更できる機能です。プラットフォームに応じて、さまざまな技術を用いてこれを実現します。

Capgo code pushでは、どのような変更をサポートしていますか？

Capgoを使用すると、アプリケーション内のあらゆるJS codeを変更できます。これにはアプリのcodeや生成されたcodeが含まれます。また、依存関係を更新することもできます。 package.json ただし、ネイティブのcode変更を必要としない場合に限ります。

ネイティブのcode（例：AndroidのJava/KotlinやiOSのObjective-C/Swift）の変更をサポートする予定はありません。ネイティブのcodeの変更を検出すると、バンドルに含まれないため、ツールが警告を表示します。

Webはサポートされていますか？

Webはすでにこの仕組みで動作しているため、Code pushは必要ありません。ユーザーがWebアプリを開くと、必要に応じてサーバーから最新バージョンがダウンロードされます。

Webでのcode pushのユースケースがあれば、ぜひ教えてください！

iOS、Android、Mac、Windows、Linuxなどで動作しますか？

はい。

これまでAndroid、iOS、Electronのサポートに注力してきており、code のプッシュは3つすべてで本番利用できます。

Capgo がサポートするOSバージョンは？

Capgo は Capacitor と同じAndroidバージョンをサポートしています。

現在、Capacitor は Android API レベル22以上とiOS 13.0以上をサポートしています： https://capacitorjs.com/docs/main/reference/support-policy

Capgo は Capacitor のどのバージョンをサポートしていますか？

Capgo は現在、Capacitor の最近の安定版のみをサポートしています。Capacitor の旧バージョンもサポート可能ですが、長期的なメンテナンスに必要なインフラがまだ整っていません。将来的には、エンタープライズのお客様向けのバージョンを含め、より多くの Capacitor バージョンをサポートする予定です。 https://github.com/Cap-go/capgo/issues/1100

Capgo は Capacitor の安定版を追跡しており、通常、安定版のリリースから数時間以内に更新されます。この更新システムは自動化されており、実行には数分かかります。その後、サーバーに公開する前に手動での検証ステップを行っています。

App Store/Play Store の審査プロセスやポリシーとの関係は？

Capgo が配信するのは Capacitor のウェブレイヤー（アプリの WebView 内で動作している HTML、CSS、JavaScript、およびアセット）のみです。ネイティブバイナリ、ネイティブプラグイン、権限、エンタイトルメント、署名、ストアのメタデータは変更しません。

ネイティブの変更や、アプリの審査対象となる目的・機能に影響しうる重大な変更には、必ずストア経由のネイティブリリースを使ってください。Live Update は、ユーザーに提出・開示済みのアプリ体験の範囲内に留めてください。

Capgo が原因で Apple のリモート code 実行がリジェクトされることはありますか？

いいえ、それは不可能です。Capgo はネイティブの code、動的ライブラリ、framework、plugin をインストールしたり実行したりすることはなく、呼び出すことも dlopen, dlsym, performSelector:、または method_exchangeImplementations()できません。レビュー済みのバイナリに既にコンパイルされている WebView または JavaScriptCore エンジン内の JavaScript、HTML、CSS、静的アセットを置き換えるだけです。

App Review がガイドライン 2.5.2 や「リモート code 実行」を挙げた場合、Capgo を原因と決めつけないでください。レビュー通知を読み、ネイティブプロジェクトや他の SDK に実行ファイルの読み込みや private-API の使用がないか確認してください。以前、Capgo のスプラッシュ画面自動非表示処理における動的リンクについてレビュー指摘がありましたが、それはライブアップデートではなく、そのネイティブ plugin のバグであり、該当するリンクは削除されました。

Apple のリモート code 実行に関する制限は、Capgo に影響しますか？

いいえ、Capgo がリモート code 実行拒否を引き起こすことはありません。詳しくは Capgo が原因で Apple のリモート code 実行がリジェクトされることはありますか？をご覧ください。Capgo は Capacitor アプリのインタプリタ方式の Web レイヤー向けに作られています。レビュー後にネイティブの code をインストールしたり実行したりすることはありません。Apple は各アプリを個別の事実関係に基づいて審査するため、Capgo が結果を保証することはできません。

Appleの App Review Guideline 2.5.2 では、アプリの機能や動作を追加・変更するcodeをダウンロード、インストール、実行してはならないとしています。審査チームは、このルールとApple Developer Program License Agreementの セクション 3.3.1(B) （実行可能なcodeに関する規定）を根拠に、承認後にリモートリソースを使って挙動を変えるアプリをリジェクトします。典型的な例は次のとおりです。 dlopen, dlsym, performSelector:、またはプライベートAPIにアクセスするリモートスクリプトなどです。

同ライセンス契約では、次の条件を満たす場合に限り、 インタプリタ型のcode のダウンロードを許可しています：

アプリの主な目的を変更しないこと、
署名、サンドボックス、その他のOSセキュリティ機能をバイパスしないこと、および
他のアプリケーション向けのストアやストアフロントを作成しないこと。

セクション 3.3.1(C) App Store、Custom App Distribution、TestFlight 以外の配信メカニズムを通じて、追加の機能や機能性を提供・アンロック・有効化することを別途制限しています。ただし、Apple が事前に書面で承認した場合、または以下のセクションで認められている活動は除きます。 3.3.9(A) (アプリ内課金 API)。その条項が特定の interpreted code OTA bundle にどう適用されるかは、貴社チームと法務顧問が判断すべき法的問題です。

Capgo は、アプリの WebView または JavaScriptCore エンジン内で既に動作している JavaScript、HTML、CSS、静的アセットを置き換えます。ネイティブバイナリ、マシン code、動的ライブラリ、プラグインは含まれません。ガイドライン 4.7 (以下で明確化) 2025年11月) は、アプリがバイナリに埋め込まれていない HTML5 や JavaScript のミニアプリ、ミニゲーム、チャットボット、プラグイン、または同様のソフトウェアを提供する場合に適用されます。ユーザーがアプリ内から複数の異なるソフトウェア体験を閲覧・起動できる場合は、追加の 4.7 要件について法務顧問と検討してください。単一の製品がレビュー済みの自身の web bundle をチャネル経由で更新するのは別のユーザー体験ですが、その説明にメタデータが合致するかどうかを決めるのは Apple だけです。

ネイティブ機能、権限、エンタイトルメント、実質的な機能変更は、通常の App Store バイナリで配信してください。提出済みのアプリの範囲内に留まる Web レイヤーの修正や改善には Capgo を使用してください。詳細は Apple のリモート code 実行と Capgo より詳細なコンプライアンス分析については、またはブログの解説ガイドライン 2.5.2、ADPLA 3.3.1(B)、および 2025 年のガイドライン 4.7 の明確化について。

Capgo は App Store または Google Play の承認を保証しますか？

いいえ。Apple と Google は各アプリとリリースを個別の事実に基づいて審査するため、Capgo は個別の承認や審査結果を保証できません。アプリの内容、開示事項、更新範囲、および現行のストアポリシーへの準拠については、引き続きチームが責任を負います。

審査とリリース計画については、公式ポリシーを直接ご確認ください： Apple App Store レビューガイドラインと Google Play デバイスおよびネットワークの不正利用ポリシー.

私の国で Capgo を使用できますか？

私たちは、どの国からのCapgoへのアクセスも制限しようとはしていません。

一部の国では、国内からアクセスできるURLに制限があることを認識しています。Capgoは現在、R2 StorageやCloudflare workersを含むCloudflare Cloudをホスティングに使用しています。

Capgoで使用されるURLは以下の通りです：

https://api.capgo.app — 以下で使用されます npx @capgo/cli コマンドラインツールがCapgoサーバーとやり取りし、ユーザーのデバイス上のCapgo updaterが更新を確認するために使用されます。
https://*.r2.cloudflarestorage.com — 以下で使用されます npx @capgo/cli bundleのアップロードとダウンロードを行うコマンドラインツール

これらのURLがすべてあなたの国からアクセス可能であれば、Capgoは動作するはずです。

お住まいの地域でこれらのURLへのアクセスをブロックする必要がある場合は、お知らせください。プロキシサーバーの利用など、解決策を一緒に検討します。

Capgo をセルフホストできますか？

はい。独自のインフラストラクチャでアップdaterバックエンドを運用する必要がある場合、ライセンス付きのセルフホスト型 Capgo デプロイメントをサポートしています。セルフホスト型 Updater デプロイメントモデルとエンドポイントの詳細はこちら。

code のプッシュにはインターネット接続が必要ですか？

はい。一般的なインターネットとは別にサーバーを構築してアップデートを配布することも考えられますが、デバイスにアップデートを転送するには何らかのネットワーク接続が必要です。

ネットワーク接続がない場合、Capgo はどのように影響を受けますか？

Capgo updater（Capgo でアプリをビルドするとアプリに含まれます）は、ネットワーク接続の問題に耐えられるように設計されています。

デフォルトのアップデート動作では、アプリの起動時に Capgo updater へ通知され、updater は別スレッドを生成して Capgo のサーバーにアップデートを問い合わせるネットワークリクエストを送ります。アプリが行っている他の処理をブロックしないよう、意図的に別スレッドを使用しています。ネットワークリクエストが失敗するかタイムアウトした場合、updater は次回アプリ起動時に再度チェックを試みるだけです。

Capgo のコマンドラインツール（例： npx @capgo/cli@latest bundle upload）は動作にネットワーク接続が必要です。Capgo でアプリを配信している場合は、CI システムにネットワーク接続があることを確認してください。

ユーザーが長期間アップデートせず、更新を逃した場合はどうなりますか？

私たちの実装では、リクエスト元のデバイスに合わせたアップデートを常に送信し、常に利用可能な最新バージョンへ更新します。そのため、ユーザーがしばらくアップデートしないと、途中のアップデートは「飛ばされる」ことになります。

アプリケーションのニーズに応じて、次の増分バージョンまたは最新バージョンで応答するように更新サーバーを変更できます。代替の更新動作が重要であれば、お知らせください。

Capgo は Capacitor とどのような関係ですか？

Capgo は Capacitor 用のプラグインで、code push を追加します。Capgo は Capacitor の代替ではありません。すでに熟知し愛用している Capacitor ツールを继续使用できます。

Capacitor の最新安定版リリースを追跡し、code push プラグインをそれに対応するように更新しています。

更新はいつ行われますか？

デフォルトでは、Capgo アプデーターはアプリ起動時に更新を確認します。バックグラウンドスレッドで実行され、UIスレッドをブロックしません。ユーザーがアプリを使用している間に更新がインストールされ、アプリが再起動された時点で適用されます。

また、Capgo アプデーターを手動で実行することも可能です @capgo/capacitor-updater パッケージを通じて、プッシュ通知を含む任意のタイミングで更新をトリガーできます。

Capgo アップデータは、ネットワークが利用できない場合やサーバーがダウンして到達不能な場合でも、アプリが通常どおり動作するように設計されています。サーバーからアップデートを削除した場合でも、すべてのクライアントは通常どおり動作し続けます。

パッチのロールバック機能を追加しました。最も簡単な方法は、以前のバンドルをチャネルにアタッチして元に戻すことです。

app_id を秘密にしておく必要はありますか？

いいえ。 app_id はアプリに含まれており、公開しても安全です。バージョン管理（公開でも）にチェックインしても、他の人にアクセスされる心配はありません。

あなたの app_id を持っている人は、Capgo サーバーからアプリの最新バージョンを取得できますが、アプリへのアップデートをプッシュしたり、Capgo アカウントの他の部分にアクセスしたりすることはできません。

Capgo サーバーに送信される情報は何ですか？

完全なデータインベントリ、エンドポイントの動作、プライバシー制御については、コンプライアンス.

設定 statsUrl: '' で明示的なアップデータ統計レポートを無効にできます。また、 statsUrl を、あなたが管理するプロキシまたはエンドポイントに送信することもできます。詳細はセルフホスト環境での統計処理。アップデートチェックには、Capgo が正しいアップデートを選択し、月間アクティブデバイス数を測定するために、アプリスコープのデバイス識別子が必要です。

このサブプロセッサー一覧は、プロバイダー、処理場所、転送メカニズム、変更履歴に関する最新の公開情報源です。

HIPAA の機密データを扱うアプリで Capgo は使えますか？

はい、ただしコンプライアンス責任者が適切なデプロイモデルを選択する必要があります。Capgo Cloudは現在、HIPAA準拠のホスト型統計プロセッサとして提供されていません。デフォルトでは、アップデータはデバイススコープであり、既知のアプリユーザーに紐付けられていないため、多くのチームがこのモデルを成功裏に利用しています。

より厳格なレビューに対応するため、プラグインのトラフィックを地理的にローカライズしたり、 statsUrl を空文字列に設定して統計を無効にしたり、統計エンドポイントのみをセルフホストしたり、ライセンス付きセルフホスティングを使用したりできます。 CapacitorUpdater.setCustomId(...) に、メールアドレス、ユーザーID、患者ID、従業員ID、またはアップデータテレメトリを個人にマッピングする値を渡さないでください。

詳細は HIPAA準拠完全な技術的なセットアップと、統計を無効にした場合のオブザーバビリティのトレードオフについては、こちらを参照してください。

Capgo の live update データを欧州に保存できますか？

はい。Capgo Cloudのプラグイントラフィックに対してEUデータレジデンスが必要なアプリは、アップデータエンドポイントをEUホストに設定できます：

updateUrl: https://plugin.eu.capgo.app/updates
statsUrl: https://plugin.eu.capgo.app/stats
channelUrl: https://plugin.eu.capgo.app/channel_self

アップデートの確認、統計、チャンネルの自動割り当てで同じリージョンのデータパスを使用するため、3つのEU URLをすべて併用してください。これらの値は capacitor.config.tsに保存されるため、既存のインストール済みアプリが新しいエンドポイントを使うには、本番モバイルアプリのネイティブリリースが必要です。

詳細はデータの保存場所の Capacitor および Electron の例を参照してください。

Capgo はどのプラットフォームをサポートしていますか？

現在、Capgo は Android、iOS、および Electron をサポートしています。すべて本番環境で利用可能です。

iOS、Android、または Electron での Capgo の利用は、それぞれ独立して決定できます。必要に応じて、Android 用や App Store 向けにビルドした ipa 用、または Electron 用のチャンネル戦略を設定できます。

Capgo は（比較的容易に）デスクトップや組み込みターゲットをサポートするように拡張可能です。これらが重要な場合は、ぜひお知らせください。

Capgo は Play Testing Tracks や Apple TestFlight とどのように連携しますか？

各アプリストアには、限定されたユーザーグループにアプリを配信するための個別の仕組み（「内部テスト」「クローズドベータ」など）があります。これらはすべて、ユーザーをグループに分け、それぞれに特定のバージョンのアプリを配信するための仕組みです。

残念ながら、これらの仕組みのすべてが、特定のテストトラックや TestFlight 経由でアプリがインストールされたことをサードパーティが検知できるわけではありません。そのため、これらのグループの構成を確実に把握することはできず、これらのグループに基づいて Capgo パッチへのアクセスを確実に制限することもできません。 https://stackoverflow.com/questions/53291007/can-an-android-application-identify-the-test-track-within-google-play https://stackoverflow.com/questions/26081543/how-to-tell-at-runtime-whether-an-ios-app-is-running-through-a-testflight-beta-i

Capgo bundle の利用範囲をセグメント化したい場合は、4つの選択肢があります。

グループごとに個別の channel を使用する。これが最もシンプルな方法ですが、複数の channel を管理する必要があります。すでに利用範囲の異なる dev channel と prod channel があるかもしれません。その場合は dev channel をアップデートして検証した後、別途 prod channel をアップデートできます。各リリースに対応するソースを追跡しやすくするため、バージョン管理で branch や tag を使うことをお勧めします。
オプトインユーザーのセットを独自に管理し、自動更新を無効化、特定のユーザーのみに対して更新をトリガーできます。 @capgo/capacitor-updater package 経由です。これは現在でも利用できますが、オプトインリストは自分で管理する必要があります。
Capgo では、デバイスごとに独自のオプトインメカニズムを作成できます（Test Tracks や TestFlight に似ていますが、プラットフォーム非依存です）。これにより、QA チームは bundle が一般公開される前にオプトインできます。
使用する段階的なロールアウトを使用して、チャンネル内のランダムで固定されたサブセットに候補の bundle を配信します。ロールアウト率を 0–100% で設定するか、 --rollout-percentage-bps を使用して 0.01% 刻みで設定できます。キャッシュ期間は 60 秒から 365 日まで設定可能で、自動一時停止ポリシーも任意で設定できます。これは名前付きデバイスグループを選択するものではありません。

請求

プランのアップグレードやダウングレードはどのように行いますか？

ダッシュボードからいつでもプランをアップグレードまたはダウングレードできます： https://console.capgo.app/settings/organization/plans。アップグレードはすぐに反映されます。ダウングレードは現在の請求サイクル終了時に適用されます。

MAU の上限に達するとどうなりますか？

Capgo から、MAU上限の50%、70%、90%、100%に達した時点でメールが届きます。上限に達すると、現在の請求サイクルが終了するまでLive Updatesはブロックされます。配信を再開するには、上位プランにアップグレードするかクレジットを購入してください。詳細は Capgo の料金プランと pricing.md のプラン階層を参照してください。

返金は可能ですか？

法律で義務付けられている場合を除き、有料サブスクリプションの料金は返金できません。一部の返金リクエストは、Capgo の独自の裁量により、ケースバイケースで検討される場合があります。該当すると思われる場合は、サポートまでお問い合わせください。

請求期間はいつリセットされますか？

請求期間は、Capgo のサブスクリプションを開始した日と同じ日付に、毎月自動的にリセットされます。例えば、月の15日に開始した場合、請求期間は毎月15日にリセットされます。

サブスクリプションを解約するにはどうすればいいですか？

ダッシュボードからいつでもサブスクリプションをキャンセルできます： https://console.capgo.app/settings/organization/plans

1年分を前払いできますか？

はい。組織プラン設定.

ストレージに含まれるのは何ですか？保持期間は変更できますか？

ストレージには、各チャネルの保持された履歴バンドルとそのDeltaアセットが含まれます。各アプリの未使用バンドルの保持期間は、App Settingsで管理できます。アクティブなチャネルまたはロールアウトにリンクされたバンドルは保護され、配信とロールバックのために利用可能のままになります。

リージョン間のレプリケーションによって、ストレージや帯域幅の消費は増えますか？

いいえ。bundle は、配信するリージョンに関係なく、ストレージでは 1 回だけカウントされます。帯域幅もリージョンによって倍増することはありません。次を参照してください：帯域幅のカウント方法.

帯域幅のカウント方法

帯域幅は、デバイスが Capgo から実際にダウンロードしたファイルだけをカウントします：

差分アップデート： でアップロードすると、 --deltaデバイスは、既に持っているバージョンから変更されたファイルだけをダウンロードします。カウントされるのはそれらのファイルだけです。大きな画像やフォントなど、変更のないファイルは再ダウンロードされず、コストはかかりません。次を参照してください：差分アップデート.
エッジキャッシュ: リクエストされたファイルまたはフルzipがすでにエッジにキャッシュされている場合、そのダウンロードは帯域幅にカウントされません。これはDeltaファイルとフルzipの両方に適用されます。
ダウンロード再開: ダウンロードが中断された場合、デバイスは停止した位置から再開します。ダウンロード済みの部分は再ダウンロードされず、カウントされません。
フルzip: Deltaなしでアップロードされたバンドル --delta、またはDeltaをサポートしていないプラグインバージョンのデバイスは、フルzipをダウンロードします。これはエッジキャッシュから配信されない場合にのみカウントされます。

帯域幅を抑えるには、 --delta を使用してアップロードし、めったに変更されない大きなアセットは固定のファイルパスに置いてください。

Enterprise SLAには何が含まれますか？

エンタープライズプランでは、本番環境プラットフォームの月次稼働率99.9%をコミットメントとして提供します。このコミットメントが未達の場合、月次稼働率に基づき10%から30%のサービスクレジットが適用されます。初期のサポート対応目標は、P1: 1時間（24/7/365）、P2: 2営業時間、P3: 1営業日、P4: 2営業日です。詳細はエンタープライズSLA の完全な条項をご覧ください。

統計と分析

ダッシュボードの統計は、UTCで毎晩0時に更新されます。統計は、直近30日間のローリング期間中にアクティブだった MAU から計算されます。

デバイスIDの生成方法

デバイスIDは初回実行時にデバイス上で生成され、デバイス単位のインストール重複排除や、パッチ総数ではなくインストールされたユーザー数（例: 月間アクティブユーザー）に基づく課金に使用されます。

Capgo の価格設定において、MAUはインストール数よりも正確で、デバイスごとのCapgoの実際のコストを反映するため、より優れた指標です。

デバイスIDの永続性:

iOSとv7.25.0以降、デバイスIDはKeychainに保存され、通常の再インストール後も維持されます。
Androidではv7.50.1以上（または該当リリースラインではv5.50.1+/v6.50.1+）を使用してください。Androidのバックアップ/リストアでアプリ設定が保持される場合のみ、デバイスIDが復元されます。
ElectronデバイスIDは安全なストレージに保存されます。
Androidに関する注意バックアップの無効化、関連する設定の除外、またはアプリデータのクリアにより、新しいデバイスIDが生成されます。Android v7.25.0からv7.50.0では、バックアップが有効な場合でも再インストール後に新しいデバイスIDが生成されることがあります。

デバイスIDはアプリスコープで、Live Updateの配信とMAUの重複排除をサポートします。広告やアプリ横断トラッキング用の識別子ではありません。

デバイスIDは、アプリがupdaterまたはstatsエンドポイント経由でCapgoにチェックインした後にリストされます。パッチをインストールしていなくてもデバイスリストに表示されます。

デバイス数がMAUと一致しない理由

デバイスリストとMAUは異なるシグナルに基づいています。

デバイスリストには、デバイスID、プラットフォーム、プラグインバージョン、OSバージョン、ネイティブバージョン、チャネル、インストール済みbundle、取得できた場合はリクエスト元の国など、各デバイスの最新の既知メタデータが表示されます。リクエスト元の国は、GPSやアプリが提供する位置情報ではなく、そのデバイスに対するCloudflare処理リクエストから受け取った最新の有効な2文字のcodeです。有効な国を含まないリクエストでは、最後に有効だった値はクリアされません。Capgoはアプリのチェックイン時にこのメタデータを更新しますが、同じメタデータを報告する繰り返しのチェックインでは、行や最終更新日時が変わらないことがあります。

MAUは請求期間中のアクティブなデバイスのユニーク数を数えます。デバイスのメタデータが同じままでもアクティビティは増えることがあるため、デバイス数とMAUは異なる場合があります。

プラットフォームごとに異なるアップデートを配信する方法

プラットフォームごとにチャンネルを作成し、各チャンネルでプラットフォーム固有のアップデートを無効化できます。

iOSチャンネルではAndroid向けのアップデートを無効にし、AndroidチャンネルではiOS向けのアップデートを無効にします。

その後、各チャンネルにbundleをアップロードすると、プラットフォームごとに異なるアップデートを配信できます。

両方のプラットフォームで同じアップデートが必要な場合は、1つのbundleを複数のチャンネルにリンクできます。bundleを複製する必要はありません。

FAQから続きを読む

使用している場合 よくある質問 live update の配信を計画するには、以下と連携させます： Capgo Live Update Capgo Live Updates のプロダクトワークフロー向けに、概要実装の詳細は Overview を機能実装の詳細は Features をアップデートの動作実装の詳細はアップデートの動作を、およびアップデートの種類実装の詳細はアップデートの種類を。