「Codex に指示しても、思った通りのコードが出てこない」「同じことを何回も言わせられる」――そんな経験ありませんか？
実は、プロンプトの書き方 で Codex の出力品質は劇的に変わります。この記事では、実体験ベースの10個のテクニック を紹介します。
1. **「結論を先に」言う**
❌ 悪い例：
このサイトには記事が80本あって、それぞれに画像が必要で、画像はOGP用で…
⭕ 良い例：
全80記事のOGP画像を一括生成するスクリプトを作って。詳細は以下：
- 入力：
content/blog/*.md- 出力：
public/og/[slug].png- サイズ：1200x630
最初に「何をしてほしいか」を1文で言い切ってから、詳細を箇条書きにします。Codex の集中力（コンテキストの優先順位）が劇的に上がります。
2. **「制約」を明示する**
「いい感じに作って」では Codex が迷います。
⭕ 良い例：
ボタンコンポーネントを作って。
- TypeScript で型をきっちり
- Tailwind のみ使用（CSS Modules 禁止）
disabled状態のスタイルも入れる- クリックハンドラは prop で受け取る
制約を 3〜5個 明示すると、出来上がりが期待に近づきます。
3. **「サンプル」を見せる**
❌ 「人気記事カードを作って」
⭕ 「人気記事カードを作って。デザインは components/PostCard.tsx の variant='horizontal' を参考に」
既存のコードを参照 させると、プロジェクトのスタイルに揃ったコードが返ってきます。
4. **「やってほしくないこと」を書く**
人間と同じで、ポジティブな指示より 否定的な指示のほうが効きやすい ことがあります。
⭕ 例：
ローディング状態を追加して。
- ❌
useEffectで setLoading は使わない- ❌ ライブラリ追加禁止
- ⭕ React の Suspense を使う
「これは禁止」と書くと事故が減ります。
5. **段階に分けて頼む**
❌ 「ユーザー登録機能を全部作って」
⭕ ステップ分割：
- Step 1：登録フォームのUIだけ作って
- （確認して問題なければ）Step 2：バリデーションを追加
- Step 3：DB保存を実装
- Step 4：テストを書く
各ステップで動作確認できるので、ミスが小さいうちに直せます。
6. **「出力フォーマット」を指定する**
⭕ 例：
既存のテストを分析して、不足しているテストケースをリストアップして。 形式：
- ファイル名
- 不足しているケース（箇条書き）
- 優先度（高/中/低）
Codex は 指定したフォーマットで出力 してくれます。後の処理（PR作成、Issue化）に直結する形式で出してもらいましょう。
7. **「役割」を与える**
⭕ 例：
あなたはセキュリティに厳しいシニアエンジニアです。 この
auth.tsを読んで、潜在的な脆弱性を3つ以上指摘してください。
「役割設定」を加えると、Codex の出力スタイルや視点が変わります。コードレビュー、ドキュメント執筆、設計相談 などで効きます。
8. **「思考過程」を可視化させる**
複雑なタスクで結果だけ求めると外しやすい。
⭕ 例：
このバグの原因を以下の手順で調べて：
- まず関連するファイルを列挙
- データの流れを追う
- どこで値がおかしくなるか特定
- 修正案を提示
ステップを明示すると、Codex が 論理的に追跡 してくれます。
9. **「テストで確認させる」**
コードだけ書かせて終わるより、動作確認まで指示 したほうが品質が上がります。
⭕ 例：
ユーザー登録機能を実装して。 実装後、必ず以下を確認して：
npm testが緑になるnpm run typecheckが通るnpm run buildが成功する
Codex が 自己検証 してくれるので、後でビルドが落ちる事故が減ります。
10. **「AGENTS.md を更新」させる**
学んだことは Codex 自身に書かせます。
⭕ 例：
今のセッションで「ログ出力は
console.log禁止、logger.infoを使う」というルールが明らかになりました。 このルールを AGENTS.md に追記して。
セッションを跨いだ 記憶の継承 ができます。詳しくは AGENTS.md ガイド。
番外編：避けるべきパターン
❌ あいまい語の多用
「いい感じに」「適切に」「うまく」は禁句。Codex の解釈が広がりすぎて空振りします。
❌ 長すぎる前置き
最初に5段落の説明を書くより、結論 + 3〜5個の箇条書き で十分。
❌ 質問形ばかり
「どう思いますか？」を連発すると、Codex が分析モードになり手が止まります。「やって」「作って」 という命令形のほうが動きます。
❌ 1ターンで全部頼む
大きいタスクは段階に分けるのが鉄則。1ターン1テーマ が品質維持のコツ。
実践：Before / After 比較
Before（悪いプロンプト）
このサイトの認証まわりを良くしたいんだけど、なんかうまく動かないのを直して、できれば全体的にコードもキレイにしたいです
After（良いプロンプト）
認証バグの修正をお願いします。
症状：ログイン後、約30秒で勝手にログアウトされる 想定する原因：JWTの有効期限が短い、or リフレッシュトークン未実装
対応：
lib/auth/jwt.tsを読んで、現状の有効期限を確認- 有効期限を24時間に延長
- リフレッシュトークンが未実装なら、シンプルな形で追加
npm testで既存テストが通ることを確認
After のように 症状・原因仮説・対応ステップ・検証方法 をセットで書くと、Codex は迷わず動けます。
チートシート（コピペ用）
タスク開始時に貼り付けると便利なテンプレ：
# タスク
[何をするか1行で]
# 背景
[なぜ必要か簡潔に]
# 制約
- [制約1]
- [制約2]
- [禁止事項]
# 期待する成果物
- [ファイル名・場所]
- [動作確認の方法]
これを Slack のスニペットやエディタのスニペット機能に登録しておくと、毎回安定した依頼ができます。
よくある質問（FAQ）
Q. 日本語と英語、どっちのプロンプトが良いですか？
A. 日本語で問題ない。Codex は日本語のニュアンスも理解します。ただし、変数名・関数名は英語のほうが扱いやすい。
Q. 絵文字を使うと精度が下がる？
A. 下がりません。むしろ「✅」「❌」「⚠️」のような 構造化された絵文字 はLLMの理解を助けることもあります。
Q. プロンプトに「お願いします」「ありがとう」は必要？
A. 不要。短く明確に書くのが鉄則。礼儀よりも構造のほうが大事です。
Q. 同じプロンプトでも結果が違う？
A. はい。LLM には 温度（temperature） によるランダム性があります。意外性が欲しければそのまま、安定が欲しければ 「決定論的に」 と一文加える。
Q. プロンプトを保存しておきたい
A. AGENTS.md か、エディタのスニペット機能・テキストエディタの一覧 .md ファイルなどで管理を。
まとめ
プロンプトの書き方を変えるだけで、Codex の出力品質は何倍にも上がります。「結論先出し・制約明示・否定指示・段階分け」 の4つを意識するだけで、ほとんどの問題は解決します。
次に読むなら、プロジェクト全体に効く AGENTS.md ガイド で、毎回書かなくて済む常駐プロンプトを設計しましょう。