Zenn
📘

Vibe codingで構築するSaaS, 0→1設計・実装オレオレベストプラクティス

に公開
AI
Supabase
React Router
GitHub Copilot
Vibe Coding
tech

はじめに

0xkoheです。
AIを使った開発(Vibe coding)を通して数ヶ月で新規サービスを約10万行のコードを書き、作った経験からの新規Webサービス作成においてのオレオレベストプラクティスを記録しておきます。
※2025/04~05くらいまでの記録です。変化が激しすぎるので、今では違う方法が良いところもあると思います。
(今回はマルチテナントサービスです)

Vibe coding（または vibecoding）とは、人工知能（AI）に依存するプログラミングのパラダイムである。この手法では、人間が問題を数文で大規模言語モデル（LLM）に対してプロンプトとして提示し、それに応じてLLMがソフトウェアを生成する。これにより、プログラマーの役割は手動でのコーディングから、AIが生成したソースコードの指導・テスト・修正へと移行する。
Vibe codingの擁護者たちは、この手法によってソフトウェア工学に必要とされる高度な訓練やスキルがなくても、アマチュアのプログラマーがソフトウェアを開発できるようになると主張している。
この用語は、2025年2月にAndrej Karpathyによって提唱され、翌月には「スラングおよび流行語」として、Merriam-Webster辞典に掲載された。
https://en.wikipedia.org/wiki/Vibe_coding

今回、Vibe Codingに使ったのは主にGitHub Copilot Agentです。
Rate Limiteがない時代だったので、できる限りコスパよく実装したいという思いからです。
(Roo Codeでも全然良いと思います、今だとClaude Codeもプラスで使います)

なのでGitHub Copilotが使えるプランを契約しておけば、基本この記事の内容は実行可能です。
(お好みでClaude,ChatGPTを契約してもいいと思いますが、GitHub Copilotのプランを契約しておけば、https://github.com/copilot から好きなモデルを選んで会話できるのでお得です。あまり知られていませんが）


とりあえずAIに合った技術選定をすれば8~9割のタスクは消え去ります。
ただ、残りの1~2割はエンジニアしかできないタスクが残っているので、よく言われているエンジニア不要論や、非エンジニアがVibe codingで作れちゃうというのは懐疑的な立場です。

テックリーダーがチームメンバーのコードレビューや、ひたすら難しいところの設計や、セキリティについて考えまくる感覚と大分近いです。
そして、相談相手(AI)がいるのでハマって時間がとけると言うことが減っていくので高負荷な思考をする状態をKeepする感じになります。

AIコーディングアシスタントは定型作業の約70％を肩代わりし、開発を効率化しました。しかし、残る30％――複雑な要件理解や保守性の高い設計、エッジケース対応など――は依然として人間のエンジニアリングが求められます。

You’ve seen how AI coding assistants like Cursor, Cline, Copilot and WindSurf have transformed how software is built, shouldering much of the grunt work and boilerplate–about 70%.1 But what about that last “30%” of the job that separates a toy solution from a production-ready system? This gap includes the hard parts: understanding complex requirements, architecting maintainable systems, handling edge cases, and ensuring code correctness. In other words, while AI can generate code, it often struggles with engineering.
Beyond Vibe Coding by Addy Osmani より

技術選定

基本的には有名所を使っておくとよいです。記事や参考データなどがWeb上に大量に落ちているので、そいういうものはAIが得意です。

  • React Router v7 with fs-routes
    • SPA
    • Tailwind
  • Cloudflare for SPA
  • Supabase

※SPAは好みです。
Supabaseは非常にAIと相性が良いです。あたかもフロントからDBを操作しているかのようにコードを書くことができるので、コンテキストがそのフロントのファイル(ないしはディレクトリ）で完結します。

https://x.com/kiwicopple/status/1916813407350911292
Supabaseが凄まじい勢いでユーザー数を増やしているのも納得できます。

また、ディレクトリの設計もAI時代の開発では、できる限りそのページの情報は同じディレクトリ配下においておくのがよいと思っています。
コンテキストがそのディレクトリで完結することが重要です。それに伴い、共通化を従来と比べてしないようになりました。
意思決定基準としては抽象的になるのですが、「迷ったら」しないということにしています。
明らかにしたほうが良いケースはもちろんします。

これに fs-routesがうまくマッチしています。

├── routes/
│   ├── index.tsx        → "/"
│   ├── about.tsx        → "/about"
│   ├── blog/
│   │   ├── route.tsx    → "/blog"
│   │   └── component1.tsx

このように blogディレクトリ配下にroute.tsxというものがあり、それが、そのページのメインのファイルとなります。それ以外のものはアクセスできるものとして配置されないので、Componentsとして作ることができます。
ですので、そのページの情報は基本的にそのフォルダの中に埋め込まれることになります。

コンテキストが完結すること以外にも、AIに書かせれば1000行程度のコードであれば難なく作ってしまうので、工数削減のための共通化をするということは従来と比べてそこまでしなくてもいいかなと。

また、後述しますがUniCopyというものを使う際にもこれが役立ちます。
https://zenn.dev/kooooohe/articles/93c2dc09b289f4

AI群

AIを使って開発するのは、このメタファーが一番しっくり来ています。
https://x.com/GOROman/status/1920613567226896568

それぞれの特性を理解し、適切にタスクをふっていくことが求められます。
例えば、デザインであればClaude Sonnet 4にお願いしよう、token数が多い場合はGeminiに一旦任せよう などです。
※複業のメンバーとチームを組んだことがある人はその感覚に近いと思います。

  • (1) GitHub Copilot Agent
    • Claude Sonnet 4
    • Gemini 2.5 Pro
  • (2) Roo Code
    • DeepSeek
      • 安さを求めたいときに使います
    • Claude Sonnet 4
    • Gemini 2.5 Pro
  • (3) ブラウザ
    • Claude
    • ChatGPT
    • Gemini

copilot-instraction.md 、.roorules は
https://github.com/kinopeee/cursorrules
などを参考にして最初は作ります。
これは、AIに指示を出していく中で同じことをしているなと感じたときに、どんどん更新していきます。
これ重要です。

ブラウザ版のAIにデータを食わすときは、ディレクトリ配下の情報をすべて1つのテキストとしてCopyをしたかったのでUniCopyという拡張機能を作り、これを使っています。
一般公開しているのでよかったら。

  • 0->1デザイン
    • (3) Claude
    • ここまではブラウザのClaudeが早くて安い
  • 1ファイルあたりのコードが500行超える -> 分割
    • (1,2) Claude
  • ロジック実装
    • (1,2) Claude
    • (1,2) Gemini
  • 雑魚い大量処理
    • (2)DeepSeek,Gemini, Claude
      • 例: 全ページスマホ対応
    • Boomerang mode
      • 扱いが若干難しいですが、本当に大量の処理を行ってくれます。
    • まだ、GitHub Copilot Agentだとスピードが遅かったり、途中で止まったりするので暴走機関車でもある Roo Codeに任せるのがおすすめです。

https://x.com/roo_code/status/1923368288869924970
27h かけてLravelからNext.jsに移行したという報告もあるほどです。

  • エラー処理

    • (1,2,3) Claude,Gemini

  • テーブル設計、全体構想、その他設計等壁打ち

    • (3) GPT o3,4

GitHub Copilot Agentのリクエスト数の上限は上げておくと良いです。

0->1 開発イメージ

画面一覧、機能詳細

まずは画面一覧、機能詳細をざっくりします。
サービスアイディアを入れれば、画面一覧とそれぞれの機能について考えてくれるGPTsを作り、最初の最初はこれを使います。
https://chatgpt.com/g/g-67838acdb6bc81919c8c73dde40696fe-saas-blueprint-architect-xin-gui-saasyao-jian-she-ji-akitekuto?model=gpt-4o

ファイル一括生成

Copilot Agentにお願いし、下記のような上記の情報から ファイルだけ を作成します。
おそらくClaudeだと中身まで作ってしまいがちなので、GeminiやらGPT4.1を使うのが良いかなと。

├── routes
│   ├── _auth.admin.login/
│   │   └── route.tsx           // 管理者用ログイン画面
│   ├── _auth.client.login/
│   │   └── route.tsx           // テナントユーザー用ログイン画面
│   ├── admin.dashboard/
│   │   └── route.tsx           // 管理者用ダッシュボード（全体利用状況・統計）
│   ├── admin.tenant-management/
│   │   └── route.tsx           // テナントの登録・編集・停止・契約状況の管理
│   ├── admin.user-management/
│   │   └── route.tsx           // 全テナント横断のユーザー管理（有効/無効切替、ロール設定）
│   ├── admin.role-templates/
│   │   └── route.tsx           // 権限テンプレートの作成・適用・履歴管理
│   ├── admin.system-settings/
│   │   └── route.tsx           // 点検・修理・見積に関する通知タイミングの管理設定
│   ├── client.dashboard/
│   │   └── route.tsx           // テナント内の点検・修理予定、未対応タスクを確認する画面
│   ├── client.devices._index/
│   │   └── route.tsx           // 所有機器一覧画面（検索・フィルタ対応）
│   ├── client.devices.$deviceId/
│   │   └── route.tsx           // 機器の詳細表示（基本情報、点検履歴、修理履歴）
│   ├── client.calendar/
│   │   └── route.tsx           // スケジュール・カレンダー画面（予約・点検・修理の統合管理）
│   ├── client.users/
│   │   └── route.tsx           // 自社メンバーの招待・編集・権限管理画面
│   └── client.devices-register/
│       └── route.tsx           // 機器の新規登録および情報更新画面（QRコード出力含む）

デザイン実装

ざっくりすべて実装

ファイルが出来上がったら、GPTsに作ってもらった画面一覧、機能一覧の情報を渡して一気に中身ををすべて作ってもらいます。

デザインはClaudeが得意なのでそこにおまかせします。

ページごとの改善

ページごとのデザインをみて、それに指示を与えて改善していきます。
私の場合は、このときにテキストをコピーしてブラウザのClaudeで直します。
(スピードが早いのとせっかく課金しているので）

このときにコード量が500~700行を超えてくるととたんに、重くなったり取得が途中できれるようになるはずです。
その際は、Copilot Agentに同じフォルダ内にコンポーネント分割をするようにお願いします。
そうすると、全体のコード量が多くなってもAIが処理を継続してれるようになります。
この分割が非常に重要です。

+α

おそらくこの作業をしていると、足りないページや考慮漏れのものがでてくるのでそれが尽きるまで、
ページの追加、デザインの実装をしていきます。

テーブル設計

コアとなるテーブル設計は、o3などと壁うちをして先に作っておく必要があります。
例： Multi Tenantを管理するテーブル設計、RLSを全体的にどうかけるか等。

フロントのコードからテーブルの設計を出力

上記が終わり次第、そのテーブル情報をプロンプトに組み込み。Create 系の処理があるフロントのコードとともにClaude or GPT 4にテーブル設計をするように投げます。
1ページ１ページ行うことがコツです。

これを各Create系のページをすべてに行いレビューをします。
毎回既存のテーブル情報をすべて投げると良いです。でないと同じテーブルや若干違ったテーブルを作り始めます。

実装

テーブル設計が終わり、Supabaseにそれを流し込んだら、Supabaseの機能でそのテーブルの情報をTypeScriptの型情報としてフロントに吐いてくれます。
なので、その型情報が入ったファイルを参照するように指示を入れて、各ページの実装をするように指示をします。
※この際もある程度コード量が膨らんできたら、同じフォルダ内　にコードを分割するように指示をします。

Read系の実装していると、単純にSupabaseのテーブルを取得するだけでは足りなくなったりするので、残りはストアドファンクションを作るなり、Viewをつくるなり、Edge Functionsを使うなりはそれぞれAIと相談しながら作り込んでいってください。

終わりに

エンジニアのレビュー、セキリティ、設計諸々思考するところは引き続き残ります。
個人的にはここがとても好きなので、設計やある程度決めたあとのわかりきった作業を代替できるツールがあるととても楽しいのです。

リアルにAIをうまく使えるのか、AIにあった技術選定、構成をしているか、AIが得意な領域の開発をしているかによって100倍の生産性を出せるなと感じております。
そこの見極め、三大美徳の怠惰が重要な時代なのではないのでしょうか。

Three Virtues
According to Larry Wall(1), the original author of the Perl programming language, there are three great virtues of a programmer; Laziness, Impatience and Hubris
Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.
Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.
Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.
https://thethreevirtues.com/

Discussion