こんにちは、オフィスピコッツの小笹です。
第9話では、月900円弱で停止したままになっていたVPSへ、26サイトを5分おきに見回る「サイト監視係」を配属しました。
第10話では、同じVPSへさらに、
- ドメイン期限チェック係
- 月次稼働率レポート係
を追加しました。
1台のサーバーに仕事を少しずつ増やしていく、サーバー活用シリーズの第3弾です。
今回は、4人目の係を配属しました。
仕事は、
サイトの中にあるリンク切れや画像切れを、週に1回巡回して探すこと。
そしてこの4人目、配属初日のテストでいきなり仕事をしました。
自社サイトから、404エラーを5件見つけてきたのです。
しかも、そのうち2件は、普段サイトを普通に見ているだけではまず気づかないような不具合でした。
「サイトが動いている」と「サイトの中が壊れていない」は別の話
現在、同じVPSでは3つの仕事が動いています。
- サイト監視係
26サイトを5分間隔で確認し、サイトが応答しなくなったらメール通知 - ドメイン期限チェック係
毎週、管理対象ドメインの期限を確認し、期限が近いものだけ通知 - 月次稼働率レポート係
毎月1日に前月の監視データを集計してメール報告
これで、
「サイトが落ちた」
「ドメイン期限が近い」
「先月どれくらい正常に動いていたか」
は自動で分かるようになりました。
ただ、これらの係では分からないことがあります。
たとえば、
サイトは普通に表示されているのに、本文中のリンクをクリックすると404になる。
こういう状態です。
サイト監視係から見れば、トップページは正常に応答しています。
緑ランプです。
でも利用者から見ると、
「詳しくはこちら」
を押したら404。
サービス紹介ページから別ページへ進んだら404。
ページ送りの「次へ」を押したら404。
サイト全体が落ちているわけではないので、死活監視だけでは検出できません。
リンク切れは、静かに増えていく
ホームページを長く運営していると、ページは少しずつ変わります。
新しいサービスを作る。
古いサービスを終了する。
記事を整理する。
URLを変更する。
不要な固定ページを削除する。
カテゴリー構成を変える。
その作業自体は正しくても、
以前そのページへ張っていたリンクだけが、別の場所に残る
ことがあります。
しかも、リンク切れが1つ発生してもサイト全体は普通に動きます。
運営者がたまたまそのリンクを踏まない限り、なかなか気づきません。
訪問者にとっても使いにくいですし、検索エンジンの巡回という意味でも、存在しないURLへのリンクを大量に放置したくはありません。
だから、
人間が思い出したときにチェックするのではなく、定期的に機械へ見回らせる。
これも同じVPSの仕事にしてしまうことにしました。
4人目は「リンク切れ巡回係」
AI社員へ伝えた条件は、大きく3つです。
- 週1回、サイト内を巡回する
- リンク切れや画像切れがあったときだけメールする
- チェックそのものがサイトへの負荷にならないようにする
特に3つ目は重要です。
将来的には自社サイトだけでなく、管理をお任せいただいているクライアントサイトへの展開も考えています。
リンク切れを調べるために短時間で大量アクセスし、相手のサーバーへ負荷をかけてしまったら本末転倒です。
そこでAI社員と相談しながら、かなり控えめな動きにしました。
「深夜に閲覧者が1人来る」くらいを目安にした
今回の設定では、
- ページを取得する間隔は約1.2秒
- 1サイトあたり最大150ページ
- 同じURLは何度も確認しない
- 外部リンクは本文全体を取得せず、軽い確認にとどめる
- 実行時間は深夜
という形にしています。
一気に数百ページへアクセスするクローラーではありません。
イメージとしては、
深夜に1人の訪問者が、ゆっくりサイト内を見て回っている程度
を目指しました。
初回テストでも150ページの上限まで巡回し、メールには「150ページ上限に到達（未巡回あり）」と明記されました。
つまり、無理に全ページを一度に取りに行くのではなく、決めた範囲の中で定期的に点検する設計です。
構築は今回もAIと一手ずつ
作り方は、第9・10話とほぼ同じです。
VPSへSSHで接続。
AI社員が次の作業を出す。
私がコマンドを貼り付ける。
結果を見せる。
問題がなければ次へ進む。
サーバー自体はすでにできています。
メール通知の仕組みも、第10話で作っています。
そのため、今回はゼロから環境を作る必要がありません。
AIがリンクチェック用のPythonプログラムを作り、既存サーバーへ設置していきます。
既存の仕組みを使ったら、一度だけエラーが出た
メール通知については、第10話で使った設定をそのまま流用することにしました。
ところが最初の実行で、
KeyError: 'SMTP_USER'
というエラーが出ました。
以前作った係と、今回AIが書いたプログラムで、環境変数の名前が違っていたためです。
新しくメール設定を作り直す必要はありません。
AI社員に現在の設定内容を見せると、
「既存の設定ではこの名前を使っているので、今回のプログラム側を合わせます」
という形で修正。
数か所の変数名を既存環境へ合わせるだけで動きました。
こういう場面を見ると、第10話で感じた、
「2つ目からは、前に作った仕組みを部品として使える」
というメリットがさらに大きくなってきます。
サーバーもある。
メール通知もある。
自動実行の仕組みもある。
4人目になると、新しく作る部分は「リンクを見回る仕事」そのものだけです。
着手から動作確認まで、約30分でした。
追加の有料サービスも契約していません。
初回テスト。自社サイトを巡回させてみる
まずはクライアントサイトではなく、自社サイトのpikoz.netだけで試します。
いきなり外部のサイトへ展開するのではなく、
まず自分のサイトで、本当に役に立つかを確認する。
これもこれまでのAI社員実践記と同じです。
プログラムを実行。
しばらく待ちます。
そしてGmailを見ると、メールが届いていました。
件名は、
「【リンク切れ】5件検出のお知らせ」
でした。
150ページを確認して、
HTTP 404が5件。
毎週のように記事を追加し、固定ページもかなり触っている自社サイトです。
「多少はあるかもしれない」
とは思っていました。
それでも、いきなり5件出てくるとは思っていませんでした。
初版メールには、大きな弱点があった
検出そのものは成功です。
メールには404になったURLが5件並びました。
ただ、見ていてすぐに問題に気づきました。
たとえば、
https://pikoz.net/○○○
が404だと分かっても、
そのURLがサイトのどこに張られているのかが分かりません。
リンク切れを直すには、
- 切れているURLを知る
- そのURLを張っているページを探す
- WordPressで該当箇所を開く
- リンクを修正する
必要があります。
1番しか自動化できていない。
これでは、修正のたびにGoogle検索やサイト内検索でリンク元を探すことになります。
せっかく機械に見回らせるなら、もう一歩欲しい。
そこでAI社員に、
「どのページからそのリンクが張られているのかも、メールに出してほしい」
と伝えました。
その場でプログラムを改良
AI社員は、巡回時に、
「どのページを見ているときに、そのURLを発見したか」
も記録するようプログラムを変更しました。
もう一度実行します。
届いた改良版がこちらです。
今度は404のURLだけでなく、その下に、
「リンク元」
が表示されています。
たとえば、
「このURLが切れています」
だけではなく、
「このページに、その切れたURLが張られています」
まで分かります。
こうなると、通知メールの意味が大きく変わります。
単なるエラー報告ではありません。
メールそのものが、そのまま修正指示書になります。
これはかなり使いやすくなりました。
5件を、その場で全部確認してみた
せっかくなので、検出された5件をそのまま放置せず、AIと一緒に原因を確認しました。
5件は大きく2種類に分かれました。
3件は、ページ整理のあとに残った古いリンク
3件は比較的分かりやすいものでした。
以前使っていたページを削除したり、別のページへ整理したりしたあとに、
リンクだけが別ページに残っていた
ものです。
具体的には、
- 受賞歴ページに残っていた旧URL
- サービス選び方ページに残っていた古い補助金ページへのリンク
- 業種別ガイドに残っていた削除済みページへのカードリンク
などでした。
改良版メールにはリンク元まで出ているので、該当ページを開いてリンクを変更。
不要ならリンクそのものを削除します。
1件あたり数分です。
リンク切れが発生したこと自体より、
これまで発見する仕組みがなかったこと
の方が問題だったのだと思います。
残り2件は、普通のリンク切れではなかった
残った2件が面白いものでした。
404になっていたのは、
- お知らせ一覧の7ページ目
- コラム一覧の190ページ目
です。
普通の固定ページではありません。
WordPressが自動で作っている一覧ページのページ送りです。
一覧の下に表示される、
「1 2 3 4 … 次へ」
のようなリンクです。
しかもページ送りには、ちゃんと「7」や「190」が表示されています。
つまり画面上では、
「そのページは存在します」
というリンクが出ている。
ところがクリックすると404。
これは単に「古いリンクを消し忘れた」という話ではありません。
記事数を数えても、ページ数は合っていた
AI社員と一緒に切り分けました。
まず、
「そもそも記事数が足りないのでは？」
と考えました。
でも記事数を確認すると、ページ数そのものは計算上おかしくありません。
テーマ側は、
「ここまでページがあります」
と正しく判断しているように見えます。
では、なぜWordPressは404を返すのか。
設定を一つずつ確認していきました。
そして行き着いたのが、WordPressの表示設定でした。
ここに、
「1ページに表示する最大投稿数 10件」
とあります。
一方、実際のサイトの一覧では、テーマ側が1ページに9件ずつ表示していました。
この「10」と「9」が原因でした。
「10件」と「9件」の1件差で、最後のページだけ404になった
たとえば記事が61件あるとします。
9件ずつ表示すれば、
61 ÷ 9
なので、7ページ必要です。
テーマは9件表示を基準にして、
「7ページ目があります」
というリンクを出します。
ところがWordPress本体の設定が10件なら、
61 ÷ 10
なので、WordPress側から見ると7ページ目は必要ありません。
結果、
テーマは「7ページ目があります」とリンクを出す。
WordPress本体は「そんなページはありません」と404を返す。
というズレが起こります。
コラム一覧でも同じことが起きていました。
設定の数字を、
10 → 9
へ変更して保存。
それだけで、2つの404は解消しました。
人間が普通に見ていたら、かなり見つけにくい不具合だった
この2件は、今回のリンク巡回係を作っていなければ、かなり長く残っていたと思います。
なぜなら、
一覧の最後のページまでページ送りを押していく人は、ほとんどいない
からです。
お知らせ一覧なら、1ページ目や2ページ目を見ることはあります。
でも7ページ目まで進むことは少ない。
コラム一覧の190ページ目なら、なおさらです。
普段サイトを更新している私自身も、そこまでクリックして確認することはありません。
一方、機械は違います。
ページ内にリンクがあれば、順番に確認します。
だから、
人間にはほとんど見えないけれど、機械が巡回すると見つかる404
を拾うことができました。
今回4人目に任せた仕事は、まさに機械向きだったと思います。
「見つける」だけで終わらず、その日のうちに直せた
朝にリンク巡回係の構築を開始。
初回実行。
5件検出。
メールを見て弱点に気づく。
リンク元も表示するよう改良。
もう一度実行。
5件の原因を確認。
WordPress側を修正。
その日のうちに5件すべて対応できました。
この流れで一番便利だったのは、
検出と修正が同じ会話の中でつながったこと
です。
AI社員はリンクチェッカーを作ったあと、
「では見つかった5件をどう直すか」
の相談相手にもなります。
ツールを作るAIと、エラーを分析するAIが別々ではありません。
作った仕組みの結果をそのまま見せて、
「これ、何が原因？」
と続けられる。
この連続性は、実際の業務ではかなり使いやすいと感じます。
毎週水曜の深夜3時に、自動で巡回
最後に、今回のリンクチェックも自動実行へ登録しました。
設定したのは、
毎週水曜日の午前3時。
訪問者が少ない時間帯です。
何もしなくても、週に1回リンク巡回係が起きます。
最大150ページを巡回。
リンク切れや画像切れを確認。
異常がなければ、何も言いません。
問題があった場合だけ、
リンク切れURL＋リンク元
をメールで送ります。
水曜日の朝、メールが来ていなければ正常。
来ていれば、そのメールを修正リストとして使う。
そんな状態になりました。
1台のVPSが4係体制になった
第9話から使い始めた1台のVPS。
現在は、4つの仕事をしています。
1人目：サイト監視係
26サイトを5分おきに確認。
落ちたときだけ通知します。
2人目：ドメイン期限チェック係
毎週、管理対象ドメインの期限を確認。
期限が近いものや、期限を取得できなかったものだけ通知します。
3人目：月次稼働率レポート係
毎月1日、前月分のサイト稼働率を集計して報告します。
4人目：リンク切れ巡回係
毎週水曜の深夜3時にサイト内を巡回。
404や画像切れがあれば、リンク元付きで知らせます。
すべて同じVPSです。
今回も、新しいサーバーを増やしていません。
外部の有料リンクチェックサービスも契約していません。
今回の追加費用は0円。
前に作った土台の上へ、また一つ仕事を増やしただけです。
4人目になると「作る」より「改善する」時間の方が長くなった
第9話で最初の監視係を作ったときは、サーバーそのものの準備から必要でした。
第10話では、既存サーバーと通知の仕組みを使い回せるようになりました。
今回の第11話では、さらにその傾向が強くなっています。
基本的な仕組みは約30分で動きました。
むしろ時間を使ったのは、
「検出メールにリンク元も欲しい」
という改善や、
「見つかった404の原因は何か」
という実務部分です。
つまり、環境を作る作業より、
どうすれば実際の仕事で使いやすいか
を考える時間の方が増えてきました。
これは、AI社員との仕事が少しずつ「構築」から「運用」へ移ってきたということかもしれません。
今回の結論
今回、AI社員と一緒に作ったのはリンクチェッカーです。
でも、一番印象に残ったのはリンクチェッカーが完成したことではありません。
作ったその日に、自社サイトの404を5件見つけ、その日のうちに全部直したこと。
です。
しかも、そのうち2件は、
WordPressの表示件数「10」と、
テーマの表示件数「9」という、
たった1つの数字のズレ
が原因でした。
人間がサイトを普通に閲覧していたら、かなり見つけにくい問題です。
今回改めて感じたのは、
「サイトが表示されている」ことと、「サイトの中に問題がない」ことは別
だということです。
人間が気をつけ続けるのではなく、
機械に定期的に見てもらう。
そして問題が見つかったときだけ、人間が判断して直す。
第9話から続けてきたVPS活用は、少しずつそんな役割分担になってきました。
サイト管理は「異常があったら知らせる」に変えていける
ホームページ管理には、小さな確認作業がたくさんあります。
- サイトが落ちていないか
- ドメイン期限は大丈夫か
- リンク切れはないか
- 画像が消えていないか
- 先月の稼働率はどうだったか
これを毎回、人が覚えて確認する必要はありません。
機械に定期巡回させ、問題があったものだけ人へ返す。
そうすれば、人間は「見る作業」ではなく、
判断すること、直すこと
に時間を使えます。
オフィスピコッツでは、こうした仕組みづくりも含めてホームページの運営をサポートしています。
「リンク切れがないか気になる」
「古いページをかなり整理した」
「ホームページを作ってから、しばらく全体点検をしていない」
という場合は、一度状態を確認してみるのもおすすめです。
- 運営サポート：https://pikoz.net/unei-support/
- AIレスキュー（スポット点検・修復）：https://pikoz.net/ai-rescue/
- 無料相談：https://pikoz.net/contact/
- AI社員実践記：https://pikoz.net/category/ai-jissen/
AI社員実践記は、まだ続きます。
京都産業21 登録専門家（No.46）／滋賀県DX協創パートナー／デジタル庁 デジタル推進委員。2002年開業、創業25年目。京都・滋賀を中心に1万件超のWeb活用・制作に携わる。 会社概要を見る