プロローグ — 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

整理すると。

| 領域 | 2021 | 2026 |

| --- | --- | --- |

| Python インストール | pyenv | uv |

| venv | python -m venv | uv venv(自動) |

| 依存管理 | pip + requirements.txt | uv + pyproject.toml + uv.lock |

| Lock | pip-tools / poetry | uv(内蔵) |

| Lint | flake8(数十秒) | ruff(ms) |

| Format | black(数秒) | ruff format(ms) |

| Import sort | isort | ruff(統合) |

| 型チェック | mypy / pyright | ty(alpha)/ pyright / mypy |

| DataFrame | Pandas | Polars / Pandas 3.0 |

| 検証 | dataclasses + 手動 | Pydantic v2 |

| Web | Flask/Django/FastAPI | FastAPI/Litestar/Robyn/Django 5 |

| 並行 | asyncio / multiprocessing | free-threaded(3.13+)+ asyncio |

**一行サマリー**: 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 は即時

3.14 — deferred import

from __future__ import deferred_imports

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」。事実だった。

何を置き換えるか

| 既存ツール | uv が置き換える機能 |

| --- | --- |

| pip | install / uninstall |

| pip-tools | requirements compile / lock |

| pipx | グローバル CLI ツールインストール |

| poetry | プロジェクト・依存管理 |

| pipenv | 依存 + venv |

| pyenv | Python インタプリタインストール・管理 |

| virtualenv | venv 作成 |

| twine | パッケージビルド/アップロード(uv build、uv publish) |

別の言い方で、**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 依存)。

| 操作 | pip | poetry | uv |

| --- | --- | --- | --- |

| Cold install | 48s | 62s | 2.1s |

| Warm install | 12s | 18s | 0.4s |

| Lock 生成 | n/a | 24s | 0.9s |

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

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 単一バイナリ」**。

何を置き換えるか

| 既存ツール | Ruff の対応 |

| --- | --- |

| flake8 | `ruff check` |

| pycodestyle | `ruff check`(E ルール) |

| pyflakes | `ruff check`(F ルール) |

| isort | `ruff check --select I` または `ruff format` |

| black | `ruff format` |

| pyupgrade | `ruff check --select UP` |

| autoflake | `ruff check --fix --select F401` |

| bandit(一部) | `ruff check --select S` |

| flake8-bugbear | `ruff check --select B` |

| flake8-comprehensions | `ruff check --select C4` |

| pydocstyle | `ruff check --select D` |

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

基本使用

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 ファイル)。

| ツール | 時間 |

| --- | --- |

| flake8 | 12.3s |

| black --check | 8.1s |

| isort --check | 4.5s |

| pyupgrade | 6.2s |

| **合計(逐次)** | **31.1s** |

| **ruff check + ruff format --check** | **0.4s** |

数十倍の差。これが 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

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)。

| ライブラリ | group-by | join |

| --- | --- | --- |

| Pandas 2.x | 95s | OOM |

| Pandas 3.0(PyArrow) | 41s | 220s |

| Polars 1.0(eager) | 12s | 38s |

| Polars 1.0(lazy) | 6.8s | 22s |

特に 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 の意味

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」の代表。

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

@app.function(gpu="A100", timeout=600)

def train(epochs: int):

学習コード

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/