Codex翻訳の使い方｜コードと仕様を守る確認手順で実践

Codex翻訳はコード変更と分けて考える

Codexに「このリポジトリを日本語化して」とだけ頼むと、コメントや文書だけでなく、識別子、テストの期待値、画面に表示する文字列まで同じ基準で変更されるおそれがあります。翻訳の目的が利用者向け文書の整備なのか、開発者向けコメントの統一なのか、画面表示の多言語化なのかで、触ってよいファイルと確認方法は変わります。最初に成果物の種類を限定し、コードの挙動を変える作業とは別の依頼として扱うことが重要です。

この切り分けを先に行えば、翻訳の結果を「文章が読みやすくなったか」と「ソフトウェアが変わらず動くか」の二つの軸で評価できます。両方を一度に確認するのが難しい場合は、まず文書だけを対象にして、次にコメント、最後に画面文言という順番で広げます。対象を小さく始めることは、Codexの能力を疑うためではなく、失敗したときに原因を一つに近づけるための実務的な工夫です。

なぜ今、Codex翻訳の確認方法を整えるのか

2026年10月2日から3日にかけて、OpenAIのCodex公式リリース一覧では0.162.0-alpha.2〜.10が先行版として公開されています。連続して版が出る時期は、利用者が新しい版を試したくなる一方、翻訳の自然さや作業速度を版番号だけから判断しやすい時期でもあります。公式ページに掲載された事実と、手元で確認した結果を分けて残せば、「新しいから訳が正確なはず」という推測を、実際の差分やテスト結果に置き換えられます。出典: https://github.com/openai/codex/releases

さらに、OpenAI Developersの2026年9月11日の資料では、GPT-6 Astra向けの指示を必要以上に長くせず、作業に関係する文書を必要な場面で参照できる形に整える考え方が説明されています。翻訳でも同じで、全リポジトリの説明を毎回貼り付けるより、対象ディレクトリ、用語表、変更しない範囲、完了条件を短く示す方が判断しやすくなります。指示ファイルを置いている場合も、翻訳に関係する部分だけを確認し、過去の前提をそのまま残さないよう見直します。出典: https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra

今のCodex翻訳で大切なのは、どの言語へ変えられるかを競うことではありません。版が変わっても、対象の意味、コードの境界、訳語の判断、確認記録が追えることです。翻訳は文章の完成品を一度に得る仕事ではなく、原文と訳文を比べて不明点を減らす作業として設計すると、モデルや入口が変わっても品質を保ちやすくなります。

版番号を機能差の代わりにしない

公式リリース一覧には、安定版と先行版が区別され、公開日や版番号が掲載されます。しかし、番号が新しいことだけでは、翻訳の語調、長文の扱い、固有名詞の保持、差分の正確さまでは分かりません。詳細な変更説明がない版について、翻訳性能が上がった、特定言語に強くなったと書く根拠はありません。まず小さなREADMEや数個のコメントで同じ依頼を試し、原文にない情報を足していないかを確認しましょう。

言語より先に成果物を決める

「英語にする」という指定だけでは、READMEなのかコメントなのか、画面文言なのかが曖昧です。対象ファイル、対象見出し、除外するコードブロック、読者、希望する語調、完了時に返してほしい確認内容まで決めると、Codexは翻訳と編集を分けて考えられます。特にコード例は、文章部分だけを訳すのか、説明用のコメントも含めるのかを明記してください。

翻訳対象を棚卸しする

翻訳を始める前に、対象ファイルを一覧にし、変更してよい範囲を決めます。ディレクトリ全体を対象にする場合でも、コード、設定、テスト、文書の拡張子を同じ扱いにしないことが重要です。READMEだけならリンクとコード例を重点的に見れば済みますが、コメントまで含めるなら、コメントが説明する実装の現在地も確認しなければなりません。

文章として訳すもの

README、設計メモ、利用手順、FAQ、変更履歴の説明は、読者が意味を理解するための文章です。原文の文法を一語ずつ移すより、前提、条件、例外、操作の順序が保たれているかを優先します。見出しの階層、箇条書き、表、リンク先は構造として残し、文章だけを訳すように指示すると差分を読みやすくできます。コードブロックの中にあるコマンドやJSONのキーは、説明文と分けて扱います。

そのまま保つもの

関数名、変数名、クラス名、型名、APIのパス、CLIのオプション、環境変数名、ファイルパス、ログのエラーコードは、原文の表記を保つのが基本です。これらを日本語へ変えると、検索、参照、コピー、テストの期待値が壊れます。製品名やモデル名も、公式の表記に合わせてください。訳語を添える場合は括弧や説明文で補い、呼び出しに使う文字列自体を置き換えないようにします。

迷いやすいもの

画面のボタン、通知、エラーメッセージは、文章であると同時にプログラムから参照されるデータでもあります。翻訳対象に含めるなら、表示文字列を管理する場所、言語を切り替える仕組み、文字列を検査するテストを先に確認します。コメントの中のコード例や設定例も同様です。説明だけを訳すのか、実際に貼り付けて使う例まで訳すのかを分けると、読者向けの自然さと実行可能性を両立しやすくなります。

Codex翻訳の依頼文を組み立てる

依頼文は「訳して」で終わらせず、Codexが判断に迷う境界を先に書きます。OpenAIの資料では、Codexは大きなコードベースを読み、計画し、変更と検証を進める用途で紹介されています。翻訳を成功させるには、文章の質だけでなく、何を変更しないか、何をもって完了とするかを指定する必要があります。次の四つを順番に書くと、短い依頼でも確認可能な成果物になります。出典: https://developers.openai.com/cookbook/examples/codex/code_modernization

Step 1: 対象と完了条件を固定する

最初に言語の組み合わせではなく、ファイルと範囲を示します。「docs/guide.mdの見出しAからCまでを英語から日本語へ訳す」「コードブロック、URL、ファイル名は変更しない」のように書くと、作業範囲が明確になります。完了条件には、指定範囲の未翻訳文がないこと、見出しとリンクが壊れていないこと、変更外のファイルに差分がないことを含めます。全体を見てから対象外を報告する、という終わり方も有効です。

Step 2: 訳語と表記のルールを渡す

製品名、機能名、エラーの種類、利用者の呼び方に決まった表記があるなら、短い用語表として提示します。たとえば「workspaceはワークスペース」「repositoryはリポジトリ」「agentはエージェント」と決めたうえで、公式名称だけは原文表記を維持する、と指定します。用語が未確定なら、勝手に統一せず候補を残すよう求めてください。翻訳後に用語を探し直すより、先に判断基準を渡す方が差分を小さくできます。

Step 3: 変更しないものを列挙する

翻訳作業では、変更対象の指示よりも、変更禁止の指示が重要になることがあります。識別子、コードブロック、URL、コマンド、設定キー、表の列数、見出しの階層をそのまま保つと書きます。テストファイルや設定ファイルを対象外にする場合も、ファイル名やディレクトリ名を具体的に示してください。曖昧な「コードは触らない」だけでは、コメント内の例まで含めて判断が揺れるため、例外があれば先に定義します。

Step 4: 不確かな箇所を止めて報告させる

原文に誤字がある、用語が二通りに読める、リンク先と説明が食い違う、といった場合は、自然な訳を選んで黙って進めるより、該当箇所を一覧にして確認を求める方が安全です。依頼文に「判断に必要な前提がない場合は、原文、候補訳、確認したい点を示して停止する」と入れます。完了報告には、変更ファイル、保留箇所、確認したコマンド、テスト結果を分けて記載させると、あとから人が判断できます。

Codex翻訳を進める手順

大きな文書を一度に渡すより、対象を小さな単位に区切って原文と訳文を比べます。以下はREADME、コメント、画面文言のいずれにも応用できる順序です。

1. 原文ファイルを読み、対象の見出し、コードブロック、リンク、固有名詞を先に特定します。対象外のファイルや変更禁止の文字列も記録し、翻訳前の状態を基準にします。
2. 用語表を作り、製品名、機能名、技術用語、略語、エラー表記を一行ずつ定めます。決められない語は無理に確定せず、候補と理由を残します。
3. 一つの見出し、または一つのコメント群だけを訳します。原文の段落構造、表、箇条書き、インラインコードを保ち、説明を膨らませる場合は原文にない補足として分けます。
4. 原文と訳文を段落単位で照合します。条件、否定、例外、数値、単位、リンク、コマンド引数が抜けていないかを確認し、迷いがある箇所は保留にします。
5. 差分を読み、対象外のファイルや識別子に変更がないかを確認します。画面文言やコメントを変えた場合は、関連するテスト、サンプル、表示幅も調べます。
6. 必要なテストや文書確認を行い、翻訳による変更と、もともと存在した問題を分けて記録します。Codexの完了表示だけで終わらせず、人が採用する範囲を判断します。

この順序の利点は、翻訳の誤りとコードの誤りを同じ差分の中で見失いにくいことです。たとえば、コメントの一文だけを訳したなら、コメントの内容が現在の分岐条件と合っているかを確認できます。画面文言を訳したなら、文字数や改行で表示が崩れないかを確認できます。作業単位ごとに記録を残せば、別の版や別のモデルでやり直す場合も、どこから比較すればよいかが明確になります。

入口ごとの使い分け

Codex翻訳は、どの入口を使うかで確認のしやすさが変わります。重要なのは、同じ製品名でも、ローカルのファイルを直接扱う場面と、ブラウザやアプリから結果を確認する場面では、差分の残し方が異なることです。翻訳の規模、手元の編集環境、確認する人の人数を基準に選びます。

CLIは差分を細かく読みたいときに向きます。対象ファイルを明示し、訳したあとに検索やテストを同じ場所で確認しやすいためです。IDEでは、コメントの直前にある処理や型定義を見ながら訳せる一方、開いているファイルだけを全体と誤認しないよう、対象範囲を依頼文に書きます。アプリやCloudを使うときは、結果を受け取ったあとに必ず対象プロジェクトと変更ファイルを確認し、長い文章の一部だけが変更された状態を完成品とみなさないようにします。

訳文の品質を確認する四つの軸

翻訳の確認は、自然な日本語かどうかだけでは足りません。原文の意味、用語の一貫性、コードとの整合性、表示のしやすさを分けて見ると、問題の場所がわかります。各軸で「問題なし」「要確認」「対象外」を付けるだけでも、判断の抜けを減らせます。

意味が保たれているか

最初に、主語、条件、否定、順序、例外、数値が原文と対応しているかを見ます。日本語では主語が省略されやすく、英語では条件が文の後半に置かれることがあります。翻訳者の理解で補った主語が仕様を変えていないか、mustやmayの強さが変わっていないか、対象者が利用者から管理者へすり替わっていないかを確認します。自然さはこの確認のあとに評価します。

用語がそろっているか

同じ概念を文書ごとに別の語へ訳すと、検索性が下がり、読者は別機能だと誤解します。用語表にない語を見つけたら、既存の公式表記、画面の表示、コード内の名前を照合します。あえて別の語を使う場合は、対象読者や文脈の違いを説明できるようにします。大文字小文字、単数複数、略語、カタカナの長音も決めておくと、複数ファイルの調整がしやすくなります。

コードと一致しているか

コメントやREADMEの手順が、現在のコマンド、オプション、ファイルパス、画面名と一致しているかを確認します。翻訳を機会に、原文の古い説明を勝手に修正したくなることがありますが、翻訳と仕様更新は分けて記録します。明らかな誤りは保留にして報告し、修正する場合は原文側と訳文側の両方へ反映するかを人が決めます。コード例はコピーして読める形か、設定キーや引用符が変わっていないかも見ます。

表示と読みやすさを見られるか

日本語訳では、英語より文が長くなったり、逆に短くなったりします。ボタン、表、見出し、エラー表示に収まるか、改行位置が不自然でないか、リンクの文字列が意味を持つかを確認します。画面文言では文字数だけでなく、前後のラベルや状態表示と組み合わせたときの意味も見ます。文章を整えるためにHTMLやMarkdownの構造を変える場合は、文言の変更と構造の変更を差分で区別してください。

英日・日英翻訳で起こる落とし穴

言語の方向によって、誤りの出方は変わります。英日では、短い技術用語に多くの意味が含まれるため、文脈を失うと一般語へ寄りすぎます。日英では、主語や対象を補う必要がある場面で、原文にない責任範囲を追加しやすくなります。方向ごとの注意点を依頼文に入れておくと、Codexが文章の自然さだけを優先しにくくなります。

英語を日本語にするとき

「context」は文脈、コンテキスト、周辺情報など、使う場所によって訳が変わります。「session」も会話、セッション、作業単位のどれを指すかを、画面や仕様で確認してください。「permission」「approval」「access」は似て見えますが、権限、承認、アクセスを混ぜると、誰が何を許すのかが曖昧になります。訳語を固定する前に、その語が指す対象と判断の主体を確認することが大切です。

日本語を英語にするとき

日本語の「確認する」「対応する」「必要に応じて」は、英語では主体と条件を補わないと意味が広がります。「確認する」が読むだけなのか、テストを実行することなのか、「対応する」が修正することなのか、利用者へ案内することなのかを決めてください。仕様書やREADMEでは、行動、条件、結果を分けて書くと、英語にした後も完了条件が伝わりやすくなります。

コメントとエラー文を同じように訳さない

コメントは実装の理由や前提を説明する文章ですが、エラー文は利用者や別のプログラムが受け取る契約の一部です。コメントは読みやすさを整えられても、エラー文は画面、ログ、テスト、問い合わせ資料との整合性が必要になります。エラーの識別子やコードは保ち、表示文言を変える場合は検索して利用箇所を一覧にする、と依頼文へ書くと安全です。

失敗したときの切り分け方

Codex翻訳で問題が起きたときは、まず「訳が不自然」なのか「原文の意味と違う」のか「コードを変えてしまった」のかを分けます。一つの報告にすべてを混ぜると、文章の修正で済む問題にコード確認を広げたり、逆に挙動の変更を言い回しの問題として見逃したりします。次の順番で確認すると、戻す範囲を小さくできます。

1. 変更ファイルを確認し、依頼した対象以外に差分がないか調べます。対象外の差分があれば、翻訳の評価より先にその原因を切り離します。
2. 原文と訳文を段落、表、コードブロックごとに比べ、条件、否定、数字、リンク、固有名詞の欠落を探します。
3. 用語表と公式の製品表記を照合し、同じ概念が別の語になっていないか確認します。決められない箇所は候補として残します。
4. コメントや文書が説明するコードを読み、手順、オプション、ファイルパス、画面名が現在の状態と一致するか確認します。
5. テスト、文書のリンク確認、必要な表示確認を行い、翻訳で起きた問題と既存の問題を分けて記録します。

Codexの版を更新した直後なら、同じ原文の短いサンプルで再確認するのも有効です。公式リリース一覧からわかるのは版の公開事実であり、特定の言語や文書形式での結果ではありません。旧版と新版で違いが出た場合も、「新しい版が正しい」と決めるのではなく、原文、依頼文、訳文、差分、確認結果を並べて人が採用する方を判断します。

そのまま使えるCodex翻訳の依頼文

次のテンプレートは、READMEやコメントの翻訳を小さな範囲から始めるためのものです。[]の部分を対象に合わせて置き換え、必要なら用語表を追加します。全体の文体を一度に指定するより、変更対象と禁止事項を具体的に書く方が、結果の確認がしやすくなります。

次の範囲だけを翻訳してください。

対象ファイル: [ファイルパス]
対象範囲: [見出し名、行、コメントの範囲]
翻訳方向: [英語から日本語 / 日本語から英語]
読者: [開発者 / 利用者 / 管理者]

用語:
- [原語] は [訳語] とする
- 製品名、モデル名、API名は公式表記を使う

変更しないもの:
- 関数名、変数名、クラス名、型名、ファイルパス
- URL、コマンド、オプション、設定キー、エラーコード
- コードブロックの内容とMarkdownの見出し階層

完了条件:
- 対象範囲の文章を訳す
- 原文の条件、否定、数値、リンク、例外を保つ
- 対象外のファイルを変更しない
- 迷う箇所は候補訳と確認点を報告して保留する
- 最後に変更ファイル、保留箇所、確認した内容を報告する

この依頼文を使うときも、対象範囲が大きすぎないかを先に確認します。用語表にない言葉をすべて自動で決めてほしい場合は、許容する判断の範囲と、あとで人が読む一覧の形式を追加します。逆に、公開直前の文書や外部仕様に関わる文言は、候補訳を出させてから採用を決める方が適しています。

Codex翻訳を実務に定着させる考え方

翻訳を一度きりの文章作成と見ると、次の更新で同じ用語を再び迷い、原文と訳文の差が広がります。対象ディレクトリごとに読者、用語、変更禁止の範囲、確認方法を短く記録しておけば、後から別の人や別の版で作業するときも判断を再利用できます。OpenAIの資料が示すように、指示は長ければよいのではなく、必要な場面で必要な情報へ到達できることが重要です。出典: https://developers.openai.com/api/docs/guides/prompting

ただし、指示ファイルへすべての翻訳ルールを詰め込む必要はありません。共通の表記だけを短く保ち、製品ごとの用語や特定文書の例外は対象ファイルの近くに置く方が、別の作業へ影響を広げにくくなります。OpenAIのCodex向け資料でも、リポジトリを近代化するときは、対象、設計、検証の成果物を分けて、何を確認すれば完了かを明示しています。翻訳でも、原文の調査、訳文の作成、差分の確認、表示やテストの確認を分けると、結果を説明できます。出典: https://developers.openai.com/cookbook/examples/codex/code_modernization

最新版のCodexを試す場合は、翻訳の仕事と版の評価を同じ日に行わない方法もあります。まず現在使っている版で基準となる訳文を作り、次に新しい版で同じ小さな入力を試します。差分が良くなったように見えても、どの語が変わり、どの条件が保たれ、どの確認が通ったかを記録します。これなら、版更新による違いを文章の印象だけでなく、根拠のある比較として扱えます。

まとめ

Codex翻訳の要点は、コードを動かす文字列と、人が読む文章を最初に分けることです。READMEやコメントは意味、条件、用語、構造を保って訳し、関数名、API名、コマンド、設定キー、エラーコードは原則としてそのまま残します。画面文言を変える場合は、表示場所とテストの期待値まで確認します。

2026年10月2〜3日の0.162.0-alpha系のように版が続けて公開されても、番号だけで翻訳性能を決めつけることはできません。公式リリースの事実と、手元で確認した訳文や差分を分け、小さな対象で比較します。依頼文には対象、訳語、変更禁止、完了条件、不確かな箇所の扱いを入れます。

自然な文章を作ることは入口にすぎません。原文の意味が残り、コードや表示が壊れず、用語がそろい、あとから人が差分を読める状態まで確認できて、Codex翻訳は実務で使える成果物になります。