時差のある相手との会議候補をAIで整理するときは、都市名と「午前中」だけで頼まず、対象日、タイムゾーン、会議時間、各自の参加可能枠を表にします。夏時間の切り替えをまたぐと、同じ現地時刻でも、別の地域での時刻が変わることがあります。
AIには条件の整理と候補表を作らせ、日時の変換、予定の空き、招待の送信は別々に確認します。この記事の東京とロンドンの条件は架空の例です。日時の対応を説明するもので、実際のカレンダーの空きや参加者の合意を確認した候補ではありません。
目次
参加可能枠を、それぞれの現地時間で集める
まず参加者ごとに、次の項目を決めます。必要なのは居住国の推測ではなく、会議日に使うタイムゾーンです。出張中なら普段の所在地と異なることがあります。
表は横にスクロールできます
| 項目 | 記録する内容 |
|---|---|
| 対象日・期間 | 年を含む日付。どの地域の日付かも明示 |
| タイムゾーン | Asia/Tokyo、Europe/Londonなど |
| 参加可能枠 | 現地時間での開始・終了。曜日別の条件も残す |
| 会議の長さ | 30分、60分など |
| 必須条件 | 参加必須者、休憩、準備時間、終了期限 |
| 希望条件 | 午前を希望、連日の会議を避けたいなど |
| 未確認範囲 | 予定の空き、祝日、移動日、相手の合意など |
「9時から18時まで参加できる」なら、会議の終了も18時までに収めるのかを確認します。18時開始で30分の会議を置いてよいと、AIに判断させないでください。
必須条件と希望条件を分けると、候補がない場合も理由を説明できます。希望条件を満たさないことと、参加可能枠を超えることは同じではありません。枠を広げる案は、確定候補とは別の相談事項にします。
タイムゾーン名と、固定の時差を混ぜない
IANAのタイムゾーンデータベースは、各地の時刻の履歴や、UTCとの差、夏時間の規則を扱います。地域の制度変更を反映するため更新されるので、都市同士の差を一年中同じ数字と決めつけないようにします。IANA公式：Time Zones（新しいタブで開く）
「ロンドンは東京より8時間遅い」という固定の説明だけで、冬の会議まで計算しないでください。基準は対象日のEurope/LondonとAsia/Tokyoです。BSTやGMTといった表示も、対象日に合うかを確認します。
英国政府の案内では、2026年は10月25日に時計を1時間戻します。以下では、その前後で同じロンドン午前9時が東京で何時になるかを比較します。英国政府：時計の変更日（新しいタブで開く）
架空の30分会議で、開始と終了を比べる
条件は、東京・ロンドンともに現地時間9時から18時まで、会議は30分、終了まで枠内に収めるとします。休日や既存予定はまだ確認していない前提です。
表は横にスクロールできます
| 候補の基準 | UTC | Europe/London | Asia/Tokyo | 入力した時間枠の判定 |
|---|---|---|---|---|
| 2026年10月20日、ロンドン9時開始 | 10月20日08:00–08:30 | 10月20日09:00–09:30 | 10月20日17:00–17:30 | 時間枠内。空きと合意は未確認 |
| 2026年10月27日、ロンドン9時開始 | 10月27日09:00–09:30 | 10月27日09:00–09:30 | 10月27日18:00–18:30 | 東京の終了が枠外 |
10月27日にロンドン8時開始へずらすと、東京では17時になりますが、今度はロンドン側の参加可能枠より早くなります。この条件のままでは、双方の枠内に30分を収められません。
候補がないときに、AIがどちらかの参加可能枠を黙って広げてはいけません。「時間枠内の候補なし」とし、別日、会議時間の変更、非同期の確認、参加条件の相談を分けて提示します。参加者の負担を変える案を、決まった予定のように扱わないでください。
候補表には、地域ごとの日付も書く
時刻だけを並べると、日付をまたいだことが見えなくなります。例えば2026年10月20日16:00 UTCは、ロンドンでは同日17時、東京では10月21日1時です。これは時刻対応の説明で、会議候補として勧める時間ではありません。
表にはUTCの開始・終了と、各地域の年・月・日・開始・終了を持たせます。「火曜の夜」「翌朝」だけの説明へ変えると、基準の地域が分からなくなります。曜日も使うなら、各地域の日付と一緒に確認します。
定例会議の場合は、何を固定するかも決めます。「ロンドンの毎週9時」を固定するのか、「UTCの毎週9時」を固定するのかでは、夏時間の前後で別地域の表示が変わります。初回が合っていることだけで、次月も同じ現地時刻になるとは扱いません。
AIへの依頼は、未確認と候補なしを許す
次の条件から会議候補表を作ってください。
参加者ごとのタイムゾーン、参加可能枠、対象日、所要時間を使ってください。
出力：候補ID｜UTC開始・終了｜各地域の年月日と開始・終了｜条件判定｜未確認事項。
開始だけでなく、終了と必要な前後時間も参加可能枠に収めてください。
対象日の夏時間を確認し、一年中同じ固定時差で計算しないでください。
タイムゾーンや日付が不明なら、候補を確定せず質問へ分けてください。
条件に合う枠がなければ「候補なし」とし、条件変更案を別欄へ出してください。
カレンダーの空きを取得していない場合は「空き未確認」と明記してください。
予定の作成、招待、参加者への連絡は行わず、候補表までにしてください。
条件：［対象日、地域、参加可能枠、所要時間、必須条件と希望条件］
この依頼文だけで、AIが現在の時刻規則やカレンダーを正しく参照したと保証できるわけではありません。候補表ができたら、日付を指定できるカレンダーやタイムゾーン対応の時刻処理で、同じUTCが各地域にどう表示されるかを別に照合します。
JavaScriptで確認する場合、Intl.DateTimeFormatはtimeZoneを指定して日時を表示できます。ただし、表示する機能と、相手の空き予定を読む機能は別です。MDN：Intl.DateTimeFormat（新しいタブで開く）
候補を確定する前に、四つの層を確認する
第一に時刻の対応を見ます。同じ瞬間を指しているか、日付がずれていないか、夏時間の前後を混ぜていないかを確認します。
第二に入力条件を見ます。終了時刻、休憩、移動、参加必須者の条件に違反していないかを調べます。候補を並べる途中で条件を変えたなら、変更前後を分けてください。
第三に実際の予定と合意を見ます。空き時間の取得範囲、非公開予定の扱い、休暇や祝日、相手が確認した候補かを確かめます。「予定が取得できなかった」を「空いている」へ置き換えません。
第四に招待へ転記した結果を見ます。採用した日付、タイムゾーン、開始・終了、定例の基準、参加者が候補表と一致するかを確認します。候補表の作成と、外部へ招待を送る操作は分けます。
日程が変更された場合は、AIの前の回答を読み替えるのではなく、変更後の日付と条件から表を作り直します。特に夏時間の切り替え前後へ移動した会議では、以前の時差の説明をそのまま使わないでください。
会議を実施した後の担当・期限の整理は、議事録からタスクを抽出する方法で確認できます。案内文へ日時を載せる場合は、文章作成の条件を伝えるプロンプトも使い、開催日時と申込期限を混ぜないようにします。
参考資料
- IANA：Time Zones（新しいタブで開く）
- GOV.UK：When do the clocks change?（新しいタブで開く）
- MDN：Intl.DateTimeFormat（新しいタブで開く）
資料の確認日：2026年10月20日。候補表は架空条件の例です。参加者の予定、カレンダー表示、招待の送信、AIサービスの精度は実測していません。