自動化は反復作業を減らせますが、鮮度、正確性、適切さを保証しません。AIの要約も検証が必要な案です。
数値の根拠を残す
使用データと数値を照合し、期間、単位、フィルタ、計算バージョンを保存します。重要な計算は独立に確認します。欠損を架空の値で埋めたり、予測を観測結果として示したりしません。
エラーと確認を設計する
確認者、受信者、修正担当を決めます。部分失敗を明示します。最後の正常なレポートは再送しても新しくなりません。内容と宛先を確認し、普遍的な効果を約束せず実際の節約を測ります。
| 項目 | 記録する確認内容 |
|---|---|
| 数値 | 出典、式、範囲を追跡可能 |
| AI要約 | 主張と限界を確認 |
| 配信 | 状態と受信者を確認 |
出典と確認
- NIST — Generative AI Profile, confabulation and evaluation
- Government Analysis Function — Communicating uncertainty
タイムゾーンと遅延イベント
報告期間はイベント時刻と締め規則に依存します。
- イベント時刻、受信時刻、業務のタイムゾーンを別々に記録します。架空例では23:30 UTCは固定オフセットUTC+02:00で翌日の01:30です。PostgreSQLのタイムゾーン付きタイムスタンプは元のゾーン名を保持しません。
- 開始を含め、終了を含めない区間を使います。業務ゾーンで境界を決めてからUTCに変換します。夏時間の変更、月の切替、時刻のない日付を試します。現地の一日を常に24時間として扱うことはできません。
- 許容遅延と集計の締切を決めます。同じ識別子を再処理し、新規イベントと重複を区別します。公開版を残して訂正の影響を記録します。ウォーターマークは到着の見積もりであり、完全性の保証ではありません。
再現できる受け入れ事例
架空の例です。顧客や実際の観測結果を示すデータではありません。
事例の入力を見る
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}期待される判断
指定の時間帯では10月9日のイベントです。UTCの時点も保持します。
検証手順
- 報告の時間帯と基準時点を定めます。
- 深夜付近のイベントを再現します。
- UTC、現地日付、締切規則を残します。 時刻変更時の曖昧な現地時刻も含め、時点を推測せずオフセットとタイムゾーンを保存します。
受信日をイベント日として使えますか？
レポートの定義がそう求める場合に限ります。両方の時刻を保存し、遅着イベントの扱いを説明します。
一次資料：PostgreSQL — Date/time types. 関連する方法：実践ガイドを読む.