3行まとめ
触る範囲と触らない範囲を決めます。
成功、失敗、境界値を確認します。
未回答なら実装へ進みません。
質問は、実装を遅らせるためではなく手戻りを減らすために使います。
- Codexに実装を頼む前に、対象範囲、期待挙動、制約、テスト、承認条件の5つを質問させると、手戻りを減らしやすくなります。
- 大事なのは、質問を出させることではなく、回答をIssueや作業ログに固定し、未回答なら実装へ進まない停止条件を置くことです。
- 5つの質問は万能ではありません。認証、決済、DB、本番影響、secretに関わる作業では、人間承認と追加レビューへ戻します。
本文の事実確認には、OpenAIのCodex関連資料、Codex AGENTS.md guide、Codex permissions、公開済みの実装前レビュー/リファクタリング記事を使っています。Xで伸びていた「実装前に質問させる」系の投稿は需要シグナルとして扱い、本文の根拠にはしていません。
この記事でわかること
5分類で質問させる型を作れます。
回答を作業前提に固定できます。
推測実装を止められます。
質問と差分を対応づけられます。
回答が残ると、PRレビューで前提を確認できます。
- Codexに実装前質問をさせる理由
- 5つの質問を対象、期待挙動、制約、テスト、承認条件に分ける方法
- 回答をIssue化して作業前提に固定する手順
- 未回答時に実装を止める条件
- PRレビューや
AGENTS.mdへつなげる方法 - 質問が増えすぎる時の整理方法
前提知識
- 1質問
不足情報を5分類で出します。
- 2回答
Issueやログへ固定します。
- 3実装
回答済みの範囲だけ進めます。
- 4レビュー
質問への回答と差分を照合します。
質問だけで終わらせず、完了条件へ変えます。
Codexに「この機能を作って」と頼むだけでも、ある程度の実装は進むことがあります。ただし、前提が曖昧なまま進むと、実装後に「そこは違う」「そのケースは想定していない」「テストが足りない」と戻ることになります。
実装前の質問は、Codexの出力を止めるためではありません。人間とCodexの前提を揃え、実装後にレビューできる形へ変えるための工程です。
質問は作業を遅くするものではない
質問が増えると遅く見えますが、曖昧なまま実装して戻るほうが遅くなります。特に、既存コードを触る作業では、対象範囲、変えてよい挙動、テスト、承認条件を先に揃えます。
確認項目
対象ファイル、対象ユーザー、期待挙動、非対象範囲、既存仕様、テストコマンド、レビュー担当を確認します。
注意点
質問を出させるだけで満足しないことです。回答が作業ログやIssueに残らないと、次のスレッドやPRで前提が消えます。
実装前に5つ質問させる理由
| 項目 | 内容 | 見方 |
|---|---|---|
| 対象範囲 | 画面、API、component、ファイルを確認します。 | |
| 期待挙動 | 成功時、失敗時、境界値を確認します。 | |
| 制約 | 変えてはいけない仕様を確認します。 | |
| テスト/承認 | 確認方法と止まる条件を決めます。 |
広すぎる質問ではなく、実装条件に変わる質問にします。
Codexの質問は、情報不足を埋めるために使います。最初に質問させることで、実装前の不明点を表に出せます。
5問で確認する範囲
| 質問分類 | 確認すること |
|---|---|
| 対象範囲 | どの画面、API、component、ファイルを触るか |
| 期待挙動 | 成功時、失敗時、境界値でどう動くか |
| 制約 | 変えてはいけない仕様、依存追加、UI文言、互換性 |
| テスト | どのテストを走らせ、何を手動確認するか |
| 承認条件 | 人間確認へ戻す条件、触ってはいけない領域 |
依頼例
実装に入る前に、必要な確認事項を5つ質問してください。
質問は、対象範囲、期待挙動、制約、テスト、承認条件に分けてください。
まだファイルは変更しないでください。評価基準
質問が実装判断に直結しているかを見ます。「ほかに希望はありますか」のような広すぎる質問は、作業前提を固める役に立ちにくいです。
質問の答えを完了条件に変える
質問への回答は、実装の完了条件になります。たとえば、対象範囲の回答は触ってよいファイル、期待挙動の回答はテスト観点、承認条件の回答は停止条件になります。
確認項目
回答ごとに、実装条件、テスト条件、レビュー条件へ変換できているかを見ます。
注意点
回答が曖昧な場合は、そのまま実装へ進みません。追加質問を出すか、調査スレッドへ分けます。
質問は5分類に分ける
触る場所を狭めます。
テストに変換します。
壊してはいけないものを固定します。
人間確認へ戻す条件を決めます。
回答しやすい質問ほど、Issueに残しやすくなります。
質問は多ければよいわけではありません。最初は5分類に絞ると、回答しやすく、Issueにも残しやすくなります。
対象範囲
対象範囲では、どこを触ってよいか、どこを触らないかを決めます。
例
今回の変更対象は SearchBox component だけですか。
API handler、URL query、検索結果の並び順、CSS class は変更対象に含めますか。注意点
対象範囲が広すぎる場合は、実装を分けます。1つのPRでUI、API、DB、ログを同時に触るとレビューが難しくなります。
期待挙動
期待挙動では、成功時だけでなく失敗時と境界値を確認します。
例
検索結果が0件の時、空文字の時、通信エラーの時、
既存の表示やエラーメッセージはどうなるべきですか。評価基準
期待挙動がテストに変換できるかを見ます。テストにできない期待は、まだ曖昧な可能性があります。
制約
制約では、変えてはいけないものを確認します。
例
既存のURL、API response、UI文言、CSS class、依存関係、アクセシビリティ属性で、
変えてはいけないものはありますか。注意点
制約がないように見えても、既存ユーザーや他チームが依存している場合があります。公開APIやURLは特に注意します。
テスト
テストでは、自動テストと手動確認を分けます。
例
実装後に必ず実行するコマンドは何ですか。
unit test、E2E、手動確認、スクリーンショット確認のうち、今回必要なものはどれですか。評価基準
テストが実行できない場合に、未検証として報告する条件があるかを見ます。
承認条件
承認条件では、Codexが止まるべき境界を決めます。
例
認証、決済、DB migration、secret、外部API、依存関係追加、本番影響に触れる場合は、
実装を止めて人間確認に戻す、でよいですか。注意点
承認条件は自然言語だけでなく、permission profile、approval、branch protection、review ruleとも合わせます。
回答をIssue化して固定する
| 項目 | 内容 | 見方 |
|---|---|---|
| 目的 | 何を終わらせるかを書きます。 | |
| 対象範囲 | 触る/触らない範囲を残します。 | |
| テスト | 実行コマンドと手動確認を残します。 | |
| 未回答 | 保留と追加確認を残します。 |
Issueだけを見て実装へ入れる状態を目指します。
質問に答えたら、回答をIssueや作業ログへ固定します。会話の中だけに置くと、後からレビューできません。
Issueテンプレート
[目的]
[対象範囲]
[期待挙動]
[制約]
[テスト]
[承認条件]
[未回答/保留]評価基準
このIssueだけを見て、Codexが実装へ入れるかを見ます。Issueを読んでも質問が残るなら、まだ実装前です。
関連
実装前レビューの観点は、Codexに実装前レビューを頼む記事と合わせると、バグや例外ケースを先に拾いやすくなります。
AGENTS.mdへ繰り返しルールを置く
毎回同じ質問をさせたい場合は、AGENTS.mdへ実装前確認のルールを置きます。
例
実装に入る前に、対象範囲、期待挙動、制約、テスト、承認条件を確認する。
未回答のままファイル編集へ進まない。注意点
AGENTS.mdは作業契約です。実行権限そのものではありません。承認条件はpermissionsやreview ruleと合わせます。
未回答なら実装を止める
- 1範囲不明
調査スレッドへ戻します。
- 2仕様不明
期待挙動を確認します。
- 3テスト不明
既存テスト調査を先にします。
- 4高リスク
人間承認へ戻します。
仮説で進める場合も、未検証として残します。
質問への回答が揃わない時は、実装へ進まない判断が必要です。Codexが推測で埋め始めると、手戻りが増えます。
止める条件
| 条件 | 対応 |
|---|---|
| 対象範囲が曖昧 | 調査スレッドへ分ける |
| 期待挙動が決まらない | 仕様確認へ戻す |
| テストが不明 | 既存テスト調査を先に行う |
| 承認条件に該当 | 人間レビューへ戻す |
評価基準
Codexが「推測して実装します」と進めていないかを見ます。推測が必要な場合は、推測ではなく仮説として報告させます。
注意点
未回答を全部ブロッカーにすると進みません。影響が小さいものは仮説として明記し、影響が大きいものは止める、という線引きが必要です。
仮説で進める場合
小さなUI文言や低リスクな内部実装では、仮説で進めることもあります。その場合も、仮説、未検証、戻し方を明記します。
例
「0件時は既存の空状態コンポーネントを使う、という仮説で進める。未確認のため、レビュー時に仕様確認が必要。」
評価基準
仮説がPR descriptionに残り、レビュー担当が確認できるかを見ます。
テストとレビュー条件へつなげる
| 項目 | 内容 | 見方 |
|---|---|---|
| 対象 | 余計なファイルを触っていないか見ます。 | |
| 挙動 | 成功/失敗/境界値を見ます。 | |
| 制約 | APIやUI文言が変わっていないか見ます。 | |
| 承認 | 止まるべき変更が混ざっていないか見ます。 |
質問とレビューがつながらないなら、質問が弱い可能性があります。
5つの質問は、実装後のレビュー条件へ変換します。質問とレビューがつながらないなら、質問が弱い可能性があります。
質問からレビュー項目へ
| 質問 | レビュー項目 |
|---|---|
| 対象範囲 | 余計なファイルを触っていないか |
| 期待挙動 | 成功/失敗/境界値が満たされているか |
| 制約 | API、URL、UI文言、依存が変わっていないか |
| テスト | 指定コマンドと手動確認が実行されたか |
| 承認条件 | 人間確認へ戻すべき変更が混ざっていないか |
評価基準
レビュー担当が、質問への回答を見ながら差分を確認できるかを見ます。
関連
リファクタリングへ進む場合は、Codexにリファクタリングを頼む前の記事の3案比較へつなげると、変更目的が混ざりにくくなります。
最終報告の型
確認した5項目:
実装したこと:
実行したテスト:
未検証:
承認条件に触れたか:
レビューしてほしい点:注意点
未検証が空欄の場合は、本当に未検証がないのか確認します。実行していないテストがあるなら、理由を書きます。
セキュリティ・コスト注意
tokenやenvを質問に含めません。
必要最小限の情報で進めます。
質問が重い時はタスクを分けます。
繰り返す質問は初期ルールにします。
質問の質と情報管理を同時に見ます。
要件確認の質問には、セキュリティやコストに関わるものも含まれます。特に認証、決済、DB、外部API、secretに触れる場合は、質問だけで進めません。
secretや本番情報を質問に含めない
質問で具体的なtoken、顧客情報、本番ログ、契約情報を聞かせないようにします。必要ならダミー値や抽象化した条件を使います。
確認項目
Codexに見せる情報、見せない情報、外部通信の可否、ログ保存、作業スレッドの共有範囲を確認します。
注意点
「正確に実装するために全部共有する」は危険です。必要最小限の情報で進め、機密に触れる場合は人間承認へ戻します。
質問が多すぎるコスト
質問が多すぎると、回答する人間の負担が増えます。最初は5分類に絞り、必要な時だけ追加質問へ進みます。
評価基準
5問への回答に10分以上かかる場合、タスクが大きすぎる可能性があります。対象範囲を分けるか、調査タスクへ戻します。
改善方法
よく出る質問はAGENTS.mdやIssueテンプレートに移します。毎回同じことを聞くより、初期値として固定したほうが速くなります。
失敗点とハマりどころ
実装条件に変わりません。
回答がPRで消えます。
未回答を勝手に埋めます。
タスクが大きすぎるサインです。
回答は、Issueとレビュー条件に残します。
実装前質問の失敗は、質問を出しただけで実装条件が固まった気になることです。
抽象的な質問で終わる
「何か制約はありますか」だけでは不十分です。UI文言、API response、依存追加、アクセシビリティ、テスト、承認条件まで具体化します。
回答がログに残らない
会話で答えても、IssueやPRに残らなければレビュー時に消えます。回答を作業前提として残します。
未回答を推測で埋める
Codexが推測で実装すると、後で手戻りになります。推測する場合は仮説として明記し、レビューで確認します。
実務で使うなら
- 1日目
5分類を決めます。
- 2日目
既存Issueへ当てはめます。
- 3日目
Codexに質問させます。
- 5日目
PRレビューで対応を確認します。
毎回の会話ではなく、標準手順へ入れます。
実務では、5つの質問をIssueテンプレートとAGENTS.mdへ入れます。毎回の会話で思い出すのではなく、作業開始の標準手順にします。
1週間の進め方
1日目に5分類の質問を決めます。2日目に既存Issueへ当てはめます。3日目にCodexへ実装前質問を出させます。4日目に回答をIssue化します。5日目にPRレビューで質問と差分が対応しているか確認します。
スコアカード
| 評価軸 | 合格ライン |
|---|---|
| 対象範囲 | 触る/触らない範囲が明確 |
| 期待挙動 | 成功、失敗、境界値がある |
| 制約 | 変えてはいけないものがある |
| テスト | 実行コマンドと手動確認がある |
| 承認条件 | 止まる条件が明確 |
| ログ | 回答がIssueやPRに残る |
関連導線
5つの質問で出た不安点は、実装前レビューの記事へつなげます。比較評価にしたい場合は、AI Coding Benchmark Kitの記事を使うと、同じ条件で測りやすくなります。
FAQ
低リスクなら簡略化できます。
未確認前提を報告に残します。
調査と実装に分けます。
繰り返すなら書く価値があります。
迷ったら、レビューで確認できるかを基準にします。
毎回5つ質問させる必要がありますか？
小さな作業では簡略化できます。ただし、対象範囲、期待挙動、テスト、承認条件のどれかが曖昧なら質問したほうが安全です。
Codexが質問せずに実装できそうな時は？
低リスクなら進めることもありますが、未確認の前提は最終報告に残します。高リスク領域では止めます。
質問が増えすぎる時は？
タスクが大きすぎる可能性があります。調査、実装、レビューへ分けます。
5つの質問はAGENTS.mdに書くべきですか？
繰り返し使うなら書く価値があります。ただし、AGENTS.mdは作業契約であり、権限強制そのものではありません。
更新履歴
- 2026年5月31日
Codex関連資料、AGENTS.md guide、permissions、関連記事を確認して初版を作成しました。
導入時には最新の公式情報を確認してください。
2026年5月31日 JSTに、OpenAIのCodex関連資料、Codex AGENTS.md guide、Codex permissions、公開済みの関連記事を確認して初版を作成しました。Codex関連機能は更新されやすいため、導入時には最新の公式情報を確認してください。