Codex実践ワークフロー集｜調査・修正・レビューの依頼文例
Codex に慣れてくると、「結局、実務ではどう頼めばいいのか」が気になってきます。調査、バグ修正、テスト追加、レビュー、リファクタ、ドキュメント更新など、作業の種類によって、渡すべき情報と確認方法は少しずつ違います。
本記事では、Codex を実務で使うときのワークフローを、すぐ使える依頼文例つきで整理します。各パターンに「向いている場面」「依頼文例」「確認ポイント」を付けるので、自分の作業に近いものを選んで使ってください。
夕宮たいだふぁ……みんな〜、今日は実務での頼み方をまとめるよぉ。困ったときに見返せる、ワークフロー集にしていこ〜。
1. ワークフロー化する理由
ひとことで：毎回ゼロから頼み方を考えず、作業ごとの型に当てはめます。
Codex は、1回ごとに自由な文章で依頼できます。しかし実務では、同じ種類の作業が何度も出てきます。バグ調査、テスト追加、PRレビュー、README更新などは、毎回似た情報を渡し、似た確認をします。
そこで、作業をワークフローとして型にしておくと便利です。
| 作業 | 渡す情報 | 確認するもの |
|---|---|---|
| コード調査 | 関連ファイル、知りたい観点 | 説明の根拠、関係ファイル一覧 |
| バグ修正 | 再現手順、期待結果、制約 | 再現しないこと、テスト結果 |
| テスト追加 | 対象関数、既存テスト例 | テストが通ること、範囲が妥当か |
| レビュー | 差分、観点、優先度 | バグリスク、未テスト箇所 |
| ドキュメント更新 | 現在の仕様、読者、文体 | 事実と一致しているか |
OpenAI公式の Codex Workflows でも、各ワークフローは「いつ使うか」「どのCodexの入口に向くか」「プロンプト例」「文脈メモ」「検証方法」の形で整理されています。本記事でも、この考え方を初心者向けに噛み砕いて使います。
夕宮たいだ毎回「どう頼もうかなぁ」って悩むの、地味に疲れるんだぁ。型を持っておくと、すぐ作業に入れるよぉ。
2. 共通の依頼テンプレート
ひとことで：どのワークフローでも、Goal / Context / Constraints / Done when を基本にします。
CX-04で扱ったように、Codexへの依頼は次の4要素で組み立てると安定します。
- Goal：何を達成したいか
- Context：関連ファイル、エラー、仕様、参考例
- Constraints：守るルール、変えてはいけないもの
- Done when：何が確認できれば完了か
共通テンプレートは次のとおりです。
Goal:
（何をしたいか）
Context:
（関連ファイル、エラー、再現手順、参考例）
Constraints:
（変更範囲、禁止事項、安全条件）
Done when:
（確認条件、テスト、報告してほしい内容）この型をそのまま使う必要はありません。ただし、実務では「目的」「文脈」「制約」「完了条件」の4つをどこかに入れておくと、Codexの作業が読みやすくなります。
3. ワークフロー1：コードベースを調査する
ひとことで：初めて触るコードは、まず説明と関係ファイル一覧を出してもらいます。
コードベース調査は、Codexの強みが出やすい使い方です。新しいリポジトリに入ったとき、古い機能を引き継いだとき、データの流れを理解したいときに向いています。
依頼文例です。
Goal:
この機能の処理の流れを理解したいです。
Context:
まず `src/features/payment/` 配下を見てください。
入口になりそうなルート、主要コンポーネント、API呼び出しを確認してください。
Constraints:
ファイルは変更しないでください。
推測で断定せず、根拠になったファイル名を示してください。
Done when:
1. 処理の流れを番号付きリストで説明
2. 関係する主要ファイル一覧
3. 変更時に注意すべき点を3つ
をまとめてください。確認ポイントは、説明に出てきたファイルが実際に存在するか、説明とコードが一致しているかです。分からないところがあれば、続けて「この部分を図解してください」「関数ごとの責務に分けてください」と頼みます。
夕宮たいだ調査だけなら変更リスクが低いから、最初の実務利用にも向いてるんだぁ。まずは「読んで説明して」から始めよ〜。
4. ワークフロー2：バグを修正する
ひとことで：バグ修正は、再現手順と検証方法をセットで渡します。
バグ修正では、「何が起きているか」だけでなく、「どう再現するか」と「直ったと判断する条件」が重要です。公式Workflowsでも、再現手順と制約、修正後の確認を含める流れが示されています。
依頼文例です。
Goal:
設定画面で保存した内容がリロード後に戻る不具合を修正してください。
Context:
再現手順:
1. `npm run dev` で起動する
2. `/settings` を開く
3. 「通知を有効にする」をONにする
4. 保存ボタンを押す
5. ページをリロードするとOFFに戻る
関連しそうなファイル:
`src/pages/Settings.tsx`
`src/api/settings.ts`
Constraints:
APIのリクエスト形式は変更しないでください。
修正は最小限にしてください。
可能であれば回帰テストを追加してください。
Done when:
再現手順で不具合が起きないことを確認してください。
実行したコマンドと結果を報告してください。確認ポイントは、Codexが再現手順を理解しているか、修正範囲が広がりすぎていないか、テストや確認コマンドが実行されているかです。バグ修正では、いきなり実装させず、まず原因候補と方針を出してもらうのも有効です。
5. ワークフロー3：テストを追加する
ひとことで：テスト追加は、対象と既存テストの書き方を明示します。
テスト追加は、Codexに任せやすい作業の一つです。ただし、テストの書き方はプロジェクトごとに違います。既存テストの例をContextに入れると、形式が揃いやすくなります。
依頼文例です。
Goal:
`formatPrice` 関数に対するユニットテストを追加してください。
Context:
対象ファイルは `src/utils/formatPrice.ts` です。
既存テストの書き方は `src/utils/date.test.ts` を参考にしてください。
Constraints:
実装コードは変更しないでください。
既存のテストライブラリと命名規則に合わせてください。
Done when:
正常系、0円、負の値、不正な入力の代表例をカバーしてください。
追加したテストを実行し、コマンドと結果を報告してください。確認ポイントは、テストケースが多すぎないか、既存の書き方に合っているか、実装コードを勝手に変えていないかです。テストが失敗した場合は、原因がテスト側か実装側かを分けて説明してもらいます。
夕宮たいだほえ〜、既存テストを見せるだけで、書き方が揃いやすくなるんだぁ。真似してほしい例を渡すの、大事だねぇ。
6. ワークフロー4：コードレビューを依頼する
ひとことで：レビューでは、実装させるのではなく、リスクと確認漏れを探してもらいます。
Codexは、コードを書く相手としてだけでなく、レビュー相手としても使えます。Pull Request前のセルフレビュー、差分のリスク確認、テスト漏れの洗い出しに向いています。
依頼文例です。
Goal:
この差分をレビューし、バグリスクと確認漏れを指摘してください。
Context:
今回の変更目的は、プロフィール編集画面に表示名のバリデーションを追加することです。
差分全体を見てください。
Constraints:
コードは変更しないでください。
指摘は重要度順に並べてください。
好みのリファクタ提案より、バグ・仕様漏れ・テスト不足を優先してください。
Done when:
1. 重大な懸念
2. 中程度の懸念
3. テスト不足
4. 問題なさそうな点
を分けて報告してください。確認ポイントは、指摘が具体的なファイルや行に紐づいているか、好みの問題とバグリスクが分かれているかです。レビュー結果をそのまま採用せず、必要な指摘だけ人間が選びます。
7. ワークフロー5：小さくリファクタする
ひとことで：リファクタは、振る舞いを変えないことと検証方法を明確にします。
リファクタは、Codexに頼むと便利ですが、範囲が広がりやすい作業です。最初は、1ファイル、1関数、1コンポーネントに絞ります。
依頼文例です。
Goal:
`UserList.tsx` の表示ロジックを読みやすく整理してください。
Context:
対象は `src/components/UserList.tsx` だけです。
既存の見た目と挙動は変えないでください。
Constraints:
外部API、propsの型、表示内容は変更しないでください。
新しい依存パッケージは追加しないでください。
変更範囲が大きくなりそうなら、実装前に方針を提示してください。
Done when:
既存テストが通り、変更前後で表示と挙動が変わらないことを説明してください。
変更した理由を箇条書きでまとめてください。確認ポイントは、振る舞いが変わっていないか、不要な抽象化が増えていないか、変更前より本当に読みやすいかです。リファクタは「差分が増えたのに価値が薄い」こともあるため、採用判断を慎重にします。
夕宮たいだリファクタは気持ちいいけど、広げすぎ注意だよぉ。「振る舞いを変えない」って最初に書いておこうねぇ。
8. ワークフロー6：ドキュメントを更新する
ひとことで：ドキュメント更新では、読者と事実確認の範囲を指定します。
README、セットアップ手順、仕様メモ、PR説明文などは、Codexに頼みやすい作業です。ただし、事実と違う説明が混ざると困るため、必ず根拠になるファイルを確認してもらいます。
依頼文例です。
Goal:
READMEのセットアップ手順を、現在のプロジェクト構成に合わせて更新してください。
Context:
確認してほしいファイル:
`package.json`
`README.md`
`.env.example`
読者:
初めてこのリポジトリを触る開発者
Constraints:
推測で手順を追加しないでください。
実行していないコマンドを「確認済み」と書かないでください。
変更はセットアップ手順の章だけに限定してください。
Done when:
変更した箇所、確認したファイル、未確認の前提を報告してください。確認ポイントは、ドキュメントが実際のコードや設定と合っているかです。特にセットアップ手順では、コマンドが古い、環境変数が足りない、動作確認していないのに断定している、というミスに注意します。
9. ワークフロー7：PR説明文を作る
ひとことで：PR説明文は、変更目的・確認内容・レビュー観点を整理してもらいます。
Pull Requestを出す前に、Codexに説明文を作ってもらうと、レビューがスムーズになります。ただし、PR説明文は「美文」よりも、レビューしやすさが重要です。
依頼文例です。
Goal:
現在の差分をもとに、Pull Request説明文の下書きを作ってください。
Context:
変更目的は、ユーザー設定画面の保存バグ修正です。
差分全体を見てください。
Constraints:
実装していない内容は書かないでください。
不確かなことは「未確認」として分けてください。
Done when:
次の形式で出力してください。
## 変更内容
## 確認したこと
## レビューしてほしい観点
## 残タスク確認ポイントは、PR説明文が差分と一致しているかです。Codexが推測で「テスト済み」と書いていないか、レビュー観点が具体的かを確認します。
10. ワークフロー8：エラー切り分けをする
ひとことで：エラー調査では、ログ全文よりも再現条件と期待結果を整理して渡します。
ビルドエラー、テスト失敗、実行時エラーなどは、Codexに調査を頼みやすい場面です。ただし、エラーログだけを貼るより、何をしたときに起きたかを添えると安定します。
依頼文例です。
Goal:
次のテスト失敗の原因を切り分けてください。
Context:
実行コマンド:
`npm test -- UserList`
期待結果:
全テストが通ること
実際の結果:
`UserList renders empty state` が失敗しています。
エラー:
（ここに秘密情報を除いたエラー文を貼る）
Constraints:
まず原因候補を2〜3個に絞ってください。
いきなり修正せず、確認すべきファイルと調査順を提示してください。
Done when:
原因候補、確認したファイル、次に実行すべきコマンドをまとめてください。確認ポイントは、Codexがエラー文だけに飛びつかず、テスト対象、期待結果、最近の変更を見ているかです。ログに秘密情報が含まれる場合は、必ず伏せてから渡します。
11. ワークフローを安全に回すコツ
ひとことで：小さく頼み、差分を読み、検証してから採用します。
どのワークフローでも、最後に見るべきポイントは共通です。
- 変更ファイルが依頼範囲に収まっているか
- 実行したコマンドと結果が報告されているか
- テストや確認が本当に必要十分か
- 秘密情報や本番環境に触れていないか
- 自分が差分を説明できるか
Codexの結果は、採用、修正依頼、却下の3択で判断します。方向性が良くても差分が大きすぎる場合は、「対象ファイルを絞ってやり直してください」と戻します。意図しない変更が含まれる場合は、採用せずに差分を戻します。
夕宮たいだ差分を読めないまま採用するのは、ほんとダメだよ。Codexは作業相手だけど、最後の判断は人間がやるんだぁ。
12. 次に読む記事
ひとことで：第2期では、プロジェクト指示や外部連携へ進みます。
本記事では、Codexを実務で使うためのワークフローを、調査、バグ修正、テスト追加、レビュー、リファクタ、ドキュメント更新、PR説明文、エラー切り分けの8パターンで整理しました。
ここまでで、第1期の「導入から日常利用」までの土台は揃いました。次に読む記事は、CX-07「Codex AGENTS.md完全ガイド｜プロジェクト指示を書く方法」です。毎回同じ指示をプロンプトに書かなくてもよいように、プロジェクトごとのルールを AGENTS.md にまとめる方法へ進みます。
公式情報としては、Codex Workflows、Codex Best practices、Codex Prompting を確認しておくと、本記事のテンプレートをより実務に合わせて調整できます。
夕宮たいだふぁ……これで日常作業の型はかなり揃ったねぇ。次は、毎回の指示を減らすために、AGENTS.mdを育てていこ〜。
この記事とあわせて読みたいCodex記事
ひとことで：この記事の理解を深めるための関連回です。
- CX-03 Codexの使い方｜最初に試すプロンプトと安全な進め方
- CX-04 Codexプロンプト設計｜Goal・Context・Done whenの書き方
- CX-05 Codexの権限と安全設定｜承認・サンドボックス・Git管理
- CX-10 Codex Subagents入門｜複数エージェントで並列作業する方法
Codexシリーズ記事一覧
ひとことで：Codex編は、導入から専門機能まで順番に読めるシリーズです。
- CX-01 Codex入門｜できること・始め方・Claude Codeとの違い
- CX-02 Codex導入ガイド｜App・IDE・CLIの選び方と初期設定
- CX-03 Codexの使い方｜最初に試すプロンプトと安全な進め方
- CX-04 Codexプロンプト設計｜Goal・Context・Done whenの書き方
- CX-05 Codexの権限と安全設定｜承認・サンドボックス・Git管理
- CX-06 Codex実践ワークフロー集｜調査・修正・レビューの依頼文例（本記事）
- CX-07 Codex AGENTS.md完全ガイド｜プロジェクト指示を書く方法
- CX-08 Codex MCP入門｜外部ツール連携の仕組みと安全な使い方
- CX-09 Codex Skills完全ガイド｜作業手順を再利用する方法
- CX-10 Codex Subagents入門｜複数エージェントで並列作業する方法
- CX-11 Codex Cloud・Automations入門｜作業を任せる運用設計
- CX-12 Codexベストプラクティス完全ガイド｜失敗しない使いこなし方
