動画で見る（3分33秒）
章から見る
動画の台詞を読む
部長：最近、問い合わせが、静かなのよね。平和でいいわ
トラ猫：……そのフォーム、最後に、自分で送ってみたのは、いつですか
部長：え？ 送ったこと、ないわよ
トラ猫：編集部の製品では、問い合わせフォームが、65日間、送信を、受け付けていませんでした
部長：65日？
トラ猫：しかも、その間、監視は、ずっと、正常、と言っていたんです
問い合わせと、登録の入口が、気づかれずに止まっていた、2つの記録です。
トラ猫：きっかけは、サイトのドメインを、移したことです
トラ猫：移した後、フォームの送信を受け取る所が、ずれて、送信そのものが、受け付けられなくなりました
トラ猫：送ると、405。この送り方は、受け付けません、という返事です。データベースには、1行も、残りません
部長：それが、65日間も
トラ猫：はい。65日間です
部長：でも、監視は、あったんでしょ
トラ猫：ありました。見ていたのは、まだ知らせていない問い合わせの、件数です
トラ猫：送信が1件も届かないので、件数は、ずっと0件。監視は、正常、と出し続けました
部長：0件なら、平和ってことじゃない
トラ猫：そこが、落とし穴です。0件は、問い合わせが無いのか、届いていないのか、データベースからは、区別できません
部長：うちの、最近静か、と、同じね
トラ猫：65日間で、何件を取りこぼしたかは、分かりません。記録が、1行も、残っていないからです
部長：……分からないのが、一番、こわいわ
トラ猫：もう1つ。別の製品では、企業情報の、新しい登録が、2日間、100%、失敗していました
トラ猫：原因は、基盤の移し替えで、1つの項目の、決まった値の設定が、抜けたことです
トラ猫：それでも、一覧や詳細の画面は、普通に開けます。返事は200。正常です
トラ猫：エラーも、途中で握りつぶされて、数は、0件のまま
部長：誰が、気づいたの
トラ猫：最初の、お客様からの、問い合わせです
部長：……お客様が、監視だったのね
部長：じゃあ、何を、見ればよかったの
トラ猫：2つとも、監視は、届いた物の中を、数えていました。入口が閉じると、中には、何も来ません
トラ猫：編集部は、2026年9月に、本番の問い合わせの入口へ、本当に送信する監視を、足しました
トラ猫：テストだと分かる印を付けた1件を、定期的に送って、届いたかを、確かめます
部長：うちで、できることは？
トラ猫：まず、今日、自社のフォームから、自分で1件、送ってみてください。届いたかを、見ます
トラ猫：サイトの引っ越しや、作り直しをした日は、特にです
トラ猫：そして、テストの印を付けて、定期的に送る仕組みを、作ってもらう
部長：……最近、問い合わせが静かなの。平和だと、思ってたわ
トラ猫：本当に静かなのか、届いていないのか。送ってみれば、分かります
部長：今から、うちのフォームに、送ってみる
トラ猫：はい。1件で、分かります
あなたの会社のフォーム、今、届きますか。記事は、AIコンパス、問い合わせフォーム、405、で検索。
自社プロダクト「Studel」の問い合わせフォームが、ドメインの移設をきっかけに65日間405を返し続けていた(出所: 自社の運用記録、確認日2026-09-06)。
この記事で分かること
- なぜデータベースの件数監視では受け口の故障を検知できなかったのか
- 何を監視に足せば次は見つかるか
- SREの監視分類のどこにこの故障が当てはまるか
この記事で分からないこと(正直に書く)
- 65日間で実際に取りこぼした問い合わせの件数(原理的に復元不可能)
- 同種の受け口が他のプロダクトに残っていないかどうかの全数確認
何をしたか: ドメインを移設した
問い合わせフォームを含む配信環境のドメインを移設した。この移設によって、フォーム送信を受け取る処理の配置がずれ、送信そのものが受け付けられなくなった(出所: 自社の運用記録、確認日2026-09-06)。
何が起きたか: 65日間、送信が消え続けた
移設後、問い合わせフォームへの送信は405を返し続けた。データベースには送信の行が一切増えないため、「未通知の件数を数える監視」は常に0件を示し、それが正常なのか、そもそも届いていないのかをデータベース側からは区別できなかった(出所: 自社の運用記録、確認日2026-09-06)。取りこぼした件数は原理的に復元できない。
なぜ気づけなかったか: 「受け取ったものの異常」しか見ていなかった
監視が見ていたのは「受け取った送信の中に異常があるか」だった。受け口そのものが機能しているかどうかは対象に入っていなかった。米Googleが公開しているSREの監視の考え方では、監視を症状に基づくブラックボックス型と、内部の状態を調べるホワイトボックス型に分け、エラーの指標については「明示的な失敗だけでなく、200のような成功応答でありながら中身が誤っているものも含めて捉える」という考え方が示されている(出所: Google SRE Book「Monitoring Distributed Systems」、https://sre.google/sre-book/monitoring-distributed-systems/、確認日2026-09-06)。今回の受け口は、そもそも応答そのものが405だったにもかかわらず、後段のデータベース側の指標だけを見ていたために「システムが今まさに動いていない」という症状を直接捉える監視が存在しなかった。
どう直したか: 本番へ実際に送信する合成監視を置いた
2026年9月、本番の問い合わせエンドポイントへ実際に送信し、テストである旨を含む行を残す合成監視を追加した。データベースの件数だけを見る監視と併用し、受け口そのものの生死を外側から定期的に確認する形にした(出所: 自社の運用記録、確認日2026-09-06)。
再発防止: 受け口には外から叩く検査を足す
問い合わせ・申込・予約・登録のような受け口は、内部の記録が増えないこと自体では故障と区別がつかない。何を検査に書けば次は見つかるかという観点では、データベースの件数監視に加えて、本番エンドポイントへ実際にリクエストを送る合成監視を置くことが効いた。デプロイや配信構成を変えた直後は特に、この外側からの検査を欠かさないようにしている。
会員向け画面がデプロイから丸ごと消えていた事例は会員画面が消えていた話、人間には白紙だったページの事例はcurlでは見えない白紙ページの話にまとめている。監視の粒度の設計判断は、姉妹記事「監視の粒度を上げるほど費用になる理由」も参考にしてほしい。
自社の受け口監視や合成監視の設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. なぜデータベースの件数監視では検知できなかったのか
送信が受け付けられずデータベースに行が一切増えないため、「未通知件数」を見る監視は常に0件を示し続けた。0件が「異常が無い」のか「そもそも届いていない」のかを区別できなかった。
Q2. SREの監視の考え方とはどう関係するか
Google SRE Bookは、症状に基づくブラックボックス型監視と内部状態を見るホワイトボックス型監視を分け、エラーの指標には成功応答でも中身が誤っているものを含めるべきだとしている。今回はその成功応答にすら至らず405を返していたが、受け口そのものの症状を直接見る監視が無かった。
Q3. 取りこぼした問い合わせは後から分かるのか
分からない。データベースに記録が一切残らないため、65日間で実際に何件を取りこぼしたかは原理的に復元できない。
Q4. 再発防止のために何を追加したか
本番の問い合わせエンドポイントへ実際に送信し、テストである旨を含む行を残す合成監視を追加した。データベースの件数監視と併用し、受け口そのものの生死を外側から確認できるようにした。