Codexの変更を確認する：差分と実行結果を併せて見る

Codexが機能を直して「修正完了」と伝えたとき、最初に見るべきものは実際のファイルの差分です。結果の要約は変更目的の理解に役立ちますが、何が追加され、何が消えたかはdiffで確認する必要があります。いくつのファイルが変わったか、元の問題に無関係なコードも変わったか、確認したテストがどの範囲を扱うかを併せて読むと、結果を受け入れやすくなります。この記事は、コードレビューを依頼する一般的な方法より、実際の変更を受け取る時点での確認順序に焦点を当てます。

まず何を比較しているかを確認する

diffは2つの状態の違いです。作業フォルダーとステージング領域を比較することも、2つのコミットやブランチを比較することもできます。同じ「変更を表示」画面でも、基準が変わると表示されるファイルが変わります。OpenAIの公式レビューガイドは、レビュー画面がリポジトリの現在の変更状態を反映し、Codex以外の変更も含む場合があると説明しています。そのため、画面に見えるすべてのファイルを今回のAI作業の結果と断定しません。どの基準状態と現在の状態を比較しているかを先に読む必要があります。

ターミナルを使う場合は、Gitの読み取り専用コマンドで範囲を分けて確認できます。説明例として、git diffは未ステージの変更、git diff --stagedはステージ済みの変更の確認に使います。git diff HEADは、最後のコミットを基準に作業フォルダーの追跡済みの変更を見る際に使えます。この記事のコマンドは個人のリポジトリで実行した結果ではなく、確認方法を説明する例です。新しく作った未追跡のファイルは、別途状態一覧を確認する必要があることも覚えておいてください。

ファイル一覧を想定範囲と比較する

説明用の作業を「設定画面のオプション保存エラーの修正」と仮定しましょう。設定画面、保存関数、関連テストが変わるのは自然です。一方でログイン権限設定、全体のスタイルファイル、パッケージバージョンまで変わっていたら、理由を確認する必要があります。無関係に見えるファイルが含まれていても、必ず誤りとは限りません。元の問題を解決するため、共通関数を変えた可能性があります。ただし関係を説明できてこそ、確認範囲を定められます。

ファイル名だけで役割を判断せず、変更目的を記すよう頼みます。「変更した各ファイルを、問題解決に直接必要な変更、検証用の変更、それ以外の変更に分類し、理由を教えて」と書けます。単純な書式整理が多いと、実際の動作を変える行が埋もれる場合があります。機能修正と書式変更を分けられるか確認すれば、次の確認が容易になります。ユーザーがすでに修正したファイルは、その目的を読み、今回の結果と一緒に照合しなければなりません。

確認する変化	読み取るための問い	必要な検証
条件文の修正	新しい条件はどの入力を違って扱うか	正常・空値・境界入力を比較
関数名の変更	呼び出す別のファイルも変わったか	呼び出し箇所とビルドを確認
既定値の変更	既存のユーザー設定に影響するか	保存済みデータと新しいデータを比較
パッケージの変更	この修正に必要な変更か	互換性・インストール・ロックファイルを確認
テストの追加	元のエラーを実際に再現するか	修正前の失敗と修正後の結果を確認

赤い行と緑の行を一緒に読む

追加されたコードだけを見ると、以前保証していた動作が消えたかどうか分かりにくくなります。削除された行の役割と、新しい行がその役割をどう引き継ぐかを併せて読む必要があります。diffの文脈行は、変更されていない周辺コードを示します。文脈が不足していたら、元のファイルと該当関数全体を開いて読んでください。条件文を1行変えただけでも、その前で値が変換されたり、後で例外処理が行われたりする場合があります。変更行数は影響範囲の代わりにはなりません。

例えば架空のJavaScriptコードで、if (!value)を値がない場合の既定値処理に使っていたとします。この条件はfalseや0も既定値として扱う場合があります。nullとundefinedだけを確認する条件に変えると、falseと0は保持されます。この変更がよいかは実際の要件次第です。「無効」を意味するfalseをユーザーが選べるなら保持が必要かもしれませんが、空文字列も値なしとして扱うべきなら追加条件を検討しなければなりません。コードが短くなっただけで正しいと判断しません。

入力ごとの変更前後の結果表を作る

変更した条件を確認する際は、正常値を1つだけ入れるより、異なる入力を分けて見るほうがよいでしょう。架空のオプション保存コードでは、true、false、0、空文字列、null、undefinedが何を意味するかを定めます。この表は実際の製品で使った値ではなく、確認方法を説明する例です。値の意味を先に定めてこそ、以前のコードと新しいコードのどちらの結果が要件に合うか判断できます。データ型が異なれば、画面上では同じ値でも違う条件を通過する場合があります。

入力例	業務上の意味の例	確認する条件
false	ユーザーが機能を無効にした	既定値で上書きせず保持するか
0	許容される最小数量	値なしと区別するか
空文字列	ユーザーが値を空にした	空値を許すかが定義されているか
null	明示的に値がない	既定値またはエラー処理が適切か
undefined	フィールドが提供されていない	欠落フィールドの方針に合うか

テスト合格の範囲を読む

すべての検査に合格したという文を見たら、どの検査をどの状態で実行したかを確認します。インストール段階が失敗してテストが始まらなかったなら、テスト失敗とは区別する必要があります。関連する単体テストだけに合格した状態と、アプリ全体を実際の画面で確認した状態も異なります。検証結果には実行コマンド、検査対象、成功と失敗、実行できなかった項目を分けるよう頼みます。古い結果を最後の修正後の結果として受け取らないよう、検査時点も確認してください。

新しいテストが、コードの現在の実装を繰り返すだけになっていないかを見ることも役立ちます。誤った動作をそのまま期待値に記すと、テストが合格しても元の問題は解決しません。説明用の保存エラーなら、ユーザーに見える結果を基準に、「オプションを無効にして再読込してもfalseが維持される」ことを確認しなければなりません。修正前のコードで同じ事例が失敗するか確認できれば、回帰検証の根拠がより明確になります。ただし実際に修正前の状態を実行していないなら、そのような結果を報告書に作って入れません。

具体的な追加依頼を書く

結果全体が気に入らないとだけ伝えるより、確認した行と影響を記します。「オプション値を読む条件で、空文字列の方針がまだ説明されていない。現在の入力定義を確認し、falseと0を保持する意図を維持したまま、空文字列の処理だけを整理して。ログインやパッケージバージョンは変えないで。関連する入力表と検証結果を再び残して」のように書けます。この依頼は、新しい機能を広く任せる代わりに、残った判断を絞ります。

Codexのレビュー結果でも、推測と実際の再現を区別するよう頼んでください。「起こり得る」という指摘は、そこに到達する条件があるかを確認する必要があります。実際に問題となる入力と呼び出し経路を説明できれば、修正を判断しやすくなります。逆にコードスタイルの好みが違うだけの指摘は、現在のエラー解決から分けられます。レビュー後は追加修正のdiffを再び読み、元の問題につながらない変更が追加されていないか確認します。

バイナリー・生成ファイルが変わった場合

画像や文書などのバイナリーファイルは、テキストdiffだけでは内容を十分に確認しにくいものです。実際のファイルを開き、サイズ、レイアウト、内容が意図どおり変わったかを見ます。ロックファイルや自動生成ファイルは、元の設定と生成過程を併せて確認する必要があります。変更行が多いからといってすべて無視したり、すべて危険と判断したりはしません。変更がどのコマンドや元設定から生じたかを結び付けると、確認対象を整理できます。

ファイルの改名や移動も確認しなければなりません。同じ内容のファイルを移しただけでも、相対パスやimportパスに影響する場合があります。文書リンク、テストパス、デプロイ設定が以前の位置を参照していないかを点検します。AIに「ファイル移動は内容の変更と分けて説明し、以前のパスを参照する場所を確認して」と頼めます。移動後の動作を確認していないなら、ファイルが存在するだけで完了と記しません。

結果を受け入れる前の最終確認

最後に、元の問題が再現しなくなったか、維持すべき動作が残っているか、実際の変更ファイルと結果要約が一致するかを確認します。コミットやデプロイなど次の段階に進む前に、検証できなかった項目も読みます。「レビュー完了」は、考えられるすべての欠陥がない保証ではなく、定めた範囲の結果を確認したという意味で記録します。コード変更を受け入れる判断では、diff、入力事例、実行結果が互いにつながっている必要があります。

diffが長すぎる場合はどうしますか？ ファイルごとの目的を整理し、実際の動作を変える部分から読みます。必要なら書式変更を分けるよう頼んでください。AIが作った変更だけを見れば十分ですか？ ユーザーの変更と共通コードが一緒に動くため、現在のリポジトリ状態も確認する必要があります。検査に合格したのに画面が違う場合、何を見ますか？ 検査環境と実際の画面の設定・データ・ビルドが同じか比較し、欠けた再現条件を追加してください。

公式資料と執筆基準

• OpenAIのコードレビューガイド
• Git公式git-diffガイド

AIを活用して作成した情報記事です。公式文書は2026年10月3日に確認し、以下の例は説明用に構成しました。実際の個人プロジェクトでの実行成果や実測値を意味しません。公開前に変更された製品案内を再確認します。

Codexの変更を確認する

1. 比較基準を確認

→

2. ファイルごとの目的を整理

→

3. 削除・追加行を併せて読む

→

4. 入力ごとの変化を確認

→

5. 検査結果を照合

説明用に独自に作成したフロー図であり、実際の製品画面や測定結果ではありません。