Codex英語の使い方と日本語プロンプトの違い・実践例付き

Codex英語を選ぶ理由は「言語力」より指示の揺れを減らすこと

Codexに英語で頼むとよい、と言われる理由を「英語のほうが賢くなる」とだけ理解すると、期待と結果の差が大きくなります。OpenAIの説明では、モデルは英語向けに最適化されつつ、多くの言語を理解して生成できます。つまり日本語が使えないわけではありません。英語を選ぶ主な利点は、開発文書、エラーメッセージ、ライブラリの用語、コードレビューで使われる表現を同じ語彙にそろえやすいことです。公式の言語案内は、複数言語を扱えることと、可能ならプロンプト全体を一つの言語に保つと一貫性を保ちやすいことを説明しています。詳細はOpenAI Help Centerの多言語テキストの説明で確認できます。

さらにCodexは、入力を読んで終わるチャットではなく、必要に応じてファイルを調べ、コマンドやテストを実行し、その結果を次の判断材料にします。OpenAIのCodex agent loop解説でも、最初の指示にツールの結果が積み重なって次の応答へ渡る流れが説明されています。最初の依頼で「何を変えるか」「何を変えないか」「何を見れば終わりか」を英語で明確にしておくと、その後に返ってくる確認質問や作業報告も読みやすくなります。英語は魔法の性能スイッチではなく、コードに近い語彙で境界を示すための道具です。

英語が向く場面

ライブラリ名、型名、エラーメッセージ、テスト名、設定キーが中心になる依頼では、英語の短い指示が扱いやすくなります。たとえば「認証を改善して」のような抽象的な日本語を訳すより、Update the validation in src/auth/session.ts. Preserve the public API. Add a regression test for an expired session. のように対象、制約、確認項目を並べるほうが、何を調べるべきかが明確です。固有名詞を翻訳しないことも大切です。session, public API, regression test といった語をそのまま使えば、検索や差分確認の対象がぶれにくくなります。

チーム内の開発資料が英語中心の場合も、英語プロンプトには利点があります。ただし、英語の長文を作ることが目的ではありません。依頼する人が読んで意味を確認できる短さを保ち、必要なら日本語の補足を別段落に置きます。Codexに返答言語を指定する場合は、Reply in Japanese, but keep code identifiers and error messages unchanged. のように、出力の言語とコード上の表記を分けて書くと実務に合います。

日本語で書いたほうがよい場面

仕様の背景、利用者が困っている状況、画面上で感じる違和感、社内で決めた優先順位は、日本語のまま書いたほうが正確なことがあります。たとえば「初めて使う人が迷わないように、失敗時は原因と次の操作を同じ画面で読めるようにする」という要件は、英語の定型表現に置き換えるより、関係者が合意した日本語を残すほうが意図を守れます。ユーザー向け文言の修正では、翻訳調の英語が混ざると、かえって望ましい語感から離れることもあります。

日本語を使うときは、対象のファイルや画面を具体的にします。「いい感じに直す」ではなく、「resources/views/login.blade.php のエラー表示だけを対象にし、文言は日本語のまま、余白と色は既存のデザインに合わせる」と書きます。要件の背景は日本語、コード上の対象は英語表記、完了条件は短い英語という組み合わせでも構いません。大切なのは文体の統一ではなく、どの情報をどの言語で固定するかを先に決めることです。

英語プロンプトの基本構造を四つに分ける

英語で書くときに最も避けたいのは、丁寧な説明を一つの段落へ詰め込み、Codexに目的と制約を推測させることです。OpenAIのCodexベストプラクティスは、依頼にゴール、背景、制約、完了条件を含める形を勧めています。これは英語専用の文法ではなく、日本語にも使える整理法です。先に日本語でこの四つを埋め、最後に英語へ置き換えると、翻訳作業が単なる言い換えで終わりません。公式ガイドはCLI、IDE拡張、デスクトップアプリに共通する考え方として、この構造を紹介しています。参照先はCodex公式のBest practicesです。

ゴールは、変更後に何ができるようになるかを一文で表します。背景は、どのファイルやエラー、既存仕様を前提にするかです。制約は、変更範囲、互換性、使ってはいけない方法、維持すべき命名などを示します。完了条件は、テスト、画面表示、ログ、差分のいずれで判断するかを書きます。この順番で並べると、Codexが先に調査すべきことと、最後に報告すべきことが分離されます。英語の自然さに悩んだら、短い主語と動詞を使い、条件を箇条書きではなく短い行に分けたコードブロックで渡してもよいでしょう。

GoalとContextを先に固定する

最初の二行で、目的と根拠を切り分けます。Goal: Prevent duplicate requests when the Save button is clicked twice. は到達したい状態を示し、Context: The relevant code is in src/components/SaveForm.tsx. The current test is ... は調査範囲を示します。目的に実装方法まで詰め込むと、より安全な修正案を検討する余地が狭くなります。逆に背景が広すぎると、関係のないファイルを読む時間が増えます。対象パス、再現条件、現状のエラー、参照すべきテストを優先して書きましょう。

Constraintsで変更範囲を囲む

制約は「してほしくないこと」だけではなく、守るべき境界です。Do not change the public API.、Keep the existing Japanese labels.、Use the current test framework. のように、既存利用者へ影響する点を短く書きます。依存パッケージの追加が不要ならそのことも明示します。大きな修正では、対象外のディレクトリや、調査だけにとどめるファイルを指定すると、差分を見直しやすくなります。英語の命令形にすると強く見えますが、ここで重要なのは語気ではなく、優先順位を曖昧にしないことです。

Done whenで完了条件を数える

完了条件は「うまく動けば終わり」から一段具体化します。Done when: the regression test passes, the existing tests remain green, and the diff is limited to the authentication module. のように、確認対象と差分範囲を組み合わせます。テストを追加できない場合は、再現手順、期待結果、実際の結果を記録する条件に置き換えます。Codexから「実装はできたが未確認」と返ってきたときも、Done whenがあれば不足している作業が明らかです。英語を使う目的は、完璧な表現ではなく、終了ラインを観測可能にすることです。

日本語の要件を英語の実行指示へ変える手順

ここでは、既存の日本語プロジェクトで、英語を使う場面だけを切り出す方法を示します。日本語の要件を捨てて英語へ置き換えるのではなく、意味を保ったまま、Codexが調査と修正を進めやすい形へ変換します。英語を読んで確認できる人がいない場合も、先に日本語の原文を保存し、その下に短い英語版を置けば、意図の照合ができます。英語版だけを残すと、後から仕様を見直す人が背景を失うため、要件と実行指示の役割を分けるのが安全です。

Step 1: 日本語で成功状態を一文にする

まず、画面やコードのどこがどう変われば成功かを書きます。「ログインを改善する」では広すぎるので、「期限切れのセッションを送信前に検出し、利用者へ再ログインを促す」とします。この文には対象、条件、望む結果が含まれています。まだ実装方法を決めていないなら、特定の関数名やパッケージ名を無理に加えません。成功状態を決めると、Codexが調べる範囲を必要以上に広げずに済みます。

Step 2: 対象と制約を英語の短文にする

次に、パス、再現条件、保持する仕様を英語へ移します。たとえば Inspect src/auth/session.ts and the related tests.、Keep the existing response shape and Japanese user-facing messages. のように、動詞から始めます。日本語の固有名詞、画面文言、エラーコードは訳さず、引用符で囲みます。翻訳に迷う文章は、原文を残してから、対象と操作だけを英語にするほうが安全です。

Step 3: 確認方法を最後に指定する

最後に、実行してほしいテストと報告してほしい内容を明記します。Run the focused test first, then run the relevant existing tests. Report changed files, test commands, and any remaining risk. のように、確認の順序と報告形式を指定できます。ここで結果を捏造しない条件も必要です。テストを実行できなかったときは、理由と代わりに確認した内容を返すように書きます。英語が短くても、完了条件まで含めれば依頼全体の精度は上がります。

Step 4: 一回の依頼を小さく試す

いきなり複数の機能を一度に頼まず、最初は調査と小さな修正に分けます。最初の返答で対象ファイル、理解した再現条件、変更案が合っているかを確認し、次の依頼で実装へ進みます。Codexが想定外のファイルを読み始めたら、依頼を止めて対象範囲を補足します。小さな依頼を一つの検証単位にすると、英語の表現が原因なのか、要件の不足が原因なのかを見分けやすくなります。

実践例：日本語のログイン不具合を英語で頼む

例として、ログイン画面で期限切れセッションを送信したとき、利用者には一般的な失敗メッセージしか表示されないケースを考えます。目的は認証処理の全面改修ではなく、期限切れだけを明確に扱い、既存の表示や応答形式を保つことです。英語にする前に、日本語の要件として「対象はログイン送信」「期限切れだけ専用の案内」「他の失敗は現状維持」「認証関連テストを追加」と決めます。これが決まっていれば、英語は短くできます。

Step 1: 調査を依頼する

Inspect the login flow for expired sessions.
Start with src/auth/session.ts, src/pages/login.tsx, and the related tests.
Do not modify files yet.
Report the current failure path and the smallest safe change.

この段階では修正を頼まず、対象と現状の確認だけを求めます。「最小の安全な変更」と書くことで、全面的な認証方式の変更を避ける意図を伝えます。返答では、Codexが実際に読んだファイル、期限切れを判定している場所、画面へエラーを渡す場所を確認します。指定した三つ以外を読む必要があるなら、理由を説明してから進むよう追加で頼めます。

Step 2: 変更条件を確定する

Implement the smallest fix for the expired-session case.
Keep the existing response shape and all Japanese user-facing messages.
Do not change the public API or the handling of other authentication failures.
Add a regression test for an expired session.

ここでは、英語の命令文を増やすより、変更してはいけない範囲を明示することが重要です。日本語の画面文言を残す条件を英語で書いても、引用すべき文言自体は対象ファイルから読み取れます。もし望む表示文言が決まっているなら、Use this exact message: "セッションの有効期限が切れました。もう一度お試しください。" のように日本語を引用します。翻訳させるのではなく、保持する文字列を指定する形です。

Step 3: 検証結果を確認する

Run the focused authentication test first, then the relevant existing tests.
Report changed files, test commands, and any remaining risk.
If a test cannot run, explain why instead of claiming it passed.

この依頼の完了条件は、コードが書き換わったことではありません。期限切れの再現を防ぐテストが通り、既存の認証テストに意図しない差分がなく、変更ファイルがログイン周辺へ限定されていることです。結果を受け取ったら、テスト名と差分を自分でも確認します。英語プロンプトが正しくても、確認を省けば、見た目だけ直って別の認証経路を壊す可能性があります。

日本語プロジェクトで英語を使うときの実務上の注意

日本語のリポジトリで英語を使う場合、プロンプト本文の言語よりも、識別子と説明文を混ぜる位置が問題になります。ファイルパス、関数名、クラス名、テスト名、エラーコードは、実際の表記をそのまま書きます。画面に表示する日本語は引用し、変更前後で保持するのか、修正するのかを分けます。これだけで「英訳された名前を探して対象が見つからない」「ユーザー向け文言まで英語になる」といった事故を減らせます。

プロジェクトの規約をCodexに読ませる場合も、最初の依頼で長々と再掲する必要はありません。リポジトリにあるAGENTS.mdや既存の開発ガイドが対象なら、Read the repository guidance before editing. と先に指定し、どの指示を読んだかを報告させます。OpenAIのCodex解説では、プロジェクト階層の指示ファイルがモデルへの初期指示に加わる仕組みも説明されています。自分のプロジェクトにそのようなファイルがない場合は、今回守る規約だけを短く書き、恒久的なルールと一時的な依頼を混同しないようにします。

コード識別子は翻訳しない

UserRepository を「ユーザーリポジトリ」と書き換えたり、useSession を日本語の別名にしたりすると、検索対象が曖昧になります。文章の中では日本語で説明しても、コードブロック内の名前は実物を使います。英語の依頼文でも、対象パスと識別子はバッククォートで囲み、文字列の大文字小文字を変えません。特にテスト名と設定キーは一文字の違いが別物になるため、自然な英語より正確な表記を優先します。

エラーと画面文言を役割で分ける

エラーコードは英語や数字のまま扱い、利用者への説明は日本語として設計します。Keep error code SESSION_EXPIRED unchanged, but improve the Japanese message shown to the user. のように書くと、内部の判定と表示の担当を分けられます。表示文言を新しくするなら、対象画面、文字列、改行、句読点を具体的に指定します。英語プロンプトにしたからといって、成果物の画面まで英語にする必要はありません。

返答言語と成果物の言語を指定する

返答は日本語、コードコメントは既存方針に合わせる、コミット用の説明は英語、といったように、出力先ごとに条件を指定できます。Explain the result in Japanese. Keep code identifiers unchanged. Follow the repository's existing comment language. は短いですが、利用者が読む報告と、コードに残る文章を分けています。言語の指定を最後に一行置くと、作業内容の条件と混ざらず、返答の確認もしやすくなります。

英語にしても結果が不安定になる書き方

英語を使えば曖昧さが消えるわけではありません。Make it better.、Fix everything.、Improve performance. のような依頼は、日本語に戻しても対象、基準、完了条件がありません。英語の短さと情報不足を取り違えないことが大切です。また、モデル名や版が変わったときに過去の返答をそのまま再現できるとは限りません。Codex CLIの公式リリースでは、9月上旬にもモデル選択画面や質問の扱いに関する修正が記録されています。利用中の版は公式リリース一覧で確認し、重要な修正は差分とテストで判断します。

もう一つの問題は、英語と日本語を一文ごとに頻繁に切り替えることです。OpenAIの言語案内が示すとおり混在入力そのものは扱えますが、条件が複数あるときは、ゴールと制約のブロックを同じ言語でそろえたほうが読み返しやすくなります。固有の画面文言や仕様用語だけ日本語で引用する構成にすると、必要な混在に絞れます。英語の文法を直すことより、情報のまとまりを保つことを優先してください。

目的語がないまま動詞だけを置かない

Refactor the code. では、どのコードをどの理由で変えるのか分かりません。Refactor the parsing logic in src/parser.ts without changing the exported function signature. のように、対象と境界を追加します。「最適化」「整理」「改善」といった言葉を使う場合は、速度、メモリ、読みやすさ、バグ修正のどれを指すのかも書きます。英語の命令形が強くても、目的語がなければ実装の選択肢が広がりすぎます。

手段を固定しすぎて調査を狭めない

最初から特定の関数を一行だけ変えろと指定すると、原因が別の場所にある場合に遠回りになります。まず対象範囲と成功条件を示し、調査の結果を報告させてから、必要な手段を決めます。一方で、既存APIを変えない、依存を追加しない、特定ディレクトリを触らないといった境界は最初に書くべきです。目的を固定し、実装方法には検討の余地を残すという分け方が有効です。

返答の流暢さを完了の証拠にしない

英語の報告が自然でも、実際にテストが走ったとは限りません。変更ファイル、実行コマンド、終了結果、未確認の点を順に読みます。「問題ありません」だけで終わっている場合は、具体的な出力と差分を返すよう追加で頼みます。Codexの公式説明でも、ツールの結果を次の判断に使う流れが重視されています。文章の説得力ではなく、観測できる証拠で完了を判定してください。

最新のCodexで英語プロンプトを見直すタイミング

2026年9月11日時点では、Codex CLI 0.154.0-alpha.11が9月9日に公開され、0.153.4も9月4日に公開されています。前者は公式リリース一覧で確認でき、後者にはモデル選択画面での表示や、利用可能なツールに応じた質問の扱いに関する修正が記録されています。これは英語そのものの仕様変更ではありませんが、モデルの見え方や会話の進み方が変われば、同じ指示でも確認質問の出方や報告の粒度が変わる可能性があります。新しい版を使い始めたときは、以前の例文を信じ切らず、小さな対象で同じ完了条件を再確認します。

見直すべきなのは、まずモデル名と利用クライアント、次にプロジェクトの指示ファイル、最後にテストの前提です。英語プロンプトに「最新版だからこう動く」と書くのではなく、使っている版で確認できる振る舞いを記録します。OpenAIのベストプラクティスは、難しい作業ほど目的、背景、制約、完了条件を明示し、必要な推論の深さを作業に合わせることを勧めています。これらを固定した小さな検証を残しておけば、モデル更新があっても、何が変わったのかを比較できます。

リリース直後は小さな検証を先にする

新しい版を入れた直後に、いきなり大きなリファクタリングを任せるのではなく、既知の小さな修正を一つ選びます。同じ英語プロンプト、同じ対象ファイル、同じテスト条件で依頼し、返答の理解、変更範囲、テスト結果を見比べます。差があっても、すぐに優劣を決めず、版の違い、設定、対象コードの状態を切り分けます。検証用の依頼には本番の機密データを入れず、結果をレビューできる範囲に限定します。

更新後も日本語の合意を中心に置く

モデルやクライアントが更新されても、プロジェクトの仕様まで英語へ移す必要はありません。関係者が合意した要件、画面文言、利用者への説明は日本語で管理し、Codexへ渡す実行指示だけを英語に整える方法が扱いやすいです。英語版の指示は、目的、対象、境界、確認方法が原文と一致しているかを確認します。更新のたびに言語を変えるのではなく、検証できる構造を保つことが長期的な安定につながります。

Codex英語の使い方を定着させる確認項目

ここまでの要点は、英語を選ぶことではなく、依頼を検証できる形にすることです。英語はコードや開発資料の用語をそろえやすく、短い命令文で対象と境界を書きやすい一方、背景の細かな合意や画面文言は日本語のほうが正確なことがあります。両者を競わせず、情報の種類ごとに役割を与えます。日本語で成功状態を決め、英語で調査・変更・確認を指定し、返答と差分を自分で照合する流れが基本です。

実際に使うときは、最初の依頼にゴール、背景、制約、完了条件を入れます。コード識別子とエラーコードは原文のまま、利用者向け文言は維持または変更の条件を明示し、返答言語も指定します。新しい版を使い始めたら小さな修正で結果を確認し、テストできなかった点を成功扱いにしません。公式情報はCodexのベストプラクティス、多言語の扱いはOpenAI Help Center、版の変更はCodexのリリース一覧を参照できます。英語の流暢さより、意味と結果が追跡できるプロンプトを目指しましょう。