こんにちは。ディレクターのshuheiです。
私はWebディレクターという仕事柄、普段、直接コードに触れることはほとんどありません。それでも、Claude Codeを使った開発に興味があったので、試しにやってみたら、自分用の小さな死活監視システムが思ったよりいい感じにできました。今回はその話をします。
そもそも、監視の仕組みが欲しいと思ったとき、わざわざエンジニアに一から作ってもらうのは大げさです。普通なら既製のSaaSを入れます。ただ、SaaSはSaaSでコストがかかりますし、導入や設定にエンジニアの工数が必要なこともあります。使いこなすための学習コストもそれなりにかかります。かといってエンジニアに何か頼んでも、みんな手が空いているわけではないので、すぐに対応してもらえるとは限りません。
それなら、自分が使いやすくて、自分が見たいものだけを並べたものを、自分で作ってしまえばいい。コードが書けない私でも、AIに任せればなんとかなるかもしれない。そのくらいの軽い気持ちで始めました。
見たかったのは、もっと小さくて具体的なこと
ちゃんとした監視サービスはいろいろあります。PingdomやUptimeRobot、StatusCakeのように外部からサイトの可用性を確認してくれるもの。ZabbixやMackerelのようにサーバー全体を本格的に監視する基盤。どれも優秀で、規模が大きいならこういったものを使うべきだと思います。
ただ、私が見たかったのは、もっと小さくて具体的なことでした。
- 担当しているサイトのHTTPステータスと応答時間を見たい
- 証明書の残日数を知りたい
- FTPSがちゃんとTLSで繋がるかも確認したい
- 通知してほしい対象と、眺めておくだけの対象を分けたい
たとえば、応答が遅くなってきている、証明書がもうすぐ切れる、といった兆候に、クライアントから連絡が来る前にこちらで気づきたい。そういう「毎日ちょっと見ておきたい」程度のことのために、本格的なサービスを契約して運用を覚えるのは大げさでした。
だったら、自分たちの見たい項目だけを並べた小さな画面を作ったほうが早い。そう考えて、自作する方向にしました。
Claude Codeに「これできる?」と聞きながら作った
最初からきれいな設計があったわけではありません。「まずHTTP監視がほしい」「次は証明書」「FTPSも確認したい」と、運用で気になったことを一つずつ足していきました。
作り方も、自分でコードを書いたわけではありません。Claude Codeに「こういうことできる?」と聞いて、「できる」と返ってきたら、そのまま実装に組み込んでもらう。動いたのを確認して、また次の要望を伝える。これを繰り返して、少しずつ形にしていきました。いわゆるバイブコーディングです。
正直なところ、これを全部自分で調べて書こうとしていたら、最初の一歩で止まっていたと思います。やりたいことを言葉にすれば動く形になって返ってくる、というのは、コードを書かない自分にとってかなり大きな変化でした。
もちろん、出てきたものをそのまま信じて終わりにはしていません。実際に接続して、取れる値を確認して、通知が多すぎないか様子を見て、画面の見づらいところを直す。そのあたりは自分で確認しました。
「何を監視するか」「どの状態を異常とみなすか」「誰にいつ通知するか」は、結局のところ運用している自分が決める部分です。Claude Codeは作る速度を一気に上げてくれましたが、判断の部分は人間が引き受けるものだと感じました。
まずはHTTPの死活監視から
中身はとてもシンプルです。
監視対象のURLをDBに登録しておき、cronで定期的にアクセスします。期待するHTTPステータスが返れば正常、そうでなければ異常として記録します。あわせて、応答時間やTTFB、リダイレクト数も保存しています。
200が返るかどうかだけでも監視にはなりますが、応答時間を残しておくと「最近遅くなってきた」といった変化に気づけます。クライアントから言われる前に気づきたい、という当初の目的には、これがよく効きました。
通知は「失敗したら即」にはしない
監視を入れて最初に困ったのが、通知でした。
一時的な回線の揺れや、たまたまのタイムアウトで毎回Slackに通知が来ると、すぐに通知疲れしてしまいます。本当に見たい異常が埋もれてしまっては意味がありません。
そこで、異常が一定回数連続したときだけ通知するようにしました。復旧したときも、必要に応じて知らせます。監視はしたいけれど通知はいらない対象もあるので、対象ごとに通知のON/OFFも持たせています。
証明書の期限を見張る
運用で地味に怖いのが、証明書の期限切れです。
サイト自体は動いていても、証明書が切れると、利用者にはエラーにしか見えません。これはまさに「クライアントから連絡が来てしまう」典型的なパターンです。
そこで、HTTPS証明書の有効期限、残日数、発行先、発行者を取得して保存しています。残りが少なくなったらSlackに通知し、緊急度に応じて、残り10日以内は @here、5日以内は @channel と通知レベルを変えています。
FTPSのTLS接続まで確認する
今回はHTTPSだけでなく、FTPSも対象にしました。
FTPSは、ポートに繋がるだけでは「ちゃんと使える」とは言い切れません。TLSでの暗号化がきちんと有効になっているか、証明書が正しく検証できるか、その上で実際にデータのやり取りまでできるか——というところまで見て、はじめて安心できます。
そこで、TLSを有効にしてから、保護された状態でデータ接続まで通ることを、ひと続きで確認するようにしました。ここもClaude Codeに頼んで形にした部分です。ここまで見ておくと、「FTPSサーバーに繋がる」だけでなく「保護されたデータ接続まで使える」ことを確認できます。
ダッシュボードで一覧する
チェック結果はDBに保存し、Web画面から一覧で見られるようにしました。
監視対象ごとにカードを並べていて、現在の状態（UPかどうか）、直近20回のチェックを緑と赤で並べた履歴バー、直近・平均・最大・最小の応答時間、HTTPコード、24時間・7日・30日の稼働率を表示しています。通知対象とは別に「参考」として眺めるだけの対象も、同じ画面に並べています。画面上部には稼働中の対象数（6/6など）も出していて、自動更新をONにしておけば、開きっぱなしにしておくだけで最新の状態が分かります。
証明書については別の画面にまとめていて、残日数や有効期限、TLSハンドシェイクと検証の結果を一覧で確認でき、気になったときはその場で「今すぐ確認」もできます。
画面下部には時系列グラフも置いていて、6時間・24時間・7日・30日と期間を切り替えながら、応答時間の推移を対象ごとに重ねて見られるようにしました。
AIで状況の短い解説も出す
応答時間や稼働率の数字が並んでいても、ぱっと見で「大丈夫なのか、まずいのか」を判断するのは、意外と難しいものです。
そこで、直近の監視データ（状態、応答時間の傾向、稼働率、直近の異常回数など）をもとに、Gemini APIで短い解説文を生成し、各カードに表示するようにしました。たとえば「平均応答時間172msに対し、最大2179msの突発的な遅延が出ている（平均の約12.7倍）」といった具合に、数字だけでは埋もれてしまう状況が、一言で読み取れます。状態に応じて表示の色も変えているので、画面を開いた瞬間に、どこを気にすればいいかが分かります。
API呼び出しが増えすぎないよう生成結果は短時間キャッシュし、APIが失敗したときはルールベースの簡単な説明にフォールバックさせています。
cronは分けて回す
HTTP監視と証明書監視は、見たい頻度が違います。
HTTPは数分おきに確認したいですが、証明書の期限は毎分見る必要はありません。そのためcronも分けていて、HTTPは短い間隔、証明書は1日1回程度にしています。古いチェック結果や通知履歴は、別のcleanupスクリプトで定期的に削除しています。
小さく作ると、運用に合わせて育てやすい
最初から大きな監視システムを作ろうとすると、おそらく途中で挫折していました。
HTTPの死活監視から始めて、応答時間、通知制御、証明書、FTPS、ダッシュボード表示、そしてAIによる解説と、必要になったものを少しずつ足していく。そうすると、自分たちの運用にちょうど合った形になっていきました。
構成自体はPHP、MySQL、cron、Slack通知という素朴なものです。そこにAIの解説を一つ加えただけですが、「落ちているかどうか」以上の状態が、ひと目で分かるようになりました。
そして今回いちばん面白かったのは、普段コードを書かない自分でも、欲しいものを自分の手で作れてしまった、という体験そのものでした。これまでは「こういうのが欲しい」と思っても、エンジニアにお願いするか、諦めるかのどちらかでした。それが、AIのおかげで「とりあえず自分で作ってみる」が選択肢に入った。興味本位で始めたものが、気づけば日々の運用に入ってくる道具になっていました。
もちろん、これはエンジニアが要らなくなるという話ではありません。何を作るべきか、どこからが本当に難しいのかを見極めるのは、やはりエンジニアの領域です。ただ、こうした小さな道具を自分で用意できるようになると、その分エンジニアには、もっと重要なところに集中してもらえます。技術を本業にしている会社だからこそ、職種にかかわらず一人ひとりがAIで手を動かせることには、けっこう意味があると思っています。
大きな監視基盤を置き換えるものではなく、運用の隙間を埋める小さな道具として。そして、その道具を自分で作るための相棒として、AIはかなり頼れる存在でした。