--- title: "クラウドの監視は何を見るのか。死活・リソース・アプリ｜アメリア・テクノロジー株式会社" url: https://www.ameliatechnology.co.jp/blog/cloud-monitoring-what-to-watch/ description: "クラウドの監視は、外から見て動いているか（死活）、資源に余裕があるか（リソース）、利用者から見て正しく動いているか（アプリ）の3つの層で見ます。各クラウドの仕組み、通知の決め方、24時間の監視を仕組みと人の対応に分ける考え方を説明します。" updated: 2026-11-14 publisher: "アメリア・テクノロジー株式会社" --- # クラウドの監視は何を見るのか。死活・リソース・アプリ クラウドの監視は、外から見て動いているか（死活）、資源に余裕があるか（リソース）、利用者から見て正しく動いているか（アプリ）の3つの層で見ます。各クラウドの仕組み、通知の決め方、24時間の監視を仕組みと人の対応に分ける考え方を説明します。 2026.11.14 [クラウドと運用](https://www.ameliatechnology.co.jp/blog/category/cloud/) 執筆 [石田誠](https://www.ameliatechnology.co.jp/blog/author/ishida/)（グループCTO） クラウドと運用（CLOUD & OPERATIONS）のコラム ## この記事の要点 - 監視は、死活・リソース・アプリケーションの3つの層で見ると、見落としと重複を減らせます。 - 通知は、人が動く必要のあるものだけに絞り、通知を受けた人がすることを手順書に書いておきます。 - 24時間見張るのは監視の仕組みに任せ、夜間・休日に通知を受けて切り分ける人と、原因を直す人の役割を分けて決めます。 クラウドの監視は、外から見てシステムが動いているか（死活）、サーバーやデータベースの資源に余裕があるか（リソース）、利用者から見て正しく動いているか（アプリケーション）の3つの層で見ます。3つの層に分けると、「サーバーは動いているのに、利用者は画面を開けない」といった見落としに気づきやすくなります。 [監視](https://www.ameliatechnology.co.jp/glossary/monitoring/)は、仕組みを入れること自体より、何を見て、異常のときに誰が何をするかを決めることのほうが大切です。この記事では、見るものの決め方と、24時間の監視を仕組みと人の対応に分ける考え方を説明します。 ## 3つの層で見る 監視で見るものを、3つの層に分けて整理します。 | 層 | 見ること | 例 | |---|---|---| | 死活 | 外から呼びかけて応答があるか | Webサイトの応答、APIの応答、サーバーの起動の状態 | | リソース | 資源に余裕があるか | CPU・メモリ・ディスクの使用率、データベースの接続数 | | アプリケーション | 利用者から見て正しく動いているか | 応答の時間、エラーの割合、ログイン・注文などの手続きが通るか | 死活の監視は、止まったことに気づくための最低限の監視です。リソースの監視は、止まる前の兆しに気づくために使います。アプリケーションの監視は、サーバーは動いていても、利用者から見ると使えない状態に気づくために使います。 3つのうち、死活とリソースは、クラウドの事業者の仕組みで比較的すぐに始められます。アプリケーションの層は、何を「正しく動いている」とするかを業務に合わせて決める必要があるため、後回しにされがちですが、利用者への影響を直接映す層です。応答の時間やエラーの割合の目標を決める考え方は、[SLO](https://www.ameliatechnology.co.jp/glossary/slo/) の用語の説明もあわせてご覧ください。 ## 各クラウドの監視の仕組み 3つのクラウドは、それぞれ監視の仕組みを用意しています。 ### 外からの死活の確認 Google Cloud の Cloud Monitoring の稼働時間チェック（uptime check）は、公開している URL などに、世界の複数の場所から定期的に HTTP・HTTPS・TCP の要求を送り、応答を確かめます。失敗したときに通知する設定もでき、既定では、少なくとも2つの地域から1分以上失敗が報告されたときに通知されます。1か所だけの失敗では、既定の設定では通知されません。 出典：[Manage public uptime checks（Google Cloud）](https://docs.cloud.google.com/monitoring/uptime-checks) 複数の場所からの失敗を条件にするのは、確かめる側の一時的な通信の不調で、不要な通知が出るのを防ぐためです。 AWS の CloudWatch Synthetics のカナリアは、決まった間隔で動くスクリプトで、利用者と同じ経路をたどり同じ操作をすることで、利用者がいない時間でも、利用者から見た動きを確かめ続けられます。応答の有無と時間を確かめ、画面の写しを残すこともでき、最短で1分ごとに動かせます。 出典：[Synthetic monitoring (canaries)（AWS）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) カナリアのように手続きの流れまで確かめる仕組みは、アプリケーションの層の監視にもなります。 ### リソースとアプリケーション AWS の CloudWatch のアラームは、指標（メトリクス）を見張り、しきい値を上回ったときなどに通知を送ったり、資源を自動で変えたりします。アラームは状態が変わったときに動作を起こし、通知の先として Amazon SNS（通知のサービス）などを指定できます。指標のデータが届かないときは「データ不足」の状態になり、資源が動いていないだけで、問題があるとは限らない、とされています。 出典：[Using Amazon CloudWatch alarms（AWS）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) Microsoft の Azure Monitor は、Azure のさまざまな資源から指標とログを集め、仮想マシンや Kubernetes のクラスターからは、指標に加えてイベントのログも集めます。Application Insights は、動いている Web アプリケーションの性能を監視する機能です。アラートは、集めたデータから問題を見つけて、利用者に影響が出る前に知らせるためのものと説明されています。 出典：[Azure Monitor overview（Microsoft Learn）](https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview) 監視の仕組みが集めた指標とログを、原因の調べやすさまで含めて使う考え方は、[オブザーバビリティとは。監視と何が違うのか](https://www.ameliatechnology.co.jp/blog/observability-vs-monitoring/)で説明しています。ログの残し方は、[ログの取り方と見方。何を、どのくらい残すか](https://www.ameliatechnology.co.jp/blog/log-management-basics/)をご覧ください。 ## 通知は、人が動くものだけに絞る 監視で見るものと、人に知らせるものは分けて考えます。見る指標をすべて通知にすると、通知が多すぎて、本当に対応が要る通知が埋もれます。 通知の設定を決めるときは、次の点を決めます。 1. **知らせる条件**：その状態が続くと、利用者に影響が出るか 2. **知らせる相手**：誰が受けるか（時間帯ごとに違う場合も含めて） 3. **受けた人がすること**：最初に確かめること、切り分けの手順、誰に連絡するか 4. **急ぎの度合い**：すぐに動くもの、翌営業日でよいもの、記録だけでよいもの 3つ目の「受けた人がすること」は、[手順書（ランブック）](https://www.ameliatechnology.co.jp/glossary/runbook/)として書いておきます。通知を受けた人が手順書を見て動ける状態にしておくと、担当者が替わっても、夜間でも、同じように対応できます。手順書の作り方と、障害のときの連絡の流れは、[障害が起きたときの一次対応。連絡の流れと手順書](https://www.ameliatechnology.co.jp/blog/cloud-incident-first-response/)で説明しています。 通知の条件は、一度決めて終わりではありません。不要な通知が多いもの、通知が出なかったのに障害が起きたものを、月に一度などの機会に見直します。 ## 24時間の監視は、仕組みと人の対応を分ける 「24時間監視」と聞くと、人が画面を見続ける姿を思い浮かべるかもしれませんが、見張ること自体は監視の仕組みが24時間自動で行えます。人の対応は、通知を受けて切り分ける役割と、原因を直して再発を防ぐ役割に分けて考えます。 1つ目の「見張る」は、監視の仕組みが24時間365日、自動で回します。人が決めるのは、何を見て、どの条件で知らせるかの設計と設定です。 2つ目の「受けて切り分ける」は、通知を受けて、影響の範囲を確かめ、手順書にある一次対応（再起動など）を行い、必要な人へ連絡する役割です。夜間・休日もこの役割を担う必要がある場合は、社内の当番か、手順書にもとづいて動く外部の専門の会社に任せる方法があります。 3つ目の「直して再発を防ぐ」は、原因を調べ、設定や構成を直し、同じ障害が起きないようにする役割です。急ぎの切り分けとは違い、落ち着いて調べる時間が要るため、営業時間内に行う形でも回せる場合があります。 24時間の監視を、仕組みと人の対応に分ける - **見張る**：監視の仕組みが**24時間365日、自動で回す**。人は、何を見て、どの条件で知らせるかを設計・設定する - **受けて切り分ける**：通知を受け、影響の範囲を確かめ、手順書にある一次対応を行い、必要な人へ連絡する。夜間・休日は社内の当番か、手順書にもとづいて動く外部の専門の会社 - **直して再発を防ぐ**：原因を調べ、設定や構成を直し、同じ障害が起きないようにする。営業時間内に行う形でも回せる場合がある 3つを分けると、「夜間に誰が起きているか」と「誰が原因を直すか」を別々に決められるため、少ない人数の会社でも無理のない体制を作りやすくなります。担当者が少ない会社の体制の考え方は、[インフラの担当が1人しかいない会社のクラウド運用](https://www.ameliatechnology.co.jp/blog/one-person-infra-team/)で説明しています。 ## 当社のご支援 当社は、死活・リソース・アプリケーションの3つの層での監視の設計と設定、通知の条件と手順書づくりを、[クラウドの構築と運用管理](https://www.ameliatechnology.co.jp/service/cloud/)でお手伝いしています。監視の仕組みは24時間自動で回し、夜間・休日の通知の受け付けと一次対応は、当社の手順書にもとづいて外部の専門の会社が担い、原因の調査と再発の防止、月次の報告は当社が営業時間内に行う形でお受けしています。料金の目安は[料金のページ](https://www.ameliatechnology.co.jp/pricing/#cloud)に載せています。 - 監視 - クラウド - 運用 - アラート ## この記事に出てくる用語 - [クラウド](https://www.ameliatechnology.co.jp/glossary/cloud/) - [監視](https://www.ameliatechnology.co.jp/glossary/monitoring/) - [サーバー](https://www.ameliatechnology.co.jp/glossary/server/) - [データベース](https://www.ameliatechnology.co.jp/glossary/database/) - [Webサイト](https://www.ameliatechnology.co.jp/glossary/website/) - [API](https://www.ameliatechnology.co.jp/glossary/api/) - [SLO（サービスレベル目標）](https://www.ameliatechnology.co.jp/glossary/slo/) - [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-monitoring-what-to-watch/