世界97都市の現在時刻と日本時間との時差をリアルタイムに比較できます。 未来の日時指定と、複数拠点の業務時間が重なる会議時間帯の可視化に対応した無料ツールです。
時差計算ツールとは？日本時間と世界の現在時刻を比較する仕組み
本ツールは、世界97都市から基準都市と比較都市を選ぶだけで、日本時間との時差と現地の現在時刻を同時に表示する時差計算サイトです。比較都市は最大5件まで並べられるため、「東京・ニューヨーク・ロンドン」のような3拠点以上の同時確認にも対応します。 単なる世界時計と異なり、日付と時刻を直接指定して未来の時差を計算でき、さらに全拠点の業務時間が重なる時間帯を24時間のタイムラインで可視化するため、海外との会議設定をそのまま完了できます。 時差の計算はブラウザ標準のIntl APIとIANAタイムゾーンデータベースを参照しており、サマータイム（夏時間）の実施状況と切り替え日も自動で判定されます。日付が変わる都市には「翌日」「前日」のバッジが付くため、日付変更線をまたぐ予定の取り違えも防げます。
こんなシーンで便利です
海外拠点とのオンライン会議の日程調整
24時間タイムラインで全拠点の業務時間が重なるコマを探し、そのままクリックして各都市の日付・曜日まで確定できます。誰にも深夜対応を強いない時間帯が存在するかを一目で判断できます。
海外出張・旅行のスケジュール確認
現地到着時刻が何時になるか、家族に連絡してよい時間かを日本時間換算で確認。日付が前後する都市には「翌日」「前日」が表示されるため、予約日の取り違えを防げます。
サマータイム切り替え期をまたぐ予定の確認
3月や10〜11月の切り替え時期は時差が1時間ずれます。日時を指定すればその日の正確な時差が算出され、都市ごとの切り替え日も一覧で確認できます。
海外イベント・スポーツ中継の日本時間換算
現地発表の開始時刻を基準都市に設定して切り替えれば、日本時間が何時何分になるかを即座に確認できます。深夜帯で日付をまたぐ場合も明示されます。
海外市場の開場・閉場時間の把握
ロンドン市場やニューヨーク市場の取引時間は、サマータイムの有無で日本時間が1時間変動します。夏時間と標準時それぞれの時差を確認して取引時間を管理できます。
東京より先に日付が変わる都市の確認
オークランドやシドニーなど、日本より東にある都市は先に日付が変わります。年越しや日付基準の締切を扱う際に、どの都市が何時間先行しているかを正確に把握できます。
使い方は簡単 5ステップ
- 「基準都市」をクリックし、検索ボックスから比較の起点にする都市を選びます。
- 「都市を追加」で比較したい都市を最大5件まで登録します。
- 各都市の現在時刻・時差・UTCオフセット・日付のずれがカードに表示されます。
- 会議時間を探す場合は、24時間タイムラインで全都市が緑になるコマを確認します。
- 特定日時の時差を調べる場合は「日時を指定」に日付と時刻を入力します。
※都市名・国名はローマ字でも検索できます（例：newyork、london、singapore）。選んだ都市の組み合わせはブラウザ内に保存され、次回アクセス時に復元されます。
ご利用時の注意点
- サマータイムの自動判定：夏時間の実施状況は、指定された日時ごとにUTCオフセットを算出して判定しています。固定の時差表を使用していないため、切り替え日をまたぐ計算でも正確です。
- 精度の根拠：ブラウザ標準のIntl APIとIANAタイムゾーンデータベースを参照しています。各国の制度変更が反映されるかは、お使いのブラウザやOSの更新状況に依存します。
- 業務時間の基準：会議時間帯の色分けは9時〜17時を業務時間、8時と18時〜20時を対応可能な時間帯として判定しています。実際の勤務体系や祝日は考慮していないため、目安としてご利用ください。
- 同一国内の複数標準時：アメリカやオーストラリアのように国内に複数の標準時がある国は、都市単位で個別に登録しています。国名ではなく必ず相手が滞在する都市を選択してください。
- 通知機能はありません：指定時刻を知らせる通知は送信しません。会議の予定はカレンダーアプリ側に登録してください。
日本との時差 早見表｜主要都市の時差一覧とサマータイム期間
日本時間（JST／UTC+9）を基準にした主要都市の時差一覧です。サマータイムを実施する地域は、標準時と夏時間で時差が1時間変わります。
| 都市・エリア | 標準時の時差 | 夏時間の時差 | サマータイム | 日本が正午のときの現地時刻 |
|---|---|---|---|---|
| 韓国 / ソウル | 時差なし | 同左 | なし | 12:00（同日） |
| 中国 / 北京・上海 | -1時間 | 同左 | なし | 11:00（同日） |
| シンガポール | -1時間 | 同左 | なし | 11:00（同日） |
| オーストラリア / パース | -1時間 | 同左 | なし | 11:00（同日） |
| タイ / バンコク | -2時間 | 同左 | なし | 10:00（同日） |
| インド / デリー | -3.5時間 | 同左 | なし | 08:30（同日） |
| UAE / ドバイ | -5時間 | 同左 | なし | 07:00（同日） |
| ロシア / モスクワ | -6時間 | 同左 | なし | 06:00（同日） |
| イギリス / ロンドン | -9時間 | -8時間 | 3月末〜10月末 | 03:00（同日） |
| フランス / パリ | -8時間 | -7時間 | 3月末〜10月末 | 04:00（同日） |
| ドイツ / ベルリン | -8時間 | -7時間 | 3月末〜10月末 | 04:00（同日） |
| ブラジル / サンパウロ | -12時間 | 同左 | なし（2019年廃止） | 00:00（同日） |
| アメリカ / ニューヨーク | -14時間 | -13時間 | 3月第2日曜〜11月第1日曜 | 22:00（前日） |
| メキシコ / メキシコシティ | -15時間 | 同左 | なし（2022年廃止） | 21:00（前日） |
| アメリカ / シカゴ | -15時間 | -14時間 | 3月第2日曜〜11月第1日曜 | 21:00（前日） |
| アメリカ / デンバー | -16時間 | -15時間 | 3月第2日曜〜11月第1日曜 | 20:00（前日） |
| アメリカ / ロサンゼルス | -17時間 | -16時間 | 3月第2日曜〜11月第1日曜 | 19:00（前日） |
| アメリカ / ホノルル | -19時間 | 同左 | なし | 17:00（前日） |
| オーストラリア / シドニー | +1時間 | +2時間 | 10月上旬〜4月上旬 | 13:00（同日） |
| ニュージーランド / オークランド | +3時間 | +4時間 | 9月下旬〜4月上旬 | 15:00（同日） |
| 協定世界時 / UTC | -9時間 | 同左 | なし | 03:00（同日） |
【時差の向きの読み方：日本より西は遅れ、東は進む】
日本の標準時（JST）はUTC+9です。表の「-」は日本より時刻が遅れていることを意味し、アジア・中東・欧州・南北アメリカはすべてこちらに該当します。逆に「+」はシドニーやオークランドのように日本より先に日付が変わる都市です。ニューヨークが「-14時間」なら、日本の正午は現地では前日22時になります。
【サマータイムの落とし穴：南半球は北半球と逆に動く】
欧米では3月〜10月（米国は11月まで）が夏時間ですが、オーストラリアやニュージーランドは10月〜4月が夏時間で、北半球とは真逆です。そのため、日本とシドニーの時差は年間を通じて+1時間と+2時間の間で変動します。さらに、アリゾナ州（フェニックス）のようにアメリカ国内でも夏時間を実施しない地域があり、ブラジルは2019年、メキシコは2022年に夏時間を廃止しています。表の値は目安として使い、実際の予定確認はツール上で日付を指定して行ってください。
【30分・45分単位の時差がある国】
すべての国の時差が1時間単位とは限りません。インドはUTC+5:30、ネパールはUTC+5:45、イランはUTC+3:30、オーストラリアのアデレードはUTC+9:30です。本ツールは分単位でオフセットを算出するため、これらの都市も「-3時間30分」のように正確に表示します。
海外との会議設定と時差運用を仕組み化するタイムゾーン管理の実務
複数のタイムゾーンをまたぐ業務を統括する担当者やエンジニア向けに、時差に起因する調整コストの削減と、システム設計上の標準化テクニックを整理します。
多拠点会議を成立させるコアタイムの選定と、負担ローテーションの設計
アジア・欧州・米州の3拠点を同時に結ぶ場合、全拠点の9時〜18時を重ねることは物理的に不可能です。なぜなら、東京とニューヨークの時差だけで13〜14時間あり、どちらかが必ず業務時間外に入るからです。現実的な運用は2つあります。ひとつは1〜2時間の重複枠を全社共通のコアタイムとして固定する方法（東京の朝8〜9時は、欧州の前日夕方と重なりやすい枠です）。もうひとつは、週ごとに深夜・早朝を負担する拠点をローテーションさせる方法で、特定拠点への恒常的なしわ寄せを避けられます。本ツールの24時間タイムラインで全都市が緑にならない場合は、後者の設計が必要だという明確なシグナルです。
サマータイム移行期に発生する会議のずれを構造的に防ぐ運用ルール
毎年3月と10〜11月に、欧米との時差は1時間ずれます。なぜ事故が起きるかというと、定例会議を「日本時間◯時」で固定している場合、相手側では現地時刻が1時間動いてしまうからです。防ぐには、招待状に両拠点の現地時刻を併記し、カレンダーの予定は必ずタイムゾーン付きで登録してください。加えて、切り替え日の前週に定例のリマインドを入れ、その週だけは開始時刻を再確認する運用を標準化すると、移行期のすれ違いをほぼ根絶できます。本ツールでは表示中の都市の切り替え日を年単位で一覧表示するため、この確認をカレンダーに落とし込む起点として使えます。
システム設計における時刻の保持方針：UTC統一とISO 8601表記の徹底
グローバル展開するアプリケーションでは、データベースに保持する時刻を必ずUTCへ統一してください。なぜなら、現地時間で保存すると、サマータイム終了時に同じ現地時刻が1日に2回出現し、ログの順序が壊れたりレコードが重複したりするからです。保存と演算はUTCで行い、画面表示の直前にだけIntl.DateTimeFormatで各都市の現地時間へ変換する構成が標準解です。ドキュメントやAPIのやり取りではISO 8601（例：2026-06-23T07:00:00Z）に統一し、「6月23日16時」のような曖昧な表記を残さないことが、解釈の齟齬による障害を防ぐ最も安価な対策になります。
国名ではなく都市で管理する：同一国内に複数標準時がある地域への対応
海外の連絡先を管理する際は、国名ではなく都市名またはIANAタイムゾーンID（例：America/Chicago）で記録してください。なぜなら、アメリカ本土だけで東部・中部・山岳部・太平洋の4つの標準時があり、「アメリカだから-14時間」という一括りの計算は最大3時間の誤差を生むからです。オーストラリアも東部・中部・西部で3区分あり、さらに州によって夏時間の実施可否が分かれます。同じ理由で、アリゾナ州のフェニックスは夏時間を実施しないため、夏季はデンバーではなくロサンゼルスと同じ時刻になります。連絡先台帳に都市名を1列足しておくだけで、この種の事故は構造的に消えます。
時差計算でよくある失敗と対策
サマータイムの切り替え時期を見落とし、海外会議の時間を1時間間違える
欧米の取引先とWEB会議を調整する際、時差が年間を通じて一定だと思い込み、3月や10〜11月の移行期を無視して予定を組んでしまう失敗です。現地時刻が1時間ずれるため、遅刻やすれ違いが発生します。さらに南半球のオーストラリア・ニュージーランドは北半球と逆の時期に切り替わるため、同じ「夏時間」という言葉で混乱が起きやすい領域です。
💡 対策・解決策を見る▼
日付変更線のまたぎ方を勘違いし、航空券やホテルの予約日を1日間違える
日本からアメリカ方面へ移動する際、時差計算で日付が戻る・進むという「日付のまたぎ」を誤り、現地のホテルのチェックイン日や乗り継ぎ便の搭乗日を1日前後させて予約してしまう失敗です。逆にオークランドやシドニーのように日本より先に日付が変わる都市では、締切や年越しの扱いで認識のずれが生じます。
💡 対策・解決策を見る▼
アメリカ国内の複数タイムゾーンを確認せず、全米一律の時差で計算する
アメリカ（東部・中部・山岳部・太平洋）やオーストラリアのように、同じ国の中に複数の標準時が存在する地域への連絡で、都市ごとの時差を確認せず「アメリカだから日本時間マイナス14時間」と一括りにしてアポイントを取り違えるケースです。本土の東西だけで3時間の差があり、さらにアリゾナ州は夏時間を実施しません。
💡 対策・解決策を見る▼
2都市だけで判断し、3拠点目の担当者に深夜対応を強いてしまう
東京とロンドンで都合の良い時間を決めてから、後になってシンガポールやニューヨークの担当者を招集した結果、その拠点だけが深夜や早朝になっていたと気づくケースです。2都市の比較を繰り返しても、全体で成立する時間帯があるかどうかは判断できません。
💡 対策・解決策を見る▼
30分・45分単位の時差がある国を1時間単位で丸めて計算する
インド（UTC+5:30）、ネパール（UTC+5:45）、イラン（UTC+3:30）、オーストラリアのアデレード（UTC+9:30）などは、1時間単位ではない時差を持ちます。これを「インドは日本より3時間半くらい遅い」と概算で扱うと、会議の開始時刻が30分ずれて、相手が入室済みなのに気づかないといった事態を招きます。
💡 対策・解決策を見る▼
よくある質問（FAQ）
Q.日本との時差を調べたい都市が一覧に見つからない場合はどうすればよいですか？
A. 都市名の欄をクリックすると検索ボックスが開き、世界97都市をアジア・中東アフリカ・ヨーロッパ・北米・中南米・オセアニアの地域別に絞り込めます。日本語の都市名だけでなく、国名やローマ字での入力にも対応しているため、「ニューヨーク」でも「newyork」でも「アメリカ」でも同じ候補にたどり着けます。同じ国の中に複数の標準時がある国も都市単位で個別に登録されているため、アメリカならニューヨーク・シカゴ・デンバー・ロサンゼルス・ホノルル、オーストラリアならシドニー・ブリスベン・アデレード・パースをそれぞれ正確な時差で比較できます。協定世界時（UTC）も基準として選択可能です。
Q.未来や過去の特定の日時を指定して、そのときの時差を計算することはできますか？
A. はい、できます。画面上部の「日時を指定」にある日付欄と時刻欄に、基準都市の現地日時を入力すると、その瞬間における各都市の現地時刻と時差が表示されます。数日後でも数ヶ月後でも指定でき、サマータイムの実施状況もその日付に基づいて自動判定されるため、切り替え日をまたぐ予定でも正確な時差が求められます。指定を解除して現在時刻に戻したい場合は、右上の「現在時刻に戻す」を押してください。
Q.複数の海外拠点が同時に業務時間に入っている時間帯を調べることはできますか？
A. はい、「会議に使える時間帯を探す」の24時間タイムラインで確認できます。基準都市の0時から23時までを1時間ごとに区切り、比較中の全都市の現地時刻を色分けして並べます。9時から17時が緑、8時と18時から20時が黄、それ以外が灰色で表示され、全都市が緑になる時間帯には枠線が付きます。全都市が業務時間に収まる時間帯が存在しない組み合わせの場合は、その旨を明示するため、どの拠点に早朝や夜間の対応を依頼するかの判断材料になります。マスをクリックするとその時刻に固定され、各都市の日付と曜日まで確認できます。
Q.サマータイム（夏時間）はいつ切り替わるのかを確認することはできますか？
A. はい、表示中の都市のうちサマータイムを実施している地域について、その年の切り替え日と時刻を一覧表示します。たとえば2026年であれば、ニューヨークは3月8日3時に夏時間へ、11月1日1時に標準時へ戻り、ロンドンは3月29日2時と10月25日1時に切り替わります。南半球のシドニーは4月5日に標準時へ、10月4日に夏時間へと北半球とは逆の動きをします。これらの日付は固定のデータではなく、ブラウザが保持するIANAタイムゾーンデータから毎回算出しているため、制度変更があってもブラウザの更新に追随します。
Q.東京より先に日付が変わる都市はどこですか？日付の前後はどう表示されますか？
A. 日本より東に位置するオセアニア方面の都市が該当します。ニュージーランドのオークランドは日本より3〜4時間進んでおり、東京がまだ前日の夜でも既に日付が変わっています。オーストラリアのシドニーも1〜2時間先行します。本ツールでは、比較都市の時刻が基準都市と異なる日付になっている場合、「翌日」「前日」のバッジを時差の横に表示するため、海外の航空券やホテルの予約日、深夜帯の会議設定で日付を1日間違えるミスを視覚的に防げます。
Q.この時差計算ツールで選択した都市や設定した情報が外部に送信されることはありませんか？
A. ありません。時差の計算、サマータイムの判定、会議時間帯の算出まで、すべての処理をお使いのブラウザ内で完結させる完全ローカル処理型の設計です。選択した都市の情報がサーバーへ送信されることも、データベースに保存されることもありません。なお、次回アクセス時に同じ都市構成をすぐ表示できるよう、選んだ都市の組み合わせのみをブラウザのLocalStorageに保存していますが、これはご利用の端末内にのみ残るデータで、ブラウザのサイトデータを削除すると消去されます。
Q.表示される時差やサマータイムの判定はどの程度正確ですか？根拠は何ですか？
A. ブラウザに組み込まれたIntl標準APIと、その基となるIANAタイムゾーンデータベースを直接参照して計算しています。固定の時差表を持たず、指定された瞬間ごとにUTCからのオフセットを算出する方式のため、インドの5時間30分やネパールの5時間45分といった30分・45分単位の時差、サマータイムを廃止したブラジル、州によって夏時間を実施しないアメリカのアリゾナ州（フェニックス）なども正しく扱えます。ただし精度はブラウザが保持するタイムゾーンデータの更新状況に依存するため、各国の制度変更が反映されるかはブラウザやOSの更新次第となります。
あなたの声で、
このツールをより鋭く。
「こんな機能が欲しい」「ここを直してほしい」といったご意見や、新しいツールのリクエストを募集しています。エンジニアが直接目を通し、開発の参考にさせていただきます。