こんにちは
個人開発をしていると、地味な定型作業に時間を取られます。コミットメッセージを考える、CHANGELOG に1行足す、リリースのたびにバージョン番号をあちこち書き換える、README を直す。一つひとつは数分でも、毎回やると積み重なって、肝心の開発のリズムを削ります。
最近は、この手の作業を Codex CLI の非対話モードに任せています。codex exec にお願いすると、コマンド一発で終わる。この記事では、Codex CLI（モデルは gpt-5.5、reasoning は medium）を使って、個人開発の定型作業を自動化する手順を、コピペで追える形でまとめます。後半では、自分が普段使っている Claude Code との使い分けと、自動化で必ず気をつける点も書きます。
前提です。Codex CLI が使えること（この記事は v0.13x 系で確認）、ターミナルが使えること、git で管理されたプロジェクトがあること。モデルは gpt-5.5、reasoning effort は medium を使います。ゴールは、コミットメッセージ生成・CHANGELOG 追記・バージョン一括上げ・差分レビューの4つを、コマンドで回せるようにすることです。バージョンや細部は環境で変わるので、エラーが出たら末尾のつまずき集も見てください。
まず、Codex CLI の2つのモードを押さえる
Codex CLI には、大きく2つの使い方があります。
ひとつは対話モードです。codex だけで起動すると、画面の中で会話しながら進めます。手探りで作業するときはこちら。
codex
もうひとつが、今回の主役、非対話モードです。codex exec に指示を渡すと、会話せずに一回だけ実行して、結果を標準出力に返します。これがスクリプトや自動化に向いています。短縮形は codex e です。
codex exec "このリポジトリの構成を1段落で要約して"
定型作業の自動化でやりたいのは、後者です。毎回同じ指示を、コマンドとして打てるようにしていきます。
モデルと reasoning を設定する
最初に、使うモデルと考える深さを決めておきます。~/.codex/config.toml に書きます。
# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
model_reasoning_effort を medium にしているのには理由があります。定型作業は、難しい設計判断ではなく、決まった形の書き換えや要約がほとんどです。ここに xhigh のような重い推論を使うと、遅くなってコストも上がるわりに、結果はたいして変わりません。gpt-5.5 は medium でも定型作業には十分で、速度とコストのバランスが良い。難しい場面に当たったときだけ、その場で上げればいいんです。
approval_policy = "on-request" は、Codex がファイルを書き換えたりコマンドを実行する前に、確認を挟む設定です。慣れるまではこれが安全です。sandbox_mode = "workspace-write" は、作業フォルダの中だけ書き込みを許す設定で、フォルダの外を触らせないための安全弁になります。
設定を一時的に変えたいときは、コマンドに -c を付けて、その場だけ上書きできます。
codex exec -c model_reasoning_effort="high" "難しめのリファクタを検討して"
プロジェクトの方針は AGENTS.md で渡す
Codex は、作業フォルダにある AGENTS.md を、作業の前に読みます。Claude Code でいう CLAUDE.md に当たるものです。ここにプロジェクトの決めごとを書いておくと、出てくる結果のブレが減ります。
# AGENTS.md
## このプロジェクトについて
WordPress プラグインです。
## 方針
- コミットメッセージは日本語、1行、命令形を避ける
- バージョンは「メインPHPのヘッダー」と「readme.txt の Stable tag」を必ず一致させる
- 既存のファイル構成やフォーマットを勝手に変えない
以降の作業は、この方針に沿って動いてくれます。
ハンズオン1 コミットメッセージを生成する（初級）
いちばん簡単なところから始めます。ステージ済みの変更から、コミットメッセージを書いてもらいます。
git add -A
codex exec "git diff --staged を読んで、変更を要約した日本語のコミットメッセージを1行だけ出力して。前置きや説明は書かないで。"
出力されたメッセージを確認して、よければそのまま commit します。一気にやるなら、出力を変数で受けて渡せます。
msg=$(codex exec "git diff --staged を読んで、変更を要約した日本語のコミットメッセージを1行だけ出力して。説明や記号は付けないで。")
echo "$msg" # 中身を一度確認する
git commit -m "$msg"
最初は、必ず一度 echo で中身を見てください。たまに余計な前置きが混ざることがあるので、そのまま commit せず、目で確かめてから渡すのが安全です。
ハンズオン2 CHANGELOG に追記する（初級から中級）
次は、直近の変更を CHANGELOG.md に足してもらいます。
codex exec "直近のコミットの変更内容を読んで、CHANGELOG.md の先頭に、今日の日付つきで箇条書き2〜3行を追記して。既存の書式に合わせて、それ以外は変更しないで。"
ここで approval_policy = "on-request" が効きます。Codex が CHANGELOG.md を書き換える前に「この変更を適用していい?」と確認してくるので、提案された差分を見てから許可できます。意図しない場所を触っていないかを、ここで止めて確認する。これが、自動化と安全の折り合いです。
ハンズオン3 バージョンを一括で上げる（中級・実務向け）
ここが、個人開発でいちばん助かる定型作業だと思います。リリースのたびに、複数のファイルに散らばったバージョン番号を、漏れなく揃える作業です。
WordPress プラグインだと、メインPHPファイルのヘッダーの Version: と、readme.txt の Stable tag: を、必ず一致させる必要があります。片方だけ上げ忘れると、配信がおかしくなる。これを手でやると、地味に間違えます。
Codex に一括でやってもらいます。
codex exec "このプラグインのバージョンを 1.0.9.10 から 1.0.9.11 に上げて。対象は、メインPHPファイルのプラグインヘッダーの Version: と、readme.txt の Stable tag の2か所。両方を 1.0.9.11 に書き換えて、それ以外は一切変更しないで。"
実行すると、Codex が対象ファイルを探して、2か所を書き換える差分を提案します。on-request なので、適用前に差分を確認できます。意図どおりなら許可する。これで、上げ忘れのない一括更新が、コマンド一発になります。
変更後は、必ず自分の目で diff を確認してください。
git diff
AIが書き換えた結果を、そのまま信じない。とくにバージョンのような、間違えると配信に直結する箇所は、最後は人間が確認します。
ハンズオン4 スクリプトにまとめて1コマンドにする（中級）
ここまでの作業は、シェルスクリプトや Makefile にまとめると、もっと楽になります。リリース前の定型作業を、1コマンドにします。
#!/usr/bin/env bash
# release-prep.sh : リリース前の定型作業をまとめて実行する
set -euo pipefail
NEW_VERSION="$1"
echo "==> バージョンを $NEW_VERSION に更新"
codex exec "プラグインのバージョンを $NEW_VERSION に更新して。メインPHPの Version: と readme.txt の Stable tag の2か所。それ以外は変更しないで。"
echo "==> CHANGELOG を更新"
codex exec "直近の変更を CHANGELOG.md の先頭に、$NEW_VERSION の見出しと箇条書きで追記して。既存の書式に合わせて。"
echo "==> 差分を確認してください"
git diff
使うときは、新しいバージョン番号を渡すだけです。
bash release-prep.sh 1.0.9.11
スクリプトの出力を機械的に処理したいときは、--json を付けると、結果が1行ずつの JSON（JSON Lines）で返ってくるので、jq でパースできます。
codex exec --json "リポジトリ構成を要約して" | jq
ここまで来ると、定型作業は「番号を渡して1コマンド」になります。自動化で完全に手放したい場合は、確認を挟まない設定にもできますが、これは扱いに注意が要ります（後述）。
Codex と Claude Code を、どう使い分けているか
自分は、Codex CLI と Claude Code の両方を毎日使っています。最初は「どちらか一つでよくないか」と思っていましたが、しばらく両方を触って、向いている仕事が違うと分かってきました。ここは少し厚めに書きます。
役割分担の基本
ざっくりした分担は、こうです。
| 場面 | 向いている道具 | 理由 |
|---|---|---|
| ゼロから大きめの実装 | Claude Code（対話） | 全体の文脈を抱えて、行き来しながら組み立てるのが得意 |
| 設計を相談しながら | Claude Code（対話） | 方針を一緒に詰める対話に向く |
| 決まった形の定型作業 | Codex（codex exec） | スクリプトに組み込んで一発で回せる |
| 繰り返し・バッチ処理 | Codex（codex exec） | 非対話で、同じ指示を何度でも |
| 別の目でのレビュー | もう片方 | 書いた本人と違うモデルが見落としを拾う |
探索や組み立てのような「行ったり来たりする仕事」は Claude Code、決まった作業を「まっすぐ流す仕事」は Codex、という分け方です。
パターン1 作って、別の目でレビューさせる
いちばんよく使うのが、これです。Claude Code で書いたコードを、Codex にレビューさせます。
codex exec "git diff を読んで、セキュリティとバグの観点でレビューして。問題があれば、ファイルと行を挙げて指摘して。良し悪しの感想ではなく、具体的な指摘だけ出して。"
なぜ別のモデルに見せるかというと、同じモデルは、同じ癖で見落とすからです。書いたモデル自身にレビューさせると、自分の出力を肯定しがちになる。別の系統のモデルに渡すと、片方が当たり前だと思って素通りした箇所に、もう片方が引っかかることがあります。
一つ気をつけているのは、レビューを頼むときに「褒めなくていい、指摘だけ出して」と明示することです。そうしないと、AIは「良いコードですね」と前置きしてから、当たり障りのない感想を返しがちです。評価ではなく、具体的な問題と場所を出させる。これだけで、レビューの質がだいぶ変わります。
パターン2 探索は Claude Code、繰り返しは Codex に切り出す
新しい機能を作るときは、まず Claude Code で対話しながら形にします。あれこれ試して、方針が固まる。ここまでは Claude Code が得意な領域です。
その過程で「これは毎回やるな」という定型部分が見えてきたら、そこだけ Codex の codex exec に切り出して、スクリプトにします。さっきの release-prep.sh が、まさにそれでした。探索の中で繰り返しを見つけて、繰り返しの部分だけ Codex に渡す。考える仕事と、流す仕事を、道具で分けるわけです。
パターン3 大事な変更は、両方に投げて突き合わせる
間違えると痛い変更は、同じ指示を両方に投げて、結果を見比べることもあります。
# 同じ依頼を両方に出して、結果の差分を見る
claude -p "この関数のリファクタ案を出して" > claude.txt
codex exec "この関数のリファクタ案を出して" > codex.txt
diff claude.txt codex.txt
二つの案が一致していれば、まあ安心できます。食い違っていたら、そこが判断のいる場所だと分かる。毎回やると重いので、ここぞという変更だけにしています。
文脈の渡し方
道具を切り替えるとき、地味に効くのが、文脈の渡し方です。
Claude Code には CLAUDE.md、Codex には AGENTS.md と、それぞれが読む方針ファイルがあります。両方をリポジトリに置いて、同じ方針を書いておくと、どちらの道具でも同じ前提で動きます。ただし、片方だけ更新して、もう片方が古いまま、というズレが起きやすい。方針を変えたら両方直す、をセットにしておくのが安全です。
長い作業の途中で道具を移すときは、それまでの経緯を全部渡し直すのではなく、片方に要約させてから渡すと軽くなります。AIが一度に見られる量には限りがあるので、最初から全部を積まず、要点だけを移す。このひと手間で、切り替え後の精度が上がります。
コストの考え方
お金の話も、二刀流では効いてきます。
自分の理解では、こう分けると無駄が少ない。長くて探索的な作業は、定額で使えるところで回す。短くて機械的な自動化は、従量でも一回が安いので、そこで回す。Claude Code を対話で使うぶんは、サブスクの枠の中で動きます。一方、codex exec のような短い自動化は、一回の処理が小さいので、従量でもたいしてかかりません。
注意したいのが、2026年6月15日からの変更です。Claude を claude -p のように、プログラムから自動で呼ぶぶんは、サブスクの枠を離れて、別建ての従量に移りました。なので、claude -p を使った自動化は、以前のように定額の感覚では回せません。逆に言えば、対話の探索は Claude Code（定額のまま）、短い自動化は Codex の codex exec（従量でも安い）、と分けるのが、いまの料金体系とも噛み合います。料金や条件は変わりやすいので、最新は各社で確認してください。
一連の流れにすると
ここまでを、小さな機能追加の一周にまとめると、こんな流れになります。
- Claude Code を対話で起動して、新機能を作る（探索・組み立て）
- できた差分を、Codex にレビューさせる（
codex execで別の目を入れる） - 指摘を取り込んで、自分で diff を確認して commit
- リリース前の定型作業（バージョン上げ・CHANGELOG）は
release-prep.shで一括（Codex） - 最後にもう一度
git diffを自分の目で見て、push
作る・確認する・整える、の役を道具で分けて、判断と最終確認だけ自分が握る。これが、二刀流の基本の回し方です。
二刀流の、つまずきと注意
便利な反面、二つ使うと増える面倒もあります。
- 方針ファイルが2つに増える …
CLAUDE.mdとAGENTS.mdがズレると、道具ごとに挙動が変わる。変えたら両方直す - 同じファイルを両方で同時に触らない … 片方の編集を、もう片方が上書きすることがある。作業は片方ずつ進める
- レビュー役が同意するだけになる … 「指摘だけ」と明示しないと、当たり障りのない肯定で終わる
- 増やしすぎない … 一つで足りる作業に二つ使うと、手間とコストが増えるだけ
二つ使うのが、いつも正解なわけではありません。一つで足りるなら一つでいい。作る役と確認する役を分けたいとき、定額と従量を使い分けたいとき、そういう「分けて得」な場面でだけ二刀流にする。これが、自分の今の落としどころです。
つまずきやすいところと、危険なところを先回りします。
- 対話モードで
/clearするとモデルが既定に戻る場合がある … config.toml の model が反映されないことがあるので、自動化はcodex execを使う（exec は config を正しく読む） - reasoning が高すぎて遅い・高い … 定型作業は medium で十分。重い推論は難所だけ、その場で上げる
- 既存のフォーマットを壊す … 「それ以外は変更しないで」と明示し、適用前に必ず差分を確認する
- 確認なしの自動実行は強力だが危険 …
approval_policy = "never"と書き込み許可を組み合わせると、確認なしでファイルを変更・コマンド実行します。CI など中身を理解した環境以外では使わない。手元ではon-requestを既定にする
自動化でも、必ず人間が確認すること
ここは、プラグインを公開している身として、強めに書いておきます。
Codex に定型作業を任せると、速くなります。でも、AIが行った変更は、レビュー前の外部入力として扱うのが安全です。とくに、確認を挟まない自動実行に慣れてくると、diff を見ずに通したくなる。そこが危ないところです。
バージョン番号、設定ファイル、ユーザー入力を扱うコード。間違えると配信や安全に直結する箇所は、自動化したあとでも、commit や push の前に必ず自分の目で diff を見る。確認を挟む設定（on-request）を既定にして、確認なしの自動実行は、中身を理解しきった作業だけに限る。速くなったぶんの時間を、確認に回す。これが、AIに定型作業を任せながら、事故を起こさないための線引きでした。
次の自分に渡すメモ
Codex CLI の codex exec は、決まった形の作業を、コマンド一発に変えてくれます。コミットメッセージ、CHANGELOG、バージョン上げ、差分レビュー。一つずつ手でやっていた地味な工程が、番号を渡すだけで終わるようになって、開発のリズムが途切れにくくなりました。
gpt-5.5 は medium で、定型作業には十分です。重い推論は、難所に当たったときだけ、その場で上げればいい。作る役は Claude Code、繰り返しと確認は Codex、と道具を分ける。そして、速くなったぶん、diff を見る時間はちゃんと残す。次にリリース前の作業で手が止まったら、まず release-prep.sh に一行足せないか、を考えます。
参考
仕様やコマンドは更新が速いので、最新は公式で確認してください。