バイブコーディングで本番サービスを作ってわかった、AIツール使い分けのリアル

Claude、Codex、Cursor——AIツールが乱立する今、「全部使ってます」では何も伝わらない。バイブコーディングで本番サービスを開発・運用している現場から、工程ごとのツール使い分けと、日々変わる最適解との向き合い方を共有する。

---

バイブコーディングで「本番サービス」は作れるのか？

結論から言う。作れる。

スキルシート作成サービス「Skillsheet-Port｜スキルシートポート」は、実際にバイブコーディングで開発されている。
企画・要件定義から実装・テストまで、ほぼすべての工程でAIツールを活用して開発・運用しているサービスだ。

ただし、プロトタイプと本番は別物だ。バイブコーディングで「動くもの」を作るのは簡単になった。だが本番サービスには、エッジケースの処理、セキュリティ、長期運用に耐える設計が求められる。
AIに任せっぱなしだと、この部分が必ず甘くなる。

そこで必要になるのがツールの使い分けだ。一つのAIに全部任せるのではなく、工程ごとに最適なツールを選ぶ。
前回の記事「生成AI活用をスキルシートにどう書く？」では工程ごとにツールの得意領域が違うと書いた。今回はその話を、実際の開発現場の視点から深掘りする。

---

「ITコンサルのClaude、CTOのCodex、職人のCursor」——三者三様の性格

工程別の使い分けに入る前に、各ツールの性格を整理しておきたい。ここを理解しているかどうかで、使い方がまるで変わる。

Claude——「ITコンサルタント」タイプ

日本ではバイブコーダーの間でも圧倒的に人気が高い。
理由はわかる。レスポンスが丁寧で、誰にでも伝わる言葉で返してくれる。UI/UXの提案や、仕様の規則性を整理する能力は高い。
「ここ、ユーザーからしたらわかりにくくないですか？」という指摘が自然に出てくる。

ただ、深い技術領域に入ると物足りなくなる。まるで優秀なITコンサルタントのように、万人受けする受け答えはするのだが、いざ実装レベルの複雑な判断を任せると精度が落ちる。
知識面ではCodexに遠く及ばない場面がある。

もしあなたが今Claude一本で開発しているなら、要件整理やUI設計まではスムーズに進むはずだ。
だが、設計が深くなった途端に「なんか回答が表面的だな」と感じる瞬間が来る。そこが切り替えのサインだ。

Codex——「口数の少ないCTO」タイプ

正直、日本ではまだ不人気だ。UIも取っつきにくいし、Claudeのような愛想の良さはない。
最初に触って「なんか使いにくいな」と離脱した人も多いだろう。

だが、技術を深く突き詰めると、Codexが第一選択肢になる。DB設計からAPI実装、テストコード生成まで、「面で塗る」ように広範囲の作業を一気に押し進められる。知識量も圧倒的で、フレームワークやライブラリの引き出しは他のツールを大きく上回る。

口数の少ない、ザ・エンジニアのCTOだ。技術は確かだが愛想はない。精細さにも欠ける。でもプロダクトを前に進める力は一番強い。

Claudeに慣れた人がCodexに切り替えたとき、最初は「不親切だな」と感じると思う。でも一度その知識量と面で押す力を体感すると、戻れなくなる。食わず嫌いはもったいない。

Cursor——「コード職人」タイプ

Cursorは、ClaudeやCodexのようにクリエイティブで広がりのある提案はしてこない。ゼロからアーキテクチャを考える、新しいアイデアを壁打ちする——そういう仕事には向いていない。

その代わり、指示さえ的確に出せば、ザ・コード職人のような仕事をする。「この関数のこの部分だけ直して」という局所的な修正は抜群に速く、正確だ。
コードの整理整頓、リファクタのピンポイント修正。
ただし、プロジェクト全体を俯瞰した判断や、複数ファイルにまたがる横断的な作業にはミスが出やすい。

使いどころを間違えると「全然使えないじゃん」と思うが、正しい場面で使うと手放せなくなる。
万能ナイフではなく、切れ味抜群のメスだと思ってほしい。

この三者は競合ではなく相互補完の関係にある。
コンサルタントのClaude、CTOのCodex、職人のCursor。
どれか一人で全工程を回そうとすると、必ずどこかで品質が落ちる。チームで回すから強い。

---

工程別ツール使い分け——Skillsheet-Portの場合

ここからは、Skillsheet-Portで実際に使っている工程別の割り当てを公開する。

企画・要件定義：Claude + Codex

このフェーズでは「何を作るか」を言語化する。
Claudeの出番が最も多いのがここだ。

Claudeは要件の壁打ち相手として優秀だ。「この機能、ユーザー目線で本当に必要ですか？」「このフロー、初見のユーザーが迷いませんか？」——こういう人間的な視点からの問いかけが自然に返ってくる。仕様の矛盾や抜け漏れを指摘する力も高い。ITコンサルタントとしての本領発揮だ。

ただし、Claudeだけで要件定義を完結させようとすると詰まる場面がある。「この構成でスケールするか」「このライブラリの最新仕様はどうなっているか」——こうした技術的な実現可能性の検証に入ると、Claudeの回答が急に浅くなる。
ここがCodexへのバトンタッチのタイミングだ。CTOに「これ、技術的にいける？」と確認するイメージ。

基本設計・詳細設計：Codex

設計フェーズに入ると、Codexが主役になる。

DB設計、API設計、画面遷移図——こうした広範囲にわたる設計作業は、Codexの「面を押す」力が活きる。
ドキュメント生成も速い。設計段階で大量の叩き台を出してもらい、そこから人間が取捨選択する流れだ。

ここでClaudeを使わない理由は明確で、設計の複雑さがClaudeの処理能力を超えるケースが多いからだ。
特にマイクロサービス間の依存関係や、複雑なビジネスロジックの設計では、CTOの知識量に頼る場面が多い。

実装：Codex

実装フェーズもCodexがメインだ。

Codexは「面で塗る」ように大量のコードを生成できる。
CRUD処理、バリデーション、エラーハンドリング——こうした定型的だが量の多い実装を一気に進められる。

ただし、精細さに欠けるのは実装フェーズでも変わらない。
生成されたコードをそのまま本番に入れることはない。必ずレビュー工程を挟む。
ここが「バイブコーディングで本番サービスを作る」と「バイブコーディングでプロトタイプを作る」の決定的な違いだ。

レビュー：Codex → Claude → Cursor（この順番が重要）

レビューは唯一、3ツールすべてを併用する工程だ。しかも、回す順番に意味がある。

Step 1 → Codex：まずCTOの目で全体を俯瞰する 最初にCodexでプロジェクト全体の整合性を見る。アーキテクチャ観点の問題、モジュール間の依存関係の矛盾、設計方針からの逸脱がないか。ここでは「面」で見ることが重要なので、Codexが最適だ。

Step 2 → Claude：次にコンサルの目で規則性をチェックする 全体の整合性が確認できたら、次はClaudeで細部の一貫性を見る。命名規則の統一、UI/UXの一貫性、コードスタイルの揺れ。「この変数名、他の画面と統一されていますか？」——Claudeのこういう指摘は的確だ。

Step 3 → Cursor：最後に職人の目でバグを潰す 最後にCursorでピンポイントのバグを検出・修正する。「この条件分岐、境界値でNullPointerが出ます」のような局所的な指摘は圧倒的に速い。

面で全体を見て、人の目で整合性を見て、点で精密に潰す。
この三段構えで品質を担保している。

もし「AIにレビューさせたけどバグが残る」と感じているなら、一つのツールで全部見せようとしていないか振り返ってみてほしい。
観点ごとにツールを変えるだけで、レビューの質は変わる。

単体・結合テスト：Codex

テストコードの生成は「面で押す」作業の典型だ。
Codexにテストケースを網羅的に生成させ、人間がカバレッジと重要度を確認する。

テスト設計の「どこを重点的にテストするか」の判断は人間がやる。生成されたテストケースの「量」はCodexに任せ、「方向性」は自分で決める。ここでも「AIに任せる範囲」と「自分が判断する範囲」の切り分けが重要になる。

---

「正解は毎月変わる」——固定しない覚悟を持つ

ここまで工程別の割り当てを紹介したが、正直に言うと、これは2026年4月時点のスナップショットでしかない。

各AIツールの進化スピードは尋常ではない。先月まではCursorが苦手だった横断的な作業が、今月のアップデートで改善されることもある。Codexの精細さが向上すれば、レビュー工程のClaude・Cursorの比重は変わる。

Skillsheet-Portの開発でも、この工程別の割り当てをリアルタイムで入れ替えている。
「先月はこの工程をClaudeに任せていたけど、Codexのアップデートで今月からCodexに移した」ということが日常的に起こる。

じゃあ、どう評価すればいいのか？

「試して評価しろ」とだけ言っても実践しにくいと思うので、自分がやっている方法を共有しておく。
シンプルに、同じタスクを複数ツールに投げて比較するだけだ。

たとえば新しい画面のコンポーネントを作るとき、まずCodexに投げる。
次に同じ指示をClaudeにも投げてみる。
出力の質・速度・修正の手間を比べる。これを月に1〜2回やるだけで、各ツールの得意・不得意の変化が肌感でわかるようになる。

大事なのは「どのツールが最強か」を決めることではない。
特定のツールに依存しないことだ。工程ごとに最適なツールを評価し続ける。この姿勢自体が、バイブコーディング時代のエンジニアに求められるスキルだ。

---

この知見、スキルシートにどう落とす？

ここまでの内容をスキルシートに書くとしたら、どうなるか。前回の記事で紹介した3つの型を使ってみよう。

記載例：

【AI活用】 ・開発全工程でAIツールを活用したバイブコーディング体制を構築 ・企画・要件定義：Claudeで仕様の壁打ち・UI/UX観点のレビューを実施 ・設計〜実装：Codexで設計ドキュメント・コード生成を実施。実装リードタイムを従来比約50%短縮 ・レビュー：Codex（全体整合性）+ Claude（規則性）+ Cursor（精密バグ検出）の3ツール併用体制を設計・運用 ・テスト：Codexでテストコードを網羅的に生成。テストカバレッジ方針・重点テスト領域の選定は自身が担当 ※各ツールの役割はアップデート状況に応じて継続的に評価・最適化

「全部使ってます」ではなく、どの工程で・なぜそのツールを選び・何を判断したかが読み取れる。
以前「エンジニアの自己PRを『STAR法』で構造化する」で紹介した型にも、そのまま落とし込める内容だ。

ここまで書ける人は、正直まだほとんどいない。だからこそ、今書けるだけで圧倒的な差別化になる。

---

まとめ——AIは道具、選び方がエンジニアの価値になる

ITコンサルのClaude、CTOのCodex、職人のCursor。それぞれ得意も苦手もある。

大事なのは、どの道具を、どの工程で、どう組み合わせるかを判断できることだ。そしてその判断は、AIの進化に合わせて常にアップデートし続ける必要がある。

ツールは進化する。
でも「選ぶ力」と「組み合わせる力」は、エンジニア自身のスキルだ。
まずは、今使っているAIツール一つに加えて、もう一つ別のツールを試してみることから始めてほしい。
性格の違いに気づいた瞬間から、使い方が変わる。

---

※本記事はAI活用シリーズの第2弾です。第1弾「生成AI活用をスキルシートにどう書く？」も合わせてどうぞ。