Workspace Studioの日付ずれ対策｜対象日・実行時刻を分ける5手順

「毎朝のレポートを自動化したのに、件名の日付だけ昨日になっている」「予定どおり動いたはずなのに、集計した期間が違う」。Workspace Studioで日付を扱うとき、こんな食い違いに困ることがあります。

時刻の設定を直す前に、まず確認したいことがあります。動いた日時と、仕事が対象とする日付は別の情報です。ここを分けないまま「今日の分を作って」と頼むと、予定、開始、集計対象、表示する日付の意味が混ざってしまいます。

この記事では、Google Workspace Studioの日付を含むフローを設計するために、対象日・予定時刻・実行時刻を整理する5手順を紹介します。僕がStudioで効果を実測した体験談ではなく、2026年10月30日に確認したGoogle公式ヘルプを土台にした準備と点検のガイドです。記入例は説明用の架空例で、画面に存在しない変数や関数は使いません。

日付ずれの原因は「今日」の意味が一つではないこと

日付が期待と違っても、すぐにタイムゾーンの不具合と決めつける必要はありません。まずは「どの日の仕事を、いつ動かし、どの書式で見せたいのか」を言葉で分けてみましょう。原因の切り分けは、画面の時計を眺めるところからではなく、期待する結果を決めるところから始まります。

対象日・予定日時・実行日時を別の欄にする

対象日は、仕事が扱う日や期間です。予定日時は、フローを開始する予定の日時。実行日時は、実際に開始した日時です。たとえば「10月30日の朝に、10月29日の作業記録をまとめる」なら、対象日は29日で、予定日時と実行日時は30日になる場合があります。

この状態は、それだけでは誤りではありません。29日分のレポートを30日に作るのが目的なら、正しく動いています。逆に30日分を作る仕事なのに29日が対象になったなら、確認が必要です。数字が違うことより、各欄の意味が依頼と一致しているかを見ます。

さらに、レポートの作成日と、保存先のファイル名に入れる日付が違う設計もあります。「対象日で検索したい」のか「作った順に並べたい」のかで選び方が変わるため、両方欲しいなら別々に表示します。一つの「日付」欄へ全部の役割を背負わせないことが大切です。

公式仕様と、自分で決める運用を分ける

Googleの公式ガイドでは、Workspace Studioのフローは開始条件となるスターターと、後に続くステップで構成されます。スケジュールによる開始では日時や繰り返し頻度を設定でき、タイムゾーンも指定できます。ただし、設定した開始日時から、あなたのレポートの対象日まで自動で正しく決まるとは限りません。

対象日を当日にするか前日にするか、遅れた処理をどこまで許すかは、仕事のルールです。本記事の5手順は、そのルールを整理するための提案であり、Googleが定めた公式のエラー修正手順ではありません。画面の表示や使えるステップは、アカウントや更新によって異なります。

参考：Google公式のスターター・ステップ案内。利用中の環境に同じ選択肢があるかを確認し、見当たらない項目を推測で補わないようにしましょう。

須賀ともひろ

僕なら、設定を触る前に「このレポートは何日分なのか」を一文にします。期待する日付が決まると、何を直すべきかも見つけやすくなります。

手順1〜2：対象日を定義し、予定と実行を分ける

最初の2手順では、まだ日付の計算を始めません。対象日と実行条件の意味を固定します。いつ動かすかだけを先に決めると、深夜に処理がずれたとき、何日分を扱うのか説明できなくなるからです。

手順1：何日分を、どの範囲で集めるかを書く

たとえば「毎朝、前日の記事作成メモをまとめる」という架空の仕事を考えます。ここでは、対象は日本時間で前日の0時から翌日0時の直前までに作られたメモ、と定義します。開始側を含み、次の日の開始を含めない、と書けば、境界の同じメモを二日分へ入れることを避けやすくなります。

ただし、元データが持つ日時も確認してください。作成日時で集めたいのに更新日時で絞ると、昔のメモを今日修正しただけで対象へ入ります。これは時計のずれではなく、使っている日時項目の違いです。「作成」「更新」「受信」「予定開始」など、どの時点を対象とするかも一緒に記録します。

週報なら「前の一週間」とだけ書かず、月曜から金曜なのか、直近7日間なのかを決めます。日曜の夜に作る資料と、月曜の朝に作る資料では、同じ「今週」でも読者の解釈が違うことがあります。境界は、自分以外の人が読んでも同じ範囲を取り出せる表現にしましょう。

手順2：遅れたときに対象日を変えるか決める

予定が10月30日9時で、実際の開始が同日9時20分だったとします。前日分のレポートなら、この20分の遅れによって対象を変える理由はありません。ところが開始が翌日になり、そこから単純に「昨日」を計算すると、元の予定で扱うはずだった日とは違う結果になります。

そこで、対象日を決める基準を、予定と実行のどちらに置くかを先に選びます。予定された一日分の集計なら対象日を維持する設計、実際に動いた時点から直近24時間を集めたいなら実行時刻を基準にする設計、というように目的で決めます。どちらか一方が常に正しいわけではありません。

再開時も同じです。途中で止まったレポートを再開するなら、最初の対象期間を持ち越すほうが目的に合う場合があります。一方、毎回最新情報を取り直す仕事なら、再実行時点の期間を使うこともあります。自分の運用メモには「再開でも対象期間を維持する」か「新しく計算する」かを書き、結果のファイル名にも反映します。

これはStudioの設定項目名や標準変数名を並べたものではありません。フローへ渡す値を選ぶ前に、人が用意する設計メモです。実際の開始時刻をどこで取得できるかは、後で実行履歴と使える変数の両方から確認します。

定期実行の全体像や、開始時刻と完成時刻の考え方を整理したい方は、こちらも補足になります。製品や画面は異なるため、設定をそのまま移すのではなく、仕事の区切り方を参考にしてください。

Codexのスケジュール機能で定期作業を自動化する方法と注意点「毎週月曜の朝9時に、Codexが自動で記事の下書きを作ってくれたら便利…

手順3〜4：タイムゾーンと形式を決め、必要な値を渡す

対象期間が決まったら、次に時計の基準と表示形式をそろえます。ここで注意したいのは、見た目の日付が同じでも、データが同じ意味とは限らないことです。日付だけの文字列と、時刻・タイムゾーンを含む日時は分けて考えます。

手順3：どの時計で日付を区切るかを明示する

日本向けの一日を扱うなら、日本時間を基準にする、とメモへ書きます。説明上の例として、日本時間の10月30日0時30分は、UTCでは10月29日15時30分です。同じ瞬間を別の時計で表すため、日付の数字が違います。どちらも同じ出来事を指しているので、表示だけを見て誤データと判断しないようにしましょう。

日付だけを先に切り取ってしまうと、その後で時差を調整しても、もとの瞬間を復元できないことがあります。時刻を扱うデータなら、元の値とタイムゾーンを確認し、基準をそろえてから必要な日付表示へ変える、という順番で考えます。提供されている機能でどう変換するかは、個々のステップの説明を確認してください。

単に文字へ「JST」と付け足すだけでは、UTCの時刻が日本時間へ変換されるわけではありません。反対に、すでに日本時間へ変換済みの値へ、さらに時差を加えると二重変換になります。元の値、変換の有無、最後の表示を一組で確認します。

ファイル名などの日付だけなら「2026-10-30」、実行の記録なら「2026-10-30 09:20 日本時間」のように用途を分けると読みやすくなります。「10/30」だけでは年が分からず、海外の相手とのやり取りでは月日順も混乱しやすいため、保存する記録は年も含めるのがおすすめです。

手順4：文章に日付を書くことと、変数を入れることを区別する

Workspace Studioでは、前の工程の情報を後の工程で使うために変数を挿入します。公式ヘルプでは、入力欄のVariablesや「@」から候補を選ぶ方法が案内されています。文章に「現在日時」と書くだけで、常に実際の実行日時へ置き換わるとは考えないようにしましょう。

日付が固定文字なら、同じフローを翌日に動かしても同じ文字が残る可能性があります。変数として挿入されているなら、どのスターターや前のステップの値なのかを確認します。見た目が似ていても、予定の開始時刻、メールの受信時刻、資料内に書かれた日付は別物です。

また、入力欄によって受け取れる型が異なります。日時の入力に合う候補が前工程にない場合、変数を追加する選択肢が表示されないこともあると公式ヘルプは説明しています。候補が出ないときに、想像した変数名をそのまま文字で打ち込んで動的な値のつもりにしないことが重要です。

参考：Google公式の変数の使い方。自分の画面で選べる値と、その値を生成したステップを一つずつ確かめてください。

AIへ渡すメモには、日付の役割も添える

文章生成のステップへは、値だけでなく、その値が何を意味するかも渡します。たとえば「対象日：2026-10-29。作成予定日：2026-10-30。タイトルの日付には対象日を使う。資料内の日付は引用対象の事実であり、対象日を変更する根拠にはしない」という形です。ここでの日付は説明用の固定例です。

実際のフローでは、この例を毎日書き換えるのか、選択できる変数から値を渡すのかを決めます。必要な値が自動取得できないなら、自動化範囲を狭め、人が確定した対象期間を入力に使う方法もあります。未確認の機能を前提に、全自動の設計だけを先に完成させないようにしましょう。

外部サービス連携の変数には、メールや予定の内容が含まれる場合があります。日付を直す作業のために、読者の相談全文や顧客情報まで渡す必要はありません。日時の確認に必要な、共有してよい最小限のデータで設計します。

手順5：日付の境界と遅延をテストする

最後の手順は、完成したフローの動作と、設計した日付の意味を照合することです。一度正しい件名が出ただけでは、深夜や遅延時も正しいとは確認できません。正常な例と、間違えやすい境界の例を、分けて点検します。

まず自分宛て・コピー資料で確認する

Googleは、Studioのテスト実行でもメッセージ送信や文書変更などの実際の処理が行われると案内しています。テストという名前でも、画面だけのシミュレーションとは限りません。本番の送信先や重要な文書を使ったまま、気軽に繰り返さないでください。

最初は自分宛ての通知と、内容を確認できるコピーの文書を使います。日付確認のための例なら、実在の顧客のメールではなく、架空の作業記録で十分です。送信先や更新先が後続の変数で変わる場合も、最終的にどこへ処理されるかを確認してから実行します。

参考：Google公式のテスト実行と安全な試し方。本番での再送や重複更新を避けるため、テスト結果の保存先も分けておきましょう。

通常・深夜・遅延・週末をケース表にする

テスト用メモは「入力の想定」「期待する対象期間」「件名の日付」「確認結果」の4欄で作ります。すべてを一度に試す必要はありませんが、あなたの仕事で起こる境界を選んでください。

1. 通常：朝に前日分を作り、件名も対象日になっているか
2. 深夜：日本時間とUTCの日付が異なる例で、基準を取り違えないか
3. 遅延：予定より遅れても、維持すると決めた対象期間が変わらないか
4. 週末・月またぎ：金曜分を月曜に扱うなどの運用で、どの日を対象にするか説明できるか
5. 再開：同じ仕事を再開したとき、対象日と保存先が一致し、送信済み結果を重複させないか

この5ケースは製品の標準テスト項目ではなく、設計確認の例です。実行時刻を自由に指定できない環境で、PCの時計やアカウントのタイムゾーンを変えて無理に再現する必要はありません。まず固定の入力データで日付ルールを確認し、その後の自然な実行履歴で本当に渡った値を照合します。

Activityの開始時刻と、出力の対象日を照合する

公式案内では、Activityから実行の開始時刻や各ステップの詳細を確認できます。フローの出力と同じタイミングの実行を開き、「何時に動いたか」と「どの日を扱ったか」を並べて見ます。作成した文書が複数あるなら、リンクやファイル名も記録し、別の実行結果を見比べないようにします。

たとえば、Activityでは30日朝に開始していて、入力が29日分、出力の件名も29日分なら、前日レポートとしては整合します。入力が29日分なのに件名だけ30日なら、表示・文章生成側を確認します。入力の時点ですでに30日分なら、対象データの選択や日付の決定に戻ります。

全部の設定を一度に変えると、どの変更が効いたか分からなくなります。まず誤っている欄を一つ特定し、一箇所を修正して同じケースを確認する。期待と実際の差を短く残しておくと、次回の切り分けも進めやすくなります。

参考：Google公式の画面案内・Activity、フローの問題を調べる公式ヘルプ。利用上限や権限など、日付以外の理由で止まっている場合は、表示されたエラーを先に確認します。

よくある疑問と、日付ずれを防ぐ確認メモ

日付の扱いを少し丁寧に決めるだけで、結果の見方は整理できます。最後に、最初の設定で迷いやすい疑問を確認し、あなたの仕事へ戻せるメモにまとめます。

5手順を、一枚の確認メモへまとめる

ここまでの手順を振り返ります。手順1で対象日と対象期間を言葉にし、手順2で予定と実行、遅延時の扱いを分けます。手順3でタイムゾーンと表示形式を固定し、手順4で実際に渡せる値を選びます。最後の手順5で、日付境界と出力を照合します。

メモには、仕事名、対象期間の基準、使う元データの日時項目、タイムゾーン、件名の日付、遅延・再開の規則、確認した出力先を書いてください。さらに「固定文字なのか変数なのか」「その変数はどのステップの値か」を添えると、後から設定を見直す人にも意図が伝わります。

書き方の例は「前日作成メモの集計。対象日は日本時間基準。件名には対象日を表示。予定と実開始は別記録。再開時は対象期間を維持し、同じ保存先と送信結果を照合する」です。これは説明用の提案なので、あなたの実際の仕事に合う部分だけを残してください。

須賀ともひろ

最初から全部のケースを自動化する必要はありません。まず一つのレポートで、対象日と実行日時を別々に説明できる状態を目指してみましょう。

毎回使う確認事項を文章として保存する考え方は、こちらの記事でも整理しています。Studio専用の設定ファイルを作るという意味ではなく、日付の規則を会話だけに置かず、次回も読める資料へ残すための補足です。

CodexのAGENTS.mdとは？書き方と5項目テンプレートを実例解説Codexへ仕事を頼むたびに、同じ条件を何度も説明していませんか？ 「本…

Workspace Studioの日付ずれ対策では、いきなり時計を直すより、何がずれたのかを分けることが先です。対象日、予定日時、実行日時、表示形式がそれぞれの目的に合っていれば、日付の数字が違っていても正しい場合があります。逆に数字が一致していても、対象データが違えば確認は未完了です。

今日の一歩は、今使っている一つのフローについて、「この仕事は何日分か」「どの時計で区切るか」「遅れたら何を維持するか」の3行を書くことです。手元の結果と比べ、分からない値を分からないまま残し、公式の画面と実行履歴へ戻って確認する。その積み重ねが、日付を含む自動化を見直せる形にしてくれます。