Claude Code × Codex 二刀流でコードを書かずにアプリを作った話

はじめに

AIエージェントの使い方を模索する中で、実際にアプリをゼロから作ってみることにしました。

試行錯誤の末たどり着いたのが、Claude CodeとCodexを組み合わせる「二刀流」です。今のところ、これがうまく回っています。

自分がコードを直接書くことはありませんでした。

この記事では、二刀流のワークフロー、環境構築、指示書の設計について紹介します。

なお、個人開発が前提なので、大規模なチーム開発では考え方が変わる部分があります！

作ったもの

動画をアップするだけで、AIがノートを自動生成する業務支援アプリです。動画を意味単位のチャンクに分割し、各チャンクから代表的なフレームを画像として抽出、内容を要約してまとめてくれます。

パイプライン: ファイル取り込み → 音声抽出 → フレーム抽出 → 文字起こし → タイムライン整列 → AIフレーム選定 → AIノート生成 → リファインメント → DOCX出力 → Google Drive連携 → 一時ファイル削除

技術スタック:

Frontend: Next.js + TypeScript
Backend: FastAPI + Python
Infra: Google Cloud（Cloud Run, Firestore, GCS）, Vercel
AI: Gemini

技術の幅が広く、フロントエンド、バックエンド、インフラ、AI、ドキュメント生成とそれぞれ異なる知識が求められます。これを一人で全部手書きするのは現実的ではありませんが、AIエージェントとの協業なら形にできます。

⚔️ 二刀流（dual wielding）とは

2種類のAIエージェントを使い分ける開発スタイルです。今回はClaude Code（Anthropic）とCodex（OpenAI）を組み合わせました。

Claude Code — 人間と機械のインターフェースとして、対話を通じた設計・指示・意思決定の支援を担当。

Codex — コード実装やレビュー、バグ修正など、自律的にタスクを実行する役割を担当。

性能の差が語られることもありますが、どちらが上ということではなく、得意分野が違う印象です。

そしてAIはどんどん進化するので、明日にはこの使い分け方が最善ではなくなっている可能性もあります。

大事なのは、人間が意思決定者であるという役割分担です。

なぜ2つ使うのか。1つのAIだけだと、そのAIの思考の癖やバイアスに気づけません。2つのAIにそれぞれ独立して意見を出させることで、片方が見落としている論点がもう片方から出てきます。人間のペアプログラミングやコードレビューと同じ発想です。

🖥️ 作業環境: ターミナル4分割

開発中はターミナルを4分割してAIエージェントを4セッション並列で使っていました。内訳は以下の4つです。

開発作業用 Claude Code × 2 Git Worktreeで異なるタスクを同時進行させます。それぞれがサブエージェントを使うこともあり、増やすほど目を配る範囲が広がります。マージやコンフリクトの解消も大変です。だいたいAIがやってくれますが、正しく処理されているかの確認は人間の仕事です。自分は2つくらいがちょうどいいバランスでした。

会話用 Claude Code 作業リポジトリとは別のディレクトリで立ち上げます。CLAUDE.mdでキャラ設定をして、設計の壁打ちやちょっとした調べ物に使います。MCPやCLIで社内ツールと連携させることで、個人秘書のような存在になっています。作業用のClaude Codeがコードを書いている間や、Codexが実装している間の待ち時間に活躍します。

別班 Codex メインの開発とは独立したタスクをまるっと任せます。リサーチや技術検証など、ミッションを与えて、自律的にタスクを完遂してもらいます。今回はOSSモデルの性能比較で大活躍しました。

📝 指示書を育てる

AIエージェントを使った開発で避けて通れないのが、エージェントへの指示書をどう設計するか、という問題です。Claude CodeのCLAUDE.md、CodexのAGENTS.md、settings.jsonによるhooks・権限制御、スキル、コマンド、メモリーなど。手段は複数あります。

GitHubには長大なベストプラクティスをまとめたリポジトリがたくさんありますが、自分はなるべく短く書く派です。長くすればそれだけコンテキストウィンドウを消費します。そしてドキュメントはコードと乖離していきがちです。hooksでメンテする方法などもあるとは思いますが、現状のコードベースを常に正として扱い、コードから読み取れないルールだけに絞る、というやり方に落ち着きました。

育て方はシンプルです。

まずは最低限のルールだけ書いて使い始める
「これ何回も同じこと言ってるな」に気づく
それを指示書やスキルに追記する（ユーザーレベルにするかプロジェクトレベルにするかも都度判断）
繰り返しが減り、AIが賢くなったように感じる

今回の開発では、CLAUDE.mdにClaude CodeとCodexの協業ルールを書いていました。

1. まずClaude自身で方針を考える
2. codex exec -s read-only でCodexの意見も聞く
3. 合意を得てから codex exec -s workspace-write で実装

read-onlyは意見・レビューだけ。コードは触らせません。workspace-writeで初めてコードを書かせます（権限設定には注意が必要です）。このルールをCLAUDE.mdに書いておくだけで、Claude Codeが自動的にCodexと連携してくれます。つまり、人間がいちいち「Codexに聞いて」と指示しなくても、Claude Codeが自分の判断でCodexを呼び出すようになります。

なお、2026年3月30日にはOpenAIから公式プラグイン（codex-plugin-cc）がリリースされ、/codex:reviewや/codex:rescueといったスラッシュコマンドでClaude CodeからCodexを呼び出せるようになりました。codex execが毎回使い切りなのに対し、プラグイン版はセッションを維持して途中経過の確認や前回の続きからの再開ができます。場面や好みに合わせて使い分ければ良いと思います。

🔧 開発の進め方

ここからは、設計から実装まで、実際にどう進めたかをステップごとに紹介します。

🎤 Step 1: 音声入力で要件を吐き出す

最初にやったのは、plan.mdに作りたいもののイメージをとにかく書き出すことです。きれいな文章を書く必要はありません。音声入力で一気に喋るだけです。

「えっと、ウェビナーの録画をアップしたら自動でメモ作ってくれるやつが欲しくて、スライドも一緒に抜き出してほしくて...」

こんな荒い状態でも、あとからAIに「これ整理して」と渡せば、構造化された要件定義にまとめてくれます。曖昧な部分は「ここはどういう意味ですか？」と聞き返してくれるので、対話しながら固めていきます。

💬 Step 2: AI同士に議論させる

ここが二刀流の面白いところです。discussion.mdというファイルを用意して、2つのAIにそれぞれ意見を書き込ませます。

やり方はシンプルです。まずClaude Codeに設計レビューを書き込ませる。次にCodexの意見も聞いて書き込ませる。お互いの主張をぶつけさせて、自分が最終ジャッジを下す。

実際のやりとり（抜粋）:

Claude Code: --regionをMVPに含めるべきという主張、理屈はわかるがUXの面で疑問がある

Codex: 任意機能としてでも最初から設計に入れておくべき

Claude Code（撤回）: 「閾値調整で吸収できる」と言い切ったのは楽観的だった。Codexの落とし所に同意する

お互い遠慮なく意見を出して、一方が自分の誤りを認める場面もありました。

ポイントは過剰に同調させないことです。放っておくとAIは相手の意見に同調しがちです（Sycophancyの問題）。「お世辞抜きで回答を書き込んで」「本当にそう思ってる？」と本音を引き出す声かけが大事でした。

議論の結果はfixed_plan.mdにまとめます。アーキテクチャ、技術スタック、ディレクトリ構成、パイプライン設計。ここまでコードは1行も書いていません。

課題もあります。議論が白熱するとドキュメントが長大化しがちで、人間が全部読むのは現実的ではなくなります。AI同士の議論→重要な意思決定のみ人間にエスカレーション→結論の提示まで自動化できるはずで、ここは改善の余地があると感じています。

🔁 Step 3: 実装ループ

設計が固まったら、以下のループをひたすら回します。

Claude Codeでタスクの実装方針を整理
Codexにセカンドオピニオン（codex exec -s read-only）
自分がジャッジ
Codexが実装（codex exec -s workspace-write）
Claude CodeとCodexがそれぞれレビュー、結果を突き合わせる
→ 1に戻る

Claude Codeだけだと設計も実装も同じAIになり、セルフレビュー状態になります。Codexを挟むことで別の視点でのチェックが入るのが二刀流のメリットです。

実際にループを回していると、それぞれのAIに傾向があることに気づきます。片方がスコープを広げすぎて必要以上に作り込もうとすることもあれば、もう片方が細部を見落としていることもある。1つのAIだけで完結させていたら、こうした偏りに気づくのは難しかったはずです。

人間でも、自分で書いたコードを直後にレビューすると甘くなることがあると思います（バイアス）。AIも同じです。

codex execはワンショット実行なので、実装したセッションとレビューするセッションが完全に切れます。同じツールでも、コンテキストが切れているだけで別の目になります。

このループの中で人間がやっているのは、3の「ジャッジ」です。2つのAIの意見を聞いて、どちらの方針で進めるかを決める。技術的に正しいかどうかだけでなく、今の優先度やプロダクトの方向性を踏まえて判断します。「技術的にはAが正しいけど、今はBでいい」。こうした判断はAIからは出てきにくいので、人間が進む方向を補正してあげる必要があります。

🏭 内製という選択肢

今回はAIエージェントの使い方の検証がメインでアプリを作ることは主目的ではありませんでしたが、アプリのアイデア自体は以前からあったものです。

参考までに、AIが今ほど発達していなかった頃にこのアプリを外注していた際のコストをAIに試算させてみました。

実装見積もり: 500〜1,000万円
仕様書作成だけでさらに数百万
開発期間も数ヶ月〜半年はかかるのが一般的

さらに、出力されるノートの品質やUIは使いながら細かく、時には大胆に調整し続ける必要があります。「ここ、なんか使いにくいな」という感覚は仕様書には落とせません。その業務を知っている人にしか分からないからです。

加えて、AI周りの技術スタックは移り変わりが非常に速いです。外注で大きな投資をしても、すぐに改修が必要になります。実際、今回の開発中にも文字起こしのエンジンを丸ごと入れ替えています。こうした変化に即応できるのは、自分たちの手元にコードがあるからこそです。

つまり誰かに丸投げでは作れない。かといって、一人で全部手書きする必要もない。業務を深く知っていて、AIの出力に対して「これでいいのか」と判断できる人が、自分たちの手で作る。コードを書く力ではなく、判断する力が求められる時代です。

AIエージェントの登場で、その判断力さえあれば内製が現実的な選択肢になりました。

実際、今回のアプリは他の業務の合間に進めて、約1週間で形になりました。SIerに依頼する場合は品質保証や保守体制も含まれるため単純比較はできませんが、今回のようなプロトタイプ段階では内製のスピードが活きました。

📌 まとめ

やったことをまとめると:

🛠️ 環境を整える — ターミナル4分割、Git Worktreeで並行開発
📝 指示書を書く — CLAUDE.mdやAGENTS.mdを育てる
🗣️ 喋る — 音声入力で要件を伝える
💬 議論させる — discussion.mdでAI同士にぶつけさせる
⚖️ 判断する — 自分は審判として最終決定
⚡ 実装させる — Claude Codeが全体をハンドリングし、Codexが実装とレビュー

人間がやるのはコードを書くことではなく、技術選定の判断、優先度の決定、品質のジャッジ。プロダクトマネージャーに近い動き方です。今回の検証を通して、「このアプリ、アイデアはあるけど作れない」で終わっていた時代は、少なくとも個人開発の領域では終わりつつあるなと強く感じました。

AIエージェントの二刀流、ぜひ試してみてください。