個人サイトの『健康診断』をするクローラーを自作してみた

こんにちは。麗です。

自分のサイトを巡回して、リンク切れやSEOまわりの設定、本番環境の状態などをチェックする自分専用の健診クローラーを作ってみました。

最初はコマンドを実行するとMarkdownの健診票が出てくるだけだったのですが、最終的には「院内検査」と「往診」に分け、管理画面から結果を確認できる仕組みになりました。

今回は、なぜこれを作ろうと思ったのか、そして実際に作ってみて感じたことを書いていきます。

クローラー作りのきっかけ

少し前に、アクセス解析を自作したことや、そこでAIクローラーに興味をもったことを記事に書きました。

AIクローラーとは、Webサイトを自動で巡回し、ページの情報を読み取っていくプログラムのことです。

そこでふと思いました。

クローラーって、自分でも作れるのでは？？？

興味本位でChatGPTに相談してみたところ、他人のサイトを巡回するクローラーは、使い方によっては規約や倫理面を考える必要がありそうでした。

その一方で、自分のサイトだけを対象にしたクローラーなら問題ない ということが分かりました。

自分のサイト用のクローラーと言ってもさまざまな用途のものがあるようですが、私が興味を抱いたのは「サイトの健康診断」をする、というものでした。自分のサイトを巡回して悪いところを探してくれるクローラーです。

そうして、私のクローラー開発が始まりました。

「サイトの健康診断クローラーを作りたい」

今回も、実装にはClaude Codeを使いました。

最初から細かい仕様を全部コードで指定したわけではなく、

自分のサイトの健康診断をするクローラーを作りたい

と伝えるところからの相談です。

ここまでずっと「健康診断」に例えてやってきたため、その世界観をそのまま採用したものを作りたいと伝えました。

そうして決まったことは下記になります。

検査は大きく2種類です。

「クローラー」「静的ファイル検査」「HTTPチェック」と並べるより、個人的にはこちらのほうが何をしているのかイメージしやすくて気に入っています。

院内検査クローラーでできること

院内検査では、公開用に作られたファイルだけでなく、必要に応じて元のファイルも読み比べます。

たとえば今回の健診では、こんな項目を調べています。

SEOに関係する項目もありますが、それだけではありません。

「サイトを更新しているうちに、うっかり壊してしまいそうなところ」をまとめて見る検査に近いです。

ちなみに昨日の院内検査では70ページを検査し、リンク切れや孤立ページなど、要治療・要観察に分類される所見は0件でした。

また、単純にOK・NGを出すだけではなく、

といったものは**「参考所見」**として一覧にしています。

ここはあえて機械にOK/NGの判断はさせないようにしました。

たとえば本文が短いからといって、必ずしも悪いページとは限らないためです。

ゲームの実行画面なら文章がほとんどなくても当然なので、「200文字未満ならNG」のような基準を勝手に作らず、数字を並べるところまでを機械、人が判断するところは人と分けました。

往診クローラーでできること

一方の往診は、ファイルを見るだけでは分からないことを調べるものです。

実際にurara.devへHTTPリクエストを送り、本番環境が期待どおり動いているか確認します。

今回の往診では、たとえば次のような項目を確認しました。

こちらも今回、要治療・要観察の指摘は0件でした。

院内検査では「正しいファイルが用意されている」ことを確認できます。

でも、たとえばCloudflare側の設定が外れていたり、デプロイが本番まで届いていなかったりすると、ファイルだけ見ても分からないのです。

そこで、院内でカルテを見るだけではなく、実際の患者のところまで見に行くという意味で「往診」という名前を付けました。

往診における問題点

往診にはひとつ困ったことがあります。

本番サイトへアクセスするということは、当然ながら自分で作ったアクセス解析にも記録されるということです。

今回の往診では74回のGETリクエストを送っています。

そのまま実行すると、健康診断をするたびにアクセス数が数十件増えてしまいます。

そこで全リクエストに、

を付けるようにしました。

Cookieによって自分自身の健診アクセスを通常の集計から除外し、さらに万が一Cookieがうまく届かなかった場合でも、User-Agentにbotを入れておくことで、人間のアクセスとして数えられにくくしています。

健康診断するためのアクセスで健康状態の数字を変えてしまっては困るので、このあたりも仕組みに組み込みました。

健診クローラーを初めて動かしてみたら‥‥

ここまで書くと、なんだか最初から完成形が見えていたように見えるかもしれません。

でも、初期実装はかなり地味で、拍子抜けしてしまいました。

以上。

実際にはサイトの中を調べてくれているのですが、私から見えるものは、

「コマンドを打ったら、読む資料がひとつ増えた」

というだけでした。

正直、こうに思いました。

「……つまらない」

「クローラーがサイトを巡回する」と聞いていたので、私はどこかでもっと動いている実感のあるものを想像していたようです。

もちろん裏側ではちゃんと働いているのですが、それすらも一瞬なので、本当に読む資料がひとつ増えただけに見えてしまったんですよね。

でも、自分が触る道具としては、どうにも存在感がありませんでした。

健診クローラー専用管理画面の作成

それなら、結果を見る場所も健康診断らしくしてしまおう。

ということで、管理画面を作ることにしました。

管理画面から健診結果を確認できるようにしたことで、急に「クローラーを作った」という実感が出てきました。

やっている処理自体が大きく変わったわけではありませんが、ターミナルの向こう側にあったものが画面として見えるだけで、印象がかなり違います。

「画面があると、こんなに違うんだな」

と改めて感じた出来事です。

GitHub Actionsでクローラーを一部自動化

さらに、もうひとつ機能をつけ足しました。自動実行機能です。

現在、院内検査はGitHub Actionsを使い、週に1回、自動で実行するようにしています。

GitHub Actionsは、決めたタイミングでプログラムを自動実行してくれるGitHubの機能です。無料でもかなり使うことが出来ます。

往診の方は、手動実行にしました。

往診は本番サイトへ実際にアクセスする検査なので、自動で何度も動かすより、必要なときに自分で実行する形にしています。

アクセス解析から健診用アクセスを除外する仕組みは入れていますが、それでも本番へリクエストを送る処理であることに変わりはありません。

院内検査と往診で、役割だけでなく動かし方も分けることになりました。

クローラーが、ワクワクするものに変わった

今回いちばん印象に残ったのは、クローラーそのものの仕組みよりも、同じ処理でも見せ方によって自分の感じ方がかなり変わることでした。

最初のクローラーも、管理画面を作ったあとのクローラーも、サイトを調べて健診票を作るという基本的な仕事は同じです。

でも、

だけだったときと、

になったあとでは、私にとっては完全に別物になりました。

裏側で何かが動いているだけではなく、「自分のサイトを定期的に診てくれるもの」がそこにいる感じがしてきますね。

長く愛用していきたいからこそ、そういった、自分がちょっとワクワクする仕組みって大事だと思うんです。

クローラーに興味を持ったところから始まって、最終的にはサイトそのものを診てもらう仕組みになりました。

今後urara.devのページや作品が増えていっても、たまに健診票をのぞきながら育てていけそうです。