日本語エラーメッセージ：
AI翻訳が失敗する理由と修正すべきポイント

▶ 60秒スライド要約 この記事には10枚スライド版もあります。60秒で読めます。 スライドを見る →

TL;DR

エラーメッセージは、日本語SaaSプロダクトの中で最もリスクの高いマイクロコピーです。ユーザーがすでに行き詰まったり、不安を感じたりしている、まさにその瞬間に表示されるからです。AI翻訳の失敗には4つの決まったパターンがあります。ユーザーを責めるトーンになる、次の行動を示さず曖昧なまま終わる、ストレスのかかる場面に合わない丁寧度を選ぶ、技術用語をそのまま直訳する。良い日本語エラーメッセージは「何が起きたか・なぜか・次に何をすべきか」を、落ち着いた丁寧体で伝えます。AIに下書きは作れても、そのまま出荷はできない領域です。

キーポイント

• エラー画面はトーンを増幅する。設定画面なら許容される少しのズレが、エラーメッセージでは致命傷になります。
• AIは「責める」方向に倒れる。「無効な入力です」のような直訳は、英語では中立でも日本語では非難として響きます。
• 日本語では「曖昧」がより危険。「エラーが発生しました」だけでは、ユーザーは行き詰まり、静かに離脱します。
• 丁寧度は「上げる」のではなく「落ち着かせる」こと。ストレス時に必要なのは硬い敬語でも素っ気ない常体でもなく、落ち着いた丁寧体です。
• AIはドラフト止まり。エラー文言には「何がそのメッセージを引き起こすのか」の文脈確認が必要で、文字列リストだけでは判断できません。

なぜエラーメッセージは日本語UIで最もリスクが高いのか

プロダクトの中の他のマイクロコピーは、基本的に「問題のない」ユーザーが読みます。設定画面を眺め、ツールチップにカーソルを合わせ、料金表を見比べている——いずれも落ち着いた状態です。エラーメッセージだけは違います。ユーザーがそれを読む時点で、すでに何かがうまくいっていません。行き詰まっているか、混乱しているか、決済やログインのフローであれば少し不安を感じています。

その状況が、トーンのズレを大きくします。少し硬すぎるボタンラベルなら、ユーザーに余裕があるので気にされません。しかし、少し冷たい、少し曖昧、少し責めるようなエラーメッセージは、もう余裕の残っていないユーザーに届きます。同じ程度のローカライゼーションのズレでも、エラー画面では結果がずっと悪くなります。その瞬間のユーザーは、ずっと寛容ではないからです。

海外SaaSにとって、その代償は具体的です。サインアップ・チェックアウト・認証のフローで出る不自然なエラーは、日本のユーザーを苛立たせるだけでは終わらず、セッションそのものを終わらせてしまいます。しかも、再試行することが多い欧米のユーザーと違い、わかりにくいエラーに出会った日本のB2Bユーザーは、それを「このプロダクトは日本市場の準備ができていない」という兆候と受け取り、そのまま戻ってこないことがよくあります。

さらに、エラーメッセージはQAで最も見落とされるマイクロコピーでもあります。意図的に発生させにくく、コードベースの各所に散らばり、メインUIとは別の文字列ファイルから引かれることも珍しくありません。ローカライゼーションQAが最も飛ばしやすい文字列であり、そして間違っていたときに最も大きなダメージを与える文字列です。

AI翻訳が日本語エラーメッセージを壊す4つのパターン

海外SaaSプロダクトのQAレビューを重ねてわかったのは、AI翻訳のエラーメッセージには4つの決まった失敗の形があることです。どれも、「そのエラー文字列がどんな文脈で表示されるか」を知らずに翻訳したことから、予想どおりに起こります。

パターン1 — ユーザーを責めるトーン

英語のエラー文言は「invalid」「incorrect」「you entered」といった言い回しをよく使いますが、英語の読者にはどれも中立に感じられます。ところが直訳すると、日本語では角が立ちます。プロダクトが「あなたのせいだ」と言っているように聞こえるのです。良い日本語エラー文言は、ユーザーの「失敗」ではなく、「状態」を描写します。「あなたは無効でした」ではなく、「形式を確認する必要があります」と書きます。

パターン2 — 次の行動を示さない曖昧な文言

「Something went wrong」が英語で許容されるのは、英語のUX文化では、エラー文言を目に見える再試行ボタンやサポートリンクとセットで提示するからです。日本語に単独で訳すと——「何かがうまくいきませんでした」もまた、どこか不穏に響きます——ユーザーは取り残されます。日本のB2Bユーザーがエラーメッセージに何よりも期待するのは、たった一つの問いへの答えです。「今、自分は何をすればいいのか」。この問いに答えないエラーメッセージは、プロダクトが匙を投げたと受け取られます。

パターン3 — ストレス時に合わない丁寧度

「より丁寧な日本語のほうが常に安全だ」という思い込みがよくあります。エラー画面では、それは当てはまりません。摩擦の瞬間に重い敬語を向けるのは、英語で過剰にフォーマルな謝罪をするのと同じように響きます。距離があって、事務的です。逆方向の失敗、つまり素っ気ない常体（「入力エラー」）は、突き放したように響きます。エラーメッセージに適した丁寧度は、落ち着いた丁寧体（ですます）です。ユーザーを真剣に受け止めていることが伝わる敬意があり、人間味を感じさせるだけの平易さもあります。

パターン4 — 技術用語の直訳

「Bad Request」「Session timed out」「Token expired」といったエラーテキストは、開発者のために書かれたものです。日本語に直訳しても（「不正なリクエスト」「トークンが失効しました」）、開発者向けのままです。違うのは、それが混乱したお客様の目の前にあるという点だけです。さらに悪いことに、「不正」のような語は、日本語では英語の「bad」にはない不穏な含みを持ちます。直し方は、専門用語をもっと上手に訳すことではありません。専門用語を、ユーザーにとっての「結果」に置き換えることです。

日本語で機能するエラーメッセージの構造

ユーザーを実際に助ける日本語エラーメッセージは、次の3つの要素を、この順で組み立てます。

1. 何が起きたか: 平易に述べる。ユーザーの落ち度ではなく、状態を描写する（「ログインの有効期限が切れました」）。
2. なぜか（役立つ場合のみ）: 簡潔な理由。ユーザーの取るべき行動が変わる場合にのみ添える。多くの場合は省略できます。
3. 次に何をすべきか: 具体的な行動を、丁寧体で（「もう一度ログインしてください」）。この要素だけは、決して省略しません。

3要素すべてに共通する丁寧度は、落ち着いた丁寧体（ですます）です。感嘆符は使いません——半角の「!」も全角の「！」も、日本語のエラーメッセージでは慌てた、あるいは攻撃的な印象を与えます。責める構文も使いません。ユーザーが見たいわけではない生の技術用語も使いません。理由とお詫びがふさわしい場面では、「お手数ですが」が、重い敬語に陥らずに摩擦を認める、温かく標準的な言い回しです。

よくあるエラーメッセージの文例13選

ここまでの原則を、SaaSで頻出するエラー文言に当てはめた文例です。左から、英語の原文、AI翻訳や直訳で出やすい形、推奨する日本語の順に並べています。推奨文はどれも、落ち着いた丁寧体で「何が起きたか」と「次に何をすればよいか」を伝える形にそろえています。

数値（10MBなど）や項目名（会社名など）は例です。実際のプロダクトの値と、フロー全体で使っている用語に合わせて置き換えてください。

決済・認証エラー：コストが最も高くなる場所

すべてのエラーメッセージが重要ですが、日本では2つのカテゴリが突出したリスクを抱えます。決済エラーと認証エラーです。どちらも、日本のユーザーが最も慎重になっている瞬間——金融情報を渡そうとしている瞬間、あるいは自分のアカウントに入れないと告げられた瞬間——に発生します。

特にFinTechやチェックアウトのフローでは、不自然な日本語のエラーは独特のダメージを与えます。非難するように聞こえるカード拒否のメッセージや、生の技術用語で説明された3Dセキュアのタイムアウトは、日本のユーザーに「このプロダクトはお金を預けられない」と思わせます。同じメッセージの英語版は単に煩わしいだけですが、日本語版はその瞬間、検討の対象から外れる理由になります。

決済エラーは、用語の問題も絡んできます。チェックアウトフローの他の部分が取引プロセスを「決済」で統一しているのに、エラーメッセージだけが突然「支払い」に切り替わると——あるいはその逆でも——ユーザーが最も注意を払っているまさにその場所で、不整合が生まれます。認証エラーも、「ログイン」と「サインイン」で同じ落とし穴があります。エラーメッセージは、プロダクトで決めた用語をそのまま引き継ぐべきもので、文字列ごとに決め直すものではありません。

日本語SaaSビルドのエラーメッセージQAチェックリスト

日本語ビルドをリリースする前に、このチェックは実際のプロダクトに対して——文字列リストではなく、実際にエラー状態を起こして——行ってください。以下のチェックの多くはスプレッドシート上では実行できません。だからこそエラーメッセージは、文脈の中で行う日本語QAが最も効くポイントなのです。

AIはドラフトは作れても、リリースの判断はできない

丁寧度を指定し、読者を明示し、次の行動を求めるプロンプトを与えれば、AI翻訳ツールは実は妥当な日本語エラー文言のドラフトを作れます。最初の一手としては、本当に役立ち、やる価値があります。

AIにできないのは、いちばん肝心な部分です。AIは、あるメッセージが実際に何によって引き起こされるのかを知りません。「認証エラー」は、パスワード誤り・セッション切れ・アカウントロックのいずれでも表示されうるもので、それぞれ違う文言が必要です——それぞれで「次の行動」が変わるからです。文字列だけを見ても、ツールにはどの状況に向けて書いているのかがわかりません。さらに、ビルド全体に散らばる数十のエラー状態を通して丁寧度の一貫性を保つことも、日本語の文字列がトーストコンポーネントで切れないかを確かめることも、摩擦の瞬間のトーンを判断することもできません——その瞬間を、AIは決して目にしないからです。

したがって、信頼できるワークフローは「AIか人間か」ではありません。「AIがドラフト、その後に実ビルドに対する日本語ネイティブQA」です。AIが量をさばき、ネイティブレビューが文脈・丁寧度の一貫性・そしてライブのプロダクトにしか存在しない文字切れと発生条件のチェックを担います。エラーメッセージでいえば、この2つ目のステップは「あれば望ましい仕上げ」ではありません。日本のユーザーを前に進ませるエラー状態と、その人のセッションを静かに終わらせるエラー状態を分ける、まさにその違いです。

よくある質問