受注管理アプリを保守する開発担当者が、リリース前に設定一覧と起動コードを照合しています。接続先は環境変数で切り替え、設定例はリポジトリ内のファイルで管理しています。コードレビューと自動テストも運用していますが、設定値の確認方法は項目ごとに異なります。接続先の不足はデータベースにアクセスするまで分からず、ポート番号の誤記は起動処理の途中で例外になる、といった状態を想定します。これは本記事のために設定した架空の業務例です。

AIを使わない場合、担当者は設定仕様を読み、環境変数を参照するコードを検索し、既定値や変換処理を確認します。その後、不足している検証を実装し、設定不足・不正値・正常値のテストを追加します。既存の検索機能やテスト基盤を使えるため、すべてを手作業で調べ直す必要はありません。それでも、仕様と参照箇所とテストを往復しながら、同じ条件が一貫して扱われているか確かめる作業は残ります。

今回の成果物は、環境変数を起動時にまとめて検証する変更一式です。検証関数だけでなく、起動処理への組み込み、回帰テスト、設定例、レビュー用の確認記録までを含めます。Codexには調査結果の整理と実装・テストの作成を補助してもらい、設定の意味や停止条件は担当者が決めます。

対象読者には、Pythonの例外処理、環境変数、Gitの差分確認、自動テストを読める知識を想定しています。狙うのは設定事故全般の解消ではありません。定義した必須項目や値の範囲に違反した場合に、リクエストを受け付ける前に停止できる状態を作ることです。

この保守作業では、コードを書く前の照合に注意が必要です。設定一覧に必須と書かれていても、コード側では既定値が入っているかもしれません。逆に、設定例には載っていない変数が別のモジュールで参照されている場合もあります。検索結果を集めるだけでは、どちらが正しい仕様か判断できないでしょう。担当者は運用上の意図を確認し、今回変更する項目を限定する必要があります。

変換処理の違いも見落としやすい箇所です。ポート番号を整数へ変換する処理があっても、許可する文字列の形式や数値の範囲まで確認しているとは限りません。接続先の設定が存在していても、空文字を受け入れてしまえば、不足した状態と実質的に変わりません。こうした条件を一つずつ仕様と照合し、テストの入力と期待結果へ転記する工程に繰り返しが生じます。

Codexを使う場合も、入力と品質条件は変えません。同じ仕様、同じコード、同じテスト基盤を対象に、照合表の下書きや変更案を作ってもらう進め方を提案します。人が残す判断を含めると、工程の対応は次のようになります。

| 工程 | AIを使わない場合 | Codexに依頼する補助 | 人が残す判断 |
| --- | --- | --- | --- |
| 調査 | 仕様と参照コードを照合します | 参照箇所と不一致候補を整理してもらいます | 正式な仕様を決めます |
| 実装 | 検証と起動処理を変更します | 限定した範囲の変更案を作ってもらいます | 停止位置と互換性を確認します |
| テスト | 条件ごとにケースを作ります | 入力と期待結果からテストを作ってもらいます | 期待結果の正しさを確認します |
| レビュー | 差分と実行結果を読みます | 変更理由と未確認事項を整理してもらいます | 採用と承認を行います |

省略を期待できるのは、確認対象を探して並べ直す作業や、確定した条件から類似ケースを書き起こす作業です。仕様の矛盾をAIの推測で埋めると、後のレビューが増えるおそれがあります。調査段階で不明点を分離しておくことが、実装後の手戻りを抑える前提になります。

練習用には、本番の秘密情報を含まない小さなPythonリポジトリを使います。以下のファイル名や設定条件は、再現用に提案する架空の構成です。アプリの起動処理を `app/main.py`、設定処理を `app/config.py`、テストを `tests/test_config.py`、設定例を `.env.example` に置く想定にします。実際の作業では既存構成へ読み替え、テストの起動方法もリポジトリに記載された手順を確認してください。

今回の仕様は二項目に絞ります。`DATABASE_URL` は必須で、未設定・空文字・空白だけの値をエラーにします。接続先の到達性や認証の成否は、この検証では扱いません。`PORT` も必須とし、半角数字だけで構成された文字列を受け付け、整数に変換した結果が1以上65535以下であることを求めます。前後の空白、符号、小数点を含む入力は拒否します。既定値による補完は行わない仕様です。

起動順序も受け入れ条件に含めます。環境変数の読み込み後、データベース接続と待ち受け開始の前に検証し、不正なら終了する構成を目指します。モジュールの読み込み時に接続するコードがあれば、関数を先頭へ追加するだけでは条件を満たせません。Codexへの調査依頼には、副作用のある初期化処理の確認も含めるとよいでしょう。

OpenAIの公式Cookbookでは、`AGENTS.md` は任意のリポジトリ向け指針として認識され、計画や作業段階を記録するファイル群は推奨される運用上の慣例と説明されています。すべての管理ファイルを新設する必要はありません。既存の指針があれば読み、今回の目的、変更対象、検証条件を短い作業メモにまとめる運用を提案します。（出典: OpenAI Cookbook）

提供された資料の取得日時は2026年11月7日ですが、これは公開日を意味しません。本記事では、その資料を新機能の発表として扱わず、範囲を限定して開発作業を進める参考として使用しています。

操作は、リポジトリを扱う既存のCodex作業環境で行う想定です。製品固有の画面や起動コマンドは追加せず、作業対象のコードを参照できる状態から始めます。主な段階は、読み取り調査、仕様の確定、実装とテスト、差分の受け取りの四つです。以下のお願い文は業務への応用例であり、実行済みの記録ではありません。ファイル名は自分の構成に置き換えてください。

最初は編集を始めず、現状を調べてもらいます。検索対象を二つの変数だけに固定すると、別の設定整理まで変更が広がるのを防ぎやすくなります。

コピーして使う調査用のお願い文です。

適用されるリポジトリの指針と、起動処理、設定処理、既存テストを読んでください。
この段階ではファイルを変更しないでください。

DATABASE_URLとPORTについて、次を整理してください。
・参照箇所と、現在の必須判定、既定値、型変換
・環境変数を読み込むタイミング
・接続処理と待ち受け開始の位置
・モジュールの読み込み時に発生する初期化処理
・既存のテスト実行方法

根拠となるファイルと箇所を示してください。
確認できない仕様やコマンドは推測せず、未確認としてください。

担当者が調査結果を読み、前章の仕様と既存動作の差を確定したら、実装を依頼します。既定値を廃止する変更は運用への影響があるため、練習用の仕様をそのまま本番へ当てはめてはいけません。実務では利用環境の設定状況も確認してから条件を確定します。

コピーして使う実装用のお願い文です。

以下は今回確定した仕様です。この範囲で実装とテストを作成してください。

DATABASE_URL：必須です。未設定、空文字、空白だけの値は拒否します。
接続先の到達性や認証は検証対象外です。
PORT：必須です。半角数字だけを許可し、整数で1〜65535を受け付けます。
空白、符号、小数点は拒否し、既定値は補いません。

環境変数の読み込み後、接続処理と待ち受け開始の前に検証してください。
設定を受け取る検証関数と、プロセスを終了する起動側の処理を分離してください。
失敗時は変数名と違反条件だけを表示し、設定値や元の例外全文は表示しないでください。

未設定、不正値、境界値、正常値のテストと、起動前に停止するテストを作ってください。
依存追加と外部サービスへの接続は行わず、必要なら理由を報告してください。
既存の方法で検証し、変更ファイル、実行結果、未実行項目を報告してください。

成果物では、検証関数が環境変数の対応表を引数に取り、成功時に利用可能な設定を返す構成を期待します。この分離により、テストごとに実際のプロセス環境を書き換える必要を減らせます。設定値を保持するオブジェクトを作る場合は、自動生成される文字列表現に接続先が含まれない設計も検討してください。

返ってくるエラー表示の例は、`PORT: 1〜65535の半角数字を指定してください` のような形式です。これは出力形式の提案です。入力した不正値そのものを埋め込まない点を、実装とテストの双方で確認します。最後に差分と実行結果を受け取り、報告だけで完了とせず、次章の確認へ進みます。

レビューでは、Codexが作成したテストと実装が同じ思い違いを共有していないか確認します。例えば実装が前後の空白を除去し、テストも空白付きのポート番号を正常と期待していれば、テストは通っても今回の仕様には違反します。担当者は実装から期待結果を逆算せず、確定した仕様から確認用のケースを用意してください。

`PORT` では、未設定、空文字、空白付き、符号付き、小数、半角以外の数字を拒否することを確かめます。範囲の境界では0と65536を拒否し、1と65535を受け付けることが確認対象です。`DATABASE_URL` は未設定・空文字・空白だけの値を拒否し、架空の接続文字列を受け付けることを確認します。ただし、この成功は実際の接続成功を意味しません。形式や認証まで保証したと説明しないこともレビューの一部です。

起動処理のテストでは、検証に失敗したときに接続関数と待ち受け開始関数が呼ばれないことを、テスト用の代替関数などで確かめます。検証関数だけの単体テストでは、起動順序までは確認できません。正常値では起動処理が検証済み設定を受け取ること、各モジュールが環境変数を再読して検証を迂回していないことも見ます。

秘密情報の扱いには、専用の確認を設けます。本物の認証情報を使わず、識別しやすい架空の文字列を接続先の認証部分へ入れ、別項目の `PORT` を不正にして起動を失敗させます。その際、標準出力、標準エラー、アプリのログに、その文字列や設定全体が出ないことを確認してください。例外の文字列化、設定オブジェクトの表示、上位のログ処理が漏えい経路になっていないかも読みます。

修正を依頼する場合は、「安全にしてください」と広く頼むより、違反した条件を指定する方が差分を追いやすくなります。例えば「設定例外を捕捉した箇所で接続先が表示されています。変数名と違反条件だけに修正し、再現テストを追加してください」と伝えます。担当者は修正差分と関連する検証結果を確認し、通常のレビュー手順で承認します。ここまでの手順も提案例であり、本記事で検証の成功を報告するものではありません。

期待できる効率化は、調査・転記・テスト作成の反復がどれだけ減るかに左右されます。設定参照が複数のファイルに分かれている場合、参照箇所をまとめた下書きは照合の足場になります。受け入れ条件が明確であれば、境界値や異常系のテストも依頼しやすくなるでしょう。ただし、設定仕様が曖昧なままなら、AIへの説明と出力の修正に手間が移る可能性があります。

自分の業務で確かめる際は、同じ開始時点のコード、同じ設定仕様、同じ完成条件を使って比較します。AIを使う側だけテストを省く、あるいは使わない側だけ詳細な文書を作る、といった条件差を避けてください。同一課題を順番に行うと二回目には学習効果が入るため、結果は厳密な性能比較として扱わず、工程のどこに負担が残るかを見る材料にします。

記録する項目は、仕様を整える準備、参照箇所の調査、実装、テスト作成、実行、レビュー、修正です。Codexへ渡す文脈を整理した時間も含めます。作業時間だけでなく、追加で人が見つけた仕様違反、未確認事項、レビューで読み直した箇所を残すと、単なる出力の速さでは見えない負担を把握できます。短縮率は実際に記録してから算出し、今回の提案から数値を推定しないようにします。

OpenAIの公式Cookbookは、作業段階ごとに目的、成功条件、境界を整理する進め方を紹介しています。この考え方を今回の保守へ当てはめるなら、調査結果、確定仕様、変更差分、検証記録を対応付けて残す運用が考えられます。ファイル数を増やすことより、後から判断根拠を追えることを優先してください。（出典: OpenAI Cookbook）

最初の一歩には、外部接続を伴わない練習用リポジトリで、二つの環境変数だけを対象にする方法を勧めます。不正値で待ち受け前に止まり、正常値で検証済み設定を返し、ログに架空の秘密文字列が出ないところまで確認します。その一組の差分をレビューできてから、既存アプリのどの設定へ適用するか判断すれば、変更範囲と確認負担を具体的に見積もれます。

- Iterating Development Workflows with Codex