🧰 Codex/AI開発術

Codexへテストを依頼する書き方|再現条件・期待結果・証拠を揃える

Codexへテストを頼むときに、対象範囲、再現手順、期待結果、失敗時の報告形式をどう指定するか、コピー可能な依頼例とともに解説します。

Codexへ「テストして」とだけ頼むと、対象や完了条件が決まりません。既存テストを1回実行しただけで終わったり、正常系だけを見て不具合を見逃したりします。

良い依頼は長文である必要はありません。「対象」「変更範囲」「再現手順」「期待結果」「証拠」を観測できる形で揃えることが重要です。OpenAIの公式ガイドも、大きい依頼では目的、文脈、出力形式、変更してはいけない境界を伝える考え方を示しています。

テスト依頼が曖昧になる原因

テストには、既存テストの実行、テスト追加、ブラウザ操作、原因調査があります。「ログインをテストして」だけでは担当範囲が決まりません。

目的は「誤ったパスワードでログインが拒否され、秘密を含まないエラーが出ることを確認」のように、入力と観測したい出力を1文にします。

また、「テストだけ」と「不具合を直して再テストする」も分けます。診断だけなのに修正まで許可すると、調査前の状態が変わることがあります。

OpenAIの公式資料では、Codexはテスト、リンター(コードの静的検査)、型検査を実行でき、端末ログやテスト出力を検証の証拠にできると説明されています。ただし、使える環境はリポジトリごとに異なります。

依頼の種類を先に選ぶ

同じ「テスト」でも、依頼の種類によってCodexがしてよいことは変わります。最初に次のどれかを指定すると、確認だけの依頼でコードまで変わる行き違いを減らせます。

依頼の種類Codexに頼む範囲変更の扱い主な完了証拠
既存テストの実行指定コマンドを実行する原則変更しないコマンド、終了コード、成功・失敗件数
不具合の再現手順どおりに症状を確認する原則変更しない最短の再現手順、実結果、関連ログ
テストの追加期待動作を検査するテストを書く許可したテストファイルだけ追加したテスト名、変更ファイル、実行結果
修正と再テスト失敗を確認し、修正後に同じ検査を行う指定範囲だけ変更する修正前の失敗、修正後の合格、関連テスト

判断がつかない場合は、まず「不具合の再現だけ。修正はしない」と頼み、原因候補と必要な変更範囲を受け取ってから次の依頼を分ける方法があります。

対象と変更範囲を固定する

対象の機能、入口、関係するファイルを示します。不明なら画面名、URL、API、実行コマンドのどれかで指定し、確認範囲と変更範囲を分けます。

対象: お問い合わせフォームの送信処理
入口: /contact
確認範囲: src/pages/contact、送信API、関連テスト
変更してよい範囲: テストファイルだけ
禁止: 本番送信、依存追加、共通CSS変更

メール送信、決済、削除、外部APIなどを含む場合は、実サービスを呼ばず、テスト用環境やモック(外部処理の代用品)を使う条件も書きます。

修正範囲を特定できないときは「範囲外の修正が必要なら、変更せず候補と理由を報告」と指定します。依頼全体の基本形はCodexへの依頼テンプレートも参考にしてください。

同じリポジトリで毎回使うテストコマンドや禁止事項は、依頼文へ繰り返すだけでなくAGENTS.mdへ置く方法もあります。OpenAIの公式ドキュメントでは、Codexが作業前にAGENTS.mdを読み、プロジェクト固有の指示を取り込む仕組みが説明されています。依頼文そのものの組み立て方はCodexへの依頼テンプレートで整理しています。

再現手順を渡す

不具合では、開始状態、操作、入力値、発生頻度、実際の結果を順番どおりに書きます。

開始状態: 開発サーバー起動済み、未ログイン
手順:
1. /loginを開く
2. 登録済みメールアドレスと誤ったパスワードを入力する
3. 「ログイン」を1回押す
実際の結果: 読み込み表示のまま戻らない
発生頻度: 3回中3回

アカウント名、トークン、Cookie、実データは貼らず、ダミー値へ置き換えます。OS、ブラウザ、Node.jsなどの版が関係しそうなら、推測せずコマンドで確認してもらいます。

再現しない場合は「3回まで試し、再現しなければ環境差、ログ、未確認事項を報告」のように上限を置きます。

期待結果を観測可能にする

「正しく動く」ではなく、文言、HTTPステータス、保存件数、遷移先、終了コードなど、実行後に見える結果へ置き換えます。

確認項目曖昧な期待結果観測可能な期待結果
入力エラー適切に拒否される送信されず、入力欄の近くにエラーが表示される
APIエラーになるHTTP 400を返し、応答に秘密情報を含めない
コマンドテストが通る指定コマンドの終了コードが0になる
保存二重登録されない同じ操作を2回しても対象レコードが1件のまま

空欄、形式違い、上限値、連続操作、通信失敗から、不具合に近い境界条件を2〜4件に絞って加えます。

OpenAIの長時間作業向け資料でも、期待動作、レビュー基準、制約、完了条件など、Codexが検証できる基準を与える考え方が示されています。

失敗時の報告形式を決める

失敗も役に立つ結果です。報告には、実行コマンド、終了コード、期待結果、実結果、関連ログ、変更ファイルを含めます。

報告形式:
- 状態: 合格 / 不合格 / 未実行
- 実行したコマンドと終了コード
- 期待結果と実際の結果
- 最短の再現手順と原因候補
- 変更したファイル
- 未実行項目と理由

ログはエラーの前後に絞り、秘密情報や個人情報は伏せた事実を明記します。スクリーンショットだけでなく、文字のログ、テスト名、終了コードも残します。

合格時もコマンド名と結果は必要です。受け取った後は、変更範囲と境界値を自分の目で確認してください。

終了コードは、コマンドが成功したかを機械的に確認するための数値です。ただし、終了コードが0でも期待した画面やデータになっているとは限りません。PowerShellでは直前のコマンドの終了コードが$LASTEXITCODEに入るため、実行直後にその値を表示して確認します。

そのまま使える依頼例

次の角括弧を案件に合わせて置き換えます。

[機能名]の不具合をテストしてください。

目的: [入力・操作]で[観測可能な期待結果]になることを確認する。

対象:
- 入口: [URL、画面名、API、コマンド]
- 関連箇所: [分かる範囲のファイル]
- 変更可: [具体的な範囲]
- 禁止: [本番データ、依存追加、共通設定]

再現手順:
1. [開始状態と操作]
2. [入力]
実際の結果: [現在の症状]

合格条件:
- 失敗を再現するテストを先に確認する
- 修正を許可した範囲では、修正後に同じテストが通る
- 関連する既存テストも通る
- 実行コマンド、終了コード、期待結果、実結果を報告する

停止条件:
秘密情報、外部サービスへの送信、範囲外の変更が必要なら実行せず報告する。
テストを実行できない場合は、未実行の理由と必要な準備を報告する。

修正を含む依頼では、「失敗を確認してから修正し、同じ手順で再検査」と書きます。レビューも必要なら、テスト結果と指摘を混ぜず、重要度を「直す・相談・保留」の3段に分けて書かせてください。

よくある質問

Codexに「テストして」とだけ頼んではいけませんか

簡単な確認なら動くこともありますが、対象、修正の可否、合格条件が一致するとは限りません。少なくとも「対象」「期待結果」「変更してよい範囲」の3点を添えると、結果を判断しやすくなります。

テストコマンドが分からない場合はどう書きますか

「既存設定とAGENTS.md、README、設定ファイルから候補を調べ、実行前に採用理由を示す」と依頼します。依存追加や設定変更が必要なら、実行せず報告する条件も付けます。

不具合の修正まで一度に頼んでもよいですか

範囲が明確なら可能です。「失敗を再現する」「許可した範囲だけ修正する」「同じ手順と関連テストで再検査する」の順序を指定します。原因調査だけが目的なら、修正しないことを明記します。

テストが通れば、そのまま公開してよいですか

テスト合格だけでは十分とは限りません。未実行の検査、変更差分、実環境との違い、秘密情報の混入がないかを人が確認し、公開や本番反映は別の判断として扱います。

再現しない不具合はどう依頼しますか

OS、ブラウザ、実行時刻、入力条件、発生頻度など、差が出そうな情報を渡します。「最大3回まで再現を試し、再現しなければ環境差と追加で必要な情報を報告」と上限を決めると、同じ操作の繰り返しを避けられます。

依頼前の最終確認

最後に、対象、変更範囲、再現手順、観測可能な合否、失敗時の証拠が揃ったか確認します。5点が揃えば、回答を次回も使えるテスト記録にできます。

一次情報の確認メモ

続き(結論と実データ)はnoteに置いています

ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。

noteで続きを読む Xをフォローする