--- title: "障害が起きたときの一次対応。連絡の流れと手順書｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/cloud-incident-first-response/ description: "クラウドの障害の一次対応は、影響を確かめ、事業者の障害か自社の問題かを切り分け、手順書の初動を行い、決めた相手へ連絡することです。障害情報の確かめ方、連絡の流れ、夜間・休日の体制を説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # 障害が起きたときの一次対応。連絡の流れと手順書 クラウドの障害の一次対応は、影響を確かめ、事業者の障害か自社の問題かを切り分け、手順書の初動を行い、決めた相手へ連絡することです。障害情報の確かめ方、連絡の流れ、夜間・休日の体制を説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - 一次対応の目的は原因を突き止めることではなく、影響を確かめ、広がりを抑え、決めた相手へ早く知らせることです。 - クラウドの事業者の障害かどうかは、各社が用意する自分の環境向けの障害情報（AWS Health・Azure Service Health・Personalized Service Health）で確かめます。 - 夜間・休日は、手順書にもとづいて通知を受けて切り分ける役割と、営業時間内に原因を直す役割を分けると、少ない人数でも体制を組めます。 クラウドで障害が起きたときの一次対応は、影響の範囲を確かめ、クラウドの事業者の障害か自社の側の問題かを切り分け、手順書にある初動を行い、決めた相手へ連絡することです。一次対応の目的は、原因をその場で突き止めることではなく、被害の広がりを抑え、判断する人に早く正しい情報を届けることにあります。 障害のときに慌てないためには、何が起きたら誰が何をするかを、平常時に決めて書いておくことが欠かせません。この記事では、一次対応の流れ、クラウドの事業者の障害情報の確かめ方、連絡の流れ、手順書の書き方を説明します。セキュリティの事故を含めた対応の計画の全体は、[セキュリティ事故に備える、初動の手順書のつくり方](https://www.ameliatechnology.co.jp/blog/incident-response-plan/)にまとめています。 ## 一次対応の流れ 一次対応は、次の順番で進めます。 1. **気づく**：監視の通知や、利用者・社員からの連絡で、異常に気づきます 2. **影響を確かめる**：どのシステムの、どの機能が、どの利用者に使えないのかを確かめます 3. **切り分ける**：クラウドの事業者の障害か、自社の設定・アプリケーション・最近の変更が原因かを見分けます 4. **初動を行う**：手順書にある範囲の対応（再起動、切り戻し、利用者への案内の表示など）を行います 5. **連絡する**：決めた相手へ、分かっていることと分かっていないことを分けて知らせます 6. **記録する**：気づいた時刻、行ったこと、その結果を、時刻つきで残します 2つ目と3つ目は、同時に進めることもあります。大事なのは、手順書にない対応をその場の判断で次々に試さないことです。原因が分からないまま設定を変えると、障害が広がったり、後で原因を調べる手がかりが消えたりします。手順書の範囲で収まらないときは、判断できる人へ引き継ぎます。 6つ目の記録は、後で原因を調べ、再発を防ぐための材料になります。対応しながら記録するのは負担ですが、チャットの専用の部屋に時刻つきで書き込むなど、手軽に残せる形を決めておきます。 ## クラウドの事業者の障害かどうかを確かめる 切り分けで最初に確かめたいのは、クラウドの事業者の側で障害が起きていないかです。3つのクラウドは、それぞれ自分の環境に関わる障害の情報を見る仕組みを用意しています。 ### AWS：AWS Health AWS Health は、自社の資源の状態と、AWS のサービスとアカウントの可用性を知らせる仕組みです。AWS Health Dashboard は、設定なしで、すべての利用者が追加の料金なしで使えます。障害の情報（イベント）は、Amazon EventBridge を通して、追加の料金なしで受け取ることもできます。 出典：[What is AWS Health?（AWS）](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) ### Microsoft Azure：Azure Service Health Azure Service Health は、3つの仕組みの組み合わせです。Azure の状態のページは、すべての Azure のサービスと地域の全体の様子を示します。Service Health は、自社が使っているサービスと地域に絞って、障害・計画された保守・注意の情報を知らせます。Resource Health は、特定の仮想マシンなど、個別の資源の状態を示します。Microsoft は、全体の状態のページは広い範囲の障害の参考になるとしたうえで、利用者には Service Health で障害と保守の情報を受け取るよう勧めています。 出典：[What is Azure Service Health?（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/service-health/overview) ### Google Cloud：Personalized Service Health Google Cloud の Personalized Service Health は、自社のプロジェクトに関わる障害の情報を示す仕組みで、Google は障害の情報の主な経路と位置づけています。障害の情報は Cloud Logging に記録され、新しい障害が報告されたときや、障害の情報が更新されたときに通知を受ける設定ができます。 出典：[Personalized Service Health overview（Google Cloud）](https://docs.cloud.google.com/service-health/docs/overview) どのクラウドでも、全体向けの状態のページだけを見るより、自分の環境向けの情報を見るほうが、自社に関わる障害かどうかを早く判断できます。障害の通知を、監視の通知と同じ受け先に届くように設定しておくと、切り分けの時間を短くできます。 クラウドの事業者の障害だと分かった場合、自社でできることは限られます。影響を受けている機能を確かめ、利用者への案内を出し、事業者の情報の更新を見守ります。別の地域に切り替える仕組みを用意している場合は、手順書に従って切り替えるかを判断します。過去の大規模な障害から学べる備えは、[クラウドの大規模障害から学ぶ、備えておくこと](https://www.ameliatechnology.co.jp/blog/lessons-from-cloud-outages/)で説明しています。 ## 連絡の流れを決めておく 障害のときは、誰に、どの順番で、何を伝えるかを、平常時に決めておきます。 | 決めること | 中身 | |---|---| | 連絡の相手 | システムの責任者、業務の責任者、経営者、委託先、必要に応じて利用者や取引先 | | 連絡の基準 | どの程度の影響なら、誰まで知らせるか | | 連絡の手段 | 電話・チャット・メールのどれを使うか、つながらないときの次の相手 | | 伝える中身 | 起きていること、影響、行っている対応、次に知らせる時刻 | 伝える中身では、分かっていることと分かっていないことを分けて書きます。「原因は調査中です。次は30分後にお知らせします」のように、次に知らせる時刻を添えると、受け取った人が何度も問い合わせずに済みます。 利用者や取引先への案内を出すかどうかは、業務の責任者が判断できるよう、基準を決めておきます。個人の情報の漏えいが疑われる場合など、法令にもとづく報告が関わる場面は、一次対応の担当だけで判断せず、計画に沿って責任者へ引き継ぎます。個別の判断は弁護士などの専門家にご確認ください。 ## 手順書（ランブック）の書き方 [手順書（ランブック）](https://www.ameliatechnology.co.jp/glossary/runbook/)は、通知を受けた人が、その場で読んで動けるように書きます。 - **きっかけ**：どの通知、どの症状のときに使う手順か - **最初に確かめること**：見る画面、確かめる指標、事業者の障害情報 - **行ってよい対応**：再起動・切り戻しなど、一次対応の担当が判断なしで行ってよい範囲 - **行ってはいけない対応**：データの削除や大きな設定の変更など、判断できる人に引き継ぐもの - **連絡先**：引き継ぐ相手と、つながらないときの次の相手 - **記録の残し方**：どこに、何を書くか 手順書は、実際に使ってみると足りないところが見つかります。障害が起きた後や、訓練のたびに見直し、使えない手順書のまま置いておかないようにします。訓練の進め方は、[復旧の目標（RTO・RPO）の決め方と、復旧の訓練](https://www.ameliatechnology.co.jp/blog/rto-rpo-and-recovery-drills/)をご覧ください。 ## 夜間・休日の一次対応 夜間・休日も一次対応が要るシステムでは、通知を受けて切り分ける役割を、誰が担うかを決めます。社内に当番を置く方法のほかに、手順書にもとづいて一次対応を行う外部の専門の会社に任せる方法があります。 外部の会社に任せる場合は、手順書が一次対応の範囲を決める契約の中身になります。行ってよい対応と、引き継ぐ相手を手順書にはっきり書いておかないと、夜間に判断が止まったり、反対に、任せていない対応まで行われたりするおそれがあります。夜間・休日に受けて切り分ける役割と、営業時間内に原因を調べて直す役割を分けると、社内の担当者が毎晩起きている必要はなくなります。24時間の監視を仕組みと人の対応に分ける考え方は、[クラウドの監視は何を見るのか。死活・リソース・アプリ](https://www.ameliatechnology.co.jp/blog/cloud-monitoring-what-to-watch/)で説明しています。 ## 当社のご支援 当社は、クラウドの障害のときの連絡の流れと手順書づくり、監視の通知の設計を、[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)でお手伝いしています。運用管理をお任せいただく場合、夜間・休日の通知の受け付けと一次対応は、当社が作った手順書にもとづいて外部の専門の会社が担い、原因の調査と再発の防止、月次の報告は当社が営業時間内に行います。夜間・休日の監視と初動は、内容に応じてお見積りします。 - 障害対応 - クラウド - 運用 - 手順書 ## この記事に出てくる用語 - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [監視](https://www.ameliatechnology.co.jp/glossary/monitoring/) - [ロールバック](https://www.ameliatechnology.co.jp/glossary/rollback/) - [AWS（Amazon Web Services）](https://www.ameliatechnology.co.jp/glossary/aws/) - [可用性・SLA](https://www.ameliatechnology.co.jp/glossary/availability-sla/) - [Microsoft Azure](https://www.ameliatechnology.co.jp/glossary/azure/) - [仮想化](https://www.ameliatechnology.co.jp/glossary/virtualization/) - [Google Cloud](https://www.ameliatechnology.co.jp/glossary/google-cloud/) この記事を書いた人 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/) グループCTO インターネットの黎明期から、ホスティング事業の立ち上げや、インフラ・セキュリティのプロジェクトに携わってきました。現在は、AWS・Azure へのクラウド移行の支援と、業務アプリケーションの要件定義から実装までを担っています。 このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。 ## あわせて読みたい - [Windowsサーバーと Active Directory を Azure へ移すときの考え方](https://www.ameliatechnology.co.jp/blog/windows-ad-to-azure/) - [Google Cloud を選ぶ場面。データ分析と Google Workspace とのつながり](https://www.ameliatechnology.co.jp/blog/when-to-choose-google-cloud/) - [Well-Architected の柱で、いまの構成を確かめる](https://www.ameliatechnology.co.jp/blog/well-architected-review/) [クラウドと運用のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/cloud/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/) ## 次の一歩 ### クラウドの構築と運用を任せる AWS・Microsoft Azure・Google Cloud の設計・構築・移行から、監視・運用・セキュリティまでを一つのチームで受け持ちます。監視は仕組みで24時間365日自動に回し、原因の調査と再発の防止は当社が担います。 [クラウドの構築と運用管理を見る](https://www.ameliatechnology.co.jp/service/cloud/) ### クラウドの状態を、無料で確かめる 15の設問に答えると、構成と管理・権限・守り・障害への備え・費用と体制の5つの分野の点数と、最初に取り組むことをまとめたレポートをその場でお届けします。 [クラウドの自己診断（無料）を受ける](https://www.ameliatechnology.co.jp/diagnosis/cloud/) ## ご関心に合わせて、お選びください。 [情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis) --- 出典：アメリア・テクノロジー株式会社「障害が起きたときの一次対応。連絡の流れと手順書｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/cloud-incident-first-response/