Claude翻訳ワークフロー — 精度を検証してから確定する手順

Claudeの翻訳で「精度」が崩れる場所はどこか

翻訳が崩れる箇所は毎回同じです。出力言語の指定漏れ、専門用語のゆれ、そして誤訳を見つける仕組みの不在。この3か所を順番に潰していくと、Claudeへの翻訳依頼は仕上がりの安定度がはっきり変わります。

Claudeは会話の流れから出力言語を推測しますが、業務利用ではこれに頼りません。指定・固定・検証の3工程を毎回同じ順番で通すのが、精度検証つき翻訳ワークフローの中身です。1文だけの依頼なら不要ですが、契約書や仕様書のような分量のある文書ほど効いてきます。

以下では、単発のチャットで完結する手順と、繰り返し使う文書向けにProjectsへ設定を寄せる手順の両方を扱います。

出力言語はClaudeの推測に任せず明示する

出力言語を明示すると、訳文が安定します。会話の流れからの推測に頼ると、原文と同じ言語で返る・意図しない言語が混ざるといった揺れが起きます。

公式ドキュメントは、システムプロンプトでの言語指定を最も確実な方法としています。2言語間の翻訳では、両方の言語名を明示することも推奨されています。

次のテキストを日本語から英語に翻訳してください。
訳文のみを返し、説明や前置きは付けないでください。
 
対象テキスト:
{原文をここに貼り付け}

チャットの都度この一文を書き直すのは手間なので、同じ言語ペアを繰り返し扱うならProjectsのカスタム指示に固定してしまうほうが確実です。会話ごとに書き直す手間が消え、指定漏れによる訳文の揺れも同時に防げます。

原文は原語のスクリプトのまま渡す

原文はローマ字化・カナ表記に変換せず、原語のスクリプトのまま渡します。公式ガイドはこれを多言語利用のベストプラクティスの1つに挙げています。

翻字を経由すると、固有名詞や声調・活用の情報が失われ、Claudeが元の語を復元しなければならなくなります。中国語のピンイン化、アラビア語のローマ字転写、日本語のローマ字入力はいずれも同じ理由で避けます。逆に、原語のネイティブスピーカーが読むような自然な言い回しで訳してほしい場合は、その意図もプロンプトに書き添えます。「直訳ではなく、ネイティブスピーカーが書くような自然な文章にしてください」の一文があるだけで、硬い逐語訳が減ります。

文化的な背景を要する表現(慣用句、敬語のニュアンス、宗教・商習慣に触れる言い回し)は、単純な語の置き換えでは処理し切れません。公式ガイドも「効果的なコミュニケーションには、純粋な翻訳を超えた文化的・地域的な配慮が必要になることが多い」と述べています。訳文だけでなく、注意が必要な箇所を別途指摘させる依頼を添えると、レビューの負荷が下がります。

用語の一貫性はProjectsのナレッジに置く

社名・製品名・専門用語の訳語は、チャットのたびに指定するのではなくProjectsのナレッジファイルに固定します。用語集を1つのファイルとして置いておけば、会話が変わっても同じ訳語が使われます。

Projectsは無料アカウントを含む全ユーザーが利用でき、無料プランでも最大5つまで作成できます。プロジェクトごとにカスタム指示とナレッジファイルを設定でき、その内容は同じプロジェクト内のすべての会話に自動で反映されます。有料プランでは、ナレッジがコンテキスト上限に近づくとRAG(検索拡張生成)が自動で有効になり、扱える分量が最大10倍まで広がります。

# 訳語統一表
 
| 原語 | 訳語 | 備考 |
|---|---|---|
| Onboarding | オンボーディング | カタカナのまま。「導入研修」は使わない |
| Stakeholder | 関係者 | 文脈により「利害関係者」も可 |
| {自社製品名} | {固定表記} | 英語表記のまま、活用形を付けない |
 
# 訳出方針
- 敬体(ですます調)で統一する
- 見出しは体言止め、本文は敬体
- 数値・日付の書式は原文の桁区切りを保持する

この形でナレッジを置いておくと、翻訳を頼むたびに用語集を貼り付ける必要がなくなります。用語が増えたらファイルを差し替えるだけで、以降の会話すべてに反映されます。

訳し戻しで誤訳を検出するループを作る

翻訳の精度検証で最も効くのは、訳文をレビューさせてから確定する2段階の依頼です。1回の依頼で訳させて終わりにすると、誤訳や訳し漏れがそのまま残ります。

Anthropicのプロンプト設計ガイドは、この形を「self-correction」と呼び、下書きを作らせる→基準に沿ってClaude自身にレビューさせる→レビューを踏まえて修正させる、という3段の連鎖を代表的なパターンとして挙げています。翻訳に当てはめると、次の順番になります。

1. 下書き翻訳: 通常どおり翻訳を依頼する
2. 訳し戻し(back-translation): 訳文だけを渡し、元の言語に訳し戻させる
3. 突き合わせ: 訳し戻した文と原文を比較し、意味がずれた箇所を指摘させる
4. 修正: 指摘箇所だけを直させ、他の部分は変えないよう指示する

先ほどの日本語訳を、英語に訳し戻してください。
その上で、最初の英語原文と訳し戻した英語を比較し、
意味が変わってしまった箇所があれば指摘してください。
指摘がなければ「意味の齟齬なし」とだけ返してください。

すべての文書にこの4段階を回す必要はありません。社内メモの下訳程度なら1段階で十分ですが、契約書・製品仕様・法務文書のように誤訳の影響が大きい文書では、訳し戻しのひと手間が効きます。

言語ペアとモデルの組み合わせをどう選ぶか

翻訳するペアの言語によって、選ぶモデルの重みは変わります。高リソース言語同士なら軽量モデルでも精度差はわずかですが、低リソース言語が絡むと上位モデルとの差が開きます。

公式の多言語ベンチマークは、翻訳版MMLU(多分野の知識・読解問題)をextended thinking有効の条件で解かせ、英語で解いたときのスコアを100%とした相対値を言語ごとに公開しています。つまりこの数値は翻訳という作業そのものの品質を測ったものではなく、「その言語に翻訳された問題文をどれだけ正しく理解して解けたか」を表す指標です。公開されているのはClaude Sonnet 4.5とClaude Haiku 4.5の実測値で、2モデルの世代間の位置づけはClaudeモデル一覧で確認できます。

日本語・中国語・韓国語・スペイン語のような主要言語では、SonnetとHaikuの差は3〜5ポイントに収まります。一方でスワヒリ語やヨルバ語のような低リソース言語は、モデル間の差が10〜27ポイントまで開きます。この数値が示しているのは、訳文の見た目の自然さそのものより、原文を正しく理解する力の差です。差が表に出やすいのは、専門文書や低リソース言語、文脈依存の言い回しのように原文の読解が難しい場面で、逆に一般的な文書の言語間比較では大きな差になりにくいというのが読み取り方です。日本語の翻訳精度をどこまで信頼できるかはClaudeの日本語精度で扱っています。専門文書・低リソース言語・文脈依存の言い回しを扱うときほど、上位モデルへの切り替えと訳し戻し検証の両方を厳しめに運用する価値があります。

よくあるつまずき

• 出力言語が安定しない: システムプロンプトやカスタム指示に言語指定を書いていない場合に起きます。会話の途中からでも、指定を1文足すだけで直ります
• 固有名詞が毎回違う訳語になる: 用語集をチャットのたびに貼り付けている場合に起きやすい現象です。Projectsのナレッジに固定すれば解消します
• 長い文書の後半で訳が雑になる: 一度に渡す分量が多すぎると、後半の見直しが甘くなることがあります。章・セクション単位に分割して依頼すると安定します
• 訳し戻しで「意味の齟齬なし」ばかり返る: 検証の基準を具体的に書いていないと、無難な回答に流れがちです。「数値・固有名詞・否定表現の3点を重点的に確認してください」のように確認観点を絞ると、指摘の精度が上がります
• 文化的な言い回しがそのまま直訳される: 慣用句や敬語のニュアンスは語の置き換えでは処理し切れません。訳文と合わせて「文化的に注意すべき箇所」を別途指摘させる依頼を添えます

よくある質問

APIやClaude Codeから同じ手順を組み込めますか

はい。ここで扱った出力言語の明示・訳し戻しの2段階依頼は、システムプロンプトの一文として実装できるため、API経由でもそのまま使えます。訳し戻しのステップも、1回目の応答をそのまま2回目のリクエストの入力に渡すだけで再現できます。Claude Codeからバッチで大量のファイルを処理する場合も、同じプロンプトの型をスクリプトに組み込む形になります。

用語集ファイルの分量に上限はありますか

Projectsのナレッジファイルは1ファイルにつき容量上限があります。詳細な上限値やファイル数の上限は製品側で変わることがあるため、Claude Projects完全ガイドで最新の数値を確認してください。用語集単体であれば、多くの場合この上限を意識する必要はありません。

訳し戻しをしても精度が上がらない場合はどうすればよいですか

確認観点を絞らずに「チェックしてください」とだけ依頼していないか見直します。数値・固有名詞・否定表現・敬語のニュアンスのように、確認してほしい項目を具体的に列挙すると、指摘の解像度が上がります。それでも改善しない場合は、原文自体の曖昧さが訳文に伝播している可能性があるため、原文側の文を短く区切ってから依頼し直す方法があります。

SonnetとHaikuはどちらを選べばよいですか

主要言語(日本語・中国語・韓国語・スペイン語など)同士の翻訳で、内容が一般的な文書であれば、単価の低いHaikuでも大きな差は出にくい傾向があります。専門文書や低リソース言語が絡む場合、あるいは公開資料のように誤訳を後から直しにくい文書では、Sonnet以上を選び、訳し戻しの検証も併用するのが安全です。

まとめ

精度検証つきの翻訳ワークフローは、出力言語の明示・原語スクリプトでの入力・Projectsでの用語集固定・訳し戻しによる誤訳検出、この4つの積み重ねです。どれも単体では地味ですが、抜けた箇所から訳文の質が崩れます。

単発の翻訳なら出力言語の指定だけで十分な場面も多くあります。繰り返し同じ言語ペア・同じ用語を扱う業務では、カスタム指示とナレッジファイルをProjectsに寄せておくと、依頼のたびに条件を書き直す手間が消えます。低リソース言語や誤訳の影響が大きい文書を扱うときは、訳し戻しの一手間とモデル選びを見直す価値があります。

翻訳以外の文書作成・編集にClaudeを使う場合は、Claude文章作成ガイドがライター・編集者向けの工程を扱っています。アップロードした資料をそのまま訳す場合は、ClaudeのPDF読み込み・画像解析の使い方でファイル形式ごとの上限を確認できます。Projectsの設定を詳しく知りたい場合は、Claude Projects完全ガイドにナレッジファイルの容量上限や共有設定がまとまっています。モデルごとの特性差はClaudeモデル比較で扱っています。