フロントとバックを「同一ドメインにまとめる」か「別URLで公開する」か

Posted at 2025-08-26

TL;DR

開発初期は別オリジン（例: localhost:3000 と 8000）でOK。手早く進められる。
本番は同一ドメイン配下にまとめるのが基本（例: https://example.com/ と https://example.com/api/）。セキュアで管理もしやすい。
別URL公開（例: frontend.vercel.app と backend.onrender.com）も可能だが、CORS/CSRF 等の調整が必須になる、という理解でよい。
移行は比較的容易。開発時から「APIパス設計」「環境変数化」「相対パス利用」を意識しておけば、後から同一ドメインへ寄せられる。

用語の前提

オリジン＝スキーム + ドメイン + ポートの組み合わせ
例）http://localhost:3000（フロント）と http://localhost:8000（バック）は別オリジンである。

2つの公開方式

方式A：同一ドメイン配下にまとめる（推奨）

例）
- フロント：https://example.com/
- API：https://example.com/api/
利点
- ブラウザの同一オリジン制約に素直に乗れるため扱いやすい。
- CORS設定が原則不要で、CSRFも標準的なやり方で扱える。
- URL設計・ログ収集・監視・WAF設定・CDN適用などの運用が一元化しやすい。
よくある構成
- Nginx等のリバースプロキシで /api/ をDjangoへ、それ以外をフロントに振り分ける。
- Djangoで静的にフロントを配信（Next.jsを静的エクスポートして static/ 等から配信）。

方式B：フロントとバックを別URLで公開する

例）
- フロント：https://frontend.vercel.app/
- API：https://backend.onrender.com/
利点
- デプロイ先やスケール戦略を独立に選べる（例：フロントはVercel、バックはRender）。
- チーム分業やデプロイ頻度の差異に柔軟。
注意点（要点のみ）
- CORS設定が必要（フロントのオリジンをバックで許可する）。
- CSRFの扱いが複雑化しやすい。開発初期は @csrf_exempt で回避してもよいが、本番は認証・トークン設計を見直すべきである。
- Cookieベースの認証・OAuthのリダイレクトURI・Samesite属性など、ドメイン跨ぎ特有の落とし穴が増える。

開発段階のおすすめ方針

ローカルでは別オリジンで開発（Next.js: 3000 / Django: 8000）でよい。
フロントは fetch("/api/xxx") など相対パス前提の書き方を基本にし、開発時のみ環境変数でAPIベースURLを切り替える。
- 例）NEXT_PUBLIC_API_BASE_URL=http://localhost:8000（開発時）
- 本番は相対パス（/api/...）で同一ドメイン前提に寄せると移行が楽である。

本番公開に向けた構成パターン

パターン1：リバースプロキシでまとめる（一般的）

1つのドメイン https://example.com の直下でフロントとAPIを出し分ける。
例：Nginxの設定

# 例：/api/ を Django（gunicorn 等）へ、その他はフロントの静的ファイルへ
server {
    listen 80;
    server_name example.com;

    # フロントのビルド成果物（例：/var/www/frontend）を配信
    location / {
        # ここで Next.js の静的ファイルを返している
        root /var/www/frontend;
        try_files $uri /index.html;
    }

    # /api/ 配下は Django アプリにリバースプロキシ
    location /api/ {
        # ここでバックエンドのアプリケーションサーバへ転送している
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

パターン2：Djangoでフロントも配信

Next.js を静的エクスポートしてDjangoの静的ファイルとして提供するやり方である。
運用が単純になる一方、SSRやISR等のNextの一部機能は工夫が必要になる場合がある。

別オリジンから同一ドメインへ「移行」を楽にする実践ポイント

APIのベースパスを最初から固定（例：/api/）。
- これだけでルーティング切替やプロキシ設定が簡単になる。
フロントのAPIエンドポイントは原則相対パスで書く。
- 例：fetch("/api/summarize")
- 開発時のみ NEXT_PUBLIC_API_BASE_URL で上書き（fetch(process.env.NEXT_PUBLIC_API_BASE_URL + "/api/summarize")）できる設計にしておく。
ドメイン依存のロジックをなるべく排除。
- OAuthのリダイレクトURLやCookieドメインは環境変数で差し替えられるようにしておく。
本番の直前に整理する設定
- CORS（別公開をやめるなら不要にできる）
- CSRF（@csrf_exempt を外し、正規のトークン/認証へ）
- HTTPS化・セキュリティヘッダ・WAF/CDNなど

いつ「別URL公開」を選ぶべきか

フロントとバックでスケール要件・コスト最適化が異なる場合。
チームが完全に分離運用しており、各自が独立デプロイを行いたい場合。
マルチテナント/マイクロサービス等でバックエンドが多数存在する場合。

それ以外では、まずは同一ドメイン配下に寄せる設計を第一候補とするのが安全である。

まとめ

開発初期は別オリジンで素早く進め、本番は同一ドメイン配下にまとめる方針が扱いやすい。
別URL公開は可能だが、CORS/CSRFなどの設定が必要になる程度の認識でよい（詳細は個別要件次第）。
APIベースパスの固定・相対パスの徹底・環境変数による切替を守れば、後からの移行は比較的容易である。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up