日本と海外の日程調整でJSTと現地時刻を併記する方法

日本と海外の日程候補は、年と日付、都市、タイムゾーンを指定して同じ時点を変換し、JSTと相手側の現地日時を一組で示します。固定の時差を覚えて当てはめず、候補日ごとの表示とカレンダー招待を照合してください。

候補時刻より先に、日付と相手の都市を確かめる

最初に、年、月日、開始と終了、相手が参加する場所を確認します。会社の本社が海外にあることと、今回参加する人がその都市にいることは同じではありません。出張中などの事情で場所が変わるなら、予定日の参加場所を尋ねます。相手の私的な滞在先の詳細ではなく、時刻の照合に必要な都市やタイムゾーンだけを扱います。

時刻照合票には、候補番号、元にする日時、元のタイムゾーン、相手の都市とタイムゾーン、変換後の開始と終了、確認日を入れます。都市名が同じでも国が分からない場合や、略称だけで地域を特定できない場合は未確認とします。相手の署名や会社の所在地から推測した時刻を、本人が確認した現地時刻として記録しません。

日本側の都合だけで時刻を選ぶ前に、相手が確認した業務時間帯や参加可能な範囲を読みます。現地の休日についても、国名だけで企業の営業日を断定しないでください。公開の祝日と相手の社内予定は別です。まだ候補の段階なら候補と明記し、変換できたことから参加可能や日程確定まで進めないようにします。

日付ごとにタイムゾーンを指定して変換する

カレンダーなど、日付と地域を扱える方法で同じ時点を照合します。今日の時差を来月の予定へ使い回すのではなく、実施する日付で確認します。開始だけでなく終了も確認し、日付をまたぐ場合は相手側の年月日を明示します。時差の計算だけ正しくても、終了時間や所要時間が違えば同じ予定の案内にはなりません。

Googleカレンダーのヘルプは、特定のタイムゾーンで予定を作成でき、招待相手には現地のタイムゾーンで表示されると説明しています。また、タイムゾーンの変更が反映される時期によって表示がずれる可能性にも触れています。機能があることを、将来のあらゆる制度変更や各参加者の設定が正しいことの保証にしないでください。

確認票にはタイムゾーンを識別できる名称を残します。東京ならAsia/Tokyo、ロンドンならEurope/Londonのように、どの地域の規則を使ったかが分かる形です。相手に送る文章では、その人が理解できる都市と現地時刻を添えます。UTCからの差だけを書く場合も、候補日における値かを確認し、地域名の代わりに曖昧な略語だけを置かないようにします。

本文の二つの日時と所要時間をそろえる

メールでは一つの候補に日本時間と相手の現地日時を対応させます。別々の段落に並べ、どの候補同士が同じか分からない書き方を避けます。日付、開始、終了、都市、時間帯の順番をそろえると照合しやすくなります。相手側で日付が違うなら、その違いを省略しません。曜日を加える場合は、双方の日付に対応する曜日を確認します。

件名や本文に「日本時間」と書いただけで、海外の相手が変換する負担を全て負う必要はありません。一方で、未確認の地域を使って親切そうな現地時刻を作るのも避けます。地域が不明なら、候補はJSTとその旨を明記し、どのタイムゾーンで確認すべきかを尋ねます。先に分からない点を明らかにする方が、誤った確定案内を減らせます。

候補を送る段階では、確認を求める内容も明確にします。日時の都合だけを聞くのか、参加場所の時刻表示も照合してほしいのかを区別します。相手が「可能です」と返した場合、どの候補への回答か分からなければ確定しません。複数候補を一つの予定へ統合する前に、対象の候補番号と日時を確認してください。

架空の東京・ロンドン候補を照合する

以下は全て架空の例です。候補Aを2026年11月12日、日本時間19時から19時30分とし、相手がロンドンのタイムゾーンで参加すると確認できたとします。日付と地域を指定した照合では、ロンドンの同日10時から10時30分に対応します。これは説明用の時刻例であり、実在する商談や相手の業務時間、参加承諾を示すものではありません。

架空の文面は「候補A：2026年11月12日、東京の日本時間19時から19時30分／ロンドンの現地時間10時から10時30分です。ロンドンでご参加との前提で併記しています。ご都合と、予定日の参加場所に変更がないかをご確認いただけますでしょうか」です。実際に送る際は、その日付と地域で再照合し、自社が確認した内容へ置き換えます。

対照の架空ケースでは、相手が欧州にいるとしか分からず、参加する都市が未確認です。担当者は欧州全体を同じ時刻とせず、現地表示を保留します。確認票には元のJST候補と地域未確認を残します。国や地域の推測で現地時刻を完成させたり、以前の担当者が使った時差を今回の根拠へ流用したりしないでください。

カレンダー招待は本文と別に照合する

日時に合意したら、予定のタイムゾーン、開始と終了、本文の案内を照合します。自分のカレンダーに表示されている時刻だけで、相手がどの時刻を認識したかは分かりません。招待へ双方の日時を説明として残す場合も、予定そのものの時刻と一致させます。画面表示を直しただけで送信済みの本文まで変わるわけではないため、各記録を分けます。

相手が移動する場合は、カレンダーの表示が変わっても同じ時点の会議なのかを確認します。移動先の時刻へ会議を動かすのか、会議はそのままで表示だけ変わるのかは異なる判断です。相手の画面を見ないまま誤設定と断定せず、年月日、都市、開始と終了を照合します。予定の変更を行う場合は、開催者と対象の予定を特定してください。

日付を変えたときは、元の時差が使えると考えず、再度変換します。特に繰り返し予定は、それぞれの日付で必要な確認をします。更新を送った事実と、相手が認識したことも区別します。返信がないのに全参加者確認済みと記録せず、確認した相手と残る対象を票へ残してください。制度変更を含む将来の表示を一律に保証しません。

合意した時点と変換の根拠を引き継ぐ

確定後は、合意の原文、元の日時、相手側の日時、使用したタイムゾーン、招待の参照を一組にします。後任が別地域から予定を開いても、表示だけを見て会議を動かさないようにします。日時の誤案内を訂正する必要が出たら、候補の変換とは別に訂正対象と更新を管理します。今回の作業は、最初から同じ時点を案内するための照合です。

LDMへ海外を含む営業連絡の運用を相談する場合は、対象の地域、候補の表し方、確認が残る参加者を整理してください。本稿は自動時差変換、全参加者への更新通知の到達、会議参加を保証する製品機能を示していません。相手の連絡希望と、メールを送るために必要な社内の確認も、時刻が計算できたことから省略しないようにします。

一次資料、確認日2026年10月18日：Googleカレンダーヘルプ「さまざまなタイムゾーンでGoogleカレンダーを使用する」 https://support.google.com/calendar/answer/37064?hl=ja 。予定のタイムゾーンと現地表示、変更反映への注意のみを参照します。照合票と文面、日程は実務提案と架空例です。個別の参加者の設定、営業日、参加可能時間は検証していません。

実際には無料の受信トレイ到達テスト（check.live-direct-marketing.online）で確認できます。

よくある質問