codex 日本語で使える？日本語プロンプトの書き方と注意点

この記事でわかること
良い指示文を作る前提
日本語プロンプトの型
日本語利用で起きやすい失敗
良い指示は「何に使うか」から決める
悪い結果が出たときは原因を分ける
日本語指示テンプレート
まとめ
参照元（公式・公式に準じる情報のみ）

この記事でわかること

Codexに日本語で指示するときの基本形
悪い指示を具体的な作業指示へ直す方法
日本語と英語を混ぜるべき場面
悪い指示をどう直すかの考え方
日本語・英語・用途別に調整すべきポイント

良い指示文を作る前提

Codexは日本語でも使えます。コードそのものは英語ベースの命名やライブラリが多いですが、指示文は日本語で書いても問題ありません。たとえば「この関数の役割を説明して」「このエラーの原因を調べて」「既存のデザインを崩さずにスマホ表示を修正して」「READMEを日本語で分かりやすく書き直して」といった依頼ができます。

日本語でCodexを使うメリットは、仕様や意図を自然に書けることです。特に日本語サイト、社内システム、WordPress案件、観光メディア、ECサイトなどでは、仕様説明や文言ルールが日本語で管理されていることが多いです。英語に無理に変換するより、日本語で正確に条件を書いた方が、意図が伝わりやすい場合があります。

一方で、コードの世界では英語のキーワードやファイル名、関数名、エラー文が多く使われます。そのため、プロンプトは日本語だけでなく、対象ファイル名、関数名、エラーメッセージ、実行コマンドなどを正確に含めるのが有効です。「エラーを直して」ではなく、「npm run buildで出るTypeScriptエラーを直してください。対象はsrc/components/Header.tsxです。UIの見た目は変えないでください」のように書きます。

日本語プロンプトの型

日本語でCodexを使うなら、毎回同じ型を使うと安定します。たとえば「目的：〇〇。対象：〇〇。制約：〇〇。完了条件：〇〇。作業後：変更点と確認方法を日本語で説明してください」という形です。この型にすると、感覚的な依頼ではなく、作業指示として伝わりやすくなります。

悪い例は「このページをいい感じに直して」です。これでは、見た目を変えるのか、コードを整理するのか、SEO文言を変えるのか、バグを直すのか分かりません。良い例は「目的：スマホで見出しが2行になって崩れる問題を直す。対象：トップページのHeroコンポーネント。制約：文言と画像は変更しない。CSSのみ変更。完了条件：幅375pxでボタンが折り返さない」です。

日本語で仕様を伝える場合でも、コード上の名前は原文のまま書くべきです。Header.tsx、useAuth()、npm run build、TypeErrorなどを日本語に訳すと、かえって誤解が増えます。日本語で意図を説明し、技術用語やファイル名は原文を維持する。この混在が、実務では最も扱いやすい書き方です。

日本語利用で起きやすい失敗

日本語プロンプトで起きやすい失敗は、日常語の曖昧さです。「自然に」「違和感なく」「今風に」「シンプルに」という言葉は、人間同士でも解釈が分かれます。Codexに依頼する場合は、見た目、挙動、コード構造、文言のどれを変えるのかを分けて書くべきです。特に「シンプルに」は、コード量を減らす意味なのか、デザインを簡素にする意味なのか、記事文を読みやすくする意味なのかを明確にしましょう。

日本語プロンプトの最後にテンプレートを置くと実用性が上がります。「目的」「対象」「制約」「完了条件」「作業後の報告」を空欄形式にしておけば、読者がそのまま自分の案件に置き換えて使えます。

日本語プロンプトで重要なのは、曖昧な表現を避けることです。「いい感じに」「自然に」「おしゃれに」「最適化して」だけでは、Codexが判断する余地が大きくなります。代わりに、「既存の命名規則に合わせる」「新しいライブラリは追加しない」「HTML構造は大きく変えない」「CSSだけで修正する」「変更範囲をこのファイル内に限定する」「テストが通ることを確認する」のように条件を具体化します。

日本語でよく使えるプロンプト例をいくつか挙げます。調査なら「このプロジェクトの構成を初心者向けに説明してください。主要なディレクトリと役割を一覧にしてください」。修正なら「このエラーの原因を調べ、最小限の変更で修正してください。修正前に方針を説明してください」。レビューなら「この差分をレビューし、バグの可能性、不要な変更、テスト不足を指摘してください」。ドキュメントなら「このREADMEを日本語で、初めて使う人にも分かるように整理してください」。

日本語サイトを扱う場合は、文言のトーンも指定できます。たとえば「敬体で統一」「観光サイト向けにやわらかく」「医療・法律のように断定しすぎない」「広告っぽくしすぎない」「SEO見出しは自然な日本語にする」などです。Codexはコードだけでなく、README、コメント、文言ファイル、ヘルプテキストの整備にも使えるため、日本語の編集指示は有効です。

ただし、日本語で指示しても、Codexが仕様を完全に理解するとは限りません。特に、業界特有の言い回し、社内ルール、法令表記、旅行業や医療・金融などの規制が関わる文章では、AIの修正をそのまま採用しない方がよいです。コードとして動くかどうかと、文言として正しいかどうかは別問題です。日本語文言の変更は、担当者が必ず確認すべきです。

英語で使うべき場面もあります。エラーメッセージ、ライブラリ名、公式ドキュメントの用語、API仕様、GitHub Issueのやり取りなどは英語のまま扱う方が正確です。日本語で全体の意図を説明し、英語のエラー文や関数名はそのまま貼る、という混在型が実務では使いやすいです。

Codexを日本語で使う場合の実践的なコツは、「目的」「対象」「制約」「確認方法」を毎回入れることです。たとえば、「目的：スマホ表示の崩れを直す。対象：Headerコンポーネント。制約：HTMLは変えずCSS中心で修正。確認方法：幅375pxでメニューが折り返さないこと」のように書きます。この形式にすると、日本語でもかなり伝わりやすくなります。

良い指示は「何に使うか」から決める

codex 日本語で使える？日本語プロンプトの書き方と注意点では、リポジトリやタスクを細かく書くことも大切ですが、最初に用途を決める方が結果が安定します。たとえば「かっこいいコード」ではなく、「SNSの冒頭で目を止めるための変更案」「旅行広告の第一印象を作る変更案」のように使い道を入れると、AI側の解釈が狭まります。用途、対象者、雰囲気、避けたい要素を分けて書くと、修正もしやすくなります。

悪い結果が出たときは原因を分ける

狙いと違う結果が出たとき、すぐに長い指示を足すと、かえって意図が散らかります。まずは、変更範囲が違うのか、設計方針が違うのか、コードの品質が足りないのか、型やテストが崩れているのかを分けて見ます。そのうえで「対象ファイルだけ変える」「処理の責務だけ分ける」「既存の公開APIは維持する」など、1回の修正で動かす条件を少なくすると、改善の理由を把握しやすくなります。

日本語指示テンプレート

場面	指示例
調査	まず変更せず、この不具合の原因候補をファイル名つきで説明してください。
修正	影響範囲を小さくして修正してください。変更後に確認すべきテストも教えてください。
レビュー	この差分でバグ、セキュリティ、仕様漏れの可能性がある箇所を優先順に指摘してください。