Codexのコードレビューとテスト｜確認漏れを防ぐ方法

2026年10月1日
Codex

こんにちは。Osukeラーニング、運営者の「osuke」です。

Codexにコードレビューを頼み、「大きな問題はありません」と返ってきた。でも、テストまで動かしたのかは分からない。作った業務ツールや修正した機能を公開する前に、そんな迷いを抱えていませんか。

結論からいうと、コードを読むレビュー、プログラムを動かすテスト、変更を採用する判断は分けて扱うのが基本です。Codexに何となく「確認して」と任せるより、対象の差分、期待する動作、実行結果と未確認事項を指定したほうが、次に何を確かめるべきかが明確になります。

この記事は2026年10月1日に確認したOpenAI公式資料と、Xの複数の公開投稿をもとに整理しています。osuke本人が実務で検証した体験談ではありません。本文の会員CSV出力機能は手順を説明するための架空例であり、実測結果ではない点も先にお伝えします。

記事のポイント

コードレビューとテストで分かることの違い
対象の差分と期待動作を伝えるプロンプト
実行済み・失敗・未実行を分ける確認方法
AIの指摘を採用する前に人が判断する範囲

Codexのコードレビューとテストの基本

最初に整理したいのは、機能の多さではなく「何を確認した結果なのか」です。レビューの指摘が少なくても、テストの実行環境や業務上の正しさまで確認できたとは限りません。まず確認対象と証拠をそろえましょう。

レビューと実行確認を分ける

レビューは問題の可能性を探す作業、テストは決めた条件で実行結果を確かめる作業です。コードの読み取りから、入力が空のときの分岐漏れや権限チェックの位置に気づくことはあります。一方、実際の依存関係や設定を含む環境で動くかどうかは、コードを読むだけでは確定しません。この違いを曖昧にすると、「確認した」という同じ言葉で別の作業を指してしまいます。

例えば、会員一覧をCSVに出力する変更を考えてみてください。レビューでは、管理者以外も出力できる経路がないかを読みます。テストでは、一般ユーザーで呼び出したときに拒否されるかを実行して確かめます。さらに出力してよい項目が業務ルールと一致するかは、担当者が判断する必要があります。どれか1つが済んでも、残り2つまで自動的に完了するわけではありません。

確認の種類	主に見るもの	それだけでは分からないこと
コードレビュー	差分、処理の流れ、想定外の入力	実環境での実行成功
テスト実行	指定した条件での結果	用意していない条件の正しさ
採用判断	要件、未確認事項、影響範囲	将来の不具合がゼロである保証

「二重に確認するのは面倒」と感じるなら、すべてを同じ重さで扱う必要はありません。表示文言の修正と、会員情報の出力や削除処理では影響が違います。小さな変更は関連する少数のテストから始め、重要な処理は権限や異常系まで広げる、という配分にします。レビューを省くか全部読むかの二択ではなく、失敗した場合に困る箇所から確認を厚くする考え方です。

レビュー結果とテスト結果を別の欄で受け取る
テストを作っただけなら「実行済み」と数えない
業務上の正解は人が決め、AIに明示する

差分とベースブランチを決める

レビューを始める前に、どの変更をどこと比較するかを決めます。OpenAIの公式資料では、ローカルのGitプロジェクトで/reviewを使い、ベースブランチとの差分や未コミットの変更を対象にできると案内されています。単に「このリポジトリを確認して」と頼むより、今回の修正を含む範囲を選ぶほうが、対象外の古いコードに話が広がりにくくなります。

未コミットの変更には、自分が今回触ったもの以外が混ざっていることもあります。例えば、CSV機能の修正と別件の画面調整が同じ作業場所に残っていたら、その両方をレビューするのか、片方だけなのかを先に区別します。関係のない変更を勝手に戻して整理するのではなく、作業者や変更理由を確認してください。差分表示は「Codexが書いたコードだけ」の一覧とは限らないためです。

CLIで非対話のレビューを行う場合、公式の開発者コマンド資料にはcodex review --uncommittedやcodex review --base mainが示されています。後者のmainは例であり、実際の比較先に置き換えます。これらの対象指定とカスタムプロンプト引数は併用できないため、思いついた文章をコマンド末尾へ足す使い方は避けましょう。手元のバージョンで使える指定はヘルプでも確認します。

アプリの画面やPR向けのCode Reviewと、ローカルのレビューコマンドは入口が異なります。この記事ではローカルの差分確認を中心にしています。まずGit管理された対象を開き、変更一覧と比較先を確認してからレビューを開始してください。入口やレビュー対象の考え方は、OpenAI公式のコードレビューガイドでも確認できます。

未コミット変更に別作業が混ざっていないか確認
ベースブランチは名前だけでなく比較したい基準かを確認
レビューのために他者の変更を削除・巻き戻ししない

期待動作をプロンプトに書く

差分が選べても、何が正しい動作なのかが伝わらなければ、レビューは表面的になりがちです。「不具合を探して」に加えて、利用者、入力、期待する結果、変えてはいけない動作を渡しましょう。業務の担当者だけが知っている例外は、コードから読み取れないことがあります。文章を書く負担を増やすためではなく、AIが推測で埋める余地を小さくするための準備です。

架空のCSV機能なら、「管理者だけが使う」「0件でもヘッダー行は出す」「出力項目は既存仕様から増やさない」といった条件が考えられます。ただし、これらはすべてのシステムで正しい仕様ではありません。あなたの業務で必要な内容へ置き換えてください。仕様が未確定なら、Codexに正解を決めてもらうのではなく、選択肢と影響を整理させ、人が決めた後にレビューへ進みます。

通常のチャットで使う依頼例です。CLIの対象指定に続けて貼る引数ではありません。

対象：今回の会員CSV出力の変更。比較先と対象ファイルは添付の差分で確認
期待：管理者のみ利用可、0件でもヘッダーを出力、出力項目を増やさない
今回は修正せず、再現条件・該当箇所・期待と実際の差を報告
テストを実行していない場合は、その旨を明記

最初の依頼で「問題があれば全部直して」まで含めると、指摘の妥当性を読む前に変更が増える可能性があります。まず報告だけを受け取り、直す範囲を選んでから修正依頼へ進む形がおすすめです。特に既存コードの設計変更や依存ライブラリ更新まで広がると、本来の修正と関係ない差分が増えます。診断と修正を区切れば、採用しない提案を無理に戻す手間も減らせます。

毎回共通するテストコマンドや禁止事項は、CodexのAGENTS.mdの書き方で扱ったようにプロジェクトの指示へ整理できます。ただし今回だけの期待動作まで固定ルールに詰め込む必要はありません。常設の基準と、その変更固有の条件を分けておくと、長い指示の中に大切な例外が埋もれにくくなります。

指摘の根拠と優先度を読む

レビュー結果が返ったら、指摘の件数よりもどの条件で何が起こるかを読みます。ファイル名や行番号が付いていると説得力がありそうに見えますが、それだけでは正しい指摘と確定しません。対象が最新の差分か、指摘された経路に実際に到達できるか、前提にした仕様が合っているかを確認してください。改善提案と、今すぐ直すべき不具合を同じ重さにしないことも大切です。

例えば「空の配列で処理が壊れる」という指摘なら、空配列を渡せる入口があるか、どこで検証されるか、期待する戻り値は何かを確かめます。逆に「関数を分割したほうが読みやすい」という提案は、保守上の価値があっても、公開を止める根拠とは別です。説明例として、データ漏えいにつながる権限漏れ、利用者が操作できない不具合、読みやすさの改善の順に、影響を具体化して判断します。

指摘に納得できないときは、反論して消してもらうより、条件を掘り下げると役立ちます。「その入力はどこから来るのか」「既存の検証では防げないのか」「最小の再現例は何か」と聞けば、確認の次の一歩が見えます。再現できなければ即座に誤検知と断定するのでもなく、環境や前提が不足している可能性を残します。疑問が解消するまでは、未確定の指摘として管理しましょう。

また、指摘が0件だった場合も、対象外のファイルや不明な要件がないかを確認します。レビューが見ているのは、渡した情報と選んだ範囲です。小さな差分を丁寧に見た結果と、広すぎる変更を十分に追えなかった結果が、同じ「指摘なし」に見えることも考えられます。報告には対象範囲と残る不確実性を添えてもらい、安心感だけで公開を決めないようにしてください。

指摘ごとに「条件・影響・根拠」を読む
不具合と設計上の好みを分ける
指摘なしの場合も、対象外と不明点を確認する

Xの実例から限界を知る

Xの公開投稿を調べると、実装からレビュー、テストまでを単一の「AIにお任せ」でまとめない運用が見つかりました。例えば@nanomix_ltdの投稿では、人が読める粒度で実装し、コード確認と動作確認を分け、テストも相互に確認する流れが説明されています。これは一利用者の運用例であり、効果を独立検証したデータではありませんが、確認する量とタイミングを設計する視点は参考になります。

一方、@exceedsystemの投稿には、GitHub連携のPRレビューを始めようとして利用制限で進めなかったという報告がありました。投稿内の課金設定による回避や不具合原因については未確認の推測が含まれるため、ここでは解決手順として紹介しません。読み取れるのは、レビューを頼んだことと、レビューが実行されたことは別だという実務上の注意点です。開始前に止まった処理は、完了件数に含めないでください。

さらに@yagiryuuuは、AIでツールを作りやすくなっても継続保守は別問題で、専門家による定期的な確認体制が重要だという意見を述べています。この記事では、その意見を「AIだけで全部完結する」という期待に対する反対の視点として扱います。利用者の意見は製品仕様の根拠ではなく、あなたの環境でも同じ結果になる保証もありません。便利な部分と責任が残る部分を分けて考える材料です。

今回の調査は2026年10月1日に公開状態で読めた少数の投稿を対象とし、利用者全体の満足度や不具合率を測ったものではありません。検索結果には宣伝やニュース紹介も多く、目立つ成功例だけを集めると判断が偏ります。複数のAIを使えば必ず品質が上がる、といった一般化も避けます。手順を採り入れる際は、自分の小さな変更で必要な確認が残っていないかを見てください。

運用例は参考にし、製品仕様は公式資料で確認
制限や権限で開始できなかった作業は未実行扱い
成功談の数を、そのまま安全性の証明にしない

Codexのコードレビューとテストの手順

ここからは、レビュー後にどう確かめて採用するかを整理します。すべてのプロジェクトに同じテストコマンドがあるわけではありません。使っている環境と既存の手順を確認し、実行してよい範囲から進めることが前提です。

テスト条件を先に整理する

テストを追加するときは、コードの行を増やす前に条件を整理します。正常な入力だけでなく、空の入力、境界の値、権限がない利用者、外部サービスが失敗した場合など、今回の変更で影響を受けるものを選びましょう。すべてを一度に網羅する必要はありません。変更前に守れていた動作と、新しく求める動作を分けると、回帰テストで何を残すべきかが見えてきます。

架空のCSV機能なら、会員が1件のとき、0件のとき、出力権限がないときの3条件から考えられます。日本語の氏名やカンマを含む項目がある場合は、利用先のソフトで正しく扱えるかも検討します。ただし、個人情報を含む実データをそのまま持ち込む必要はありません。テスト専用のダミーデータと隔離された環境を使い、業務データの送信や本番での実行は別途許可された範囲に限定します。

Codexへは「テストを書いて」だけでなく、「この期待動作を確認する最小のテストを提案し、既存のテスト方法に合わせて追加して」と頼むと、目的を共有しやすくなります。既存のコードに合わせただけのテストでは、そのコードと同じ誤解を固定してしまう可能性があります。期待する結果の根拠は、実装そのものではなく仕様や業務ルールに置いてください。テストが正しいかもレビュー対象です。

「テスト環境がないので何もできない」という場合は、まず環境の有無と実行手順を調べてもらいましょう。新しいテスト基盤を勝手に大量導入するより、既存の確認手順、手動確認が必要な部分、後日自動化する候補を分けるほうが進めやすいことがあります。初回は小さい処理1つの入力と期待結果を明文化するだけでも、説明のない動作確認から前進できます。

正常系：想定どおりの入力で期待する結果になるか
例外系：空・境界・権限不足などの扱いは決まっているか
回帰：変更していない既存動作を壊していないか
データ：本番情報ではなく安全なテスト用データか

実行ログと未実行を確認する

テストを頼んだ後は、「成功しました」という要約だけで終えず、何を実行したかを確認します。コマンド、実行した場所、結果、失敗やスキップの有無が分かれば、後から再確認しやすくなります。OpenAIのベストプラクティスでも、関連するテストやチェックを行い、その結果を確認することが推奨されています。以下の5項目は、その考え方を日常の作業に落とし込むための報告書式です。

実行後の報告依頼例

対象：どの変更・どの状態を確認したか
実行：コマンドと作業ディレクトリ
結果：終了状態、成功・失敗・スキップの内訳
未実行：実行していない確認と理由
残課題：人の操作や追加環境が必要な項目

終了コードが0でも、目的のテストが見つからず実行件数が0だったり、重要なケースがスキップされていたりする可能性を見落とさないでください。また、型チェックやlintが通ったことと、利用者の操作が正しいことは別です。架空のCSV例であれば、静的チェックは完了したが、ダウンロードしたファイルを想定ソフトで開く確認は未実行、というように役割を分けて記録します。

ログを全部読む時間がない場合も、要約と根拠を行き来できるようにします。「関連する3つのテストを実行した」と返ってきたら、その3つが確認した条件は何か、という一段だけ掘り下げてください。反対に、必要のない長大なログを公開チャットや共有資料へ貼り付けるのも避けます。接続情報や実データが混ざることがあるため、共有するのは必要な範囲を確認した記録にとどめます。

権限、ネット接続、利用制限などで実行できない場合は、その理由を未実行欄へ残せば十分です。未実行を成功に読み替えたり、作業を進めるために承認を無条件で回避したりしてはいけません。実行の許可と完了の確認は別の話です。制約の考え方はCodexの権限とサンドボックスの注意点でも整理しています。残った確認を誰がどこで行うかまで決めましょう。

失敗時は原因を分けて直す

テストが失敗したら、すぐに実装を書き換えるのではなく、どの種類の失敗かを分けます。コードの不具合、テストの期待値の誤り、依存関係の不足、接続先が使えない状態などでは、取るべき対応が違います。赤い結果を緑にすることではなく、正しい条件で期待する動作を確かめることが目的です。失敗を消すためだけにテストや検証を弱めると、安心する材料まで失ってしまいます。

例えばCSVの出力順が期待と違った場合、仕様では順序が決まっているのかを確認します。決まっているなら実装が誤っている可能性があり、決まっていないならテストの前提を見直す余地があります。一方、ライブラリが見つからず起動前に止まった場合は、CSV処理の正しさを評価できていません。この状態を「CSVのテストに失敗したからロジックを変更する」と解釈しないことが重要です。

Codexには、「原因を切り分け、根拠と最小の修正案を示して。無関係な変更はしないで」と依頼できます。修正する箇所を決めた後は、同じ条件で再実行し、周辺の既存動作も必要な範囲で確認します。不具合を再現できた場合は、修正前に失敗し修正後に成功するテストを残せると、同じ問題の再発を検知しやすくなります。ただし、再現環境がない段階で成功結果を作ってはいけません。

失敗が続くと、設定を一気に変えたり、依存関係をまとめて更新したくなるかもしれません。変更を増やすほど原因が追いにくくなるため、まず1つの仮説を小さく確認します。本番へのアクセスやデータ削除が必要そうなら、その場で自動実行の範囲を広げず、担当者に判断を渡してください。直せなかった理由が正確に残ることも、誤った修正を入れないための成果です。

コード・テスト・環境のどこで失敗したかを分ける
通すためだけにテスト削除や期待値変更をしない
修正後は同じ条件で再実行し、結果を更新する

人の確認と継続運用を残す

レビューと関連テストが完了しても、変更を採用する責任は残ります。業務上の出力項目、利用者の権限、操作の分かりやすさなどは、コードだけを見ても正解が分からないことがあります。「技術的に動く」と「その業務で使ってよい」は同じではありません。人が判断する項目を最初から残しておくほうが、最後になって誰も確認していなかったと気づく事態を防ぎやすくなります。

架空のCSV機能なら、担当者がダミーデータで出力内容を確認し、必要な項目だけが含まれるかを見ます。開発者は権限チェックや実装差分を確認し、運用担当者は障害時の連絡先や元に戻す手順を確認する、と分担できます。小規模なチームで1人が兼ねる場合でも、確認の役割を分けて記録することは可能です。全員が同じAIの要約だけを見る状態は避けましょう。

「別のAIにもう一度読ませれば、人の確認はいらないのでは」と感じるかもしれません。別の観点から指摘を探す使い方には意味がありますが、同じ誤った仕様を渡せば、複数の確認でも誤りが残り得ます。台数や回数を増やすだけでなく、期待動作の根拠、再現条件、実行記録を増やすほうが判断材料になります。専門知識が必要な箇所は、適切な担当者へレビューを依頼してください。

公開後も、依存関係や外部サービスの変更で、以前の確認がそのまま有効とは限りません。利用者からの不具合報告、実行失敗の記録、次回変更時に必要なテストを残しておくと、毎回ゼロから調べ直す負担が減ります。すべてを大規模に自動化する前に、今回の変更と確認結果を結び付けて保存しましょう。レビュー済みという印だけより、何を見たかが追える記録のほうが役立ちます。

業務担当：期待する結果と利用してよい範囲
開発担当：差分、テスト、未解決の技術的な懸念
運用担当：公開後の確認と問題発生時の対応

Codexのコードレビューとテストのまとめ

Codexのコードレビューとテストを使うときは、「AIが大丈夫と言ったか」ではなく、対象・期待・実行・未確認が説明できるかを基準にしてみてください。差分を読むこと、テストを作ること、実行結果を確かめることはそれぞれ違います。この区別だけでも、指摘なしの返答をそのまま公開許可と受け取る迷いから抜け出しやすくなります。

最初の1回は、小さい変更を1件選ぶところからで構いません。対象の差分を確認し、期待動作を3点程度にまとめ、まず修正なしのレビューを頼みます。指摘の根拠を読んで採用する修正を決めたら、関連するテストを実行し、実行済みと未実行を別々に報告してもらいましょう。これは工程を増やすためではなく、何が済んだかを見失わないための順番です。

確認する余裕が少ないときほど、未確認の項目を消さないことが大切です。権限がなく動かせない、業務仕様が決まっていない、手動操作をまだ試していない、といった状態を明記すれば、次の担当者に作業を引き継げます。逆に「一通り問題なし」という短い報告だけでは、後から不足に気づいても、どこから確認し直せばよいか分かりません。正確な未完了報告も品質管理の一部です。

Codex自体の役割や利用の全体像がまだ曖昧なら、Codexでできることと使い方の基本から整理してみてください。そのうえで、今日の変更1件について、次の確認票を埋められるか試すのがおすすめです。完璧に任せられる道具を探すより、任せた結果を確かめられる形にすることが、継続して使うための土台になります。