Codexテスト実行｜コマンドの選び方と失敗時の確認手順

Codexのテスト実行で何を確認するか

Codexに「テストして」と伝えるだけでは、既存テストを動かすのか、新しいテストを作るのか、画面を操作して振る舞いを確かめるのかが曖昧になります。まず今回の目的を一つに絞ります。変更済みの関数を確かめたいなら関連する既存テストを対象にし、不具合の再現条件を探したいなら失敗した入力や期待結果を添えます。実行だけを頼む場合は、製品コードやテストの期待値を変更しないことも明記すると、結果の意味を保ちやすくなります。

OpenAIの公式ベストプラクティスでは、変更を依頼したあとに関連する確認を行い、結果と差分をレビューする進め方が案内されています。これを既存テストに当てはめると、動かした対象と観測結果を確認してから変更を受け入れる形になります。テストの成功は、そのテストが表現している条件を満たした証拠です。まだテストがない振る舞いや、異なる環境での動作まで確認したことにはなりません。

たとえば金額計算の丸め方を変更した場合、該当関数の単体テストが通っても、画面に表示される税額や外部へ送る金額が同じ規則になっているかは別に確認が必要です。依頼時に「計算関数の既存テストを実行する」と書き、報告に「画面と外部連携は未確認」と残せば、次に調べる範囲が明確になります。成功と未確認を同時に記録することは、確認の不足を見つけるためにも有効です。

なぜ今、モデル変更とテストを一緒に考えるのか

OpenAIの公式更新履歴は、2026年9月29日にGPT-6.1 Solの提供を案内しました。複雑な作業に向けたモデルですが、利用可否はプラン、利用画面、組織の設定に左右されます。モデルを変えたから同じ修正が必ず正しくなる、という判断はできません。いつも扱う小さな課題で、変更の内容とテスト結果を確認すると、自分の開発環境での使い方を検討できます。

また、公式モデル資料では、GPT-5.5が2026年10月14日にChatGPT、ChatGPT Work、Codexで提供終了する予定とされています。この予定はOpenAI APIには適用されません。この記事の対象日である10月7日は予定日の一週間前です。ChatGPTへのサインインでCodexを使い、古いモデルを選んでいる人は、利用可能な置き換え先を確認する時期にあたります。

テストを依頼する前に、モデル名と利用画面を控えておくと、後から結果を比較しやすくなります。ただし、テストの合否だけでモデルの性能を順位付けするのは早計です。入力した指示、参照できた資料、作業フォルダー、依存関係が違えば、結果も変わります。まず同じ課題と同じ期待結果を使い、追加修正の有無や確認にかかった手間を見てください。この記事では性能比較の数値を提示せず、比較の土台となる実行記録を作ります。

既存テストを動かす前にそろえる情報

実行コマンドはプロジェクトごとに異なります。JavaScriptを使っているから必ず同じコマンドになるわけではなく、PHPやPythonでもテストの道具や設定によって対象の指定方法が変わります。説明書、パッケージ設定、既存のテストファイルを読ませて、実際にそのプロジェクトが使っている方法を確認してください。検索で見つけた一般的なコマンドを、対象の構成を見ずに流用すると、違う範囲を動かす可能性があります。

作業場所も同じくらい重要です。ルートフォルダーと、その中のアプリ専用フォルダーでは設定の見え方が異なります。複数のアプリを含む構成なら、どのアプリのテストなのかを指定します。依存関係が用意されているか、テスト用のデータが必要か、ローカルのサービスを起動する前提があるかも確認します。準備が不足している場合は、不足内容を報告してもらい、インストールや設定変更をどこまで任せるかを決めます。

変更前に一度テストを動かせるなら、その結果が基準になります。最初から失敗しているテストと、今回の変更で失敗したテストを区別できるためです。すでに変更済みの状態から依頼する場合は、その事実を明記します。変更前の結果がないことを隠さず、現在の結果と失敗箇所を残せば、原因を断定せずに調査を続けられます。比較のために作業中の変更を勝手に消すような依頼は避け、必要な確認範囲を具体的に伝えます。

Codexへテスト実行を依頼する手順

実務では、確認する範囲を段階的に広げると結果を追いやすくなります。最初に関連する小さなテストを動かし、その結果と変更箇所を見てから周辺のテストを追加します。毎回すべてを動かすかどうかは、プロジェクトの規約と変更の影響範囲で判断してください。規約で全件確認が求められる場合は、その条件を優先します。小さな範囲で成功したことを、全件の成功として報告しないことが重要です。

以下は、既存のテスト構成を調べてから実行する依頼例です。完成条件を先に示すことで、必要な情報が結果から抜けにくくなります。コマンドの選定理由を残せば、次の担当者も同じ条件で確認できます。例に出す項目はプロジェクトに応じて変更し、利用していない道具の名前や存在しないテストファイルを前提にしないでください。

Step 1: 実行対象とコマンドを確認する

対象フォルダーと変更した機能を渡し、説明書や設定から既存の実行方法を探してもらいます。この段階では、候補のコマンド、選んだ理由、必要な準備を報告対象にします。複数の候補があるなら、単体テストと結合テストのどちらなのか、対象を絞る指定が有効かを確認します。実行方法が見つからなかった場合は、そのまま未確認と報告してもらいます。

Step 2: 関連する既存テストを実行する

実行対象が分かったら、対象の変更を確かめるテストを動かしてもらいます。実行時には作業場所とコマンドを残し、待機が長い場合は実行中なのか終了したのかを確認します。途中で止めた場合は完了扱いにしません。コードの修正まで頼んでいないなら、失敗した箇所と理由の候補を報告するところで区切り、期待値を書き換えて通過させないようにします。

Step 3: 結果と確認できなかった範囲を報告する

終了コード、対象件数、成功・失敗・除外の件数を、テストの道具が出力する範囲で報告してもらいます。件数が出ない場合は推測せず、その旨を残します。失敗したテスト名と主要なエラー、実行できなかった理由、まだ確認していない範囲も添えます。短い要約と根拠となるログの抜粋を受け取り、対象の振る舞いを確認できたか判断します。

依頼文は、次のようにまとめられます。これは製品固有の命令形式ではなく、会話で渡すための例です。

対象フォルダーの説明書と設定を読み、金額計算に関連する既存テストを確認してください。
実行コマンドが分かったら、そのテストを実行してください。
今回は製品コードとテストの期待値を変更しないでください。
依存関係の追加や設定変更が必要なら、不足内容を先に報告してください。
作業場所、実行コマンド、終了コード、対象件数、失敗したテスト名を報告してください。
除外したテストと、確認できなかった範囲も明記してください。

テスト失敗を環境とコードに切り分ける

テストが失敗したときは、まずどこまで進んだかを確認します。テストの道具そのものが起動していない場合と、テストが動いて期待値との不一致が出た場合では、調べる順番が違います。依存関係が見つからないというエラーなら、準備の不足や作業場所の誤りが候補です。データベースへ接続できない場合は、テスト用サービスの状態や接続先を確認します。この段階で製品コードの計算式を直しても、実行の前提は整いません。

期待値との不一致が出ているなら、入力、実際の出力、期待された出力を並べて読みます。今回の変更による回帰なのか、以前からの失敗なのか、仕様変更に伴って期待値を見直す必要があるのかを調べます。テストが正しいとも実装が正しいとも、最初から決めつけません。仕様を根拠に判定するため、関連する説明や再現条件をCodexへ渡すと、修正案の理由を確認しやすくなります。

テストが見つからないときの終了コードは道具によって異なります。表は終了コードの仕様を断定するものではなく、結果の読み方を整理したものです。画面に成功らしい表示があっても、目的のテストが実行されたことを件数や名前で確認してください。除外や保留も同様です。実行された範囲の成功と、対象全体の確認完了は、記録上も区別しておきます。

修正を追加で頼む場合は、失敗した一つの条件と期待する振る舞いを指定します。修正後は同じ対象を再実行し、必要に応じて影響する周辺テストを確かめます。失敗が再現しない場合は、その事実と変わった条件を残します。一度成功しただけで原因が解消したと判断せず、入力や準備の違いを調べることが、再発時の調査を助けます。

実行結果を次の判断に使える形で残す

報告では「テスト済み」の一言を、確認可能な情報へ置き換えます。必要なのは、対象、作業場所、コマンド、結果、未確認事項です。モデル名や利用画面も残すと、次回の依頼条件を再現しやすくなります。一方、ログをすべて貼り付けるだけでは判断に必要な箇所が埋もれます。要約に実行範囲と結論を書き、その根拠となるテスト名やエラーを短く添える形が読みやすくなります。

たとえば「金額計算に関連する既存テスト12件を実行し、12件成功、除外なし。画面表示と外部連携は未確認」という報告なら、次に確認する範囲が分かります。これは報告形式を示す仮の例で、この記事で実際に動かした結果ではありません。環境が整わず動かせなかった場合も、「実行用の依存関係がなく未実行。製品コードの正否は未判定」と残せば、準備の問題と品質の問題を混同せずに済みます。

モデルの切り替え時には、同じ報告形式を使ってください。GPT-6.1 Solが利用できる場合も、別の対応モデルを使う場合も、テストが確かめる振る舞いはプロジェクトの仕様で決まります。必要な対象を実行し、期待結果と照合し、確認していない範囲を残す。この習慣があれば、Codexの応答だけで作業完了を判断せず、実際のコードと観測結果を基に次の修正やレビューへ進めます。