Codexに任せる作業と人が確認する結果｜能力・権限・完了の見分け方

Codexへ依頼するときは、「できる能力があるか」「今回の環境でアクセスできるか」「結果を検証できたか」を分けて考えます。コード案が出ること、ファイルが変更されること、公開先が更新されることは別の結果です。

モデル名と作業環境を分ける

Codexは、エディターなどの作業環境でコードの説明や変更、レビューを支援するエージェントです。公式IDEガイドは、開いたファイルを文脈に含めること、差分を確認すること、作業を委譲する流れを案内しています。特定の旧モデル一つと同じ意味ではありません。

一方、使えるファイル、ツール、ネットワークはその環境と設定に依存します。ChatGPTにコードを貼る場合と、リポジトリを開いたCodexで作業する場合を同じ前提にしないでください。

依頼と証拠を対応させる

「直しました」という文章だけでは、テストや公開まで終わったとは判断しません。逆に一度失敗したことだけで、長時間の作業ができないという一般的な結論も出せません。

要件が曖昧なときの依頼例

「CSV取込で空行を無視したい。ヘッダーは必須、不正な日付は行番号付きでエラーにする。既存の列名は変えない。空行、ヘッダー欠落、不正日付の三ケースで確認してください」と伝えます。

この例では、「使いやすくする」より採否を判断しやすくなります。仕様が決まっていない点は確認事項に分け、AIが補った内容を既存仕様と混同しません。

停止時に確認する順序

権限不足、ツールエラー、利用上限、要件不足を別々に記録します。最初のエラー、最後に成功した操作、未完了の要件を短く保存し、その一件を再開します。内部の思考や最適化が原因だと観測なしに断定しません。

変更前のコピーかGitのチェックポイントを持ち、意図しない変更は差分単位で戻します。認証情報の発行、第三者への送信、本番変更などは、対象と影響を確かめたうえで判断します。

完了の判断

コードとテストと公開結果を別欄にまとめれば、能力への印象ではなく確認結果から次を選べます。残っている作業を明記した報告の方が、検証されていない「全部完了」よりも、引き継いで再開しやすくなります。