TL;DR

日本語の日付・時刻・数値フォーマットはロケール設定である程度まで対応できますが、ビジネスSaaSで肝心な慣習ほど、i18nライブラリは判断してくれません。どの暦を使うか（西暦2026年か和暦令和8年か）、ダッシュボードの会計年度表記をどうするか、大きな数値に万を使うかどうか、監査ログのタイムスタンプをどう整形するか。どれも、日本企業の商習慣を分かっている人が決めるべきことです。間違えても製品が動かなくなるわけではありません。ただ、人ではなくシステム任せでローカライズしたことが、日本のビジネスユーザーには伝わってしまいます。

主なポイント

ロケール設定で実際に処理できること、できないこと

i18nライブラリのロケールをja-JPにすると、一部のフォーマットについては信頼できる土台ができます。数値には日本語の小数点と千単位の区切りが付き、日付は年月日の順（2026年5月25日）になります。通貨記号も正しい位置に出て、タイムゾーンはAsia/Tokyoに設定できます。この土台には十分な価値があります。これがなければ日本のユーザーに「May 25, 2026」と表示され、「2026年5月25日」にはなりません。これは大きな問題です。

問題は、製品チームがロケール設定を日付・数値ローカライゼーションの出発点ではなく、ゴールとして扱いがちなことです。ロケール設定がやってくれるのは形式の骨組みまでです。ある場面でどの形式が適切かを決めるビジネス慣習、金融データを日本のビジネスユーザーに読みやすくする日本独自の桁の区切り方、日付が日本の制度に関わる場面で出てくる暦の問題には、手が届きません。

「ロケールが設定されている」と「日本語の日付・数値フォーマットが正しい」の間にある溝を埋めるのが、ローカライゼーションQAの役目です。この溝にある問題は、UIの文字列を眺めただけでは見えてきません。製品が選んでいるフォーマットが日本のビジネスで通用するかを見極めるには、日本企業が数をどう数え、どう報告し、時間をどう言い表すかを知っている人が必要です。

暦の選択：2026年か令和8年か

日本では西暦（seireki）と日本の元号（wareki）の両方が使われています。現在の元号は令和で、2019年5月に天皇陛下が即位された際に始まりました。2026年は令和8年にあたります。

SaaS製品で西暦と和暦のどちらを使うかは、業務の文脈に照らして決めることで、答えは製品の業界とユーザー層によって変わります。行政向けのソフトウェアや、医療・法律・金融サービスで国内のコンプライアンス対応に使う製品では、公式の日本語文書が和暦で書かれるため、和暦がよく使われます。テック企業・スタートアップ・グローバル企業向けの一般的なB2B SaaS製品なら西暦です。ユーザーが海外とのやり取りで使う暦と揃うからです。

よくある失敗は、暦の選び方を間違えることではなく、選び方がばらばらなことです。ほとんどの画面は2026年なのに、一部のレポートやPDFエクスポート、通知テンプレートだけ令和8年になっている。製品の各部分を別々のチームが別々の時期に作ると、こうなりがちです。これでは統一した日本語スタイルガイドなしに作った製品に見え、ローカライゼーション全体がちぐはぐな印象になります。

⚠ 製品内で不統一
ダッシュボード: 2026/05/25
PDFエクスポート: 令和8年5月25日
通知メール: May 25, 2026
同じ日付が3種類の異なる形式で表示されている。それぞれは技術的に正しくても、統一されたスタイルがないことが伝わってしまう。
✓ 統一された慣習
UI全体: 2026年5月25日
（業界・用途に応じて和暦への統一も可）
1つの形式を一貫して適用している。西暦か和暦かの選択は製品の日本語スタイルガイドに文書化されている。

会計年度の慣習：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つの点で影響があります。第一に、日本のビジネスカレンダーは日曜日ではなく月曜日から始まります。初期設定が日曜始まりのカレンダーウィジェットも動きはしますが、日本のビジネスの週の感覚とは少しずれます。第二に、日本は国民の祝日（祝日）が多く、営業日の計算に響きます。スケジュール管理・期限管理・請求サイクルの機能がある製品で日本の祝日を営業日計算に入れていないと、結果が間違ってしまいます。文字列のローカライゼーションでは片づかない問題で、日本の祝日カレンダーのデータソースを製品の日付ロジックに組み込む必要があります。

関連記事

製品の日付・数値フォーマットは日本のエンタープライズバイヤーに対応できていますか？

ミニ診断では、日本の財務・コンプライアンスチームが製品を評価するときに確かめるフォーマットの慣習を、漏れなく点検します。

ミニ診断を申し込む