日本語へのローカライズでは、SaaSやFinTechのほとんどの企業が機械翻訳後編集（MTPE）を標準のワークフローにしています。DeepL、ChatGPT、Google翻訳の出力は、日本語として一応読めます。問題はまさにそこにあります。

訳文が流暢に見えると、レビュアーは気を緩めます。ぎこちない機械翻訳なら一目でわかるはずのエラーも、文章全体が自然に読めるせいで見過ごされます。ところが日本語では、「流暢」と「信頼できる」の間に大きな開きがあります。MTPEのレビュアーが最も見落とすのは、まさにこの開きの中にあるエラーです。

この記事では、日本語MTPEのレビューを20年以上続けてきた経験から作ったQAチェックリストを紹介します。対象は、AIのレビューツールでは検出できず、時間に追われると見落としやすい問題に絞りました。

日本語MTPEに異なるQAアプローチが必要な理由

MTPEのQAフレームワークの多くは、英語と構造の近いヨーロッパ言語の組み合わせを前提に作られています。日本語には、日本語ならではのQAの課題があります。

日本語MTPE QAチェックリスト

レイヤー1：文体の一貫性

🔍

文書全体で単一の文体が使われているか確認する

です/ます体（丁寧体）か普通体のどちらかに、文書全体がそろっているかを確認します。MTは、原文の丁寧さが変わる箇所で、段落の途中から文体を切り替えてしまうことがよくあります。

🔍

顧客向けUIでの敬語使用を確認する

通知メッセージ、エラー画面、ヘルプセンターのテキストには丁寧語が必要です。MTはこうした文脈で普通体やカジュアルな表現を生成することがよくあります。

❌ MT出力
パスワードを入力してください。アカウントにアクセスする。
文体の混在：丁寧語のCTAに続いて普通体の動詞
✅ ポストエディット後
パスワードを入力してください。アカウントにアクセスしてください。
全体を通して一貫した丁寧体

レイヤー2：ドメイン文脈における用語の正確さ

🔍

決済・請求用語の確認

「決済」と「支払い」の使い分け（別記事「決済 vs 支払い」参照）を確認し、「請求」「課金」「引き落とし」が文脈に合った使い方になっているかをチェックします。MTはいちばん一般的な訳語を機械的に選ぶので、B2B SaaSの請求の場面では外れることが多くなります。

🔍

機能名とUI用語の一貫性確認

MTPE開始前に用語集を作成してください。MTは「dashboard」をある文では「ダッシュボード」に、別の文では「管理画面」に訳します。どちらも正しいですが、不統一がそのまま問題になります。

🔍

法務・コンプライアンス用語の確認

プライバシーポリシー、利用規約、請求に関する開示書類は、法的に正確な日本語でなければなりません。こうした箇所のMT出力は、軽いポストエディティングで済ませず、人間が全面的にレビューする前提の初稿と考えてください。

レイヤー3：冗長性と過度の直訳

❌ MT出力
53以上の53人以上のユーザーがこの機能を使用しています
「53+ users」から生じる典型的なMTの冗長性
✅ ポストエディット後
53名以上のユーザーがこの機能を利用しています
冗長なし、自然な動詞の選択
🔍

「以上／以下」表現の確認

MTは「53以上以上」や「53+以上」のように、ここを二重にしがちです。英語の「+」を訳したうえで、それとは別に日本語の「以上」も付け足してしまうからです。

🔍

主語の重複挿入の確認

日本語では、同じ主語が続く文では主語を省くのが自然です。MTは文ごとに主語を入れ直すことが多く、その結果、ネイティブが書いたものではないとすぐわかる、ぎこちなく機械的な文章になります。

レイヤー4：CTAとコンバージョンコピー

重要QAゾーン： CTAボタン、サインアップの誘導文、料金ページのCTAは、ユーザーの目がいちばん集まり、エラーが出たときの損失も最も大きい箇所です。ページのほかの部分のMT品質がどうであれ、ここは必ず人間がレビューしてください。

🔍

CTAの文体と行動の明確さ

MTが出すCTAは、文法は正しくても押しが弱すぎることがよくあります。「無料で始められます」（You can start for free）は、「無料で始める」（Start for free）に比べて弱く響きます。当社のQA業務でも、日本語のB2Bでは直接的な命令形のほうが安定してコンバージョン率が高いという結果が出ています。

🔍

エラーメッセージとエンプティステートの確認

MTが訳したエラーメッセージは、言い切りが強すぎるか、ぼんやりしすぎるかのどちらかになりがちです。「エラーが発生しました」（An error occurred）だけでは、どうすれば復旧できるのかがわかりません。何が起きていて次に何をすればよいかが、自然な日本語で書かれているかを確認しましょう。

レイヤー5：ビジュアルとフォーマットのQA

🔍

句読点の正規化

日本語では、引用符に「」、句点に。、読点に、を使い、ASCIIの記号では代用しません。MTの出力にはASCIIと全角の句読点が混じっていることが多く、仕上げが済んでいない印象を与えます。

🔍

数字と単位のフォーマット確認

日本語には独自の数字の書き方があります。大きな数は万（10,000）単位で表すことがあり、文脈によっては3桁ごとのカンマが不自然に見えます。日付は年月日の順です。MTは、日本語の中では浮いてしまう西洋式の書式をそのまま残しがちです。

🔍

テキストの拡張とUIの切れ

日本語のテキストは、たいてい英語の文字数の1.1〜1.3倍になります。MTでローカライズしたボタンラベルやタブ見出し、ナビゲーション項目は、UIの枠からはみ出すことがよくあります。テキスト単体ではなく、実際の画面に表示した状態でレビューしましょう。

最も重要なQAギャップ

MTの品質推定機能のようなAIのレビュー支援ツールでも、ここまでの問題の多くは検出できます。ただし、商売上いちばん大事な項目は苦手です。それが信頼の文体です。

信頼の文体とは、その日本語が、買い手の業界や求められる改まり方、仕事の場面をわかっている人の書いたものに読めるかどうかです。決済プラットフォームなら、銀行の文書のような日本語であるべきです。開発者ツールなら、経験を積んだエンジニアが書いたと思える日本語です。HRのSaaS製品なら、日本のHRの専門家が実際に使う正式なHR用語に合わせる必要があります。

今のところ、これを測れるAIツールはありません。その分野の経験がある日本語ネイティブのレビュアーが見るしかなく、手順立てたMTPE QAが担うのはまさにこの部分です。

MTPE QAだけでは不十分な場合

軽いMTPEとQAレビューが適切なのは、ヘルプセンターの記事、FAQ、ブログコンテンツ、コンバージョンのリスクが低い社内ドキュメントなどです。

次の種類のコンテンツは、MTの出力がどれだけ流暢でも、人間による全面翻訳（少なくとも手厚いMTPE）をおすすめします。

こうしたコンテンツを今のワークフローで軽いMTPEだけで済ませているなら、コンバージョンを取りこぼしている可能性が高いでしょう。信頼の差はアナリティクスには表れませんが、プロダクトを読む日本のエンタープライズの買い手には一人残らず伝わっています。