Python エコシステム 2026 完全ガイド — Python 3.13 · FastAPI · Django 5 · Litestar · SQLAlchemy 2 · Polars · Pydantic 2 · Ruff · uv · mypy 徹底分析

「Python は 2026 年、もはや『遅い言語』ではない。Pydantic は Rust に、Polars も Rust に、Ruff と uv もまた Rust に — Python のホットパスはすべてシステム言語に移った。」 — PyCon US 2026 基調講演

Python は 2025〜2026 年に最大のツールチェーン置き換えを経験しました。pip は uv(Astral、Rust 製)へ、Black + isort + flake8 + pylint は Ruff 単一ツールへ、pandas は PyArrow バックエンドあるいは Polars へ — 4 つの巨大ツールが同時に交換された出来事は Python 30 年の歴史で初めてです。そしてそのすべてのツールの中核エンジンは Rust で書かれています。

言語そのものも変わりました。Python 3.13(2024.10)は実験的 JIT(PEP 744)と free-threaded ビルド(PEP 703)を導入し、3.14(2025.10)はこれらを安定化させつつ per-interpreter GIL を磨きました。2026 年 5 月現在、Python は「型を持ち、非同期を自然に扱い、GIL なしでマルチスレッドを回せる」言語へ変貌しつつあります。本稿では、言語・Web フレームワーク・ORM/データ・検証・ツールチェーン・テスト・並行性・ML 隣接・CLI・スクレイピング、そして韓国・日本の採用事例までを一つの記事にまとめます。

1. 2026 年の Python エコシステムを一望する

2026 年の Python エコシステムは次の 5 レイヤーで整理できます。

肝心なのは「Python は単一ツールチェーンへ収束しつつあるが、その内部実装は Rust に分岐している」という点です。ユーザが書くコードは依然 Python ですが、それを処理するツールはシステム言語に移りました。

2. Python 3.13 — JIT プレビュー、Free-Threaded、改善されたエラーメッセージ

Python 3.13(2024.10)はバックエンドにもデータサイエンスにも影響する 3 つの大きな変化を導入しました。

第一に、実験的 JIT コンパイラ(PEP 744) です。copy-and-patch 方式の JIT がホットループをネイティブコードへコンパイルします。2026 年時点で 5〜15% の向上が標準で、NumPy のような C 拡張呼び出しが支配的なコードでは効果が限定的です。第二に、Free-threaded ビルド(PEP 703) は python3.13t / python3.14t として配布され、GIL を完全に取り除きます。CPU バウンドなマルチスレッドはコア数に比例してスケールします。第三に、改善されたエラーメッセージ — NameError 時に近い名前を提案し、インデントエラーを視覚的に表示します。

# uv で free-threaded Python 3.13 をインストール
uv python install 3.13t
uv venv --python 3.13t
source .venv/bin/activate

# GIL の状態を確認
python -c "import sys; print('GIL enabled:', sys._is_gil_enabled())"
# free-threaded ビルドでは False が出る

# JIT を有効化して確認
PYTHON_JIT=1 python -c "import sys; print('JIT:', sys._jit.is_enabled())"

free-threaded を本番で使う事例はまだ少なく、Granian や一部データ処理ワークロードが実験的に導入しています。ライブラリの互換性 — 特に C 拡張 — が最大の障壁です。

3. Python 3.14 — JIT の安定化と Per-Interpreter GIL

Python 3.14(2025.10)は 3.13 の実験的機能を磨き上げたリリースです。JIT は引き続き「experimental」ですが回帰が減り、free-threaded ビルドは安定 PEP に昇格しました。Per-Interpreter GIL(PEP 684) は同一プロセス内に複数のサブインタプリタを立て、それぞれに独立した GIL を持たせます。WSGI/ASGI サーバが fork コストなしにマルチコアを活かす道が開けました。

新文法では PEP 695(ジェネリック構文) の安定化と、PEP 750(t-string、テンプレート文字列リテラル) の導入が目立ちます。t-string は SQL インジェクションやシェルエスケープなどセキュリティセンシティブな箇所で自動エスケープを強制できる新しい構文です。PEP 695 のジェネリックは def first[T](items: list[T]) -> T: の形でクラス/関数に直接型パラメータを宣言でき、t-string は t"SELECT * FROM users WHERE name = ..." 構文でランタイムが値とテンプレートを分離します。

4. uv — pip と Poetry を同時に置き換える

Astral の uv は 2024 年の初リリース以降、2025〜2026 年にかけて Python パッケージマネージャ市場を急速に侵食しました。Rust 製の単一バイナリで、pip / pip-tools / virtualenv / pyenv / pipx / Poetry / PDM の機能を吸収しています。ベンチマーク上 pip + venv の 10〜100 倍速く、キャッシュベースのロックファイルが再現可能なインストールを提供します。

# pyproject.toml(uv 標準)
[project]
name = "myapi"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = [
    "fastapi[standard]>=0.115",
    "sqlalchemy[asyncio]>=2.0",
    "pydantic>=2.9",
    "uvicorn[standard]>=0.30",
    "httpx>=0.27",
]

[dependency-groups]
dev = [
    "pytest>=8.3",
    "pytest-asyncio>=0.24",
    "ruff>=0.7",
    "mypy>=1.13",
]

[tool.uv]
managed = true
default-groups = ["dev"]

コマンドは直感的です。uv init, uv add fastapi, uv sync, uv run pytest, uv pip install -r requirements.txt。既存の Poetry プロジェクトは uv migrate で移行でき、PEP 621 の pyproject.toml 標準に準拠しているのでリスクは低いです。2026 年 5 月時点で PyPI ダウンロード上位 100 パッケージのうち 70% 以上が uv 互換メタデータを持っています。

5. Ruff — 4 つのツールを 1 つに

Ruff は Astral が作った Rust 製リンター・フォーマッタです。Black + isort + flake8 + pylint の 700 を超えるルールを単一バイナリに統合し、速度は平均で 10〜100 倍。2026 年時点で FastAPI · Pydantic · Polars · Hugging Face · pandas を含むほぼすべての主要 OSS が Ruff に移行しました。

# pyproject.toml に追記
[tool.ruff]
line-length = 100
target-version = "py313"

[tool.ruff.lint]
select = [
    "E",   # pycodestyle errors
    "W",   # pycodestyle warnings
    "F",   # pyflakes
    "I",   # isort
    "B",   # flake8-bugbear
    "C4",  # flake8-comprehensions
    "UP",  # pyupgrade
    "N",   # pep8-naming
    "S",   # bandit (security)
    "RUF", # ruff-specific
]
ignore = ["E501"]  # 行長はフォーマッタに任せる

[tool.ruff.format]
quote-style = "double"
indent-style = "space"

ruff check . --fix && ruff format . の 1 行でクリーンアップが完了します。巨大モノレポでも 1 秒以内に全体検査が終わるため、pre-commit フックの負担が事実上消えました。

6. mypy 対 pyright — 型チェッカーの両強体制

型チェッカーは mypy(Python 製、Dropbox 発) と pyright(TypeScript 製、Microsoft 発) の両強体制です。mypy 1.13(2025)は PEP 695 ジェネリック、PEP 696 type defaults、PEP 692 TypedDict for kwargs をサポートし、pyright は VS Code Pylance のコアエンジンとして最速のインクリメンタル推論を誇ります。

# pyproject.toml — mypy と pyright を併設
[tool.mypy]
python_version = "3.13"
strict = true
warn_return_any = true
warn_unused_configs = true
disallow_untyped_defs = true
plugins = ["pydantic.mypy", "sqlalchemy.ext.mypy.plugin"]

[[tool.mypy.overrides]]
module = "third_party_without_stubs.*"
ignore_missing_imports = true

[tool.pyright]
include = ["src"]
exclude = ["**/__pycache__"]
pythonVersion = "3.13"
typeCheckingMode = "strict"
reportMissingImports = "error"
reportMissingTypeStubs = "warning"

選定基準は明快です。CI/CD 全体での型安全保証が目的なら mypy(歴史が長く PEP の権威がある)、VS Code 統合と速いインクリメンタル分析が目的なら pyright。両方を併用するチームも増えており、mypy を CI、pyright を IDE で同時に回すパターンが最も安定します。

7. FastAPI 0.115+ — 自動 OpenAPI · DI · Pydantic 2

FastAPI(2018〜、Sebastián Ramírez 作)は 2026 年も Python API フレームワークの事実上標準です。GitHub 80K 超、PyPI 月間ダウンロード 200M 超。0.115 では Starlette 0.41 と Pydantic 2.9 への依存に上がり、検証スループットがさらに向上しました。中核価値は自動 OpenAPI 生成、型ベース依存性注入、Pydantic 2 検証統合の 3 点です。

# FastAPI + Pydantic 2 + SQLAlchemy 2 async の標準パターン
from fastapi import FastAPI, Depends, HTTPException
from pydantic import BaseModel, EmailStr, Field
from sqlalchemy.ext.asyncio import AsyncSession
from typing import Annotated

app = FastAPI(title="User API", version="1.0")

class UserCreate(BaseModel):
    email: EmailStr
    name: str = Field(min_length=1, max_length=50)
    age: int = Field(ge=0, le=150)

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

async def get_db() -> AsyncSession:
    async with AsyncSessionLocal() as session:
        yield session

DbSession = Annotated[AsyncSession, Depends(get_db)]

@app.post("/users", response_model=UserOut, status_code=201)
async def create_user(payload: UserCreate, db: DbSession) -> UserOut:
    user = User(**payload.model_dump())
    db.add(user)
    await db.commit()
    await db.refresh(user)
    return UserOut.model_validate(user, from_attributes=True)

Annotated[Type, Depends(...)] パターンは 0.95 以降推奨で、0.115 では sub-dependency キャッシュなど微調整が追加されました。

8. Django 5.1+ — ついに成熟した async ビュー

Django は 2026 年 5 月時点で 5.2 LTS が最新安定版であり、async ビューがついに実戦水準に達しました。Django 5.1 で async ORM メソッド(aget、acreate、afilter)が安定化し、5.2 では async signals · async aggregation · async middleware が追加されました。WSGI + Gunicorn 時代から ASGI + uvicorn/Daphne 時代への転換が本格的に始まったのです。

# Django 5 の async ビュー — 真の同時処理が可能
from django.http import JsonResponse
from django.views.decorators.http import require_GET
from asgiref.sync import sync_to_async
import httpx, asyncio

@require_GET
async def aggregate(request):
    async with httpx.AsyncClient() as client:
        # 外部 API 2 つを並列に
        a, b = await asyncio.gather(
            client.get("https://api1.example.com/data"),
            client.get("https://api2.example.com/data"),
        )

    # async ORM
    user = await User.objects.aget(pk=request.user.id)

    return JsonResponse({
        "user": user.email,
        "data1": a.json(),
        "data2": b.json(),
    })

Django の強みは Admin · Auth · Migrations · ORM が一体である点に変わりありません。大規模 SaaS はビジネスロジックを Django、API ゲートウェイを FastAPI/Litestar とするハイブリッド構成を好みます。

9. Litestar 2.x — コントローラベースの次世代 ASGI

Litestar(旧 Starlite、2021〜)は FastAPI の関数ベース API に満足しないチームが選ぶコントローラベース ASGI フレームワークです。2.x では DTO(Data Transfer Object)システム、msgspec 統合、OpenTelemetry の一次サポート、チャンネル(WebSocket pub/sub)などエンタープライズ機能が加わりました。

# Litestar 2.x — コントローラベース
from litestar import Controller, Litestar, get, post
from msgspec import Struct

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

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

    @get("/")
    async def list_users(self) -> list[User]:
        return [User(id=1, name="Alice")]

    @post("/")
    async def create_user(self, data: User) -> User:
        return data

app = Litestar(route_handlers=[UserController])

Litestar は検証エンジンとして msgspec をデフォルト推奨します。msgspec は Pydantic 2 比で 2〜5 倍速いシリアライズ/デシリアライズ性能を示し、メモリ消費も低めです。ただし IDE 統合とエコシステム規模では Pydantic 2 が圧倒的なので、msgspec 単独で FastAPI を離れるほどの決定的動機にはなりにくいというのが大方の見解です。

10. Flask 3.x · Sanic · Quart · aiohttp 4 · Robyn — その他陣営

Flask 3(2023)は WSGI 時代のクラシックなマイクロフレームワークとして生き残りました。async ビューは限定的にサポートされますが、本質は同期です。Quart は Flask とほぼ同一の API に ASGI を載せたフォークで、Flask ファンの非同期陣営。Sanic は自前 ASGI サーバまで含む単一非同期パッケージ、aiohttp 4 はクライアント・サーバの両方を扱う非同期 HTTP の古参です。

Robyn は Rust コアの上に Python インターフェースを載せた新しい挑戦です。ルータ・ミドルウェア・HTTP パーサがすべて Rust 製で、Python ハンドラを呼び出します。単純ルーティングのベンチマークでは uvicorn + FastAPI 比で 2〜3 倍のスループットを示します。ただしエコシステムが狭く Python デバッガ統合が弱いため、本番採用は慎重です。

11. Starlette — FastAPI · Litestar の共通の祖先

Starlette は ASGI 標準の上にルーティング・ミドルウェア・テストクライアントを載せたマイクロフレームワークです。FastAPI は Starlette を直接依存として取り込み、Litestar は独自実装ながらインターフェースは酷似しています。単体使用時は from starlette.applications import Starlette の 1 行から始め、ルート・ミドルウェアを手で組み立てる形になり、それが FastAPI/Litestar との本質的な違いを理解する最良の出発点です。

12. Granian — uvicorn を脅かす Rust 製 ASGI サーバ

Granian は Emmett フレームワークの作者が手掛けた Rust 製 ASGI/WSGI/RSGI サーバです。uvicorn(uvloop + httptools)比で 1.5〜2 倍のスループットを示し、free-threaded Python 3.13t ではマルチスレッドワーカーを自然に活用します。

インストールは uv add granian の 1 行、実行は granian --interface asgi main:app の uvicorn 互換ドロップインです。ワーカーとスレッドを同時調整するなら --workers 4 --threads 2、Granian 専用 RSGI モード(より軽量)は --interface rsgi で有効化します。

2026 年 5 月現在、Granian は「uvicorn 互換ドロップイン」として定着し、FastAPI/Litestar とも公式ガイドに Granian を併記しています。uvicorn は依然標準ですが、性能が重要な箇所は徐々に Granian へ移っています。

13. Pydantic 2 — Rust コアの検証エンジン

Pydantic 2(2023)はコアを Rust で書き直した検証エンジンです。v1 比 5〜50 倍速く、JSON シリアライズは orjson 並みに近づきました。FastAPI · Django Ninja · Litestar · LangChain · OpenAI SDK など、ほぼすべての API ライブラリが Pydantic 2 の上で動きます。

from pydantic import BaseModel, Field, EmailStr, computed_field, model_validator
from datetime import datetime
from typing import Self

class Order(BaseModel):
    id: int
    email: EmailStr
    items: list[str] = Field(min_length=1)
    quantity: int = Field(gt=0)
    price_per_item: float = Field(gt=0)
    created_at: datetime

    @computed_field
    @property
    def total(self) -> float:
        return self.quantity * self.price_per_item

    @model_validator(mode="after")
    def check_premium_quota(self) -> Self:
        if self.quantity > 1000 and "@example.com" not in self.email:
            raise ValueError("non-premium accounts limited to 1000")
        return self

# シリアライズ
order = Order(id=1, email="a@b.com", items=["sku-1"], quantity=10, price_per_item=99.0,
              created_at=datetime.now())
print(order.model_dump_json())

Pydantic 2 の核となるトリックは、すべての検証ロジックを Rust へ移した pydantic-core です。Python 側は薄いラッパーが残るだけです。

14. msgspec · attrs · dataclasses · cattrs — 検証の代替

検証/シリアライズは Pydantic 2 だけではありません。msgspec は Pydantic 2 比でさらに速いシリアライズライブラリで Litestar がデフォルト採用、attrs は Python 標準ライブラリにも影響を与えたクラス定義ツール、dataclasses は stdlib 標準、cattrs は attrs/dataclasses の上に構造化/逆構造化レイヤを載せたツールです。

15. SQLAlchemy 2.x — Core と ORM を統合した async

SQLAlchemy 2.0(2023)は Core と ORM の API を統合したメジャーリリースです。select() ベースの統一クエリ、AsyncSession、型ヒント優先のマッピング、PEP 695 ジェネリック互換が中心です。2026 年 5 月時点では 2.0.36 が最新で、asyncio ダイアレクトは PostgreSQL(asyncpg)、MySQL(aiomysql)、SQLite(aiosqlite)、MSSQL(aioodbc)を正式サポートします。

# SQLAlchemy 2 — async + 型付きマッピング
from sqlalchemy import select, String
from sqlalchemy.ext.asyncio import AsyncSession, create_async_engine, async_sessionmaker
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column
from datetime import datetime

class Base(DeclarativeBase):
    pass

class User(Base):
    __tablename__ = "users"
    id: Mapped[int] = mapped_column(primary_key=True)
    email: Mapped[str] = mapped_column(String(255), unique=True)
    name: Mapped[str] = mapped_column(String(50))
    created_at: Mapped[datetime] = mapped_column(default=datetime.utcnow)

engine = create_async_engine("postgresql+asyncpg://user:pw@localhost/db", echo=True)
AsyncSessionLocal = async_sessionmaker(engine, expire_on_commit=False)

async def find_recent_users(session: AsyncSession) -> list[User]:
    stmt = select(User).where(User.created_at > datetime(2026, 1, 1)).order_by(User.id)
    result = await session.scalars(stmt)
    return list(result)

Mapped[...] 型アノテーションはカラムメタデータの真実の源で、mypy/pyright との統合もクリーンです。

16. SQLModel · Tortoise · Peewee · Piccolo · Edgy — ORM の選択肢

SQLModel は SQLAlchemy 2 のカラムマッピングの上に Pydantic 検証を載せ、「1 モデル = ORM + API DTO」パターンを提供します。FastAPI 公式ガイドが SQLModel を併記したことで、このパターンが事実上の標準になりました。

17. Polars — pandas 後継候補

Polars(Rust + Apache Arrow)は 2024〜2025 年にかけて pandas を急速にシェア侵食したデータフレームライブラリです。マルチスレッドクエリエンジン、lazy 評価、Arrow メモリモデルが基本です。大規模データ(>1GB)では pandas 比 5〜30 倍速く、韓国 NAVER · 日本 ZOZO のデータチームが新規 ETL はすべて Polars で書くと公表しています。

import polars as pl

# eager API
df = pl.read_csv("orders.csv")
result = (
    df.filter(pl.col("country") == "KR")
      .group_by("user_id")
      .agg([
          pl.col("amount").sum().alias("total"),
          pl.col("order_id").count().alias("orders"),
      ])
      .sort("total", descending=True)
      .head(10)
)

# lazy API — クエリプランナ最適化
plan = (
    pl.scan_parquet("logs/*.parquet")
      .filter(pl.col("status") == 200)
      .group_by("path")
      .agg(pl.col("latency_ms").mean())
)
print(plan.explain())  # 実行計画を確認
top_paths = plan.collect()

pandas ユーザが Polars へ移る際の最大の壁はインデックス概念の不在です。Polars はインデックスを持たずすべての列を対等に扱うため、pandas の .set_index() / MultiIndex パターンを再モデリングする必要があります。

18. pandas 2.x · PyArrow · DuckDB — データスタックの共存

pandas 2.x(2023〜)は PyArrow バックエンドを一級サポートし、メモリ消費と文字列 dtype の性能を改善しました。2.2 から pd.options.future.infer_string = True が標準となり、copy-on-write モードが既定化されました。Polars に移っていないチームでも pandas 2 + PyArrow バックエンドで大きな性能向上が得られます。

DuckDB は in-process OLAP データベースで、pandas/Polars データフレームに直接 SQL を実行できます。Jupyter で最速の分析ツールとして定着し、httpfs 拡張で S3/HTTP ファイルを直接クエリできます。

import duckdb, polars as pl

# Polars データフレームに SQL を直接実行
df = pl.read_csv("orders.csv")
result = duckdb.sql("""
    SELECT user_id, COUNT(*) AS orders, SUM(amount) AS total
    FROM df
    WHERE country = 'KR'
    GROUP BY user_id
    ORDER BY total DESC
    LIMIT 10
""").pl()  # 結果を Polars に戻す

# S3 Parquet を直接クエリ
duckdb.sql("INSTALL httpfs; LOAD httpfs;")
top = duckdb.sql("""
    SELECT path, AVG(latency_ms) AS avg_lat
    FROM read_parquet('s3://bucket/logs/*.parquet')
    WHERE status = 200
    GROUP BY path
""").df()

19. pytest · pytest-asyncio · hypothesis · polyfactory — テストの標準

Python テストは pytest 単一標準です。2026 年 5 月時点で pytest 8.3、pytest-asyncio 0.24 が推奨です。hypothesis は property-based testing ツールで、入力空間を自動探索してエッジケースを発見します。polyfactory は Pydantic/dataclass/SQLAlchemy モデルから自動でフェイクデータを生成します。

# pytest + hypothesis
import pytest
from hypothesis import given, strategies as st

@given(st.lists(st.integers(min_value=0, max_value=1000), min_size=1))
def test_sum_is_nonneg(xs: list[int]) -> None:
    assert sum(xs) >= 0

# pytest-asyncio
@pytest.mark.asyncio
async def test_user_create(client):
    response = await client.post("/users", json={
        "email": "a@b.com", "name": "Alice", "age": 30
    })
    assert response.status_code == 201

# polyfactory
from polyfactory.factories.pydantic_factory import ModelFactory

class UserFactory(ModelFactory[UserCreate]):
    __model__ = UserCreate

def test_random_users():
    for _ in range(100):
        u = UserFactory.build()
        assert u.age >= 0

並列実行は pytest-xdist、カバレッジは coverage + pytest-cov、ミューテーションテストは mutmut が標準です。

20. asyncio · anyio · trio — 非同期並行性

Python の並行性は stdlib の asyncio が中心です。ただしキャンセル意味論とタスクグループが複雑なので、anyio という抽象レイヤが台頭しました。anyio は asyncio と trio を同時にサポートし、構造化並行性(structured concurrency)モデルを提供します。trio 自体は Nathaniel Smith の独立した非同期ライブラリで、学術的・設計的整合性が高い一方エコシステムは狭めです。

# anyio — 構造化並行性
import anyio
import httpx

async def fetch(url: str) -> int:
    async with httpx.AsyncClient() as client:
        r = await client.get(url)
        return r.status_code

async def main():
    async with anyio.create_task_group() as tg:
        for url in ["https://a.example", "https://b.example", "https://c.example"]:
            tg.start_soon(fetch, url)
    # タスクグループの終了時にすべての子の後片付けが保証される

anyio.run(main)

FastAPI 0.110+ / Starlette 0.36+ は内部で anyio を採用し、2026 年 5 月時点では新規 async コードは anyio パターンに従うのが推奨です。

21. NumPy 2 · SciPy · scikit-learn · transformers · PyTorch — ML 隣接

NumPy 2.0(2024)は ABI 変更、新しい string dtype、簡素化された API が主な変化です。SciPy 1.13+ は NumPy 2 互換、scikit-learn 1.5+ は NumPy 2 と free-threaded ビルドの実験的サポートを追加しました。PyTorch 2.5+ は torch.compile が安定化し、free-threaded ビルドの実験的サポートも始まりました。transformers 4.45+、JAX 0.4+ も Pydantic 2 検証を部分的に統合しています。

ML ワークロードではデータパイプラインが Polars + DuckDB + PyArrow に、学習が PyTorch + Lightning + datasets に集約されました。

22. Typer · Click · argparse · fire — CLI 陣営

CLI ツールには 4 つの選択肢があります。Typer(FastAPI の姉妹プロジェクト、Pydantic/型ベース)、Click(Flask 陣営、デコレータベース)、argparse(stdlib 標準)、fire(Google 製、オブジェクト自動公開)。Typer では関数の型ヒントがそのまま CLI オプションになります — def ingest(path: Path, workers: int = 4, dry_run: bool = False) -> None: という関数に @app.command() デコレータを付ければ完成した CLI になります。

uv + Typer の組み合わせは「CLI スクリプト + 自動インストール」を最もきれいに実現します。uv tool install mycli の 1 行でシステム PATH に登録されます。

23. httpx · playwright-python · Scrapy 2.12 — Web クライアントとスクレイピング

httpx(Encode)は requests の非同期後継として定着しました。requests API 互換に async、HTTP/2、SOCKS、OAuth などが追加され、async with httpx.AsyncClient(http2=True) as client: の 1 行で HTTP/2・接続プーリング・タイムアウトが処理されます。playwright-python はブラウザ自動化の標準として Puppeteer/Selenium を急速に置き換えました。Scrapy 2.12 は本格的なクローリングフレームワーク、軽量パースは parsel(Scrapy から分離)を使います。

24. 韓国の採用事例 — Toss · Naver · Coupang · Kakao

Toss は ML プラットフォームとデータ処理パイプラインに Python を全面導入しました。モデルサービングは FastAPI + Pydantic 2 + Granian の組み合わせ、特徴量エンジニアリングは Polars + DuckDB を使います。2025 年第 3 四半期の技術ブログで「Polars 導入により pandas 比 8 倍速い ETL」を公開しました。

Naver は検索ランキングの特徴量エンジニアリングと Clova モデルサービングに Python を使い、2025 年末に社内データ標準を Polars 優先に変更したと公表しました。Coupang は広告/検索 ML サービングに FastAPI + Pydantic 2 + SQLAlchemy 2 を使い、社内モノレポに Ruff + uv を標準化しました。Kakao は KoGPT シリーズの推論サービングに FastAPI + PyTorch + ONNX Runtime を使っています。

25. 日本の採用事例 — Mercari · ZOZO · LINE · SmartNews

Mercari は ML プラットフォーム ML-2(2024 公開)の全体を FastAPI + Pydantic 2 で書き、シリアライズのホットパスに msgspec を部分導入しました。ZOZO はファッション推薦システムの特徴量パイプラインを pandas から Polars へ移行する作業を 2025 年に完了し、社内標準リンターを Ruff に統一しました。

LINE は広告システムと推薦システムの両方に FastAPI + SQLAlchemy 2 async を使い、東京の PyCon JP 2025 で Granian 導入事例を発表しました。SmartNews はコンテンツランキング学習パイプラインを PyTorch + Polars + DuckDB で構成しました。

26. ツールチェーンの移行 — 2026 年標準の推奨セットアップ

Python プロジェクトを 2026 年標準でセットアップするなら以下の組み合わせが最も無難です。既に稼働中のプロジェクトでは一度にすべて移行せず段階的に進めましょう。

# 2026 年推奨の pyproject.toml セットアップ
[project]
name = "myproject"
requires-python = ">=3.13"
dependencies = [
    "fastapi[standard]>=0.115",
    "pydantic>=2.9",
    "sqlalchemy[asyncio]>=2.0",
    "polars>=1.12",
    "httpx>=0.27",
]

[dependency-groups]
dev = [
    "pytest>=8.3",
    "pytest-asyncio>=0.24",
    "hypothesis>=6.115",
    "ruff>=0.7",
    "mypy>=1.13",
    "pyright>=1.1.385",
]

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

[tool.ruff.lint]
select = ["E", "W", "F", "I", "B", "C4", "UP", "N", "S", "RUF"]

[tool.mypy]
python_version = "3.13"
strict = true
plugins = ["pydantic.mypy", "sqlalchemy.ext.mypy.plugin"]

[tool.pytest.ini_options]
asyncio_mode = "auto"
addopts = "--strict-markers -ra"

移行順序は (1) Poetry/pip から uv へ、(2) Black + isort + flake8 から Ruff へ、(3) pandas から Polars へ(新規コードのみ)、(4) pydantic 1 から pydantic 2 へ(BC が壊れるので慎重に) です。mypy と pyright は二者択一せず、mypy を CI、pyright を IDE で同時に回すパターンが最も安定します。

27. 結論 — Python のホットパスは Rust に移った

2026 年の Python を一文で要約すれば「言語はそのまま、ツールは Rust へ」です。ユーザコードは依然 Python で書かれますが、それを処理するすべての中核ツール — パッケージマネージャ(uv)、リンター・フォーマッタ(Ruff)、検証エンジン(Pydantic 2 / pydantic-core)、データフレーム(Polars)、ASGI サーバ(Granian) — は Rust 製です。

言語自体も Python 3.13 の free-threaded ビルドと JIT、3.14 の per-interpreter GIL · t-string により進化中です。2030 年頃には GIL なしの Python が標準となる可能性が高いでしょう。それまで私たちがやるべきことは Pydantic 2 + SQLAlchemy 2 + Polars + FastAPI/Django/Litestar + Ruff + uv という標準の組み合わせを身につけ、新規プロジェクトに適用し、既存プロジェクトを段階的に移行することです。

References

• Python 公式ドキュメント: https://docs.python.org/3/
• FastAPI: https://fastapi.tiangolo.com/
• Django: https://docs.djangoproject.com/en/5.2/
• Litestar: https://litestar.dev/
• Starlette: https://www.starlette.io/
• SQLAlchemy: https://docs.sqlalchemy.org/en/20/
• Polars: https://pola.rs/
• Pydantic: https://docs.pydantic.dev/latest/
• Ruff: https://docs.astral.sh/ruff/
• uv: https://docs.astral.sh/uv/
• mypy: https://mypy.readthedocs.io/
• pyright: https://github.com/microsoft/pyright
• pytest: https://docs.pytest.org/
• DuckDB: https://github.com/duckdb/duckdb
• msgspec: https://jcristharif.com/msgspec/
• Granian: https://github.com/emmett-framework/granian