3行でいうと

  • 日本の標準時は、協定世界時（UTC）より9時間進んでいます。米国の西海岸の太平洋時間は、標準時でUTCより8時間、夏時間では7時間遅れているので、日本との時差は、冬は17時間、夏は16時間です。
  • 米国の夏時間は、2026年は3月8日から11月1日までです。読んだ日（10月16日）は夏時間の中なので、太平洋時間との時差は16時間で、11月1日の2時以降は17時間になります。
  • 読んだ公式のリリースノートは、日付だけを書いていて、時刻や時間帯は書いていないものがほとんどでした。日付が日本とずれるかどうかは、自分で直して確かめることになります。

この記事は、公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。時刻の計算（時差の足し算）は、読んだ公式の数字をもとにした僕らの計算です。たとえ話と、「見立てです。」で始まる段落も、僕らの考えです。

先に結論

公式の文書を読んで言えることは、次の4つです。

  1. 日本とのずれは、時差が原因です。 日本は、UTCに9時間を足した時刻（NICTのQ&Aの説明）。米国の太平洋時間は、標準時でUTC-8（Microsoftの時間帯の表）です。
  2. 米国の時差は、季節で変わります。 NISTによると、米国の夏時間は、3月の第2日曜から11月の第1日曜までで、時計を1時間進めます。2026年は3月8日から11月1日までです。
  3. 公式のお知らせの日付は、時間帯が書かれていないことが多いです。 OpenAI、Anthropic、Google Cloudのリリースノートを読みましたが、時間帯の説明はありませんでした。
  4. だから、「本日」は、発表した側の日付だと考えます。 日本では、1日先の日付になっていることがあります。

たとえ話：「今日の夜に電話するね」

僕らのたとえです。公式の文書にあるものではありません。

海外に住む友達が、「今日の夜に電話するね」と言ったとします。友達の「今日の夜」は、日本では、翌日の昼前かもしれません。友達の言葉は間違っていませんが、日本の私たちが「今日」と思っている日とは、ずれています。

AIのニュースの「本日」も同じです。米国の会社が「本日」と書くとき、その日は、会社のある場所の日付です。

時差の仕組み：3つの数字だけ覚える

日本：UTC + 9時間

NICT（情報通信研究機構）のQ&Aは、日本標準時を、協定世界時（UTC）に、東経135度に相当する+9時間を加えたものと説明しています。UTCは、世界の時刻の共通の物差しです。

米国：場所と季節で変わる

米国には、複数の時間帯があります。Microsoftの「既定の時間帯」の表では、太平洋時間（US & Canada）はUTC-8、東部時間はUTC-5、東京はUTC+9です。ただし、この表は標準時の値で、夏時間は載っていません。

NISTのページによると、米国の夏時間は、3月の第2日曜の午前2時に始まり、11月の第1日曜の午前2時に終わります。始まるときは時計を1時間進め、終わるときは1時間戻します。2026年は、3月8日に始まり、11月1日に終わります。ハワイ、アメリカ領サモア、グアム、プエルトリコ、米領バージン諸島、アリゾナ州（先住民ナバホ・ネーションを除く）は、夏時間を使いません。

日本との時差（僕らの計算）

米国の場所 夏時間のあいだ（〜2026年11月1日） 標準時のあいだ（2026年11月1日の2時以降）
太平洋（西海岸） UTC-7（PDT）→ 日本は16時間進む UTC-8（PST）→ 日本は17時間進む
東部（東海岸） UTC-4（EDT）→ 日本は13時間進む UTC-5（EST）→ 日本は14時間進む

「PDT」「PST」などの略称は、一般的な呼び方で、読んだNISTやMicrosoftのページには書かれていませんでした。Googleの変更履歴にPSTという表記があるのを読みましたが、PDTとの区別は、後の例で触れます。

「日付が変わる」目安（僕らの計算）

たとえば、太平洋夏時間の10月15日午前10時は、日本の10月16日午前2時です。太平洋夏時間の10月15日午前6時は、日本の10月15日午後10時で、同じ日付です。

公式のお知らせは、時間帯をどう書いているか

2026年10月16日に読んだ範囲です。

例1：OpenAI：日付はあるが、時刻も時間帯もない

OpenAIのGPT-6のお知らせは、2026年10月7日付です。ChatGPTのPlus、Pro、Business、Enterpriseの人に、同じ日から展開を始め、FreeとGoの人には翌日から、と書いています。時刻と時間帯の記載はありませんでした。

ChatGPTのリリースノートも、「October 15, 2026」のように、月・日・年を書いていて、時間帯の説明は見当たりませんでした。読んだ時点の最新の3項目は、10月15日、10月9日、10月7日でした。

見立てです。日本では、米国の昼間に出た発表は、翌日の日付になります。リリースノートの日付と、日本のニュースサイトやSNSの日付がずれて見えるのは、この仕組みだと思います。実際に何時に出たかは、ページからは分かりません。

例2：Anthropic、Google Cloud：同じく、日付だけ

Claudeのリリースノートは、「October 7, 2026」のような見出しで、時間帯の記載はありませんでした。Google Cloudのリリースノートも、「October 15, 2026」のように日付だけで、時間帯や日付の決め方の説明は、読んだ範囲にはありませんでした。

例3：Gemini API：時刻と「PST」がある1件

GoogleのGemini APIの変更履歴は、日付の時間帯を書いていませんでした。ただ、2026年4月14日の項目に、あるモデルを「2026年4月30日の午前9時（PST）」に終了する、という1件がありました。

NISTによると、4月は米国の夏時間のあいだです。ページの「PST」が、標準時の意味なのか、太平洋時間の通称なのか、ページからは分かりません。ただ、どちらの場合も、日本では4月30日ではなく5月1日の早朝です。終了の日付を、日本の予定に入れるなら、この1日のずれが効いてきます。

「最終更新」は、UTCで書かれていることがある

Google AI for DevelopersのGemini APIの変更履歴のページには、「最終更新 2026-10-14 UTC」という表示がありました。UTCの日付は、日本時間では、同じ日の午前9時から、翌日の午前8時59分までにあたります。UTCで10月14日と書かれていても、日本時間では10月15日の朝かもしれません。

また、NISTの夏時間のページは、更新日を「2026年2月9日」と、時間帯なしで書いています。ページごとに、書き方は違います。

誤解されやすい点

「米国時間」は1つではない 太平洋時間と東部時間では、3時間違います。日本との時差も、16時間と13時間（夏時間のとき）で違います。

時差は、1年中同じではない 米国の夏時間は、2026年11月1日の2時に終わり、そのあと日本との時差が1時間広がります。

日本の「今日」が、米国の「今日」と同じとは限らない 発表の「本日」は、発表した側の日付です。

今日からできること

  1. 時間帯の記号を探す。 「PT」「ET」「UTC」「JST」などです。書かれていなければ、発表した側の現地の日付と考えます。
  2. 日本の日付に直す。 太平洋時間なら、夏時間のあいだは+16時間、標準時のあいだは+17時間です。上の表を使います。
  3. 日付より、「自分の画面にいつ届くか」を確かめる。 届く日は、プランや地域でも変わります。同じ連載の「発表」「発売」「提供開始」の記事を見てください。
  4. 予定に入れるときは、時間帯も一緒に書く。 「10月30日の午前9時」ではなく、「米国太平洋時間の10月30日午前9時（日本時間の10月31日）」のように。
  5. 3月と11月は注意する。 米国の夏時間が変わる時期は、時差も変わります。

やってはいけないこと： リリースノートの日付を、そのまま日本の日付として、仕事の予定やお知らせに書くこと。1日ずれて、「もう終了していた」「まだ始まっていなかった」ということが起きます。

気をつけること

出典

更新履歴