SaaS開発9ヶ月で実装の主役が3回入れ替わった話——Claude Code → Codex → Cursor Composer
非エンジニアが完全AI駆動で本番SaaSをリリースするまでの9ヶ月。
実装フェーズではClaude Code、Codex、Cursor Composerの登場で運用が3回入れ替わった。
この記事では、各ツールの限界と転機を時系列で振り返り、最終的に落ち着いた「分業」スタイルを整理する。
この記事は Codexがやばい——AI実装の主役が交代した、SaaS開発後半6ヶ月の話 のダイジェスト版です。
各ツールでの具体的なやらかし事例や、さくらクラウド × Terraform本番運用の話は、上記の完全版をどうぞ。
補足:手法は2025年6月〜2026年3月頃のモデル前提。サービス開発の本質は変わらないが、ベストスタックは流動的。
前提:前編で要件定義は詰め切ってあった
要件定義フェーズではClaude・ChatGPT・Cursorの「三すくみレビュー」で2ヶ月かけて詰め切った(前編に詳しい)。そこから実装フェーズに入る。
実装フェーズに入った瞬間、運用は変わらざるを得なかった。理由はシンプルで、ChatGPTは普段使うコードエディタに直接統合できないから。ブラウザのChatGPTに毎回コピペで投げるのはファイルが増えると現実的じゃない。
エディタに直接組み込めるAIで回すしかなくなる。ここから実装の主役交代の物語が始まる。
実装フェーズの主役交代——時系列まとめ
ざっくり時系列で整理するとこうなる。
| 時期 | 主役 | 役割 | きっかけ・限界 |
|---|---|---|---|
| 2025年7〜9月 | Claude Code | 実装の主役 | 自律的にコードを書き進める爆速さで導入。しかし広範囲実装で文脈を保てない問題が頻発 |
| 2025年9月〜10月 | Codex(GPT-5-Codex) | 実装の主役へ移管 | 多ファイル跨ぎの「面を押す力」が頭2つ抜けていた。Claude Codeの限界を超える |
| 2025年10月末〜現在 | Codex + Cursor Composer | Codex実装 / Cursorレビュー+リファクタ | Cursor ComposerリリースでCursorが実装能力を獲得。レビュー精度も跳ねた |
「Claude Codeはもう実装フェーズの主役としては太刀打ちできないのでは?」と感じるくらい、Codex導入後の差は今でも続いている。
Claude Codeの限界——3つの「やらかし」パターン
Claude Codeを実装で本格運用してすぐ、3つの問題が頻発した。これは「Claude Codeが悪い」ではなく、広範囲の実装で文脈を保ち続けられない構造的限界だと感じている。
やらかし①:自分で決めた命名規則を、忘れる
要件定義では完璧な命名を出してくれたのに、開発実装になると別ファイルで命名を忘れている。忘れているだけならまだ良くて、新しく、しかも既存と重複する命名を平然と作って実装を進める。
パッと見は綺麗で動作もする。だが後でディレクトリ全体を見ると、同じものを指す命名がファイルごとに微妙に違う。1箇所直すと関連で別の場所が壊れる。これだけで半日溶けた日もあった。
やらかし②:既存ディレクトリを無視して新規ディレクトリを作る
すでに作成済みのディレクトリ構成があるのに、Claude Codeは別の場所に新たなディレクトリを作って同じような画面コンポーネントを書き始める。
結果、画面表示やCSSの競合、ルーティング混乱、コンポーネント二重実装。動かしてみないと気づけないバグが量産される。
やらかし③:「ハードコーディングするな」と何度言っても、する
これが一番きつかった。プロンプトに書き、CLAUDE.mdに書き、それでも忘れる。短期的な記憶では指示を覚えているが、ファイルを跨いだり時間が経つと、平然と元に戻る。
タスクを細分化したりCLAUDE.mdを書き直したりしたが、行数が膨らむと同じ現象が再発する。「非エンジニアの私がClaude Codeだけで大規模なサービス開発を完遂するのは無理だ」と確信した。
Cursorも雑だった——だから「レビュー専門」に役割固定
「じゃあCursorで補おう」と思ったが、当時(2025年8〜9月頃)のCursorも実装は雑だった。
| 項目 | Claude Code | 当時のCursor |
|---|---|---|
| アウトプット速度 | 速い | より速い |
| 中身の質 | ルールを少しずつ踏み外す | より雑。型を雑に扱う、エッジケースを潰さない |
| 作業範囲が広いとき | 文脈喪失 | より顕著 |
ここで判断を切り替えた。「Cursorには実装させない、レビュー専門に固定する」。
Claude Codeで骨組みを書かせ、Cursorで品質をレビューさせる。この役割固定でCursorは安定した。Claude Codeが暴走したときのストッパーとして欠かせない存在に。
ただこれでも実装速度は理想からほど遠い。「何かが根本的に変わらないとリリースできない」と感じ始めた頃に転機が来る。
2025年9月、Codex登場で「面を押す力」が次元違いに
2025年9月、OpenAIからGPT-5-Codexがリリースされた。
X界隈は当時Claude一色。「Claude Code最高」「これからはClaude」が支配的だった。一方で本番実装の知見が深い界隈では「Codexがやばい」「ガチの面で戦うならCodex」という声が聞こえてきた。
Claude Codeの限界を感じていた私はすぐ導入した。「頭2つ抜けている」と即座にわかった。
Codexが圧倒的に違うのは、「面を押す力」——複数ファイルにまたがる広範囲の実装を、整合性を保ちながら一気に進める能力——だ。
- チャット雑談ベースの複雑な要求でも、的確に解釈
- 多数のファイルに跨って整合性を保ったアウトプット
- ディレクトリ構造を理解した上で、新機能を既存文脈に正しく統合
- Claude Codeで頻発した「実装崩壊」のフラストレーションがほぼ起きない
ただしCodexも完璧ではない。広範囲を一気に実装できる代わりに、細部の品質、エッジケース、エラーハンドリングのきめ細かさは人間の判断と他AIのレビューが必要だ。
ここで前編で詰めた三すくみレビューの真価が、また現れる。
実装フェーズの新・三すくみ——Codex × Claude × Cursor
新しい運用はこう変わった。
- Codexが叩き台(広範囲の実装)を一気に書く
- **Claude(Code)**でドキュメント整合性・命名規則・要件との照合をレビュー
- Cursorで実装目線の粗・エッジケース・エラーハンドリングをレビュー
- 修正はCodexに戻す
- 再度2〜3でレビュー
| フェーズ | 要件定義(前編) | 実装(後編) |
|---|---|---|
| 叩き台 | Claude | Codex |
| レビュー1 | ChatGPT | Claude(Code) |
| レビュー2 | Cursor | Cursor |
| 最終判断 | 自分(PO) | 自分(PO) |
役割は違うが構造は同じ。1つのAIに任せきらない。3者で叩き合って、最後は自分で判断する。
これに落ち着いてから実装速度と品質が両立し始めた。そしてここで、前編で詰め切った要件定義の真価がようやく出てきたと感じる。細部までドキュメント化されているからCodexに渡すコンテキストが揃っている。レビュー役のClaude/Cursorも要件定義に照らして指摘が出せる。
結局、ドキュメントが整っているから、AIが正しく仕事をする。
▶ 各ツールでの具体的なやらかし事例や、Cursor Composer登場後の運用変化、さくらクラウド × Terraform本番運用の話はこちら → Codexがやばい——AI実装の主役が交代した、SaaS開発後半6ヶ月の話
2025年10月末、Cursor Composerでまた形勢が変わる
10月末、CursorがComposerをリリース。複数ファイルにまたがる広範囲の実装やリファクタリングをCursor上で自律的にこなせる新機能だ。
これが大きかった。「実装は雑、レビュー専門」と固定していたCursorが、Composerで実装精度が格段に上がる。Codexほどではないが、Claude Codeより確実に上。レビュー役としても精度がさらに跳ねた。
私の運用では、Cursorはレビューとリファクタリングで必須のポジションを確立した。逆にClaude Codeは実装の主役からは外れ、ドキュメント生成や命名・設計レビューのCLI版として限定的に使うことが多くなった。
AIコーディングの世界は本当に数ヶ月単位で勢力図が変わる。1つのツールに張り付くこと自体がリスクだと体感した。
9ヶ月を終えて学んだこと
- 1つのAIに任せると、必ずどこかで詰まる。実装フェーズも要件定義と同じだった
- AIごとに役割を固定する。実装はCodex、レビューはCursor、ドキュメント整合はClaude
- 役割は時代で変わる。Cursor Composerで一夜にして変わった。次に何が変わるかは誰にもわからない
- 「太刀打ちできない」と感じたらすぐ乗り換える。X界隈の空気ではなく自分の手と現場の声で判断する
- 要件定義が整っていないと、どのAIを使っても結局詰まる
AIコーディングは分業が正解。「AIで一人で全部できる」と言うエンジニアもいる。私も最初はそう思っていた。だが本気で本番運用するSaaSを9ヶ月作り切ってわかった。できる。ただし1つのAIでは無理だ。
スキルシートに「Cursor使用」と1行書くだけでは差がつかない時代
最後に、若手エンジニアに伝えたい一番大事なこと。
AIで爆速に作れる時代だからこそ、「どのAIを、なぜ、どう使い分けたか」を語れるエンジニアが単価で抜ける時代になる。
「AI使えます」ではなく、こう書けるかどうか。
| NG(1行) | OK(分業を語る) | |
|---|---|---|
| 記載 | 「Claude / Cursor 使用」 | 「実装はCodex、レビューはCursor、ドキュメント整合はClaudeで分業。命名規則の整合性問題はClaudeでクロスチェックすることで早期検出体制を構築」 |
| 印象 | AI活用の一人 | AIを分業させて判断できる人 |
スキルシートに「Cursor 使用」と1行書くだけのエンジニアと、AIをどう分業させてどんな成果を出したかを語れるエンジニア。案件単価で差がつくのは、間違いなく後者だ。
▶ 完全版ガイドはこちら → Codexがやばい——AI実装の主役が交代した、SaaS開発後半6ヶ月の話
▶ 無料でスキルシートを作ってみる → https://www.skillsheet-port.com/