ローカルLLMで翻訳する2026。機密文書を外に出さないモデルの選び方と、社内で精度を確かめる手順

Q: ローカルLLMの翻訳精度はクラウドの翻訳サービスと比べてどうですか？

文書の種類と用語集の有無で評価が変わるため、一概には言えません。24GB級のGPUで32Bクラスのモデルを使い、用語集と段落単位の分割を組み合わせれば、ビジネス文書の実務ラインに届くというのが2026年時点の整理です。自社の文書で評価セット30〜50文を作り、誤訳・訳抜け・用語・自然さの4軸で採点し、合否ラインで判断してください。

「この契約書、翻訳サービスに貼り付けていいんでしたっけ」。海外取引のある会社で、現場から情報システム部門に最も多く寄せられる質問の一つです。契約書・設計書・診療記録・取引先とのメールは、翻訳の需要が最も大きい文書であると同時に、社外に出しにくい文書でもあります。NDAで外部送信が禁じられている、業界ガイドラインで外部保管が認められていない、あるいは単に「翻訳サービスのサーバーに残るのが嫌だ」という理由で、翻訳だけが手作業のまま残っている会社は少なくありません。

この矛盾を解く選択肢が、社内のPCやサーバーで完結するローカルLLMによる翻訳です。2026年時点では、メモリ16GBのノートPCでもニュース記事レベルの翻訳が動き、24GB級のGPUがあればビジネス文書の実務ラインに届きます。本記事では、ローカルLLMで翻訳するときのモデルの選び方、PDFやWord文書を扱うパイプライン、用語のぶれを抑えるプロンプト設計、そして「精度は十分か」を社内で確かめる評価手順を整理します。翻訳精度の優劣は文書の種類と用語で大きく変わるため、本記事では数値での断定を避け、自社の文書で確かめる方法を示します。

この記事の要点

ローカルLLMによる翻訳が必要なのは、契約・法令・NDAで社外送信が禁じられた文書です。一般的な社内文書は法人契約のクラウドで足ります。必要な範囲を先に切り分けます

モデルは翻訳専用ではなく、日本語で使えるローカルLLMの中から選びます。16GBならQwen3-14BやQwen3 Swallow系、24GBならQwen3-32BやELYZA-Thinking-1.0-Qwen-32Bが起点です。VRAMを先に決め、そのクラスで投げ比べます

PDFやWordの翻訳は「抽出→分割→翻訳→用語集適用→再構成」のパイプラインで組みます。モデルに丸ごと渡すのではなく、段落単位で翻訳して用語集で訳語を固定します

精度は自社の文書30〜50文で評価セットを作り、誤訳・訳抜け・用語・自然さの4軸で担当者3人が採点して判断します。公開ベンチマークの順位は参考にとどめます

リアルタイム翻訳（会議・チャット）は、ローカルLLMでは「下訳を即時に出す」までが現実的な線です。正式な訳文は確認工程を挟みます

ローカルLLMでの翻訳が必要になる文書と、不要な文書

ローカルLLMでの翻訳を検討する前に、「どの文書を外に出せないのか」を切り分けます。すべての翻訳をローカルに寄せる必要はなく、むしろ寄せると精度と手間の両面で損をします。

ローカルで翻訳すべき文書

取引先とのNDAで、第三者（クラウド事業者を含む）への送信が禁じられている契約書・仕様書・見積書
設計図面の注記、製法・配合などの営業秘密を含む技術文書
診療記録・治験関連文書など、業界ガイドラインで外部保管が認められていない文書
官公庁や防衛関連の受託案件で、閉域での処理が契約条件になっている文書
未公表の経営情報（M&A、決算前資料、人事）を含む社内文書

法人契約のクラウドで足りる文書

公開済みのプレスリリースやWebサイトの多言語化
一般的な技術記事、マニュアル、製品カタログの下訳
取引先名や個人情報を含まない社内向けの一般文書

切り分けの考え方は、『生成AIの情報漏洩対策2026』のデータ区分表と同じです。社外送信が禁止された区分だけをローカルに寄せ、それ以外は学習利用なしの法人契約を使う併用構成が、翻訳でも現実的です。個人向けの無料翻訳サービスに業務文書を貼り付ける行為は、個人情報保護委員会が2023年の注意喚起で示したとおり、入力内容の扱いを確認せずに個人データを入れることになりかねません。どの区分であっても、私用アカウントの利用は止める必要があります。

クラウド翻訳・法人契約LLM・ローカルLLMの比較

翻訳の手段は、大きく3つに分かれます。それぞれの性格を一枚で比較します。

観点	クラウド翻訳サービス	法人契約のLLM（API・法人プラン）	ローカルLLM
データの所在	事業者のサーバーを経由する	事業者のサーバーを経由する（学習利用なし・保持期間は契約で確認）	社内のPC・サーバーから出ない
学習利用	サービス・プランにより異なる。利用規約で要確認	法人契約では学習利用なしが一般的。契約書で確認	発生しない
NDA・規制への適合	「第三者への送信」に該当するため、NDAによっては不可	同上。再委託先の扱いをNDAで確認	社外送信がないため適合しやすい
費用の考え方	文字数・ユーザー数の従量または月額	トークン従量または席数月額	機材費と運用の人件費。文字数が増えても追加費用は電気代だけ
精度の傾向	定型文・一般文書で安定。専門用語は用語集機能に依存	最新モデルの性能に依存。文脈理解と長文の一貫性に強い傾向	モデルのサイズと量子化に依存。用語集と分割の設計で実用域に乗せる
用語の固定	用語集機能を持つサービスが多い	プロンプトで指示	プロンプトと前処理で指示。再現性は社内で検証
向く用途	大量の一般文書、Webの多言語化	一般〜社内情報の高品質な翻訳	社外に出せない文書の翻訳。閉域環境

精度について、ここで「どれが最も高い」と断定はしません。同じモデルでも、契約書と技術仕様書では評価が変わり、用語集の有無で結果が大きく動くからです。重要なのは、翻訳の精度を「モデルの性能」ではなく「モデル・用語集・分割・確認工程を含むパイプラインの性能」として捉えることです。ローカルLLMは最新のクラウドモデルに単体で勝つことを目指すものではなく、外に出せない文書を実用域で翻訳できる環境を社内に持つための選択肢です。

ローカルLLM 翻訳向けモデルの選び方（VRAM別）

翻訳に特化したローカルモデルを探すより、日本語で使えるローカルLLMの中から翻訳用途の観点で選ぶのが現実的です。候補は『日本語で使えるローカルLLMおすすめ2026。VRAM別の現実解』で整理したモデル群と重なります。選ぶ順番も同じで、まず手元のVRAM（GPUメモリまたは統合メモリ）を確認し、そのサイズクラスの中で翻訳に効く観点で絞ります。

翻訳用途で見る4つの観点

日英の双方向: 英→日と日→英で得意不得意が分かれるモデルがあります。両方向を使うなら両方向で評価します
長文の一貫性: 段落をまたいでも主語や用語がぶれないか。契約書では「甲・乙」や定義語の一貫性が品質を左右します
用語の固定: 用語集を渡したときに、指示どおりの訳語を使い続けられるか。小型モデルほど途中で崩れやすい傾向があります
量子化の影響: 同じモデルでも量子化を強くすると、細かな語の選択や敬語の自然さが落ちる場合があります。ファイルサイズを優先して量子化を強めた場合は、評価セットで確認します

VRAM別の起点となるモデル

VRAM	クラス	翻訳の起点にするモデル	翻訳用途での位置づけ
8GB	〜4B	Qwen3-4B、Qwen3.5-4B	短文の翻訳、メールの下訳。長文の一貫性は期待しない
8〜12GB・16GBノートPC	7〜9B	Qwen3-8B、Qwen3.5-9B、Qwen3 Swallow系、Llama-3-ELYZA-JP-8B	ニュース記事レベルの翻訳。社外秘文書の下訳として実用域
16GB	13〜14B / 20B級MoE	Qwen3-14B、gpt-oss-20B、GPT-OSS Swallow	業務文書の翻訳が安定し始めるクラス。用語集との組み合わせで実務に
24GB	32B級	Qwen3-32B、ELYZA-Thinking-1.0-Qwen-32B、Qwen3 Swallow 32B	ビジネス文書・契約書の実務ライン。長文の一貫性と敬語の自然さが上がる
48GB〜 / 128GB統合メモリ	大型MoE	gpt-oss-120B、GPT-OSS Swallow 120B、Qwen3-235B-A22B	品質最優先。複数人・複数言語の同時処理にも余裕

ノートPCでの線引きは『ノートPCで動く軽量ローカルLLM 2026』で詳しく扱っています。実測報告では、4Bクラスは短文の翻訳、8B以上でニュース記事レベルの翻訳が任せられる一方、「日本語なら英語に、英語なら日本語に」のような条件付きの制御は8Bでも失敗が報告されています。翻訳方向は、モデルに判断させずに前処理で決めて渡すのが安全です。

日本語強化版（Swallow系、ELYZA系）は、日本語の生成の自然さで有利になる場面があります。ただし日→英の方向では、元のモデルの英語性能が効くため、両方向で使うなら汎用モデルと日本語強化版の両方を評価セットに通して比べます。

PDF・Word文書を翻訳するパイプライン

実務の翻訳対象は、チャット欄に貼れる短い文章ではなく、PDFやWordの文書です。文書をそのままモデルに渡すと、レイアウトが崩れ、長文では訳抜けが起きます。次の5段階のパイプラインで組みます。

PDF・Word・スキャン画像
    ↓ 1. 抽出: テキストと構造（見出し・段落・表）を取り出す
    ↓ 2. 分割: 段落または条項の単位に分ける。表はセル単位
    ↓ 3. 翻訳: 分割した単位ごとに、用語集と文脈（前後の段落・文書種別）を添えて翻訳
    ↓ 4. 用語集適用: 訳語を用語集で照合し、ぶれを検出・置換
    ↓ 5. 再構成: 元の構造に訳文を戻し、原文と訳文を対訳で並べる

1. 抽出

テキストが埋め込まれたPDFやWordは、構造ごと取り出せます。スキャン画像や画像だけのPDFは、先にOCRでテキスト化します。機密書類をローカルでテキスト化する方法は『ローカルLLMでOCR』で整理しています。OCRの段階で数値や固有名詞が捏造されると、翻訳でそのまま引き継がれるため、OCRの検証工程は翻訳前に済ませます。

2. 分割

段落・条項・箇条書きの1項目を単位にします。契約書なら条項番号ごと、仕様書なら見出しごとです。1回に渡す量を小さくすると、訳抜けと用語のぶれが減ります。ただし文脈を失わないように、直前の段落と文書の種別（契約書・仕様書など）を参考情報として添えます。表は行ごと、またはセルごとに翻訳し、構造を保ちます。

3. 翻訳

分割した単位ごとに、翻訳方向・文書種別・用語集・文体の指示を添えてモデルに渡します。プロンプトの設計は次章で扱います。

4. 用語集適用

翻訳後に、用語集の語が指示どおりの訳語になっているかを機械的に照合します。「甲」が途中から「Party A」になり、後半で「the first party」に変わる、といったぶれは、この段階で検出して置換するか、該当段落だけ再翻訳します。

5. 再構成と対訳表示

訳文を元の構造に戻し、原文と訳文を左右または上下に並べた対訳形式で出力します。確認する担当者が原文と突き合わせやすくなり、誤訳の発見が速くなります。最終的な訳文は、この対訳を見た担当者の確認を経て確定します。

用語集とスタイル指示で訳語のぶれを抑えるプロンプト設計

ローカルLLMの翻訳で最も効く工夫は、モデルの入れ替えではなく、用語集と文体指示をプロンプトに組み込むことです。社内の用語集（製品名、部署名、契約の定義語、単位の表記）をあらかじめ用意し、翻訳する段落に関係する語だけを添えます。用語集全体を毎回渡すと、小型モデルでは指示が埋もれます。

プロンプトの例を示します。

あなたは法務文書の翻訳者です。次の英文の契約条項を日本語に翻訳してください。

【文書種別】業務委託契約書
【文体】「である」調。条項番号と定義語は原文のまま保持する
【用語集】
- "Service Provider" → 「受託者」
- "Client" → 「委託者」
- "Deliverables" → 「成果物」
- "Confidential Information" → 「秘密情報」
【禁止】原文にない内容の追加、数値・日付・金額の変更、省略
【出力】訳文のみ。説明や注釈は付けない

【直前の条項（参考）】
（前の段落の訳文）

【翻訳する条項】
（原文）

技術文書では、文体と単位の指示が中心になります。

次の技術仕様の段落を英語に翻訳してください。
【文体】簡潔な技術英語。受動態より能動態を優先
【単位】SI単位を維持し、数値と単位の間に半角スペースを入れる（例: 10 mm）
【用語集】「公差」→ "tolerance"、「面取り」→ "chamfer"
【禁止】数値の丸め、単位の換算、箇条書きの統合

要点は次の4つです。

翻訳方向と文書種別を明示し、モデルに判断させない
用語集は段落に関係する語だけを渡す
「追加・変更・省略の禁止」を明文化する。小型モデルは省略で辻褄を合わせようとします
出力形式を「訳文のみ」に固定し、後工程で機械的に扱えるようにする

同じプロンプトを同じモデルに複数回通して訳文が揺れないかも確認します。揺れが大きい場合は、生成の設定（温度）を下げる、分割を細かくする、モデルのクラスを上げる、の順で対処します。

リアルタイム翻訳（会議・チャット）の現実的な線引き

「ローカルLLMで会議をリアルタイム翻訳したい」という要望もあります。可能な範囲と、期待しないほうがよい範囲を分けます。

現実的な範囲

社内チャットやメールの受信文を、その場で日本語の下訳にして読む
会議の文字起こしを一定の区切りごとに翻訳し、数十秒遅れで字幕のように表示する
自分の発言を事前に下訳し、確認してから送る

期待しないほうがよい範囲

同時通訳のように、発話と同時に正式な訳を出す
確認なしで取引先に送る正式な文書の翻訳
専門用語が多い技術討議の、用語集なしでの即時翻訳

速度はモデルのサイズとマシンのメモリ帯域で決まります。7〜8Bクラスを量子化して動かした場合の生成速度の目安は『ノートPCで動く軽量ローカルLLM 2026』に実測値があります。会議の字幕用途では、精度を落としても小型モデルで速度を確保し、正式な議事録の翻訳は会議後に上位クラスのモデルで行う、という二段構えが現実的です。会議音声の文字起こし自体をローカルで行う構成は、別途整理します。

社内で翻訳精度を確かめる手順

ローカルLLMの翻訳精度は、公開ベンチマークの順位ではなく、自社の文書で確かめます。手順は次のとおりで、評価セットの作成から合否判定まで2週間程度で終わります。

評価セットを作る（30〜50文）

実際に翻訳する文書の種類（契約書、仕様書、メールなど）から、段落単位で30〜50件を抜き出します。種類が複数あるなら種類ごとに分けます
固有名詞、数値と単位、否定表現、長い複文、箇条書きを意図的に含めます。モデルが失敗しやすい箇所を入れないと、評価が甘くなります
可能なら、過去に人手で翻訳した訳文を正解の参考として並べます。正解がない場合は、評価者が「許容できる訳」の基準を先に話し合います

採点軸を4つに固定する

採点軸	見る内容	減点の例
誤訳	意味が原文と違う	否定の反転、主語の取り違え、数値の変更
訳抜け	原文の内容が訳文にない	条件節の省略、箇条書きの統合、注記の欠落
用語	用語集どおりの訳語か	定義語のぶれ、製品名の誤り
自然さ	読み手がそのまま使える文か	不自然な語順、敬語の崩れ、冗長な直訳

誤訳と訳抜けは「1件でもあれば不合格」に近い重みで扱い、用語と自然さは段階的に採点します。採点の重みは文書の用途で変えます。契約書なら誤訳と訳抜けが最優先、社内向けの参考訳なら自然さの重みを下げます。

担当者3人で採点する

翻訳対象の業務を知る担当者2人と、言語の確認ができる担当者1人の3人で採点します。1人の評価は好みに引きずられます
候補モデルの訳文は、どのモデルの出力か伏せて提示します
同じ評価セットを候補モデルすべてに通し、同じ3人が採点します

合否ラインを先に決める

「誤訳・訳抜けが評価セットのうち何件以下なら実務に使う」という合格ラインを、採点の前に文書で決めます
合格したモデルの中で、速度と機材費を踏まえて1つに絞ります
不合格なら、用語集の追加、分割の見直し、モデルのクラスを上げる、の順で対処し、再評価します

この評価手順は、ローカルLLMのPoCでモデル選定を行う工程と同じです。段階の設計と費用の考え方は『ローカルLLM PoCの費用・期間・進め方』で整理しています。

ローカルLLMの翻訳で失敗しやすい点

評価セットに意図的に入れるべき、失敗しやすい箇所を挙げます。いずれも実務の翻訳で起きると影響が大きい項目です。

固有名詞: 社名・製品名・人名を翻訳してしまう、または表記が揺れる。用語集で「訳さない語」を明示します
数値と単位: 桁区切りの誤読、単位の勝手な換算、日付形式の変更。「数値・単位・日付を変更しない」を禁止事項に入れ、翻訳後に原文との数値一致を機械的に照合します
否定の反転: 「〜でない限り」「〜を除き」のような二重否定や例外規定で、意味が反転する。契約書の例外条項は必ず評価セットに含めます
長文での省略: 長い段落で、後半の条件や箇条書きの一部が訳文から落ちる。分割を細かくし、訳抜けを原文との文数比較で検出します
文体の混在: 「です・ます」と「である」が段落で混ざる。文体指示を毎回添え、後工程で表記を揃えます
訳文に説明が混じる: モデルが「この条項は〜を意味します」と注釈を付け足す。出力を訳文のみに固定します

これらは、モデルを上位クラスに変えるだけでは消えません。用語集・分割・禁止事項・後工程の照合という設計で抑え、残りを担当者の確認で拾う、という構えが必要です。

導入前チェックリスト

ローカルLLMでの翻訳を業務に組み込む前に、次の項目を確認します。

まとめ

ローカルLLMでの翻訳が必要なのは、NDA・法令・業界ガイドラインで社外送信が禁じられた文書です。それ以外は学習利用なしの法人契約で足り、併用構成が現実的です
モデルは翻訳専用ではなく、日本語で使えるローカルLLMからVRAM別に選びます。16GBならQwen3-14BやQwen3 Swallow系、24GBならQwen3-32BやELYZA-Thinking-1.0-Qwen-32Bが起点で、日英の双方向・長文の一貫性・用語の固定・量子化の影響の4点で投げ比べます
PDFやWordは「抽出→分割→翻訳→用語集適用→再構成」のパイプラインで扱います。段落単位で翻訳し、用語集で訳語を固定し、対訳で確認します
精度は自社の文書で作った評価セット30〜50文を、誤訳・訳抜け・用語・自然さの4軸で担当者3人が採点して判断します。合否ラインは採点前に決めます
リアルタイム翻訳は「下訳を即時に出す」までが現実的な線です。正式な訳文には確認工程を挟みます

会議音声を文字にしてから翻訳する場合、文字起こしも社内で完結させる構成は『Whisperをローカルで動かす2026』を参照してください。

よくある質問

Q. ローカルLLMの翻訳精度はクラウドの翻訳サービスと比べてどうですか？

文書の種類と用語集の有無で評価が変わるため、一概には言えません。本記事では数値での断定を避け、自社の文書で確かめる手順を示しています。24GB級のGPUで32Bクラスのモデルを使い、用語集と段落単位の分割を組み合わせれば、ビジネス文書の実務ラインに届くというのが2026年時点の整理です。評価セット30〜50文を4軸で採点し、合否ラインで判断してください。

Q. ローカルLLMで翻訳するなら、どのモデルがおすすめですか？

翻訳専用のモデルを探すより、日本語で使えるローカルLLMから手元のVRAMに合わせて選びます。16GBならQwen3-14B、gpt-oss-20B、Qwen3 Swallow系、24GBならQwen3-32BやELYZA-Thinking-1.0-Qwen-32Bが起点です。日→英と英→日の両方向で使う場合は、汎用モデルと日本語強化版の両方を評価セットに通して比べます。

Q. PDFの契約書をそのまま翻訳できますか？

そのまま渡すのではなく、テキストを抽出して条項ごとに分割し、用語集を添えて翻訳し、元の構造に戻す流れで行います。スキャンしたPDFは先にローカルのOCRでテキスト化し、数値や固有名詞の捏造がないかを確認してから翻訳します。訳文は原文との対訳で担当者が確認してから確定します。

Q. 用語のぶれはどう防ぎますか？

社内の用語集を用意し、翻訳する段落に関係する語だけをプロンプトに添えます。翻訳後に用語集と機械的に照合し、ぶれた箇所は置換するか再翻訳します。「原文にない内容の追加、数値の変更、省略の禁止」と「訳文のみを出力する」指示も併せて入れると、小型モデルでも崩れにくくなります。

Q. 会議のリアルタイム翻訳はできますか？

文字起こしを一定の区切りごとに翻訳して数十秒遅れで表示する、受信したチャットを即時に下訳する、といった用途は現実的です。同時通訳のように発話と同時に正式な訳を出すことや、確認なしで取引先に送る正式文書の翻訳には向きません。字幕用途は小型モデルで速度を確保し、正式な訳は会議後に上位クラスで行う二段構えが現実的です。

Q. ノートPCだけで翻訳できますか？

メモリ16GBのノートPCで8〜9Bクラスの量子化モデルを動かせば、ニュース記事レベルの翻訳や社外秘文書の下訳は任せられます。8GBでは4Bクラスになり、短文の翻訳に範囲を絞ります。契約書や長い技術文書で長文の一貫性が必要な場合は、24GB級のGPUか大容量の統合メモリ機で32Bクラス以上を使います。

主な参考資料: Nejumi Leaderboard 4、Qwen3公式ブログ、Swallow LLM公式、ローカルLLMでの翻訳検証（藤井太洋氏の実測）、個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」

TodoONadaでは、社外に出せない文書の翻訳をローカルLLMで行う構成の設計と、自社文書での精度評価を支援しています。機材を買う前に、DGX SparkやMacを貴社オフィスに設置して2週間で判定する社内設置の実現性検証（30万円〜・税別・機材貸出料込み）と、機材のみの短期貸出（1週4.5万円〜・税別）を承っています。評価セットの作り方や用語集の整備から相談したい、という段階でも歓迎します。

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
ローカルLLM 社内設置の実現性検証（機材貸出） — 機材を買う前に、DGX SparkやMacを貴社オフィスに2週間設置して「置けるか」を判定。機材のみの短期貸出も対応

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。