寝る前に実行すること

毎晩、ノートパソコンを閉じる前に1つのコマンドを実行します。本番サイト全体の15,000ページをチェックするコマンドです。すべてのブログ記事、すべての企業ページ、すべてのプログラマティックガイド、すべてのロケールバリアント。各ページについて、HTTPステータスの確認、TTFBの計測、Cloudflareのキャッシュステータスの確認、エラーのログ記録を行います。包括チェックの完了には約6時間かかります。寝ている間にバックグラウンドで実行されます。

加えて、2分で完了するクイッククリティカルパスチェックも実行します。ヘルスエンドポイント、サイトマップ、収益ページ、S-tierの企業ハブ、マーケットページ、プログラマティックコンテンツインデックス、i18nブログアーカイブ。こちらは見届けます。何か失敗があれば、寝る前に調査します。

このルーティンが生成するレポートは以下のようなものです：

NIGHTCHECK -- 2026-03-27 (morning)
Overnight comprehensive: 16,228/16,602 ok (97.7%)
Avg TTFB: 715ms
S-tier companies: ALL PASS, ALL HIT
Markets: ALL PASS (89-175ms HIT)
i18n blogs: es 95ms HIT | ja 196ms HIT | de 181ms HIT

誰かに頼まれてやっているわけではありません。チケットに「nightcheckを実行」とは書かれていません。スプリントにも含まれていません。このルーティンが存在するのは、自分が見ていないときにサイトが動いているかどうかを気にかけているからです。

なぜ毎晩なのか

サイトは毎日変わります。1日で87件のコミットをデプロイすることもあります。i18n翻訳、クロールプロバイダーの更新、CRO実験、パフォーマンス修正、ロゴの修正。各コミットは個別にテストされています。しかし、87件のコミットの組み合わせが、個々のコミットでは見えない障害を引き起こすことがあります。

翻訳バッチがブログサイトマップをレンダリング閾値の限界まで押し上げるかもしれません。新しいプロバイダーがレンダリングに14秒かかる企業ページを生み出すかもしれません。キャッシュヘッダーの変更により、それまで高速だったルートをCloudflareがキャッシュしなくなるかもしれません。CSSのリファクタリングが、ある1つのロケールだけでテンプレートを壊すかもしれません。

nightcheckは合成障害を検出します。「このコミットが何かを壊したか」ではなく、「今日のすべてが反映された後、サイトは動いているか」を確認するのです。この違いは重要です。合成障害はCIでは見えないからです。各コミットはそれぞれのテストに合格します。しかし、87件のコミットがそれぞれのテストに合格したからといって、システム全体が動作する保証にはなりません。

何を計測しているのか

チェックには4つの層があります：

P0 インフラストラクチャ。 ヘルスエンドポイントがデータベース接続済みでhealthyを返すこと。サイトマップが有効なXMLを返すこと。robots.txtとllms.txtが存在すること。RSSフィードが有効であること。これらが壊れると、検索エンジンからサイトが見えなくなります。

P0 収益。 ホームページ、レジュメビルダー、アナライザー、料金ページがすべて読み込まれること。壊れれば直接的な損失につながるページです。レジュメビルダーは歴史的に最も遅いページであり、5秒でWARN閾値が設定されています。

P1 SEOサーフェス。 ブログアーカイブ、ピラーハブページ、企業ディレクトリ、求人ブラウズ、5つのプログラマティックコンテンツインデックス（レジュメガイド、給与ガイド、カバーレターガイド、面接質問、ATSキーワード）、4つのi18nブログサンプル、そして20のS-tier企業ハブすべて。これらはオーガニックトラフィックを生み出すページです。Googleの企業ページでの404はSEOインシデントとなります。

P2 包括チェック。 ブログと企業サイトマップに含まれるすべてのURL。これが6時間のバックグラウンドチェックです。ロングテールの障害を検出します。不正な引用によって500エラーを返す1つのブログ記事、大規模な企業でのN+1クエリによってタイムアウトする企業ページなどです。

各ページはリアルなUser-Agentヘッダーを付けたcurlでチェックされます。素のcurlではCloudflareに403されます。キャッシュステータスヘッダーは、HTTPステータスやTTFBとともに記録されます。ページが200を返していても、HITであるべきところがDYNAMICになっていれば、キャッシュルールの設定ミスを意味します。TTFBの計測値はブラウザのレンダリング時間ではなく、実際のサーバーサイドのレイテンシです。

TTFBのトレンド

このチェックは2026年3月から実行しています。TTFBのトレンドがパフォーマンスの物語を語ります：

このトレンドはマーケットページのパフォーマンス改善の旅を記録しています。キャッシュパージが問題を露呈させ（14.3秒）、エッジキャッシュがそれを覆い隠し（89-175ms HIT）、クエリ形状の修正が根本原因を解消しました（108msオリジン）。毎晩のトレンドがなければ、エッジキャッシュが修正だと思い込んでいたでしょう。TTFBの計測値が、リバリデーション時のオリジンレンダリングがまだ遅いことを証明し、クエリのリファクタリングを正当化しました。

nightcheckがパフォーマンスの問題を修正したのではありません。問題を計測可能にし、それによって修正可能にしたのです。

誰にも見えないもの

nightcheckの最も価値ある点は、誰も見ていないときに実行されることです。「16,228ページが一晩で合格しました」というSlack通知はありません。緑に変わるダッシュボードもありません。レポートはログファイルに存在し、翌朝コーヒーを飲みながら読みます。

儀式がないことが要点なのです。nightcheckはパフォーマティブな品質管理ではありません。スタンドアップのための指標でもありません。私的な規律です。寝ている間、すべてが動いていたか？動いていたなら良し。動いていなかったなら、何が、いつ壊れたかが正確にわかります。

規律は複利で効いてきます。毎晩のチェックが翌日の比較のためのベースラインを確立します。特定のページでTTFBが50ms増加すれば調査のトリガーになります。50msがユーザーにとって重要だからではなく、増加が何かが変わったことを示すからです。新しい依存関係がレイテンシを追加したのかもしれません。キャッシュルールが期限切れになったのかもしれません。データセットの成長とともにデータベースクエリが遅くなったのかもしれません。毎晩のベースラインがあるからこそ、問題になる前にドリフトが見えるのです。

これは複利的コンテキストを運用に適用したものです。毎晩のチェックがデータポイントを蓄積します。データポイントがトレンドに積み上がります。トレンドが、単一のチェックでは見えない問題を可視化します。

ルーティンこそが基準

nightcheckをcronジョブに自動化してダッシュボードを確認するだけにすることもできます。あえて手動で実行することを選んでいるのは、実行する行為自体が「気にかける」という習慣を維持するからです。チェックが他の誰かの仕事になった瞬間、あるいは却下する通知になった瞬間、確認しなくなるダッシュボードになった瞬間に、基準は崩れます。

基準は「サイトが自動チェックに合格する」ことではありません。基準は「寝る前に自分自身でサイトが動いていることを確認した」ことです。違いはアカウンタビリティにあります。静かに失敗する自動チェックは自動化のバグです。スキップした手動チェックは、何を大事にするかについての自分自身の選択です。

毎晩実行するのは、代わりの選択肢がすべてまだ動いていると信じることだからです。検証のない信頼は希望にすぎません。希望は運用戦略ではありません。

FAQ

フルチェックにはどのくらいかかりますか？

クイッククリティカルパスチェックは2〜3分です（36ページのTTFBとキャッシュ計測）。包括的なサイトマップチェックは5〜7時間です（15,000ページ以上）。クイックチェックは同期的に実行され、包括チェックはバックグラウンドで実行されます。

アップタイム監視サービスを使わないのはなぜですか？

アップタイムサービスはページが200を返すかどうかをチェックします。nightcheckは、ページが正しいキャッシュステータス、許容範囲内のTTFB、期待されるコンテンツ構造とともに200を返すかどうかをチェックします。200を返しているが14秒かかりDYNAMICキャッシュのページは、技術的には稼働中ですが、運用上は壊れています。

何かが失敗した場合はどうしますか？

収益ページまたはインフラストラクチャページの障害であれば、寝る前に調査します。包括チェックの障害については、翌朝ログを確認し、ページタイプ別に優先度をつけます。ブログ記事の障害は企業ハブの障害より優先度が低くなります。高トラフィックページでのDYNAMICキャッシュは、低トラフィックページでの遅いTTFBより優先度が高くなります。

スケールしますか？

現在のスケールは15,000ページです。包括チェックはI/Oバウンド（シーケンシャルなcurlリクエスト）であり、コンピュートバウンドではありません。ページ数が倍になれば実行時間も倍になります。30,000ページになると約12時間かかりますが、一晩のウィンドウには収まります。それ以上になれば、レートリミット付きの並列チェックが必要になるでしょう。