Claude Code活用 #7 何を監視すべき？──AIに相談しながら本番AWSの監視を設計・構築する

2026年6月23日 2026年6月23日

blueleaf

Claude Code活用 #7 何を監視すべき？──AIに相談しながら本番AWSの監視を設計・構築する

稼働中のあるWebサイト（AWS上の EC2 + ALB 構成）で、監視もバックアップも入っていない状態を整える機会がありました。公開はしたものの、「落ちても誰も気づけない」「壊れても戻せない」状態だったのです。

このとき、監視をどう設計するかから実際の構築、そして本番に影響を出さない範囲でのテストまで、すべて Claude Code に相談しながら一貫して進めました。今回はその進め方を、サーバー運用に関わる方・インフラを触るエンジニア向けに書きます。少し技術寄りの内容です。

ポイントは、Claude Code を「設定を打ち込むだけのツール」ではなく、監視設計の相談相手であり、かつ実際に手を動かす実行役として使ったところです。

出発点：監視ゼロの本番サイト

対象は、サーバー（EC2）の前段にロードバランサー（ALB）を置き、HTTPS で公開しているという、よくある構成のサイトです。すでに本番稼働しているのに、

監視が何も入っておらず、サーバーが落ちても異常に気づけない
バックアップが無く、ディスク障害が起きたら復旧できない

という状態でした。「とりあえず動いている」けれど、運用としては怖い状態です。何から手を付けるべきか、まずは現状把握から Claude Code に相談しました。

ステップ0：今どうなっているかを棚卸ししてもらう

最初にやったのは、AWS の構成そのものを Claude Code に調べてもらうことです。AWS CLI の読み取り系コマンド（一覧取得・詳細取得だけ）を使って、

どんな EC2 / ALB / 証明書 / ネットワークが存在するか
それぞれがどう繋がっているか

を洗い出してもらい、構成図と一覧表をまとめたドキュメントを作ってもらいました。人間が AWS コンソールを画面ごとに見て回るより圧倒的に速く、しかも「どこに何があるか」が一枚の資料になります。

現状が見えると、「ここに監視が無い」「ここがバックアップ対象から漏れている」という穴も同時に見えてきます。設計の前に、まず地図を作ってもらった形です。

ステップ1：「このサーバー、何を監視すべき？」と相談する

地図ができたら、本題の監視設計です。まず EC2 について、こう尋ねました。

このEC2で、本番運用として最低限みておくべき監視項目を、理由つきで教えてほしい。

返ってきたのは、項目だけでなくなぜ必要かまで添えた提案でした。たとえば：

インスタンス/システムのステータスチェック — そもそもサーバーが応答しているか。ハード障害やOSハングを検知する基本
CPU使用率 — 高止まりは過負荷や暴走プロセスのサイン
メモリ使用率 — 標準のメトリクスには含まれないので、別途エージェントが必要
ディスクの空き容量（使用率） — ログやデータで溢れるとサービスが止まる。地味だが事故が多い。なお、ディスクの読み書き量（I/O）は標準でも取れるが、「あと何%で満杯か」という空き容量はエージェントを入れないと取れない

「メモリ使用率と、ディスクの空き容量は標準のメトリクスでは取れないので、エージェントを入れる必要がある」といった前提条件まで説明してくれるので、設計の抜け漏れに気づけます。自分一人だと「CPUだけ見ておけばいいか」で済ませてしまいがちな部分です。

ステップ2：使っているAWSサービスごとに、できる監視を聞く

次に、構成に含まれる他のサービスについても順番に相談しました。「このサービスでは、どんな監視ができる？」という聞き方です。

ロードバランサー（ALB）については、こんな項目を提案されました。

異常なバックエンド数 — 後ろのサーバーがヘルスチェックに失敗していないか
5xxエラーの数 — サーバー側 / ロードバランサー側それぞれのエラー
応答時間 — 遅延の悪化を閾値で検知

さらに、「サイトが外から本当に見えているか」を確かめる外形監視も提案されました。これは AWS の外側から定期的に実際のURLへアクセスし、HTTPSで正しく応答が返るかをチェックする仕組みです。サーバー内部のメトリクスが正常でも、DNSや証明書の問題で「外から見えない」ことはあり得るので、内部監視とは別に効きます。

このように、「使っているサービスを一つずつ棚卸しして、それぞれで取れる監視を相談する」と、設計の網羅性が一気に上がります。

ステップ3：通知をどうするか相談する

監視は「異常を検知したら誰かに伝わる」ところまで作って初めて意味があります。通知の作り方も相談しました。

提案されたのは、各アラーム → 通知トピック（SNS） → メールという素直な流れです。閾値を超えたらアラームが SNS の通知トピックに飛び、そこからメールが届く。受け取り先のメールアドレスを購読登録しておけば、異常時に手元へ通知が来ます。この通知トピックの作成や購読設定も、そのまま Claude Code に対応してもらいました。

ステップ4：エラーログ監視のプランを立ててもらう

メトリクス監視に加えて、アプリやWebサーバーのエラーログも監視したいと伝えました。「エラーが急に増えたら気づきたい」という要望です。

これに対して立ててもらったプランは、おおむね次の構成でした。

サーバー上のエージェントで、アプリのログ・Webサーバーのアクセス/エラーログをログ管理サービスへ転送する
転送したログに対して、ERROR や Exception といったパターンにマッチした件数を数える仕掛けを置く
その件数が一定数を超えたらアラームを鳴らし、通知に繋ぐ

「ログを集める」「エラーを数える」「閾値で通知する」という3段構えです。やりたいこと（エラーが増えたら気づく）を伝えるだけで、必要なコンポーネントとつなぎ方まで設計してもらえました。

実際にこの仕組みは効いていて、運用が始まってから週に1〜2回、エラーログの通知が届きます。いまのところ大きな問題につながるエラーは出ていませんが、お客様から連絡が来る前に、こちらが先に気づける状態になっているのが大きいところです。「何か起きているかもしれない」を検知できているという安心感は、運用していて想像以上に効きます。