日付ピッカーは、ローカライズした製品が「外国製」に見えてしまう、もっとも起きやすい箇所のひとつです。日本のユーザーは、必要な場面では元号（和暦）を、週末を赤と青で示す日曜始まりの週を、グリッド上に示された祝日を、そしてオフィスが実際にいつ閉まっているかを踏まえた営業日ロジックを期待します。この記事では、日本語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」を時刻の後ろに付けることはしません。カレンダーの曜日ヘッダーはローマ字の略記ではなく、一文字の漢字（月火水木金土日）にします。一つひとつは小さな慣習でも、合わさると、日付がネイティブに読めるか、未訳の英語文字列に見えるかが決まります。
月曜始まりのグリッド、英語の曜日ラベル、抜け落ちた祝日、ゴールデンウィークを無視した営業日計算、そして暦年だけの期間選択。これらは、日本の予約フローが外国製に感じられる構造的な理由です。焦点を絞ったQAレビューで、どのカレンダー・日程の前提が日本のユーザーにとって壊れているのかを突き止められます。