メインコンテンツへスキップ

会員画面が13時間消えていたのに、キャッシュは200を返し続けていた

自社プロダクト「カンタン補助金」で、公開フロントのビルドを単体で走らせたことにより会員向け画面がデプロイから丸ごと消え、13時間気づかれなかった。CDNのキャッシュが200を返し続けていた理由と、直前に検査を挟んだ手順を整理する。

自社プロダクト「カンタン補助金」で、公開フロントのビルドを単体で走らせてからデプロイしたところ、会員向け画面が丸ごと消え、約13時間気づかれなかった(出所: 自社の運用記録、確認日2026-09-06)。

この記事で分かること

  • なぜ会員向け画面が消えたのに一部のページは200を返し続けたのか
  • 切り分けを誤らせたものは何か
  • デプロイの直前にどんな検査を挟んだか

この記事で分からないこと(正直に書く)

  • 13時間のあいだに会員向け画面へアクセスしようとした利用者が何人いたか
  • 同種の合成ビルドを他のプロダクトでも見直す必要があるかどうか

何をしたか: 公開フロントのビルドを単体で走らせた

会員向けの画面は、公開フロントのビルド成果物に対して、別途ビルドした会員向けの成果物を後から所定のディレクトリへコピーする手順で組み立てられていた。ある時、公開フロントのビルドだけを単体で走らせ、コピー手順を経ないままその成果物をデプロイした(出所: 自社の運用記録、確認日2026-09-06)。

何が起きたか: 会員向け画面が全滅した

ビルドツールはビルドの成果物を書き出す前にその出力先を空にする性質を持っていた。会員向けの成果物は後工程でそこにコピーされる設計だったため、単体のビルドを挟むとその中身が丸ごと欠けたままデプロイされた。結果として会員向けのログイン画面を含む配下のページがすべて404になり、約13時間その状態が続いた(出所: 自社の運用記録、確認日2026-09-06)。死活監視は15分ごとに正しく異常を検知して通知していたが、対応されずに放置されていた。

なぜ気づけなかったか: CDNのキャッシュが200を作っていた

切り分けを誤らせたのはCDNのキャッシュだった。会員向け画面のトップやスクリプトの読み込みは直前のキャッシュが残っていたため200を返し続け、ログイン画面のURLだけが404になった。この現れ方だけを見ると、機能自体の不具合のように見え、デプロイの中身が丸ごと欠けているという実態には至りにくかった(出所: 自社の運用記録、確認日2026-09-06)。個別のデプロイごとに発行される確認用URLで見比べれば、正常なデプロイと壊れたデプロイの違いは数分で分かるが、通常運用で使う本番ドメインだけを見ているとキャッシュがその違いを隠してしまう。デプロイの管理画面に表示される連携元の情報も、あくまでビルドを走らせた作業ディレクトリの状態を示すだけで、実際にデプロイされた成果物の中身とは無関係だった。

どう直したか: デプロイ直前に中身を検査する手順を挟んだ

2026年9月、ビルドからデプロイまでを1つの手順にまとめ、成果物を書き出した直後に、会員向け画面の入り口ファイルと、それが参照するスクリプト・スタイルの実在を検査する工程を挟んだ。検査を通過して初めてデプロイへ進み、デプロイ後には公開直後のURLに対して主要な入り口が実際に200を返すかを確認する(出所: 自社の運用記録、確認日2026-09-06)。この手順を経ずにビルドツールを直接叩く運用はやめた。

再発防止: 「後から混ぜる」構成は混ぜる前が壊れやすいと考える

成果物を複数の工程に分けて合成する構成は、どれか1つの工程だけを単体で走らせても一見ビルドが成功してしまう点が危険である。何を検査に書けば次は見つかるかという観点では、デプロイの直前に成果物の中身を検査する工程と、キャッシュの影響を受けないデプロイ個別のURLで健全性を確認する習慣が効いた。

同じ移行を総当たりで実測した経緯は9件が壊れていた話、受け口そのものが死んでいた事例は問い合わせフォームが65日間405だった話にまとめている。監視の粒度の設計判断は、姉妹記事「監視の粒度を上げるほど費用になる理由」も参考にしてほしい。

自社のデプロイ手順や公開前検査の設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。

よくある質問

Q1. なぜ会員向け画面が消えたのに一部は200を返し続けたのか

会員向けのトップやスクリプトの読み込みはCDNの直前のキャッシュが残っていたため200を返し続け、ログイン画面のURLだけがキャッシュの無い404として現れた。

Q2. 死活監視は異常を検知していなかったのか

検知していた。15分ごとに正しく異常を通知していたが、対応が行われず約13時間その状態が続いた。

Q3. 何が切り分けを誤らせたのか

本番ドメインで見比べるとCDNのキャッシュが差を隠してしまう点。個別のデプロイごとに発行される確認用URLで見比べれば、正常なデプロイと壊れたデプロイの違いはすぐに分かる。

Q4. 再発防止のために何を挟んだか

ビルドからデプロイまでを1つの手順にまとめ、成果物を書き出した直後に入り口ファイルと参照先の実在を検査する工程と、デプロイ後に主要な入り口が実際に200を返すかを確認する工程を挟んだ。

関連する取り組み

CONNECTED SERIES
AIで投資の壁を越える
18 本の実装記録。AI 投資の「予測不能」と言われる 9 つの壁を、コードと実データで検証した連載。
note で読む →
B2B API
Persona API
行動データから再構成した 2,245 体のペルソナを LLM 推論に注入。AI 出力の文脈リッチ化、顧客 segmentation に。
詳細を見る →

AI導入のご相談を承っています

AI導入支援の実務経験を活かし、お手伝いしています。お気軽にご相談ください。

他のカテゴリも読む

AI最新ニュース AI業界の最新ニュースと企業動向 AI導入戦略 AI投資判断・ROI分析・導入ロードマップ 業界別AI活用 製造・金融・小売など業界別のAI活用動向 導入事例 企業のAI実装プロジェクト事例とコンサルティング知見 研究論文 NeurIPS、ICMLなどの注目論文レビュー