こんにちは。AI漬けの毎日を送っている橋本です。
今日はAIを使って普段どういった開発フローで開発を進めているか紹介したいと思います。
まず前提として、Asialでは様々なAIツールを導入しているのですが、その中でも自分は Claude Code をメインで使っています。
最初は個人用のMax20xプランを契約して使っていたのですが、途中から会社が一括でチームプランを契約してくれることになり、現在はチームプランで開発しています。
チームプランに移って経費精算をしなくてよくなったので非常にハッピーだったのですが、使い始めると個人プランのときよりトークンの上限が厳しくて、Claude Code 単体だと普通に開発してるだけでトークンが枯渇するようになってしまったんですよね。
「これは何か工夫しないとマズいな…」と思って色々試した結果、たどり着いたのが今回紹介する Codex と組み合わせて分業させる構成です。
実際に導入してみると、トークン消費を抑えられるだけじゃなく、開発体験自体もかなり良くなったので、オススメがてら今回記事にしてみました。
まだ本格的にAIエージェントを使った開発を始めていない人でも雰囲気が伝わるように、細かい設定の話は省いて、「実際どんな流れで開発しているか」と「なんでそうしてるか」を中心に書いていきます。
そもそも Claude Code と Codex CLI って？
ご存知の方は読み飛ばしていただいて構いません。
Claude Code は Anthropic が提供している CLI ベースの AI コーディングツールです。
VS Code 拡張や Web 版もありますが、自分は基本ターミナルで動かしてます。
個人的には話してて一番しっくりくるというか、こっちの意図を察してくれる感じが好きでこっちをメインに使っています。
Codex CLI は OpenAI が出している同じく CLI ベースの AI コーディングツールです。こちらも実装やリファクタを自律的にやってくれるタイプですね。
好みもあるかもしれませんが、個人的には Codex の方が実装力に優れている印象です。ただ、相性もあると思うのですが、直接話してるとイライラすることもしばしばあるため、Claude Code を介して接する今のやり方が気に入っています。
現在使用してるプランでは Codex の方がトークンの上限が若干ゆるいので、重めの作業を Codex に任せるようにしています。
この2つを組み合わせて使う、というのが今回の記事の主題です。
大まかな開発フロー
「〇〇って機能を実装して。内容は〇〇な感じで。」と Claude Code にお願いしたとき、自分の環境ではだいたいこんな流れで実装が進みます。
- 要件整理と設計 — 依頼内容を Claude Code が読み解いて、変更対象のファイルや影響範囲・作業の重さを確認します
- 実装の委譲 — 実装作業は Claude Code 自身ではなく、Codex に丸投げしています。軽めなら Claude Code 1人が指示を出し、重めなら自動でチーム編成して複数 Claude → 複数 Codex で並列実装します（詳しくは後述）
- エラーチェックと自動修正 — Codex が一通り実装を終えた段階で、テスト・型チェック・Lint のエラーが残っている場合、Codex がゼロエラーになるまで自律的に修正します
- コードレビュー — 実装を依頼した Claude Code が自身とは別のサブエージェントを立ち上げ、そちらのサブエージェントに品質とセキュリティの観点でレビューしてもらいます
- 完了報告 — エラーゼロとレビュー対応が両方そろった段階で、メインの Claude Code が完了報告をしてくれます
要するに、Claude Code は設計と監督に専念して、実装の手はほぼ動かさない という構成です。
この流れを見ると「なんだか冗長じゃない？」って感じるかと思うのですが、やってみると意外といい感じなんですよね。
なんで Claude = 設計者 / Codex = 実装者にしてるのか
冒頭で書いたとおり、もともとは「Claude Code のトークンが枯渇しがちだったので、重い処理は Codex に逃がそう」っていう、半ば応急処置として始めた構成です。
実際にこのスタイルで運用してみると、Claude Code 単体で実装してたときにありがちだった以下のような問題点に自然と対応することができて、今ではこの構成が当たり前になっています。
問題1：コンテキストが重い作業ですぐ埋まってしまう
Claude Code に実装からテスト実行まで全部任せてると、tsc のエラー、Vitest の出力、ESLint の警告みたいなログがどんどんコンテキストに溜まっていきます。
長めのタスクになってくると、本来覚えていてほしい設計の前提とか、「このプロジェクトでは class を使わない」みたいなルールをポロッと忘れてしまうことがあって、これがけっこうストレスでした。
Codex に「実装」と「エラー修正ループ」を完全に任せることで、テスト出力みたいな重たい情報は Codex 側のコンテキストで完結してくれます。Claude Code 側には「終わったよ、ゼロエラーだよ」という結果しか返ってこないので、Claude Code のコンテキストが埋まるのを防ぐことができます。
問題2：Claude Code のセルフレビューは見落としだらけ
Claude Code に自分の書いたコードをレビューさせると、思い込みで見落としが起こったり、甘い判断になることがよくあります。「ちゃんと書きました、レビュー OK です」とか自信満々に言ってくるんですが、別のエージェントに見てもらうとボロボロ問題が出てくる、なんてこともしょっちゅうあります。
実装を Codex に任せて、レビューは別の Claude Code（依頼を受けた本人ではなくサブエージェント）に任せる構成にしたところ、第三者目線の指摘がちゃんと入るようになりました。
問題3：1つのツールで全部やると得意・不得意がそのまま出る
冒頭でも触れましたが、個人的には Claude Code は会話と設計の理解が得意で、Codex は実装そのものの精度が高い印象です。
1つのツールでやろうとすると、どうしても不得意領域までそのツールに任せることになって、結果として品質が安定しない場面が出てきます。
役割を Claude=設計、Codex=実装と分けることで、それぞれの得意領域だけを使えるようになって出来上がるコードの質がよくなった気がしています。
Codex シリーズのスキル紹介
Claude Code には、特定の作業を別のツールやエージェントに委譲するための仕組みとしてスキルという機能があるのですが、今回の構成で開発を進めるにあたって、Codex への委譲をスキル化して、用途ごとに使い分けてます。
今回はそのうち、よく使っている3つをざっくり紹介していきます。
codex-analyze — 分析・調査を委譲するスキル
Codex を read-only モードで起動して、コードの調査・レビュー・アーキテクチャ分析なんかをやってもらうスキルです。read-only なのでファイルを書き換える心配がなく、安心して広めの範囲を見てもらえます。
呼び出しはこんなイメージです。
このリポジトリの認証周りがどう実装されてるか調べて「このリポジトリのこの機能、どんな実装になってる？」「依存関係的にここ変えて大丈夫？」みたいな調査タスクで重宝してます。
Claude Code でも grep や Read は使えるんですが、広い範囲をざっと俯瞰してもらうような用途だと、Codex に丸投げした方が早いことが多いです。
codex-exec — 実装を委譲するスキル
実際に実装を進める一番の肝になってくるスキルです。「この機能を実装して」「このファイルを作って」みたいな指示を、Codex に丸ごと渡して書かせます。
たとえばこんな感じで Claude Code に投げると、内部で Codex に指示書が渡って実装が走ります。
ユーザー一覧ページを作って。テストも一緒に書いてね。Claude Code 側でやることは、設計方針の整理と、Codex への指示書づくり。実際にファイルを書くのは全部 Codex 任せです。
新規ファイルを作るときはユニットテストもセットで作ってもらうように指示書に含めるのがマイルールで、これだけで「あとからテストが無いことに気づく」みたいな悲しい事態がかなり減りました。
codex-fix — エラー修正ループを委譲するスキル
実装完了後の「テスト通して」「tsc エラー直して」「lint も直して」っていう一連の作業を、Codex に自律的に回してもらうスキルです。
呼び出しはすごく単純で、こんなノリで OK です。
ゼロエラーにしてこれだけで Codex 側が pnpm test / tsc --noEmit / pnpm lint を順番に回して、エラーが出たら直して、また回して…をエラーがゼロになるまでループしてくれます。
正直、このスキルが個人的にはいちばん効果を感じてます。
エラー修正って、エラーを読んで、原因を特定して、ファイルを直して、また実行して…の繰り返しになりがちで、Claude Code にやらせるとあっという間にコンテキストを圧迫してトークンもゴリゴリ消費していくんですよね。
これを Codex 側に閉じ込めることで、Claude Code 側は「ゼロエラーになったよ」っていう最終結果だけ受け取れます。
エラーがゼロになるまで Codex が勝手にループしてくれるので、Claude Code と自分はひたすら待つって感じです。この間にトイレに行ったり飲み物を取りに行ったりしています。
ただ、Codex がテストを通すためにズルをすることもしばしばあるので、Claude Code によるコードレビューが必須になってきます。
3つの共通点をまとめると、Claude Code 側のコンテキストを節約しつつ、Codex の自律性をフル活用する という設計思想です。
「重い作業は Codex に任せて、Claude Code は脳みそ（設計）に専念する」っていう発想を、スキルとして固定化しているわけですね。
重めの実装は自動でチーム化される
ここまで紹介したのは「Claude Code 1人が Codex に投げる」シンプルな構成ですが、依頼内容によってはもう一歩スケールします。
自分の環境では、Claude Code が「これは重めの作業だな」と判断したら、自動でチーム編成に切り替わる ようにしています。具体的にはこんな条件です。
- 互いに非競合な独立タスクが3つ以上ある
- 変更対象がフロントエンドとバックエンド、あるいは複数の独立モジュールにまたがる
- 大規模なリファクタリング
こういう作業を投げると、構成が自動でこんな形にスケールします。
Claude（メイン・指揮官）
├─ チームエージェント1 → codex-exec → Codex
├─ チームエージェント2 → codex-exec → Codex
└─ チームエージェント3 → codex-exec → Codexメインの Claude Code が "指揮官" になって、複数のサブ Claude を束ねつつ、それぞれが Codex に実装を委譲する、という階層構造です。
ここまで自動でやってくれると、たとえば「ユーザー管理機能まるごと実装して」みたいな依頼でも、フロントは A、API は B、DB マイグレーションは C、みたいに自然と並列で走ってくれます。
チーム化するとどうしてもトークンの消費量が多くなってしまうので、「いつでもチーム化」ではなくて「重いときだけ自動でチーム化」というバランスが、運用上ちょうど良い感じです。
まとめ
いかがでしたでしょうか。今回は Claude Code と Codex を「設計者と作業者」として組み合わせて使う開発環境についてざっくり紹介しました。
ポイントを振り返ると、
- 実装は Codex に委譲して、Claude Code は設計・監督に専念する
- エラー修正ループも Codex 側に閉じ込めて、Claude Code のトークン消費量を抑える
- レビューは必ず別のサブエージェントに任せて、セルフレビューは避ける
- 重い作業のときは Claude Code が自動でチーム化して、複数 Codex が並列で実装する構成にスケールさせる
といったところでしょうか。
Claude Code をすでに使ってる人も、これから触ってみようかなって人も、ぜひぜひ参考にしてみてくださいね。
ではまた！