Claudeの翻訳精度をビジネス文書の実例で検証する
契約書と仕様書の訳文例を使い、翻訳で崩れやすい箇所を検証します。数値・定義語・条件節のどこに注意が要るか、指示の出し方まで扱います。
Claudeの翻訳精度を直接測った公式の数字は、多言語対応ページにはありません。そこにある日本語96.8%(Sonnet 4.5)と93.5%(Haiku 4.5)は、英語を100%としたときの多言語評価のスコアで、訳文の正確さとは別のものです。ビジネス文書の訳が使えるかどうかは、文書ごとの点検で決まります。
ビジネス文書の翻訳で崩れやすいのはどこか
契約書や仕様書の翻訳は、日常文の翻訳と壊れ方が違います。単語の意味を取り違えることはまれでも、数値の解釈・定義語の一貫性・条件節の係り受けの3か所で、文書の効力や要求の強さが変わる訳になりえます。どれも読み流すと見逃します。
この記事では、架空のサンプル文書と訳文例を素材に、翻訳の仕上がりをどこで点検するかを具体的に見ます。訳文例は、モデルや実行ごとに変わりうる一例です。そのため、点検の観点は人の訳文にもそのまま使えます。
汎用的な翻訳ワークフロー(出力言語の固定・用語集の作り方・訳し戻しループの組み方)はClaude翻訳ワークフローにまとめてあります。本記事は、契約書・仕様書という特定の文書ジャンルで何が起きるかを扱います。訳文を誤りの種類と重大度で採点する方法はClaudeでMQM翻訳品質評価にあります。
96.8%という数字は翻訳の正確さを測っていない
Anthropicの多言語対応ページには、言語ごとの性能表があります。表に載っているClaude Sonnet 4.5は現在、非推奨の表記です。日本語の値は、英語を100%とした相対値で並んでいます。
多言語ページの日本語スコア
英語(基準)
100%
固定値
Sonnet 4.5・日本語
96.8%
zero-shotのchain-of-thought評価
Haiku 4.5・日本語
93.5%
同じ評価条件
この数字の元は、英語版のMMLU(大規模マルチタスク言語理解ベンチマーク)を、プロの翻訳者が14言語に訳したテストセットです。測っているのは、日本語で出題された問題を解く知識・推論の力です。契約書の「遅滞なく」を適切な英語に移せるかどうかは、この表からは読み取れません。
同じ表の中でも、モデルによる差は小さくありません。日本語ではSonnet 4.5とHaiku 4.5で3.3ポイントの開きがあります。言語による差はさらに大きく、スワヒリ語はSonnet 4.5で91.1%、ヨルバ語は79.7%です。モデルと言語の組み合わせで、理解力の水準自体が変わります。
翻訳品質は、自分の文書で別に点検する必要があります。公式ページの次のステップにも、公開前に翻訳とローカライズの品質を評価するよう促す項目があります。ページ自体も、表にない言語は自分の用途に合わせて試すよう勧めています。ChatGPTとの翻訳精度の違いが気になる場合は、ClaudeとChatGPTを翻訳精度で比較する記事も参考になります。
指示の出し方で何が変わるか
同じページには、多言語利用の指針が3つ並んでいます。入力言語と出力言語を明示すること、翻字ではなく原語の文字で渡すこと、文化的な文脈を考えることです。
翻訳の指示例も載っています。2言語を名指しして、訳文だけを返させる書き方です。
Translate the user's message from German to Korean. Respond with only the translation.アプリでは、この指示をシステムプロンプトに置くと会話の全ターンで安定します。ユーザーが言語を選べる場合は、その選択をシステムプロンプトに差し込む形が推奨されています。
ビジネス文書では、これに文書の性格を足します。以下は筆者が組み立てた指示の例です。
次の日本語の契約条項を英語に翻訳してください。
- 訳文だけを返してください。
- 「ものとする」は shall、「することができる」は may と訳し分けてください。
- 「遅滞なく」のように期限が曖昧な語は、訳文を変えずに末尾へ注記してください。
- 定義語は初出の訳を固定し、以後も同じ語を使ってください。公式ページは「ネイティブのような慣用的な表現で」と促す書き方も紹介しています。会話文や広報文には向きますが、契約書では原文の構造を保つ逐語寄りの訳が求められる場面もあります。文書の種類に合わせて、この指示を入れるかどうかを決めます。
サンプル1: 契約条項の日本語から英語へ
架空のNDA(秘密保持契約)の一条項を用意しました。登場する語はすべて架空です。
原文(日本語)
第5条(秘密情報の返還等) 乙は、本契約が終了した場合又は甲から請求があった場合には、甲から開示を受けた秘密情報及びその複製物を、甲の指示に従い、遅滞なく甲に返還し、又は廃棄するものとする。ただし、法令に基づき保存が義務付けられている場合は、この限りでない。
訳文例(英語)
Article 5 (Return of Confidential Information) Upon termination of this Agreement or upon request by Party A, Party B shall, in accordance with Party A's instructions, promptly return or destroy the Confidential Information disclosed by Party A and any copies thereof; provided, however, that this shall not apply where retention is required by applicable laws or regulations.
この訳文例で良い点は、法的な言い回しが英文契約書の型に収まっていることです。「ものとする」は拘束力を示す shall になっています。「ただし、〜この限りでない」は provided, however, that ... shall not apply という定型句に移っています。「甲」「乙」も Party A Party B で揃っています。
注意が要るのは「遅滞なく」の promptly です。「〜日以内」のような具体的な期限を示さない語で、原文が意図して期限を決めていないのか、曖昧に書いただけなのかは訳文から判断できません。期限の厳密さは原文の作成者に尋ねる事項です。翻訳の精度ではなく、原文の設計の問題として扱います。
サンプル2: 仕様書の英語から日本語へ
技術仕様書の抜粋です。システム名や数値は架空です。
原文(英語)
The system shall process incoming requests within 200 milliseconds under normal load. If the request queue exceeds 500 pending items, the system should reject new requests with a 503 status code until the queue depth returns below 300.
訳文例(日本語)
本システムは、通常の負荷条件下において、受信したリクエストを200ミリ秒以内に処理するものとする。リクエストキューの保留件数が500件を超えた場合、キューの深さが300件を下回るまで、システムは新規リクエストを503ステータスコードで拒否することが望ましい。
数値の200ミリ秒・500件・300件・503は、原文と訳文を突き合わせるだけで検算できます。数値密度の高い仕様書では、この照合が最初の作業です。
次に見るのは要求レベルです。原文は shall(必須)と should(推奨)を使い分けています。IETFのRFC 2119は、SHALLをMUSTと同じ絶対的な要求、SHOULDを正当な理由があれば外せる推奨として定義しており、仕様書ではこの差が意味を分けます。訳文例では「ものとする」と「望ましい」に訳し分けられています。
ただし、この訳し分けが毎回再現される保証はありません。shall / should / may の区別が重要な仕様書では、「shallは必須、shouldは推奨として訳し分けてください」と指示しておくほうが安定します。前節の指示例の2行目が、この役割です。
サンプル3: 主語が省略された日本語文の英訳
日本語のビジネス文書には、主語を書かなくても意味が通る文が頻出します。仕様変更の連絡メールを想定した一文で試します。社内向けの要約作成では、逆方向の要約と翻訳を組み合わせる場面もあります。その手順はClaudeで英文メールを日本語に要約する方法にあります。
原文(日本語)
本機能については、次回リリースまでに実装を完了し、社内テスト環境へのデプロイも合わせて行う予定です。承認が下り次第、本番環境への反映に着手します。
訳文例(英語)
For this feature, implementation will be completed by the next release, and deployment to the internal test environment will also be carried out at the same time. Once approval is granted, work on the production rollout will begin.
この訳文例は、受動態(will be completed will be carried out)で主語を補わずに訳しています。we や the team に決め打ちしていないので、原文に無い情報は増えていません。
裏を返せば、誰が実装し誰がデプロイするのかは、英訳でも曖昧なままです。社内連絡ならこれで足ります。委託契約の作業範囲を定める条項のように責任の所在が要る文書では、翻訳の前に原文へ主語を補います。訳文側に主語を明示させる指示を出す方法もあります。どちらを選ぶかは、文書の性質に合わせて人が決めます。
長い文書で見落としやすい2点
ここまでの3例は短い一条項・一文です。短い範囲では確かめきれない点が2つあります。
1つ目は定義語の一貫性です。サンプル1では「甲」「乙」が一条項の中で揃っていました。契約書全体では、「本契約」「本製品」のような定義語が後半で別の訳語に変わっていないかを、文書全体で見る必要があります。用語集の固定と訳し戻しでの検出は、Claude翻訳ワークフローの手順が受け持ちます。
2つ目は条件節の入れ子です。サンプル1の「ただし、法令に基づき保存が義務付けられている場合は、この限りでない」は単純な例外構文でした。「〜の場合において、〜であって、〜でないときは」のように条件が二重・三重になる文では、どの条件がどこにかかるかを、原文と訳文を並べて人が読み合わせます。
Claudeに任せる部分と人が決める部分
3つの訳文例から、作業の分担が見えます。
翻訳作業の分担
訳文の生成で任せやすい
- 「ものとする」から
shallへの法的な言い回しの変換 - 数値・単位・ステータスコードの転記
- 例外構文を定型句に移すこと
人が決める
- 「遅滞なく」のような曖昧語を、期限として固めるか
- 主語が省略された文で、責任主体を明記するか
- 長文書の定義語と入れ子条件の最終確認
人が決める側の項目は、訳文の品質では解決しません。原文の設計に関わる判断だからです。
点検の項目と、対応する指示
翻訳結果を点検するときの観点を、文書ごとの例とあわせて並べます。
翻訳結果の点検項目
数値・固有名詞
契約書では金額・期日・当事者名、仕様書では閾値・単位・エラーコードを原文と1つずつ照合します。
拘束力・要求レベル
契約書のshall / must / may、仕様書のRFC 2119準拠のshall / should / mayが、原文の強さのまま訳されているかを見ます。
定義語の一貫性
契約書の「本契約」「甲」「乙」、仕様書の製品名・コンポーネント名が、文書の最後まで同じ訳語かを見ます。
条件節と例外
「ただし〜この限りでない」やif / unlessの入れ子が、原文と同じ範囲にかかっているかを見ます。
曖昧語と省略された主語
「遅滞なく」「as soon as possible」や、義務の主体が省かれた条項は、原文の作成者に判断を戻します。
まとめ
Claudeの多言語スコアは理解力の指標で、契約書の訳文が使えるかは自分の文書で点検するしかありません。数値の転記や定型句への変換は照合で済みますが、期限の曖昧さや主語の省略は原文の側で決める事項です。