自社プロダクト「カンタン補助金」の基盤を全面的に移行した2日後、公開機能を本番で総当たりに実測したところ、9件の欠陥が見つかった。9件すべてがHTTP 200系のステータスを返しながら壊れていた(出所: 自社の運用記録、確認日2026-09-06)。
この記事で分かること
- なぜ9件とも200系を返し続けたのか
- 総当たり実測で何を確認したのか
- 次に同じ移行をするときに検査へ書くべき項目
この記事で分からないこと(正直に書く)
- 9件以外にまだ見つかっていない欠陥が残っているかどうか
- 同種の移行を別の基盤で行った場合に何件になるか
何をしたか: 移行の2日後に全機能を総当たりで実測した
基盤を全面移行した直後は、ビルドとデプロイの成功しか確かめていなかった。2日後に、公開機能を本番環境に対して総当たりで実測する検証を行った。読み取り系は複数のロールを切り替えながら全件を叩き、書き込み系は作成から削除までの一巡を実際に通した(出所: 自社の運用記録、確認日2026-09-06)。
何が起きたか: 9件、すべて200系で沈黙していた
総当たり実測の結果、9件の欠陥が見つかった。内訳は3つの型に分かれる。既定値の設定方法の違いで新規作成だけが失敗する型、応答に含まれる項目名や配列の形が変わり画面側の処理が例外で止まる型、保存した状態が非同期処理側に渡らず同じ処理が繰り返し走る型である(出所: 自社の運用記録、確認日2026-09-06)。いずれも直接のエラー応答ではなく、200系を返しながら壊れていた。読み取り処理は保存済みのデータをそのまま返すため正常に見え、壊れているのは特定の操作だけという非対称な壊れ方だった。
なぜ気づけなかったか: 200は「読める」の証拠でしかない
200が返り続けた理由は単純で、読み取りの健全性と書き込みの健全性が別物だからである。一覧や詳細の取得は保存済みのデータをそのまま返すため、書き込みや非同期処理だけが壊れていても応答は変わらない。加えて、候補が0件で返る機能は「該当なしが正しい」のか「並び順の指定漏れで先頭しか見ていない」のかが応答だけでは区別できない。この移行では、ある候補選定機能がどの条件でも0件を返し続けていたが、0件という応答自体は異常を示さないため長く気づかれなかった(出所: 自社の運用記録、確認日2026-09-06)。
さらに自動テストが16件失敗していたが、原因はすべてテスト側の記述(文言の変更前後、旧パスワード、権限設定の不足など)だった。テストの失敗が製品の欠陥を意味するとは限らないため、原因を切り分けずに放置すると、本物の欠陥もテストの記述ミスも見分けがつかなくなる(出所: 自社の運用記録、確認日2026-09-06)。
どう直したか: 総当たりの手順を検査として固定した
2026年9月、次を検査の手順として固定した。読み取り機能を複数のロールで実際に叩き応答の中身まで確認すること、書き込み機能は作成・取得・更新・削除を一巡させ作成したデータは都度削除すること、候補が0件で返る機能は個別に条件を疑うこと、応答の解析に失敗した際に空の結果へ握りつぶす実装を外すこと、検証用アカウントが対象機能の権限条件を満たしているか先に確認することの5点である(出所: 自社の運用記録、確認日2026-09-06)。テストの失敗も原因不明のまま放置せず、検証できない場合は理由を明記してスキップする運用にした。
再発防止: 「200が返る」を健全性の証拠にしない
この一件から得た教訓は、200という応答そのものを検査の合格条件にしないことである。何を検査に書けば次は見つかるかという観点では、応答コードではなく応答の中身と、書き込みの一巡が実際に成立するかを見る検査を残すことが効いた。移行直後は、ビルドの成功やデプロイの完了ではなく、機能を実際に動かした結果で健全性を判断する必要がある。
既定値の消失だけを深掘りした記事は既定値がSQLに移らなかった話、200を返しながら人間には表示されていなかった別の事例はcurlでは見えない白紙ページの話にまとめている。監視の粒度の設計判断は、姉妹記事「監視の粒度を上げるほど費用になる理由」も参考にしてほしい。
自社の基盤移行や本番検証の設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. なぜ9件とも200系を返し続けたのか
読み取り処理は保存済みのデータをそのまま返すため、書き込みや非同期処理だけが壊れていても応答コードには影響しなかった。候補が0件で返る機能も、0件という応答自体は異常を示さないため見分けがつかなかった。
Q2. 総当たり実測では具体的に何を確認したのか
読み取り機能を複数のロールで全件実測し、書き込み機能は作成から削除までの一巡を実際に通した。応答コードだけでなく応答の中身を確認した。
Q3. 自動テストが失敗していたのは製品の欠陥だったのか
16件の失敗はすべてテスト側の記述(文言の変更前後、旧パスワード、権限設定の不足など)が原因で、製品側の欠陥ではなかった。ただし放置せず、原因を都度切り分けている。
Q4. 次に同じ移行をする場合、何を検査に加えるべきか
応答コードを合格条件にせず、読み取りの中身の確認、書き込みの一巡、0件応答の個別確認、パース失敗を握りつぶさないこと、検証用アカウントの権限確認の5点を検査手順として固定した。