SaaS スタートアップの技術選定は、エンジニアの好みやその時々の流行で決めると、半年後に必ず跳ね返ってきます。MVP を最速で出すために選んだ構成が、最初のスケールやピボットで足かせになり、結局作り直す。これはよくある失敗です。
この記事では、SaaS スタートアップが MVP からスケールまで耐える技術スタックを、AI 駆動開発を前提にどう選ぶかを整理します。判断軸は終始一貫して 2 つだけです。「どれだけ速く作れるか」と「捨てる・直すときにいくらかかるか」。フレームワーク、インフラ、データ設計のそれぞれをこの二軸で評価し、最後に実案件のスタック構成例と、移行で後悔しないための線引きまで共有します。FIXIT が AI 駆動開発のクリエイティブスタジオとして関わってきた現場の判断基準です。
技術選定で最初に決めるべきは「捨てやすさ」
スタートアップの初期に作るものは、ほぼ確実に変わります。プロダクトマーケットフィットを探している段階では、想定したユーザー像も主要機能も数か月で書き換わるのが普通です。この前提に立った開発体制の選び方は PMF 前のスタートアップが選ぶべき開発体制 で整理しています。つまり最初に作る構成の大半は、いずれ捨てるか大きく直す前提で組むべきです。
ここから導かれる選定の優先順位は、世間の技術記事とは少し違います。多くの記事は「スケールするか」「将来性があるか」を上位に置きますが、PMF 前のスタートアップにとって最も重要なのは初速、つまりどれだけ速く作って検証できるかです。次に重要なのが、変えるとき・捨てるときのコストの低さです。
選定対象を 2 つのグループに分けて考えると判断が楽になります。1 つは「後から変えやすいもの」、もう 1 つは「後から変えると全体に波及するもの」です。
後から変えやすいものの代表は、UI のコンポーネントライブラリ、状態管理の細かい方針、個々の画面の実装方法です。これらは局所的なので、最初は迷わず一番速く書けるものを選び、必要になってから見直せば十分です。ここで完璧を目指して時間をかけるのは、初速を犠牲にする悪手です。
逆に、後から変えると全体に波及するものは、データモデルの根幹、テナント分離の方式、主要言語、認証基盤などです。これらは一度プロダクトに根を張ると、入れ替えるときに全コードへ影響します。だからこそ選定の労力はここに集中させます。「捨てやすさ」を基準に置くというのは、捨てやすい領域では速度を優先し、捨てにくい領域だけ慎重に決める、という配分のことです。
AI 駆動開発を前提にすると、この配分はさらに有利になります。捨てやすい領域の実装は AI に高速で書かせ、人間は捨てにくい領域の意思決定に集中できるからです。AI 駆動開発そのものの考え方は AI 駆動開発とは もあわせて読むと、この記事の前提が掴みやすくなります。
フロントエンド／バックエンドの選び方（Next.js・Hono などの実構成）
Web 系の SaaS において、フロントとバックの言語をどう揃えるかは初速に直結します。結論から言うと、TypeScript で統一する構成が、AI 駆動開発の前提では最も合理的です。フロントとバックで言語が分かれていると、型定義の二重管理が発生し、AI に渡すコンテキストもリポジトリをまたいで分断されます。言語を揃えれば、API の入出力の型がそのままフロントに伝わり、AI も 1 つの言語の文脈だけで実装を進められます。
具体的な組み合わせとしては、いくつかの定番があります。
一番手堅いのは、フロントもバックも Next.js に寄せる構成です。App Router と Route Handler、あるいはサーバーアクションで API を内包すれば、最初は 1 つのアプリだけで SaaS の主要機能を完結させられます。MVP の段階では、サービスを分けないこの形が圧倒的に速いです。SEO が要るマーケティングページと、ログイン後のダッシュボードを同じ枠組みで扱える点も、スタートアップの最初期には効いてきます。
API の独立性を早めに確保したい場合は、フロントを Next.js、バックエンドを Hono のような軽量フレームワークで切り出す構成も選びやすくなっています。Hono は型安全なルーティングを持ち、エッジ環境でもそのまま動くため、後述する Cloudflare 系のインフラと相性が良いです。クライアントへ型付きの API を共有しやすく、AI に「この型のエンドポイントを追加して」と指示したときの精度も上がります。モバイルアプリや外部連携を早期に想定するなら、最初からこの分離を選ぶ判断もあります。
フレームワーク選定でやってはいけないのは、誰もチームに知見がない技術を話題性だけで選ぶことです。AI を入れても、レビューできる人間がいなければ生成されたコードの正しさを判断できません。AI 駆動開発はチームの知見を増幅する道具であって、知見ゼロの領域をゼロから埋めてくれる魔法ではない、という前提を外さないことが大切です。
状態管理やコンポーネントライブラリといった、先ほど「捨てやすい」に分類した領域は、ここでは深追いしません。チームが慣れたものを選び、AI に一気に実装させ、必要になったら差し替える。それで十分です。
インフラ選定｜Cloudflare・サーバーレスでスモールスタートする
インフラは、スタートアップが固定費と運用負荷で消耗しやすい領域です。ユーザーがまだ数社しかいない段階で、冗長化された常時稼働のサーバー群を抱えるのは典型的な過剰投資です。初期は「使った分だけ払う」サーバーレス系を基本に置くと、固定費を抑えながらスモールスタートできます。
選択肢として現実的なのは二系統です。1 つは Cloudflare Workers や Pages を中心に据える構成で、エッジで動くため初期のレイテンシ対策が要らず、無料枠も広いため検証段階のコストをほぼゼロに近づけられます。前述の Hono と組み合わせれば、API もエッジで完結します。もう 1 つは、より一般的なマネージドのコンテナやサーバーレス関数を使う構成で、既存資産やチームの慣れに合わせて選びます。
データベースは、ここでの後戻りコストが最も大きい部分です。検証段階ではマネージドの PostgreSQL を選んでおくのが無難です。リレーショナルなデータモデルは SaaS の業務要件と素直に対応し、後からスケールさせる手段も豊富にあります。最初から特殊な分散データベースや、用途の限られたストアに寄せると、要件が変わったときの移行が重くなります。データの根幹は捨てにくい領域なので、ここは「枯れていて移行先が多い」選択を優先します。
インフラ選定で押さえておきたいのは、構成をコードで管理しておくことです。手作業でクラウドのコンソールを触って作った環境は再現性がなく、後から AI にも人間にも全体像が見えません。Infrastructure as Code で構成を宣言的に残しておけば、AI に「この設定を踏まえて新しい環境を追加して」と頼める状態になり、環境の複製や移行のコストが下がります。スモールスタートと再現性は両立できます。
スケールの段階で監視やログ基盤、CDN のチューニングが要るようになりますが、それらは負荷が見えてから足せばよい領域です。最初から全部を用意しようとすると、検証に使うべき時間と予算をインフラに吸い取られます。
データモデルとマルチテナント設計を最初にどこまでやるか
SaaS でほぼ唯一「最初に慎重に決めるべき」と言い切れるのが、データモデルとマルチテナント設計です。ここは後から入れ直すと全クエリに波及するため、後戻りコストが突出して高い領域だからです。
最初に必ずやることは 1 つ、テナント識別をデータの根に通すことです。主要なテーブルに tenant_id(あるいは組織 ID)を持たせ、アプリ層では必ずそのテナントのスコープを付けてアクセスする、という規約を初日に固めます。これを後から入れると、すでに書いた全クエリを見直す羽目になり、しかも見落とせばテナント間のデータ漏洩という最悪の事故につながります。後戻りコストと事故のリスクの両方が極端に高いので、ここだけは速度より正しさを優先します。
一方で、最初からやらなくてよいことも明確にしておきます。テナントごとにデータベースを物理的に分ける方式や、行レベルセキュリティの細かい作り込みは、最初の数社の段階では過剰です。これらは影響範囲が分離方式の選択に閉じており、後から移行できます。論理分離(共有データベースで tenant_id により分ける)で始め、特定の大口顧客が物理分離を求める段階になってから対応すれば間に合います。
データモデルそのものは、最初から完璧を目指さないことが逆に重要です。PMF 前は要件が変わるので、スキーマも変わります。ここで効いてくるのが、マイグレーションを最初から仕組みとして整えておくことです。スキーマ変更を順序立てて積み上げられる状態にしておけば、データモデルの変更を恐れずに済みます。捨てにくいのはテナント分離という「設計の骨格」であって、個々のカラムやテーブルは変えられる前提で組むのが、初速とのバランスを取るコツです。
AI 駆動開発の現場では、このテナント分離のルールを規約として明文化しておくことが特に効きます。「全クエリにテナントスコープを付与する」「テナントをまたぐ集計は専用の経路を通す」といったルールをドキュメントに残しておけば、AI が実装するときもそのルールに沿ってコードを書き、レビューでも逸脱を検出しやすくなります。設計の意図を言葉にしておくほど、AI の実装精度は上がります。
AI 駆動開発を前提にした選定基準（AI が読み解きやすい構成とは）
ここまでの判断軸に、もう 1 つの基準を重ねます。「その構成は AI が読み解きやすいか」です。同じ機能を作れるスタックでも、AI が文脈を把握しやすい構成かどうかで、実装の初速と正確さが大きく変わります。
AI が読み解きやすい構成の特徴は、人間にとって読みやすい構成とほぼ同じです。違うのは「曖昧さのコスト」が跳ね上がる点だけです。人間なら口頭の経緯や暗黙の前提で補える曖昧さを、AI は補えず、誤った推測でコードを埋めてしまいます。だから AI 駆動開発を前提にした選定とは、特殊な作法を足すことではなく、良い設計を曖昧さが残らないレベルまで徹底することだと考えると外しません。この詳細は AI 駆動開発のアーキテクチャ設計 で掘り下げています。
具体的な選定基準としては、まず型情報が豊富な言語・フレームワークを選ぶことが効きます。TypeScript を軸にする理由はここにもあります。型はそのまま AI への仕様伝達になり、関数の入出力やデータ構造の意図が型として表現されていれば、AI は曖昧さなく実装を進められます。型のない動的な世界は、人間にとっても AI にとっても推測の余地が大きく、初速は出ても後から事故が増えます。
次に、モジュール境界が明確で、ディレクトリ構造から責務が読み取れることです。AI は一度に把握できるコンテキストに上限があるため、関連するコードがまとまっていて、無関係なものが混ざっていない構成ほど精度が出ます。1 つのリポジトリに収まっていて、その中でドメインごとに境界が切られている状態が、現実的に最も扱いやすいです。
テスト・型・規約が AI 実装速度を左右する
AI 駆動開発の初速を実際に左右するのは、華やかなフレームワーク選定よりも、テスト・型・規約という地味な三点です。
テストは、AI が書いたコードの正しさを人間に代わって検証する安全網になります。テストがあれば、AI に変更を任せても挙動が固定されているかを即座に確認でき、人間はレビューと判断に集中できます。テストの考え方そのものを AI 駆動開発に合わせて設計する話は AI 駆動開発と TDD でまとめています。テストがない構成では、AI が生成したコードを一行ずつ人間が目で追う必要が出てきて、せっかくの初速が相殺されます。
型は、前述のとおり仕様伝達の手段です。型で意図を表現しておくほど、AI は仕様の取り違えを起こしにくくなります。
規約は、AI のばらつきを抑える役割を持ちます。命名、ディレクトリの置き方、エラーハンドリングの方針、テナント分離のルールといった規約を CLAUDE.md のようなドキュメントに明文化しておけば、AI はそれを参照して一貫したコードを書きます。規約がないと、AI は呼び出しのたびに違うスタイルのコードを出し、レビューの負荷が膨らみます。技術選定の段階で、この三点を整えやすいスタックかどうかを評価軸に入れておくと、後から効いてきます。
実案件のスタック構成例と移行で後悔しないための線引き
ここまでの基準を実際の構成に落とすとどうなるか、FIXIT が AI 駆動開発のクリエイティブスタジオとして関わった範囲での典型例を示します。固有の社名は伏せ、構成の考え方として読んでください。
ある B2B SaaS の MVP では、フロントとバックを Next.js に寄せ、データベースはマネージドの PostgreSQL、インフラはサーバーレス系でスモールスタートする構成を取りました。主要テーブルには初日から tenant_id を通し、マイグレーションとテストの仕組みを最初に整え、規約を CLAUDE.md に明文化したうえで実装を AI 駆動で進めました。結果として、検証可能なプロダクトを短期間で立ち上げられました。MVP を短期で立ち上げる進め方は 3 週間で SaaS の MVP を立ち上げた事例 でも具体的に紹介しています。
別の案件では、既存のレガシーなシステムを、捨てにくい領域だけを慎重に設計し直しながら段階的に置き換えました。データモデルとテナント分離を先に固め、変更頻度の高い領域から AI 駆動で書き換えていく進め方です。一度に全部を作り直すのではなく、移行可能な単位に切って進めたことで、稼働を止めずに刷新できました。この種の進め方は レガシー刷新を半分のコストで実現した事例 にまとめています。
移行で後悔しないための線引きを、最後に整理します。捨てやすい領域(UI、状態管理、個々の画面、コンポーネントライブラリ)は、最初から速度を優先し、必要になってから差し替える前提で組みます。捨てにくい領域(データモデルの根幹、テナント分離、主要言語、認証基盤)は、後戻りコストが全体に波及するため、選定の労力をここに集中させます。この線引きさえ間違えなければ、MVP の初速と将来のスケールは両立できます。
逆に、よくある後悔は 2 つです。1 つは、捨てやすい領域に最初から作り込みすぎて初速を失うこと。もう 1 つは、捨てにくい領域、とりわけテナント分離を後回しにして、ユーザーが増えてから全クエリの見直しに追われることです。技術選定の良し悪しは、流行のスタックを選べたかではなく、この二軸での配分を説明できる状態にあるかで決まります。
まとめ
SaaS スタートアップの技術選定は、「速度」と「後戻りコスト」の二軸ですべて判断できます。捨てやすい領域は速度を優先して AI に高速で実装させ、捨てにくい領域(データモデル・テナント分離・主要言語)だけ慎重に決める。これが、MVP からスケールまで耐えるスタック設計の核心です。そして AI 駆動開発を前提にするなら、型・テスト・規約を整えやすい構成を選ぶことが、初速を最大化する近道になります。
技術選定は一度きりの賭けではなく、捨てやすさを設計しておく営みです。どのスタックが自社のプロダクトと事業フェーズに合うか迷っているなら、構成の壁打ちから一緒に考えます。MVP を最短で出す手順そのものは SaaS の MVP の作り方｜最短リリースする 7 手順 にまとめています。技術選定の無料相談は お問い合わせ から、MVP の立ち上げ自体を任せたい場合は SaaS MVP 開発サービス をご覧ください。