Googleカレンダーの終日予定に「+09:00」を付けて登録したら前日にずれた話

おはようございます。まさきんです。

家族の予定は、AIアシスタント経由でGoogleカレンダーに入れることが増えました。便利な反面、先日ちょっとした落とし穴を踏みました。終日の予定が、なぜか1日前にずれて入っていたんです。仕組みを調べたら納得できたので、記録として残しておきます。

※記事公開時点の情報です。最新の条件は公式サイトでご確認ください。

何が起きたのか

僕はAIアシスタント(Claude)とGoogleカレンダーを連携させています。家族で共有しているカレンダーにも、予定を自動で入れてもらっています。

先日、あるサブスクの無料トライアルを試していました。クラウドストレージ付きのAIプランです。続けるかどうかの判断日を、2段構えで決めることにしました。

1つ目は、途中で使い心地を確かめる中間チェック日です。2つ目は、続けるかやめるかを決める最終判断日です。最終判断日は、解約期限の9日前に置きました。ギリギリに判断すると、忙しさで流れてしまいそうだったからです。

この2日を、終日予定として家族カレンダーに登録しました。AIに日付を伝えて入れてもらう、いつものやり方です。

ところが、カレンダーを開くと様子が違いました。12月の2つの予定が、どちらも1日前に入っていたんです。解約期限の話なので、1日のずれでも気持ちが悪いですね。

原因は「+09:00」とカレンダーのタイムゾーン

調べてみると、原因は日付の渡し方でした。AI経由で予定を作るとき、終日の日付に「+09:00」を付けて指定していたんです。「+09:00」は日本時間を表す書き方です。

一方で、家族共有カレンダーのタイムゾーンはUTCになっていました。UTCは世界の基準になる時刻で、日本時間より9時間遅れています。

例えば「12月10日の0時(+09:00)」は、UTCに直すと「12月9日の15時」です。UTCのカレンダーから見ると、この時刻は12月9日に属します。なので終日予定も12月9日として入った、と考えるとつじつまが合います。

使っているAI連携ツールの中身は、僕からは見えません。なので、細かい変換の手順までは断言できません。ただ、ずれ方は9時間の時差でぴったり説明できると思います。

「Z」付きで入れ直したら正しい日に

試しに、日付を「Z」付きで渡して予定を更新し直しました。「Z」はUTCを表す記号です。すると、今度は正しい日に入りました。

「12月10日の0時(Z)」は、UTCのカレンダーでも12月10日のままです。時差の分だけ日付がまたがる、ということが起きません。

それ以来、このAI連携では終日予定をZ付きで渡すことにしています。とはいえ、これは正攻法ではありません。後で書きますが、本来の仕様はもっとシンプルでした。

終日予定は「時刻のない日付」

ここで立ち止まって考えたのは、終日予定とは何かという点です。

時刻のある予定は、世界のどこから見ても同じ瞬間を指します。東京の9時は、ロンドンの0時と同じ瞬間です。見る場所によって、表示される時刻が変わります。

一方で、終日予定は「その日一日」を指す予定です。誕生日や締め切り日のように、時刻とは関係なく日付そのものに意味があります。本来はタイムゾーンで動いてほしくない情報ですね。

ところが、日付に時刻やタイムゾーンを付けて渡すと話が変わります。受け取る側は、それを「ある瞬間」として扱うかもしれません。その瞬間がどの日付に属するかは、カレンダー側のタイムゾーンで決まります。今回のずれは、まさにこの食い違いだったのかなと思います。

Google Calendar APIの仕様

Googleの開発者向けドキュメントを読むと、終日予定の渡し方がはっきり書かれていました。

予定の開始と終了には、date と dateTime という2種類の項目があります。date は「yyyy-mm-dd」形式の日付で、終日予定のときに使うとされています。dateTime は時刻付きの値で、タイムゾーンのずれ(オフセット)が必要です。

さらに、ドキュメントには大事な一文がありました。終日予定では、タイムゾーンの項目は意味を持たないとされています。

また、開始と終了は「両方とも時刻付き」か「両方とも終日」にそろえる必要があるそうです。開始を date にして、終了を dateTime にするような混在はできません。

つまり、終日予定は日付だけで渡すのが正解です。日付だけなら、カレンダーのタイムゾーンに左右されずに済みます。

end.date は翌日を入れる

もう一つ、つまずきやすいのが終了日です。ドキュメントでは、開始は「含む」で終了は「含まない」と書かれています。

12月10日だけの終日予定なら、end.date には翌日の12月11日を入れます。公式のサンプルでも、6月1日の終日予定は end が6月2日になっていました。

"start": { "date": "2026-12-10" },
"end":   { "date": "2026-12-11" }

ここで end も12月10日にすると、期間がゼロになってしまいます。人間の感覚だと少し不思議ですが、そういう決まりだと覚えておくとよさそうです。

今回のZ付きは「受け口に合わせた回避策」

ここは正直に書き分けておきたいところです。

APIの仕様に沿うなら、終日予定は start.date と end.date で渡すのが本筋です。一方で僕が使っていたのは、AIとカレンダーをつなぐ連携ツールでした。その受け口では、終日予定も日時の形で受け取る作りになっていたようです。

その作りの中で、UTCのカレンダーに正しく入る書き方がZ付きだったということです。APIを自分で直接たたける人は、日付だけで渡すのが素直だと思います。

渡し方ごとの結果を整理

理屈の上で、渡し方とカレンダーのタイムゾーンの組み合わせを並べてみました。日付は説明用の例です。実際に試したのは、UTCのカレンダーの2パターンだけです。残りは時差からの計算なので、参考程度に見てください。

日本時間のカレンダーでは、Zの0時は日本の朝9時にあたります。なので、日付はずれない計算です。とはいえ、UTCより西の地域のカレンダーでは前日にずれる計算になります。どの書き方でも安定するのは、やはり日付だけの渡し方ですね。

家族カレンダーを自動化している人が踏みやすい点

家族で共有しているカレンダーは、個人のメインカレンダーとは別に作ることが多いと思います。Googleのヘルプを読むと、タイムゾーンはカレンダーごとに設定できると書かれています。

つまり自分のメインカレンダーが日本時間でも、共有カレンダーは別の設定かもしれません。今回の家族カレンダーがなぜUTCだったのか、経緯は僕にもはっきりしません。気づかないまま運用していた、というのが正直なところです。

手で予定を入れているうちは、この違いはあまり表に出ないのかもしれません。自動化してAPI経由で入れ始めると、急に顔を出すのではないでしょうか。

開発者向けドキュメントには、カレンダーのタイムゾーンが「既定のタイムゾーン」とも呼ばれるとあります。予定の一覧を取り出すときにも、このタイムゾーンが基準になるそうです。自動化するなら、カレンダーの設定は一度見ておいて損はないと思います。

カレンダーのタイムゾーンを確認する手順

Googleカレンダーのヘルプに沿うと、パソコンでの確認手順は次のとおりです。

1. パソコンでGoogleカレンダーを開く
2. 左側の「マイカレンダー」で、対象のカレンダーにカーソルを合わせる
3. その他アイコンから「設定と共有」を開く
4. カレンダーの設定にある「タイムゾーン」を見る
5. 変えたい場合は、都市や国を検索して選ぶ

全体の「メインのタイムゾーン」は、右上の設定アイコンから開く設定画面にあります。こちらとカレンダーごとの設定は別物なので、両方見ておくとよさそうです。

ただ、ヘルプには「予定の主催者ではない場合は変更できない」という注記もあります。共有カレンダーの設定を変えるなら、作った人に頼むのが早いかもしれません。

登録後に確認すること

仕組みを直しても、最後は目で見るのが一番確実だと感じています。僕が決めた確認のポイントは次の3つです。

• 登録した予定を、カレンダー上で日付ごと目視する
• 終日予定なら、終了日が翌日になっているかを見る
• 共有している家族のスマホでも、同じ日に見えているか確かめる

特に、解約期限のような「ずれたら困る予定」は念入りに見ています。今回も、目視で気づけたから助かりました。

よくある失敗と落とし穴

自分の体験と、公式ドキュメントから考えられることをまとめました。

• 終日予定に時刻とタイムゾーンを付けて渡してしまう
• 自分のメインカレンダーと共有カレンダーのタイムゾーンが同じだと思い込む
• end.date に開始日と同じ日付を入れてしまう
• 開始を日付、終了を日時のように形式を混ぜてしまう
• 登録できたことだけ確認して、日付までは見ない

僕が踏んだのは、一つ目と二つ目と最後の一つです。どれも自動化の最初は気づきにくいのかもしれません。

始める前に確認すること

• 登録先カレンダーのタイムゾーンを設定と共有の画面で見た
• 自分のメインのタイムゾーンと食い違っていないか確かめた
• 終日予定を日付だけで渡せるかツールの仕様を確認した
• 終了日が翌日になっているか登録後に見る習慣をつけた
• 家族の端末でも同じ日に表示されるか一度確かめた

仕組みを作るときの考え方

今回の件で、自動化の順番について少し考え直しました。

仕事でも、データの受け渡しでは形式の食い違いがよく起きます。家族の予定も、中身は同じようなデータのやりとりなんですね。なので、送る側の書き方と受ける側の設定をセットで確認するのが大事だと感じています。

以前、口約束の家族の予定をAIでカレンダーに入れる話を書きました。学校のプリントをカレンダーに登録する仕組みでは、終日予定の end を翌日にしています。今回の仕様の話は、その裏付けにもなりました。

時刻の基準がずれる話は、cronの日と曜日の罠の記事でも少し触れています。自動化はUTCとの付き合い方が大事なのかもしれません。

よくある質問

Q. 終日予定をAPIで作るときは何を使えばいいですか?

Google Calendar APIでは、start.date と end.date を使うとされています。形式は「yyyy-mm-dd」の日付です。dateTime は時刻のある予定用なので、終日予定には使いません。

Q. end.date には何を入れればいいですか?

終了は「含まない」扱いなので、最終日の翌日を入れます。12月10日だけの予定なら、end.date は12月11日です。公式のサンプルも同じ形になっていました。

Q. 終日予定でtimeZoneを指定すると効きますか?

開発者向けドキュメントでは、終日予定ではタイムゾーンの項目は意味を持たないとされています。日付だけで渡せば、カレンダーのタイムゾーンに左右されないはずです。

Q. カレンダーごとにタイムゾーンは違うのですか?

Googleのヘルプでは、カレンダーごとにタイムゾーンを変更する手順が案内されています。なので、メインと共有カレンダーで設定が違うこともありえます。「設定と共有」の画面で確認できます。

Q. Z付きで渡せば必ず正しい日に入りますか?

僕の場合は、UTCのカレンダーで正しい日に入りました。ただ、計算上はカレンダーのタイムゾーンによって結果が変わりえます。日付だけで渡せるなら、そちらのほうが安定すると思います。

Q. 共有カレンダーのタイムゾーンを変えられません。

Googleのヘルプには、予定の主催者ではない場合は変更できないという注記があります。カレンダーを作った人に、設定を見てもらうのが早いかもしれません。

Q. すでにずれて入った予定はどう直せばいいですか?

僕は、正しい書き方で予定を更新し直しました。手で直す場合も、予定を開いて日付を変えれば済みます。直したあとは、家族の端末でも表示を確かめておくと安心です。

参考にした公式情報

• Events(Google Calendar API リファレンス)
• Calendars and events(Google Calendar API ガイド)
• Calendars(Google Calendar API リファレンス)
• さまざまなタイムゾーンで Google カレンダーを使用する(Google カレンダー ヘルプ)

まとめ

終日予定は「時刻のない日付」です。そこにタイムゾーン付きの日時を渡すと、カレンダー側の設定しだいで日付がずれることがあります。僕の家族カレンダーでは、それが1日前へのずれとして出ました。

APIの仕様どおりなら、終日予定は日付だけで渡して終了日は翌日にします。今回のZ付きは、使っている連携ツールに合わせた回避策という位置づけです。

家族のカレンダーを自動化している方は、一度カレンダーのタイムゾーンを見てみてはいかがでしょうか。トライアルの判断日のように、期限を管理する予定は特にずれると困りますね。期限の管理ついでに、毎月の固定費も眺めてみるといいかもしれません。

本記事にはアフィリエイト広告を含みます。当サイトのリンクを経由して商品・サービスへお申し込みいただいた場合、提携先企業から成果報酬を受け取ることがあります。 また、運営者は楽天グループに所属する社員であり、紹介プログラムを通じた報酬を受け取る場合があります。記事内容・評価は広告の有無にかかわらず、運営者の実体験と調査に基づき作成していますが、 上記の関係性をご理解のうえお読みください。詳しくは免責事項・アフィリエイト表記をご覧ください。

楽天モバイルの通信エリア・電波状況について気になることがある方は、公式の電波改善・調査依頼フォームからご相談いただけます。