【AI社員実践記 第19話】保守を「見える化」するWeb暖簾　最終点検日が自動更新されるバッジを作った

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

ここ最近のAI社員実践記では、サーバーの裏側で働く仕組みをずいぶん増やしてきました。

サイト監視。

ドメイン期限チェック。

リンク切れ巡回。

補助金の締切ウォッチ。

自動処理そのものの点呼。

管理画面のセキュリティ改善。

どれも実際の業務では役に立っています。

ただ、一つ気になっていたことがあります。

こうした保守の仕事は、ちゃんとやればやるほど外から見えない。

ということです。

サイトが落ちない。

ドメインが失効しない。

リンク切れが放置されない。

バックアップが取れている。

何も問題が起きなければ、訪問者から見えるのは「普通に動いているホームページ」だけです。

それは本来、良いことです。

でも、保守を依頼しているクライアント自身から見ても、

「実際に今も見てもらっているのか」

は分かりにくい。

今回は、この「見えない仕事」をどう見せるかをAI社員と考えました。

出てきた発想が、

Web版の「暖簾」

でした。

「ちゃんと見ています」を、店先に小さく出せないか

AI社員との商品アイデアの相談中、

「保守契約そのものを、サイト上で自然に見せる方法はないか」

という話になりました。

そこで出てきたのが暖簾という比喩です。

昔の店先に掛かる暖簾のように、

「この店は今も営業し、ここに人がいる」

ことを静かに示すものをWebにも置けないか。

派手な広告バナーではありません。

フッターの一番下に、小さく一行だけ。

例えば、

「このサイトは保守されています｜最終点検 8月23日｜オフィスピコッツ」

と表示する。

これなら、

制作会社の宣伝というより、

「このホームページには今も管理者がいる」

ことを示せます。

かなり良さそうに思えました。

ただし、ここですぐ問題が出ます。

日付を手書きしたら、ただの飾りになる

HTMLに、

「最終点検 8月23日」

と書くだけなら数分でできます。

でも、翌日は8月24日です。

人間が毎日書き換えるわけにはいきません。

そしてもっと問題なのは、

実際には点検していないのに、古い日付だけが残り続けること。

です。

それでは、

「このサイトは見守られています」

という信用表示ではなくなります。

そこで今回、AI社員と最初に決めたのが、

バッジ側では日付を作らない

というルールです。

表示する日付は、

実際に監視サーバーが確認した結果からだけ作る。

ここを仕組みの中心にしました。

「嘘をつけないバッジ」にするための3つのルール

今回のWeb暖簾には、3つの条件を入れました。

1. 日付は実測データからだけ入れる

毎朝、監視サーバーがUptime Kumaの状態を確認します。

対象サイトが正常なら、

その日の点検日をCloudflare側へ送ります。

人間が日付を入力することはありません。

2. データが古くなったら自動で消す

何らかの理由で、

監視サーバーから新しいデータが来なくなったとします。

それなのに、

「最終点検 8月23日」

が何週間も残り続けてはいけません。

そこで、

3日以上更新されなければバッジそのものを表示しない

設計にしました。

表示が消えることも、仕組みの一部です。

3. サイトが落ちている日は更新しない

監視対象サイトがダウンしている日に、

「本日点検済み」

と更新してしまうのもおかしい。

そのため、

Uptime Kumaで正常と確認できた日だけ、新しい日付を送る

ようにしました。

つまり今回作りたかったのは、

ただの「保守中です」表示ではありません。

バッジが表示されていること自体が、裏側の監視が現在も動いている証拠になる状態

です。

監視サーバーとCloudflareで役割を分けた

構成は、第13話あたりから固まってきたオフィスピコッツの使い分けをそのまま使いました。

定期的に動く処理はVPS。

外部へ常時配信するものはCloudflare。

今回も同じです。

流れはこうなります。

1. VPS上のスクリプトが、毎朝Uptime Kumaの監視状態を確認
2. 対象サイトが正常なら、その日の点検日を送信
3. Cloudflare Workerが受け取る
4. 日付をWorkers KVへ保存
5. Workerがバッジ表示用JavaScriptを配信
6. 各サイトはscriptタグを1行置くだけ

サイトごとに複雑なプログラムを入れる必要はありません。

監視する側に仕組みを集約して、

サイト側は表示するだけです。

まずCloudflareに保存場所を作る

最初にCloudflare Workers KVへ、今回の点検情報を保存する領域を作りました。

KVは、これまでのAI社員実践記でも使っています。

今回保存するデータはかなり小さいものです。

サイトを識別する情報。

最終点検日。

必要な状態情報。

それだけです。

この程度なら大きなデータベースを用意する必要はありません。

AI社員が設計をまとめ、

私は管理画面で名前を入力して作成。

次へ進みます。

次に配信用Workerを作る

続いてCloudflare Workerです。

役割は大きく2つあります。

一つは、

監視サーバーから届いた点検情報を受け取ること。

もう一つは、

各サイトへバッジ表示用JavaScriptを配信すること。

Workerをデプロイし、KVと接続します。

ここまで来れば、仕組みの中心はほぼ完成です。

あとはVPS側から、

「このサイトは今日正常でした」

という情報を送れるようにします。

ところが、ここで今回一番のつまずきが起きました。

トークンは合っているのに403 Forbidden

VPSからWorkerへ点検データを送るテストをします。

すると、

HTTP 403 Forbidden

で拒否されました。

認証用の秘密トークンを確認します。

Worker側。

VPS側。

同じです。

コピーし直します。

それでも403。

コードの処理も一見おかしくありません。

こういうエラーが一番困ります。

間違っているように見える場所が、全部合っている。

自分だけで調べ始めると、かなり時間を使いそうです。

そこでAI社員と切り分けました。

同じ通信をcurlで試したら通った

AI社員から出たのは、

「まず、Pythonではなくcurlで同じ送信を試しましょう」

という案でした。

同じWorker。

同じURL。

同じトークン。

送信する内容も同じ。

道具だけ変えます。

すると、

curlでは成功。

これで一気に範囲が狭まりました。

Workerそのものが壊れているわけではない。

トークンも間違っていない。

Cloudflareまでの経路も生きている。

違いは、

Pythonから送るか、curlから送るか。

だけです。

AIが疑ったのはUser-Agentだった

AI社員が次に注目したのがUser-Agentです。

Pythonの標準ライブラリで通信すると、

通信元がPython系のクライアントとして識別されます。

AI社員は、

Cloudflareの手前のセキュリティ判定が、この通信を機械アクセスとして弾いている可能性

を疑いました。

ここは「原因を完全に証明した」とまでは言えません。

ただ、

• curlでは通る
• Python標準の通信では403
• User-Agentを明示すると通る

という差分は、かなり強い手がかりです。

そこで送信時に、

独自のUser-Agent

を1行追加しました。

もう一度実行します。

結果は、

pushed ok, 200

でした。

通りました。

403を「認証エラー」と決めつけなくてよかった

今回の403は、最初だけ見ると、

「トークンが違う」

「Workerの認証処理がおかしい」

と考えてしまいそうです。

でも、同じ条件を別の方法で試したことで、

認証以外の場所まで切り分けられました。

これまでのAI社員実践記でも何度かありましたが、

AIが特に役に立つのは、

答えそのものより、次に何を試せば原因を狭められるか

を出してもらう場面です。

今回も、

「403の原因を考えて」

だけではなく、

curlで比較する。

差分を見る。

User-Agentを変える。

という順で進んだことで、数分で抜けられました。

バッジを作ったら、自社サイトの監視漏れを発見した

通信が通るようになったところで、もう一つ副産物がありました。

最初の試験設置先として選んだのは、

京都・滋賀プレスリリース

です。

ところが、Uptime Kumaの監視対象を確認すると、

localpr.jpが入っていませんでした。

クライアントサイトの監視を優先して増やしてきた結果、

自社メディアが後回しになっていたようです。

かなりありがちな話です。

お客様のサイトは見る。

自分のサイトは後回し。

今回のバッジは、

「監視されているサイトだけ表示する」

設計なので、この漏れをそのまま見つけました。

すぐにUptime Kumaへ追加します。

ステータスは正常。

監視が始まりました。

保守を見える化する仕組みを作ったことで、保守そのものの漏れが一つ直った。

思わぬ副産物でした。

サイト側でやることはscriptタグ1行

最後は実際のサイトへ表示します。

サイト側で必要なのは、基本的にscriptタグを1行設置するだけです。

監視結果を取得する処理。

日付を保存する処理。

古い日付かどうか判断する処理。

そのあたりはCloudflare側にあります。

サイトへ複雑な仕組みを持ち込まないので、今後ほかの管理サイトへ展開するときも軽く済みます。

実際にlocalpr.jpのフッターへ入れた結果がこちらです。

一番下に、

「このサイトは保守されています｜最終点検 2026/08/23｜オフィスピコッツ」

という一行が表示されています。

かなり小さいです。

最初から、このくらいでいいと考えていました。

派手にしない方が「暖簾」らしい

このバッジを、

大きな画像にすることもできます。

緑色で、

「24時間監視中！」

と目立たせることもできます。

でも今回は、あえてやめました。

サイトを見る人の目的は、

保守会社の宣伝を見ることではありません。

地域情報を見る。

商品を見る。

サービスを見る。

問い合わせる。

そちらが主役です。

保守バッジは、

気づいた人が「あ、ちゃんと管理されているんだ」と分かる程度

でいい。

制作会社のクレジットと同じくらいの控えめさにしました。

「暖簾」という今回の比喩にも、その方が合っています。

毎朝7時50分、日付だけが静かに進む

VPS側の処理は、毎朝7時50分に動かします。

Uptime Kumaの状態を確認。

正常なら、その日の点検日をCloudflareへ送る。

バッジの日付が更新されます。

人間は何もしません。

サイトが正常なら、

翌朝、

8月23日 → 8月24日

と進みます。

逆に、監視が止まる。

データ送信が止まる。

対象サイトが正常ではない。

そうした状態では、新しい日付は入りません。

さらに一定期間更新されなければ、バッジそのものが消えます。

表示し続けることより、表示してはいけないときに消えることの方が重要

と考えた設計です。

これは「稼働率100％」を保証するバッジではない

ここは公開するうえで大切なので、明確にしておきます。

今回のバッジが意味するのは、

「このサイトは絶対に落ちません」

ではありません。

100％の稼働を保証するものでもありません。

サーバー障害が起きることはあります。

外部サービスが止まることもあります。

ネットワーク障害もあり得ます。

今回表示しているのは、

「このサイトには現在、保守・監視の仕組みが入っており、直近の点検情報が更新されている」

という事実です。

そこを超えて、

「絶対安心」

と見せるつもりはありません。

むしろ今回、

見せる情報を実測値と結びつけ、古ければ消す

ようにしたのは、そのためです。

保守の価値は「事故が起きないほど見えなくなる」

ホームページの保守には、不思議なところがあります。

問題が頻発すれば、

修正した。

復旧した。

対応した。

という仕事が見えます。

でも、本当にうまく保守できていると、

何も起きません。

サイトが普通に表示されている。

問い合わせも届く。

SSLも切れない。

ドメインも失効しない。

バックアップも静かに取られている。

そして、

何も起きなかったことに対して、お客様が毎月費用を払う。

この価値は、とても説明しにくいものです。

今回のWeb暖簾が、そのすべてを説明できるわけではありません。

ただ、

「裏側に管理している人と仕組みがある」

ことを、小さくでも見せられるようになります。

これは保守サービスを考えるうえで、かなり面白いと思っています。

「やっています」ではなく「今も動いています」を見せる

今回特に気に入っているのは、

バッジの文言ではありません。

仕組みで嘘をつきにくくしたこと

です。

普通の保守バッジなら、

「24時間監視しています」

とHTMLに書けば終わります。

監視が止まっても表示されます。

契約が終わっても、消し忘れれば残ります。

今回の仕組みでは、

監視サーバーからの実データが来なければ更新されません。

古くなれば消えます。

つまり、

「保守しています」という宣言ではなく、「今も保守の仕組みが動いています」という状態を表示する。

ここに、ただの装飾との違いがあります。

一度作れば、ほかの管理サイトへ横展開できる

今回一番時間がかかったのは、最初の仕組みです。

KVを作る。

Workerを作る。

監視データを送る。

エラーを切り分ける。

バッジを表示する。

ここまでで約1時間半でした。

でも、2サイト目からは違います。

すでに配信基盤はあります。

監視サーバーもあります。

Workerもあります。

サイト側ではscriptタグを追加し、監視対象として登録する。

基本的にはその程度です。

第9話以降ずっと出てきた、

「最初の1つが一番高く、2つ目から安くなる」

が、今回も当てはまります。

追加費用は0円

今回、新しい有料サービスは契約していません。

監視用VPSは既存。

Uptime Kumaも既存。

Cloudflareも既存契約の範囲です。

そのため、

追加固定費は0円。

設計の相談から、

KV作成。

Worker作成。

403の切り分け。

監視漏れの修正。

サイトへの設置。

表示確認。

そこまで含めて約1時間半でした。

技術そのものも面白かったですが、

今回一番時間を使った価値は、

「保守という見えない仕事を、どう見せれば広告っぽくならず、しかも嘘にならないか」

を考えたところだったと思います。

今回の結論

第19話で作ったのは、

最終点検日が自動更新される小さな保守バッジ

です。

でも、今回のテーマはバッジ制作そのものではありませんでした。

一番考えたのは、

見えない仕事の価値を、どう伝えるか。

そして、

見せるなら、仕組み側で正直さを担保できないか。

ということです。

保守は、

何かを直す仕事だけではありません。

何も起きないように見張る。

期限を確認する。

異常があれば知らせる。

バックアップを取る。

問題になる前に手を入れる。

その仕事は、普段はほとんど見えません。

今回のWeb暖簾は、

その裏側の仕事をほんの少し店先へ出す試みです。

AI社員実践記を続けていると、

AIに何かを書かせることより、

「今ある仕事を別の形にできないか」と一緒に考える時間

の方が面白くなってきました。

ホームページの保守、今どうなっているか分かりますか

ホームページは公開して終わりではありません。

WordPress。

PHP。

SSL。

ドメイン。

バックアップ。

リンク切れ。

表示障害。

さまざまな確認が必要です。

オフィスピコッツでは、ホームページ公開後の運営・保守についても対応しています。

「今、誰がどこまで見ているのか分からない」

「制作会社との保守契約が何をしているのか見えない」

「AIで更新しているので、壊れていないか定期的に見てほしい」

といったところからでもご相談いただけます。

• 運営サポート https://pikoz.net/unei-support/
• HPセカンドオピニオン https://pikoz.net/hp-second-opinion/
• 15分立ち話相談 https://pikoz.net/tachibanashi-soudan/
• AI社員実践記 https://pikoz.net/category/ai-jissen/

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