Webアプリケーションを作るとき、「HTTPリクエストを受け取って解析する」「URLに応じて処理を振り分ける」「レスポンスを組み立てて返す」といったどのアプリでも共通する処理が大量にある。

フレームワークを使わずにこれらを全て自力で書くと何が起きるか。たとえば「ユーザー一覧を返すAPI」を作るだけでも、TCPソケットの待ち受け、HTTPプロトコルの解析、URLのパース、Content-Typeの判定、レスポンスヘッダの構築といった処理を全て書く必要がある。

アプリケーション固有のロジック（DBからユーザーを取得して返す）はこの中のごくわずかで、残りは「どのアプリでも同じ」コードである。

フレームワークはこの「どのアプリでも同じ」部分をあらかじめ用意してくれる。開発者はフレームワークが用意した「型」に沿って、アプリケーション固有のビジネスロジックだけを書けばよい。

どちらも「誰かが書いたコードを再利用する」という点は同じだが、制御の主導権が誰にあるかが異なる。

• ライブラリ
  • 自分のコードから呼び出す。呼ぶタイミングも使い方も自分で決める
• フレームワーク
  • フレームワークが自分のコードを呼び出す。処理の流れはフレームワークが決め、開発者は「穴埋め」する形になる

この「制御の逆転」がフレームワークの本質的な特徴である。

ライブラリの場合:
  自分のコード → ライブラリを呼ぶ → 結果を受け取る
  （呼ぶタイミングは自分が決める）

フレームワークの場合:
  フレームワーク → 自分のコードを呼ぶ → 結果を返す
  （呼ぶタイミングはフレームワークが決める）

• 車輪の再発明をしない
  • ルーティング、リクエスト解析、エラーハンドリングなど、どのアプリでも必要な基盤コードを自分で書かなくてよい
• チームで書き方が揃う
  • フレームワークが「こう書け」というルールを決めてくれるため、人によって構成がバラバラにならない
• エコシステムの恩恵
  • フレームワークに対応したプラグイン・ミドルウェア・ドキュメントが豊富に存在し、機能追加が楽になる
• セキュリティの基本が担保される
  • フルスタックフレームワーク（Django, Rails等）ではCSRF対策やSQLインジェクション防止が標準で組み込まれている
  • マイクロフレームワークでも入力バリデーション等の仕組みが提供される場合が多い

• 学習コスト
  • フレームワーク固有の書き方やルールを学ぶ必要がある。フレームワークが変われば学び直し
• 自由度の制約
  • フレームワークが想定していない処理をしたいとき、回り道が必要になることがある
• ブラックボックス
  • 内部でどんな処理が行われているか把握しづらい。問題が起きたときにデバッグが難しい場合がある
• バージョンアップへの追従
  • フレームワークのメジャーバージョンが上がると、既存コードの書き換えが必要になることがある

Webフレームワークが提供する最も基本的な機能がルーティングである。

ルーティングとは、「このURLにこのHTTPメソッドでリクエストが来たら、この関数を実行する」という対応付けのこと。ルーティングがなければ、リクエストのURLを自分でパースして if url == "/products" and method == "GET": のような分岐を延々と書くことになる。エンドポイントが増えるたびにこの分岐が肥大化し、保守不能になる。

フレームワークはこの対応付けを宣言的に記述する仕組みを提供してくれる。開発者は「このURLに来たらこの処理」を定義するだけでよく、URL解析やメソッド判定の実装を気にする必要がない。

たとえばECサイトであれば、以下のような対応付けになる。

• GET /products → 商品一覧を返す
• GET /products/123 → ID=123の商品詳細を返す
• POST /products → 新しい商品を登録する
• DELETE /products/123 → ID=123の商品を削除する

同じURLでもHTTPメソッド（GET/POST/PUT/PATCH/DELETE）によって異なる処理が実行される。これにより、「リソース（商品、ユーザー等）に対する操作」を直感的に表現できる。

DBアクセス（ORM）、認証、テンプレートエンジン、管理画面など、Webアプリに必要な機能を全部入りで提供するフレームワーク。

フレームワークの「流儀」に従えば少ないコードで多くのことができる。一方、流儀から外れた実装をしようとすると途端に複雑になる。

向いているケース

• Webアプリを最速でプロトタイピングしたいとき
  • プロジェクト雛形の自動生成コマンド（Djangoなら django-admin startproject）を実行するだけで、DB接続・認証・管理画面が最初から動く
• 管理画面やユーザー認証を一から作りたくないとき
  • これらを自作すると数週間かかるが、フルスタックFWなら標準搭載されている
• チームメンバーのスキルにばらつきがあり、統一された書き方が欲しいとき
  • フレームワークが「ここにこう書け」と決めてくれるので、設計力に依存しない

向いていないケース

• APIだけ提供してフロントは別チームが作るとき
  • テンプレートエンジンや管理画面など使わない機能が多く、無駄に重い
• フレームワークが想定していない特殊な処理が多いとき
  • 流儀から外れるとフレームワークと戦う時間が増える
• マイクロサービスのように小さい単位で動かしたいとき
  • フルスタックFWは1つのアプリとして動く前提で設計されている

例

• サーバーサイドでHTMLを動的に生成する仕組み。バックエンドの処理結果をHTMLに埋め込んで、完成したページをブラウザに返す
• HTMLの中に {{ user.name }} のように変数を埋め込んでおき、実行時に実際の値に置き換える
• フルスタックフレームワークではこの仕組みが標準搭載されているため、バックエンドだけで画面表示まで完結できる
• 近年はフロントエンドをReact/Vue等のSPAで作り、バックエンドはAPI（JSON）だけを返す構成が主流になっている。この構成ではテンプレートエンジンは使わず、画面の組み立てはフロントエンドが行う
  • 近年の選定の流れについては、後述の📄【Webアプリ開発2026 #4】フレームワーク を参照

フルスタックフレームワークの多くはMVC（Model-View-Controller）という設計パターンを採用している。「リクエストが来たとき、どのファイルに何を書けばいいか」のルールを決めてくれるもので、以下のような流れで処理が行われる。

Copy

ブラウザからのリクエスト
  ↓
Controller（受付係）
  - URLとHTTPメソッドを見て、どの処理を実行するか判断
  - 必要に応じてModelを呼び出す
  ↓
Model（データ担当）
  - DBからデータを取得する
  - ビジネスロジック（計算や検証）を実行する
  ↓
View（表示担当）
  - Modelから受け取ったデータを使ってHTML（またはJSON）を組み立てる
  ↓
ブラウザにレスポンスを返す

Djangoでは「MTV（Model-Template-View）」という呼び方をするが、役割の分担は同じである（Template=MVCのView、View=MVCのController に対応）。

ルーティングとHTTP処理だけを提供する最小限のフレームワーク。

DB接続、認証、バリデーションなどの機能は付属せず、必要に応じて自分でライブラリを選んで組み合わせる。フルスタックと比較して自由度が高い反面、設計を自分で決める必要がある。

たとえばFastAPIで商品管理APIを作る場合、以下のようなライブラリを自分で選定・導入することになる。

フルスタックフレームワーク（Django等）ではこれらが最初から同梱されているため選定の手間がない。マイクロフレームワークでは「何を使うか」「どう組み合わせるか」を自分で決める必要がある代わりに、不要な機能を含めずに済む。

向いているケース

• フロントエンドが分離されていて、バックエンドはAPIだけ提供するとき
  • JSONを返すだけなのでテンプレートエンジン等が不要
• 使いたいDBライブラリや認証方式が決まっていて、フレームワークのデフォルトに縛られたくないとき
  • 技術選定の自由度が必要な場面
• マイクロサービス構成で、1サービスあたりの規模が小さいとき
  • 軽量な分、起動が速くリソース消費も少ない

向いていないケース

• 管理画面やユーザー登録画面をすぐに欲しいとき
  • これらを自作する工数がそのままコストになる
• 設計経験が浅いチームで、構成の指針がないまま開発を始めるとき
  • フレームワークが構成を決めてくれないため、人によってバラバラになりやすい

参考程度にトレンド載せているサイトでも見る

https://2025.stateofjs.com/en-US

• React > Vue.js, Angular > Svelte
  • Svelte が毎年少しずつ上がっている
  • それ以外はほぼ横ばい

• 統計的な興味はhttps://svelte.jp/ がトップ
• 新しく注目されている、これから使われるようになるか否か
  • https://www.qwik.dev/
  • https://www.solidjs.com/

CSR用のフレームワークと、それを利用してSSRなどを行うメタフレームワークの2つが提供されるケースがほとんど。

ここまでの内容を踏まえて、両者を比較する。

「どちらを選ぶか」は以下のような問いに答えることで決まる。

• 作るものは何か
  • 管理画面付きのWebアプリケーション → フルスタックが強い。Django なら django-admin startproject で即座に管理画面が手に入る
  • モバイルアプリやSPAのバックエンドAPI → マイクロで十分。画面を返す必要がないのでテンプレートエンジン等が不要
  • バックエンドをAPIとして切り出すことで、Webブラウザ・モバイルアプリ・社内ツール・外部パートナーなど複数のクライアントから同じ機能を使い回せる。画面ごとにバックエンドを作り直す必要がなくなる
  • フロント・バック分離が主流になった背景
    • フロントとバックでそれぞれ専門性が高まり、独立して開発・デプロイできた方が効率的になった
    • 同じAPIを複数のクライアント（Web、モバイル、外部連携）から使い回せる
    • この構成ではバックエンドにテンプレートエンジンやHTMLレンダリングが不要になるため、マイクロフレームワークが自然な選択肢になる
• チームの構成はどうか
  • フロントとバックが同じチーム → フルスタックで一気通貫に作る方が効率的な場合がある
  • フロントとバックが別チーム・別リポジトリ → バックエンドはAPI専用のマイクロFWで作り、契約（APIスキーマ）だけ共有する方がお互い独立して動ける
• アプリの規模はどのくらいか
  • エンドポイントが数個〜十数個程度の小さなAPI → フルスタックは過剰。ORM・認証・管理画面・テンプレートなど使わない機能が大量に付いてきて、起動も遅くなりデプロイサイズも大きくなる
  • ある程度の規模で、DB・認証・管理画面を全て必要とする → フルスタックの「全部入り」が活きる
• 今後の拡張をどう見込んでいるか
  • 1つのアプリとして成長させていく → フルスタックの統一された構成が活きる
  • 機能ごとにサービスを分割する予定がある → マイクロFWの方が1サービスを軽量に保てる

開発後、実際に本番で運用し始めると以下のような差が出てくる。

フルスタックフレームワークは「どこに何を書くか」をMVC等のパターンで決めてくれる。一方マイクロフレームワークにはそのような強制力がない。何もルールを決めずに開発を始めると、ファイルの置き場所やロジックの分離が人によってバラバラになり、コードベースが成長するにつれて保守困難になる。

そのため、マイクロフレームワークを使う場合はチームで「構造のルール」を決める必要がある。最もよく使われるのが「レイヤード（層）構造」で、コードを役割ごとの層に分ける設計パターンである。詳細は別ページで扱う。

app/
├── api/              ← HTTPの受け口（Router）
├── usecase/          ← ビジネスロジック（Service / UseCase）
├── domain/           ← データ構造やビジネスルールの定義
└── infrastructure/   ← DB・外部APIとの具体的なやり取り

なぜ層を分けるのか（運用観点）

• テストしやすい
  • 各層を独立してテストできる。DBなしでビジネスロジックだけテスト可能
• 変更に強い
  • DBをPostgreSQLからMySQLに変えても、infrastructure層だけ書き換えればよい
• 分担しやすい
  • 「API層はAさん、infrastructure層はBさん」と並行作業できる