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

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

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

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

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

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

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

AIはドラフトは作れても、出荷判断はできない

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

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

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

よくある質問