AI駆動開発の実運用ノート

本編の目次 › 第3部 実装→検証イテレーション › 検証の階段

AI駆動開発の実運用ノート No.76タイムゾーンなしのtimestampが集計を9時間ずらした

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第3部「実装→検証イテレーション」から、「検証の階段」のお話です。

失敗事例タイムゾーンのない時刻が集計を9時間ずらした

型チェックは通る——テストだけが捕まえられるバグがある
事故

ダッシュボードの「本日の売上」が前日の注文を含む。バッチ監視では偽の停止アラームも

根本原因

タイムゾーン情報を持たない列型 + ツールごとに異なる解釈。書き手が増えるたびに壊れる

ルール

新規は最初からタイムゾーン付き列型。境界の生成方法を NG/OK 例で固定

強制する仕組み

境界テストの義務化(月初直前/直後が正しい月に入るか)

四段目、通しのテストが捕まえた実例です。

ダッシュボードの「本日の売上」が、前日の注文まで含んでしまいました。 原因は、タイムゾーンの情報を持たない時刻の型と、ツールごとに違う解釈でした。

ここが第3部の技術的なポイントになります。

型チェックは通ります。 構造としては何も矛盾していないからです。これはテストだけが捕まえられるバグでした。

対策は単純で、新規なら最初からタイムゾーン付きの型を選びます。それだけでこの事故は丸ごと消えます。 Keihi はそう作ってあります。顛末は事例09に書きました。

つづく