- 日本語UIの「文体」（文章全体に通っている敬語レベル）は、意識して決められることがほとんどありません。日本語ユーザーが「翻訳感が出ている」と感じる原因の多くは、ここにあります。
- B2B SaaSおよびFinTechにおいて、基本文体として正しいのは丁寧語（です・ます体）です。ボタンラベルはプロダクトの種類に関わらず体言止めを使用すべきです。
- 一つのプロダクトの中で文体が混ざっていると、一つひとつの文字列が正しくても、日本語ユーザーには品質が低いと映り、あらゆる接点で信頼が損なわれます。
- 解決策は、翻訳後のQAチェックではなく、翻訳前の文体の仕様の策定です。
- 文体はローカライゼーションの最初の決断です。丁寧語・普通体・ハイブリッドのどれを使うかは、翻訳開始前に決定しなければなりません。QAで不整合が発覚してからでは遅いのです。
- ボタンラベルは常に体言止めにします。すべてのプロダクトタイプと文体にわたって、日本語のボタンラベルは動詞なしの名詞形（保存、削除、送信）を使うべきです。「する」や「します」を追加しても価値は増えず、文字数が増えるだけです。
- エラーメッセージはカジュアルなプロダクトでも丁寧語が必要です。ユーザーがいちばん安心を求めるのは、システムに障害が起きた瞬間です。「エラーが発生した」のような普通体のエラーメッセージは不安をあおります。お詫びの一言を添えた丁寧語で、ユーザーが次に進めるよう導きましょう。
- 文体の不整合は、誤った文体の選択より有害です。一つひとつの文字列は技術的に優れていても文体が混ざっているプロダクトより、丁寧語で統一したプロダクトのほうが良い結果を出します。
- 「フローテスト」が最善のQAチェックです。日本語ネイティブのプロフェッショナルにプロダクトを最初から最後まで通して読んでもらい、トーンを一言で表現してもらいます。「ばらばら」という答えが返ってきたら、文体に問題があります。
誰も教えてくれない問い
外資系SaaS企業の日本語ローカライズは、たいてい次の流れで進みます。文字列を翻訳し、バイリンガルのレビュアーに確認してもらい、リリースする。この中でほとんど行われないのが、「文体」を意識して決めることです。文体とは、UIのすべての文章に通っている敬語レベルを指します。
これは見た目だけの問題ではありません。日本語にははっきり区別される敬語レベルがいくつかあり、どれを使うかでプロダクトの印象はまったく変わります。文体を誤ると、ただ妙に聞こえるだけでなく、「このプロダクトは自分たちのユーザーを理解していない」と受け取られます。日本のB2B SaaSでは、そう感じたユーザーが価格ページにたどり着く前に離れていくことが少なくありません。
救いもあります。SaaSの日本語で文体がどう働くかが分かれば、適切な文体は筋道立てて選べるようになります。本記事では、プロダクトのあらゆる接点で自信を持って判断できるよう、実践的なフレームワークとビフォーアフターの例を紹介します。
文体は礼儀正しいかカジュアルかという問題ではありません。日本のために作られたプロダクトなのか、日本に輸出されたプロダクトなのかを示すものです。
日本語SaaSにおける「文体」の意味
ここでいう「文体」は、話し手や書き手が使う言葉の改まり具合を指します。日本語では、これが英語よりはるかに体系立っています。日本語を母語としない人の多くは、日本語の敬語を敬語（丁寧）か普通体（カジュアル）かの二択でとらえています。しかし実際のSaaSプロダクトでは少なくとも4つのレベルが使い分けられていて、日本語ユーザーはそれぞれから違う印象を受けます。
Sonkeigo / Kenjōgo
Teineigo
Hybrid / Nominal
Plain Form
大事なのは、これらのレベルが単に「より丁寧」か「より丁寧でない」かの違いではないことです。レベルごとに伝わるものがまったく違います。丁寧語からは専門性と敬意が、尊敬語からは組織としての重みが、普通体からは気軽さが伝わります。普通体はコンシューマーアプリには合いますが、B2Bプロダクトでは雑な印象になりがちです。体言止めを使うハイブリッドな書き方（動詞なし・名詞止め）は妥協の産物ではありません。ほぼどんなプロダクトでも、ボタンラベルやUIの操作に最も適した選択です。
誤った文体がもたらす代償
日本語ユーザーは、プロダクトを使いながら文体をいちいち意識して分析したりはしません。それでも、何かがずれていればすぐに気づきます。ローカライズされたSaaSプロダクトでよく見かける文体の誤りは、大きく3つに分けられます。
- 過剰な丁寧さ：UIコピーに尊敬語セルフサービス型のSaaSプロダクト全体を丁重な敬語で書くと、使いづらさが生まれます。ボタンを押すたびに改まった手紙のような言い回しが出てくれば、インターフェースはプロらしく見えるどころか、重くて遅いものに感じられます。
- 不十分な丁寧さ：B2Bツールでの普通体普通体（だ・である体の語尾）は、カジュアルで、ときに無愛想に響きます。開発者向けのCLIやコンシューマーアプリなら合いますが、エンタープライズ向けソフトウェアやFinTech、ユーザーがデータやお金を預けるプロダクトでは、突き放されたように感じさせます。
- 不整合：ページをまたいだ文体の混在最もよく見られ、最も害の大きい誤りです。オンボーディングでは丁寧語、エラーメッセージでは普通体、価格ページではその両方が入り混じる。そうなると、プロダクトの中で統一が取れていないように見え、その不統一は品質管理ができていない証拠として受け取られます。
不整合の問題は、特に強調しておきます。ローカライズされたSaaSプロダクトのQAレビューでは、文体の混在がほぼ毎回、指摘事項の上位3つに入ります。原因も決まって同じです。時期も、ツールや翻訳者もばらばらのまま、文体の仕様なしに文字列が翻訳されているのです。一つひとつの訳は許容範囲かもしれません。それでも全体としては、設計されたものではなく寄せ集めのように感じられるプロダクトになります。
意思決定フレームワーク：あなたのプロダクトに合った文体とは
文体は気分で選ぶものではなく、プロダクトの種類、対象ユーザー、ブランドの立ち位置という3つの要素から決まります。日本市場に参入するSaaSのカテゴリーを網羅した、実践的な判断表を以下に示します。
| プロダクトタイプ | ターゲットユーザー | 推奨文体 | 避けるべきもの |
|---|---|---|---|
| B2B SaaS（人事・CRM・ERP） | エンタープライズバイヤー、マネージャー | 全体に丁寧語 | 普通体、過度な尊敬語 |
| FinTech / 決済プラットフォーム | 財務チーム、CFO | 丁寧語＋法的・請求関連は尊敬語 | 決済フローでの普通体 |
| 開発者ツール / API | エンジニア、CTO | 体言止め＋ドキュメントは普通体 | 技術的UIでの重い敬語 |
| コンシューマー / 生産性アプリ | 個人ユーザー、フリーランサー | 丁寧語UI＋体言止めボタン | 尊敬語（堅すぎる印象） |
| AI / コパイロットツール | ナレッジワーカー | 丁寧語UI＋AIレスポンスは普通体 | フロー内での不規則な混在 |
| セキュリティ / コンプライアンスSaaS | IT管理者、コンプライアンスチーム | 丁寧語＋アラートは尊敬語 | セキュリティ関連メッセージでの普通体 |
補足が一つあります。同じプロダクトの中でも、場面が変われば適した文体の細かなレベルも変わります。ボタンラベルは、プロダクトの種類を問わず、ほぼ常に体言止め（動詞の語尾なし）にすべきです。洗練された意図的な表現として、どの文体の中でも受け入れられます。説明文、ツールチップ、オンボーディングのメッセージは、プロダクト全体の文体に合わせましょう。エラーメッセージとセキュリティアラートは、ほかの部分がカジュアルでも丁寧語に寄せるべきです。システムに障害が起きた瞬間は、ユーザーを驚かせるのではなく安心させなければならないからです。
ビフォーアフター：実際の文体の使い方
文体の違いがいちばんはっきり出るのは、ユーザーがプロダクトの品質について強い印象を持つ特定の接点です。よくある8つのUIの場面と、それぞれでの文体の使い方を示します。
| UIコンテキスト | ❌ よくある間違い | ✅ 推奨表現 |
|---|---|---|
| メインCTAボタン | 無料トライアルを開始する （動詞形 — 命令的に聞こえる） |
無料で試してみる （誘いのトーン — ユーザー主導の印象） |
| 保存アクションボタン | 変更を保存します （丁寧体動詞 — ボタンには長すぎる） |
変更を保存 （体言止め — すべてのボタンラベルに正しい形） |
| 成功メッセージ | 保存した （普通体 — 唐突、冷たい） |
保存しました （丁寧語 — 温かみがあり、完了を確認） |
| エラーメッセージ | エラーが発生した （普通体 — 不安を与え、安心感がない） |
エラーが発生しました。恐れ入りますが、再度お試しください （丁寧語＋お詫び — 前に進む方向を示す） |
| オンボーディングツールチップ | ここをクリックしろ （命令形 — 無礼、命令的） |
こちらをクリックしてください （丁寧なお願い — 誘導的で敬意がある） |
| 価格CTA | 今すぐ購入する （押しつけがましい — B2Bでは抵抗感を生む） |
プランを選択する （中立的な誘い — ユーザーが主導権を持つ感覚） |
| 破壊的なアクション | 削除しますか？ （疑問形 — 取り消せないアクションには重みが足りない） |
削除してよろしいですか？この操作は元に戻せません （正式な確認＋結果の説明 — 適切な重み） |
| 空の状態メッセージ | データなし （ラベルのみ — 冷たく役に立たない） |
まだデータがありません。最初のレコードを追加してみましょう （丁寧語＋誘い — 支援的） |
敬語と普通体が日本語ユーザーに送るシグナル
文体の選び方は、個々の接点にとどまらず、プロダクト全体がどう受け取られるかを形づくります。以下の2つの列では、主な文体がプロダクト全体として何を伝えるかをまとめました。日本でのブランドの立ち位置に合わせてローカライズの方針を決める材料にしてください。
どちらの文体が常に優れているということはありません。問われるのは、文体を意図して選んでいるかどうかです。事前に決め、スタイルガイドに書き、プロダクトのすべての文字列に当てはめているか。ローカライズの問題のほとんどは、選び方を誤ったことではなく、そもそも選んでいないことから生じます。文体の指示がないまま翻訳者やAIツールが出した訳が、そのまま使われてしまった文字列の問題なのです。
タッチポイントごとの文体のガイド
日本に参入するほとんどのB2B SaaSプロダクトには、以下のタッチポイントごとのガイドが適用されます。上記の意思決定マトリックスを使って、プロダクトタイプとオーディエンスに合わせてアレンジしてください。
一貫性こそが真の目標
SaaSのローカライズで文体について最も大事なのは、どのレベルを選ぶかではありません。意識して1つを選び、どこでもそれを使い続けることです。理屈の上ではもう少し改まった文体のほうが良いかもしれない場面でも、丁寧語で統一したプロダクトは、文体が意図なく混ざったプロダクトより良い結果を出します。
日本語ユーザーは、UIの言葉を全体として読んでいるからです。オンボーディングとは違う文体のエラーメッセージが出てきたり、価格ページの段落の途中で文体が変わったりしても、ユーザーは「面白いスタイルの選択だ」とは思いません。「このプロダクトはどこか未完成な感じがする」と思うのです。一度そう思われると、体系的なQAレビューなしに印象を覆すのは困難です。
-
1翻訳前に文体を定義する 文字列がローカライゼーションワークフローに入る前に、次のように指定します。「このプロダクトはUI全体を通して丁寧語を使用し、すべてのボタンラベルには体言止めを使用し、すべてのエラーメッセージにはお詫びフレーズを添えた丁寧語を使用する。」この仕様を一つ決めておくだけで、文体の問題はほとんど防げます。
-
2ボタンラベルを個別に監査する ローカライズされたSaaSプロダクトで、文体の違反が最も多いのはボタンラベルです。すべてのボタン文字列を監査し、どれも体言止めになっているかを確認します。動詞語尾なし、丁寧語尾なし。
-
3エラーメッセージをセットとして確認する すべてのエラーと警告メッセージを1つのビューに集めて連続して読みます。文字列を1つずつレビューする際には見えない不整合が、セットとして見ると明らかになります。
-
4「だ」または「である」で終わる文字列にフラグを立てる B2B SaaSでは、普通体語尾はほぼ常に誤りです。自動化ツールで文字列ファイル内のこれらの語尾を検索すれば、リリース前に文体の修正の候補を洗い出せます。
-
5ネイティブの読者に「フローテスト」を実施してもらう 最も確実な文体のチェックは、定性的な方法です。日本語ネイティブのプロフェッショナルに、ランディングページからオンボーディング、アカウント設定までプロダクトを最初から最後まで読んでもらい、全体のトーンを一言で表してもらいます。答えが「ばらばら」や「途中で変わる」なら、個々の文字列がどう見えても、文体に問題があります。
文体は日本語SaaSローカライゼーションの仕上げの細部ではありません。最初の決断です。
「敬語と普通体のどちらを使うべきか」という問いに普遍的な答えはありませんが、あなたのプロダクト、オーディエンス、日本でのブランドポジションに合った正しい答えはあります。ただし、良いデフォルトは存在しません。文体を成り行きに任せるのは、プロダクトへの信頼を成り行きに任せるのと同じです。
日本で長期的に成功している企業は、ユーザーにどう語りかけるかを自ら決め、その決定をすべての文字列、すべてのタッチポイント、すべてのリリースで守り続けてきた企業です。その一貫性は単なる言語品質ではありません。言葉を通して目に見える形になった、ビジネスとしてのコミットメントです。
「敬語の指針」の5分類でUI文言を照合する
丁寧語で統一すると決めても、翻訳レビューの場では「この言い方は敬語として正しいのか」という議論が必ず起きます。担当者の感覚だけで判定すると、レビュアーが替わるたびに直しが往復します。社内の判断基準として使いやすいのが、文化審議会が平成19年2月2日に答申した「敬語の指針」です。指針は敬語を尊敬語・謙譲語Ⅰ・謙譲語Ⅱ（丁重語）・丁寧語・美化語の5種類に分け、第2章の後半には誤りやすい言い方を問答形式で解説しています。
以下は、その5分類と問答の例文を、SaaSのUI文言（ボタン、エラー、ヘルプ、通知メール）に当てはめたものです。指針の例文そのものは接客や学校の場面で書かれているため、表のUI例は当社による当てはめです。
5分類とUIでの出どころ
| 指針の種類（型） | 働き（指針の定義の要約） | SaaSのUIで出やすい場所 |
|---|---|---|
| 尊敬語（「いらっしゃる・おっしゃる」型） | 相手側または第三者の行為・状態を立てる | ユーザーの操作を説明する文（「ご利用になれます」「お選びください」） |
| 謙譲語Ⅰ（「伺う・申し上げる」型） | 自分側から相手側への行為について、行為の向かう先の人物を立てる | 自社側の行為（「ご案内します」「お送りします」） |
| 謙譲語Ⅱ・丁重語（「参る・申す」型） | 自分側の行為を、話や文章の相手に対して丁重に述べる | 通知メールの定型句（「弊社」「〜いたします」） |
| 丁寧語（「です・ます」型） | 話や文章の相手に対して丁寧に述べる | 成功メッセージ・エラー本文など文末全般 |
| 美化語（「お酒・お料理」型） | ものごとを美化して述べる | UIではほぼ不要。付けすぎると過剰に見える |
指針は、丁寧語のうち「（で）ございます」を謙譲語Ⅱと同程度に丁重な表現と位置づけています（p.21）。UIの定型文で「こちらが設定画面でございます」まで上げると、です・ます体で統一した他の画面から浮いてしまいます。
取り違えが起きやすい6か所
| UIの場面と起きやすい書き方 | 指針に沿った書き方 | 根拠（指針の該当箇所） |
|---|---|---|
| ヘルプ：「詳しくは管理者に伺ってください」 | 「詳しくは管理者にお尋ねください」 | 問10（p.37）。「伺う」は謙譲語Ⅰで、客の動作には使えない。「お聞きしてください」も同じ謙譲語Ⅰのため不可 |
| プラン表示：「この機能はプロプランでご利用できます」 | 「ご利用になれます」または「ご利用いただけます」 | 問12（p.38）。「ご……する」は謙譲語Ⅰを作る形式とされる。「ご利用できる」はその可能形で、ユーザーの動作を謙譲語Ⅰで述べることになる |
| 完了メッセージ：「データの準備がお整いになりました」 | 「データの準備が整いました」 | 問34（p.50、いわゆるマニュアル敬語）。「お……になる」は尊敬語の形で、物を立てることになる |
| メンテナンス通知：「サービスを一時停止させていただきます」 | 「サービスを一時停止いたします」 | 問18（p.40〜41）。「させていただく」は相手の許可と恩恵の2条件がそろうときの形。店の休業告知の例では、許可の条件がなければ「休業いたします」の方が良いとされる |
| 申込フォーム：「お申し込みください」を「申す」が入るので誤りと指摘される | 「お申し込みください」のままでよい | 問14（p.39）。「お申し込みください」「御持参ください」に含まれる「申す」「参る」は謙譲語Ⅱの働きを持たないとされ、相手側の行為に使ってよい |
| 通知メール冒頭：「ご利用いただきありがとうございます」を「ご利用くださり」に直すべきか | どちらも適切。社内でどちらかに揃える | 問17（p.40）。「御利用いただく」は謙譲語Ⅰ、「御利用くださる」は尊敬語で、どちらも適切とされる。ただし受け止め方に個人差があるとも書かれている |
レビューで判定を揃えるための4つの手順
- 動作の主を先に決める。文字列ごとに「ユーザーの動作か、自社の動作か」を訳注欄に書きます。ユーザーの動作なら尊敬語、自社の動作なら謙譲語Ⅰ・Ⅱという振り分けが、指針の5分類の出発点です。
- ユーザーの動作に付いた謙譲語Ⅰを拾う。文字列ファイルを「伺って」「お聞きして」「ご利用でき」「お問い合わせして」などで検索し、ユーザーへの依頼文に混じっていないかを見ます。
- 「させていただく」を2条件で仕分ける。ユーザーの許可を実際に求めている文（例：データ利用の同意取得）以外は「いたします」に置き換える候補にします。
- 指針が適切とする言い方を過剰に直さない。「お申し込みください」「ご利用いただきありがとうございます」は指針上問題がないとされています。レビュアーの好みで直すと、同じ文言が画面ごとに揺れる原因になります。スタイルガイドには、採用した形と指針の問番号を一緒に書いておくと、次のレビューで同じ議論を繰り返さずに済みます。
出典：文化審議会答申「敬語の指針」（平成19年2月2日、文化庁）https://www.bunka.go.jp/seisaku/bunkashingikai/kokugo/hokoku/pdf/keigo_tosin.pdf。ページ番号は答申本文の印刷ページ。表中のUI例は、指針の例文をSaaSの文言に当てはめたもので、指針に直接書かれた例ではありません。
SaaSプロダクトには敬語と普通体のどちらを使うべきですか？
B2B SaaS・FinTech・エンタープライズツールでは、UI全体で丁寧語（です・ます体）を使うのが正しい選択です。開発者向けツールやコンシューマーアプリでは、よりカジュアルな文体も適切です。最も重要なのは一貫性であり、文体を決めたらすべてのタッチポイントに適用することです。丁寧語を一貫して使っているプロダクトは、個々の文字列がより精緻でも文体が混在しているプロダクトより、高い成果を上げます。
日本語UIにおける敬語と普通体の違いは何ですか？
敬語（丁寧語）はです・ます体の語尾を使い、専門性と敬意を示せるため、ほとんどのB2Bソフトウェアに適しています。普通体（だ・である）はよりカジュアルで、開発者向けCLIやコンシューマーアプリに向いています。ボタンラベルはプロダクトの種類にかかわらず体言止め（動詞語尾なし）を使うべきです。たとえば「保存する」や「保存します」ではなく「保存」。体言止めのボタンラベルはどの文体にもなじみ、文字数も抑えられます。
日本語SaaSローカライゼーションで文体の一貫性が重要な理由は何ですか？
オンボーディングでは丁寧語、エラーメッセージでは普通体というように、プロダクトの部分ごとに敬語レベルが混在していると、日本語ユーザーはそのプロダクトに一貫性がなく、専門性が低いと感じます。これは信頼を損ない、コンバージョン率を下げます。言語の品質が業務の品質を映すと受け取られるB2Bでは、特に深刻です。文体の混在はほぼ常に、文体の仕様がないまま、異なる時期に異なるツールや翻訳者が文字列を翻訳したことが原因です。
エラーメッセージにはどの敬語レベルを使うべきですか？
エラーメッセージは、それ以外のコンテンツがカジュアルなプロダクトであっても、常に丁寧語（です・ます体）を使用すべきです。「恐れ入りますが」または「申し訳ございません」などのお詫びフレーズで始め、明確な次のステップで締めくくる必要があります。「エラーが発生した」のような普通体のエラーメッセージは冷たく不安を与え、ユーザーが最も安心を必要としている瞬間に信頼を損ないます。
日本語SaaSプロダクトで普通体が許容される場合はいつですか？
普通体は、エンジニアが直接的でコンパクトな言葉を期待する開発者ツール・CLIドキュメント・技術APIリファレンスに適しています。会話的なトーンを意図して採用しているコパイロット型ツールでは、AIアシスタントの応答にも向いています。どちらの場合も、普通体を使う判断は意図的で一貫したものであるべきです。文体の指示がないまま、AI翻訳が既定でカジュアルな出力をした結果であってはいけません。