「明日の9時」をそのまま予約しない、AI自動化の時刻意図票

「明日の9時に顧客へ連絡して」とAIへ頼んだとき、どの地域の明日か、休日ならどうするか、障害復旧後も送るかが曖昧です。業務自動化の責任者向けに、自然言語の日時を安全な実行条件へ変える「時刻意図票」を作ります。

時刻を一つの文字列で渡さない

実行日時には、少なくとも「人が意図した現地時刻」「世界で一意な実行時刻」「実行してよい幅」があります。RFC 3339は、時刻をUTCとの数値オフセット付きで表し、オフセットのない現地時刻は相互運用上問題になると説明しています。[1] ただし、2026-11-02T09:00:00+09:00だけでは「東京の毎朝9時」という業務ルールを再計算できません。

そこで、保存時にはRFC 3339の確定時刻とAsia/Tokyoのような地域名を両方持ちます。IANAのTime Zone Databaseは、地域ごとのUTCオフセットと夏時間の履歴を持ち、制度変更に応じて更新されます。[2] 固定オフセットだけを長期予定へ使わず、どのtzdb版で解決したかも記録します。

コピーして使える時刻意図票

AIは日時候補を作れますが、最終的な解決は決定的な時刻ライブラリと会社の営業日カレンダーで行います。

time_intent:
  intent_id: reminder-20261018-042
  requested_text: "次の営業日の朝9時"
  requested_at: "2026-10-18T16:50:00+09:00"
  zone: "Asia/Tokyo"
  calendar: "jp-office-2026-v3"
  policy:
    holiday: "move_forward"
    ambiguous_time: "later_offset"
    nonexistent_time: "reject"
  resolved:
    local: "2026-10-19T09:00:00"
    offset: "+09:00"
    utc: "2026-10-19T00:00:00Z"
    tzdb_version: "2026e"
  execution_window:
    opens_at: "2026-10-19T08:55:00+09:00"
    expires_at: "2026-10-19T09:15:00+09:00"
  retry:
    max_attempts: 2
    after_expiry: "manual_review"

requested_atを残すのは、「明日」を後から再解釈しないためです。calendarは祝日だけでなく会社休業日も版管理します。実行窓を過ぎた処理は、遅れてでも送るのか、人へ戻すのか、破棄するのかを業務ごとに固定します。

5段階で自然言語を実行条件へ変える

1. 基準時刻を固定する

依頼を受けた瞬間の時刻、利用者の地域、入力元を保存します。「今日」「月末」はこの時点で絶対日付へ変え、再試行時に解釈し直しません。

2. 業務語を分解する

AIには、日付候補、時刻、地域、営業日条件、締切との関係だけを構造化させます。「早め」「頃」など許容幅が決められない語は、自動予約せず質問へ戻します。

3. 決定的に解決する

時刻ライブラリ、IANA地域、営業日カレンダーを使い、現地時刻、UTC、オフセットを計算します。存在しない現地時刻、二度現れる時刻、更新されていないカレンダーはエラーとして扱います。

4. 実行窓と失効を付ける

通知なら数分の幅、価格変更なら開始時刻ぴったりなど、業務影響に合わせて窓を決めます。AWS EventBridge Schedulerにも、指定時刻後の一定範囲で実行する柔軟な時間枠と、再試行回数・保持時間を設定する仕組みがあります。[3] 製品機能の有無にかかわらず、再試行が期限を越えない設計にします。

5. 実行直前に再判定する

ワーカーはopens_at <= now < expires_at、未実行、対象状態が未変更であることを確認します。期限切れなら同じ操作を送らず、時刻意図票と失敗理由を人の確認へ渡します。

仮想例：障害復旧後の督促メール

【仮想例】経理担当者が日曜16時50分に「次の営業日の朝9時、未入金なら督促」と依頼しました。システムは東京時間、会社カレンダー、8時55分から9時15分の実行窓を保存します。月曜9時にキュー障害が起き、10時に復旧しました。

古い設計なら復旧直後にメールを送ります。時刻意図票を使う設計では、まず期限切れで停止し、入金状態を再確認して人へ戻します。完了条件は、期限内なら一度だけ送信してメッセージIDを保存し、期限外なら未送信のままレビュー案件が作られることです。

時刻に業務上の意味がなく、いつ処理しても結果が変わらないという場合には向きません。記録と再判定の費用が増えるためです。一方、送信、公開、価格変更、権限失効、締切処理には、遅延時の扱いまで含めて適用します。

明日から使える実装チェックリスト

[ ] 相対日時を依頼受信時に絶対日時へ変える
[ ] IANA地域名とRFC 3339時刻を両方保存する
[ ] 営業日カレンダーとtzdbの版を記録する
[ ] 曖昧・存在しない現地時刻の規則を決める
[ ] 実行窓と失効後の処理を分ける
[ ] 再試行回数より先に失効時刻を判定する
[ ] 実行直前に対象状態と重複を確認する
[ ] DST前後、祝日、障害復旧後をテストする

明日は一つの予約処理で、実行前、実行窓内、期限切れの三状態を再現してください。期限切れのジョブが勝手に実行されず、理由付きで人へ戻れば、時刻の安全境界は機能しています。

参考資料

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-18。