【AI社員実践記 第10話】1台のVPSに2人追加配属　ドメイン期限チェックと月次レポートを自動化してみた

こんにちは、オフィスピコッツの小笹です。

前回のAI社員実践記では、使わずに止めていたVPSへ「サイト監視」という仕事を与えました。

26サイトを5分おきに確認し、サイトが落ちたときだけメールで知らせる監視係です。

月900円弱の遊休サーバーが、24時間365日クライアントサイトを見張る設備に変わりました。

今回は、その続きです。

同じVPSに、2人目と3人目の“部下”を追加しました。

追加したのは、

• ドメイン期限チェック係
• 月次稼働率レポート係

です。

新しいサーバーを契約したわけではありません。

新しい有料サービスを契約したわけでもありません。

すでに動いているVPSの空いている時間に、仕事を2つ追加しただけです。

そして2人目は、配属したその日にいきなり仕事をしました。

サイト監視だけでは防げない事故がある

第9話で作ったUptime Kumaの監視は順調に動いています。

登録した26サイトへ5分おきにアクセスし、正常に応答しているか確認しています。

サイトが落ちれば、メールで通知が来ます。

これで「サイトが止まったこと」にはかなり早く気づけるようになりました。

ただ、AI社員と次の活用方法を考えている中で、一つ気になることが出てきました。

サイトが落ちる前には、正常に見えている事故もある。

その代表が、ドメインの期限切れです。

ドメインが有効な間は、サイトは普通に表示されます。

Uptime Kumaの画面も緑です。

ところが更新期限を過ぎてドメインが使えなくなれば、Webサイトもメールも影響を受けます。

つまり、

「落ちたことを検知する仕組み」だけでは、「落ちる原因が近づいていること」までは分からない。

ここは別の仕組みが必要です。

ドメイン更新メールだけに頼るのは少し怖い

もちろん、ドメイン管理会社から更新案内のメールは届きます。

ただ、ドメインの更新は多くても年に1回です。

一方、普段のメールボックスには毎日さまざまなメールが届きます。

広告。

通知。

問い合わせ。

サーバーからの自動メール。

サービスの案内。

その中から、年に一度だけ届く重要な更新メールを確実に拾い続ける。

できなくはありません。

でも、

「人がメールを見落とさないこと」を最後の安全装置にするのは、少し不安です。

そこで、更新メールとは別に、

ドメインそのものの期限を機械的に見に行く係

を作ることにしました。

2人目の部下は「ドメイン期限チェック係」

やりたいことはシンプルです。

管理しているドメインについて、

• 期限を定期的に確認
• 残り30日以内なら警告
• 問題があるドメインだけメール通知
• 正常なら何も送らない

という仕組みです。

実行するのは毎週月曜日の朝6時。

週に一度確認できれば、ドメイン期限の管理としては十分余裕があります。

ここで最初に必要になるのが、チェックするドメインの一覧です。

私は、

「管理しているドメインを全部もう一度入力するのかな」

と思っていました。

ところがAI社員から返ってきたのは、

「監視サーバーが、すでにサイトのURLを持っています。そこからドメインだけ抜き出しましょう」

という答えでした。

第9話で作った仕組みが、そのまま材料になった

言われてみればその通りです。

Uptime Kumaには、前回登録した監視対象サイトのURLがすでに保存されています。

そこからドメイン部分だけ取り出せばいい。

新たにExcelや管理表からコピーし直す必要はありません。

AI社員から出されたコマンドを実行すると、監視データからドメイン一覧が生成されました。

添付の作業画面では、この時点で25件のドメインが抽出されています。

さらに監視対象とは別に管理したい自社ドメインを追加し、一覧を完成させました。

ここで感じたのが、

一度作った仕組みは、次の自動化の材料になる

ということです。

第9話では、26サイトを監視するためにURLを登録しました。

そのときは「サイト監視のためのデータ」でした。

今回は、その同じデータが「ドメイン管理の元データ」になりました。

一から作るのではなく、前に作ったものを使い回せる。

こうなると、2つ目の仕組みは急に作るのが楽になります。

正常なら、何も言わない仕組みにした

ドメイン期限チェック係には、もう一つルールを決めました。

問題がない週は、メールを送らない。

毎週月曜日に、

「今週も全部正常でした」

というメールを送ることもできます。

でも、おそらく最初の数回しか読みません。

毎週同じ正常メールが来れば、

「いつものメール」

になってしまいます。

そうなると、本当に警告が出たときまで見落としかねません。

そこで今回は、

• 30日以内に期限が来るドメイン
• 期限情報を正常に取得できなかったドメイン

がある場合だけ通知します。

何もなければ黙っている。

サイト監視係と同じ考え方です。

普段は存在を意識しない。

問題が起きそうなときだけ呼びに来る。

会社の自動化は、このくらいの距離感の方が使いやすい気がします。

毎週月曜の朝6時、自動で出勤する

スクリプトが完成したら、次は自動実行の設定です。

Linuxには「cron」という、決めた日時に処理を自動実行する仕組みがあります。

AI社員の指示に沿って、

毎週月曜日の朝6時

にドメインチェックを実行する設定を登録しました。

これで私は、毎週サーバーへログインする必要もありません。

月曜日の朝6時になると、

ドメイン期限チェック係が勝手に起きる。

一覧を確認する。

問題がなければ、そのまま仕事を終える。

問題があればメールを送る。

そんな状態になりました。

テスト実行したら、本当に警告が出た

設定が終わったので、最後に動作確認です。

本番の月曜日を待つ必要はありません。

手動でスクリプトを1回実行しました。

あくまでテストのつもりでした。

ところが、しばらくするとGmailにメールが届きました。

件名は、

「【ドメイン期限】警告2件・エラー1件」

でした。

30日以内に期限が来るドメインが、2件。

どちらも残り14日でした。

さらに、WHOISの応答形式の関係で期限を正常に取得できないドメインが1件あり、「確認が必要」として通知されています。

つまり、

テストをしたら、本物の問題候補が3件出てきた。

ということです。

作った初日に、作った意味が証明された

警告になった2件のうち、1件はオフィスピコッツで運営しているメディアのドメインでした。

自動更新にはしていないドメインです。

期限まで、あと2週間。

更新案内のメール自体は届いていたはずです。

でも、私はその時点で「あと14日」という数字を意識できていませんでした。

ドメインチェック係を作らなければ、そのまま数日、あるいはさらに先まで気づかなかった可能性があります。

もちろん、実際には別のタイミングで気づいたかもしれません。

ただ、

「誰かがそのうち気づくだろう」ではなく、毎週必ず機械が確認する

状態になったことは大きな違いです。

配属初日から仕事をした新人です。

しかも、かなり重要な仕事でした。

「期限切れ」だけでなく「調べられなかった」も知らせる

今回もう一つ良かったのが、エラーも通知対象にしたことです。

すべてのドメインで、同じ形式の期限情報が取れるとは限りません。

実際、初回チェックでも1件、

WHOISの応答形式が想定と違い、期限を取得できないドメイン

がありました。

このとき、

「期限を取得できなかったから無視」

では困ります。

取得できなかったものこそ、人が確認する必要があります。

そこで、

• 期限が近い → 警告
• 調べられなかった → エラー
• 問題なし → 何も通知しない

という3段階になっています。

AIや自動化の仕組みでは、

「分からなかったことを、分からなかったと報告する」

のも大切です。

何でも自動で判断させるより、判断できないものだけ人間へ返してくる方が安心して使えます。

3人目は「月次稼働率レポート係」

ドメイン期限チェック係が完成すると、もう一つやりたいことが出てきました。

第9話で作ったUptime Kumaは、5分おきにサイトを確認しています。

つまりサーバーの中には、

各サイトがどれくらい正常に動いていたか

というデータが毎日蓄積されています。

せっかくデータがあるなら、それも仕事に使いたい。

そこで3人目として、

月次稼働率レポート係

を追加しました。

こちらは、ほぼ10分で完成しました。

毎月1日に、先月の稼働率を自動で集計する

仕事は簡単です。

毎月1日の朝に、

前月1か月分の監視データを集計。

サイトごとの稼働率を一覧にして、メールで送信します。

ドメイン期限チェック係とは違って、こちらは毎月必ず報告します。

異常があったときだけ知らせる仕事と、

定例で報告する仕事。

同じVPSの中でも役割を分けました。

実はオフィスピコッツでは、運営サポートをお任せいただいているお客様への定期報告に、サイトの稼働状況も活用していきたいと考えていました。

これまでは必要なときにUptime Kumaの画面を開いて確認する形です。

今後は毎月1日に、前月分が自動で届きます。

報告内容を増やすのに、人間の定例作業は増やさない。

こういう自動化は、かなり相性がいいと思います。

初回レポートは「0サイト」だった

こちらも設定直後にテストしました。

そして届いたメールがこちらです。

件名は、

「【月次稼働率】2026年07月・0サイト」

でした。

0サイト。

一瞬、

「失敗した？」

と思いそうになります。

でも、これは正常です。

監視を開始したのは8月。

集計対象としてテストしたのは7月。

7月にはまだ監視データがありません。

だから、

集計対象は0サイト。

仕組みとしては正しく動いていました。

まだ仕事を始める前の月なのに、

「先月分は何もありませんでした」

と律儀に報告してくる。

3人目の新人は、配属初日から少し真面目すぎるタイプでした。

1台のVPSに、3つの仕事が載った

第8話……ではなく、第9話から使っているこのVPSには、現在3つの仕事があります。

1人目：サイト監視係

5分おきに26サイトを確認。

サイトが応答しなくなったときだけ知らせます。

2人目：ドメイン期限チェック係

毎週月曜の朝6時に、管理対象ドメインの期限を確認。

30日以内の期限、または確認できないドメインがあったときだけ知らせます。

3人目：月次稼働率レポート係

毎月1日に、前月の監視結果を集計。

サイトごとの稼働率をメールで報告します。

3人とも、同じVPSの中で動いています。

2人追加して、サーバー代は増えていない

今回の2つの仕組みを追加するために、新しいサーバーは契約していません。

Uptime Kumaとは別の有料サービスも契約していません。

すでに動かしているVPSの中へ、Pythonのスクリプトと自動実行設定を追加しただけです。

そのため、今回の追加のサービス利用料は0円です。

もちろんVPSそのものの利用料はかかっています。

でも、第9話の時点では、

「26サイトの監視のためのサーバー」

だったものが、

今は、

• サイト監視
• ドメイン期限管理
• 月次稼働率集計

の3つを担当しています。

同じサーバー代でも、担当する仕事が増えるほど、1つの仕事あたりのコストは下がっていきます。

1つ目が一番大変で、2つ目から速くなる

今回、一番実感したのはここです。

第9話で監視サーバーを作ったときには、

• VPSを準備
• サーバーへ接続
• Uptime Kumaを構築
• メール通知を設定
• サイトを登録

と、土台から作る必要がありました。

ところが今回、その土台はもうあります。

メールを送る仕組みもある。

監視対象のURLもある。

サーバーも動いている。

自動実行する環境もある。

だから2人目は、既存データからドメイン一覧を作ってチェック処理を追加するだけ。

3人目になると、すでに蓄積している監視データを集計するだけです。

最初に作った仕組みが、次の仕事の部品になる。

この状態になると、自動化を一つ追加するコストが急に下がります。

AI社員は「毎回ゼロから作る人」ではなくなってきた

これまでAIを使うときは、

「この作業をどうすればいい？」

と、その都度聞くことが多かった気がします。

でも今回のように、1つの環境を継続して育てていくと少し変わります。

AI社員との会話も、

「新しく何かを作る」

ではなく、

「今ある仕組みを使って、次に何を任せられるか」

になってきました。

監視サイト一覧がある。

そこからドメイン一覧を作る。

監視データがある。

そこから月次報告を作る。

メール通知の仕組みがある。

次のスクリプトでも同じ送信方法を使う。

人間の会社でも、新入社員が入るたびに会社そのものを作り直すわけではありません。

机がある。

パソコンがある。

メールがある。

共有フォルダがある。

そこへ仕事を割り振ります。

今回のVPSも、少しそんな状態に近づいてきました。

「落ちてから気づく」と「落ちる前に気づく」は別の仕事

第9話と第10話を続けてやってみて、もう一つ分かったことがあります。

サイト監視とドメイン期限監視は、似ているようで役割が違います。

サイト監視係は、

問題が起きたことを早く知らせる係。

ドメイン期限チェック係は、

問題が起きる前に知らせる係。

です。

どちらか一方だけでは足りません。

サイトが現在正常か。

将来止まりそうな要因が近づいていないか。

さらに、その結果を毎月どう報告するか。

一つの「サイト管理」という仕事でも、分解するといくつもの小さな仕事があります。

AIやサーバーを使った自動化では、

大きな仕事を丸ごと任せようとするより、小さな役割に分けて一つずつ配属する

方が作りやすいのかもしれません。

今回の結論

前回、第9話の最後に、

「持っているものをどう働かせるか」

という話を書きました。

今回は、その続きを実際にやりました。

サイト監視という1つの仕事を与えたVPSに、

• ドメイン期限チェック
• 月次稼働率レポート

という2つの仕事を追加。

追加費用はほぼありません。

しかも、ドメイン期限チェック係は配属初日に、残り14日のドメインを2件見つけました。

これほど分かりやすく、

「作っておいてよかった」

と思える初仕事もなかなかありません。

今回の一番の発見は、

仕組みは、仕事を足すほど使い回せる部品が増えていく

ということでした。

サーバー。

通知。

監視データ。

URL一覧。

自動実行。

一度作ったものが、次の仕組みの材料になります。

最初の1人を配属するのが一番大変。

2人目、3人目になると、驚くほど早くなります。

今では、

このVPSに次は何の仕事を任せようか

と考える方が楽しくなってきました。

あなたの会社にも「機械に任せられる小さな仕事」はありませんか

オフィスピコッツでは、AIを導入すること自体ではなく、

今やっている仕事の中で、人が毎回やらなくてもいい部分はどこか

というところから整理しています。

• 毎朝見る
• 毎週確認する
• 毎月集計する
• 期限を確認する
• 異常があったときだけ知らせる

こういう仕事は、自動化と相性がいいものです。

いきなり大きなAIシステムを作る必要はありません。

一つ仕事を任せる。

使えることを確認する。

その仕組みを使って、もう一つ任せる。

今回のVPSは、まさにその形で育っています。

• AI業務診断：https://pikoz.net/ai-shindan/
• AI社員構築サービス：https://pikoz.net/ai-shain/
• 集客見守りプラン：https://pikoz.net/shukyaku-mimamori/
• AIレスキュー（AI見守りプラン）：https://pikoz.net/ai-rescue/
• AI社員実践記：https://pikoz.net/category/ai-jissen/

AI社員実践記は、まだ続きます。