AIでサイトやアプリを作る人が増えるほど、さまざまな開発サービスの名前をよく聞くようになります。
たとえば、Vercel、Netlify、Cloudflare、Supabase、Firebase、Railway、Render、Fly.io、GitHub、Stripe、Resendなどです。
聞いたことはある。
でも、それぞれが何をする場所なのか分からない。
しかも、AIに聞くと「このサービスがおすすめです」と出てくる。
別のAIに聞くと、また違うサービスを勧められる。
その結果、どれが正解なのか分からなくなります。
この記事では、個別サービスの細かい料金や仕様ではなく、AI時代に使われる開発サービスを役割で整理します。
料金や細かい仕様は変わります。
でも、役割の考え方は変わりにくいです。
サービス名で覚えるより、役割で見る
開発サービスを理解する時に、いきなり名前で覚えようとすると混乱します。
大事なのは、どのサービスが何を担当しているかです。
ざっくり分けると、サイトやアプリには次の役割があります。
- コードを保管する
- 表示する
- 裏側の処理を動かす
- データを保存する
- ユーザーを認証する
- ファイルを保存する
- メールを送る
- 決済する
- ドメインをつなぐ
- サイトを守る
1つのサービスが複数の役割を持つこともあります。
逆に、1つのアプリで複数のサービスを組み合わせることもあります。
つまり、「このサービスが最強」と考えるより、自分のサイトにはどの役割が必要かから考える方が安全です。
GitHubは、コードと変更履歴の中心
まずGitHubです。
GitHubは、コードと変更履歴の中心です。
AIでサイトを作るなら、ここを使う意味はかなり大きいです。
なぜなら、AIが書いたコードを戻せる状態で管理できるからです。
GitHubがあると、
- 変更履歴が残る
- branchで作業を分けられる
- PRで本番反映前に確認できる
- 誰が何を変えたか追える
- 外部の開発者やAIにレビューさせやすい
ようになります。
GitHubは、単なるエンジニア向けSNSではありません。
AI開発では、作業場の正本です。
Vercelは、Next.js系サイトを公開しやすい場所
Vercelは、Next.jsやReact系のサイトを公開しやすいサービスです。
GitHubと連携しておくと、branchやmainへの反映に合わせて、自動でビルドと公開ができます。
向いているのは、
- Next.jsのサイト
- LP
- ブログ
- 会員サイトの表側
- 管理画面つきのWebアプリ
などです。
AIで作ったWebアプリをすぐ公開したい時、Vercelはかなり使われます。
ただし、Vercelだけですべてが完結するとは限りません。
会員情報、データベース、メール送信、決済などは別サービスと組み合わせることが多いです。
Vercelは、主に「表側を公開する場所」と考えると分かりやすいです。
Netlifyは、静的サイトやフロントエンド公開に強い
Netlifyも、Webサイトを公開するサービスです。
静的サイトやフロントエンドの公開に向いています。
昔からJamstack系のサイトで使われてきました。
Vercelと同じようにGitHub連携で自動公開できます。
選ぶ時は、「Vercelが良いか、Netlifyが良いか」という名前の比較より、
- 使っているフレームワーク
- 必要な機能
- チームや外部開発者の慣れ
- 既存サイトとの相性
で見る方が現実的です。
Cloudflareは、配る・守る・軽い処理を動かす
Cloudflareは、少し役割が広いサービスです。
ドメイン管理、DNS、CDN、セキュリティ、静的サイト配信、Workerによる軽い処理などに関わります。
ざっくり言えば、
サイトを速く、安全に、広く配るための場所
です。
AI時代にCloudflareが注目される理由は、単なる防御だけではありません。
世界中に近い場所で処理を動かせたり、軽いバックエンド処理を置けたりするからです。
ただし、最初からCloudflareの全機能を理解する必要はありません。
初心者はまず、
- DNSやドメインに関わる
- 表示速度やセキュリティに関わる
- Workerで小さな処理を動かせる
くらいで十分です。
Supabaseは、データベースと認証を用意しやすい
Supabaseは、アプリの裏側を用意しやすいサービスです。
特に、データベース、認証、ストレージ、APIまわりで使われます。
AIで会員サイトや管理画面を作る時、よく候補に出ます。
たとえば、
- ユーザー登録
- ログイン
- 記事データ
- 購入状態
- 管理画面のデータ
- ファイル保存
こういう部分です。
Vercelが表側を公開する場所だとすると、Supabaseは裏側の記憶を持つ場所に近いです。
Firebaseは、アプリの裏側をまとめて作りやすい
Firebaseも、アプリの裏側を作るサービスです。
認証、データベース、ストレージ、ホスティング、通知など、アプリ開発に必要なものをまとめて扱えます。
モバイルアプリやリアルタイム性のあるアプリで使われることも多いです。
SupabaseとFirebaseはよく比較されます。
ただ、初心者の段階では、どちらが絶対に正解かよりも、
- どんなデータを持つのか
- 誰が運用するのか
- 将来エンジニアに引き継げるか
- AIが生成したコードと相性が良いか
を見た方がいいです。
RailwayやRenderは、アプリの裏側を動かしやすい
RailwayやRenderのようなサービスは、アプリのサーバー処理を比較的簡単に動かすために使われます。
たとえば、
- APIサーバー
- バックエンドアプリ
- バッチ処理
- 小さなWebサービス
などです。
VPSほど自分で全部管理したくない。
でも、Vercelの範囲だけでは足りない。
こういう時に候補になります。
AIで作った小さなバックエンドを動かしたい場合にも出てきます。
ただし、こちらも料金や仕様は変わるため、サービス名で決め切るより、何を動かしたいかから考えるべきです。
Fly.ioは、アプリを近い場所で動かす選択肢
Fly.ioのようなサービスは、アプリを複数地域で動かす、低遅延で配る、といった文脈で出てきます。
初心者が最初に選ぶべきとは限りません。
ただ、AI開発が進むと、アプリをどこで動かすかの選択肢として名前を聞くことがあります。
今すぐ細かく理解しなくても大丈夫です。
「VPSほど手作業ではなく、クラウド上でアプリを動かす選択肢のひとつ」
くらいに見ておけば十分です。
Stripeは、決済を任せる場所
Stripeは、決済に関わるサービスです。
会員サイト、講座販売、サブスク、単発決済などで使われます。
AIでサイトを作っても、決済を自前で作るのは危険です。
お金、カード情報、請求、キャンセル、返金、領収書などが絡むからです。
こういう部分は、専用サービスに任せる方が安全です。
Stripeは、サイト開発における「お金の処理を任せる場所」と考えると分かりやすいです。
Resendなどは、メール送信を任せる場所
問い合わせ返信、会員登録メール、通知メールなどを送るには、メール送信の仕組みが必要です。
Resendのようなサービスは、アプリからメールを送るために使われます。
メールは簡単そうに見えて、意外と難しいです。
届かない。
迷惑メールに入る。
送信元認証が必要。
返信先をどうするか。
管理者控えをどうするか。
こういう運用が絡みます。
だから、AIに「メール送信機能を作って」と頼む時は、どのサービスで送るのか、誰に届くのか、返信先はどこかまで決める必要があります。
名前ではなく、責任範囲で選ぶ
サービス選びで大事なのは、名前の流行ではありません。
責任範囲です。
このサービスには何を任せるのか。
表示だけなのか。
データ保存なのか。
認証なのか。
決済なのか。
メールなのか。
セキュリティなのか。
ここを決めずにサービスを増やすと、あとで管理が重くなります。
AIは「このサービスを使えばできます」と提案してくれます。
でも、そのサービスを増やすことで、管理する場所も増えます。
だから、AI時代の開発では、作れるかどうかだけでなく、運用できるかどうかを見る必要があります。
小さく始めるなら、この順番で考える
AIでサイトやWebアプリを作るなら、最初は次の順番で考えると整理しやすいです。
- コードと履歴はどこで管理するか
- 表側はどこで公開するか
- データはどこに保存するか
- ログインは必要か
- 決済は必要か
- メール送信は必要か
- ドメインとDNSはどこで管理するか
- 本番反映と戻し方はどうするか
この順番です。
いきなり「どのサービスが最強か」から考えると迷います。
でも、自分のサイトに必要な役割から考えると、選択肢は絞れます。
AIに聞く時の聞き方
AIにサービス選びを相談する時は、こう聞くと良いです。
「VercelとSupabaseで作りたいです。ログイン、記事管理、決済、メール送信があります。どの責任をどのサービスに持たせるべきか、運用リスクも含めて整理してください」
または、
「この構成で本番運用する時、戻せない変更、消えると困るデータ、外部サービス依存、管理者が確認すべき場所を洗い出してください」
こう聞くと、単なるおすすめではなく、運用目線の回答になりやすいです。
AI開発では、サービスを選ぶことよりも、責任の置き場を決めることが大切です。
関連して読んでおきたい記事
AIを使えば、サイトやアプリはかなり作りやすくなりました。
でも、サービスの数が増えるほど、全体像を持たないまま進めるリスクも増えます。
どこに何を任せるのか。
何が壊れた時に、どこを見ればいいのか。
何を戻せて、何を戻せないのか。
ここを見えるようにしておくことが、AI時代の開発を安心して進める土台になります。