1そもそも「タイムゾーン」とは？

地球は1日で1回転するので、太陽の位置に合わせて場所ごとに時刻が違います。日本の朝9時はロンドンの深夜0時、ニューヨークの前日の夜7時。「同じ瞬間」でも、場所によって時計の読み方が違う――これが時差であり、その読み方のルールがタイムゾーンです。

EC業務でもっとも重要なタイムゾーンは2つだけです。

• UTC（協定世界時／Coordinated Universal Time）――世界の基準。サーバーやAPIの内部時刻はだいたいこれ
• JST（日本標準時／Japan Standard Time）――UTCより9時間進んでいる。日本のモール・店舗管理画面の表示

JSTはUTC＋9時間。日本時間で朝9時のとき、UTCはまだ前日の深夜0時です。この「9時間の差」がEC実務のあらゆる場面でズレを生み出します。

2EC現場で時刻がズレる5つの場面

「うちは日本のショップだけだから関係ない」と思いがちですが、使っているシステムの裏側はほぼ全部UTCで動いています。楽天の管理画面はJST表記ですが、AmazonのSP-APIから返ってくる時刻はUTC、Shopifyの管理画面の時刻表示も初期設定はUTCです。日本のEC事業者でも、タイムゾーン問題から逃げきることはほぼ不可能です。

場面1: モールごとに「受注時刻」のフォーマットが違う

マルチモール運営の現場で、もっとも頻繁に起きるのがこのパターンです。同じ「2026年4月8日 朝9時30分の受注」でも、モールから出てくるデータは下表のようにバラバラです。

モール / システム	受注時刻のフォーマット例	タイムゾーン
楽天 RMS	2026/04/08 09:30:00	JST（タイムゾーン情報なし）
Amazon SP-API	2026-04-08T00:30:00Z	UTC（末尾Zが目印）
Yahoo!ショッピング	20260408093000	JST（区切り文字なし）
Shopify Admin API	2026-04-08T00:30:00+00:00	UTC（オフセット明示）
Stripe / PayPal Webhook	1775692200（UNIX秒）	UTC基準の経過秒数

これを統一せずに自社DBに入れると、同じ瞬間の注文が「9時間ズレた別の時刻」として記録されることになります。

場面2: 日次集計で「前日の注文」が翌日に紛れ込む

もっとも見落とされがちなのがこれです。Amazonの注文は内部的にはUTC基準で記録されています。日本時間の朝0時～8時59分の注文は、UTCではまだ前日です。

UTCのまま日付だけ取り出して「4/7の売上」に集計すると、毎日午前0時～9時の注文が前日にズレ込む。日次レポートが楽天と合わない、Amazonの管理画面の数字と社内DBの集計が合わない――この原因の8割はここです。

場面3: セールやクーポンの開始時刻がモールごとに違う

「4月10日 0時スタート」のセールを楽天とAmazonで同時に走らせる――よくある業務ですが、API経由でセール開始時刻を投げるときにタイムゾーンを書き忘れると、片方が9時間早く始まる事故が起きます。

場面4: Cronジョブの実行時刻がサーバーTZに依存

「毎日 朝6時に在庫CSVを取り込む」というスケジュール処理。Cronで「0 6 * * *」と書いただけで終わっていませんか？ このCronが動くサーバーのタイムゾーンがUTCだった場合、実行されるのは日本時間の午後3時です。

クラウドサーバーやコンテナ環境（AWS、GCP、Vercel、Cloud Runなど）は、初期設定がほぼ全てUTCです。「ローカルPCで動いていたバッチをクラウドに上げたら、なぜか実行時刻が9時間ズレた」というのは、開発現場で毎月のように発生しているトラブルです。

場面5: ログの時刻と現場の時刻が合わない

「14時頃に注文が止まった」という現場報告に対して、サーバーログを見ると14時付近に該当エラーがない――。ログの時刻がUTCで記録されていて、JSTで見ると23時になるからです。アクセス解析のレポートとサーバーログを突き合わせる、エラー報告と原因ログを紐付ける、こういった調査作業がタイムゾーンを意識しないと毎回9時間ぶん混乱することになります。

3夏時間（サマータイム）という追加の地雷

日本にはありませんが、欧米の多くの国には夏時間（DST：Daylight Saving Time）があります。年に2回、3月と11月（米国の場合）に時計が前後1時間動きます。日本のEC事業者でも、海外モールへの出店、海外SaaSの利用、海外バイヤーとのやり取りでは避けて通れません。

期間	米国東部時間（EST/EDT）	JSTとの時差
冬時間（11月～3月）	EST（UTC−5）	JSTより14時間遅い
夏時間（3月～11月）	EDT（UTC−4）	JSTより13時間遅い

つまり、米国とのやり取りでは年に2回、時差が1時間動くということです。「米国時間 朝10時のミーティング」を半年前にカレンダーに入れたら、夏時間切り替えで日本側の時刻が1時間ズレる――というのは、海外SaaSのウェビナー参加でも起きます。

夏時間切り替え当日の「存在しない時刻」と「2回ある時刻」

夏時間に入る瞬間、現地時刻は2:00から一気に3:00にジャンプします。つまりその日の「2:30」という時刻は存在しません。逆に冬時間に戻る瞬間は3:00から2:00に戻るので、「2:30」が同じ日に2回発生します。

4EC実務で起きやすい4つの事故シナリオ

タイムゾーンのトラブルが「ただの時刻表示のズレ」で済むなら、まだ被害は小さい。問題は、金額や在庫といった実務データに直接被害が出ることです。

シナリオ1: 楽天とAmazonの日次売上が毎日合わない

もっとも頻発するのがこれ。社内のデータ基盤やBIツールに楽天とAmazonの売上をまとめると、Amazonの「昨日の売上」が管理画面の数字と微妙に合わない。原因を追うと、AmazonのSP-APIで取得した受注時刻をUTCのまま日付だけで切っていて、日本時間で深夜0時～朝9時の注文がズレていることが分かる、という展開。

下手すると、毎日のレポート確認に「数字を手動で調整する作業」が組み込まれてしまう。それが半年続いて、誰もその調整の意味を覚えていない、という事態になりがちです。

シナリオ2: クラウドへの移行で深夜バッチが昼間に動き出す

長年自社サーバーで動かしていた「在庫CSV取り込みバッチ」「日次売上集計バッチ」をAWSなどのクラウドに移行したとき、サーバーのタイムゾーン設定を変えずにCron式をそのまま持っていくと、UTCで動くクラウド側ですべてのバッチが9時間ズレた時刻に発動します。

「朝6時のはずの在庫更新が午後3時に走り、店頭の在庫数とモール在庫が日中ズレ続ける」「23時の締めバッチが朝8時に走って、開店直後にレポートが上書きされる」――こうしたトラブルが、クラウド移行直後の3日～1週間に集中して発生します。

シナリオ3: Webhookの「発生時刻」とDBの「保存時刻」がズレる

Stripe・PayPal・Shopifyなど、海外発のSaaSはWebhookで「決済成立」「注文発生」を通知してきます。Webhookに含まれる時刻はほぼ全てUTCまたはUNIX秒です。これを「受信した瞬間の日本時間」でDBに保存すると、「決済発生時刻」と「DB登録時刻」が9時間ズレる記録ができあがります。

不正利用調査やチャージバック対応で「決済が起きた正確な時刻」を求められたとき、どの時刻が真実なのか分からなくなるのは大きな実務リスクです。3Dセキュア義務化後の不正利用対策でも、ログ時刻の信頼性は決定的に重要です。

シナリオ4: 月次レポートの締め日が、月初・月末でだけ合わない

「毎月1日と月末だけ、なぜかレポート数字が他のツールと合わない」という現象。原因はほぼ確実にタイムゾーンです。月末23時～翌月8時の注文が、UTC基準で集計されていると翌月扱いになる。月初0時～8時の注文が、JST基準のレポートでは当月初日、UTC基準では前月末日。

月の真ん中の日には誰も気づかないズレが、月初・月末・期末・年度末といった「区切り」のタイミングだけ顕在化する。経理・税務・株主向け数字に関わるので、影響は地味に大きいです。PQ会計の落とし穴でも触れたとおり、集計タイミングのズレは月次の利益数字に直接効いてきます。

5タイムゾーンを安全に扱う3つのルール

難しい技術は不要です。「内部はUTC、表示でJST、必ずオフセットを書く」――この3つを守るだけで、上に挙げたトラブルの大半は予防できます。

ルール1: 内部はUTCで統一する

DB・ログ・APIで時刻を保存・送受信するときは、すべてUTCに揃える。これが鉄則です。世界中のシステムがUTCを基準に動いている以上、内部時刻もUTCに合わせるのが矛盾を生みません。

「保存はUTC、表示でJSTに変換」というルールにしておけば、サーバー移行・クラウド移行で時刻ズレ事故が起きません。海外モール出店時もそのまま使えます。

ルール2: タイムゾーン情報を必ず書く

時刻を文字列で表記するときは、ISO 8601のオフセット付き形式で書く。これが第二の鉄則です。日付フォーマットの罠で解説したISO 8601は、タイムゾーンの曖昧さも同時に解決してくれます。

悪い書き方	良い書き方	理由
2026-04-08 09:30:00	2026-04-08T09:30:00+09:00	JSTかUTCか曖昧 → 明示する
2026-04-08T00:30:00	2026-04-08T00:30:00Z	UTCの場合は末尾にZを付ける
20260408093000	2026-04-08T09:30:00+09:00	区切り文字のない独自形式は他システムで読めない

ルール3: 表示する直前にだけJSTに変換する

「ユーザーに見せる」「管理画面に表示する」「CSVに書き出す」――この表示の最後の瞬間にだけ、UTC→JSTの変換をかけます。それ以外の処理（DBへの保存、API間のやり取り、ログ出力、集計バッチ）はすべてUTCのまま。

「集計したらJST」「DBに入れる前にJST」と中途半端に変換すると、UTCの値とJSTの値が混ざったDBができあがり、後から修正不能なゴミデータが残ります。「変換は最後の表示の1箇所だけ」を徹底するのが、長期的にいちばん事故が少ないアプローチです。

6自力対応の限界と、プロに任せるという選択肢

タイムゾーンの問題は、個別に見ると小さなズレです。受注時刻が9時間ズレている、レポートの数字が少しだけ合わない、海外との会議が1時間早く始まった――どれも単発で見れば「ちょっとした不便」で済みます。

しかし、これがEC業務の中で毎日、すべての注文・すべての集計・すべてのモールで繰り返されるとき、影響はじわじわと膨らみます。

• 毎月の売上数字が管理画面と合わないため、月次の確認に余計な時間が積み上がる
• セール時刻の指定ミスで、意図しない期間に意図しない価格で売り続ける
• クラウド移行のたびにバッチの実行時刻が9時間ズレ、深夜にやるべき処理が業務時間中に走る
• 不正利用やチャージバック調査で「決済が何時に発生したか」が信用できないログが残る

「タイムゾーンを意識する」「ISO 8601で書く」「内部はUTCに統一」――これらの対策はシンプルですが、すでに動いているシステムや業務フローに後からこのルールを徹底させるのは、自力では難しいのが正直なところです。モールAPIの仕様、自社DBのスキーマ、社内エクセル業務、クラウド移行計画――それぞれの場所でタイムゾーン処理を整える必要があり、業務フロー全体を理解した設計が必要になります。

「日次レポートが毎日合わなくて困っている」「モール連携を整理したい」「クラウド移行でバッチがズレた」――こうした課題は、EC実務とシステムの両方が分かる人間に相談するのが、結局いちばん早く片付きます。タイムゾーンは「分かっている人」が最初に設計に組み込むかどうかで、その後数年のトラブル発生件数が大きく変わります。