Skip to content
Published on

Python バックエンドフレームワーク 2026 完全ガイド — FastAPI · Litestar · Starlette · Sanic · Quart · Robyn · Django Ninja · BlackSheep 徹底解説

Authors

「FastAPI は Python の事実上の標準になったが、Litestar・Robyn・Granian がその座を脅かし始めた。2026年の Python バックエンドはもはや『遅い言語』ではない。」 — TechEmpower Round 23, 2025

Python バックエンドは、2018年に FastAPI 0.1.0 が公開されてから7年で、まったく別の景色になりました。Pydantic 2 が Rust で書き直されて 5〜50 倍速くなり、Granian が uvicorn を置き換え始め、Robyn は Rust ベースのコアで「Python のように書いて Go のように速い」領域を狙っています。さらに Python 3.13 は実験的な JIT と free-threaded(no-GIL)ビルドを、Python 3.14 はそれら2つを安定化する作業を進めています。

2026年5月現在、Python バックエンドフレームワークは単独の勝者がなく、レイヤード ASGI(FastAPI/Litestar/BlackSheep)、フルスタック(Django/Django Ninja)、マイクロ ASGI(Starlette/Falcon)、Rust コア(Robyn)、クラシック WSGI(Flask/Pyramid) の 5 つの陣営に分化しています。本稿では FastAPI、Starlette、Litestar 2.x、Sanic、Quart、Robyn、Django 5.2 + Django Ninja、DRF 3.16、BlackSheep、Falcon 4、FastHTML、そして Granian・uv・Pydantic 2・msgspec まで、一気にまとめます。

1. 2026年の Python バックエンド地図 — ASGI・WSGI・Rust コアの三角構図

2026年の Python バックエンドフレームワークは、大きく 5 つのカテゴリに分けられます。

カテゴリ代表的なフレームワーク主な特徴
レイヤード ASGIFastAPI, Litestar 2.x, BlackSheep自動 OpenAPI、DI、Pydantic/msgspec
マイクロ ASGIStarlette, Falcon 4ミニマル、直接ルーティング、高性能
非同期シングルトラックSanic, Quart, Tornadoasync ファースト、直接的なハンドラ
フルスタックDjango 5.2 + Ninja, DRFORM・Admin・Auth 一体型
Rust コアRobyn, Granian(サーバー)Python インターフェイス + Rust 内部

ここでの核心は「フレームワーク選定はもはや性能ではなく運用モデル」という点です。Pydantic 2 が Rust に移ったことで FastAPI と Litestar のバリデーション速度はほぼ同じになり、Granian をサーバーに使えば uvicorn の 1.5〜2 倍のスループットが出ます。そのため選定基準は「DI モデルが好みか、コントローラベースか関数ベースか、msgspec と Pydantic のどちらが好きか」のような運用上の好みへと移っています。

2. Python 3.13 / 3.14 — JIT、Free-Threaded、Per-Interpreter GIL

Python 3.13(2024年10月)と 3.14(2025年10月)は、バックエンド性能に影響する 3 つの大きな変化をもたらしました。

第一に、実験的な JIT コンパイラ(PEP 744) です。copy-and-patch ベースの JIT が hot loop をコンパイルし、5〜15% の性能向上をもたらし、3.14 でさらに安定化しました。第二に、Free-threaded ビルド(PEP 703)python3.13t / python3.14t として配布され、GIL を完全に取り除きます。CPU バウンドなマルチスレッドワークロードで、実際にコア数だけスケールするようになります。第三に、Per-Interpreter GIL(PEP 684) は同一プロセス内で複数のサブインタプリタを立ち上げ、GIL を分離します。

ASGI フレームワークから見て一番大きな変化は free-threaded モードです。Granian はすでに 3.13t でマルチスレッドワーカーを活用し始めており、uvicorn も 3.14 からサポートを追加しました。FastAPI 自体は free-threaded モードと互換であり、Pydantic 2 も Rust コアのおかげで GIL 解放下でこそ真価を発揮します。

# free-threaded Python 3.13 のインストール(uv を使用)
uv python install 3.13t
uv venv --python 3.13t

# free-threaded モードの確認
python -c "import sys; print(sys._is_gil_enabled())"
# False が出力されれば GIL が無効化された free-threaded ビルド

# JIT コンパイラの有効化(3.13 基準)
PYTHON_JIT=1 python -c "import sys; print(sys._jit.is_enabled())"

2026年5月現在、ほとんどの ASGI フレームワークは 3.11〜3.13(stable GIL)を推奨し、3.13t / 3.14t は「実験的サポート」と表記しています。

3. ASGI 標準 — Starlette が敷いたレール

FastAPI と Litestar と Quart の共通の祖先が ASGI(Asynchronous Server Gateway Interface)仕様です。ASGI は WSGI の同期モデルを非同期・双方向に拡張したもので、HTTP だけでなく WebSocket・SSE・Lifespan イベントまで扱います。Starlette はこの ASGI の上に、ルーティング・ミドルウェア・テストクライアント・セッション・CORS・静的ファイルなど「非同期マイクロフレームワークの標準部品」を提供しています。

FastAPI は Starlette を依存として直接取り込み、Pydantic バリデーション層と DI(Depends)を載せた形です。Litestar は Starlette を使わずに独自の ASGI 実装を持っていますが、ミドルウェア構造は非常に似ています。BlackSheep も ASGI の上に独自ルーターを載せた構成です。

# Starlette 単独で書ける、もっともシンプルな ASGI アプリ
from starlette.applications import Starlette
from starlette.responses import JSONResponse
from starlette.routing import Route

async def homepage(request):
    return JSONResponse({"hello": "world"})

routes = [
    Route("/", endpoint=homepage),
]

app = Starlette(debug=True, routes=routes)
# uvicorn main:app --reload で起動

この 25 行が事実上 FastAPI/Litestar/BlackSheep の「共通項」です。各フレームワークはここに何を載せるかで差別化しています。

4. FastAPI — 事実上の標準、自動 OpenAPI

FastAPI(Sebastián Ramírez, 2018〜)は、2026年現在も Python バックエンドの事実上の標準です。GitHub スターは 80K を超え 90K に迫り、PyPI ダウンロードは月 200M を突破しました。コアバリューは次の 3 点に集約できます。

第一に、Pydantic ベースの自動バリデーション — 関数のシグネチャに型ヒントを書くだけで入出力をバリデーションし、OpenAPI スキーマを自動生成します。第二に、DI(Depends) — 関数の引数に Depends(dependency) と書けば依存性が注入され、スコープ管理も自動です。第三に、Swagger/ReDoc の自動ホスティング/docs/redoc が無料で提供されます。

# FastAPI 標準パターン
from fastapi import FastAPI, Depends, HTTPException, status
from pydantic import BaseModel, EmailStr
from typing import Annotated

app = FastAPI(title="users-api", version="2.0.0")

class UserCreate(BaseModel):
    email: EmailStr
    name: str

class User(BaseModel):
    id: int
    email: EmailStr
    name: str

async def get_db():
    db = AsyncSessionMaker()
    try:
        yield db
    finally:
        await db.close()

DBSession = Annotated[AsyncSession, Depends(get_db)]

@app.post("/users", response_model=User, status_code=status.HTTP_201_CREATED)
async def create_user(payload: UserCreate, db: DBSession) -> User:
    existing = await db.execute(select(UserTable).where(UserTable.email == payload.email))
    if existing.scalar_one_or_none():
        raise HTTPException(status_code=409, detail="email already exists")
    row = UserTable(email=payload.email, name=payload.name)
    db.add(row)
    await db.commit()
    await db.refresh(row)
    return User.model_validate(row)

FastAPI の弱点もはっきりしています。DI ツリーが複雑になるほどデバッグが難しくなる うえ、コントローラ単位の構造がないため大規模プロジェクトではルートが散らばります。この 2 つに真正面から取り組もうとしたのが Litestar です。

5. Litestar 2.x — コントローラベースの高性能 ASGI

Litestar(旧 Starlite、2024年にリブランド)は FastAPI の代替として出発し、2.x で独自のエコシステムを築きました。2026年5月時点で GitHub スター 6K+ であり、主な差別化要素は次のとおりです。

  • コントローラクラスベースのルーティングController を継承して、1 つのクラスが 1 つのリソースを担当
  • msgspec 優先サポート — Pydantic より速いシリアライズオプションを提供(Pydantic もサポート)
  • DTO パターン内蔵 — DB モデルと API モデルを分離して over-fetch を防止
  • DI にプラグインシステム — SQLAlchemy、SAQ、Redis などが公式プラグイン
  • OpenAPI 3.1 を優先 — JSON Schema 2020-12 互換
# Litestar 2.x のコントローラベースパターン
from litestar import Controller, Litestar, get, post
from litestar.di import Provide
from msgspec import Struct

class UserCreate(Struct):
    email: str
    name: str

class User(Struct):
    id: int
    email: str
    name: str

class UserController(Controller):
    path = "/users"

    @post("/")
    async def create(self, data: UserCreate, repo: UserRepo) -> User:
        return await repo.create(data)

    @get("/{user_id:int}")
    async def get_one(self, user_id: int, repo: UserRepo) -> User:
        return await repo.get(user_id)

async def provide_repo() -> UserRepo:
    return UserRepo()

app = Litestar(
    route_handlers=[UserController],
    dependencies={"repo": Provide(provide_repo)},
)

TechEmpower Round 23(2025)では、Litestar + Granian の組み合わせが plaintext で 1.2M req/s を記録し、FastAPI + uvicorn(720K)の 1.6 倍のスループットを見せました。ただし、この差の大半は Granian によるものであり、FastAPI も Granian に載せれば Litestar とほぼ同水準になります。

6. Starlette 単独 — ミニマリストの選択

FastAPI/Litestar の抽象化が重く感じるとき、Starlette を直接使う選択肢があります。Pydantic がないのでバリデーションは自分で書く必要がありますが、ルーティング・ミドルウェア・WebSocket・テストクライアントはすべて揃っています。マイクロサービスを 1〜2 個軽量に立ち上げたいときや、他のフレームワークからルートをいくつかだけ切り出したいとき に最適です。

Encode(Tom Christie)チームが作る他の姉妹ライブラリ — httpxdatabasesorjson — と組み合わせると、意外にも強力なスタックになります。2026年でも Encode は Starlette + httpx + databases の組み合わせを「最小限の ASGI マイクロスタック」として推奨しています。

7. Sanic — 非同期シングルトラックの元祖

Sanic(2016〜)は FastAPI より先に登場した async ファーストな Python フレームワークです。2026年5月現在 GitHub スター 18K+、23.x リリースで安定化しました。Sanic は ASGI に従わず、独自のサーバー(Sanic Server) を持っており、これが長所でもあり短所でもあります。

長所:サーバーまで一体化しているため外部依存が少なく、24.x から HTTP/3 サポートが追加されました。短所:ASGI ミドルウェアエコシステムと互換性がありません。Flask 風のデコレータルーティングが好きならば Sanic は今でも魅力的であり、Sanic 24 の app.ext エクステンションで OpenAPI・Pydantic 統合も一段スムーズになりました。

# Sanic 23.x 非同期ハンドラ
from sanic import Sanic, json
from sanic.request import Request

app = Sanic("UsersApi")

@app.post("/users")
async def create_user(request: Request):
    data = request.json
    user_id = await create_in_db(data["email"], data["name"])
    return json({"id": user_id, **data}, status=201)

@app.get("/users/<user_id:int>")
async def get_user(request: Request, user_id: int):
    row = await fetch_user(user_id)
    if not row:
        return json({"error": "not found"}, status=404)
    return json(row)

8. Quart — 非同期 Flask、同じ API・異なるランタイム

Quart(Pallets Projects, 2017〜)は「Flask と同じ API を持つ ASGI フレームワーク」が目標です。Flask のコードをほぼそのまま移植でき、ルート関数を async def に変えるだけで済みます。2025年から Pallets 公式プロジェクトに組み込まれ、Flask チームが直接管理しています。

Flask のコードベースを持つ会社が非同期へ段階的に移行する場合、Quart はもっとも自然な選択です。Flask-Login・Flask-WTF のような Flask 拡張の 90% は Quart でも動作します。

9. Flask 3.x — クラシック WSGI は健在

Flask 3.0(2023)と 3.1(2024)は非同期を部分的にサポートしますが、本質的には WSGI フレームワークです。2026年でも PyPI ダウンロードは月 100M を超え、小規模な社内ツール・管理ページ・Webhook レシーバーの領域では圧倒的です。Flask 3.1 では trusted_hosts・async view の安定化・MIME ヘッダの整理が入り、いまでも「30 行で完結するサーバー」をもっとも素早く立ち上げられるフレームワークです。

10. Django 5.2 + Django Ninja — フルスタックの逆襲

Django 5.2 LTS(2025年4月)はフルスタックフレームワークの頂点です。ORM・Admin・Auth・Migrations・Forms・Templates・Caching が一体化しており、5.x から async def view と非同期 ORM が部分的にサポートされます。Sentry、Disqus、Mozilla、Instagram(初期)のような大規模サービスがいまだに Django を使っています。

問題は「Django ORM はいいが DRF は重い」という不満で、その答えが Django Ninja(2020〜)です。Django Ninja は FastAPI とほぼ同じ API(型ヒントベース、Pydantic バリデーション、自動 OpenAPI)を Django の上に載せた形で、2026年5月時点で GitHub スター 7K+ を超えました。

# Django Ninja — FastAPI ライクな API + Django ORM
from ninja import NinjaAPI, Schema
from django.shortcuts import get_object_or_404
from .models import User as UserModel

api = NinjaAPI(version="2.0.0")

class UserIn(Schema):
    email: str
    name: str

class UserOut(Schema):
    id: int
    email: str
    name: str

@api.post("/users", response={201: UserOut})
def create_user(request, payload: UserIn):
    user = UserModel.objects.create(email=payload.email, name=payload.name)
    return 201, user

@api.get("/users/{user_id}", response=UserOut)
def get_user(request, user_id: int):
    return get_object_or_404(UserModel, pk=user_id)

Django REST Framework(DRF)3.16(2025)も依然として強力で、特に ViewSet・Serializer・Permission のような「エンタープライズ機能」がうまく組まれたプロジェクトでこそ真価を発揮します。新規 API ならば Django Ninja、既存の DRF コードベースはそのまま維持するというのが 2026年の一般的な推奨です。

11. Robyn — Rust コアを持つ Python フレームワーク

Robyn(Sanskar Jethi, 2021〜)は Python でハンドラを書きつつ、ルーター・サーバー・HTTP パースは Rust(Actix ベース)で動かすハイブリッドフレームワークです。2026年5月時点で GitHub スター 4K+、0.65 バージョンで安定化しました。

# Robyn — Python ハンドラ + Rust サーバー
from robyn import Robyn

app = Robyn(__file__)

@app.get("/")
async def hello():
    return "Hello, Robyn!"

@app.post("/users")
async def create_user(request):
    body = request.json()
    return {"id": 1, **body}

app.start(port=8080)

Robyn は TechEmpower のようなマイクロベンチで FastAPI の 2〜3 倍のスループットを示しますが、エコシステムが小さいことが弱点です。SQLAlchemy・Redis・Celery のような標準ライブラリはそのまま使えますが、ミドルウェアや認証プラグインの量は FastAPI/Litestar の 10 分の 1 程度です。

12. BlackSheep — .NET の影響を受けた ASGI

BlackSheep(Roberto Prevato, 2018〜)は ASP.NET Core の影響を受けた Python ASGI フレームワークです。コントローラ・DI・フィルタ・ミドルウェアの構造は ASP.NET と非常に似ており、OpenAPI・OAuth2・JWT 統合が標準で含まれています。GitHub スター 1.9K+ と相対的に小さいですが、マイクロソフト出身のエンジニアの間では根強いファン層を持っています。

# BlackSheep — DI とコントローラ
from blacksheep import Application, get, post
from blacksheep.server.controllers import Controller, ApiController
from pydantic import BaseModel

class UserCreate(BaseModel):
    email: str
    name: str

class UsersController(ApiController):
    @classmethod
    def route(cls) -> str:
        return "/users"

    @post()
    async def create(self, payload: UserCreate, repo: UserRepo) -> dict:
        user_id = await repo.create(payload)
        return {"id": user_id, "email": payload.email}

app = Application()
app.services.add_scoped(UserRepo)

13. Falcon 4 — ミニマル高性能

Falcon(2013〜)は「WSGI でもっとも速いフレームワーク」として始まり、4.x(2024)で ASGI も一級でサポートします。ミドルウェアとリソースクラスだけのミニマルな構造のため、マイクロサービスや API ゲートウェイ用途で人気です。GitHub スター 9.6K+ で、特に LinkedIn・Cronitor などの企業がバックエンドの一部に採用しています。

14. Tornado / Bottle / CherryPy / Pyramid — レガシーの居場所

Tornado(2009〜)は ASGI 以前の時代の非同期フレームワークで、Facebook で作られた後 OSS 化されました。2026年でも Jupyter・IPython・一部の金融系システムで生きていますが、新規採用はほとんどありません。

Bottle(単一ファイルの WSGI)、CherryPy(古典)、Pyramid(中規模向け)はいずれもパッケージとしては存在し続けていますが、文脈は「旧式プロジェクトの保守」が大半です。

15. FastHTML / HTMX — HTML ファーストのルネサンス

FastHTML(Jeremy Howard, fast.ai, 2024)は「JavaScript ビルドなしで Python でフルスタック」を目指した新しいフレームワークです。HTMX と組み合わせてサーバー側で HTML フラグメントを返す方式により、SPA の複雑さを回避します。2026年5月時点で GitHub スター 6K+、急成長中です。

# FastHTML — HTMX フレンドリーなフルスタック
from fasthtml.common import *

app, rt = fast_app()

@rt("/")
def get():
    return Titled("Users",
        Form(hx_post="/users", hx_target="#list")(
            Input(name="name", placeholder="name"),
            Button("Add"),
        ),
        Ul(id="list"),
    )

@rt("/users")
def post(name: str):
    return Li(name)

serve()

emmett、Masonite、Reflex(旧 Pynecone)のようなフルスタックフレームワークもありますが、採用率は FastHTML に比べると低いです。

16. ASGI サーバー — Uvicorn · Hypercorn · Granian · Daphne

ASGI フレームワークは自分自身では実行せず、ASGI サーバーの上で動きます。2026年の主な選択肢は次のとおりです。

サーバー特徴性能ランク
Uvicorn標準、uvloop + httptoolsベースライン
HypercornHTTP/2・HTTP/3 サポート同等
GranianRust ベース、gunicorn ワーカー内蔵1.5〜2 倍速い
DaphneDjango Channels 用WebSocket に強い

Granian(Emmett の作者 Giovanni Barillari, 2022〜)はもっとも興味深いサーバーです。Rust ベースのコアで uvicorn の 1.5〜2 倍のスループットを示し、WSGI・ASGI・RSGI(Rust Server Gateway Interface)をすべてサポートします。2025年から fly.io・Render・Railway のような PaaS の公式推奨サーバーの 1 つになりました。

# Granian で FastAPI を起動
granian --interface asgi --workers 4 --host 0.0.0.0 --port 8000 main:app

# Uvicorn クラシック
uvicorn main:app --workers 4 --host 0.0.0.0 --port 8000

# Hypercorn(HTTP/2)
hypercorn -k uvloop --workers 4 -b 0.0.0.0:8000 main:app

WSGI 側はいまだに Gunicorn(2010〜)が標準であり、uWSGI は保守のみの状態です。

17. Pydantic 2 · msgspec · attrs — バリデーションとシリアライズ

Pydantic 2(2023)はコアを Rust(pydantic-core)で書き直し、Pydantic 1 比で 5〜50 倍速くなりました。FastAPI は 0.100 から Pydantic 2 専用に切り替え、Litestar・Django Ninja・BlackSheep のいずれも Pydantic 2 を一級でサポートします。

msgspec(Jim Crist-Harif, 2022〜)は Pydantic の強力なライバルです。C 拡張ベースで Pydantic 2 よりも速く、MessagePack・JSON・YAML・TOML をすべて扱います。Litestar は msgspec を既定のシリアライズエンジンとして採用しました。

# Pydantic 2 vs msgspec — 同じデータモデル
from pydantic import BaseModel, EmailStr
import msgspec

class UserP(BaseModel):
    id: int
    email: EmailStr
    name: str

class UserM(msgspec.Struct):
    id: int
    email: str
    name: str

# シリアライズ性能(1M req 基準、M1 Pro)
# Pydantic 2:  ~1.2s
# msgspec:     ~0.4s
# stdlib json: ~0.6s

attrs(2015〜)は dataclass の精神的な祖先であり、いまでもバリデーションなしのデータクラス用途で広く使われています。marshmallow は Flask/Django 文脈で命脈を保っています。

18. uv · Poetry · Hatch · PDM · Pixi — パッケージ管理の新しい風景

Astral が作った uv(0.5+, 2024)は 2026年には事実上の標準になりました。Rust ベースで pip 比 10〜100 倍速く、pip・pip-tools・virtualenv・pyenv・poetry の役割を 1 つのバイナリに統合します。

# uv で新規プロジェクトを開始
uv init my-api
cd my-api

# 依存関係を追加
uv add fastapi uvicorn[standard] sqlalchemy pydantic

# Python バージョンのインストール + venv 作成
uv python install 3.13
uv venv --python 3.13

# 依存関係をロック + 同期
uv lock
uv sync

# スクリプト実行
uv run uvicorn main:app --reload

# ツールのインストール(グローバル)
uv tool install ruff

Poetry 1.8(2024)も依然として強力ですが、uv の速さとシンプルさが急速に侵食しています。PDM・Hatch・Rye はそれぞれのファン層を持ち、Pixi(prefix.dev)は conda エコシステムと互換な代替として、データ・ML 文脈で人気です。

19. ORM — SQLAlchemy 2 · SQLModel · Tortoise · Piccolo · Beanie

ORM備考推奨される文脈
SQLAlchemy 2標準、async を一級でサポートあらゆる本格的な SQL ワークロード
SQLModelFastAPI 作者、Pydantic + SQLAlchemyFastAPI + SQL のクイックスタート
Tortoise ORMasync ファースト、Django ライクSanic/Quart 文脈
Piccolo ORMasync、強い型付けPostgres 専用
BeanieMongoDB ODM非 RDB ワークロード
Peewee軽量・同期小さなスクリプト・CLI
Edgyasync、Tortoise ベース新興、実験的

SQLAlchemy 2.x(2023〜)は非同期を一級でサポートしており、select() ベースの新 API は mypy・Pyright と非常に相性がよいです。SQLModel は同じクラスを ORM と Pydantic モデルとして同時に使えるので FastAPI ユーザーにとって自然ですが、複雑なクエリは結局 SQLAlchemy コアに落ちます。

# SQLAlchemy 2 の async パターン
from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column
from sqlalchemy import select

class Base(DeclarativeBase):
    pass

class User(Base):
    __tablename__ = "users"
    id: Mapped[int] = mapped_column(primary_key=True)
    email: Mapped[str]
    name: Mapped[str]

engine = create_async_engine("postgresql+asyncpg://...")

async def find_by_email(db: AsyncSession, email: str) -> User | None:
    stmt = select(User).where(User.email == email)
    result = await db.execute(stmt)
    return result.scalar_one_or_none()

20. 型チェッカ・リンタ — mypy · Pyright · Ruff · Pyrefly

型チェッカはバックエンドのコード品質の中核です。2026年5月現在、選択肢は次の 4 つに整理できます。

  • mypy 1.13+ — PEP 484 ベース、標準でもっとも古いツール
  • Pyright 1.1+ — マイクロソフト製、VS Code Pylance のコア、非常に速い
  • Pyrefly — Meta が 2025年に公開、mypy 互換 + Rust ベース
  • Ruff 0.7+ — Astral、リンタ + フォーマッタ + import 整理を統合、Rust ベース

Ruff は flake8・black・isort・pyupgrade・bandit の約 90% の機能を単一バイナリで置き換え、100 倍近い速度を示します。2026年の標準コンボは「依存管理は uv、リント・フォーマットは Ruff、型チェックは Pyright」です。

# pyproject.toml — 2026年の標準コンボ
[project]
name = "users-api"
requires-python = ">=3.13"
dependencies = [
    "fastapi>=0.115",
    "uvicorn[standard]>=0.32",
    "pydantic>=2.9",
    "sqlalchemy>=2.0",
]

[tool.ruff]
line-length = 100
target-version = "py313"

[tool.ruff.lint]
select = ["E", "F", "I", "B", "UP", "ASYNC"]

[tool.pyright]
pythonVersion = "3.13"
typeCheckingMode = "strict"

21. テスト — pytest 8 · pytest-asyncio · hypothesis · Locust

pytest 8(2024)はいまでも Python テストの標準であり、pytest-asyncio 0.23+ は ASGI アプリのテストを簡潔にしてくれます。FastAPI/Starlette/Litestar のいずれも TestClient(httpx ベース)を提供しており、in-process でテストできます。

# FastAPI + pytest-asyncio + httpx TestClient
import pytest
from httpx import AsyncClient, ASGITransport
from main import app

@pytest.mark.asyncio
async def test_create_user():
    async with AsyncClient(transport=ASGITransport(app=app), base_url="http://test") as ac:
        r = await ac.post("/users", json={"email": "a@b.com", "name": "alice"})
        assert r.status_code == 201
        assert r.json()["email"] == "a@b.com"

Hypothesis は property-based テストの標準であり、Locust は負荷テストの標準です。小さなシナリオなら httpx + asyncio でも十分です。

22. 認証 — Authlib · python-jose · PyJWT · Authentik · Logto

Python バックエンドの認証は、通常 2 層に分かれます。トークン検証ライブラリ(PyJWT、python-jose、Authlib)が JWT のデコードや OIDC フローを扱い、外部 ID プロバイダ(Authentik、Authelia、Logto、Auth0、Cognito)がユーザー/セッションを管理します。

2026年現在の新規プロジェクトでの標準コンボは次のとおりです。

  • JWT 検証:PyJWT(もっとも単純)または Authlib(OIDC が必要なとき)
  • セッション管理:Redis ベースのセッション(Starlette/Litestar のミドルウェア)
  • ID プロバイダ:セルフホストなら Authentik/Logto、SaaS なら Auth0/Clerk
  • 権限管理:単純な RBAC は自前で、複雑なら OPA(Open Policy Agent)または Permit.io

23. デプロイ — Docker · Granian · Lambda · Modal · Vercel

デプロイ形態推奨スタック備考
コンテナDocker + Granian/Uvicorn + Gunicorn標準
サーバーレスAWS Lambda + Mangum + FastAPIコールドスタート 約 300ms
AI ワークロードModal, Replicate, Beam, HF SpacesGPU の自動スケール
エッジVercel Python, Cloudflare Workers Pythonbeta、制約多し
マネージドRender, Railway, Fly.ioPaaS 標準
# 2026 標準 FastAPI Dockerfile(uv + Granian)
FROM python:3.13-slim AS base

ENV UV_SYSTEM_PYTHON=1 PYTHONDONTWRITEBYTECODE=1
RUN pip install --no-cache-dir uv==0.5.*

WORKDIR /app
COPY pyproject.toml uv.lock ./
RUN uv sync --frozen --no-dev

COPY . .
RUN uv sync --frozen --no-dev

EXPOSE 8000
CMD ["uv", "run", "granian", "--interface", "asgi", "--workers", "4", \
     "--host", "0.0.0.0", "--port", "8000", "main:app"]

Lambda デプロイは Mangum アダプタを介して FastAPI/Starlette を Lambda ハンドラとしてラップします。コールドスタートは Pydantic 2 の導入後 0.2〜0.4 秒水準まで下がり、AWS の SnapStart for Python(2025)を有効化すれば 50ms 以下も可能です。

24. 実運用での導入事例 — Netflix · Microsoft · NAVER · Mercari

Netflix は社内の ML サービング・オーケストレーションで FastAPI を広範に使っていると 2023 PyCon の基調講演で明かしました。特にレコメンドシステムの推論ゲートウェイは FastAPI + Pydantic 2 の上に載っており、GraphQL ゲートウェイは Starlette + Strawberry です。

Microsoft は Azure ML と一部の OpenAI 関連インフラで FastAPI を使っています。Sebastián Ramírez がマイクロソフトに加わったのも、この流れの延長線上です。

NAVER 検索チーム は ML サービングと社内ツールの一部に FastAPI を採用しており、CoupangKakao のバックエンドの一部チームも FastAPI を使っています。トス(Toss) はコアの決済は JVM ですが、社内ツールと ML サービスでは FastAPI を使っています。

日本では メルカリ(Mercari) が一部のマイクロサービスに FastAPI を導入し、LINE YahooサイバーエージェントDeNA も ML・データパイプラインで広範に使っています。Instagram は Django をコアで使い続けるもっとも大きなケーススタディです。

25. 意思決定ツリー — どのフレームワークを選ぶか

2026年5月時点での推奨意思決定ツリーは次のとおりです。

  • REST API だけ素早く作りたい → FastAPI(エコシステム最大)または Litestar(構造重視)
  • フルスタック・管理者ページ・ORM が必要 → Django 5.2 + Django Ninja(新規)または DRF(既存)
  • 性能が絶対的な価値 → Litestar + Granian、または Robyn
  • 小さなマイクロサービスを複数 → Starlette または Falcon 4
  • 非同期シングルトラック + Flask スタイル → Sanic または Quart
  • Flask のコードベースを非同期へ段階移行 → Quart
  • HTML ファースト・JS ビルド回避 → FastHTML + HTMX
  • .NET 出身チーム → BlackSheep

選定の中心には常に「チームに馴染んだパラダイム + バリデーションエンジンの好み(Pydantic vs msgspec)+ サーバー(Granian vs Uvicorn)」の 3 軸があります。

26. 移行ガイド — Flask/Django から FastAPI/Litestar へ

既存の Flask コードを ASGI に移すとき、もっとも自然なステップは Quart に移したあとルートごとに FastAPI/Litestar のハンドラへと切り出していくことです。Django から FastAPI に移すときは、一気に移すのではなく Django Ninja で /api/v2 エンドポイントを追加して段階的に移行する方が安全です。

# Django + Django Ninja を 1 プロジェクトで併用するパターン
# urls.py
from django.urls import path
from ninja import NinjaAPI
from .api import api as v2_api

urlpatterns = [
    path("admin/", admin.site.urls),
    # 既存の DRF ルートを維持
    path("api/v1/", include("legacy.urls")),
    # 新規は Ninja で
    path("api/v2/", v2_api.urls),
]

移行の要諦は「一気に全部変えない」です。認証ミドルウェア・セッションストア・DB コネクションプールを共有しながらルート単位で移していけば、1〜2 か月で大きなリスクなく転換できます。

27. むすび — Python バックエンドは 2026年でも第一候補

Python バックエンドの 2026年の風景は、一言でまとめれば「選択肢が十分に増えた」です。FastAPI は依然として標準ですが、Litestar・Robyn・Django Ninja がそれぞれの領域で強力であり、Granian・uv・Pydantic 2・msgspec のような Rust ベースのツールが「遅い言語」という古い評判を覆しています。

新規プロジェクトなら「FastAPI + Pydantic 2 + SQLAlchemy 2 + Granian + uv + Ruff + Pyright」がもっとも安全な出発点で、性能が本当に絶対的な価値であれば「Litestar + msgspec + Granian」でもう一段先に進めます。Django エコシステムなら「Django 5.2 + Django Ninja + uv」がフルスタックをもっともスムーズに扱えます。2026年の Python バックエンドはもはや「Java より遅い代替」ではなく、「Java と同じくらい速く、かつコードが 4 分の 1 で済む、最初の選択肢」です。

参考資料