AIをチームとして運用する：ClaudeCode × Codex × ChatGPTで回したAndroid開発フロー 🔄

はじめに 👋

AIを開発に使う中で、最近強く感じているのは、1つのAIに全部任せるより、役割を分けた方がうまくいくということです。

今回、Androidアプリの改善対応の中で、ChatGPTで論点整理、ClaudeCodeで実装プラン作成、Codexで実装、さらにClaudeCodeとCodexでレビューを往復させる、というフローを試しました。

題材はOOM改善でしたが、実際に得られた学びは、個別の実装テクニック以上に「AIをどう開発フローに組み込むか」にありました。

この記事では、その進め方と、やってみて見えたメリット・ハマりポイントをまとめます。

---

背景：AIに「全部やらせる」より、役割分担させた方が安定した 🧩

今回の対応では、最初からCodexに実装させたわけではありません。

まずやったのは、ChatGPTで論点整理とプロンプトの叩き台を作ることでした。
当時、最初のプロンプトとしては、たとえば次のように背景・仮説・依頼内容を整理したものを作っていました。

• 特定条件でOOMが発生している
• 原因として全件読み込みが疑わしい
• 解決策候補としてページネーション導入を検討したい
• 原因分析と改善案の提案をしてほしい

つまり、最初の役割は「いきなり実装させる」ことではなく、問題設定を崩さないプロンプトを作ることでした。

この時点で感じたのは、AI活用では「最初の問いの立て方」がかなり重要だということです。
実装以前に、何を前提に、何を比較し、何をアウトプットとして求めるかを整理しておく必要がありました。

---

今回の開発フロー 🔄

実際には、次のような流れで進めました。

ポイントは、AIを1つの万能ツールとして扱わず、役割ごとに分けたことです。

• ChatGPT: 論点整理、プロンプトの壁打ち、レビュー補助
• ClaudeCode: 実装プラン作成、設計観点のレビュー
• Codex: 実装、修正対応

この流れにしたことで、最初から最後まで1つのAIに任せるより、かなり安定して進められました。

---

先にプロンプトを作る工程が意外と重要だった ✍️

今回の開発で、思った以上に効いたのがこの工程でした。

ClaudeCodeにいきなり「調べて」「考えて」と投げるのではなく、
まずChatGPTでプロンプトを壁打ちして、以下のような要素を整理してから渡しました。

• 背景
• 発生している問題
• 仮説
• 比較したい対策
• 欲しいアウトプット

この一手間を入れることで、ClaudeCodeから返ってくる内容の粒度がかなり安定しました。

特に有効だったのは、メモリ解消策を複数案で考えさせる前提を入れたことです。
「ページネーションが正しい前提」で始めるのではなく、比較対象を持たせた状態で考えさせることで、最終的にその案を採用する理由も説明しやすくなりました。

---

ClaudeCodeには、まず実装プランを書かせた 📝

プロンプトを整えた後、ClaudeCodeにやらせたのは実装そのものではなく、実装プランの作成でした。

ここで出てきた内容はMarkdownにして固定し、その後のレビューの基準にしました。
実際、今回も「問題の全体像」「原因」「短期対応」「中期対応」「今後の作業プラン」のような構造で整理されたプランを先に作り、その内容を精査してから実装に進めています

この進め方にして良かったのは、次の点です。

• AI同士で前提を共有しやすい
• 人間がレビューしやすい
• 実装途中で論点がぶれにくい
• 変更差分を追いやすい

Markdownを中間成果物として持っておくと、設計と実装の間にひとつ安定したレイヤーができます。
結果として、コードレビューの前に設計レビューを成立させやすいのが大きかったです。

---

実装プランは「そのまま採用」ではなく、往復して精査した 🔍

実装プランが出てきたあと、それをそのまま使ったわけではありません。

実際には、

• Codexに読ませて実装観点で違和感がないか確認する
• ChatGPTにも読ませて、構造や抜け漏れを確認する
• 必要ならClaudeCodeにプラン自体を修正させる

という往復を何度か行いました。

この工程が良かったのは、「設計レビュー」と「実装レビュー」を分けて考えられたことです。

たとえば、実装プランの段階で見つかるのは次のような論点です。

• 方針として本当に筋が良いか
• 短期対応と中長期対応が混ざっていないか
• 影響範囲の切り分けが妥当か
• メモリ削減の見積もりが楽観的すぎないか

こうした話は、コードが出てからやるより、プランの段階で潰しておいた方が圧倒的に楽でした。

---

実装はCodexに任せた ⚙️

プランがある程度固まったら、実際の実装はCodexに任せました。

ここで重要だったのは、Codexに「自由に実装させる」のではなく、レビュー済みのMarkdownプランを前提として渡したことです。

この状態だと、Codexはかなり安定して動きます。

逆に、前提が曖昧なまま実装させると、

• 本来やらなくていい範囲まで変更する
• 影響範囲を広げすぎる
• 実装は合っているが意図とずれる

といったことが起きやすいです。

つまり、Codexをうまく使うには、実装能力そのものよりも、事前にどれだけ前提を固定できているかが効いていました。

---

コードレビューはClaudeCodeとCodexの間で何度か往復させた 🔁

実装が出た後も、すぐに終わりにはしていません。

次にやったのは、Codexが書いたコードをClaudeCodeにレビューさせることでした。
そのレビュー結果を受けて、さらにCodexに修正させ、必要ならもう一度ClaudeCodeで見直す、という往復を何度か行っています。

このやり方の良さは、人間がレビューする前に論点をかなり減らせることです。

実際のレビューでは、たとえば次のような観点が出やすくなります。

• 実装方針とコードの整合性
• 一時対応と本対応の切り分け
• 変更の副作用
• 将来の拡張や移行を考えた構造の妥当性

この工程を挟むことで、最終的に人間が見るときには「設計意図のズレ」や「明らかな粗い部分」がかなり減っている感覚がありました。

---

こういうフローが成立した前提には、Androidチームでのskills整備があった 🏗️

今回のフローがうまく回った背景として、見落とせないのがAndroidチームで進めていたskillsの整備です。

ClaudeCodeやCodexを開発に組み込むには、単にモデルが賢いだけでは足りません。
どのように調査し、どのように提案し、どの粒度でレビューさせるかが、ある程度運用として整理されている必要があります。

今回のような進め方ができたのも、ClaudeCode / Codexを活用しやすいように、Androidチーム側でskillsや運用パターンが整えられていたことが大きかったです。

自分自身がその整備を直接進めたわけではありませんが、チームで整えられた土台があったことで、今回のような「設計→実装→レビュー」のフローを実践しやすくなっていたと感じています。

個人的には、AI活用は「良いモデルを使うこと」以上に、チームとして再現可能なフローに落とし込めるかどうかが重要だと思っています。

---

得られたメリット ✅

今回の進め方で特に良かったのは、次の3点です。

設計と実装を分けてレビューできる

実装プランを先に固定したことで、
「この設計で行くのか」と「このコードで良いのか」を別々に見られるようになりました。

AIごとの得意な役割を活かせる

• ChatGPTは論点整理や壁打ち
• ClaudeCodeは設計・レビュー
• Codexは実装

という分業がかなりハマりました。

人間レビューの前に粗い論点を減らせる

AI同士の往復で、少なくとも一次レビュー相当の観点はかなり消化できます。
結果として、人間はより本質的な判断に集中しやすくなりました。

---

ハマりポイント ⚠️

もちろん、何でもうまくいくわけではありません。

特に大事だと思ったのは、Markdownプランの粒度です。

ここが雑だと、その後の全部がずれます。

• Codexの実装がぶれる
• ClaudeCodeのレビューもずれる
• 人間が最後に調整する量が増える

また、AI同士で往復できるとはいえ、途中で前提が変わったら必ず人間が整理し直す必要があります。
放っておくと、もっともらしいけれど前提の違う議論が進んでしまいます。

---

まとめ 🎯

今回の学びはかなりシンプルでした。

AIは、1つのツールとして雑に使うよりも、役割を分けてチームとして運用した方が強いです。

今回の流れをまとめると、次のようになります。

• ChatGPTで問題設定とプロンプトを整える
• ClaudeCodeで実装プランを作る
• Markdownで固定してレビューする
• Codexで実装する
• ClaudeCodeとCodexの間でレビューを往復させる

この流れにすると、単純に実装速度が上がるだけでなく、
設計の安定性やレビューのしやすさまで含めて改善できる感覚がありました。

特に、影響範囲が広い改修や、性能・メモリ・構造のバランスを考える必要がある対応では、このやり方はかなり相性が良いと思います。

---

おわりに 👋

今回の題材はOOM改善でしたが、本質的には「AIをどう開発フローに組み込むか」の話でした。

今後も、AIに何かを“やらせる”というより、
AI同士と人間の間に、どんなレビューサイクルを作るかを意識して進めていきたいと思っています。

同じようにAIを実務開発に組み込んでいる方の参考になればうれしいです。