上海の月曜朝9時、日報が予定どおりに届く。見出しは「昨日の実績」。しかし数字の元は、まだ終わっていないロサンゼルスの日曜日だ。丸一日同士を比べたつもりが、完成した一日と途中の一日を比較している。
定時に起動したことと、データがそろったことは別である。 AI自動化のタイムゾーンは実行時刻を決める。データ元がどこで一日を区切るか、報告をどの業務日に帰属させるかまでは決めない。
BudaではSkillが方法、Automationが実行時点を定める。日付判断を方法に含めてから、時刻を考えたい。
三つの時計に名前を付ける
- 起動の時計：
Asia/Shanghaiの月曜09:00など、IANAタイムゾーンと実行時刻。 - データ元の暦：
America/Los_Angelesの午前0時から翌日0時など、元データの日付境界。 - 報告の業務日： チームが報告を保存する日付と、その報告で比較したい実際の範囲。
業務日は取得日時ではなく、元データの日付の別名でもない。上海の月曜報告でロサンゼルス土曜の確定データを使うことはできる。ただし締め日を明示する。見出しを変えても日曜実績にはならない。
朝9時には、元データの日曜日が終わっていない
以下は架空の社内日報で、時刻換算には実際のIANA規則を使う。実際のBuda実行記録や、提供元の固定的な公開遅延を示すものではない。
2026年10月19日月曜、上海09:00は、ロサンゼルス10月18日日曜18:00に相当する。日曜日はあと6時間ある。終了は上海月曜15:00だ。
| 上海 | ロサンゼルス | 日曜データの判断 |
|---|---|---|
| 10月19日09:00 | 10月18日18:00 PDT | 暦日が未終了 |
| 10月19日15:00 | 10月19日00:00 PDT | 暦日は終了。ただし入庫完了とは限らない |
| 提供元が完了を確認後 | 実際の状態を確認 | 根拠がある場合に完全性を受け入れる |
元の範囲は America/Los_Angeles の [2026-10-18 00:00, 2026-10-19 00:00) とする。上海では [10月18日15:00, 10月19日15:00)。終端を含まない半開区間なら、23:59:59以降の端数の扱いで迷わない。
上海の「暦の昨日」は18日00:00から19日00:00。月曜09:00から過去24時間なら18日09:00から19日09:00である。この三つは異なる。単に「昨日」とせず、範囲と時区を表示する。
実行ごとに日付の契約を渡す
「毎朝9時に昨日を分析」では判断材料が足りない。入力やSkillに次を記録する。提案する契約であって、Buda標準のロックや完全性保証ではない。
報告業務日：2026-10-19、Asia/Shanghai
起動予定：09:00、Asia/Shanghai
データ元：許可済みロサンゼルス運用データ
元の日付：2026-10-18、America/Los_Angeles
範囲：[10-18 00:00, 10-19 00:00)
比較：同じ定義の一つ前の完全な元データ日
data-through：提供元が実際に返した最新日付
完全性：提供元で確認。不明ならnullであり0ではない
最早時点：上海15:00以降。入庫遅延は別途確認
業務キー：データ元ID＋元の日付＋報告種別＋版
要確認：遅延、修正方針、待機/partialを決める責任者
キーは既存成果を探す手掛かりであり、厳密に一度だけ動くロックではない。修正版を作るなら旧版と置換関係を残す。提供元の更新、対象期間の締め、報告生成の日時を一つのupdatedAtにまとめない。
イベント時刻と取込時刻のどちらで抽出するかも確認する。時差換算では遅着や後日の補正は解消できない。暦日が終わっても数値が修正される場合がある。
未終了の日を完全な日報にしない
架空の月曜09:00では責任者が二つの出力を選べる。
- 対象日の完了を待つ。 「ロサンゼルス18日は上海15:00まで未終了。入庫完了時刻は要確認」と明示する。これは状態報告であり、完成した日曜実績ではない。
- partialで渡す。 土曜までの完全データを本当に確認できた場合だけ、報告業務日19日、元データ締め17日ロサンゼルス、日曜未完と書く。異なる長さの窓で日次増減を計算しない。確認済みの完全日がなければ数字を補わない。
待機という判断は、自動停止、再試行、再予約が行われるという意味ではない。追加実行には別の権限と方法の確認が必要である。
夏時間では、固定時差ではなく地域名を使う
2026年11月2日月曜の上海09:00は、ロサンゼルス日曜17:00、PSTになる。日曜日の終了は上海16:00で、10月の15:00とは違う。
America/Los_Angeles を保持し、日付ごとに換算する。「上海から15時間引く」を永久ルールにしない。10月例は15時間、11月例は16時間差。上海09:00の起動自体は変わらない。
夏時間地域の早朝には存在しない、または二度現れる時刻もある。調度器の具体的な扱いを日付付きで確認するまで、毎回一度だけ起動すると約束しない。
予約せず、三つの入力で方法を確認する
| 推奨確認 | 状態 | 期待する出力 |
|---|---|---|
| 正常 | 暦日終了かつ提供元が完全性を確認 | 業務日、対象範囲、締め日、比較可能な前窓 |
| 遅延 | 終了したが未確定、または欠損 | 待機/partialと具体的不足。不明を0にしない |
| 重複 | 同キーの成果あり、または前回送信が不明 | 既存版と状態を調べ、再送前に判断を求める |
未実行の検収案であり、成功済みのテストではない。実入力、出力、責任者の判断を残す。ファイルの存在だけでは送信済みと証明できない。
日付で迷いやすい点
データ元に時区がなければ推測できる？
できない。どのイベントを含むかが変わる。責任者に時区と完全性の定義を確認し、不明の間は跨日比較を止める。操作者やブラウザーの時区を勝手に使わない。
一日が終わっても完全とは言えない？
暦の終了と入庫完了は別条件。data-through、実際の範囲、遅着ルールを確認する。終了だけが分かるなら完全性は不明のままにする。
翌日に再実行したら帰属日を変える？
元の業務日と対象範囲を維持し、再実行日時と修正版を別に残す。送信状態が不明なら、生成成功を理由に再送しない。
まず一つの見本で日付を説明させる
確認済みの三つの時計と停止条件をBuda Agentに渡し、日付説明と要確認一覧を作らせる。予約や送信はさせない。Agent tabで入力と実ファイルを確認する。
反復するならBuda AIのMarketplaceで適切なSkillを検索してインストールし、日付入力を受け取れるか確認する。一文での日報依頼は入口を簡単にしても、「昨日」の定義までは決めてくれない。