木曜日の夜、あなたのCapacitorJSショッピングアプリで、Android 14ユーザーにだけダッシュボードが真っ白に表示され始めました。iOSユーザーは通常どおり閲覧しており、Electronデスクトップユーザーからも報告はありません。オンコールのエンジニアはWebViewのリグレッションを疑い、Android Studioを開いて、デバイス間のレンダリング挙動の比較に数時間を費やします。しかし最終的な原因は、レンダリングバグではありませんでした。CDNのキャッシュ無効化がモバイルクライアントに届かず、ステージングのAPIキーが本番環境に到達していたのです。
このようなインシデントは珍しくありません。モバイルの障害は、リポジトリの境界を無視して起きることが多いからです。JavaScriptの新しい変更自体は無害でも、デプロイ、設定値、権限状態、サービス依存関係、ネットワークパスがユーザージャーニーを壊すことがあります。Microsoftのインシデント分析によると、 本番環境のインシデントの40%はcodeまたは設定のバグに起因し、60%はインフラ、デプロイ、サービス依存関係に起因していました。実践的な教訓はシンプルです： アプリのトラブルシューティングは、スタックトレースではなく、障害ドメイン全体から始める必要があります. (Microsoftのインシデント分析)
このプレイブックは、CapacitorJS と Electron のリリース後に私が使用するワークフローに基づいています。ユーザーが実行した内容を正確に特定し、再現を試みる前に本番環境のテレメトリを確認し、code 以外の原因を検証し、症状に一致する最も狭いレイヤーをデバッグします。7つのステップは、インシデントのスコープ設定、階層化されたログ、Web とネイティブのデバッグ、ネットワークと状態の確認、CI のガードレール、ライブアップデートの復旧、そして予防策を割り当てるインシデント後のレビューです。
目次
- ダッシュボードが暗転した夜
- Webview、ネイティブ、OSからのログを読む
- Webレイヤーとネイティブレイヤーのデバッグ
- ネットワーク、ストレージ、権限の初期チェック
- 早期検知システムとしての自動テストとCI
- 緊急リカバリチャネルとしての Live Updates
- 次のインシデントを防ぐ事後分析
ダッシュボードが暗転した夜
木曜日の夜、Android ユーザーからダッシュボードが真っ白になるという報告が寄せられた一方、Electron デスクトップユーザーは通常通り動作していました。最初の仮説は Android 14 または WebView のリグレッションでした。この手がかりは調査範囲を絞り込みましたが、根本原因の特定には至りませんでした。影響を受けたユーザーは、リリースチャネル、キャッシュされた設定パス、API 環境、そして特定のダッシュボードリクエストの順序を共有していました。
オンコールエンジニアは WebView バージョンの比較から着手しました。結果は妥当に見えましたが、結論には至りませんでした。ダッシュボードが真っ白になる原因は、レンダリング例外、空の API レスポンス、リクエストの拒否、無効なトークン、フィーチャーフラグ、またはセッション復元を妨げるストレージ読み取りなど、多岐にわたります。code を変更する前に、影響を受けたユーザーが受け取ったバイナリ、Web バンドル、設定、バックエンドパスを特定してください。
正確な障害箇所を特定する
開発者用ラップトップではなく、本番環境のテレメトリから始めましょう。Google の Android クラッシュおよび ANR ガイドラインでは、イベントを以下で絞り込むことを推奨しています デバイス、OS、時間ウィンドウ、その後、障害箇所が不明な場合は再現時に logcat を使用します。（Google の Android vitals トラブルシューティングガイドライン)
影響を受けたセッションからこれらのフィールドを取得してください：
- ビルドの識別情報： ネイティブアプリのバージョン、ビルド ID、Web バンドルのハッシュ、リリースタイムスタンプを記録します。
- 配布チャネル： ユーザーが canary、beta、staged、stable のいずれのコンテンツを受信したかを確認します。
- ランタイムのコンテキスト: Android または iOS のバージョン、デバイスモデル、ネットワークの種類、権限の状態、バックグラウンドから復帰したかどうかを記録します。
- 最後に成功したアクション: タップの正確な順序、リクエスト、レスポンスステータス、表示された結果をそのまま記録してください。
- 設定のスナップショット: API のベースURL、フィーチャーフラグ、認証設定、プラグイン構成を、正常に動作しているデバイスと比較してください。
Capacitor は、WebView内で実行されるWebコンテンツとネイティブバージョンを分離して管理します。これにより、ストアからインストールされたバイナリは共通でも、ユーザーごとに異なるJavaScript bundleを受け取ることが可能です。また、Web bundleは共通でも、異なるネイティブプラグインを使用することもできます。Electronの場合は、リリースmanifest、メインプロセスのバージョン、レンダラーbundle、アップデートチャネル全体で同様の確認が必要です。レンダラーパッケージのメタデータだけでは、ユーザーが実際に何を実行したかを特定できません。
変数を排除して再現する
識別子を収集したら、インシデントを次のように分類します： canaryのみ、段階的ロールアウト中、または全ロールアウト済み。canaryのみの失敗は、特定のbundle、フラグ、チャネルの割り当てに原因があることを示します。段階的ロールアウトでの失敗は、対象ユーザーやデバイス選択のロジックに問題があることを示唆します。全ロールアウト済みでの失敗は、共通設定、バックエンドの挙動、ネイティブ互換性の優先度を上げます。
問題が発生しているデバイスと正常なデバイスをdiffで比較してください。ネイティブプラグインのバージョン、Webハッシュ、チャネル、API 環境、認証状態、権限設定を確認します。エミュレータを使う前に、ユーザーの最後のアクションシーケンスをローカルで再現してください。1つのフラグが失敗を左右しているなら、他の変数は固定したまま、そのフラグの挙動をbisectしてください。
実践的なルール： ビルドID、チャネル、Webバンドル、OS、設定が一致するまで、再現を「同じバグ」と断定しないでください。
Androidダッシュボードのインシデントは設定修正で解決しました。チームはスナップショットを比較し、ネイティブバイナリが有効であることを確認し、WebViewとダッシュボードのcodeが変更されていないことを検証しました。以前のキャッシュ無効化がすべてのモバイルクライアントに届いていなかったため、本番クライアントはステージング資格情報を持つ環境を要求していました。そのため、復旧作業は設定の修正、適切なキャッシュ無効化ヘッダーの設定、影響を受けた地域とクライアントパスからのCDNパージの検証に集中しました。
この順序が重要なのは、パージコマンドが成功しても、すべてのユーザーが修正された値を取得できることを保証するものではないためです。復旧を宣言する前に、CDNレスポンス、キャッシュの経過時間、バンドルまたは設定のハッシュ、新しいクライアントセッションを確認してください。ネイティブ再ビルドは、失敗の原因となった成果物を変更せずにロールアウト時間を増やすだけでした。
今後のインシデントでも同じ規律を適用してください： ユーザーの成果物を特定し、障害箇所を特定し、環境の違いを排除してから、code をデバッグします。書面による モバイルチーム向けのインシデント対応ガイド は、ネイティブバイナリが障害箇所でない場合に live update を使用するか否かの判断を含む、テレメトリクエリ、ロールアウトの責任者、パージ検証、オンコールランブックの隣に配置すべきです。
Webview、ネイティブ、OSからのログ読み取り
CapacitorJS または Electron アプリケーションは複数のレイヤーでエビデンスを生成し、各レイヤーは異なる質問に答えます。WebView は JavaScript 例外や失敗したリクエストを表示できますが、すべてのプラグインの失敗を説明するわけではありません。ネイティブログはブリッジとライフサイクルの動作を公開し、OS はメモリ圧力、権限拒否、プロセス終了を記録しますが、アプリケーションの code はこれらを観測できない場合があります。
各症状をそのエビデンスに一致させる
の WebView レイヤーでは、コンソールエラー、未処理の Promise 拒否、ナビゲーションイベント、リクエスト URL、レスポンスステータス、リクエストタイミングを収集します。サイレントなプラグイン拒否は特に危険です。UI はレンダリングを継続する一方で、カメラ、ファイルシステム、セキュアストレージ、または通知操作がすでに失敗している可能性があります。
この ネイティブレイヤー Android の logcat 出力、iOS os_log のレコード、プラグインブリッジの例外、Activity または View Controller のライフサイクルイベント、ネイティブクラッシュトレースが含まれます。Electron では、メインプロセスのログストリーム、自動更新イベント、ウィンドウ作成の失敗、IPC メッセージが追加されます。レンダラープロセスのエラーは必ずしもメインプロセスには現れず、メインプロセスのクラッシュはレンダラーコンソールの出力には表示されません。
この OS レイヤー アプリケーションの制御範囲外のイベントを説明します。メモリ圧力、バックグラウンドでの強制終了、バッテリー制限、拒否された権限、プロセスの強制終了、システムレベルのクラッシュレポートを確認してください。このレイヤーは、有用な JavaScript スタックトレースがない「ランダムなクラッシュ」の原因を説明することがよくあります。
フィルタリング前に相関付けを行う
WebView、ネイティブブリッジ、バックエンド、中央ログシンク全体で共有されるリクエスト ID または操作 ID を使用します。ユーザー操作が始まる前に ID を付与し、ネットワークリクエストとネイティブコールバックを通じて保持します。タイムスタンプは一致した形式で相関付けし、デバイスの時計のズレを考慮し、元のイベントを保持した後にのみフレームワークのノイズをフィルタリングします。
すべてのレイヤーで同じコンテキストフィールドを保存します：アプリバージョン、Web バンドルハッシュ、チャネル、デバイス、OS、セッション、機能フラグの状態。中央集約的な収集により、再現試行をユーザーの証拠と比較でき、推測で置き換える必要がなくなります。実用的な モバイルデバッグ用のログ分析ツールキット は、エンジニアが各デバイスからスクリーンショットを集めることを強制せずに、これらのフィールドを検索するのに役立ちます。
Web層とネイティブ層のデバッグ
症状が発生している層をデバッグしてください。ネイティブのライフサイクルイベントには反応するのに画面がフリーズする場合、原因は通常WebView側にあります。プロセスの終了、プラグインの例外、起動失敗は、ネイティブツールまたはElectronのメインプロセスで扱います。この振り分けルールなしに層を行き来しても、原因の特定に近づかない作業が増えるだけです。
WebViewから始める
Androidでは、デバッグ可能な Capacitor build を Chrome に接続して開いてください。 chrome://inspectコンソール、ネットワークパネル、ストレージ、パフォーマンスタイムラインを確認してください。iOSでは、接続したデバイスまたはシミュレータでSafari Web Inspectorを使用します。Electronでは、DevToolsポート経由でレンダラーにアタッチするか、 BrowserWindow.webContents.openDevTools() 調査中に呼び出してください。
本番環境のスタックトレースは、ソースコードと紐付けられる場合にのみ有用です。各web bundleのsource mapをuploadして保持し、symbolicationアーティファクトが正確なbundleハッシュと一致することを確認してください。重要な操作には制御されたコンソールインターセプターを追加しますが、認証情報、token、個人情報のログ出力は避けてください。代わりに、操作名、request ID、レスポンスクラス、状態遷移をキャプチャします。
証拠がnative側を指す場合は、nativeツールに切り替えます。
Android StudioのLogcatをアプリケーションパッケージでフィルタリングし、最小限の操作手順で問題を再現します。 npx cap run android --livereload WebViewの変更に対するイテレーションループは短縮されますが、パッケージ化されたnativeアーティファクトの検証はできません。iOSではXcodeから実行し、Devicesウィンドウでデバイスログを確認します。InstrumentsのTime Profilerは継続的なCPU負荷の解析に、Allocationsはメモリ増加の特定に役立ちます。
Electronには2つのデバッグ対象があります。DOM、JavaScript、ネットワークの挙動にはレンダラーのDevToolsを使用します。メインプロセスには --inspect または --inspect-brk デバッガーを使用し、起動時やauto-updateのテスト中はそのstderr出力を保持してください。
症状に応じてルーティングします。UIの挙動はWebViewから、ネイティブの終了はAndroid StudioまたはXcodeから、Electronの起動失敗はメインプロセスから調査を開始します。
この分離がなぜ重要なのかを説明する有用な記事が CapacitorのWebViewとネイティブブリッジモデルにあります。ブリッジは単一のデバッグ面ではなく境界です。そう捉えることで、各ログ行が抱える質問に答える可能性が高まります。
ネットワーク、ストレージ、権限の初期チェック
チームはネットワークエラーが技術的で馴染みがあるため、まずAPIを確認しがちです。しかし、その習慣は、古い状態、権限宣言の変更、サンドボックスの挙動を変えたプラットフォームのアップグレードによる失敗を見逃します。最速の確認方法は、失敗のドメインによって異なります。
| 失敗ドメイン | 一般的な症状パターン | まず確認すべきこと |
|---|---|---|
| ネットワーク | データが空白、ログインループ、タイムアウト、アップロード失敗、特定のネットワークでのみ動作するリクエスト | 実行 curl 同じネットワークから、失敗したWebViewリクエストを調べ、CORSプリフライト、証明書ピンニング、キャプティブポータル、プロキシの挙動を確認します |
| ストレージ | 以前は動作していた機能が、アップデート、再起動、またはOSの変更後に動作しなくなるケース | ストレージ推定値を確認し、IndexedDBのクォータエラーをチェックし、暗号化キーを比較し、Electronの userData パスを確認して、クリーンなサンドボックスでテストします |
| 権限 | アプリ側で明確な例外が出ていないのに、カメラ、ファイル、通知、位置情報、バックグラウンド動作が失敗するケース | iOSの使用目的の説明、Androidの ACCESS_* 宣言、Electronのパーミッションハンドラー、およびコールドスタート時の権限タイミングを確認します |
ストレージの問題については、 storage.estimate() クォータの逼迫を明らかにできる場合がありますが、すべてのデータベース問題を診断できるわけではありません。手動でクリーンアップしたアプリのサンドボックスでテストし、既存のプロファイルと挙動を比較してください。Capacitor Preferencesの暗号化キーローテーションにより、以前は有効だった値が読めなくなることがあります。また、SQLiteのWrite-Ahead Logging（WAL）は、突然の終了後に破損した状態を残す可能性があります。さらに、Electronアプリでは、OSアップグレードによって解決される userData パス。
権限にも同じレベルの注意を払う必要があります。iOS の使用目的の説明は、要求されている機能と一致していなければなりません。Android の権限動作は SDK の変更後にずれることがあり、通知プロンプトがコールドスタート初期化と競合することもあります。Electron の権限ハンドラーは、レンダラーが有用な説明を受け取る前にリクエストを拒否する可能性があります。
ユーザーが「昨日は動いていた」と言う場合、ネットワークが変わったと決めつける前に、ストレージと権限を確認してください。
早期検知システムとしての自動テストとCI
CI は、ユーザーが実行する成果物をテストするときに最も低コストでリグレッションを検出できます。開発サーバーに対するテストスイートがグリーンであっても、署名済みの Android パッケージ、iOS アーカイブ、または Electron インストーラーが起動し、バンドルを読み込み、実際の認証済み操作を完了できることを証明するものではありません。
共有ロジックとシェルをテストする
使用する Vitest 共有 Web ロジック用、および Jest Electronのメインプロセス動作にはJestを使用します。Capacitorプラグインでは、JavaScriptの契約とネイティブ実装を別々にテストし、権限拒否、ハードウェア利用不可、不正な形式のレスポンス、ライフサイクル中断の統合カバレッジを追加します。
Playwrightはビルド済みのWebバンドルをテストできます。Electronでは、ローカル開発プロセスが配信するレンダラーだけでなく、パッケージ化されたバイナリに対してPlaywright Electronまたは同等のシェルテストを使用してください。パッケージ版のテストなら、ブラウザテストでは隠れてしまうアセットの欠落、パスの誤り、署名ミス、起動時の前提を検出できます。
デバイスカバレッジは、実際のインストールベースを反映させるべきです。BrowserStackやSauce Labsなら、意図的に選んだデバイスプロファイル、OS、権限状態、ネットワーク条件のセットでテストできます。目的はマトリックスの最大化ではなく、代表的な失敗をカバーすることです。
失敗をマージブロックにする
以下を明示的にチェックする:
- Bundleの変更: 予期しないbundleサイズの差分とsource mapの欠落を拒否する。
- Nativeとの整合性: プラグインのバージョン乖離や非互換を検知する
minSdkVersionの設定にスキームを追加します。 - アーティファクトの整合性: 署名、パッケージの識別情報、埋め込みアセット、リリース用マニフェストを検証する。
- 起動時の動作: パッケージ化されたアプリを起動し、認証が必要なエンドポイントへのリクエストを1回完了させる。
- アップデートの挙動: 古いbundleをインストールし、候補のアップデートを適用して再起動し、ロールバックの挙動を確認します。
すべての結果を一つの GitHub ステータスチェックで公開し、赤信号が出たらマージをブロックします。ユニットテストは通っても、署名済みアーティファクトの検証に失敗するビルドは「ほぼ成功」ではなく「失敗」として扱うべきです。
この Capacitor リリースのための継続的インテグレーション（CI）設定 これらのチェックを再現可能なパイプラインに組み込む際に役立ちます。CIは本番環境のテレメトリの代わりにはなりませんが、ステージングに到達する欠陥の数を減らし、インシデント発生時にオンコールエンジニアが直面する不明要素を減らせます。
緊急リカバリチャネルとしての Live Updates
本番環境でのデグレが必ずしも新しいネイティブビルドを必要とするわけではありません。欠陥が JavaScript、CSS、テキスト、設定、その他のWebアセットにあるなら、チームが正式なリリースを準備する間に live update でユーザー体験を復旧できます。これにより、Live Updateの配信は単なる 運用上のリカバリチャネルとなり、見た目だけの変更のための便利機能ではなくなります。
安全性に求められるのは「制御」です。Canary、Beta、Stableの各オーディエンス向けに、名前付きチャネルを分けてください。ネイティブアプリIDと互換性のあるランタイム制約を明示し、各オーディエンスが受け取るbundleを記録します。live update では、ネイティブ権限の追加、ネイティブプラグインの置換、Electronのメインプロセスの変更、アップデーターが初期化される前に発生する障害の修復はできません。そうしたケースでは、引き続きストアまたはインストーラー経由のリリースが必要です。
ガード付きロールアウトを実施する
緊急時のフローは次のようになります:
- 影響範囲を確認: 影響を受けたネイティブバージョン、チャネル、バンドルハッシュ、障害シグナルを特定します。
- 最小限のパッチを準備する: 失敗しているパスを復旧するために必要な Web 側の動作だけを変更します。
- カナリアオーディエンスを対象とする: すべてのインストール先ではなく、制御されたチャネルにバンドルを送信します。
- テレメトリを監視する: 影響を受けたコホートに対して、クラッシュ、ロード、リクエスト、および更新失敗のシグナルを確認します。
- プロモーションまたはロールバック: シグナルが正常な間だけ拡大してください。パッチで新たな障害が発生したら、直ちにロールバックしてください。
自動ロールバックには、チームが選んだ明確なクラッシュ率やロード失敗のしきい値を使用すべきです。ロールバックがユーザーを保護できるのは、アップデーターが失敗を検知でき、かつ以前のbundleが利用可能な場合に限られます。サポートが特定のデバイスで何が起きたかを説明できるよう、バージョン履歴とチャネルのガードレールを維持してください。
Capgo は、CapacitorJS および Electron アプリケーション向けに、署名付き web bundle の配信、ターゲットチャネル、デバイスごとのログ、採用率と失敗のメトリクス、バージョン履歴、自動ロールバック保護を提供します。実践的な判断ルールは明快です： 修正が web bundle 内に収まり、アップデーターが安全に起動できる場合は live update を使用してください。ランタイム、プラグイン、権限、パッケージ、メインプロセスが関与する場合は、ネイティブホットフィックスを計画してください。 Capacitor の Live Update フロー これら2つのパスの境界について説明します。
次のインシデントを防ぐ事後分析
振り返りは、システムを変えるときにこそ価値があります。ログ、デプロイの文脈、運用担当者の判断が残っているうちに記録してください。記録は事実に基づき、個人を責めず、他のエンジニアがインシデント全体を再現しなくても不足していたガードレールを特定できる程度に具体的にしてください。
5つの具体的なブロックを使う
テレメトリのタイムスタンプ付きタイムライン 最初の失敗リクエスト、影響を受けたリリース、アラート作成、調査手順、緩和措置、復旧を記録します。Android ダッシュボードのインシデントでは、タイムラインに設定ロールアウト後に空白ビューが表示され、iOS は引き続き有効なレスポンスを受信していたことが示される可能性があります。
ユーザーに見える障害モード。 顧客が体験したことを記述し、code が何をしたかを記述しないでください。「認証後に Android ユーザーが空のダッシュボードを確認した」は、「API キー不一致」よりも対応者に方向性を与えます。前者は壊れたジャーニーと、それを検出すべきシグナルを指し示します。
検知のギャップ。 チームが遅く知った理由を明記します。アプリが正常にレンダリングされたためクラッシュ監視はグリーンのままだったかもしれませんが、認証済みリクエストの失敗や空のダッシュボードペイロードを追跡するアラートは存在しませんでした。欠落したシグナルと、それが発火すべき場所を記録します。
code 以外の寄与要因。 設定のドリフト、キャッシュ動作、デプロイタイミング、サービス依存関係、権限変更、または Electron の自動更新レースを列挙します。アプリケーションの code に欠陥がなくても本番障害が発生し得るため、これらの領域は早期チェックに値します。
予防的ガードレール。 問題を検出できたはずのテストまたはコントロールを割り当ててください。例: デプロイ時に本番環境の認証情報を検証する、代表的なクライアントから配信された設定を確認する、パッケージ化された Electron の起動テストを追加する、などです。ガードレールには、単なる振り返り文だけでなく、オーナーと失敗条件が必要です。
通知経路の確認も同じレビューで行います。メール通知がチームに届かない場合は、 Gmailでメールが迷惑メールに振り分けられないようにする方法 といった実用的なリソースを通知チェックの際に参照し、アラート経路を検証してください。メッセージの作成に成功したことを、オペレーターがアラートを受信した証拠と見なさないでください。
インシデントをクローズする前に作業を割り当てる
各ブロックには、担当者を1人、期限を1つ、検証方法を1つ設定します。改めてインシデントを 24時間期限内に、エンジニアが調査の前提に異論を唱えられるうちにレビューしてください。新しいテスト、ダッシュボード、設定確認、ロールアウトルールが問題なく実行できてから、項目をクローズしてください。
最後に、このチェックリストを使ってください：
- 対象の Native Build と web bundle を正確に特定できましたか？
- 原因が code、設定、デプロイ、インフラ、依存関係のどれなのか区別できましたか？
- テレメトリで、クラッシュだけでなくユーザーに実際に影響した障害を確認できましたか？
- 影響を受けたチャネルと、正常動作が確認できているチャネルの両方をテストしましたか？
- 本番環境前に失敗するガードレールを追加しましたか？
- live update かネイティブリリースのいずれが適切かを文書化しましたか？
- 指名された責任者が修正を検証しましたか？
ユーザーからの苦情は、レビューがクラッシュだけでなく幅広い問題をカバーすべき理由を示しています。 6,634アプリの監査では、支払い失敗が 28.6% のアプリに影響し、デバイス互換性 28.4%、UI/UXの摩擦 25.4%、サブスクリプションの問題 21.8%、ログインエラー 17.2%が挙げられ、クラッシュは7位で 10.3%. (Bright App Dataによるモバイルアプリ苦情の監査) 「なぜアプリがクラッシュしたのか？」だけを問うトラブルシューティングでは、決済やサインイン、通常のプロダクト利用を妨げている障害を見逃す可能性があります。
安定性データも同じ運用モデルを裏付けています。ベンチマークでは、中央値のアプリは クラッシュフリーセッション率99.95%となっており、パフォーマンスの高いアプリは 99.99% 、パフォーマンスの低いアプリは 99.77%以下です。また、中央値として報告されているのは ANR率が10,000セッションあたり2.62件、つまり OOM率が10,000セッションあたり1.12件、アプリのハング率が 10,000セッションあたり64〜103件です 品質ティアによって異なります。(モバイル安定性ベンチマーク) 高い安定性でも、依然として意味のある失敗が発生します。チームは、失敗したリクエスト、空白状態、ハング、更新エラー、その他のユーザーに見える症状についてテレメトリが必要です。
2026年のレポートによると、ユーザーは 新機能のリクエストよりも、基本的な機能の破損に関する苦情を6倍多く提出しました、また、 1回のクラッシュで15.4%がアンインストールし、2〜3回のクラッシュで半数以上が離脱します. (アプリの基本的な機能の破損に関する2026年のレポート) 対応は実用的です：広く検出し、素早く回復し、すべてのインシデントをテスト可能な制御に変換します。
使用する Capgo 署名済みの CapacitorJS および Electron の Web バンドル更新を制御されたチャネル経由で配信し、デバイス単位のテレメトリを確認し、ストアのレビューを待たずに失敗した JavaScript 修正をロールバックできます。リリースパイプラインに接続し、安定版とカナリアのオーディエンスを定義して、次のダッシュボード障害の前に復旧パスをテストしてください。
