モダン Python 2026 — Python 3.13 / 3.14 / free-threaded / uv / Ruff / Polars 1.0 / FastAPI / Litestar / Robyn 徹底ガイド

プロローグ — 30年ぶりの二つの変曲点

Python は 1991 年に誕生した。2026 年で 35 歳。1.x から 2.x、3.x を経て、動的型付け言語の代表格、データと ML の lingua franca、バックエンドマイクロサービスの一角となった。だが二つの慢性的不満があった。

1. GIL(Global Interpreter Lock) — CPython の単一の巨大ロック。CPU バウンドのマルチスレッドが事実上不可能だった。「Python は遅い」という評判の半分はここから来ていた。
2. パッケージング・ツール群の断片化 — pip、easy_install、conda、poetry、pipenv、pdm、hatch、rye…どれが正解かの合意がなかった。しかも全部遅かった。

2024〜2026 年は、この二つの慢性疾患が 同時に 大手術を受けた時期だ。

• Python 3.13(2024-10) — PEP 703(free-threaded)と PEP 744(JIT)が 公式 preview に入った。30年で初めて、GIL のない CPython が ABI として存在した。
• Python 3.14(2025-10) — free-threaded ビルドが stable に昇格した。deferred imports(PEP 791)、template strings、起動高速化。GIL のない Python はもう「実験」ではない。
• uv(2024-02、Astral) — Rust 単一バイナリ。pip より 10〜100 倍速いインストール、lock ファイル、venv 管理、Python インタプリタのインストールまで一つで。事実上の標準になりつつある。
• Ruff(Astral) — Rust 単一バイナリの linter + formatter。flake8 + isort + black + pyupgrade + bandit の一部まで統合。数百倍速い。
• ty(Astral、2025 alpha) — Rust で書き直された型チェッカー。mypy/pyright の座を狙う。
• Polars 1.0(2024-08) — Rust コアの DataFrame。Pandas の単一スレッド限界とメモリ非効率を正面から狙う。
• Pandas 3.0(2025-05) — Arrow backend、Copy-on-Write のデフォルト化、PyArrow が必須依存に。
• Pydantic v2.10 — Rust コア検証、FastAPI の基盤。
• Web — FastAPI は ASGI の代名詞となり、Litestar(旧 Starlite)、Robyn(Rust コア)、Quart(async Flask)、Sanic、BlackSheep が各々の色で競う。Django 5.x は依然としてフルスタックの堅牢な答え。

この記事はこれら全てを一気に見る。「どのツールを選ぶか」ではなく「なぜこの変化が起きたのか、どんなトレードオフがあるのか」を。コード例とコマンド、そして実際の意思決定ガイドまで。

1章 · 2026 年のモダン Python 風景

2026 年 5 月時点で、新しい Python プロジェクトを始めると仮定しよう。5 年前との手順の違い。

2021 年:

pyenv install 3.10.0
pyenv local 3.10.0
python -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt
pip-compile requirements.in
flake8 .
black .
isort .
mypy .
pytest

2026 年:

uv init                       # pyproject.toml + .python-version を自動生成
uv python install 3.14        # Python インタプリタも uv が管理
uv add fastapi polars         # 依存追加 + lock + インストール
uv run ruff check --fix .     # lint
uv run ruff format .          # format
uv run ty check .             # type check(alpha だが使える)
uv run pytest                 # test

整理すると。

一行サマリー: Rust で書き直されたツール群が Python ツールチェーンの半分を入れ替え、Python 自身は GIL を外し始めた。

2章 · Python 3.13(2024-10) — free-threaded preview、JIT preview

Python 3.13 は 2024 年 10 月 7 日にリリースされた。表面的には通常のマイナーバージョンだが、二つが 初 だった。

PEP 703 — free-threaded(no-GIL)ビルド

長く「理論的には可能だが互換性とシングルスレッド性能が壊れる」というのが合意だった。PEP 703(Sam Gross、Meta)はこの合意を破った。核となるアイデア。

• biased reference counting — オブジェクトを所有するスレッドはロック無しで refcount を変更、他スレッドはロックを使う。
• deferred reference counting — 一部の immortal オブジェクト(None、小さな整数など)は refcount をそもそもカウントしない。
• per-object lock — dict、list のような可変コンテナに小さなロック。
• stop-the-world GC — GC 中は全スレッド一時停止(短く)。

ビルドは オプトイン。同じ 3.13 ソースから二つのビルドが出る。

# 標準ビルド(GIL あり)
./configure && make

# free-threaded ビルド(GIL なし)
./configure --disable-gil && make
# インタプリタは python3.13t(t = threaded)

uv ならこう。

uv python install 3.13         # 通常ビルド
uv python install 3.13t        # free-threaded ビルド
uv python install 3.13+freethreaded   # 明示形

3.13 の free-threaded は preview だ。意味:

• ABI が分かれている。C 拡張は別ビルドが必要(Py_GIL_DISABLED マクロ)。
• シングルスレッド性能が約 10〜20% 遅い。
• 一部 stdlib と多くの C 拡張がまだ未対応。

PEP 744 — Copy-and-Patch JIT(experimental)

同じ 3.13 に入ったもう一つの大きな変化。Tier 2 インタプリタ上の copy-and-patch JIT。ビルド時に LLVM を使って「stencil」と呼ばれる機械語の小片を先に生成し、実行時にパッチして native code を作る。

./configure --enable-experimental-jit && make

3.13 では性能向上は小さい(0〜5%)。だが 3.14、3.15 での本格的な最適化の土台となる。

その他 3.13 の主要変更

• 新しい REPL — 複数行編集、カラー、Ctrl+D で終了。
• 改善された traceback — カラー、より正確な位置表示。
• iOS Tier 3、Android Tier 3 — 公式サポートプラットフォームに追加(Beeware/Briefcase の土台)。
• Locals API の再設計 — デバッガからの正確な変数変更。
• typing.TypeIs — TypeGuard より正確な narrowing。
• 非推奨 — argparse の一部 API、pkgutil.find_loader など。

3章 · Python 3.14(2025-10) — free-threaded stable

Python 3.14 は 2025 年 10 月 7 日にリリースされた。3.13 で始まった変化の完成形。

free-threaded が stable に

3.13 で「experimental」のタグが付いていた free-threaded ビルドが、3.14 では 公式サポートオプション になった。意味は大きい。

• numpy、scipy、pandas、polars、pillow、lxml、cryptography など中核パッケージが free-threaded ビルドの wheel を PyPI に公式アップロード。
• pip install がインタプリタ種別を見て適切な wheel を取得。
• シングルスレッド性能のペナルティが 3〜5% に縮小(JIT と組み合わせるとほぼ同等)。

deferred imports(PEP 791)

# 3.13 まで — import は即時
import heavy_module   # インタプリタ起動が遅くなる

# 3.14 — deferred import
from __future__ import deferred_imports
import heavy_module   # 実際に使われた時に import

CLI ツールや cold start が重要な環境(Lambda、serverless)で大きい意味を持つ。uv/Ruff のようなツールが速い理由の一つも、このパターンを Rust で真似たもの。

Template strings — t-strings

# f-string は即時評価
name = "world"
greeting = f"Hello, {name}!"   # 即「Hello, world!」

# t-string は lazy template
template = t"Hello, {name}!"   # Template オブジェクト、未評価
# 後でレンダリング、エスケープ、i18n 処理が可能
html = template.render(escape=html_escape)

SQL インジェクション・XSS 対策、i18n、構造化ログなどで有用。2026 年 5 月時点の採用はまだ初期段階。

その他 3.14 の主要変更

• JIT 性能改善 — 一部ベンチマークで 10〜15% 向上。
• PEP 768 — 外部デバッガが安全に attach。
• PEP 765 — finally 内の return/break/continue に警告。
• subinterpreter API — PEP 734 で stdlib に正式追加。
• typing.evaluate_forward_ref — forward reference 評価 API。

4章 · PEP 703 の意味 — GIL を外すと何が変わるか

GIL が消えるとは実際に何を変えるか。手短に。

1) CPU バウンドのマルチスレッドが本当に動く

# 2024 年以前 — GIL のせいで意味なし
from concurrent.futures import ThreadPoolExecutor

def cpu_heavy(n):
    s = 0
    for i in range(n):
        s += i * i
    return s

# スレッドを増やしても単一コアしか使わない
with ThreadPoolExecutor(max_workers=8) as pool:
    list(pool.map(cpu_heavy, [10_000_000] * 8))

free-threaded ビルドでは 8 スレッドが 8 コアに実際に分散する。multiprocessing が必要だった多くのワークロードが ThreadPool で済むようになる(メモリ共有が可能で IPC オーバーヘッドが無いので)。

2) C 拡張の作者の責任が増える

GIL はシングルスレッド前提を強制していた。今後すべての C 拡張はスレッド安全性を自前で保証する必要がある。

• グローバル可変状態があればロックが必要。
• PyObject の操作は安全だが、自前の C データ構造は自分で保護。
• Py_GIL_DISABLED マクロでビルド時に分岐可能。

numpy、scipy のような巨大パッケージは 1〜2 年かけて段階的に free-threaded 対応した。小さな C 拡張はまだ時間が必要。

3) asyncio との関係

asyncio は単一スレッドのイベントループ。GIL 除去とは別軸の並行性。ただし両者を組み合わせやすくなる。

• I/O は asyncio コルーチンで。
• CPU バウンド部分は loop.run_in_executor(ThreadPoolExecutor(), ...) で本物の並列化。

4) シングルスレッド性能のペナルティ

biased refcount のような機構は不可避的に若干のオーバーヘッドを生む。3.13 で約 15%、3.14 で約 3〜5% に縮小したがゼロではない。CPU バウンドがマルチスレッドで N 倍速くならないワークロードなら標準ビルドが有利な場合もある。

5) エコシステム分岐のリスク

同じ Python 3.14 に二つの ABI が存在することは、パッケージ保守者の負担が倍になることを意味する。小さなライブラリは片方しかサポートできず、ユーザに混乱を与える。この部分は 2027〜2028 年にどう落ち着くかが鍵。

5章 · uv(Astral) — pip / poetry / pipenv を置き換える単一ツール

uv は Astral が 2024 年 2 月に発表した Rust ベースの単一バイナリパッケージマネージャ。Ruff を作った同じ会社。発表当時のスローガンは「An extremely fast Python package installer and resolver」。事実だった。

何を置き換えるか

別の言い方で、Python パッケージングのほぼすべての層を一つのバイナリに。

インストールと基本使用

# インストール(macOS/Linux)
curl -LsSf https://astral.sh/uv/install.sh | sh

# 新規プロジェクト
uv init my-app
cd my-app
# pyproject.toml、.python-version、README.md を自動生成

# Python インタプリタのインストール
uv python install 3.14

# パッケージ追加
uv add fastapi pydantic 'polars[all]'
uv add --dev pytest ruff

# 同期(venv を lock と正確に一致させる)
uv sync

# 実行
uv run python -m my_app
uv run pytest
uv run ruff check

なぜそんなに速いのか

• Rust + 非同期 I/O — 依存解決を並列に。
• グローバルキャッシュ + ハードリンク — 同じ wheel を複数プロジェクトが共有、ディスク使用量を削減。
• PubGrub solver — 決定論的で速い依存解決。
• Wheel only 優先 — 可能なら sdist ビルドを避ける。
• HTTP/2 + zstd。

私のマシンで測った比較(2025 年後半、平均的な FastAPI プロジェクト、約 80 依存)。

差が大きすぎて、一度使うと戻れない。

pyproject.toml と uv.lock

# pyproject.toml
[project]
name = "my-app"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = [
    "fastapi>=0.115",
    "pydantic>=2.10",
    "polars[all]>=1.0",
]

[tool.uv]
dev-dependencies = [
    "pytest>=8.0",
    "ruff>=0.7",
    "ty>=0.0.1a8",
]

[tool.ruff]
line-length = 100

uv.lock は正確な hash と marker を含む lock ファイル。コミットしてチームで共有する。uv sync は venv を lock に正確に合わせる。

Python インタプリタ管理

uv python list                       # 利用可能なバージョン
uv python install 3.13 3.14 3.14t   # 複数インストール
uv python pin 3.14                  # .python-version を書く

pyenv のしていたことをする。違い: uv は事前ビルドされたインタプリタを直接ダウンロードするので速く、コンパイル依存も不要。

グローバル CLI ツール

uv tool install ruff           # pipx と同じ役割
uv tool install httpie
uv tool run pip-audit          # 一回限りの実行
uvx pip-audit                  # uv tool run のエイリアス

2026 年の標準化の流れ

• PyPI ダウンロード統計では pip 使用が依然 1 位だが、CI 環境での uv 使用は爆発的に増加。
• poetry は依然大きなユーザ層を維持するが、新規プロジェクトでは uv 優勢。
• Astral は Python Foundation のスポンサーの一つ。PSF/PyPA との協力も活発。

6章 · Ruff(Astral) — flake8 / black / isort を統合した Rust ツール

Ruff は Astral の最初のプロダクト(2022 年初リリース、2024〜2025 年に爆発的成長)。一言で言えば 「flake8 より 10〜100 倍速く、black/isort/pyupgrade の機能まで吸収した Rust 単一バイナリ」。

何を置き換えるか

数百のルールが一つのバイナリに収まり、設定で有効化する。

基本使用

uv add --dev ruff

uv run ruff check .            # lint
uv run ruff check --fix .      # 自動修正
uv run ruff format .           # format(black 互換)
uv run ruff format --check .   # CI で形式検証

pyproject.toml 設定

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

[tool.ruff.lint]
select = [
    "E", "F", "W",   # pycodestyle、pyflakes
    "I",             # isort
    "UP",            # pyupgrade
    "B",             # bugbear
    "C4",            # comprehensions
    "SIM",           # simplify
    "RUF",           # ruff specific
]
ignore = ["E501"]    # line too long(formatter が処理)

[tool.ruff.lint.per-file-ignores]
"tests/*" = ["S101"]   # tests 内の assert

[tool.ruff.format]
quote-style = "single"

なぜそんなに速いのか

• Rust の単一 AST パス — 複数ツールが別々にファイルをパースしない。
• 並列処理 — ファイル別並列、ルール別並列。
• インクリメンタル — 変更されたファイルのみ再検査。
• メモリ効率 — 大規模コードベースで black のような OOM が起きにくい。

実ベンチマーク。Django コードベース(約 3500 ファイル)。

数十倍の差。これが CI コストと開発者体感の差を同時に生む。

エディタ統合

• VS Code — Ruff 公式拡張(Astral 管理)。LSP ベース。
• PyCharm/IntelliJ — Ruff 公式プラグイン。
• Neovim — ruff-lsp(または Ruff 内蔵 LSP)。
• Zed — 標準統合。

Formatter — black 互換 + alpha

ruff format は意図的に black と同じ出力を目標にしている(99% 以上互換)。差異は通常 black のバグか、意図的改善(例えば magic trailing comma 処理)。black を使っていたチームは無損失で移行可能。

7章 · ty(Astral) — Rust で書き直された型チェッカー(alpha)

ty は Astral が 2025 年に alpha で公開した Rust 型チェッカー。mypy/pyright の領域を狙う。2026 年 5 月時点でまだ alpha だが、一部プロジェクトが採用を始めた。

なぜまた別の型チェッカーか

型チェッカー市場はすでに複雑。

• mypy — 元祖。PEP 484 のリファレンス実装。Python 製。遅い。
• pyright — Microsoft。TypeScript 製。速くて正確。VS Code(Pylance)の基盤。
• pyre — Meta。OCaml。Instagram で使用。
• pytype — Google。Python 製。漸進的型付けに強い。

ty のポジション。

• Rust — pyright 水準またはそれ以上の速度を目標。
• インクリメンタル — Ruff/uv のように変更部分のみ再検査。
• MIT — Astral 他のツールと一貫。
• LSP first-class — エディタ統合優先。
• Astral 統合 — uv/ruff とスムーズに結合。

基本使用

uv add --dev ty

# ディレクトリ検査
uv run ty check src/

# 単一ファイル
uv run ty check src/main.py

# watch モード
uv run ty check --watch src/

2026 年 5 月時点の現実

ty はまだ alpha。意味:

• 一部 typing 機能(特に generics、TypeVar bounds)が未実装。
• エラーメッセージが mypy/pyright より粗い場合あり。
• 実サービスでは pyright または mypy をメインに、ty を補助として使うパターン。

性能は印象的。大きなコードベースで mypy が 5 分かかるものが ty では約 5 秒。定着すればゲームを変える可能性がある。

推奨組み合わせ

• 現時点推奨(2026 年 5 月): メインは pyright(厳格)または mypy(漸進)、CI に ty を追加して高速な一次ゲート。
• 2027 年見通し: ty が stable になればメインに切り替え可能。

8章 · Polars 1.0(2024-08) — Pandas の代替

Polars は Ritchie Vink が 2020 年に始めた Rust ベースの DataFrame ライブラリ。2024 年 8 月に 1.0 が出た。Pandas の単一スレッド、列単位非効率、メモリ膨張問題を正面から狙う。

核となる違い

• Rust コア — コンパイルされた native code。
• Apache Arrow — 列指向メモリ表現。zero-copy interop。
• lazy execution — クエリプランナが最適化してから実行。
• multi-threaded by default — Rayon で自動並列。
• predicate pushdown / projection pushdown — SQL オプティマイザ水準の最適化。

eager と lazy

import polars as pl

# eager — pandas スタイル
df = pl.read_csv("data.csv")
result = df.filter(pl.col("age") > 30).group_by("city").agg(pl.col("salary").mean())

# lazy — 最適化してから実行
lf = pl.scan_csv("data.csv")    # まだ読まない
result = (
    lf.filter(pl.col("age") > 30)
      .group_by("city")
      .agg(pl.col("salary").mean())
      .collect()                # ここで実行
)

lazy モードではオプティマイザが「フィルタをいつ適用するか」「どの列だけ読むか」を決めて、ディスク I/O とメモリを大きく削減する。

Pandas との性能比較

H2O.ai の DataFrame ベンチマーク(group-by、join、5 GB)。

特に join やメモリ限界近くで差が大きい。

いつ Polars、いつ Pandas

Polars:

• 100 MB 以上のデータ。
• 新規プロジェクト。
• マルチコア活用が必要。
• SQL クエリオプティマイザのように表現したい時。

Pandas:

• 既存ノートブック/エコシステムとの互換(scikit-learn、statsmodels、matplotlib の一部)。
• 「10 年分の Stack Overflow 回答」が必要な新規データサイエンティスト。
• 小さなデータ(数 MB)。
• jupyter で .head() だけ見たい探索。

Pandas との interop

df_pl = pl.from_pandas(df_pd)
df_pd = df_pl.to_pandas()        # PyArrow なら zero-copy
arr = df_pl.to_arrow()           # Arrow Table
df_pl2 = pl.from_arrow(arr)

Arrow を通じた zero-copy interop がどんどん標準化されており、二つを混ぜて使うのは負担が少ない。

9章 · Pandas 3.0(2025-05) — カムバック

Pandas は死んでいない。2025 年 5 月に出た 3.0 は最大のメジャー更新。

3.0 の大きな変化

1. Apache Arrow がデフォルト backend に — numpy backend は非推奨経路。
2. Copy-on-Write がデフォルト — メモリ使用量と安全性を同時に改善。
3. PyArrow が必須依存 — もはや optional ではない。
4. string dtype のデフォルト化 — Python object の代わりに pyarrow string。
5. inplace メソッドの多くが削除 — CoW と衝突。
6. Python 3.10+ 必須。

Copy-on-Write の意味

import pandas as pd
df1 = pd.DataFrame({"a": [1, 2, 3]})
df2 = df1   # 別名

df2.loc[0, "a"] = 999

# 2.x: df1 の値も 999 になる(SettingWithCopyWarning)
# 3.0: df1 は変わらない(CoW で分岐)

長く Pandas ユーザを悩ませた SettingWithCopyWarning の終焉。ただし inplace 動作に依存していたコードは全部壊れる。マイグレーションガイドを読みつつ。

性能

Arrow backend のおかげで、文字列処理、group-by、一部 join が 2.x 比 2〜5 倍速くなった。Polars ほどではないが差は縮まった。

10章 · Pydantic v2.10 — データ検証の事実上の標準

Pydantic は v1 までは純 Python だったが、v2(2023)から Rust コアで書き直された。v2.10(2025 年後半)は v2 系の安定化バージョン。

何をするか

• ランタイムのデータ検証とシリアライズ。
• FastAPI、Litestar、BlackSheep の基盤。
• LangChain の BaseTool、OpenAI structured output など LLM ツールの基本アダプタ。

基本例

from pydantic import BaseModel, Field, EmailStr
from datetime import datetime

class User(BaseModel):
    id: int
    name: str = Field(min_length=1, max_length=64)
    email: EmailStr
    created_at: datetime
    tags: list[str] = []

# 検証 + 変換
u = User.model_validate({
    "id": "42",                       # str → int 自動
    "name": "Alice",
    "email": "alice@example.com",
    "created_at": "2026-05-16T10:00:00Z",
})

print(u.model_dump_json())

v2 の性能

Rust コアのおかげで v1 比 5〜50 倍速い(スキーマの複雑さによる)。FastAPI のようなフレームワークで P99 latency が目に見えて改善した。

Pydantic Settings

from pydantic_settings import BaseSettings

class Settings(BaseSettings):
    database_url: str
    redis_url: str = "redis://localhost"
    log_level: str = "INFO"

    class Config:
        env_file = ".env"

settings = Settings()

12-factor app の config パターンをきれいにする。

LLM ツールでの活用

OpenAI/Anthropic の structured output、function calling が Pydantic モデルから schema を受け取って enforce する。LangChain、LlamaIndex、Pydantic AI などの基本アダプタも Pydantic。

from pydantic import BaseModel
from anthropic import Anthropic

class SearchQuery(BaseModel):
    query: str
    max_results: int = 10

# Anthropic SDK が schema を抽出して tool definition に変換
client = Anthropic()

11章 · ウェブフレームワーク — FastAPI / Litestar / Robyn / Quart / Sanic / BlackSheep

2026 年の Python ウェブフレームワーク市場はかつてないほど多元化している。各々の強みが異なる。

FastAPI

• 2018 年登場、ASGI ベース。
• Pydantic + Starlette + OpenAPI 自動生成。
• 事実上 ASGI の代表。
• 学習曲線が緩やかで、コミュニティが最大。

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float

@app.post("/items/")
async def create_item(item: Item) -> dict:
    return {"id": 1, **item.model_dump()}

Litestar(旧 Starlite)

• 2022 年に Starlite として始まり、2023 年に Litestar にリブランディング。
• FastAPI に刺激を受けつつより大きな野心(controller、layered DI、plugin system)。
• DTO システム、msgspec/Pydantic/attrs すべて対応。
• 特定条件下では FastAPI より少し速い。

from litestar import Litestar, post
from pydantic import BaseModel

class Item(BaseModel):
    name: str
    price: float

@post("/items/")
async def create_item(data: Item) -> dict:
    return {"id": 1, **data.model_dump()}

app = Litestar([create_item])

Robyn

• 2022 年登場、Rust コア + Python API。
• 単一プロセスでマルチスレッド処理(Rust の tokio を活用)。
• とても速い(FastAPI 比 2〜5 倍スループット)。
• エコシステムは小さいが、性能が切実な現場で選ばれる。

from robyn import Robyn

app = Robyn(__file__)

@app.get("/")
async def hello():
    return "hello, world"

app.start(port=8080)

Quart

• Flask の async 版。
• ほぼ同じ API、Pallets チームの一部が参加。
• Flask エコシステムをそのまま使いつつ async を導入したい時。

Sanic

• 2016 年からのベテラン。
• 速く、blueprint パターン。
• 「単純な ASGI」が欲しい時。

BlackSheep

• .NET ASP.NET の影響を受けた ASGI フレームワーク。
• DI コンテナ、OpenAPI、強い型付け。
• C コアで性能が良い。

選択ガイド

• 始め/チーム小/エコシステム重要 → FastAPI
• エンタープライズ/構造化された大きなアプリ → Litestar
• スループットが切実 → Robyn または BlackSheep
• 既存 Flask コード活用 → Quart
• 単純さ → Sanic

12章 · Django 5.x — フルスタッククラシックの堅牢さ

Django は 2005 年からの大人。2026 年でも Python フルスタックの代表。

Django 5.x の大きな変化

• 5.0(2023-12) — DB 裏付けデフォルト、簡素化された form templates、GeneratedField。
• 5.1(2024-08) — CSRF middleware 再編、ORM での queryset 公開の拡大。
• 5.2(2025-04) — async ORM クエリ一部、自動 model import。

核は async サポートが段階的に成熟中 ということ。ORM の async は 5.2 で一部 stable、全体は 6.0(2026 年末予定)で完成予定。

いつ Django

• 管理画面が必要な時(Django Admin は依然として最高)。
• ORM・migration・auth・forms・templates・テストが一つのパッケージに入っている必要がある時。
• 大きなモノリスが正解な場合。
• Wagtail、django-CMS のような成熟した CMS が必要な時。

いつ使わないか

• 小さな API 一つ — FastAPI/Litestar が軽い。
• 並行性/低レイテンシが極限 — Django は依然 sync 優先。
• マイクロサービス単位 — Django の batteries が負担。

Django Ninja — 同じ ORM、FastAPI スタイル API

from ninja import NinjaAPI
from pydantic import BaseModel

api = NinjaAPI()

class ItemIn(BaseModel):
    name: str
    price: float

@api.post("/items/")
def create_item(request, item: ItemIn):
    return {"id": 1, **item.dict()}

Django の ORM/auth/admin を維持しつつ FastAPI スタイルの API を使いたい時に良い答え。

13章 · パッケージング — uv / Briefcase / Nuitka / PyInstaller

配布形態によってツールが違う。

ライブラリパッケージング — uv build / hatchling

uv build               # sdist + wheel を生成
uv publish             # PyPI アップロード(twine 代替)

内部で hatchling のような PEP 517 ビルドバックエンドを呼ぶ。setup.py は事実上終わった。

単一実行ファイル — PyInstaller / Nuitka

PyInstaller:

uv tool install pyinstaller
pyinstaller --onefile my_app.py
# dist/my_app

利点: ほぼすべてのライブラリと互換。欠点: 大きなバイナリ、AV 誤検知、遅い起動。

Nuitka:

uv add --dev nuitka
python -m nuitka --standalone --onefile my_app.py

利点: Python コードを実際の C にコンパイルするので速くて小さい。欠点: ビルド遅い、一部の動的 import に弱い。

デスクトップ/モバイル — Briefcase(BeeWare)

Python コードを native iOS/Android/macOS/Windows アプリとしてパッケージ化。

uv tool install briefcase
briefcase new
briefcase create iOS
briefcase build iOS
briefcase run iOS

Python 3.13 の iOS/Android Tier 3 サポートと組み合わせて、モバイルで Python を動かすシナリオが現実的になった。

その他

• shiv / zipapp — 単純な zip ベース配布。
• conda-pack — conda 環境ごとパッケージ化。
• Docker — 最も一般的な配布単位。python:3.14-slim + uv の組み合わせが標準。

14章 · クラウド — Modal / Replicate / Pyodide

Modal

• Python 関数をそのままクラウド GPU/CPU で実行。
• デコレータでインフラ定義。
• 「serverless GPU」の代表。

import modal

app = modal.App("ml-job")

@app.function(gpu="A100", timeout=600)
def train(epochs: int):
    import torch
    # 学習コード
    return "done"

if __name__ == "__main__":
    with app.run():
        train.remote(epochs=10)

Replicate

• ML モデルホスティング + API。
• Cog でモデルをコンテナ化。
• Stable Diffusion、LLM などオープンソースモデルの推論によく使われる。

Pyodide

• Python を WebAssembly にコンパイルしてブラウザで実行。
• JupyterLite、Streamlit-in-browser、marimo のブラウザモードなどの基盤。
• 2026 年には numpy、pandas、scipy までほぼすべての科学スタックが動く。

15章 · 韓国 / 日本の Python 活用

韓国

• Toss(トス) — バックエンドは Kotlin 中心だが、ML/データエンジニアリング・内部ツールで Python を活用。採用に Python スキルを明示。
• Kakao(カカオ) — 推薦/検索の ML パイプライン、アドテックのデータパイプライン、KakaoTalk のチャットボットなどに広く使用。
• Naver(ネイバー) — Clova/HyperCLOVA の学習/サービングインフラ、検索のデータパイプライン、LINE の ML バックエンド。
• Coupang(クーパン) — データサイエンス、推薦システム、価格最適化に Python + PySpark。
• Daangn(タンガン、カラット) — ML 推薦、データパイプライン、A/B テスト。

スタートアップトレンド: FastAPI + Polars + uv の組み合わせが急速に標準化中。データ職はほぼ Python 一色。

日本

• メルカリ — ML プラットフォーム、検索 relevance、不正検知に Python。社内 ML プラットフォーム Bakuraku、MLOps に活発に投資。
• PFN(Preferred Networks) — Chainer を作った会社。PyTorch 移行後も Python ML R&D の日本代表。
• LINE ヤフー — 検索・広告・メッセンジャーの ML/データパイプライン。
• DeNA — ゲーム・ヘルスケア・MaaS などで Python ML。
• SmartNews — 推薦システム。

日本は伝統的に Ruby 比重が高かったが、データ・ML 領域で Python への移行が強い。

16章 · 誰が何を選ぶか

状況別の推奨スタック。

データ分析/サイエンス

• Python 3.13(free-threaded はまだ補助)
• uv + Ruff
• Polars(大きなデータ)/ Pandas 3.0(エコシステム互換)
• jupyter / marimo(別記事で扱う)
• scikit-learn、statsmodels、plotly/altair

ML/AI 学習ワークロード

• Python 3.13(free-threaded または標準)
• uv + Ruff
• PyTorch / JAX
• transformers / vLLM / sglang
• Modal(サーバレス GPU)または RunPod、Replicate
• mlflow / wandb

ウェブバックエンド(マイクロサービス)

• Python 3.13 または 3.14
• uv + Ruff + ty(補助)
• FastAPI または Litestar
• Pydantic v2
• SQLModel / SQLAlchemy 2.0 / Tortoise ORM
• Uvicorn / Granian
• Docker: python:3.14-slim

ウェブバックエンド(モノリス + admin)

• Django 5.x
• uv + Ruff
• Django Ninja(REST が必要な時)
• Celery / Django-Q
• PostgreSQL

CLI ツール

• Python 3.14(deferred imports で高速起動)
• uv + Ruff
• Typer または Click
• Rich / Textual(TUI)
• PyInstaller または Nuitka で配布

デスクトップ/モバイル

• Python 3.13/3.14
• Briefcase(モバイル)/ Toga(クロスプラットフォーム UI)
• Nuitka(単一実行ファイル)

組み込み

• MicroPython または CircuitPython(CPython ではない)。
• ただし ARM Linux(Raspberry Pi など)は通常の CPython。

17章 · 移行チェックリスト — 既存プロジェクトを 2026 スタイルへ

既存の Python プロジェクトがあるなら、どう移すか。

ステップ 1 — uv 導入(リスク低)

# pyproject.toml が既にあるなら
uv lock              # uv.lock を生成
uv sync              # venv を生成/同期

# requirements.txt ベースなら
uv add -r requirements.txt

既存ワークフローと並行可能。CI で uv sync && uv run pytest に段階的に切り替え。

ステップ 2 — Ruff 導入(リスク低)

uv add --dev ruff
# 最初は lint だけ、format は black を維持しながら比較
uv run ruff check --select F,E .
# 慣れたらルールを拡張し、format も ruff に

ステップ 3 — Pydantic v1 → v2(中リスク)

API が大きく変わる。変換ツールを使う。

uv tool install bump-pydantic
bump-pydantic src/

ステップ 4 — Pandas → Polars(オプション、大作業)

全面移行より hot path だけ選別。interop がスムーズなので段階的に可能。

ステップ 5 — Python 3.13/3.14 にアップグレード

uv python install 3.14
uv python pin 3.14
uv sync
uv run pytest

free-threaded ビルドは別途検討。C 拡張互換を確認して。

ステップ 6 — 型チェッカー

mypy を使っているなら維持しつつ、ty を CI 補助ゲートとして追加。

18章 · よくある落とし穴とベストプラクティス

• pip install -r requirements.txt を Dockerfile でそのまま使わない — uv を使えばビルドが 10 倍速い。
• import pandas as pd をモジュール最上部に置かない(CLI) — cold start が暴騰。関数内で lazy import するか、3.14 の deferred imports を使う。
• free-threaded ビルドを全ワークロードで使わない — I/O 中心なら標準ビルドの方が速い場合がある。
• Polars を導入する時は lazy モードを積極活用 — eager だけだと Pandas の半分程度の利得に留まる。
• Pydantic モデルを関数呼び出しごとに新規生成しない — スキーマコンパイルコストがある。モジュールレベルで定義。
• asyncio.run() の中で sync ライブラリを呼ばない — イベントループブロック。run_in_executor を使う。
• Ruff の --fix を無批判に適用しない — 一部ルールは意味を変える。diff レビュー必須。
• uv.lock を .gitignore に入れない — チーム環境再現性の核。
• 型チェッカー二つを同時にメインで使わない — 異なるメッセージが衝突。メイン一つ + CI 補助一つ。

19章 · 未来 — 2027〜2028 年展望

• free-threaded がデフォルトに — 3.16 か 3.17 あたりで標準ビルドが free-threaded になる可能性。二つのビルドを維持するコストが大きいため。
• JIT の本格的な性能利得 — 3.15〜3.16 で 10〜30% 向上の期待。
• ty の stable 入り — 2026 年末〜2027 年中盤。
• Polars の追走加速 — Pandas との差拡大、または Pandas が Polars スタイルを吸収。
• Astral の IDE か Python ディストリビューション — 可能性あり。ruff/uv/ty が束ねられた統合体験。
• Pyodide のメインストリーム化 — ブラウザでのデータ分析/可視化が SaaS 標準に。
• モバイル Python — Briefcase + Python 3.14 の iOS/Android stable で小さな native アプリが現実的に。

20章 · まとめ — 二つの変曲点が生んだ新しい Python

2026 年の Python は二つの大きな出来事の交差点に立っている。

1. 言語自体が GIL を外し始めた(PEP 703、3.13 preview → 3.14 stable)。30 年で最大のランタイム変化。CPU バウンドスレッディングが本当に可能になり、asyncio との組み合わせがきれいになる。ただし C 拡張エコシステムが適応するのにあと 2〜3 年かかる。

2. Astral がツールチェーンの半分を Rust で入れ替えた(uv、Ruff、ty)。pip/poetry/flake8/black/isort/mypy が一社のツール 2〜3 個に統合されつつある。速度が 10〜100 倍になり、CI コストと開発者体感が同時に改善した。

加えて Pydantic v2 の Rust コア、Polars の Apache Arrow、FastAPI/Litestar/Robyn の ASGI エコシステム多元化、Pandas 3.0 の Arrow backend 吸収、Django 5.x の async 段階的成熟 — すべての層が同時に動いている。

5 年前の Python コードを見たことがあるなら、2026 年のモダン Python プロジェクトは外観上はほぼ同じに見えるが、その下のツール・ランタイム・データ処理方式がほぼ全部変わった。移行の良い点は、一度にやる必要がないこと。uv 導入 → Ruff 導入 → Pydantic v2 → Polars hot path → Python 3.14 → free-threaded(必要な時のみ)の順で段階的に移せばよい。

Python は 30 年を超えたが、今が他のどの時期よりも速く変わっている時期だ。追いかける甲斐のある変化だ。

参考 / References

• Python 3.13 release notes — https://docs.python.org/3.13/whatsnew/3.13.html
• Python 3.14 release notes — https://docs.python.org/3.14/whatsnew/3.14.html
• PEP 703 — Making the GIL Optional in CPython — https://peps.python.org/pep-0703/
• PEP 744 — JIT Compilation — https://peps.python.org/pep-0744/
• PEP 791 — Deferred Evaluation of Imports — https://peps.python.org/pep-0791/
• PEP 765 — Disallow return/break/continue in finally — https://peps.python.org/pep-0765/
• PEP 734 — Multiple Interpreters in the Stdlib — https://peps.python.org/pep-0734/
• PEP 750 — Template Strings — https://peps.python.org/pep-0750/
• Astral — Company blog — https://astral.sh/blog
• uv documentation — https://docs.astral.sh/uv/
• Ruff documentation — https://docs.astral.sh/ruff/
• ty documentation — https://github.com/astral-sh/ty
• Polars documentation — https://docs.pola.rs/
• Polars 1.0 announcement — https://pola.rs/posts/announcing-polars-1/
• Pandas 3.0 — https://pandas.pydata.org/docs/whatsnew/v3.0.0.html
• Pydantic v2 — https://docs.pydantic.dev/latest/
• FastAPI — https://fastapi.tiangolo.com/
• Litestar — https://litestar.dev/
• Robyn — https://robyn.tech/
• Quart — https://quart.palletsprojects.com/
• Sanic — https://sanic.dev/
• BlackSheep — https://www.neoteroi.dev/blacksheep/
• Django 5 — https://docs.djangoproject.com/en/5.2/releases/
• Django Ninja — https://django-ninja.dev/
• Briefcase / BeeWare — https://beeware.org/project/projects/tools/briefcase/
• Nuitka — https://nuitka.net/
• PyInstaller — https://pyinstaller.org/
• Modal — https://modal.com/
• Replicate — https://replicate.com/
• Pyodide — https://pyodide.org/
• Sam Gross — Free-Threaded Python design — https://github.com/colesbury/nogil
• Python.org downloads — https://www.python.org/downloads/
• PyPI — https://pypi.org/
• PEP index — https://peps.python.org/