2025年12月時点の「ぼくがいまやっている最強の開発方法」

はじめに

生成AIを使った開発手法がいろいろ出てきましたね。
私は普段、Webアプリケーション（TypeScript で client/server）、MCP Server on Cloud Run、バッチ処理（Python）などを作ることが多いです。そんな私が現在やっている「生成AIを使った開発方法」を共有します。最適解は人それぞれですが、参考になれば幸いです。

※ たぶん3ヶ月後にはまた違うやり方になっている気がします。

私の開発方法の変遷

• 2025年初め: Claude Code をメインに使用
• 2025年8月頃: Spec Driven + SubAgent な Claude Code に移行
• 2025年11月頃: OpenAI の Codex をメインに移行

この記事は誰向け？

有効そうな人:

• 多レイヤー（Client-Server-DB など）のアプリケーションを作っている人

関係なさそうな人:

• 数ファイル以内で完結するスクリプトを書いている人（例: 1ファイルのPython）
  • 日本語や英語が十分使えるなら、どうやってもだいたい上手くいくと思います

開発方法

概要

• macOS
• VSCode + Codex 拡張機能を使用（基本モデルは GPT-5.2-Codex / reasoning: xhigh）
• 最初に docs/dev/{feature_name}/{requirements,design}.md に要件定義と設計を書かせてレビュー
• 実装してもらい、lint / build / test を通す
• my-review というシェルスクリプトを用意し、コードレビューを自動化 (重要)
• （おまけ）通知用の slack スクリプトを用意すると少し便利

ポイントは my-review を用意し、「完全に独立したコンテキスト」でコードレビューさせることです。

VSCode の場合は Agent (full access)、codex-cli の場合は --dangerously-bypass-approvals-and-sandbox を付けて実行します。リスキーではありますが、「重要なデータは常にクラウドに置く」という前提でリスクを受容しています。極端な例として rm -rf <略> が起こっても1日程度で復旧できる体制があれば、現実的なリスクはかなり低いと考えています。

詳細

Prompt

以下のようなプロンプトを「スニペット管理ツール」などで管理し、必要に応じてコピペします。こうすると Claude Code でも Codex でも使えます。
「今回はレビュー回数を3回にしたい」「設計自体も my-review でレビューしてほしい」など、柔軟に変えられるのもメリットです。

以下の手順で進めてください。

1. feature name を決定、feature/{feature_name} ブランチを作成して移動する
2. docs/dev/{feature_name}/{requirements,design}.md を作成する。質問があれば私に聞いてください。最終的に私の承認をとってください
3. 開発を実施
4. lint, build, test を pass する
5. Bash で "my-review" コマンドの標準入力にメッセージを送信するとレビューしてもらえます。
   docs/dev/{feature_name}/{requirements,design}.md と開発内容を伝え、main との差分の品質・設計妥当性・潜在バグ・不足テストなどを指摘してもらってください。
   レビューは時間がかかるので Timeout は 900 秒にして実行してください
6. 妥当な改善点であれば実施し、もう一度 5. を実施する。この繰り返しは最大2回まで
7. "slack <message>" コマンドで私にメッセージを送信できるので、完了連絡をしてください

開発内容を相談した後に上記を貼り付けてもいいし、最初に要求を書いて最後に上記を貼り付けても OK です。

my-review シェルスクリプト

環境変数 PATH が通っている場所に以下のような my-review スクリプトを用意します。

#!/bin/bash

exec codex exec -c model_reasoning_effort=high 2>/dev/null "$@"

ここではあえて model_reasoning_effort=high にしています。理由は、レビューに深い思考は必ずしも要らないと感じているためです。xhigh が良い可能性もありますし、medium で十分な場合もありそうですが、high でも不満はありません。

slack シェルスクリプト（おまけ）

環境変数 PATH が通っている場所に以下のような slack スクリプトを用意します。最後のURLは自分の Slack Incoming Webhook に置き換えてください。

#!/bin/bash

MSG=$(echo $@ | tr -d '"=')
exec curl -X POST --data-urlencode "payload={\"text\":\"message: ${MSG}\"}" https://hooks.slack.com/services/T00XXX00/BDXXXXXXXX/XXXXXXXXXXXXXXXXXXXX

このスクリプトは相当昔に適当に作ったものですが、最低限の通知は来ます。「レビュー終了時の音が分かりにくい」「離席していてもスマホで気づける（家事が捗る）」などの理由で、私は用意しています。

何故これが最強なのか

コードレビュー・フィードバックプロセスが強力

一番気に入っているのは my-review によるコードレビューです。重要な指摘が普通に返ってきます。
「本当の不具合」「エッジケースの考慮不足」「テストを追加した方がいい」など、読んでいて納得できる指摘が多いです。

面白いのは、Codex（gpt-5.2-codex）で書いたコードでも、opus-4.5 で書いたコードでも、結構「重要な指摘」が返ってくることです。同じモデルで書いたコードでも指摘が返ってくるので、コードレビューは独立したコンテキストで実施するのが良いと感じます。
人間でも、昨日書いた自分のコードを今日見返すと「これはちょっとアレだな…」と思うことがあるので、AIでも同じことが起きているのかもしれません。

このプロセスを入れると10分単位で完了までの時間が延びますが、コード品質だけでなく機能面の見落としも減るので、結果的にバグが減り、リリース後の手戻りも減ります。トータルで見ると開発速度は上がります。

Codex の特性

コーディング性能が高い

Codex はコード生成能力・理解能力が非常に高いです。特に gpt-*-codex 系はコード生成に特化しているからか、コードを書く能力が高いと感じます。

sonnet/opus-4〜4.5 のときに感じたのは「気がつくとコードが重複している」「局所的には正しいが全体の整合性が取れていない」といった問題でしたが、Codex ではあまり感じません。重複が少なく、全体的に整合性が取れたコードを書いてくれます。

※ codex でも xhigh にしないで medium だと破綻しがちだったので、コード生成時は xhigh を推奨します。

淡白なコミュニケーション

opus-4.5 で requirements / design を書かせると、無駄な日本語が多かったり、過度に詳細化して後で破綻したりすることがありました。
gpt-*-codex はそういうことがあまりなく、淡白に要件定義・設計を書いてくれます。
結果的にレビューが楽です（全ては書いていないが、誤りも少ない、くらいの粒度）。

人間に迎合しない

「ここはこうなんじゃない？」と言うと、「それは違います」など、結構しっかり反論してくれます。opus-4.5 は人間に迎合しやすく「はい、そうですね」と言うことが多かったのですが、gpt-*-codex は反論するので、設計や要件定義の精度が上がる感じがします。

ここは好みの問題もありますが、毎回自画自賛したり「素晴らしいアイディアです！」と言ってくる opus を見ていると「その一言いらない…」と思うことが多かったので、私はこの淡白さが好きです。とはいえ、ちょくちょく褒めてくれる opus も嫌いではないです。

週間の容量が大きい

GPT Pro（$220?/month）に入っていると、Codex の使用量がかなり多いです。
1週間に30〜50時間くらい Codex を使っていますが、だいたい 20〜40% くらい残ります。
1〜2並列で作業していることが多いですが、それでも結構余裕があります。
※ 使い倒せていないだけかもしれません。

opus-4.5 でも手戻りが少なければ同じくらいなのかもしれませんが、opus-4.5 は後から大きく書き換える必要が出て、結果的に時間も容量も無駄にすることが多かった印象です。この辺は、アプリケーションの性質や私の使いこなし力にもよると思います。

---

GPT Plus でも Codex が使えます。コードを書かせず my-review だけ使うなら Plus でも十分なので、まずは Plus で試してみるのも良いと思います。

ちょっと足りない点

現時点で最強（私にとって）と思っていますが、足りない点もあります。

指示を無視することがある

特に要件定義や設計を作成して「私に承認を取ること」をよく忘れます。ストレートに進んでいるときは大丈夫ですが、定型指示をコピペした後に数回やり取りすると忘れやすいです。opus-4.5 ではほぼありませんでした。

まあご愛嬌かな…と思いつつ、認識違いが起きると手戻りになるので、「今回は確認が大事だな」と思うときは無駄なやり取りをせずに始めさせたり、最初に "1, 2" だけ渡すなどで工夫しています。

時間はかかる

もちろん規模にもよりますが、1ターンで10〜40分くらいかかる体感です（コードレビュー2回含む）。
40分はそこそこ大きな機能（例: 疑似ファイルシステムを作成して内部Toolとして使えるようにする）を作るとき、10分くらいは小さな機能（例: ある entity の CRUD）を作るときです。

opus の方がもう少し速い印象がありますが、コード品質やバグの少なさを考えると、Codex の方がトータルでは速いと思います。

参考

Codex の設定

通知用の音を設定しておくと、処理が終わったときに分かりやすいです（この例では Mac 用）。
通常は sandbox_mode, approval_policy, sandbox_workspace_write.network_access はこの辺が安全で使いやすいかなと思います。

意味などの詳細は https://developers.openai.com/codex/config-basic をご覧ください。

~/.codex/config.toml (2025年12月時点)

sandbox_mode = "workspace-write"
approval_policy = "on-failure"
notify = ["bash", "-lc", "afplay -v 20 /System/Library/Sounds/Blow.aiff"]
model = "gpt-5.2-codex"
model_reasoning_effort = "xhigh"

[features]
web_search_request = true
rmcp_client = true

[sandbox_workspace_write]
network_access = true

さいごに

だんだん「考えるだけでコードが書ける ≒ 自動化・定型化・アプリケーション化できる」ようになってきたなと感じています。
来年の今頃に同じ記事を書くとしたら、何を書いているのか、今から楽しみです。