TL;DR
日本語の日付・時刻・数値フォーマットはロケール設定で一部対応できますが、ビジネスSaaSで最も重要な慣習はi18nライブラリが代わりに判断してくれるものではありません。どの暦を使うか（西暦2026年か和暦令和8年か）、ダッシュボードの会計年度表記をどうするか、大きな数値に万を使うかどうか、監査ログのタイムスタンプをどう整形するか——これらはすべて、日本企業のビジネス文脈を理解した人間が判断する必要があります。これらを誤っても製品が壊れるわけではありませんが、ローカライズを人がではなくシステムが行ったことが日本のビジネスユーザーに伝わってしまいます。
主なポイント
- 日本の元号はロケール設定ではなくビジネス文脈の判断事項 — 令和8年と2026年のどちらを使うかは製品の業界とユーザー層によって異なります。どちらも正しいですが、文脈によって意味合いが変わります。
- 日本のほとんどの企業の会計年度は4月始まり — 会計年度の文脈なしにダッシュボードで「Q1」を表示すると、Q1が4〜6月の日本のユーザーにとって混乱を招きます。
- 万（10,000）は日本語の大きな数値の自然な単位 — 金融文脈では1,000,000円と表示するより100万円の方が自然です。ロケール設定では万フォーマットは適用されません。
- 24時間制は日本のビジネスソフトウェアの標準 — 午前/午後（AM/PM）表記は馴染みがありますが、日本のエンタープライズSaaSでは24時間制の方が標準的です。
- 日付ピッカーのローカライズはカレンダー表示だけではない — 週の始まり、祝日カレンダー、会計期間の境界はすべて、日本のユーザーが日付選択UIを使う際の体験に影響します。
ロケール設定で実際に何が処理され、何が処理されないのか
i18nライブラリのロケールをja-JPに設定すると、特定のフォーマット判断に対して信頼性の高いベースラインが得られます。数値には日本語の小数点と千単位の区切りが付きます。日付は年月日の順で表示されます（2026年5月25日）。通貨記号が正しい位置に表示されます。タイムゾーンをAsia/Tokyoに設定できます。このベースラインは価値あるものです——なければ日本のユーザーに「May 23, 2026」が「2026年5月25日」の代わりに表示されることになり、それは大きな問題です。
問題は、製品チームがしばしばロケール設定を日付・数値ローカライゼーション作業の終わりとして扱い、始まりとして扱っていないことです。ロケール設定は構造的なフォーマットを処理します。しかし、特定の文脈でどのフォーマットが適切かを決定するビジネス慣習、日本のビジネスユーザーにとって金融データを読みやすくする日本固有のグルーピング慣習、日付が日本の制度的な生活に関わる形で参照されるときに生じる暦系の疑問については、処理しません。
「ロケールが設定されている」と「日本語の日付・数値フォーマットが正しい」のギャップこそが、ローカライゼーションQAが価値を発揮する場所です。このギャップにある問題はUIの文字列を見ただけでは明らかではありません——製品が行っているフォーマットの選択が日本のビジネス用途として適切かどうかを評価するには、日本企業がどのように数を数え、報告し、時間について話すかを理解した人が必要です。
暦の選択：2026年か令和8年か
日本では西暦（seireki）と日本の元号（wareki）の両方が使われています。現在の元号は令和で、2019年5月に天皇陛下が即位された際に始まりました。2026年は令和8年にあたります。
SaaS製品で西暦と和暦のどちらを使うかは、実際のビジネス文脈の判断事項です。答えは製品の業界とユーザー層によって異なります。行政向けソフトウェアや、日本国内のコンプライアンスのために医療・法律・金融サービスで使われる製品では、公式な日本語文書で和暦が使われるため、頻繁に和暦が用いられます。テック企業・スタートアップ・グローバルビジネスをターゲットにした一般的なB2B SaaS製品では、ユーザーが国際的なコミュニケーションでも使うカレンダーと一致するため、西暦が使われます。
最も多い失敗は、間違った暦を選ぶことではなく、一貫した選択をしないことです。ほとんどの画面では2026年を表示しながら、一部のレポート・PDFエクスポート・通知テンプレートでは令和8年が表示される製品（製品の異なる部分が異なるタイミングで異なるチームによって作られたため）は、統一された日本語スタイルガイドなしに作られた製品だという一貫性のないローカライゼーションの印象を与えます。
PDFエクスポート: 令和8年5月25日
通知メール: May 23, 2026
（業界・用途に応じて和暦への統一も可）
会計年度の慣習：Q1問題
日本のほとんどの企業は4月1日から3月31日の会計年度で運営しています。つまり、Q1（第1四半期）は4月・5月・6月です。Q4（第4四半期）は翌暦年の1月・2月・3月です。
1月〜12月の会計年度を前提に作られた海外SaaS製品は、日本の財務チームが業績を追跡する方法と構造的に相容れない形で四半期データを表示します。「Q1 2026」が1月〜3月を意味するダッシュボードは、日本企業にとっては「2025年度Q4」（2025年度第4四半期）に相当します。これは見た目だけの問題ではありません——日本の財務チームが予算報告・目標管理・業績評価にこの製品を使うとき、データの読み間違いというリアルなリスクが生じます。
解決策は、設定可能な会計年度設定（多くのエンタープライズSaaS製品がこれを提供しています）を採用するか、または暦年の前提を日本のユーザーに明示的に表示することです。「Q1 2026（1月〜3月）」というラベルのグラフであれば、月が明示されているため会計年度が一致しなくても日本の財務チームにとって使えます。「Q1 2026」だけで月の説明がないグラフは、サポートリクエストや契約更新の会話で表面化する曖昧さを生みます。
| 四半期ラベル | 前提（1月〜12月） | 日本企業の標準（4月〜3月） | 表記のベストプラクティス |
|---|---|---|---|
| Q1 2026 | 1月〜3月 | 4月〜6月 | Q1（1月〜3月）と表記して月を明示 |
| Q2 2026 | 4月〜6月 | 7月〜9月 | Q2（4月〜6月）と表記 |
| Q3 2026 | 7月〜9月 | 10月〜12月 | Q3（7月〜9月）と表記 |
| Q4 2026 | 10月〜12月 | 1月〜3月（翌年） | Q4（10月〜12月）と表記 |
万の単位：日本の金融数値の実際の読まれ方
日本語には1,000ではなく10,000（万、読み方：まん）で数値をグルーピングする固有の単位があります。これは数値の金融データを表示する製品にとって、最も実用上重要なローカライゼーションの違いの一つです。1,000,000は英語では百万（one million）ですが、日本語での自然な読み方は100万（ひゃくまん、「100の万」の意味）です。
SaaS製品が収益・予算・取引データを西洋の千単位でコンマ区切りしたフォーマット——「¥1,000,000」——で表示すると、日本の財務チームは頭の中で換算しなければなりません。換算は難しくありませんが、読む数値ごとに余分な認知ステップが発生します。「¥100万」と同じデータを表示する製品はこの換算を不要にし、日本の財務担当者が実際にこれらの金額について考える方法に合致した財務ダッシュボードを生み出します。
課題は、万が Unicode のロケール対応単位ではないため、標準のi18nライブラリが万フォーマットを適用しないことです。万ベースの数値表示を実装するには、カスタムのフォーマット関数——通常は10,000以上の数値を万表記に変換する小さなJavaScriptユーティリティ——が必要です。これは一度行えばよいエンジニアリング作業であり、日本のユーザーに金融データを表示する製品に対して永続的なローカライゼーションの価値をもたらします。
万フォーマットの適用範囲についての実践的メモ：万ベースの表示は1万円以上の金額に最も有効です。それ以下の金額では全桁表示（¥9,800）の方が標準的です。1億（1億 = 1,000万の10倍）を超えると、億という単位に変わります——¥120,000,000ではなく¥1億2,000万です。完全な日本の金融数値フォーマッターは、適切な閾値で円・万・億を処理します。億を処理せずに万フォーマットだけを表示する製品は、大きな取引金額に対しておかしな出力を生み出します。
監査ログと活動フィードのタイムスタンプ書式
活動ログ・監査証跡・通知タイムスタンプは、ダッシュボードグラフとは異なる一連のフォーマット判断を必要とします。活動フィードを読む日本のユーザーが探しているのは2つのことです——何かが起きた時刻（相対的または絶対的な時間）、そしてタイムスタンプが監査目的に十分な精度があるかどうかです。
相対時間フォーマット（「3分前」「昨日」）は日本語でも機能します——「3分前」「昨日」——しかし精度の期待が異なります。特に財務・人事・コンプライアンス上重要なワークフローにおいて、日本のエンタープライズの文脈では、相対時間よりも絶対的なタイムスタンプが強く好まれます。「2026年5月25日 14:32:07 JST」を示すログエントリは、「2時間前」と示されるものより、技術的にはどちらも正確であっても、日本のコンプライアンス担当者にとって信頼性が高く見えます。相対フォーマットは「前」がどのタイムゾーンでカウントしているのかという疑問を生じさせます。
コンプライアンスや監査要件を持つ日本のエンタープライズユーザーを対象とする製品のベストプラクティスは、すべての監査ログと活動フィードの文脈で明示的なJSTタイムゾーン付きの完全なISO形式のタイムスタンプを表示し、監査精度が不要な日常的な活動の文脈（最近のコメント、通知フィードなど）にのみ相対時間を使用することです。
日本語ローカライゼーション向け日付フォーマットQAチェックリスト
暦の慣習が文書化され、一貫して適用されている
製品には西暦（西暦）か和暦（和暦）かの表示について文書化された判断がある。UI・メール通知・エクスポート書類を通じて同じ形式が一貫して使われている。
四半期ラベルに月の範囲が含まれている
UIのすべての「Q1/Q2/Q3/Q4」ラベルに対応する月が明示されており、4月〜3月の会計カレンダーで運営している日本のユーザーにとっての会計年度の曖昧さを解消している。
金融金額で万/億フォーマットのレビューが完了している
¥10,000以上の金融データ表示について、万単位フォーマットの適用機会がレビューされている。万フォーマットを実装しない場合、製品スタイルガイドにその理由と日本のユーザーがどのようにデータを読むことを期待しているかが記載されている。
監査ログとコンプライアンス上重要なタイムスタンプは絶対形式でJSTを使用している
監査・コンプライアンス・法的文脈のすべてのタイムスタンプが YYYY年MM月DD日 HH:MM:SS JST 形式で表示されている。これらの文脈では相対時間（「X時間前」）は使用していない。
日付ピッカーのカレンダーが日本のビジネス週に合わせて月曜始まりになっている
日付ピッカーが日本のカレンダー慣習で表示されている：週が月曜始まり、製品の予約またはスケジュール機能に関連する場合は日本の国民の祝日がマークされている。
ビジネス文脈の時刻表示が24時間制を使用している
会議時間・締切時間・ログタイムスタンプなどのビジネス文脈の時刻表示が24時間制を使用している。AM/PM表記は、ビジネス以外のユーザーにとってより直感的な場合があるコンシューマー向けの文脈のために予約されている。
よくある質問
SaaS製品は西暦と和暦の両方の表示をサポートすべきですか？
ほとんどのB2B SaaS製品にとって、ユーザーが設定で選択できる形が理想ですが、必ずしも実現可能とは限りません。一般的な日本企業を対象とした製品では、画面全体を西暦（2026年）で統一し、公式な行政手続きで使用するエクスポート書類にのみ和暦表示のオプションを設けるのが現実的なアプローチです。医療・法律・行政関連のセクターで使われる製品については、これらの分野の公的書類では和暦が一般的なため、和暦を主要な形式として検討すべきです。
日本のユーザーは通貨記号として¥を使うべきか、それとも円という文字を使うべきですか？
文脈によってどちらも標準的に使われます。¥記号はコンパクトで広く認識されているため、ダッシュボード・入力欄・サマリー表示などのほとんどのUI場面で使われます。一方「円」という文字は、請求書・契約書・コンプライアンス文書・公式通知など、書面的な文脈で使われます。ダッシュボードの「¥100,000」と公式書類の「金額：100,000円」はどちらも正しい表記です。避けるべき失敗は、どちらも使わないことです。日本のフィンテックSaaS製品で通貨単位を示さない「100,000」のような金額表示をすると、yen・千円単位など単位が何なのか曖昧になってしまいます。
日本のユーザーはダッシュボードのパーセンテージをどのように読みますか？
日本語のパーセント表記は明快で、「25%」は普遍的に使われます。複雑なのは周辺のコピーです。英語では「a 25% increase」と言うところ、日本のビジネス慣行では「25%増加」または（ポイントの増加を区別したい場合）「25ポイント上昇」と表現します。「パーセント」と「%」の使い分けは文脈次第です。データ表示では「%」、説明文では「パーセント」が使われることがあります。最も多いローカライゼーションの誤りは、「%」が慣用表現のところで「25 percent」を直訳して「25パーセント」と書いてしまうことです。
日本語で日付の範囲はどのように表記するのが正しいですか？
日本語の日付範囲は、文脈に応じて〜（波ダッシュ）またはから〜まで構文を使います。日付範囲ピッカーのようなコンパクトなUI要素では「2026年5月1日〜2026年5月31日」または「5/1〜5/31（2026年）」、公式な文章では「2026年5月1日から2026年5月31日まで」と表記します。〜は日本語UIでの範囲表示として標準です。英語スタイルのenダッシュ（「5/1 – 5/31」）を使う製品もありますが、日本語の慣習ではなく、日本のユーザーは読めても外国スタイルの書式として認識します。
日本の労働週の慣習はカレンダーのローカライゼーションに影響しますか？
はい、2つの点で影響します。第一に、日本のビジネスカレンダーは月曜日（月曜日）始まりで、日曜始まりではありません。日曜始まりのデフォルト設定のカレンダーウィジェットは技術的には機能しますが、日本のビジネス週の認識とは若干ずれています。第二に、日本には豊富な国民の祝日カレンダー（祝日）があり、営業日計算に影響します。スケジュール管理・期限管理・請求サイクル機能を持つ製品において、日本の祝日を営業日計算に組み込まない場合、誤った出力が生じます。これは文字列のローカライゼーションを超えた問題で、製品の日付ロジックに日本の祝日カレンダーデータソースを統合することが必要です。