日付ピッカーは、ローカライズした製品が「外国製」に見えてしまう、もっとも起きやすい箇所のひとつです。日本のユーザーは、必要な場面では元号（和暦）を、そして赤と青で示された週末を持つ日曜始まりの週を、グリッドに表示された祝日を、さらにオフィスが実際にいつ閉まっているかを知っている営業日ロジックを期待します。この記事では、日本語UIを「翻訳された」ものではなく「ネイティブ」に感じさせる、カレンダーと日程まわりの判断を扱います。
日本は2つの年表記を並行して使っています。西暦の年は2026です。元号の年、和暦は現在「令和」で、2026年は令和8年にあたります。どちらも日常的に使われており、海外のソフトウェアが犯しがちな間違いは、必ずどちらか一方を選ばなければならないと思い込むことです。正解は文脈次第で、どちらの方向に間違えても摩擦を生みます。
一般的なスケジューリング、予約、そして大半の消費者向け・B2B向けSaaS UIでは、西暦が安全な既定値です。日本のユーザーは、予定・締切・カレンダーの予定について2026年と読み書きすることにまったく抵抗がありません。気軽な予約フローに和暦を強制するのは、英語のアプリが年号にローマ数字を使うことを英語話者に強いるのと同じで、妙に堅苦しく感じられます。
とはいえ、和暦はどこでも省略してよいものではありません。行政の書類、公的文書、契約書、確定申告、保険、そして多くの金融商品では、今も元号表記が期待され、ときに法的に求められます。公的な申請に対応するフォームで西暦しか受け付けないFinTech製品は、ユーザーに頭の中で変換させることになりますし、保険や医療の製品が証券の日付を西暦のみで表示すれば、ユーザーが手にしている紙の書類と食い違うかもしれません。失敗の典型は、単一の体系を決め打ちすることです。ローカライズされたやり方は、日常のUIでは西暦を既定としつつ、公的・法的・行政に近い業務に触れる箇所では和暦の入力・表示にも対応すること——そうした文脈では、たとえば 2026年（令和8年）のように両方を示すのが理想です。
元号にはもう一つの細かな点があります。元号の境目は暦年と一致しません。令和は2019年の途中に始まったため、元号の最初の年（元年）や元号の切り替わりは、日付計算や過去の記録でエッジケースを生むことがあります。和暦に対応するソフトウェアは元年（元号の「1年目」は1年ではなく元年と書く）を扱える必要があり、10年ごとに元号がきれいに切り替わるといった前提を置いてはいけません。
日本の壁掛けカレンダー、手帳、印刷された予定表をほぼどれでも開いてみると、週は日曜（日）から始まっています。これは日本で支配的な慣習であり、それに伴う視覚的な文法があります。日曜は赤、土曜は青で印刷され、この2つが並ぶと一目で週末だと読み取れます。国民の祝日も赤で示され、「休業日」という視覚言語を共有しています。
多くのカレンダーや日付ピッカーは、週の始まりを開発者のロケールやライブラリの既定値から受け継ぎます——多くは月曜（ISO標準）か、配色のない米国式の日曜始まりです。月曜始まりのグリッド自体が抽象的に「間違い」なわけではありませんが、見慣れた形を目で追う日本のユーザーにとっては、どこか違和感があります。列がずれていて、週末が目の期待する位置になく、週末や祝日が平日と視覚的に区別されていないのです。ユーザーは形を「認識」する代わりに、グリッドを数え直さなければなりません。
曜日の略記そのものも一文字の漢字です。月火水木金土日（月曜から日曜）。日本のカレンダーのヘッダーは、ローマ字の「Mon/Tue」やフル表記ではなく、この一文字の形を使います。日本語UIで「Mon Tue Wed」と表示する日付ピッカーは、周辺のUIだけが訳されてカレンダーはローカライズされていない、という即座のサインです。
日本には16の国民の祝日が一年を通じてあり、元日（1月1日）から天皇誕生日、そして4月下旬から5月上旬のゴールデンウィークと呼ばれる祝日の集中する時期まで広がっています。これらの日には、多くのオフィス・銀行・行政サービスが休業します——つまり、予定を組み、予約し、出荷し、決済するソフトウェアは、これらの日を知っている必要があります。
他国向けに書かれた祝日ロジックをつまずかせる追加ルールがあります。振替休日です。国民の祝日が日曜と重なると、翌営業日が代わりに休日になります。ですから、固定の日付しか持たない素朴な祝日リストは、祝日が日曜に当たる年にはどこかで間違います——振替の日を丸ごと見落とし、休業日を営業日として示してしまうのです。
実務的には、これは日付を決め打ちするのではなく、最新の日本の祝日カレンダーを読み込んで保守することを意味します。祝日の日付は変わり得ます——「第3月曜日」のようなルールで定義されるもの（ハッピーマンデー）もあれば、政府が特別な行事のために一度限りの祝日を追加することもあります。日本向けの製品は、祝日カレンダーを毎年更新されるデータとして扱い、日付ピッカーでは祝日を視覚的に（多くは日曜と同じ赤で）示し、あらゆる営業日計算から除外すべきです。
日本の時刻表示は2つの形式に対応し、どちらが適切かは画面次第です。24時間制は一般的で曖昧さがなく——14:00 は広く理解され、交通の時刻表・業務システム・公式スケジュールで標準です。12時間制は午前（文字どおり「正午の前」）と午後（「正午の後」）を使い、時刻の前に置きます。午後2時であって、2時午後ではありません。英語の「2:00 PM」のレイアウトをそのまま移植して時刻の後ろに午前/午後を置いたり、ラテン文字の「AM/PM」を使ったりすると、未訳に読めます。
本文やUIの日付は、一文字の形で曜日を括弧付きで添えるのが一般的です。2026年6月11日（木）——年・月・日、そして括弧内に曜日の木（木曜）。この「（曜日）」の慣習は日本の日程の文脈に広く浸透しており、これを含めると日付が正しく整形されているように感じられます。曜日を省いたり英語で綴ったりするのは、どちらも日付の書式がローカライズされていない小さなサインです。
「3営業日以内」のように表現される見積もりは、日本の商取引・サポート・金融に絶えず登場します——日本語では営業日です。「3営業日以内」を読むユーザーは、その数え方が週末と国民の祝日を除外していることを期待します。暦日で数えたり、週末や祝日を営業日として数えたりするソフトウェアは、単純に間違った見積もりを出します。ゴールデンウィークをまたいで約束された「3営業日」の配送は、システムが表示した日付よりはるかに遅く届きます。
正しい営業日ロジックには、上で述べた祝日カレンダーと、週末の除外を組み合わせる必要があります。さらに、振替休日が営業日として数えられないよう、振替休日ルールも扱う必要があります。これは見た目だけの問題ではありません——出荷の期間、決済日、SLAの約束、サポートの返答時間において、営業日の数え方は製品がユーザーに対して交わす約束だからです。
日本の日程をもう一つ作り替える日付の概念が、年度です。日本のほとんどの組織——企業・学校・行政——では、年度は多くの場合4月1日に始まり、翌年の3月31日に終わります。これは暦年（年）とは別物です。日本のユーザーが報告期間や年間計画、「今年」のフィルターを見るとき、その頭の中のモデルは1月ではなく4月を境にするかもしれません。学校の年度、採用サイクル（新卒採用）、予算サイクル、そして多くのサブスクリプションや報告のフローは、すべて年度に揃っています。1月から12月の期間しか提供せず、年度の概念を持たないダッシュボードやスケジューリングツールは、日本のビジネスユーザーにあらゆる年間の数字で頭の中の計算を強いることになります。
ローカライズされたやり方は、年間の期間が現れる箇所ではどこでも年度ベースの期間を第一級の選択肢として提供すること——2026年4月から2027年3月まで走る「2026年度」の範囲を、暦年と並べて——そして、どちらの境界を見ているのかユーザーが分かるよう、明確にラベル付けすることです。
カレンダーのグリッドの仕組みを超えて、日程まわりの言葉そのものにも独自の慣習があります。中心となる名詞は予約で、来店予約・レストランの席・会議の枠などに等しく使われます。互いに都合のよい時間を見つける行為——英語で「scheduling」と呼ぶやり取り——は日程調整であり、日本のビジネス文化では独立した、認知された概念です。相手に選んでもらうために複数の候補日を提案することがよくあります。
予約のコピーは、直訳ではなくこうした定着した用語を使うべきです。「Book now」を直訳したボタンはぎこちなく着地しかねません。「予約する」が自然な形です。時間を提案するフローは、それらを候補として枠組みし、「let's find a time」の直訳ではなく日程調整の枠組みを使うべきです。そして、日本のビジネスコミュニケーションは取引の場面で丁寧さに寄るため、確認やリマインダーのコピーは、ぶっきらぼうな命令調よりも、ですます調——「ご予約ありがとうございます」——の方がよく読まれます。
月曜始まりのグリッド、英語の曜日ラベル、抜け落ちた祝日、ゴールデンウィークを営業日として数える営業日計算——これらは、日本の予約フローが外国製に感じられるもっともよくある原因です。日本語ローカライゼーションQAレビューは、どのカレンダー・日程の前提が日本のユーザーにとって壊れているか、そしてそれをどう直すかを正確に突き止めます。
ミニ診断を申し込むソフトウェアでは和暦と西暦、どちらを表示すべきですか？
文脈によります。一般消費者向け・B2B向けのSaaS UIの大半は西暦（2026年）を主たる表記にでき、日本のユーザーは日常的なスケジュール管理ではまったく違和感なく扱えます。一方で和暦——現在は令和——は、行政の書類、公的文書、契約書、確定申告、多くの金融・保険の商品では今も期待される、あるいは法的に求められます。安全な原則は、一般的なスケジューリングUIでは西暦を既定とし、公的・法的・行政に近い業務に触れる箇所では和暦の入力・表示にも対応することです。どちらか一方の体系を決め打ちすることが失敗の典型です。
なぜ日本のユーザーにとって週が「違う曜日」から始まって見えるのですか？
多くのカレンダー部品は、日本の慣習ではなく開発者のロケールに基づいて、月曜や米国式の週の始まりを既定にします。日本では紙でもデジタルでも、カレンダーは圧倒的に日曜（日）始まりで、日曜は赤、土曜は青で示されます。月曜始まりの、あるいは週末や祝日を視覚的に区別しない日付ピッカーは、どこか外国のものに感じられ、ユーザーはグリッドを数え直さなければなりません。日曜始まりの慣習と赤・青の週末配色を尊重することは、小さな変更でカレンダーをネイティブに感じさせます。
日本の祝日はスケジューリング・予約ソフトにどう影響しますか？
日本には16の国民の祝日があり、祝日が日曜と重なると翌営業日が振替休日になります。日本の祝日を無視したスケジューリング・予約・営業日のロジックは、オフィスが閉まっている日に枠を提示したり、配送・決済の日付を誤算したり、間違った営業日の見積もりを出したりします。日本向けのソフトウェアは、最新の日本の祝日カレンダーを読み込み、振替休日も考慮し、日付ピッカーでは祝日を（多くは日曜と同じ赤で）示すべきです。
年度とは何で、なぜ期間の選択で重要なのですか？
年度は会計・事業の年で、日本のほとんどの組織では多くの場合4月1日に始まり3月31日に終わります。暦年（年）とは別物です。学校の年度、採用サイクル、予算、多くの報告フローは年度に揃っているため、日本のユーザーが年間の期間や「今年」のフィルターを見るとき、その頭の中のモデルは1月ではなく4月を境にするかもしれません。暦年と並べて年度ベースの範囲（例：2026年度＝2026年4月〜2027年3月）を、明確にラベル付けして提供すれば、日本のビジネスユーザーから頭の中の計算をなくせます。
日本語UIでは日付と時刻をどう書式設定すべきですか？
日付は年・月・日の順で、括弧内に一文字の曜日を添えます：2026年6月11日（木）。時刻は24時間制（14:00）か、午前／午後を時刻の前に置く12時間制（午後2時）を使い——ラテン文字の「AM/PM」を時刻の後ろに置きません。カレンダーの曜日ヘッダーは一文字の漢字（月火水木金土日）で、ローマ字の略記ではありません。これらの慣習は個々には小さくても、合わさって、日付がネイティブに読めるか、それとも未訳の英語文字列に読めるかを決めます。