Codexにエラー再現を任せる：最小再現例と環境情報の整理

Codexに「エラーを直して」とだけ依頼すると、異なる失敗を同じ問題として扱う場合があります。プログラムが起動しないのか、特定入力で計算を誤るのか、画面上の表示だけが異なるのかを先に整理する必要があります。良い再現資料は、説明の長さではなく、別の実行でも同じ失敗を確認できる条件を含みます。

本記事はバグを再現してから修正・検証する依頼方法を案内します。特定のモデルや料金プランを前提にせず、以下のコードとログ形式は説明用に作った事例です。実際のプロジェクトを実行した結果や本ブログの読者のエラー記録ではありません。Codexが変更を提案した状態と、エラーが実際に解決した状態を区別します。

1. エラー報告を四つの欄に分ける

まず入力、実行手順、期待結果、観察結果を書きます。入力はファイルや関数引数など問題を起こす資料で、手順はその資料を処理した順序です。期待結果は意図した規則で、観察結果は実際の画面や出力です。期待結果を書かないと、例外をなくした変更が正しい動作か判断しにくくなります。

欄	説明用の記入例	避ける表現
入力	数量欄に空白一文字	変な値を入れた
手順	例の関数を該当文字列で呼び出す	ただ実行した
期待	空の数量として処理	正常であるべきだ
観察	該当実行で生じた例外と位置	たぶん変換エラーだ

ここで観察欄は自分の実際の実行結果で埋める必要があります。未確認のエラーメッセージをインターネットからコピーすると、別の失敗を再現する場合があります。ログがなければ観察を未確認のまま残し、まず短い再現を依頼してください。原因候補は別欄に書き、確定した観察のように伝えません。

2. 実行環境は結果を変え得る項目から

作業フォルダー、OS、言語ランタイム、依存関係のロックファイル、実行コマンド、現在のコードバージョンを用意します。ウェブ画面の問題なら、ブラウザーや画面サイズなどの関連条件を加えられます。すべての端末情報を長く列挙するより、失敗を再現するのに必要な条件を選んでください。バージョンはインストール案内の数値より、現在の環境で確認した値を使います。

「自分のPCでは動く」という状況では、成功した環境と失敗した環境を同じ欄で比較します。コードバージョン、実行フォルダー、入力ファイルが同じかから確認すると差を絞れます。別環境のコマンドをそのままコピーせず、該当プロジェクトの案内する実行手順を基準にします。

再現にアカウント情報が必要なら、実際のパスワードやトークンを原稿のように貼り付けるより、失敗条件を維持する例示資料を作れるか調べます。例えば顧客識別子は架空の値に変えつつ、文字列の長さや空白といったエラー条件は保ちます。この置換が結果に影響し得るなら、その事実も再現説明に残します。

3. 最小例はファイル数より失敗条件を保つ必要がある

以下は数量文字列を扱う説明用のPython関数です。空文字列は空の値として扱いますが、空白だけの文字列は別の経路に入ります。これを実際の製品の不具合とは仮定しません。どの入力を同じ種類として扱うべきか規則を整理する例です。

def parse_quantity(text):
    if text == "":
        return None
    return int(text)

要件を「空文字列と空白だけの文字列はいずれもNone、数値文字列は整数、文字入力はエラー」と決めれば、再現と検証の範囲が明確になります。これで、空白入力だけを直したという主張と、数値入力の従来の動作も維持したという主張を分けて確認できます。空欄の規則が実際の製品と違うなら、まず規則から修正する必要があります。

大きなプロジェクトから例を縮小する際は、無関係な画面やデータから除き、その都度同じ失敗が残るか確認します。縮小後にエラーが消えたら、除いた条件に関連要素がある可能性があります。最も短いコードより、失敗と期待動作を併せて維持する小さな資料を目指します。縮小過程も記録すると、元のプロジェクトへ戻る根拠になります。

4. 修正前に再現結果から求めるプロンプト

最初の依頼には作業順序と完了基準を併せて入れます。以下は上の関数事例のために自作した依頼形式です。ファイルパスとコマンドは実際のプロジェクトの値で埋める必要があり、例文を提出しただけではCodexが該当環境へアクセスしたりコマンドを実行したりしたことにはなりません。

まず関連コードを読み、提供した入力と手順でエラーを再現してください。修正前の期待結果と観察結果を分けて記録し、実際の実行コマンド、終了状態、主要な出力も残してください。再現できなければ、コード変更前に不足する環境条件を説明してください。再現できたら、その失敗を確認する小さな検査と最小限の修正案を作り、同じ入力で再確認してください。

この依頼は、すべてのバグで無条件に新しいテストファイルを作る規則ではありません。計算や入力処理の回帰を繰り返し確認する必要があれば、自動検査が役立ちます。一時的な環境設定の問題なら、該当条件の観察と復旧確認の方が適切な場合があります。問題が起きた経路を確認する証拠を選び、検査ファイル数を成果として数えません。

OpenAIのコード近代化の例は、同じ入力で出力と動作を比較し、差があれば小さな修正で再検証する流れを示しています。プロンプト案内も変更後の実際の検査を強調します。本記事の依頼様式は、その原則を小さなバグに適用した記入例であり、公式製品のメニューや指定された必須プロンプトではありません。

5. 失敗入力と正常入力を併せて検証する

数量の事例では、空文字列、空白、数字、数字以外の文字を分けて確認できます。空白を処理するためにすべての変換例外をNoneに変えると、文字入力まで黙って空になる場合があります。実際の要件が文字入力エラーなら、この修正は例外が減っても規則を変更したことになります。

説明用の入力	定めた期待結果	確認の目的
空文字列	None	従来の空欄規則を保存
空白だけの文字列	None	失敗条件の処理
文字列12	整数12	正常な変換を維持
文字列abc	変換エラー	不正な入力を隠さない

各検査には修正前後の結果を別々に記します。修正前は空白入力だけ、修正後は数字だけを確認すると、同じ失敗を直したか照合できません。両実行のコードと入力も同じ基準にそろえてください。結果が変わった理由を確認せず失敗検査を削除すると、回帰確認の資料が失われる場合があります。

6. 再現できなかった場合の停止点を決める

再現できなければ、成功を宣言する代わりに差を確認します。実行フォルダー、入力ファイルの文字コード、依存関係、現在の設定、コードバージョンのうち、結果を変え得る候補を一つずつ照合します。元の失敗が断続的なら実行回数と成功・失敗条件を記録できますが、任意の成功一回だけで問題なしとは結論付けません。

Codexがコマンドを実行できなかったなら、実行制限とコード分析結果を分けて読みます。コードから原因候補を見つけるのは有用ですが、再現の証拠の代わりにはなりません。最終回答で「静的分析で見つけた候補」「実際に再現」「修正後に確認」「確認できなかった条件」を分けるよう依頼できます。

データを縮小すれば再現できても、元のサービスだけで追加の失敗があるなら、両問題のつながりを確認します。小さな例の成功をサービス全体の成功へ拡大しません。最小例は原因を理解する道具であり、実際の問題が解決したという判断には元の失敗経路の確認も必要です。

7. 結果ファイルと変更内容を読む順序

作業後はまず再現記録を読み、変更したファイルを確認します。次に同じ失敗入力の修正後の結果と正常入力の結果を照合してください。最後に実行できなかった検査と残る不確実性を読みます。回答が長くてもこの四つの証拠がなければ、必要な結果を再要求できます。

例えば報告書に「すべての検査に合格」とあっても、実際のコマンドや検査対象がなければ、どの条件を確認したか問う必要があります。逆に小さな検査一つだけでも、実際のエラー経路を明確に確認したなら、その範囲では有用な証拠となります。確認範囲を広げるには、その必要性を説明し追加条件を指定します。

再現記録のファイル名には、コードバージョンや実行順番号を付けられます。修正前後の出力を同じファイルへ上書きすると比較根拠がなくなるため、別々に保管してください。例外発生行はコード変更で移動し得るため、行番号と該当する関数名を併せて残すとよいでしょう。

変更を戻す際は、作業前の状態と今回の変更を区別します。ユーザーが既に修正したファイルとCodexの修正が混ざっているなら、一括復旧するより変更内容を先に照合してください。修正案をレビューする段階と実際のサービスへ反映する段階も分ける必要があります。バグ再現の依頼は、原因と修正の根拠を作る出発点です。

公式出典と執筆基準

• OpenAI：Codexでコードベースを近代化する
• OpenAI：プロンプトエンジニアリング

資料確認日：2026-10-06。実際に開いた公式資料に基づきAIが作成した説明です。別途示した計算・コード・確認事例は説明用であり、ユーザー環境を直接試験したり実測したりした結果ではありません。公開準備段階で機能と公式資料の変更有無を再確認しました。