【BigQuery】AI生成SQLのタイムゾーン処理で発生した日付ズレの罠と解決策

はじめに

ChatGPTやGeminiなどの生成AIを使えば、複雑なSQLも一瞬で書いてくれる時代になりました。しかし、一見完璧に動いているように見えるクエリでも、特定の条件（時間帯）でのみ発覚するサイレントバグが潜んでいることがあります。

今回は、AIが生成したBigQueryのSQLで「日付フィルターが微妙にズレる」という現象に遭遇したトラブルシューティングの実例を紹介します。

発生した問題：8/4のデータなのに8/5指定で出てくる？

APIの期間指定フィルターをテストしていた際、奇妙な現象に気づきました。

2026-08-03 13:30 のデータ $\rightarrow$ 「8/3」で検索すると正常にヒット
2026-08-04 17:20 のデータ $\rightarrow$ なぜか「8/5」で検索しないとヒットしない（1日ズレる）

「8/3」のテストでは問題なく動いていたため、最初はAIの書いたSQLが正しいと思い込んでスルーしてしまっていました。

原因：AIが提案した「タイムゾーン変換」の罠

AIが生成したSQLの日付判定ロジックは以下のようになっていました。

-- AIが生成したコード
WHERE DATE(TIMESTAMP(res.end_date), 'Asia/Tokyo') >= DATE(@startdate)

一見、「日本時間（Asia/Tokyo）のDATEに変換していて正しそう」に見えます。しかし、ここにはBigQueryの仕様による大きな罠がありました。

なぜ15時以降だけズレたのか？

DB（res.end_date）に保持されていた文字列は、すでに**日本時間（JST）の 2026-08-04 17:20:15** でした。

TIMESTAMP('2026-08-04 17:20:15') 文字列にタイムゾーン表記（+09 など）がないため、BigQueryはこれを 「UTC（協定世界時）」 と解釈します。
DATE(..., 'Asia/Tokyo') 「UTCの 8/4 17:20」を日本時間に変換するため、さらに +9時間 加算されます。
結果: 8/4 17:20 + 9時間＝ 8/5 02:20（翌日になってしまった！）

なぜ 8/3 13:30 は正常に見えたのか？

13:30 に +9時間を足しても 22:30 となり、たまたま日を跨がなかったために表面上は正しく動いているように見えていたのです。（日本時間の15時＝UTCの6時以降のデータだけが日を跨いでバグになる）

解決策：文字列から直接日付を切り出す

DBに入っている値がすでに日本時間文字列であるならば、TIMESTAMP を噛ませてUTC解釈させる必要はありません。

-- 修正後：文字列の先頭10桁（YYYY-MM-DD）を取得して判定
WHERE SUBSTR(CAST(res.end_date AS STRING), 1, 10) >= @startdate
  AND SUBSTR(CAST(res.end_date AS STRING), 1, 10) <= @enddate

このように修正することで、15時以降のデータでも日付が一切ズレなくなりました。

まとめ：AI時代におけるエンジニアの役割

「たまたま動いたテストデータ」に騙されない（時間帯によって結果が変わるパターンがある）
AIはデータの背景（すでにJSTなのかUTCなのか）まで完全には把握できない
生成されたコードの暗黙の前提（TIMESTAMP() のデフォルト挙動など）を疑う姿勢が重要

AIは強力な相棒ですが、最後の品質担保や仕様との整合性チェックを行うのは人間のエンジニアの役割だと痛感した出来事でした。