こんにちは、オフィスピコッツの小笹です。
以前のAI社員実践記で、AIに画面を見せながら、初めてクラウドサーバーを契約した話を書きました。
あのとき契約したサーバー、その後どうなったと思いますか。
正直に書くと、開発作業の区切りがついてからは、停止したまま置いてありました。
今回使っているクラウドサーバーは従量課金です。
利用明細を見ると、この環境では停止中でも1日28円。実際に7日間で196円が計上されていました。
1日28円なら、それほど気になる金額ではありません。
月にすると900円弱です。
ただし、
何も生み出していないものに、毎月900円近く払い続ける。
そう考えると、少し話が変わってきます。
今回は、この「遊んでいるサーバー」をAI社員と一緒に見直し、会社の仕事をする設備に変えた話です。
作業にかかった時間は、およそ1時間でした。
「削除する」か「働かせる」か
きっかけは、AI社員との固定費の棚卸しでした。
使っているサービス、契約中のクラウドサービス、サーバーなどを見直している中で、この停止中のサーバーも対象になりました。
AIから出てきた選択肢は、大きく2つです。
- 削除してコストをゼロにする
- 何か具体的な仕事を与えて使い続ける
バックアップは取ってあります。
必要になれば、同じ環境を作り直すこともできます。
そのため、「もったいないから、とりあえず残しておきましょう」という結論にする必要はありません。
使わないなら削除。
使うなら、月900円弱を払う意味のある仕事をさせる。
この整理は分かりやすいものでした。
そこでAI社員から出てきた候補の一つが、
クライアントサイトの死活監視
でした。
ちょうど、19サイトを人の目で確認したばかりだった
オフィスピコッツでは、運営サポートをお任せいただいているクライアントサイトについて、定期的に状態確認を行っています。
実は今回の少し前にも、17クライアント・19サイトをまとめて確認したところでした。
サイトへアクセスする。
正常に表示されるか確認する。
WordPressなどの管理画面も必要に応じて確認する。
こうした作業自体は今後も必要です。
ただし、
「サイトそのものが落ちていないか」
という確認まで、人間が定期的に見に行く必要があるのか。
ここはサーバーに任せられます。
そこで今回、
遊休状態だったクラウドサーバーに、クライアントサイトを24時間監視する仕事を与える
ことにしました。
Uptime Kumaを使って、5分おきに監視する
監視に使ったのは「Uptime Kuma」というオープンソースの監視ソフトです。
指定したWebサイトへ定期的にアクセスし、
- 正常につながるか
- エラーになっていないか
- 応答しているか
などを自動で確認してくれます。
今回は監視間隔を5分に設定しました。
つまり、人が寝ている時間も休日も含めて、
24時間365日、5分おきにサイトを確認する担当者
を1人置くようなイメージです。
もちろんサーバーが見ているのは「サイトが応答しているか」という部分です。
ページのデザインが崩れていないか。
お問い合わせフォームが正常か。
更新内容がおかしくないか。
そうした部分は、これまで通り人の目で確認します。
人のチェックを全部なくすのではなく、
機械に任せられる単純な見張りだけをサーバーへ渡す
という分担です。
まず、止めていたサーバーを再び起動
今回使ったサーバーは、以前のAI社員実践記で契約したものです。
スペックは、
- 2コア
- メモリ2GB
- ストレージ200GB
の環境です。
大規模なWebサービスを動かすわけではありません。
今回のようなサイト監視用途なら、既に持っているこの環境をまず使ってみることにしました。
サーバーを起動し、SSHで接続します。
ここからの進め方は、これまでのAI社員実践記とほぼ同じです。
AIが次の作業を1つ出す。
私が実行する。
結果を見せる。
AIが確認して次へ進む。
全部のコマンドを一気に渡してもらうのではありません。
問題が起きたときに、どこで止まったのか分からなくなるからです。
最初の構築は、ほぼコマンド1回
SSHでサーバーへ入ったあと、AI社員からUptime Kumaを起動するためのコマンドが提示されました。
それをコピーして実行します。
しばらく待つと、Uptime Kumaが起動しました。
ブラウザからアクセスすると、初期設定画面が表示されます。
管理者アカウントを作成。
ログイン。
ここまでで、およそ15分です。
サーバー構築というと、
「Linuxをかなり勉強しないとできない」
というイメージがありました。
今回も、私自身がすべてのコマンドの意味を完全に理解しているわけではありません。
その代わり、
何をしようとしているコマンドなのかをAIに確認し、結果を一つずつ見ながら進める。
この方法なら、以前よりずっと心理的なハードルは下がります。
26サイトを1件ずつ登録するのは、さすがにやりたくない
監視システムそのものは動きました。
次は、監視対象の登録です。
今回登録することにしたのは26サイト。
普通にUptime Kumaの管理画面から登録するなら、
- サイト名を入力
- URLを入力
- 監視方法を選ぶ
- 監視間隔を設定
- 保存
という作業を26回繰り返すことになります。
できなくはありません。
でも、かなり面倒です。
しかも、人間が26件入力すれば、
- URLのコピーミス
- 文字の打ち間違い
- 登録漏れ
も起こり得ます。
そこでAI社員へ、
「26サイトあるけれど、これを全部手作業で登録するの？」
と相談しました。
返ってきた答えは、
「一括登録します」
でした。
URL一覧を渡したら、登録用スクリプトができた
私は監視したいサイトの一覧をチャットへ貼りました。
AI社員は、それを使って一括登録用のPythonスクリプトを作成。
私はそのスクリプトをサーバー上へ置いて実行します。
画面には、
「登録：」
という文字が次々に表示されました。
1件。
2件。
3件。
……
26件。
最後に「完了」。
Uptime Kumaのダッシュボードへ戻ると、監視対象が一気に追加されていました。
画面上部には、
正常 26
停止 0
メンテナンス 0
不明 0
一時停止 0
と表示されています。
左側にも「100%」の緑色表示が並びました。
この瞬間から、26サイトについて5分おきの自動監視が始まりました。
AIを使う意味は「26回クリックしなくていい」だけではない
単純に考えれば、
「26件くらいなら手作業でも登録できる」
とも言えます。
でも、今回面白かったのは、
AIが“人間が画面でやる仕事”を、“コンピューターにまとめてやらせる仕事”へ変換したこと
です。
私はUptime KumaのAPIを調べていません。
一括登録スクリプトの書き方も調べていません。
「26件手入力するのは面倒」という状況を伝えただけです。
AI社員は、
では手入力をやめる方法にしましょう
と作業そのものを組み替えました。
AI活用というと、
「文章を書かせる」
「アイデアを出してもらう」
という使い方がまず思い浮かびます。
でも実務では、
面倒な手作業を見つけて、それを自動処理へ変換する
という使い方の方が、大きな効果が出る場面もありそうです。
ただ監視するだけでは、まだ役に立たない
26サイトの監視が始まりました。
これで完成……
と思ったところで、AI社員からもう一つ確認が入りました。
「異常が起きたとき、どうやって気づきますか？」
確かにその通りです。
Uptime Kumaの画面を見れば、正常かどうかは分かります。
でも、毎日そのダッシュボードを開く必要があるなら、「自動監視」の意味が薄くなります。
サイトが落ちたとき、
こちらが見に行かなくても知らせてくれる
ところまで作って、初めて監視システムになります。
そこでメール通知を設定しました。
テスト通知がGmailに届いた
通知先には、普段確認しているメールアドレスを設定しました。
設定後、テスト通知を送ります。
しばらくすると、Gmailの受信トレイに、
「サイト監視アラート Testing」
というメールが届きました。
これで、
サイトに異常が発生
↓
Uptime Kumaが検知
↓
メールで通知
というところまでつながりました。
常にダッシュボードを開いておく必要はありません。
普段は何もしない。
問題が起きたときだけ知らせてもらう。
今回欲しかったのは、まさにこの状態です。
作業の途中で、別の「守りの穴」も見つかった
メール通知を設定している途中で、AI社員との会話が別の方向へ広がりました。
通知先として使うGoogle Workspaceのアカウントを確認していたとき、
メインアカウントの2段階認証
について指摘されたのです。
監視システムとは直接関係ありません。
しかし、会社のメールや各種Googleサービスへつながる重要なアカウントです。
ここがパスワードだけで守られているなら、優先して強化した方がいい。
確かにその通りでした。
そこで、その場で2段階認証も有効化しました。
所要時間は約10分です。
今回の監視サーバー構築には必須ではありません。
それでも、
作業中に見つかったリスクを、そのまま放置せず処理する。
こういう「ついでの確認」ができるのも、AIと画面を見ながら作業するメリットの一つだと思います。
AI社員は、頼んだ作業だけをする必要はない
今回、AI社員へ最初に相談したテーマは、
「停止したまま料金がかかっているサーバーをどうするか」
でした。
そこから、
- 削除するか再利用するか整理
- サイト監視サーバーという用途を決定
- Uptime Kumaを構築
- 26サイトの一括登録
- メール通知を設定
- 2段階認証も確認
と、作業が広がっていきました。
最初からこの手順を全部計画していたわけではありません。
会話しながら、
「では次に何が必要か」
を積み重ねていった結果です。
これまでのAI社員実践記でも感じていますが、AIを単なる質問回答ツールとして使うより、
仕事の途中経過をずっと見せておく
方が、実務では面白い使い方ができます。
かかった費用はどれくらいか
今回の費用を整理します。
クラウドサーバー
今回使った環境では、利用明細上、停止中でも1日28円でした。
実際の明細では、
7日間で196円
です。
稼働状態での今月分の実額は、翌月に請求が確定してから改めて確認します。
この記事にも確定後、追記する予定です。
Uptime Kuma
0円。
オープンソースソフトなので、ソフトそのものの利用料はかかりません。
構築作業
今回、自社でAIと一緒に行ったので外注費はありません。
作業時間は、サーバー起動からサイト登録、通知テストまでで約1時間でした。
月900円弱は「固定費」から「設備費」に変わった
今回一番大きかったのは、月900円弱を節約したことではありません。
むしろ、サーバーは削除せず、今後も費用がかかります。
ただし、意味が変わりました。
以前は、
停止したまま、何もしていないサーバー。
今は、
26サイトを24時間365日見張っているサーバー。
同じ月900円弱でも、
「放置されている固定費」と
「クライアントサイトを監視する設備費」
では、意味がまったく違います。
人のチェックは、なくさない
ここは誤解のないようにしておきたいところです。
Uptime Kumaが26サイトを監視するようになったからといって、今後人間がサイトを確認しなくていいわけではありません。
監視サーバーが分かるのは、
Webサイトが応答しているか
ということです。
たとえば、
- デザインが崩れている
- WordPressの更新で表示がおかしい
- お問い合わせフォームが動かない
- 古い情報がそのまま残っている
- SSLやPHPなど別の問題が起きている
といったことまでは、この監視だけでは判断できません。
だから、
人が見る仕事と、機械に任せる仕事を分ける。
今回の仕組みは、そのためのものです。
今回の結論
今回のスタート地点は、
「使っていないのに料金だけかかっているサーバーをどうするか」
でした。
普通なら、
「使わないなら解約」
で終わる話かもしれません。
でも、AI社員と相談したことで、
解約するか、仕事を与えるか
という選択肢になりました。
結果として、停止していたサーバーは、
26サイトを5分おきに、24時間365日監視する設備
になりました。
しかも、
- 監視ソフトは無料
- 26サイトはスクリプトで一括登録
- 異常時はメール通知
- 構築は約1時間
です。
今回改めて感じたのは、
AIは「新しいものを作る」だけでなく、「すでに持っているものをどう働かせるか」を考える相手にもなる
ということです。
使っていないサーバー。
放置しているクラウドサービス。
契約したまま活用できていないツール。
会社の中には、こういうものが意外とあります。
削除して固定費を下げるのも正解です。
一方で、
月数百円、数千円なら、仕事を与えた方が価値が出ることもある。
今回のサーバーは、その一例になりました。
あなたの会社にも「遊んでいる契約」はありませんか
オフィスピコッツでは、ホームページやサーバー、クラウドサービスについて、
契約はしているけれど、何に使っているのか分からない。
昔必要だったけれど、今も必要なのか分からない。
もっと仕事に使える方法がないか知りたい。
といったところから整理しています。
AIを使う場合も、
「とりあえずAIを導入する」
のではなく、
今ある仕事・契約・道具の中で、AIを使うとどこが楽になるのか
から考えます。
- 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社員実践記は、まだ続きます。
京都産業21 登録専門家（No.46）／滋賀県DX協創パートナー／デジタル庁 デジタル推進委員。2002年開業、創業25年目。京都・滋賀を中心に1万件超のWeb活用・制作に携わる。 会社概要を見る