「Vibe Codingで商用サービスを作ったら、どうなるか？」
この問いに、明確な答えを持っている人は少ない。
今、Vibe Codingが話題だ。AIとノリでコードを書く。プロンプトを投げれば、アプリが出来上がる。個人開発のアプリ、SNSで作ったゲーム、週末に立ち上げたWebサービス——「AIでこれ作った！」が毎日のようにタイムラインに流れてくる。
いい時代になった。コーディングがノリで書ける時代だ。
私も、AIとともに開発をしている。 Claude Codeで、クライアントのシステムを構築している。
しかし、実際のクライアントワークでAIを使えば使うほど、感じることがある。
これは、Vibe Codingではない。
私の立ち位置
大前提を整理する。
私はプロジェクトマネージャーを生業としている。言語化、設計思想、仕組み化——これが私の仕事の軸だ。
PMBOKという国際基準をもとにプロジェクトを管理し、そこにAIの要素を加えたPMBOK-AIというフレームワークで活動している。ざっくり言うと、AIを1人のプロジェクトメンバーとして扱うことだ。
AI社員には要件定義の支援、設計、コーディング、テストを実施してもらっている。実稼働のデータはAI社員の実稼働データはこちらで公開している。
ではこのやり方は、世間で言うVibe Codingと同じなのか？
私の開発フロー
実際の開発フローを公開する。
Phase 1：要件定義（人間 × 人間）
クライアントのビジネスモデルを聞く。仕組みを理解する。何を実現したいのか、なぜそれが必要なのかを深掘りする。
ここはAIとやるというより、従来通りの「人と人」の仕事だ。
クライアントのビジネスが本当に成り立つのか。その目的は達成できるのか。これを真剣に会話する。コンサルティングに近い。
AIには、この「空気」は読めない。クライアントの表情、声のトーン、言葉の裏にある不安——これを汲み取るのは人間の仕事だ。
Phase 2：基本設計（人間主導）
- 機能一覧の作成
- テーブル設計
- アーキテクチャの決定
ここも、今まで通りな気がする。
データ構造はビジネスの根幹だ。テーブル設計を間違えれば、後から取り返しがつかない。機能一覧はクライアントとの合意事項だ。これをAIに任せるのはリスクが高すぎる。
Phase 3：詳細設計（人間 × AI）
ここから、Claude Codeとの対話が始まる。
ビジネスロジックや処理フローを、Claude Codeと対話しながら詰めていく。「この機能はこういうデータの流れで処理する」「例外パターンはこう扱う」——設計の解像度を上げていく作業だ。
AIの力が活きる場面。人間1人で考えるよりも、対話することで設計の抜け漏れが見つかる。
Phase 4：実装（AI主導）
詳細設計が完成したら、GitHub Issueに実装手順を書き出す。
- 実装手順のシミュレーションを行う
- 問題なければClaude Codeにコーディングを依頼
- テストもAI側で実施
コーディングとテストは、全部AI側で実施してもらう。 これがVibe Codingに一番近い工程かもしれない。
Phase 5：レビュー（人間主導）
AIが作ったコードとテスト結果を、基本設計書と要件定義書をもとに私がチェックする。
- 要件を満たしているか
- 設計と実装が一致しているか
- テストが正しくビジネスロジックを検証しているか
問題なければマージ。問題があればAIに修正を依頼。
このサイクルを、機能ごとに回していく。
Vibe Codingと何が違うのか
フローを見て、「結局AIでコード書いてるんでしょ？」と思うかもしれない。
確かに、コーディングのフェーズだけ見れば似ている。しかし、全体像は全く違う。
| 観点 | Vibe Coding | 私のやり方 |
|---|---|---|
| 要件定義 | 自分の頭の中 | クライアントとの合意 |
| 設計 | なし or AIに丸投げ | 人間が基本設計、AIと詳細設計 |
| コーディング | AIに書かせる | AIに書かせる（同じ） |
| テスト | 動けばOK | 設計書との照合 |
| レビュー | なし or 軽く確認 | 要件定義書ベースの構造的レビュー |
| 責任 | 自分だけ | クライアントへの責任 |
| インフラ | 無料プラン | 商用環境 |
コーディングの部分は同じ。それ以外が全部違う。
「責任」という視点
ここが一番の違いだと思っている。
お金をもらうことは、責任だ。
クライアントは希望のソフトウェアをお金で購入している。動く前提で購入している。 動かなければ、そもそも買わない。
個人開発なら、バグがあっても自分が困るだけだ。動かない機能があっても、「まあいいか」で済む。
商用開発では、「まあいいか」は許されない。
- この機能は本当に動くのか
- クライアントの要件を満たしているのか
- 現場で使われたときに期待した効果が出るのか
作って終わりではない。使われて、効果が出るまでがプロジェクトだ。
だから私は、自分が知らない機能がない状態を保つ。すべての機能が動くことを、何回もテストする。AIが書いたコードを、設計書と照合する。
この「責任」が、Vibe Codingとの決定的な違いだ。
Vibe Codingで起こりうる事故シナリオ
「Vibe Codingで商用サービスを作ったらどうなるか？」——この問いに、具体的な事故パターンを示す。
事故1：認証周りのセキュリティホール
AIにログイン機能を作らせて、動いたからデプロイ。しかし、JWTトークンの有効期限が設定されていなかったり、リフレッシュトークンの無効化処理が欠けていたりする。動いているけど安全ではない。 個人プロジェクトなら問題にならなくても、顧客データを扱うシステムでは致命的だ。
事故2：データ整合性の崩壊
テーブル設計をAIに任せて、外部キー制約やユニーク制約が適切に設定されていない。運用開始後に、同じユーザーが重複登録できてしまう、削除済みのデータを参照してエラーが出る——テスト段階では見つからず、本番データが貯まってから発覚するタイプの問題だ。
事故3：無料インフラの突然死
VercelやSupabaseの無料枠でサービスを公開し、順調にユーザーが増える。ある日、無料枠の制限に引っかかってサービスが停止。クライアントのビジネスが止まる。 自分のサイドプロジェクトなら「アップグレードすればいい」で済むが、クライアントのシステムでは許されない。
事故4：AIが書いたテストの偽陽性
AIにテストも書かせる。テストは全て通る。しかし、テスト自体がビジネスロジックの要件を正しく検証していない——テストが通っているのに仕様と違う動きをする。 テストカバレッジの数字に安心して、設計書との照合を怠った結果だ。
いずれも、設計とレビューのプロセスが入っていれば防げる問題だ。Vibe Codingの「コードを書く」部分に問題があるのではない。その前後の工程が抜けていることが問題なのだ。
商用環境は無料では動かない
もう1つ、見落とされがちな違いがある。インフラだ。
個人開発では、無料のデータベースや無料のホスティングで立ち上げることが多い。Vercelの無料プラン、Supabaseの無料枠、Netlifyの無料ティア——個人プロジェクトなら十分だ。
しかし、商用環境で無料はあり得ない。
無料枠で公開したサービスにユーザーが増え、ある朝アクセス上限に達してサービスが止まる。クライアントのビジネスも、そこで止まる。
インフラにかかるコストの内訳
商用環境で最低限必要な投資を具体的に挙げる。
- ホスティング：アクセス数やSLAに応じた有料プラン。月1万円〜が目安
- データベース：バックアップ・リストア機能付きのマネージドサービス。月数千円〜
- ドメイン・SSL：独自ドメインとSSL証明書。年間数千円
- 監視・アラート：障害を即座に検知する仕組み。Datadogやクラウドネイティブの監視ツール
- バックアップ：日次バックアップとリストア手順の整備。障害が起きてから考えるのでは遅い
- セキュリティ対策：WAF、DDoS防御、脆弱性スキャン。規模に応じた段階的導入
合計すると、最低でも月数万円。クライアントのビジネス規模が大きくなれば、それに比例して増える。
この投資を「コスト」と見るか「保険」と見るかで、商用開発の品質が決まる。
クライアントのビジネスがそのシステムに依存する以上、インフラにもお金と責任が必要だ。 無料プランのデータベースにクライアントの顧客データを入れるわけにはいかない。
AI開発の限界を知ること
ここまで、AIを活用した開発フローを語ってきた。しかし、AIにも明確な限界がある。これを理解していないと、Vibe Codingでも商用開発でも失敗する。
- AIはビジネス判断ができない。 どの機能を優先するか、この要件は本当に必要か——これはクライアントと人間が決めること
- AIは「前提が間違っている」ことを指摘しない。 間違った設計書を渡せば、間違ったまま完璧にコードを書く
- AIの出力には必ず人間のレビューが必要。 一見正しく見えるコードにも、エッジケースの見落としやセキュリティホールが潜む
- AIは運用の文脈を持たない。 「このシステムは月末にアクセスが集中する」「この機能は法改正で来年変わる」——こうした運用知識は人間が補う
AIは優秀なツールだが、判断の主体にはなれない。 これを忘れた瞬間、AIで作った」システムは「誰も責任を取れないシステム」になる。
Vibe Codingを否定しているわけではない
ここまで「違い」を強調してきたが、Vibe Codingを否定するつもりはない。
むしろ、Vibe Codingの存在は歓迎している。
- プログラミングのハードルが劇的に下がった
- 「アイデア→プロトタイプ」の速度が爆速になった
- エンジニア以外の人もソフトウェアを作れるようになった
これは間違いなく良いことだ。
そして、Vibe Codingで個人開発を経験した人が、次のステップとして商用開発のやり方を学ぶ。その橋渡しが必要だと感じている。
Vibe Codingから商用開発へのステップ
Vibe Codingで開発経験を積んだ人が、クライアントワークに進むとき。何が変わるか。
Step 1：設計書を書く
Vibe Codingでは設計書がないことが多い。頭の中のイメージをそのままAIに伝える。
商用開発では、設計書が全ての品質を決める。 AIへの指示の解像度が上がり、出力の品質が安定する。そして何より、クライアントとの合意の証拠になる。
具体的なアクション：
- 最低限、機能一覧とテーブル設計書を作る
- クライアントと書面で合意を取る
- AIへの指示は、設計書をベースに出す
Step 2：テストを構造化する
「動けばOK」から、「仕様通りに動くか」に基準を変える。
AIにテストを書かせるのはVibe Codingと同じ。しかし、テストが設計書の要件を検証しているかを確認するのは人間の仕事だ。
具体的なアクション：
- テストケースを設計書の要件から逆算して定義する
- AIが書いたテストコードを、要件との対応表で照合する
- 正常系だけでなく、異常系・境界値のテストを意識する
Step 3：レビューのプロセスを入れる
自分で書いて自分でデプロイ——Vibe Codingならこれでいい。
商用開発では、コードと設計書の照合というレビュー工程を入れる。リバースエンジニアリングで仕様書を逆生成し、元の設計と比較する。
具体的なアクション：
- 機能ごとにPull Requestを作り、設計書と照合してからマージする
- AIにコードから仕様書を逆生成させ、元の設計書と比較する
- 第三者レビュー（別のAIモデルや外部エンジニア）も有効
Step 4：インフラにお金をかける
無料プランを卒業する。商用グレードのインフラを選び、セキュリティとバックアップに投資する。
具体的なアクション：
- 有料のマネージドサービスを選定する（Vercel Pro、Supabase Pro、AWS RDS等）
- バックアップとリストア手順を運用開始前に確立する
- 障害時の連絡フローを決めておく
この4つのステップを入れるだけで、Vibe Codingは商用開発になる。
私の流儀
名前はどうでもいい。重要なのは、クライアントの要件を満たし、現場で使われ、効果が出るシステムを作ることだ。
要件定義は人と人で向き合い、設計は人間が責任を持ち、コーディングはAIの力を最大限に使い、テストとレビューは仕組みで回す。ノリではなく、仕組みの中でAIを動かす——これが、Vibe Codingの先にある私のAI開発の形だ。
PMBOK-AIの詳細はPMBOK-AIとはで、実際のプロジェクト適用事例はPMBOK-AIを自社サイト構築に適用した結果をご覧ください。AI開発での失敗と教訓はAI活用で痛感した失敗と教訓で解説しています。
AI開発やプロジェクトマネジメントについてのご相談はお問い合わせからお気軽にどうぞ。