Zenn
🙌

AIからはじめた人のモダンWeb開発の『全体図』 — 初心者向けシステム構成ガイド (2025年版)

に公開
AI
Web
初心者向け
プログラミング初心者
tech

対象読者: 画像生成や LLM API など "AI だけ" を触ってきたけれど、そろそろ Web アプリ を作ってみたい初級開発者。

0. なぜ "ざっくり全体像" が必要なのか

AI SDK は魔法のようですが、プロダクション ユースでは フロントエンド・バックエンド・インフラ の協奏が欠かせません。先に全景をつかむことで、個々の技術選定や学習コストを劇的に抑えられます。

1. バードアイ図: 4 層モデル

  • UI 層: React (Next.js 15) + Tailwind CSS + shadcn/ui
  • API 層: Edge Functions (Vercel)、AWS Lambda、Cloud Functions など
  • データ層: Supabase (PostgreSQL)、Firebase (Firestore)、Vector DB など
  • クラウド基盤: Vercel / AWS / GCP / Azure、IaC(Terraform) & GitHub Actions

2. フロントエンド技術の選択肢

2.1 アプリケーションフレームワーク（開発言語のフレームワーク）

フレームワーク 主な言語 特徴・用途
Next.js 15 React/JS/TS SSR/SSG/ISR 対応。App Router, Server Actions など最新仕様。SEO やパフォーマンス重視の Web アプリに最適。
Remix React/JS/TS ルーティングとデータ取得が直感的。フォーム重視。
Vite + React React/JS/TS 高速な開発体験。小〜中規模 SPA/MPA 向け。
Nuxt.js Vue/JS/TS Vue ベース。SSR/SSG/SPA 対応。
SvelteKit Svelte/JS/TS 軽量・高速。学習コスト低め。
Astro 複数対応 複数 FW 混在可。静的サイトやブログ、LP 向け。

補足: AI アプリや Web サービスでは Next.js 15（React）を中心に選ばれることが多いですが、Vue や Svelte ベースの選択肢も十分実用的です。

2.2 UI フレームワーク・UI ライブラリ

ライブラリ/フレームワーク 主な用途・特徴
shadcn/ui ヘッドレス UI。Next.js や Vite 等で利用可。アクセシビリティ重視。
Chakra UI デザイン一貫性・アクセシビリティ重視。
Material UI Google Material Design 準拠。大規模・業務系で実績多数。
Ant Design エンタープライズ向け。中国圏で人気。
Radix UI アクセシブルなプリミティブ UI。shadcn/ui のベース。
Tailwind CSS ユーティリティ CSS。どの FW でも利用可。
Bootstrap 歴史ある UI フレームワーク。

2.3 技術選定のポイント

  • アプリケーションフレームワークは「開発言語（React/Vue/Svelte 等）」ごとに選択肢があり、アプリの構造やデータ取得、ルーティングなどを担います。
  • UI フレームワーク/ライブラリは、見た目や UI 部品の実装効率・アクセシビリティ・デザイン一貫性を担保するためのものです。
  • 両者は組み合わせて使うのが一般的です（例：Next.js 15 + shadcn/ui + Tailwind CSS）。

Tip: まずは Next.js 15 + Tailwind CSS + shadcn/ui で始めてみて、必要に応じて他の選択肢も検討すると良いでしょう。

3. バックエンドの全体像と選択肢

3.1 バックエンドの役割と構成パターン

  • バックエンドは「フロントエンドからのリクエストを受けて、データベースや外部 API とやりとりし、結果を返す」役割を担います。
  • 認証・認可、データ保存、AI API の呼び出し、バッチ処理なども担当します。
  • 主な構成パターンは以下の 3 つです：
    • サーバーレス関数（Vercel Edge Functions, AWS Lambda など）
    • BaaS（Backend as a Service：Supabase, Firebase など）
    • 伝統的サーバー（Express, FastAPI, NestJS など）

サーバーレス関数 vs 伝統的サーバー

観点 サーバーレス (Lambda/Edge) 常時稼働 (EC2, App Runner)
起動オーバーヘッド コールドスタートあり 低い (常駐)
課金モデル 実行時間課金 常時計算課金
ステート保持 毎リクエスト無状態 任意で保持可

Tip: "AI API コール中心" のサービスは サーバーレス と相性良し (バーストに強い)。

3.2 BaaS（Supabase と Firebase）の比較

BaaS（Backend as a Service）は、認証・データベース・ストレージなどのバックエンド機能を「ノーコード」や「少ないコード」で素早く利用できるサービスです。AI アプリや Web サービスの初期開発に非常に便利で、Next.js 15 との連携もスムーズです。

ここでは、代表的な BaaS である Supabase と Firebase（Firestore）を比較します。

項目 Supabase Firebase（Firestore）
データベース PostgreSQL（リレーショナル/SQL） Firestore（NoSQL/ドキュメント指向）
認証 メール/パスワード、OAuth、Magic Link 等 メール/パスワード、OAuth、匿名認証等
API 自動生成 REST/GraphQL REST/SDK（クライアント主導）
リアルタイム 標準対応（Postgres の変更を Push 通知） 標準対応（リアルタイム同期が強み）
ストレージ オブジェクトストレージ（S3 互換） Cloud Storage（Google インフラ）
サーバーレス関数 Edge Functions（TypeScript/JS） Cloud Functions（Node.js, Python 等）
SQL サポート あり（本格的な集計・JOIN も可能） なし（NoSQL クエリのみ）
料金体系 無料枠＋従量課金（Postgres ベース） 無料枠＋従量課金（Google インフラ）
管理 UI Supabase Studio（Web UI） Firebase Console（Web UI）
Next.js 連携 公式 SDK あり、SSR/Server Actions 対応 公式 SDK あり、クライアント中心
その他特徴 SQL の柔軟性、OSS、セルフホスト可 Google サービス連携、モバイルに強い

Supabase は SQL ベースで柔軟なデータ操作や集計が得意、Firebase はリアルタイム性や Google サービス連携、モバイル対応が強みです。どちらも Next.js 15 との連携がしやすく、AI アプリの初期開発に最適です。

3.3 バックエンド設計のポイント

  • AI API のラップ: OpenAI 等の API キーを安全に扱うため、バックエンド経由で呼び出す。
  • 認証・認可: Supabase Auth や Firebase Auth で「誰が」アクセスしているかを管理。
  • DB 設計: ユーザー情報や履歴、設定などをどこに・どう保存するかを決める。
  • セキュリティ: .env 管理、CORS 設定、レートリミットなど。

3.4 具体的な構成例（Next.js 15 + Supabase）

  1. API ルート: /app/api/ にサーバーレス関数を実装
  2. Supabase SDK: API ルートや Server Actions から DB/認証を操作
  3. .env 管理: API キーや DB 接続情報は環境変数で安全に管理
  4. 認証フロー: サインイン/サインアップは Supabase Auth で実装
  5. AI API 連携: API ルート経由で OpenAI 等を呼び出し、レスポンスをフロントに返す

3.5 よくある質問・Tips

  • Q: 「AI API を直接フロントから叩いてもいい？」
    • A: セキュリティ上 NG。API キー漏洩やリクエスト改ざんのリスクあり。必ずバックエンド経由で。
  • Q: 「Supabase と Firebase、どちらを選ぶべき？」
    • A: SQL（集計・分析・厳密な整合性）が必要なら Supabase。リアルタイム性や Google 連携重視なら Firebase。

4. データ & AI ワークロード

4.1 データストアの全体像と選定基準

  • なぜデータストアが重要か
    AI アプリでは「ユーザー情報」「履歴」「AI の入出力」「ベクトルデータ」など多様なデータを扱います。目的ごとに最適なストアを選ぶことで、パフォーマンス・コスト・開発効率が大きく変わります。

  • 主なデータストアの種類と特徴

    データストア 主な用途・特徴
    PostgreSQL / Supabase トランザクション、集計、リレーショナルな管理
    Firestore 柔軟なドキュメント指向、リアルタイム同期
    Vector DB (ChromaDB) セマンティック検索、RAG、類似度検索
    Object Storage (S3) 画像・音声・モデルバイナリ・大容量ファイル保存

  • 選定のポイント

    • 「履歴やユーザー管理」→ RDB（Supabase/PostgreSQL）
    • 「AI の知識検索」→ ベクトル DB
    • 「画像やファイル」→ オブジェクトストレージ
    • 「リアルタイム同期」→ Firestore

4.2 AI ワークロードのパターン

  • AI アプリでよくあるデータフロー

    1. ユーザー入力を受け取る
    2. 必要に応じて履歴や設定を DB から取得
    3. AI API（OpenAI 等）にリクエスト
    4. 結果を DB やストレージに保存
    5. 必要ならベクトル DB で類似検索や RAG

  • RAG（Retrieval Augmented Generation）構成例

    1. ユーザーの質問を Embedding
    2. ベクトル DB で類似ドキュメント検索
    3. 検索結果をプロンプトに差し込み LLM へ
    4. レスポンスをキャッシュや履歴 DB に保存

4.3 Next.js 15 × Supabase/Vector DB 実装例

  • DB 設計例

    • users: ユーザー情報
    • chat_history: チャット履歴
    • documents: ナレッジベース
    • vectors: ベクトル埋め込み

  • API ルート例

    • /app/api/chat/route.ts
      入力受付 → 履歴取得 → AI API 呼び出し → 結果保存
    • /app/api/embedding/route.ts
      テキストを Embedding 化しベクトル DB へ保存

  • ベストプラクティス

    • DB アクセスは Server Actions や API Route で行う
    • Embedding や RAG はバックエンドで処理し、API 経由でフロントに返す
    • 大きなファイルや画像は Supabase Storage や S3 に保存し、DB には URL のみ持たせる

4.4 よくある課題と Tips

  • Q: ベクトル DB はどこにホストすべき？
    • 小規模なら Supabase の pgvector 拡張で十分。大規模なら ChromaDB や Pinecone 等の専用サービスも検討。
  • Q: AI API のレスポンスをどこに保存？
    • 履歴 DB（chat_history）に保存し、必要に応じてキャッシュ戦略を設計。
  • Q: データのバックアップは？
    • Supabase/Firebase は自動バックアップあり。重要データは定期的にエクスポート推奨。

4.5 まとめ

  • データストアは「用途ごとに最適なものを選ぶ」のが鉄則
  • Next.js 15 + Supabase + ベクトル DB の組み合わせで、AI アプリの主要ワークロードはほぼカバー可能
  • RAG や Embedding など AI 特有の処理は、API Route や Server Actions で安全に実装

5. CI/CD & GitHub

5.1 CI/CD とは？

  • CI（継続的インテグレーション：Continuous Integration）
    • 複数人・複数機能の開発を安全に進めるため、コードを頻繁に統合（マージ）し、自動でテスト・ビルドを行う仕組みです。
    • 例：プルリクエストを作ると、自動でテストや型チェックが走る。
  • CD（継続的デリバリー/デプロイメント：Continuous Delivery/Deployment）
    • テストに合格したコードを自動で本番やステージング環境にデプロイする仕組みです。
    • 例：main ブランチにマージされたら Vercel やクラウドに自動デプロイ。

なぜ必要？

  • 手作業によるミスを減らし、品質を保ったまま素早くリリースできる
  • チーム開発や OSS でも「誰が何を変更したか」「どこで問題が起きたか」を追いやすい

5.2 代表的な CI/CD の流れ（Next.js 15 × Vercel の場合）

  1. Pull Request（PR）作成
    • 新機能や修正を加えたら、GitHub で PR を作成。
  2. GitHub Actions で自動チェック
    • PR 作成や main ブランチへの push をトリガーに、
      • Lint（コード整形チェック）
      • Test（ユニット/E2E テスト）
      • Build（本番ビルド）
        が自動で実行される。
    • 問題があればマージできない仕組みにもできる。
  3. Vercel 等で自動デプロイ
    • main ブランチにマージされると、Vercel が自動で本番/プレビュー環境にデプロイ。
    • PR ごとに「Preview URL」が発行され、動作確認やレビューがしやすい。

5.3 CI/CD 設計のポイント

  • Secrets 管理: GitHub のEnvironmentや Vercel のProject Settingsに API キー等を安全に保存。.env.exampleはリポジトリに残す。
  • Monorepo 対応: turbo runやNxで、変更のあったパッケージだけビルド・テストして効率化。
  • 通知・可視化: テスト失敗やデプロイ完了を Slack 等に通知する設定も可能。
  • ロールバック: Vercel 等はワンクリックで前のバージョンに戻せる。

まとめ: CI/CD を導入することで、

  • 「壊れたコードが本番に出る」リスクを減らせる
  • レビューや動作確認がしやすくなり、開発効率が大幅アップ
  • 個人開発でも「安心してリリース」できる体制が作れる

6. インフラとは？クラウド 3 社ざっくり比較

6.1 そもそも「インフラ」って何？

Web アプリの「インフラ」とは、アプリを動かすための土台となるサーバー・データベース・ストレージ・ネットワークなどの IT 基盤全体を指します。
昔は自分で物理サーバーを用意していましたが、今は AWS/GCP/Azure などの「クラウドサービス」を使うのが主流です。

  • なぜクラウド？
    • サーバーの準備・運用が不要（数クリックで用意できる）
    • 必要な分だけ使えてコスト効率が良い
    • セキュリティやバックアップも自動で担保される

6.2 主要クラウド 3 社の特徴比較

観点 AWS GCP Azure
機械学習 SageMaker / Bedrock Vertex AI Azure AI Studio
サーバーレス Lambda / API GW Cloud Functions Azure Functions
マネージド DB DynamoDB, RDS Cloud SQL, Spanner Cosmos DB
ストレージ S3 Cloud Storage Azure Blob
学習コスト 情報量多いが資料豊富 UI わかりやすい .NET との親和性
  • AWS: 世界シェア No.1。機能が多く、資料も豊富。最初はやや難しいが、慣れると強力。
  • GCP: Google らしいシンプルな UI。AI/データ分析系が強い。無料枠も充実。
  • Azure: Microsoft 系サービスとの連携が強み。企業・業務システムでよく使われる。

どれを選ぶ？
個人開発や AI アプリなら「Vercel（Next.js 公式推奨）」や「Supabase（DB/BaaS）」と組み合わせて、必要に応じて AWS/GCP の一部サービスを使うのが現実的です。

7. Infrastructure as Code（IaC）とは？

7.1 IaC の基本

**Infrastructure as Code（IaC）**とは、サーバーや DB などのインフラ構成を「コード（設定ファイル）」で管理する手法です。

  • なぜ必要？
    • 手作業での設定ミスを防げる
    • チームで同じ環境を再現できる
    • バージョン管理（Git）で変更履歴を追える

7.2 代表的な IaC ツール

  • Terraform
    • AWS/GCP/Azure など複数クラウドを一括管理できる定番ツール
    • 例：terraform planで変更点を事前確認、terraform applyで反映
  • Pulumi（TypeScript 対応）
    • TypeScript や Python など普段使う言語でインフラを記述できる
  • Serverless Framework
    • サーバーレス（Lambda/Edge Functions 等）に特化。YAML で宣言

7.3 どんな時に使う？

  • 本番環境やチーム開発で「同じインフラを何度も再現したい」場合
  • サーバーレスや DB、ストレージなど複数サービスを組み合わせる場合
  • インフラの変更を安全に・自動化したい場合

個人開発でも「IaC」で管理しておくと、後から本番移行やチーム拡大がとても楽になります。

8. ロギング & モニタリング

ロギング（Logging） とは、アプリやシステムの動作記録（ログ）を残すことです。**モニタリング（Monitoring）**は、そのログや各種メトリクス（CPU 使用率、エラー数など）をリアルタイムで監視し、異常や問題を早期発見する仕組みです。

  • なぜ必要？
    • バグや障害発生時に「何が起きたか」を素早く特定できる
    • パフォーマンスのボトルネックや利用状況を把握できる
    • セキュリティインシデントの検知や追跡にも役立つ
レイヤ 推奨ツール
フロント Vercel Analytics, Sentry, LogRocket
API OpenTelemetry + Cloud Provider Logs
DB Supabase Studio / Firebase Console

Tips: Sentry や LogRocket は「どの画面でどんなエラーが出たか」を可視化でき、ユーザー体験の改善に直結します。

9. セキュリティ & .env 運用

セキュリティは「アプリやデータを守る」ための基本です。特に API キーや DB パスワードなどの「機密情報」は、.env ファイル（環境変数）で安全に管理します。

  • なぜ .env 管理が重要？
    • API キーやパスワードがコードに混ざると、うっかり GitHub 等に公開してしまうリスクが高まる
    • ステージング・本番など環境ごとに設定を切り替えやすい
    • チーム開発でも「誰が何を使っているか」を明確にできる

.env 運用のポイント

  1. .env には 絶対に コードを push しない（.gitignore で除外）
  2. ステージング・本番で環境変数を分離（例：.env.staging, .env.production など）
  3. GitHub には Dependabot & Secret Scanning を有効化（漏洩チェック）
  4. OWASP Top 10（Web 脆弱性の代表例）を最低限チェック

Tips: Next.js 15 では、NEXT_PUBLIC_ で始まる環境変数のみフロントから参照可能。それ以外はサーバー専用。

10. ローカル開発 & テスト

ローカル開発とは、自分の PC 上でアプリを動かしながら開発・テストすることです。テストは「バグを未然に防ぐ」ための自動チェックです。

  • なぜローカル開発・テストが重要？
    • 本番環境での事故やバグを未然に防げる
    • 変更の影響範囲を素早く確認できる
    • チーム開発でも「動くもの」を共有しやすい

主なツール・手法

  • Docker Compose: DB/Cache/MinIO など複数サービスをまとめて一発起動。環境差異を減らせる。
  • pnpm workspaces: 複数パッケージの依存管理を効率化。モノレポ構成に便利。
  • Playwright: ブラウザ操作を自動化し、E2E（エンドツーエンド）テストを実行。GitHub Actions など CI 上でも動作。

Tips: Next.js 15 では pnpm dev で即座に開発サーバーを立ち上げ可能。E2E テストも CI/CD に組み込むと安心。

11. まとめ: "まずは動くもの" をデプロイせよ

  • ホスティングは Vercel でスピード感を獲得 → Analytics で実測。
  • BaaS (Supabase/Firebase) で DB・Auth を後回しにし プロダクト価値の仮説検証 に集中。
  • AI コンポーネント はプラグインとして後付け可能。まず ユーザーフロー を磨く。

小さく作って多く学ぼう — "Ship early, iterate often!"

付録: さらなる参考リンク

Discussion