ノーコードアプリのインシデントランブック：検出、トリアージ、復旧

このランブックの目的と使うべき場面

インシデントとは、ユーザーがアプリを使えなくなる、極端に遅くなる、またはデータにリスクが生じる予期しない問題のことです。ノーコードアプリでは、急なログイン失敗、変更後に壊れた画面、バックグラウンドの自動化が止まる、API エラー、あるいは「成功」したワークフローが静かに誤った値をデータベースに書き込む、などが該当します。

書面化されたランブックは、ストレスの多い瞬間を小さく明確な行動のセットに変えます。推測を減らし、判断（いつロールバックするかなど）を早め、関係者全員が同じ事実を共有できるようにします。インシデント中の遅延の多くは技術的なものではなく、不確実性から来ます：本当に起きているのか？誰がリードしているのか？何が変わったのか？ユーザーに何を伝えるべきか？

このプレイブックは、問題が起きたときにアプリに関わる誰にでも使えるように作っています：変更を出すビルダー、デプロイやアクセスを管理するオプスやプラットフォーム担当、最初の報告を受けるサポートチーム、インパクトや優先度を判断するプロダクトやビジネスオーナーなどです。

AppMaster のように視覚的ロジック、生成されたサービス、複数のデプロイ方法があるプラットフォーム上で構築するチームにも配慮して、意図的に軽量にしています。

インシデントの全ループをカバーします：問題の検知と確認、迅速なトリアージ、安定化と復旧（ロールバック判断を含む）、停止中のコミュニケーション、そして同じ問題が再発しにくくするための短い事後レビューです。

長期的なアーキテクチャの再設計、深いセキュリティフォレンジクス、複雑なコンプライアンス手順は対象外です。規制データや重要インフラを扱う場合は、このランブックにより厳しい手順を追加してください。

事前準備：基準値と役割を決めておく

「通常」がどんな状態か分からないと、インシデントは混乱します。チームが実際の問題を素早く見分けられるように基準値を定義しましょう。ノーコードアプリでは、初期のシグナルはプラットフォームの健全性、ビジネスメトリクス、人の報告が混ざって出てきます。

毎日（障害時だけでなく）見るシグナルを書き出してください。一般的なものは稼働率、エラー率、画面の遅さ、ログイン失敗、決済失敗、サポートチケットやユーザーメッセージの急増などです。

誰でも使える平易な言葉で重大度を定義します：

• SEV1: 大多数のユーザーがアプリを使えない、または金銭・セキュリティにリスクがある。\n- SEV2: 主要機能に不具合があるが回避策がある。\n- SEV3: 軽微な問題、限定ユーザーのみ、見た目のバグなど。

対応の目標時間を定めて勢いをつけましょう。例：5分以内に認識（acknowledge）、15分以内に最初の更新を投稿、60分以内に安定化を目指す（完全な修正はもっと時間がかかってもよい）など。

事前に役割を決めておきます。誰がインシデントを宣言できるか、誰がリードするか、その人がオフラインのときのバックアップは誰か。AppMaster のチームでは、Business Process ロジックのオーナーと、デプロイやエクスポートを扱えるバックアップが典型的です。

最後に、インシデントの記録を一元化する場所を用意します。すべての行動にタイムスタンプ（何が、いつ、誰によって変更されたか）を付けて、後で推測せずに経緯を再構築できるようにします。

検知と確認：本物か、どれほど重大かを判断する

ダッシュボードを眺める前に影響を確認してください。明確な質問を一つ：今誰が何をできないのか？「サポートチームがチケットを開けない」は「アプリが遅い」より有用です。可能なら、影響を受けたユーザーと同じ役割・デバイスで問題を再現します。

次に、範囲を把握します。1つのアカウントか、ある顧客セグメントか、全員か？地域、アカウント種別、Web 対モバイル、単一機能かアプリ全体かなどで素早く切り分けます。ノーコードツールでは、グローバルに見える問題が実は権限ルールや特定画面の破損であることがあります。

次に何が変わったかを確認します。リリース、設定トグル、データベーススキーマ編集、データインポートなどを直近1〜2時間遡って探します。AppMaster のようなプラットフォームでは、ビジネスプロセス、データモデル、認証設定の変更が UI に目立たなくても多くのフローに影響を与えることがあります。

アプリを責める前に外部依存を除外してください。メール/SMS プロバイダ、決済（例：Stripe）、統合（Telegram、AWS サービス、AI API）などは失敗したりレート制限されることがあります。メッセージ送信時やカード決済時にだけ障害が出るなら、根本原因は上流にあるかもしれません。

シンプルな意思決定チェックリストを使います：

• 監視：影響が小さくエラーが増加していない場合。\n- 今すぐ軽減：ユーザーが主要タスクをブロックされている、またはデータが危険にさらされている場合。\n- インシデント宣言：問題が広範か、時間的に重要、あるいは不明瞭な場合。\n- エスカレーション：決済、認証、または本番データに関わる問題がある場合。\n- チェックイン時間を設定：例：15分ごと、チームが散漫にならないようにする。

重大度と範囲を分類したら、「本当に起きているか？」から「最初に何をするか？」へ推測せずに移れます。

トリアージ手順（最初の30分）

即座にインシデント記録を開きます。疑いのある原因ではなくユーザー影響を名前にした明確なタイトルを付けます（例：「EU 顧客のチェックアウトが失敗」）。開始時間（最初のアラートや最初の報告）を書き留めます。ここが決定、タイムスタンプ、変更点の単一の記録場所になります。

作業が重複しないよう役割を割り当てます。小さなチームでもオーナーを明確にするとストレス時のミスが減ります。最低限欲しい役割：

• インシデントリード： 焦点を保ち、優先度を決め、封じ込めかロールバックかを判断。\n- 修正担当（Fixer）： 調査と変更を実行。\n- コミュニケーション： ステークホルダーとサポートへの更新を投稿。\n- 記録係： 行動、時間、結果を記録。

書面で二つのことを明記します：確実に分かっていることと現在の仮説。確実に分かっていることは、エラー率が急増している、特定のエンドポイントが失敗している、モバイルのみ影響が出ている、などです。仮説は間違っていてもよいですが次のテストを導くべきです。学習に伴って両方を更新してください。

状況が不安定な間は 15 分ごとの更新を設定します。何も変わっていなければそれを伝えるだけでよいです。定期的な更新は横道の議論を止め、「何か進展は？」という重複した問い合わせを防ぎます。

最初の封じ込めアクションを選びます。目標は根本原因が不明でも害を素早く減らすことです。典型的な初動はバックグラウンドジョブを一時停止する、リスキーな機能フラグを無効にする、モジュールへのトラフィックを制限する、既知の安全設定に切り替える、などです。AppMaster では Business Process Editor で特定のフローをオフにするか、失敗を誘発する UI パスを一時的に非表示にすることがこれに当たります。

封じ込めで指標が一つの更新サイクル内に改善しない場合は、並行してロールバック計画を開始します。

まず安定化：影響を抑える

インシデントが確認できたら、「バグを見つける」から「出血を止める」に切り替えます。安定化は時間を稼ぎ、調査中にユーザー、収益、データを保護します。

害を減らす最小の変更から始めます。封じ込めは完全な修正より速いことが多く、フィーチャーを無効にする、ワークフローを一時停止する、危険な入力パスをブロックするなど、再ビルドを伴わない方法で対処できます。

データが破損している疑いがある場合は、まず書き込みを止めてください。フォームの無効化、レコードを更新するオートメーションの一時停止、更新を受け付ける API エンドポイントのブロックなどが含まれます。壊れたデータを読むのは手間ですが、誤ったデータを書き続けると後処理が増えます。

ユーザーがロックアウトされているなら、ログインを最優先で扱います。認証設定やログインフローを他のことより先に確認してください。チームやサポートがアプリにアクセスできないと他の修正は遅れます。

アプリが遅い・タイムアウトしている場合は負荷を減らし、負荷の高い経路を切ります。重い画面をオフにする、バッチジョブを一時停止する、急増を引き起こす新しい統合を無効にするといった対応です。AppMaster では問題のあるビジネスプロセスを無効化したり、コストの高いチェーンを引き起こす UI アクションを一時削除するだけで封じ込めになることがあります。

行動は意図的に、かつ文書化して行ってください。プレッシャー下ではチームが同じ変更を重ねたり、修正を誤って元に戻したりします。各変更と結果を必ず書き留めてください。

簡単な安定化手順例：

• データ破損の可能性がある場合は書き込みを止め、新しいレコードが変更されていないことを確認する。\n- タイムラインに関係する最新の機能フラグ、オートメーション、統合を無効にする。\n- 管理者向けのログインとセッションフローをまず復旧し、その後全ユーザーの復旧を目指す。\n- バックグラウンドのバッチや最も遅いユーザー経路を一時停止して負荷を減らす。\n- 各行動にタイムスタンプ、担当者、観察された効果を記録する。

目標は「安全で使える」状態であって「完全に解決」ではありません。影響が封じ込められたら、冷静に診断して適切なロールバックや修正を選べます。

ロールバックの選択とリスクチェック

障害時は速度が重要ですが、安全な手が最優先です。一般的にはロールバック、前進して修正、部分的な巻き戻し（ある機能だけオフにする）という三択が現実的です。

まず、自分たちの環境で「ロールバック」が具体的に何を意味するかを明確にします。前のバージョンをデプロイすること、設定変更を元に戻すこと、データベース状態を復元すること、などです。AppMaster のようなプラットフォームでは「バージョン」にバックエンドロジック、Web UI、モバイルビルド、環境設定などが含まれることがあります。

ロールバックが安全かどうか決めるために次のリスクチェックを使います：

• データベーススキーマの変更： 古いバージョンが異なるテーブルやフィールドを期待する場合、ロールバックは失敗する可能性があります。\n- 取り消せない書き込み： 返金やステータス変更、送信済みメッセージは元に戻せないことがある。\n- キューやウェブフック： 古いロジックがアイテムを再処理したり、新しいペイロードで失敗する可能性。\n- 外部依存： 決済、メール/SMS、Telegram 等の統合の挙動が変わっている場合。

何か触る前にシンプルなゴー／ノーゴールールを決めます。アクション後 10〜15 分以内に改善すべき 2〜3 の指標を選んでください（例：エラー率、ログイン成功率、チェックアウト成功率、API レイテンシ）。期待した方向に指標が動かなければ中止して戦略を切り替えます。

ロールバックのバックアウト（やり直し）計画も用意します。古いバージョンが新たな問題を引き起こした場合にどう元に戻すか：どのビルドを再デプロイするか、どの設定を再適用するか、誰が承認するかを明確にします。最終的な「出荷」判断は一人の責任者に任せ、途中で方針が揺らがないようにしてください。

インシデント中のコミュニケーション

沈黙は事態を悪化させます。調査中でも関係者に情報を短く定期的に伝える簡潔で再現可能な方法を用意してください。

まず内部の更新を行います。問い合わせを受ける可能性がある人とブロッカーを取り除ける人に伝え、短く事実だけを伝えます。通常必要なのは：

• サポートやカスタマーサクセス：ユーザーが何を見ているか、今言うべきこと\n- セールスやアカウントチーム：どのアカウントが影響を受けているか、何を約束しないか\n- ビルダー/エンジニアリング：何が変わったか、何をロールバックするか、誰が対応中か\n- 経営層の連絡窓口：インパクト、リスク、次回更新時間\n- 外部文言を承認する一人のオーナー

外部向けの更新では、分かっていることだけを伝えてください。原因を推測したりベンダーを非難するのは避けます。ユーザーが最も欲しいのは確認、影響、次回更新のタイミングの三点です。

シンプルなメッセージテンプレート

チャネル全体で一貫したステータス行を保ちます：

• Status: Investigating | Identified | Mitigating | Monitoring | Resolved
• Impact: 「一部のユーザーがログインできない」または「新規注文の決済が失敗する」等
• Workaround: 「10分後に再試行してください」または「Web がダウンしている間はモバイルアプリを使ってください」（実際に真なら記載）\n- Next update: 「次回更新は 14:30 UTC」

ユーザーが怒っている場合はまず認め、その後に具体的に伝えます：「チェックアウトが一部顧客で失敗していることを把握しています。現在最後の変更をロールバックしています。次回更新は30分後です。」インシデント中に期限、クレジット、恒久的な解決を約束しないでください。

解決済み vs 監視中

主要な症状が消え、主要チェック（ログイン、コアフロー、エラー率）がクリーンになった時点でのみ Resolved を宣言します。ロールバックや設定復元などの修正を適用した後、繰り返しの有無を確認する時間が必要な場合は Monitoring として、何をどのくらい監視するかと最終更新を必ず明記してください。

原因診断：絞り込むための速いチェック

状況が安定したら、消火活動から「事象を説明する最小限の事実を集める」フェーズに移ります。目標は完璧な根本原因ではなく、症状を説明するもっともらしい原因で、インシデントを悪化させずに行動できるものです。

症状ごとに疑うべき箇所が変わります。ページの遅さはしばしば遅いデータベースクエリ、トラフィックスパイク、外部サービスの遅延が原因です。タイムアウトは停止したプロセス、過負荷のバックエンド、応答を待つ統合が原因のことがあります。エラーやリトライの急増は最近の変更、不正入力、上流の障害に戻ることが多いです。

速いチェック（15分）

通常のテストアカウントで実際のユーザージャーニーを1回通してみます。UI、ロジック、DB、統合を通るため最速のシグナルになります。

注目するチェックは数点に絞ります：

• 1つのジャーニーを再現：サインイン、主要アクション実行、結果の確認。\n- 遅い・失敗するステップを特定：ページロード、API コール、DB 保存、ウェブフック。\n- 最近のデータを確認：最後の20〜50件のレコードを点検して重複、欠損フィールド、不整合な合計がないか見る。\n- 統合を検証：直近の決済試行（例：Stripe）、ウェブフック配信、メール/SMS や Telegram などを確認。\n- 変更の文脈を確認：スパイク直前に何がリリースされたか、設定されたか、マイグレーションされたか。

AppMaster を使っている場合、これは Business Process のステップ、Data Designer の変更、あるいはデプロイ設定の変更に対応していることが多いです。

維持するか前進修正かを決める

速いチェックで明確な犯人が示唆されれば、安全な手を取ります：現在の緩和策を維持するか、小さな恒久的修正を当てるか。レート制限や機能トグル、手動ワークアラウンドを外すのは、該当ジャーニーが2回成功し、エラー率が数分安定してからにしてください。

例：営業時間中のリリース失敗

火曜日の午前10時15分。チームが AppMaster 上のカスタマーポータルに小さな変更をデプロイしました。数分でユーザーがログイン後に白紙のページを見て、新規注文が止まります。

サポートに同じ内容のチケットが3件上がり、「ログインはできるが、その後ポータルが読み込まれない」と報告されます。同時にモニタリングで Web アプリの 500 エラーが急増し、API 呼び出しの成功が減少します。これは実際のインシデントとして扱います。

インシデントリードは素早く確認します：テストユーザーでデスクトップとモバイルでログインを試し、最後のデプロイ時刻を確認。タイミングがリリースと一致するため、当面は最新の変更が関与していると仮定します。

最初の30分の流れは次のようになります：

• 封じ込め： ポータルをメンテナンスモードにする（または影響する機能フラグを一時無効化）して、壊れたフローへのアクセスを止める。\n- ロールバック判断： 障害がリリース直後に始まり多くのユーザーに影響するならロールバック優先。\n- 連絡： 内部に短い更新（何が壊れているか、影響、現在の対応、次回更新時刻）を出し、顧客には認識して対応中である旨を短く伝える。\n- 復旧： 最後に正常だったバージョンを再デプロイ（または該当モジュールを元に戻す）。ログイン、ダッシュボード読み込み、例えば「チケット作成」や「注文確定」などの主要操作を再テスト。\n- 監視： エラー率、ログイン成功率、サポートチケット数を10〜15分観察して安定宣言。

10:40 にはエラーが通常に戻りました。指標を監視しつつ、サポートが新規チケットの減少を確認します。

その後、チームは短いレビューを行います：最初に何が気づいたか（アラート対サポート）、何が足を引っ張ったか（オーナー不明、ロールバック手順が不明瞭）、次に何を変えるか。一般的な改善は、ポータルのトップ3フローのリリーススモークテストを追加し、ロールバックを単一アクションでできるよう文書化することです。

インシデントを悪化させる一般的なミス

多くのインシデントが悪化する理由は二つのどちらかです：調査しながらシステムに害を与え続けるケース、あるいはあまりに多くの変更を短時間に行うケース。このランブックは両方からチームを守ることを目的としています。

よくある罠は、アプリがまだ誤ったデータを書き続けている最中に調査を続けることです。ワークフローがループしている、統合が重複投稿している、権限バグで間違ったユーザーが編集している、などがあれば、まずその処理を止めます。AppMaster では Business Process を無効化する、モジュール統合を切る、アクセスを一時制限して問題の拡散を止める、などが含まれます。

別の罠は「当てずっぽうで修正すること」です。複数の人が同時に設定をいじるとタイムラインが分からなくなります。インシデント中は一人が操作のドライバーとなり、簡潔な変更ログを保ち、未知の状態に複数変更を重ねないでください。

長時間の停止を繰り返す原因となる典型的ミス：

• まず調査してから封じ込めを行い、悪い書き込みや重複アクションが続く\n- 記録なしに複数の変更を同時に行い、何が効いたか分からなくなる\n- 連絡を遅らせる、あるいは不明瞭な更新で信頼を損なう\n- データベース状態やキュー、メール、ウェブフックの確認なしに無暗にロールバックする\n- 検証手順なしにインシデントを終了する

コミュニケーションは回復の一部です。分かっていること、分からないこと、次回の更新時間を伝えてください。「ロールバック中で、請求イベントが正しいか15分で確認します」は「調査中です」よりも良いです。

エラーが止まったからといってインシデントを閉じないでください。短い検証チェックリストで確認します：主要画面が開く、新規レコードが正しく保存される、重要なオートメーションが一度実行される、バックログ（キュー、リトライ、スケジュールジョブ）が排出されているか、安全に一時停止されているか。

圧力下で実行できるクイックチェックリスト

障害が起きると脳は同時に十個のことをやろうとします。これを使って冷静に、安全に、サービスを戻してください。

このセクションをチームが実際に見る場所にピンしておいてください。

• 実態確認と影響範囲把握（5分）： アラートがユーザー報告と一致するか確認。何が失敗しているか（ログイン、チェックアウト、管理パネル）、誰が影響を受けているか、いつからかを書き留める。可能ならクリーンセッション（シークレットウィンドウやテストアカウント）で再現。

1分だけかけてインシデントオーナーを指名してください。一人が決め、他はサポートします。

• 安定化と封じ込め（10分）： 根本原因を追う前に出血を止める。リスキーな経路（機能トグル、一時バナー、キューの一時停止）を無効化し、重要なジャーニーを1つエンドツーエンドでテスト。ビジネスにとって最も重要なジャーニーを選んでください（テストのしやすさで選ばない）。

• サービス復旧（10〜20分）： 最も安全な手を選ぶ：最後に正常だったバージョンへロールバックするか、最小限の修正を適用する。AppMaster のようなプラットフォームでは前のビルドを再デプロイするか、最後の変更を元に戻してエラー率と応答時間が正常に戻ることを確認します。

• コミュニケーション（随時）： 影響内容、ユーザーがすべきこと、次回更新時刻を短く投稿。サポートには2文スクリプトを配って全員が同じ説明をするようにします。

• きれいに終わらせる（忘れる前に）： 何が起きたか、何を変更したか、サービスがいつ回復したかを記録。対応の次工程にオーナーと期限を付ける（モニタリング改善、テスト強化、データクリーンアップ、追加入力）。

インシデント後：学習し、修正し、再発を防ぐ

アプリが復旧しただけではインシデントは完了しません。最も早くダウンタイムを減らす方法は、出来事を新鮮なうちに記録し、その学びを小さな現実的な変更に落とし込むことです。

2〜5日以内に短い事後レビューをスケジュールしてください。非難しない雰囲気で実務的に進めます。目的は誰かを責めることではなく、次のインシデントを扱いやすくすることです。

後で誰かが読んでも分かる記録を書きます：ユーザーが何を見たか、いつ検出したか、試したこと、何が効いたか、サービスがいつ戻ったか。根本原因が分かっていれば含め、見逃したアラート、オーナー不明、混乱するリリース手順などの要因を書き留めます。

学びをタスクに落とし、オーナーと期日を割り当てます。再発を防ぐ最小の変更に集中します：

• 監視の穴を埋める（より早く検出できるアラートやダッシュボードを1つ追加）\n- ガードレールを追加する（検証ルール、レートリミット、機能フラグのデフォルト、承認ステップ）\n- リスクの高い領域のテストを改善（ログイン、決済、データインポート、権限）\n- ランブックを実際に役立つ手順で更新\n- オンコールやアプリオーナー向けに短いトレーニングを実施

インシデントごとに少なくとも一つの予防措置を選んでください。小さくても効果的です：「役割変更は必ず第2レビュワーが必要」や「データ移行はまずステージングコピーで実行」といったルールが再発を防ぎます。

このランブックをビルドとリリースプロセスの隣に置いてください。AppMaster で構築している場合は、各アプリがどこにデプロイされているか（AppMaster Cloud、AWS、Azure、Google Cloud、セルフホスト）、誰が素早く再デプロイできるか、誰がロールバックできるかを書き残しておきます。単一のドキュメント置き場が欲しければ、AppMaster プロジェクトノート（appmaster.io）に一緒に保管しておくと、分刻みで動くときに見つけやすくなります。