目次
「ドキュメントを10言語に翻訳したい。Claude Code と Codex、どっちが向いてる?」——この問いには落とし穴がある。多くの人が 「ツールの優劣」と「翻訳の上手さ」を混同しているからだ。実は Claude Code も Codex も『翻訳エンジン』ではない。両者はあくまで エージェント型のCLI作業環境であり、実際に訳文を生み出すのはその裏で動く 言語モデルのほうだ。
だから問いは2つに割れる。「翻訳という作業をどの環境で回すのが効率的か(=ツール選び)」と、「訳文の品質をどのモデルに任せるか(=モデル選び)」。結論を先に書くと、リポジトリ内の多数ファイルを構造を保ったまま一括翻訳するなら Claude Code が向く。理由はローカルファイルへの直接アクセス・1Mトークンの長文脈・多ファイルの一貫編集の強さだ。翻訳品質そのものは、言語ペアで最適モデルが変わる——本記事では公式データと複数ソースに基づき、ツールとモデルの両面から徹底的に整理する。
多言語翻訳の早見結論
— 「どのツールか」と「どのモデルか」は別問題
最短の指針:「手元のファイル群を構造ごと正確に訳す」なら Claude Code。
そのうえで 訳文の最終品質は、対象言語に強いモデルを選ぶ。
※本記事のツール仕様は各公式・複数技術メディア(2026年5月時点)、多言語性能は Anthropic 公式の多言語サポート資料(MMLUベースの対英語スコア)に基づく。モデルの版や数値は更新され得るため、最終判断は自分の言語ペアでの実測を推奨する。
1. 結論:先に答えを言う
忙しい人のために要点だけ。
- 作業環境なら Claude Code が翻訳向き。理由は ①ローカルの多数ファイルを直接読み書きできる ②1Mトークンの長文脈で「記事本文+用語集+既訳」を丸ごと載せられる ③多ファイルにまたがる用語・トーンの一貫編集が得意——の3点。
- Codex が向くのは「非同期・クラウドで放置バッチ」。サンドボックスで安全に走らせPRを自動で開く運用や、OSS CLIを自前パイプラインに組み込む用途では強い。ただし文脈窓は相対的に小さめ。
- 翻訳品質は「ツール」ではなく「モデル」で決まる。長文のトーン一貫性は Claude、自然な欧州・東アジア言語と慣用句は GPT 系、低資源言語・方言の広さは Gemini 系——という傾向が複数ソースで一致。言語ペアごとに最適が変わる。
2. 論点は2つある——「作業環境」と「翻訳品質」を分ける
冒頭で触れた最重要ポイントを、もう一段ていねいに。Claude Code と Codex はエージェント型のCLI(コマンドライン)作業環境だ。ファイルを読み、編集し、テストを走らせ、PRを開く——いわば「自律的に手を動かす作業者」である。一方、その作業者の『言語能力』を担うのが裏側のモデル(Claude Opus/Sonnet、GPT-5.5、Gemini 3.1 Pro など)だ。
つまり「翻訳が上手いか」は基本的に モデルの問題であり、「翻訳という作業を効率よく・正確に・大量に回せるか」が ツールの問題になる。だから この2軸を混ぜて『どっちが翻訳に強い?』と一括で問うと答えを見失う。本記事は第3〜4章でツール、第5〜6章でモデルを扱い、第7章で両者を組み合わせた実践に落とす。
3. Claude Code vs Codex——翻訳作業に効く違い
まずツール軸。両者は「エージェント型CLIコーダー」という点では同類で、2026年5月時点の一般コーディング性能はほぼ拮抗している。だが 翻訳という作業に効く差に絞ると、性格がはっきり分かれる。
| 観点 | Claude Code | Codex |
|---|---|---|
| 実行場所 | ローカル端末でリアルタイム協働 | クラウドのサンドボックスで非同期実行 |
| ファイルアクセス | ローカルの全ファイルを直接読み書き | サンドボックス前提、ファイル/PC操作は相対的に限定 |
| 文脈窓(目安) | 最大 約1Mトークン(Opus 系) | 最大 約400Kトークン |
| 多ファイル一貫編集 | 強い(用語・トーンを横断で揃えやすい) | 可能だが大量同時編集は文脈制約を受けやすい |
| 並列実行 | サブエージェントを並列起動しやすい | 非同期タスク・放置運用に強い |
| CLIの性質 | Anthropic 提供(IDE統合が厚い) | OSS(Apache-2.0)、自前パイプラインに組み込みやすい |
| 料金レンジ | 個人 $20〜$200/月(同水準) | 個人 $20〜$200/月(同水準) |
翻訳作業の現実を思い出してほしい。訳すべきは「素の文章」だけではない。HTML/Markdown のタグ、コードブロック、用語集、既存の訳、ファイル名規則——これらを 壊さずに、何十ファイルも横断して一貫して処理する必要がある。ここで効くのが ①ローカル全ファイルへの直接アクセスと ②大きな文脈窓、そして ③多ファイル一貫編集の信頼性だ。一般的な比較でも、Claude Code は「難しい多ファイルのリファクタリングの品質」で評価が高く、Codex は「非同期のPR自動化・タスク単位のコスト・サンドボックス安全性」で評価される、という整理が定着している。詳細な総合比較はClaude Code vs Codex 徹底比較も参照してほしい。
4. 翻訳タスクではどちらが向くか
上の違いを「翻訳の3つの典型シナリオ」に当てはめると、向き不向きがはっきりする。
シナリオ別・向いているツール
迷ったら:「手元のファイル群を、構造を壊さず一貫して訳す」が主目的なら Claude Code。
「CI/夜間バッチで自動的に回したい」なら Codex の非同期運用が刺さる。
補足すると、大規模な多言語サイトやドキュメントの翻訳(数十〜数百ファイル、用語の統一が必須)では、ローカルファイルを直接いじれて文脈窓が大きい Claude Code が扱いやすい。逐一の確認をしながら品質を担保したいときの「senior な相棒」感が強みだ。一方、翻訳を完全自動の定期ジョブに組み込むなら、OSS CLI でパイプライン化しやすく非同期で放置できる Codex が選択肢に入る。
5. おすすめモデル——翻訳品質で選ぶ
ここからモデル軸。訳文の品質はツールではなくモデルで決まるので、ここが本丸だ。重要な前提として、「コーディングのベンチマークが高い=翻訳が上手い」ではない。翻訳は別の能力(トーン・慣用句・文化的文脈・低資源言語のカバレッジ)が問われる。
まず最も信頼できる一次データから。Anthropic は公式に 言語ごとの対英語性能(MMLUを professional 翻訳者が各言語に訳したテストでの相対スコア)を公開している。本サイトが扱う言語を抜粋する(数値は Claude Opus 系・拡張思考あり、英語=100%)。
| 言語 | 対英語スコア(Claude) | 傾向 |
|---|---|---|
| スペイン語 | 98.1% | 最上位帯 |
| フランス語 | 97.9% | 最上位帯 |
| ポルトガル語(ブラジル) | 97.8% | 最上位帯 |
| ドイツ語 | 97.7% | 最上位帯 |
| アラビア語 | 97.1% | 高水準 |
| 中国語(簡体) | 97.1% | 高水準 |
| 日本語 | 96.9% | 高水準 |
| ヒンディー語 | 96.8% | 高水準 |
読み取れるのは、Claude は主要言語で対英語 96〜98% という非常に高い水準を保つこと。とくにドイツ語・日本語・韓国語など トーンや敬体の一貫性が問われる言語で評価が高い、というのが各所の一致した見方だ(※このスコアは MMLU 推論ベースの代理指標で、純粋な翻訳品質そのものではない点に注意)。一方で、各モデルには得意・不得意の色がある。複数ソースで繰り返し語られる傾向を整理する。
翻訳で語られる各モデルの色
これらは複数メディアで繰り返し報告される「傾向」であり、固定の優劣ではない。
モデルの版は頻繁に更新されるため、最終判断は必ず自分の言語ペアで実測すること。
重要なのは、Claude Code でも Codex でも、呼び出すモデルは選べる/切り替えられるということ。つまり「ツールは Claude Code、品質チェックは別モデルにも当てる」といった組み合わせが現実的だ。Opus 4.8 の世代では 「正直さ」が大幅に向上し、訳の不確かな箇所を自己申告しやすくなった点も、翻訳レビューの効率に効く。
6. 言語別・用途別の使い分け
前章の傾向を、実務の意思決定に落とす。
| 状況 | おすすめの寄せ方 | 理由 |
|---|---|---|
| 長文ドキュメントを統一トーンで | Claude(Opus/Sonnet) | 大文脈で全文一括、敬体・用語の一貫性 |
| 欧州・東アジア主要言語の自然さ重視 | GPT-5.5 系 / Claude | 慣用句・言い回しの滑らかさ |
| 低資源言語・方言まで広く | Gemini 3.1 Pro | 言語カバレッジの広さ |
| 大量・低コストでバッチ翻訳 | Gemini Flash / 各社の軽量・高速モデル | 速度とコストのバランス |
| 専門文書(法務・医療等) | 上位モデル+人間レビュー必須 | 誤訳リスクが許容できない領域 |
現実的なベストプラクティスは 「1モデルで全部」ではなく「役割分担」だ。たとえば 下訳を高速・安価なモデルで一気に作り、品質が要る言語だけ上位モデルで磨く。あるいは 主翻訳と別モデルでのクロスチェックを組み合わせる。Claude Code / Codex のようなエージェント環境は、こうした 複数モデルを使い分けるパイプラインを自動で回すのに向いている。
7. 実践:翻訳パイプラインの組み方
ツールとモデルを決めたら、品質を安定させる「型」を作る。エージェントCLIで多言語翻訳を回すときの実践ポイントを挙げる。
エージェント翻訳の5つの鉄則
- 原文=英語(または日本語)を1つの基準に固定。多言語は基準言語から訳すと品質が揃う。
- 用語集(glossary)を渡す。ブランド名・固有名詞・UI文言の訳を辞書化し、全言語で統一。
- 「構造・タグ・コードは保持、文章だけ訳す」を明示。HTMLの属性値やコードは触らせない。
- 言語ごとに並列実行。8言語を同時に走らせると速い(APIレート上限に注意)。
- 機械的な品質チェックを最後に通す。未翻訳の混入・記号の取り違え・文字数超過などを自動検出。
この型がはまると、「下訳→自動リント→人間が要所だけ確認」の流れで、品質を保ったまま大幅に高速化できる。プロンプト設計とエージェントの仕組みを押さえておくと、パイプラインの精度がさらに上がる。なお、外部から取り込んだテキストを訳す場合は、権限設計とプロンプトインジェクション対策も忘れずに。
8. 注意点(正直に)
最後に、判断を誤らないための注意点を正直に並べる。
- ベンチマーク≠実翻訳品質。本記事の対英語スコアは MMLU 推論ベースの代理指標で、訳文の自然さ・正確さと完全には一致しない。必ず自分の言語ペア・ジャンルで実測を。
- モデルの版は頻繁に変わる。「○○が最強」は数か月で陳腐化する。固定の結論より 「役割分担+実測」の運用のほうが寿命が長い。
- 専門・法務・医療翻訳は人間レビュー必須。誤訳の代償が大きい領域では、AIは下訳に留め、最終責任は人間が負う。
- コストは「品質×量」で設計。全量を上位モデルで訳すと高い。下訳は安価モデル、要所だけ上位、が経済的。
- Codex のサンドボックス制約。ローカルの大量ファイルを直接いじる用途では、クラウドサンドボックスが制約になる場面がある。
まとめ
「多言語翻訳は Claude Code と Codex どっちが向いている?」への答えは——問いを2つに分けることから始まる。作業環境としては、リポジトリ内の多数ファイルを構造を保って一貫翻訳するなら Claude Code が向く(ローカル直編集・1M文脈・多ファイル一貫性)。非同期・クラウドで放置バッチ/PR自動化なら Codexが刺さる。
そして 翻訳品質はツールではなくモデルで決まる。長文のトーン一貫性は Claude、主要言語の自然さは GPT 系、低資源言語・方言の広さは Gemini 系——という傾向を踏まえ、言語ペアごとに最適を選び、下訳と仕上げで役割分担するのが2026年の現実解だ。最後にもう一度だけ強調する:固定の「最強モデル」を探すより、自分のタスクで実測し、複数モデルを使い分けるパイプラインを持つこと——これが、モデルの世代交代に振り回されない一番賢いやり方だ。
関連記事:Claude Code vs Codex 徹底比較、Claude Opus 4.8 徹底解説、GPT-5.5 vs Claude Opus 比較、ChatGPT / Claude / Gemini 無料枠比較、Claude Agent SDK とは も併読を。
FAQ
Q. 結局、翻訳が一番上手いのはどのモデルですか?
A. 「言語ペアと用途による」が正直な答えです。長文のトーン一貫性なら Claude、主要言語の自然な訳と慣用句なら GPT 系、低資源言語・方言の広さなら Gemini 系が報告される傾向。固定の「最強」は存在せず、版の更新も速いので、自分の対象言語で実測するのが確実です。
Q. Claude Code と Codex で、訳文の品質は変わりますか?
A. ツール自体は訳文を生みません。品質を決めるのは裏で動くモデルです。どちらのツールでもモデルは選べるため、「品質はモデル選び、効率はツール選び」と分けて考えてください。差が出るのは 作業の速さ・正確さ・大量処理のしやすさのほうです。
Q. 数十ファイルの多言語サイトを訳すなら?
A. Claude Code が扱いやすいです。ローカルの全ファイルを直接読み書きでき、1Mトークンの文脈で本文・用語集・既訳をまとめて参照でき、多ファイルにまたがる用語・トーンの統一が得意だからです。言語ごとに並列実行すれば、大量翻訳も現実的な時間で回せます。
Q. コストを抑えるコツは?
A. 役割分担です。全量を上位モデルで訳すと割高になります。下訳は安価・高速なモデル(Gemini Flash 等)で一気に作り、品質が要る言語・箇所だけ上位モデルで磨く。さらにプロンプトキャッシュやバッチ処理が使えるなら活用すると、大量翻訳のコストを大きく下げられます。
Q. 専門文書(契約書・医療文書)もAI翻訳で大丈夫ですか?
A. 下訳までに留め、最終確認は専門の人間が行ってください。誤訳の代償が大きい領域では、どんな上位モデルでも単独運用は危険です。AIで効率化しつつ、責任ある最終チェックは人間が担う——この線引きが安全です。