AIコーディングエージェントに振る作業、手元に残す作業
振るのは、往復が多くて判断が少ない作業です。relmeaでは次の3種類に絞っています。
- テストの赤を緑にする作業
- ビルドの修正
- 検査ゲートの改修
振らないのは、要件、設計、合否判断、検品です。ここまで振ると、作った側が自分の出来を採点することになり、確認の意味がなくなります。
費用の面の理由もあります。Codexの利用はChatGPTのプラン枠で賄われ、Claude側の週次の利用上限を消費しません。手数の多い工程を別の枠に逃がせるので、Claude側は判断と検品に回せます。なお、金額の比較は記録が無いため書きません。
別ベンダーのCLIに振る
- テストの赤を緑にする
- ビルドの修正
- 検査ゲートの改修
- 共通点は、往復が多く判断が少ないこと
手元に残す
- 要件と設計
- 合否の判断
- 検品（作った側に採点させない）
codex exec の呼び方と、入力待ちで62分止まった失敗
呼び出しの基本形は次のとおりです。
codex exec -s workspace-write --skip-git-repo-check -o <最終報告.md> "<ブリーフ>" < /dev/null > run.log 2>&1-s workspace-write：作業フォルダ内への書き込みを許可します。下見だけなら-s read-onlyにします--skip-git-repo-check：git管理外のフォルダでも動かします-o <最終報告.md>：最終報告をファイルに書き出させます< /dev/null：標準入力を閉じます。次の失敗を受けて必須にしました> run.log 2>&1：出力をすべてログに残します
標準入力を閉じずに起動して、62分空回りした
2026年9月12日、最初の1本を < /dev/null を付けずにバックグラウンドで起動しました。すると「Reading additional input from stdin...」と表示されたまま入力待ちになり、62分間何も進みませんでした。
問題は、進捗が無音になっても気付く仕組みが無かったことです。以後は < /dev/null を必ず付けています。
詰まったときの切り分け
- ログイン切れは、ログに
401 Unauthorizedが出ます。再ログインは人が行います。OAuthの同意は人の操作だからです - 旧版のCLI（0.133.0）は、モデル一覧の読み取りに失敗し、待機のためのトークンを35k消費しました。更新後は3kでした。CLIは最新にしておきます
直す前
- 標準入力を閉じずにバックグラウンドで起動した
- 「Reading additional input from stdin...」のまま62分空回りした
- 進捗が無音でも気付く仕組みが無かった
直した後
- 呼び出しの末尾に
< /dev/nullを付ける - 出力はログに、最終報告はファイルに残す
- この付け方を以後は必須にした
ブリーフに入れる4つの項目
codex exec に渡すブリーフ（作業指示）には、次の4つを必ず入れます。
- 守らせる規律：ソースを変えてよいか、モックを置ける層はどこか、skipや
expect(true)を使わないこと、設計文書や進捗管理の置き場に触らないこと、コミットしないこと - 完了条件：何が揃えば終わりか
- 赤から緑までの証拠の取り方
- 最終報告の型
テストが効いている証拠は「変異」で取らせる
テストが本当に効いているかは、変異で確かめます。変異とは、わざと壊すコード変更のことです。ブリーフには次の順番を書きます。
- 先に変異を入れ、テストが緑のままであることを確かめる（ここが穴なので記録する）
- テストを書く
- 同じ変異で赤になることを確かめる
- 変異を戻す
ブリーフの数字は、相手が直してくることがある
ブリーフに書いた細部の数字は、相手が実物を読んで訂正してくることがあります。3回振って、2回はこちらの数え間違いをCodexが直してきました。ブリーフの数字は、確認前の仮置きとして扱うほうが安全です。
手元で必ずやり直す3つの確認
Codexの最終報告は、合否の根拠に使いません。手元（Claude Code側）で、次の3つをやり直します。
変異を自分で入れ直す
Codexが「赤になった」と報告した変異を、手元で入れ直し、赤になることを再実測します。注意点が2つあります。
- zshでは変数が単語分割されないので、変異の適用は関数にまとめます
- 元に戻すときは
git checkoutではなく、ファイルのコピーを使います。git checkoutで、未コミットの変更まで消した事故があったためです
全テスト・型検査・lintをサンドボックスの外で回す
Codexのサンドボックスの内側では、tsxのプロセス間通信が listen EPERM で塞がれます。その結果、一時ディレクトリを掃除する既存テスト2本が落ちます。つまり、サンドボックス内の結果はそのまま合否に使えません。
そのため、全テスト・型検査・lintは、サンドボックスの外で回し直します。
別の検品役に合格させてからコミットする
ソースを触った差分は、別のコンテキストで動く検品役に見せ、合格してからコミットします。検品役は中位モデルで動かしています。狙いは、作った側と採点する側を分けることです。検査役の報告そのものを疑う設計は、AIエージェントのレビュー見落とし対策に書きました。
- ブリーフを書く規律・完了条件・赤から緑の証拠の取り方・最終報告の型を入れる
- codex exec を走らせる標準入力を閉じ、ログと最終報告をファイルに残す
- 変異を入れ直す手元で自分で入れて、赤になることを再実測する
- サンドボックスの外で回す全テスト・型検査・lintをやり直す
- 検品役に見せる別のコンテキストで合格してからコミットする
実際に振った記録
画像処理ツールのテスト整備（2026年9月12日）
社内の画像処理ツール（MCPサーバー）のテスト整備で、3本を振りました。
- テスト追加（2件分）：4分47秒・65.8kトークン
- 指摘の是正（2件分）：5分18秒・62.0kトークン
- 重大指摘の回帰テスト：2分30秒・25.7kトークン
3本とも、別のコンテキストの検品役が初回で合格にしました。ただし3本だけなので、成功率のような数字は出せません。
セミナースライドの閉じの改修（2026年9月12日）
自社サイトのセミナースライドの最後の部分も、Codexに実装させました。中身は次の3点です。
- 申込みボタン1つ、メルマガ、文字リンク3つの構成にする
- 25%・50%・75%まで見たかを記録する計測イベントを足す
- ボタンの見た目が特定の要素の中にしか効いておらず、メルマガのボタンがただのリンクで出ていた不具合を直す
差分は1ファイルで、37行追加・37行削除でした。検品はClaude側で行っています。grep、node --check、横幅400pxでの実際の表示、計測の区切りを実際に走らせる確認の4つです。
逆向きの使い方：レビュー役と画像生成
レビュー役として使う
実装を振るだけでなく、レビュー役として使うこともあります。2026年9月21日17時、メール配信の仕組みの再チェックをCodexに頼みました。既存テスト20件はすべて成功していましたが、模擬APIで再現させると、次の3件が残っていました。
- 同時に申し込まれると、開始イベントが2件出て、両方が
started: trueになる - 購入後メールで、送信APIの成功1件に対して、台帳の保存が0回になる
- PCが15日止まった後に復帰すると、3日目・7日目・14日目の3通を1時間おきに続けて送る判定になる
報告には「通常の成功と、障害・同時実行時の問題の解消は別に判定する必要がある」と書かれていました。確認範囲も明記されていて、架空データと模擬APIでの再現であり、本番で重複メールが届いた確認ではない、という書き方でした。
同日17時30分から19時にかけて修正し、テスト37本が全て緑、変異13本すべてで赤になることを確かめています。送る・送らないの規則の詳細は、購入後フォローメールの自動化の記事にまとめました。
画像生成にも使う
2026年10月3日には、電子書籍の漫画ページを1ページずつ生成させました。実測で1ページあたり111〜364秒、3〜4万トークンでした。気を付けている点は次のとおりです。
-i（画像の添付）は、後ろの引数を全部画像として読み込みます。そのためプロンプトは標準入力で渡します。引数に置くと「No prompt provided via stdin」になります--full-autoは廃止されたため、-s workspace-writeを使います- 呼び出し側のスクリプトは、終了コードが0でも画像ファイルが無ければ失敗として止めます。画像を開いて壊れていないかも確かめます
- 生成後のセリフは、手元のAIが画像を読んで一字一句照合します
実装でも画像でも、考え方は同じです。別のAIの「できました」は出発点として受け取り、合否は手元で自分で確かめてから決めます。