日本語技術文書の翻訳に適切なコーディングエージェントはどれか
Claude Code、Codex、Antigravityの3大コーディングエージェントを用いて日本語技術文書（Rubyリファレンス）を英訳し、その品質をLLMとGrammarlyで徹底比較しました。検証の結果、明示的な一貫性チェックを行うOpenAIの「Codex（GPT 5.2 High）」が、翻訳精度と流暢さの両面で最も優れたパフォーマンスを発揮しました。
目次
はじめに
技術文書をLLMで翻訳することを想定し、コーディングエージェントを活用する例を考えます。現在、著名なコーディングエージェントはClaude Code（Anthropic）、Codex（OpenAI）、Antigravity（Google）など群雄割拠ですが、どのコーディングエージェントが最も技術文書として適切な翻訳結果を生み出すのでしょうか。日本語で書かれた技術文書を英語に翻訳する場合を想定し、具体的な実験を通じて、定量的・定性的に検証します。
なぜコーディングエージェントで翻訳なのか
LLMを使えば日本語で書かれた技術文書を英語に翻訳することは容易です。しかし、大規模な技術文書となったときにいくつか単なるLLMのコールだけでは不十分なこともあります。
- 専門用語の統一性：例えば、10～数十のマークダウンファイルがあったときに、個別のマークダウンを翻訳するのでは、マークダウン間で専門用語の翻訳は統一されるのでしょうか。あるマークダウンファイル間で異なる翻訳をしていると読者は混乱してしまいます。
- スタイルの統一性：英語にも書き方のスタイルがあるので、これも同様にマークダウンファイル間で統一する必要があります
- トークン数の問題：最近のLLMではロングコンテクストも対応しているため一定解決していますが、マークダウンファイルが多くなった場合は一定厳しいものがあります。この点、コーディングエージェントは適宜コンテクストを圧縮するため、トークン数の伸びに対しては頑強です。
- 見直しの必要性：最適な翻訳がAPI1コールだけでできるのでしょうか。見直しのプロセスが必要で、そこでコーディングエージェントのような動的なワークフローが役立ちます。
コーディングエージェントの場合、もともと複数のファイルを編集する（GitHubのようにいくつも階層的になっているファイル）想定なので、このへんの課題に対しては一定頑強になります。
できると嬉しいこと
日本語で書かれた技術文章をコーディングエージェントで英語に翻訳したいです。なぜかというと、自分が日本語で書いた本の英語版をLLMを使っていい感じに生成したいからです。日本語で本を出すと市場のパイは日本だけになってしまいますが、英語で出せば格段に市場のパイが大きくなります。
しかし、翻訳はかなりのコストがかかるため、完全でないにしろ十分に読めそうな英語を出すためのエコシステムを考えたいです。
実験について
日本語で書かれた技術文章を複数のコーディングエージェントを使って翻訳し、その結果を定量的に評価します。
検証ドキュメント
できるだけ日本語ネイティブの人が書いたドキュメントが良いので、Rubyのリファレンスマニュアルを使いました。このドキュメントはCC-BYで利用できます。
オブジェクト指向スクリプト言語 Ruby リファレンスマニュアル
トップページから1回のクリックで辿れるページをすべてマークダウンとしてダウンロードします。このダウンロードはClaude Code（4.5 Opus）を使って行いました。今回取得したマークダウンは以下のリンクからダウンロードできます。
※重要：コーディングエージェントのミスにより、原文では日本語なものの、一部英語として保存されているものがあります。これはノイズデータにはなるため、利用の際は注意してください。
ダウンロードは以下のプロンプトで行いました。
このRubyのドキュメントをMarkdown形式で画像込みでダウンロードして。リンク先も追跡しますが、このトップページから1クリックで飛べるものだけダウンロードすればよい https://docs.ruby-lang.org/ja/3.4/doc/index.html
検証したコーディングエージェント
「Claude Code（Anthropic）」、「Codex（OpenAI）」、「Antigravity」の3つを対象に、モデルを変えて計5個のケースを調べました。
- Claude Code
- Claude 4.5 Opus
- Claude 4.5 Sonnet
- Codex
- GPT 5.2 High
- GPT 5.2 Codex High
- Antigravity
- Gemini 3.0 Pro High
これらのモデルは2025/12現在最先端のモデルです。OpusとSonnetは明らかにOpusのほうが良くなるのですが、評価指標の妥当性の検証のため比較します。
Codexはデフォルトが◯◯Codexモデルなのですが、ChatGPTで使っている通常のLLM（GPT 5.2）も切り替えて利用できます（/modelコマンド）。翻訳の場合は、Codexモデルでないほうが良い可能性が高いため比較します。
AntigravityはGemini 3 Proが良いのはほぼ明らかなので、単純にGemini vs 他モデルで検証を目的とします。
翻訳プロンプト
以下のようなプロンプトを各コーディングエージェントに対して実行しました。
ruby_docs/original以下のマークダウンファイルすべてを、ruby_docs/codex_gpt52codexhighフォルダ以下に英語で翻訳して。ただし、技術書としてわかりやすく適切な英語のスタイルにし、専門用語の翻訳の統一に注意して
注意点があり、コーディングエージェントによっては、全体のディレクトリ構造を見て、他のモデルの翻訳結果を見てチートするものがあります（Codexで確認）。こういうのを見かけたときは、他の翻訳結果をコーディングエージェントが動いているディレクトリの外に出すようにしてください。
また、各コーディングエージェントはコンテクストをキャッシュするため、モデルを切り替えるときはコンテクストを空にするようにします。
LLM as a Judge
LLMによる評価（LLM as a Judge）を使用しました。以下の3点から評価します。
- 翻訳の正確性（Translation Accuracy）：原文と翻訳結果を比較したときに、どの程度正確な翻訳か
- 技術的正確性（Technical Accuracy）：原文と同等の技術的正確性を翻訳後も保っているか
- 翻訳結果の流暢さと読みやすさ（Fluency & Naturalness）：翻訳後の英文が流暢で読みやすいかどうかを見ます。これは翻訳結果だけを対象とします。
各マークダウンについて5ケースを全部並べて、最初に原文を並べ、後は順番をシャッフルして（位置によってLLMが注目するバイアスがあるため）、上記の3点について各10点満点で評価します。これをStructured OutputなどのJSON出力で固定できる出力で評価します。
具体的には以下のようなコードでプロンプトを作成します。
def create_prompt(original_text: str, candidates: List[Dict[str, Any]]) -> str:
"""Construct the prompt for the LLM."""
candidates_text = ""
for cand in candidates:
candidates_text += f"\n--- Candidate {cand['label']} ---\n{cand['content']}\n"
prompt = f"""You are an expert technical translator and evaluator.
Your task is to evaluate the quality of multiple English translations of a Japanese technical document (Ruby documentation).
Below is the Original Japanese Text, followed by several Candidate Translations.
The Candidate Translations are labeled anonymously (e.g., Candidate A, Candidate B).
Please evaluate each candidate based on the following three criteria on a scale of 1 to 10 (10 being perfect):
1. **Translation Accuracy**: Does the translation accurately convey the meaning of the original text?
2. **Technical Accuracy**: Is the technical terminology and context preserved correctly?
3. **Fluency & Naturalness**: Is the English natural, easy to read, and grammatically correct?
**Original Text:**
{original_text}
{candidates_text}
**Output Format:**
Return a JSON object with the following structure:
{{
"evaluations": [
{{
"candidate_label": "A",
"scores": {{
"translation_accuracy": <int>,
"technical_accuracy": <int>,
"fluency": <int>
}},
"reasoning": "<short explanation>"
}},
...
]
}}
"""
評価に使用したモデル
これは通常のLLMのAPIを使い、以下の3モデルで比較しました
- Claude 4.5 Opus
- Gemini 3 Pro
- GPT 5.2 Thinking High
各評価モデル・評価ファイルに対して、5回評価を実行します。そのために、候補の順番はシャッフルします。
結果
コーディングエージェント・観点 vs 評価モデルの詳細結果
行：使用したコーディングエージェント×評価観点
列：評価モデル
で比較した点数です。各セルは、全33個のマークダウンファイルの評価結果の平均です。10点満点です。
| Candidate | Metric | Claude | GPT | Gemini |
|---|---|---|---|---|
| antigravity_gemini3pro | fluency | 7.79 | 7.88 | 7.60 |
| antigravity_gemini3pro | technical_accuracy | 8.58 | 8.56 | 8.10 |
| antigravity_gemini3pro | translation_accuracy | 8.32 | 8.53 | 8.23 |
| claudecode_claude45opus | fluency | 8.99 | 8.93 | 8.95 |
| claudecode_claude45opus | technical_accuracy | 9.20 | 9.19 | 9.14 |
| claudecode_claude45opus | translation_accuracy | 8.99 | 9.20 | 9.29 |
| claudecode_claude45sonnet | fluency | 8.69 | 8.78 | 8.62 |
| claudecode_claude45sonnet | technical_accuracy | 9.11 | 9.13 | 8.91 |
| claudecode_claude45sonnet | translation_accuracy | 8.98 | 9.16 | 9.13 |
| codex_gpt52codexhigh | fluency | 8.74 | 8.60 | 8.96 |
| codex_gpt52codexhigh | technical_accuracy | 8.93 | 8.96 | 8.93 |
| codex_gpt52codexhigh | translation_accuracy | 8.69 | 8.98 | 9.23 |
| codex_gpt52high | fluency | 9.52 | 9.48 | 9.77 |
| codex_gpt52high | technical_accuracy | 9.46 | 9.44 | 9.68 |
| codex_gpt52high | translation_accuracy | 8.90 | 9.19 | 9.54 |
全般的に、codex_gpt52highとclaudecode_claude45opusが高い傾向にあります。同じClaude Codeでも、Claude 4.5のOpusとSonnetを比較すると、Opusのほうが一貫して高いため、評価指標の妥当性も確認できます。
また、「評価モデルがGeminiだからGeminiが翻訳文章だけ良く評価される」といったこともなく、評価モデル関係なく「良いものは良いし、悪いものは悪い」という結果になりました。
評価観点別の合計点
行：使用したコーディングエージェント
列：評価観点
評価モデル間の合計を取り、上記のように集計します。これは30点満点になります。一番右の列は、評価観点の和で90点満点です。
| Candidate / Metric | fluency | technical_accuracy | translation_accuracy | Sum |
|---|---|---|---|---|
| antigravity_gemini3pro | 23.27 | 25.24 | 25.08 | 73.59 |
| claudecode_claude45opus | 26.87 | 27.53 | 27.48 | 81.88 |
| claudecode_claude45sonnet | 26.09 | 27.15 | 27.27 | 80.51 |
| codex_gpt52codexhigh | 26.30 | 26.82 | 26.90 | 80.02 |
| codex_gpt52high | 28.77 | 28.58 | 27.63 | 84.98 |
全ての観点において、codex_gpt52highが最良の結果となりました。
日本語の生成能力では、個人的にはGeminiが検討している印象があるのですが、日本語から英語への生成能力となると、OpenAIのモデルの強みが非常に出ている結果となりました。
Geminiの翻訳結果は、Fluency（流暢さ）が他のモデルより大きく損なっている結果となりました。
評価モデル別の合計点
行：使用したコーディングエージェント
列：評価モデル
評価観点で合計をとり、評価モデルごとに見ます。これは評価モデル別の得点が、もとの生成モデルとあまり関係がないことを示すものです。
| Candidate / Metric | Claude | GPT | Gemini | Sum |
|---|---|---|---|---|
| antigravity_gemini3pro | 24.69 | 24.97 | 23.93 | 73.59 |
| claudecode_claude45opus | 27.18 | 27.32 | 27.38 | 81.88 |
| claudecode_claude45sonnet | 26.78 | 27.07 | 26.66 | 80.51 |
| codex_gpt52codexhigh | 26.36 | 26.54 | 27.12 | 80.02 |
| codex_gpt52high | 27.88 | 28.11 | 28.99 | 84.98 |
実際、Antigravityの生成結果に対してVertex（Gemini）は一番低い評価をつけてますし、Codexの結果に一番良い評価をつけているのはGeminiです。
別の評価軸：Grammarly
Grammarlyには、Proofreaderの「Writing quality」というスコアがあります。これは書いた英語を100点満点で評価してくれるものです。
原文の日本語との比較ではなく、あくまで翻訳結果の評価になります（Fluencyと似たような評価）が、いくつかのケース、サンプルについてこの点数を取ってみましょう。
| file | antigravity_gemini3pro | claudecode_claude45opus | codex_gpt52high |
|---|---|---|---|
| doc/glossary.md | 54 | 88 | 91 |
| function/index.md | 93 | 98 | 100 |
| spec/call.md | 89 | 90 | 89 |
| spec/class.md | 92 | 97 | 100 |
| spec/commands.md | 84 | 92 | 92 |
| Average | 82.40 | 93.00 | 94.40 |
| 参考：LLM Judge Sum | 73.59 | 81.88 | 84.98 |
fileがZip内のパスです。最初の5行がGrammarlyのスコア（100点満点）、下から2行目がその平均点（100点満点）、一番下がLLM as a Judgeのときの合計点（90点満点）です。
こうしてみると、Grammarlyの点数とLLM as a Judgeの点数は連動していることがわかります。おそらく、Grammarlyのスコアも内部で何らかの言語処理のモデルを使っているため、似たような傾向になるのだと思われます。
なぜCodexでうまくいったか
Codex＋GPT 5.2でうまくいったのは理由があり、明示的にPlanの段階で最後に一貫性チェックを行っていたためです。たまたまPlanガチャが良かったかもしれませんが、もしかしたら他のエージェントの場合は「明示的にリフレクションしろ」といったほうがいいかもしれません。
□ Inventory source Markdown files
□ Derive terminology glossary
□ Translate files to new folder
□ Fix internal links and anchors
□ Run consistency checks
定性評価
antigravity_gemini3pro、claudecode_claude45opus、codex_gpt52highの3ケースについて、原文と翻訳結果を表示します。内容はC API関数一覧のもので、ダウンロード時にコーディングエージェントが変換したときにかなり編集が入っています。
原文
あくまでWeb上のリファレンスではなく、コーディングエージェントで全文ダウンロードしてマークダウン化したときに得られた文章です。
# Ruby 3.4 リファレンスマニュアル - C API 関数一覧
## 概要
このページは、Ruby 3.4リファレンスマニュアルの関数一覧ページです。Ruby インタプリタのC APIに関する関数群を網羅的に記載しています。
## 主要なセクション
### メモリ管理機能
- **ALLOC / ALLOC_N / ALLOCA_N**: メモリ割り当て関連の機能。ALLOC_Nは「type型のメモリをn個割り当てる」など、異なるサイズ指定に対応しています。
- **Data_Make_Struct / Data_Wrap_Struct**: 構造体をRubyオブジェクトでラップするための関数群
### オブジェクト操作
- **rb_obj_** プレフィックス: オブジェクトの操作全般（クローン、ダプリケーション、フリーズなど）
- **rb_class_** プレフィックス: クラス操作関連の機能
- **rb_mod_** プレフィックス: モジュール操作関連の機能
### 型変換
- **FIX2INT / FIX2LONG**: Fixnumから整数型への変換
- **INT2FIX / INT2NUM**: 整数からFixnum/Bignumへの変換
- **rb_String / rb_Array / rb_Integer**: 各種型への変換関数
### 評価・実行制御
- **rb_eval_string**: 文字列をRubyプログラムとしてコンパイル・評価
- **rb_funcall**: メソッド呼び出し
- **rb_yield**: ブロック実行
- **rb_protect / rb_rescue / rb_ensure**: 例外処理メカニズム
### スレッド管理
- **rb_thread_** プレフィックス: スレッド生成、切り替え、同期処理など多数の関数
### ガベージコレクション
- **rb_gc_mark / rb_gc_mark_children**: GCマーキング処理
- **rb_gc_disable / rb_gc_enable**: GC制御
### メソッド定義
- **rb_define_method**: インスタンスメソッド定義
- **rb_define_singleton_method**: 特異メソッド定義
- **rb_define_module_function**: モジュール関数定義
## 関数設計の特徴
このAPIは「type型のメモリをn個割り当てる」といった明確な役割分担と、一貫性のある命名規則を採用しており、Cレベルでの細粒度な制御を提供しています。
---
*このドキュメントは[Creative Commons License](https://creativecommons.org/licenses/by/3.0/)の下で提供されています。*
翻訳結果：Antigravity + Gemini 3.0 Pro
あまり自分英語詳しいわけではないですが、少し翻訳結果が硬い印象を受けます。
# Ruby 3.4 Reference Manual - C API Function List
## Overview
This page is a list of functions in the Ruby 3.4 Reference Manual. It comprehensively covers functions related to the Ruby interpreter's C API.
## Major Sections
### Memory Management Functions
- **ALLOC / ALLOC_N / ALLOCA_N**: Functions related to memory allocation. ALLOC_N supports specifications like "allocate n items of type memory".
- **Data_Make_Struct / Data_Wrap_Struct**: Functions to wrap structures with Ruby objects.
### Object Manipulation
- **rb_obj_** prefix: General object manipulation (clone, duplication, freeze, etc.)
- **rb_class_** prefix: Functions related to class manipulation
- **rb_mod_** prefix: Functions related to module manipulation
### Type Conversion
- **FIX2INT / FIX2LONG**: Conversion from Fixnum to integer type
- **INT2FIX / INT2NUM**: Conversion from integer to Fixnum/Bignum
- **rb_String / rb_Array / rb_Integer**: Conversion functions to various types
### Evaluation and Execution Control
- **rb_eval_string**: Compile and evaluate string as Ruby program
- **rb_funcall**: Method call
- **rb_yield**: Block execution
- **rb_protect / rb_rescue / rb_ensure**: Exception handling mechanism
### Thread Management
- **rb_thread_** prefix: Numerous functions for thread creation, switching, synchronization, etc.
### Garbage Collection
- **rb_gc_mark / rb_gc_mark_children**: GC marking processing
- **rb_gc_disable / rb_gc_enable**: GC control
### Method Definition
- **rb_define_method**: Instance method definition
- **rb_define_singleton_method**: Singleton method definition
- **rb_define_module_function**: Module function definition
## Function Design Features
This API adopts a clear role division such as "allocating n items of type memory" and consistent naming conventions, providing fine-grained control at the C level.
---
*This document is provided under the [Creative Commons License](https://creativecommons.org/licenses/by/3.0/).*
Claude Code＋Claude 4.5 Opus
Geminiの訳よりかはこっちのほうがいいかなと思います。ただ使ってる単語がちょっと難しいですね。
# Ruby 3.4 Reference Manual - C API Function List
## Overview
This page is the function list page for the Ruby 3.4 Reference Manual. It comprehensively documents the C API function groups for the Ruby interpreter.
## Major Sections
### Memory Management
- **ALLOC / ALLOC_N / ALLOCA_N**: Memory allocation functions. ALLOC_N "allocates memory for n objects of type" and handles different size specifications.
- **Data_Make_Struct / Data_Wrap_Struct**: Function group for wrapping structures in Ruby objects
### Object Operations
- **rb_obj_** prefix: General object operations (clone, duplication, freeze, etc.)
- **rb_class_** prefix: Class operation functions
- **rb_mod_** prefix: Module operation functions
### Type Conversion
- **FIX2INT / FIX2LONG**: Conversion from Fixnum to integer types
- **INT2FIX / INT2NUM**: Conversion from integers to Fixnum/Bignum
- **rb_String / rb_Array / rb_Integer**: Conversion functions to various types
### Evaluation and Execution Control
- **rb_eval_string**: Compiles and evaluates a string as a Ruby program
- **rb_funcall**: Method invocation
- **rb_yield**: Block execution
- **rb_protect / rb_rescue / rb_ensure**: Exception handling mechanisms
### Thread Management
- **rb_thread_** prefix: Numerous functions for thread creation, switching, synchronization, etc.
### Garbage Collection
- **rb_gc_mark / rb_gc_mark_children**: GC marking processing
- **rb_gc_disable / rb_gc_enable**: GC control
### Method Definition
- **rb_define_method**: Instance method definition
- **rb_define_singleton_method**: Singleton method definition
- **rb_define_module_function**: Module function definition
## API Design Characteristics
This API adopts clear role separation such as "allocates memory for n objects of type" and consistent naming conventions, providing fine-grained control at the C level.
---
*This document is provided under the [Creative Commons License](https://creativecommons.org/licenses/by/3.0/).*
Codex＋GPT 5.2 High
平易で簡潔にかかれており、個人的に一番読みやすい訳です。箇条書きの部分のスタイルはちょっと怪しい部分は難点かもしれない。
# Ruby 3.4 Reference Manual - C API Function Index
## Overview
This page is a function index for the Ruby 3.4 Reference Manual. It provides an overview of the Ruby interpreter’s C API functions.
## Major Sections
### Memory management
- **ALLOC / ALLOC_N / ALLOCA_N**: memory allocation helpers. For example, `ALLOC_N` allocates `n` items of a given type.
- **Data_Make_Struct / Data_Wrap_Struct**: functions for wrapping C structs as Ruby objects
### Object operations
- Functions with the **`rb_obj_`** prefix: object operations (clone, duplication, freeze, etc.)
- Functions with the **`rb_class_`** prefix: class-related operations
- Functions with the **`rb_mod_`** prefix: module-related operations
### Type conversion
- **FIX2INT / FIX2LONG**: convert a Fixnum to an integer type
- **INT2FIX / INT2NUM**: convert an integer to Fixnum/Bignum
- **rb_String / rb_Array / rb_Integer**: convert to each corresponding type
### Evaluation and control flow
- **rb_eval_string**: compile and evaluate a string as Ruby code
- **rb_funcall**: call a method
- **rb_yield**: execute a block
- **rb_protect / rb_rescue / rb_ensure**: exception handling mechanisms
### Thread management
- Functions with the **`rb_thread_`** prefix: thread creation, switching, synchronization, and more
### Garbage collection
- **rb_gc_mark / rb_gc_mark_children**: GC marking
- **rb_gc_disable / rb_gc_enable**: GC control
### Method definition
- **rb_define_method**: define an instance method
- **rb_define_singleton_method**: define a singleton method
- **rb_define_module_function**: define a module function
## Design Notes
This API uses clear, consistent naming and provides fine-grained control at the C level.
---
*This document is provided under the [Creative Commons License](https://creativecommons.org/licenses/by/3.0/).*
結論
原文をダウンロードしてくる部分はやや改良の余地はあるだろうけど、とりあえず日本語→英語への技術文章の翻訳ならCodexで検討すれば良さそう。
Shikoan's ML Blogの中の人が運営しているサークル「じゅ～しぃ～すくりぷと」の本のご案内
技術書コーナー
北海道の駅巡りコーナー