1そもそも、なぜ国によって日付の順番が違うのか

「2026年5月5日」を書いてみてください。日本人なら多くが 2026/05/05。アメリカ人は 05/05/2026。イギリス人は 05/05/2026。フランス人は 05/05/2026。

――この日はたまたま全員一致します。月と日が同じだからです。では「5月7日」はどうでしょう？

• 日本: 2026/05/07（年→月→日）
• アメリカ: 05/07/2026（月→日→年）
• イギリス: 07/05/2026（日→月→年）
• 中国: 2026-05-07（年→月→日）
• ドイツ: 07.05.2026（日.月.年）

同じ日付なのに、書き方が4通り、区切り文字を含めれば5通り。「07/05/2026」だけを見せられたとき、これが5月7日なのか7月5日なのかは、書いた人の国を知らないと判別できません。

EC業務の現場では、これが「ちょっと困る」では済みません。海外モールから受け取った受注データの日付が1ヶ月ズレていた、海外SaaSのスケジュール設定が想定と違う日に発動した、海外仕入先への発注書の納期が誤解された――。「世界の日付フォーマットがなぜバラバラなのか」を理解しないまま海外取引に踏み出すと、必ずどこかで事故ります。

2世界の日付フォーマット完全マップ

世界の日付フォーマットは、ざっくり3つの「順序」と、いくつかの区切り文字の組み合わせで成り立っています。順序は次の3パターンしかありません。

順序	表記例	主な使用国・地域
YMD（年→月→日）	2026/05/07 2026-05-07	日本、中国、韓国、台湾、ハンガリー、リトアニア、イラン
MDY（月→日→年）	05/07/2026 May 7, 2026	アメリカ合衆国、フィリピン（一部）、カナダ（英語圏で混在）
DMY（日→月→年）	07/05/2026 7 May 2026 07.05.2026	イギリス、ドイツ、フランス、イタリア、スペイン、ロシア、インド、ブラジル、オーストラリア、ほか世界の大半

意外な事実: MDY（アメリカ式）を使っている主要国はアメリカだけ

世界地図に色を塗ってみると、MDY（mm/dd/yyyy）を公的に使っているのは、ほぼアメリカ合衆国だけです。カナダはバイリンガル国家ゆえに混在、フィリピンはアメリカの影響で部分的に使う程度。

つまり、「05/07/2026」を見て『5月7日』と読む国民は世界全体の5%にも満たないということになります。残りの大多数は「7月5日」と読みます。

3なぜアメリカは「月/日/年」を使うのか ― 各順序の歴史的背景

「合理的に考えれば、大きい単位から小さい単位（年→月→日）が一番自然」「あるいは小さい単位から大きい単位（日→月→年）が一貫していて分かりやすい」。そう考えると、アメリカの『月/日/年』が一番不自然に見えます。では、なぜこの順序が定着したのでしょうか。

YMD（年/月/日）の起源 ― 漢字文化圏とコンピュータの相性

日本・中国・韓国などの漢字文化圏は、伝統的に「大きい単位から小さい単位へ」記述する文化があります。「2026年5月7日」と書くのと同じ流れで、住所も「日本国 → 東京都 → 千代田区 → 番地」と大きい順。

この「大きい順」が、偶然にもコンピュータでの文字列ソート（並べ替え）と相性が抜群でした。「2026-05-07」を文字列のまま並べるだけで、自動的に時系列順に並ぶのです。これがYMDが国際標準ISO 8601に採用された大きな理由のひとつになります。

DMY（日/月/年）の起源 ― ヨーロッパの口語文化

ヨーロッパの主要言語では、日付を口で言うとき「7 May 2026（the seventh of May twenty twenty-six）」のように、日 → 月 → 年の順で発音します。これは中世のラテン語の慣習がそのまま受け継がれたもので、「ローマ暦の慣習を引き継いだ国＝ヨーロッパ全体」が共通でDMYを採用しました。

イギリスがDMYなのも、フランス・イタリア・スペイン・ドイツがDMYなのも、すべて口語の語順をそのまま書記化した結果です。世界の大半の国が「英国植民地」または「ヨーロッパの影響圏」だったため、DMYが世界で最も多数派になりました。

MDY（月/日/年）の起源 ― 18世紀イギリス由来の"古い英語"

意外なことに、MDY（May 7, 2026）はもともと18世紀のイギリス英語で使われていた書き方です。当時のイギリスでは「日付を書面に残すときは月を最初に書く」というスタイルが一般的でした。そのスタイルがそのまま北米植民地に持ち込まれ、アメリカ合衆国では今も残っているのです。

本国イギリスではその後DMYへ移行（口語と一致させるため）したのに対して、アメリカは独立後も古い書式を変えなかった。結果として「アメリカだけが世界と違う」という現代の状況が生まれました。

つまり、「合理性」ではなく「歴史と慣習」が世界の日付順を決めているのです。だから今後も統一されることは期待できません。

4区切り文字と曖昧さ ― 「.」「-」「/」の使い分け

順序の違いだけではなく、区切り文字もまた国によって異なります。これも「読み違い」の温床です。

区切り文字	主な使用国	例
/（スラッシュ）	日本、アメリカ、イギリス（口語的）	05/07/2026
-（ハイフン）	ISO 8601・国際標準・APIデータ	2026-05-07
.（ピリオド）	ドイツ、ロシア、デンマーク、ノルウェー、フィンランド	07.05.2026
区切りなし	Yahoo!ショッピングなど一部の独自フォーマット	20260507
月名+カンマ	アメリカ（フォーマル）、海外メール	May 7, 2026

2桁年「26/05/07」が引き起こす破滅的な曖昧さ

もうひとつの落とし穴が2桁年表記です。「26/05/07」と書かれていたとき、これは何を意味しますか？

• YMD・2桁年で読めば 2026年5月7日
• DMY・4桁年なし? と読めば 26年5月7日（紀元前？）
• MDY・古い慣習で読めば 5月7日 1926年 or 2026年?

2桁年は2000年問題（Y2K）で世界中が痛い目を見たにもかかわらず、いまだに見かけます。EC業務でCSVを扱うときも、「年は必ず4桁」を社内ルールとして徹底しないと、後から大規模なデータ修正が必要になります。

5ISO 8601 ― 唯一の「国際共通語」

世界中の国がそれぞれ違うフォーマットを使っている以上、「どれかひとつを国際標準にしよう」という動きが当然出てきます。それがISO 8601です。

ISO 8601が解決する3つの問題

1988年に制定されたISO 8601は、次の特徴を持ちます。

• 順序は YMD（年→月→日）に固定 ―― 大きい単位から小さい単位へ
• 区切り文字は ハイフン `-` に固定 ―― スラッシュもピリオドも使わない
• 年は必ず4桁 ―― 2桁年は禁止
• 時刻は `T` で区切り、タイムゾーンを `Z` または `+09:00` で明示

このフォーマットなら、どの国の人が読んでも、どのシステムが処理しても、解釈が1つに定まります。「05/07」が5月7日か7月5日か、なんて議論は永久に発生しません。

ISO 8601が普及している場面

EC・IT実務で、ISO 8601がデファクトになっている場面は次のとおりです。

場面	使用例
API（REST API、GraphQL）	レスポンスのtimestampはほぼISO 8601
JSON形式のデータ交換	"created_at": "2026-05-07T14:30:00+09:00"
データベースの日時カラム	PostgreSQL、MySQLの推奨フォーマット
ログファイル	アクセスログ・エラーログの標準
Amazon SP-APIなどのモールAPI	受注時刻・出荷時刻はISO 8601
Shopify、Stripe、PayPalなど海外SaaS	すべてのタイムスタンプ

つまり、「人間が見るとき」だけ国別の表記、「システムが扱うとき」はISO 8601、というのが現代の標準的な考え方になっています。

6EC実務で起きる「日付の読み違い」5つの典型パターン

世界の日付フォーマットが3通り×区切り文字3種類×年2/4桁あるという現実が、EC業務でどう事故るか。実際に現場で発生する典型パターンを5つ紹介します。

パターン1: 米国モールの受注日が1ヶ月ズレる

米国Amazon、米国eBay、米国Shopifyストアなどから受注CSVを取り込むとき、受注日が「03/04/2026」と書かれていた。日本のEC事業者がこれを「3月4日」と解釈すれば米国式読みで正解。だが、日本のシステムが「DMYの欧州式」で読み込む設定だった場合、4月3日と登録される。

1日や2日のズレなら気づきますが、「3/4 → 4/3」のような月跨ぎのズレは月次レポートで初めて発覚します。発覚した時には、すでに数百件の受注データが間違った日付で蓄積されています。

パターン2: 欧州サプライヤーの請求書日付がアメリカ式と取り違えられる

欧州サプライヤー（ドイツ・フランス・イタリアなど）からの請求書にはDMY（07.05.2026）またはDMY（07/05/2026）と書かれます。これを「アメリカ式のMDY」と勘違いして「7月5日」と読むと、本来5月7日締めの請求が2ヶ月遅れて処理される事故が起きます。

支払いサイトが厳しい欧州サプライヤーから、いきなり遅延損害金の請求が来た、というのは越境ECあるあるです。

パターン3: 海外SaaSの「2/3」が想定外の日に発動

海外発のSaaSツール（Mailchimp、HubSpot、Notionなど）でスケジュール送信やリマインダー設定をしたとき、UI上の「02/03」表示が米国式（2月3日）か欧州式（3月2日）かを確認せずに設定。結果、1ヶ月後に発動するはずの予約配信が翌月発動する。

SaaSによっては、ユーザーのアカウント言語設定で日付フォーマットが切り替わるため、同じUIでも担当者が違うと違う日付として表示されることすらあります。

パターン4: 海外取引先への納期が誤解される

日本側から海外取引先に「納期: 07/05/2026」とメール送信。日本人は「7月5日」のつもり、相手国は「5月7日」と読み、相手は2ヶ月早く納品しようとする。逆に納品が遅れるパターンもあります。

これを防ぐには、海外取引先への日付通知は必ず「2026-07-05」（ISO 8601）または「July 5, 2026」（月名スペル）にする社内ルールが必要です。

パターン5: 海外サーバー連携でCSVヘッダーの日付が崩れる

海外発のクラウドサービス（AWS、GCP、Cloudflareなど）の管理画面・ダッシュボードからCSVをダウンロードすると、サーバーのロケール設定によって日付フォーマットがその場で切り替わることがあります。

同じデータでも、月初にダウンロードしたCSVと月末にダウンロードしたCSVで日付フォーマットが違っていた、というケースは実際に存在します。「いつダウンロードしても同じ形式で出てくる」とは限らないのが、海外SaaSの怖いところです。

7海外取引で日付事故を防ぐ4つの実務ルール

世界の日付フォーマットを統一することは不可能です。だから、「自分たちの社内ルール」を決めて運用するしかありません。EC現場で実用的な4つのルールを紹介します。

ルール1: 海外への日付通知は ISO 8601 か「月名スペル」

海外取引先・海外サプライヤー・海外SaaSの設定など、海外に向けて日付を伝える場面では、絶対に「07/05/2026」のような数字＋スラッシュ表記を使わない。

• 推奨1: 2026-07-05（ISO 8601）
• 推奨2: July 5, 2026（月名スペル）
• 推奨3: 5 July 2026（月名スペル・DMY）

月名がスペルで書かれていれば、順序がMDYでもDMYでも「Julyは7月」と一意に決まります。誤読の余地がゼロになります。

ルール2: CSV取り込み時にフォーマットを「明示的に指定」する

海外モールから受け取ったCSVを取り込むとき、「このモールはMDY」「このサプライヤーはDMY」とモール別・取引先別に解釈ルールを明示する。

「自動判別」に頼ってはいけません。プログラムは「03/04/2026」を見ても、それがMDYかDMYかを判定できないからです。事故が起きた後で「自動判別がおかしかった」と気づくのは、すでに数百件のデータが間違って登録された後です。

ルール3: 内部DB・APIでは ISO 8601 で統一保存

自社のデータベースや社内システム間のやり取りでは、必ずISO 8601形式で保存・送受信する。表示する瞬間（管理画面、レポート、メール文面）にだけ、日本式「2026/05/07」に変換します。

これはタイムゾーンの罠でも書いた「内部UTC統一」と同じ思想です。「内部は厳格に標準化、表示の最後の瞬間にだけローカル化」が、長期的にバグが少ないアーキテクチャです。

ルール4: 2桁年は社内禁止

「26/05/07」のような2桁年表記は、社内ルールとして全面禁止にする。たとえ手書きのメモでも、できるだけ4桁で書く習慣を徹底する。

2000年問題は終わったように見えて、2桁年に起因するバグは現代でも頻発しています。古い社内システムや小規模なバッチ処理では、いまだに2桁年で動いているものがあります。それと連携する時に1世紀ズレた日付が登録される事故が起きます。

悪い例	良い例	理由
納期: 07/05/2026（海外宛）	納期: 2026-07-05（または July 5, 2026）	順序の解釈ミスを排除
CSVを「自動」で取り込み	モール別に日付フォーマットを明示指定	誤判別による全件汚染を防止
DBに「2026/05/07 14:30」と保存	DBには「2026-05-07T14:30:00+09:00」と保存	順序＋タイムゾーンの曖昧さを排除
Excelで「26/5/7」と入力	Excelで「2026/5/7」と4桁入力	2桁年問題の予防

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

日付フォーマットの問題は「知れば防げる」ものが多い反面、「すでに走り出している業務に後からルールを徹底させる」のは想像以上に難しい問題です。

毎日100件の海外受注を処理している会社で「明日からISO 8601で記録します」と決めても、過去のデータベースに溜まった古い形式の日付はどうしますか？ 取引先10社にメールで「日付はISO 8601で書いてください」とお願いしても、相手の社内システムが対応していない場合は？

• 過去データの一括コンバージョン（数年分のCSVを再解釈）
• 取引先ごとの日付フォーマット定義書の作成
• モール別・SaaS別の取り込みルールの整理
• 表示・保存・送受信の各レイヤーでの変換ロジック設計

これらは「EC業務の流れを全部理解した上で、システム側でも整える」必要があります。社内のExcel職人と外注のシステム会社では、ここの設計品質が大きく分かれる場所です。

「越境ECを始めたいが、日付・通貨・時差で何が起きるか想像できない」「複数モールの受注データを統合したいが、日付の扱いをどう設計すべきか分からない」――こうした相談は、EC実務とシステム設計の両方が分かる人間に投げるのが、結果的にいちばん早く解決します。日付処理は最初に正しく組み込むかどうかで、その後数年のトラブル発生件数が桁違いに変わる領域です。

関連して、日付フォーマットの罠（実務トラブル編）、タイムゾーンの罠（時差編）、越境ECの三重事故（時差・通貨・日付）もあわせてご覧ください。