Python 3.15の新機能まとめ｜10月1日公開、遅延importで起動4倍

3.15の目玉は「起動を速くする遅延import」

Python 3.15が2026年10月1日にリリース予定です。今回もたくさんの変更が入りますが、多くの開発者にとって一番うれしいのは 遅延import（lazy import） だと思います。必要になるまでモジュールを読み込まない仕組みで、これまで「起動が遅い」と言われてきたコマンドラインツールが目に見えて速くなります。

この記事では、Python 3.15を実際に手元にインストールして、主要な変更点を1つずつ動かしながら確認しました。2026年8月4日にリリース候補（3.15.0rc1）が公開されたため、主要な項目は同じ手順で測り直しています。新機能の追加は5月7日に締め切られているので、ここに書いてある内容が正式版の中身です。

「何が新しくなるのか」だけでなく、「これまで何が不便で、それがどう良くなるのか」「3.15に上げたときに動かなくなる古いコードはどれか」まで、実行結果を見ながらまとめています。今回からは、Windowsでプログラムの実行そのものが速くなる変更も入りました。あわせて、3.12が「3.15で削除する」と警告している関数のうち1つが、実際には削除されないことになった件も扱います。移行の手間が1つ減る話です。

今回の検証結果を一覧にまとめました。

この記事で使った検証コードは、すべてGitHubのパブリックリポジトリに置いてあります。uv python install 3.15.0rc1 でリリース候補を入れて、同じ手順で再現できます。

なお、3.13で「インタプリタより遅い」と言われたJITコンパイラも3.15で巻き返していますが、そちらは別の記事（Python 3.15 JIT、軌道に復帰）で詳しく扱っているので、本記事ではそれ以外の変更を中心に見ていきます。

Python 3.15はいつ出る？今の開発状況

Python 3.15の正式リリースは2026年10月1日の予定です（リリース日程をまとめた PEP 790 より）。Pythonは毎年10月に新しいバージョンを出すサイクルになっていて、3.15もこの流れに沿っています。

2026年8月時点で、開発はベータを終えてリリース候補（RC）の段階に入りました。最初のRCである 3.15.0rc1 が2026年8月4日に公開されています。ここで押さえておきたいのは、新機能の追加は2026年5月7日のベータ1で締め切られているという点です。この締め切りを機能凍結と呼びます。つまり「3.15に何が入るか」はすでに確定していて、ここから増えることも減ることもありません。RC以降に入るのは、原則としてバグ修正だけです。

# uvでリリース候補を入れる
$ uv python install 3.15.0rc1
$ python3.15 -VV
Python 3.15.0rc1 (main, Aug 14 2026, 15:34:29) [Clang 22.1.3 ]

本記事は6月にベータ2（3.15.0b2）で検証した内容をもとにしていますが、RC1の公開を受けて主要な項目を同じ手順で測り直しました。結果は各セクションに追記しています。結論から言うと、性能まわりの傾向は変わっていません。ただし削除される予定だった機能のうち1つが、RCで方針転換していました。後半の「使えなくなる古いコード」で詳しく扱います。

RC版は「正式版と同じ中身で最終確認をしている段階」なので、本番に入れる前の互換性チェックには十分使えます。uv python install 3.15.0rc1 で今のPythonを消さずに並べて入れられるので、CIで自分のコードを一度通しておくと、10月の正式版が出た日にあわてずに済みます。

起動が速くなる「遅延import」とは（PEP 810）

今回の一番の目玉です。Pythonでは import をファイルの先頭にまとめて書くのが定石ですが、これだと「使うかどうかわからないモジュール」もプログラム起動時にすべて読み込まれます。コマンドラインツールが --help を表示するだけなのに、裏で何十個ものモジュールを読んでいる、というのはよくある話です。

これまでは、対策として「重い import を関数の中に隠す」という書き方が使われてきました。PEP 810によると、標準ライブラリの import の約17%が、この回避策のために関数の中に散らばっているそうです。3.15では、これを言語の機能として正面から解決します。import の前に lazy を付けるだけです。

# lazy を付けると、json はこの時点ではまだ読み込まれない
lazy import json

print("json in sys.modules before first use:", "json" in sys.modules)
# => False（まだ読み込まれていない）

# 名前を初めて「使った」瞬間に、本物のモジュールが読み込まれる
json.dumps({"hello": "world"})
print("json in sys.modules after first use: ", "json" in sys.modules)
# => True（ここで読み込まれた）

実際に動かすと、最初のアクセスまで json が読み込まれていないことがはっきり確認できました。lazy import と書いた行では、本物のモジュールの代わりに「身代わり（プロキシ）」が置かれているだけで、名前を初めて使ったときに本物に入れ替わる仕組みです。

どれくらい速くなるのか実測した

体感ではなく数字で見たいので、重ための標準ライブラリ5つ（json, pathlib, argparse, logging, http.client）を import するだけのスクリプトを用意し、「普通に import した場合」と「lazy import にして使わなかった場合」で、起動から終了までの時間を30回ずつ測りました。

下の表は6月にベータ2で測ったときの値です。8月にリリース候補（rc1）で同じスクリプトを実行し直しましたが、結果はほぼ同じでした（この節の最後に併記します）。

起動時間は 約21ミリ秒から約5ミリ秒へ、おおよそ4倍。読み込まれるモジュール数も 122個から26個に減りました。もちろんこれは「import したものを使わなかった」極端な例なので、実際の効果は何を import しているかによります。それでも、起動のたびに毎回読み込んでいた重いライブラリを後回しにできる効果は大きいです。コマンドを叩くたびに一瞬待たされていたツールが、きびきび動くようになります。

同じスクリプトを、8月に公開されたリリース候補（3.15.0rc1）でもう一度実行しました。

2か月経っても差は変わりませんでした。約4倍という比率も、モジュール数が4分の1近くまで減ることも同じです。遅延importを使わない側のモジュール数がわずかに増えているのは、標準ライブラリの構成が少し変わったためで、効果そのものには影響していません。この機能は仕様として固まったと考えて差し支えありません。

関数の中に隠していたimportを卒業できる

速くなるのは確かにうれしいのですが、私が一番ありがたいと思ったのは可読性のほうです。これまで「起動を速くするためだけに、重いimportを関数の中に書く」という回避策がよく使われてきました。先ほど触れたとおり、標準ライブラリでも約17%のimportがこの理由で関数の中に散らばっているそうです。設計上の都合でやむなくそうしていた、という人も多いはずです。

3.15では、こうしたimportをファイルの先頭の lazy import に戻せます。依存しているライブラリが冒頭にきれいに並ぶので、「このファイルが何に依存しているか」が一目でわかります。関数の中のimportのように、呼ぶたびに名前解決のコストがかかることもありません。起動の速さと読みやすさを、両方あきらめずに済みます。

ただし、すべての関数内importが不要になるわけではありません。「OSや実行環境によって必要なときだけ重いライブラリを読む」「循環import（お互いを参照し合うモジュール同士）を避けるためにわざと遅らせている」といった、ロジック上の理由がある場合は、関数の中に置いたままのほうが意図が伝わります（lazy import はトップレベルにしか書けませんし、循環importを自動で解消してくれるわけでもありません）。起動高速化のためだけに散らしていたimportは堂々と先頭へ戻し、理由があるものは残す。この線引きさえ守れば、可読性は確実に上がります。

使うときの注意点

便利な反面、いくつか落とし穴があります。実際に試して分かった点を挙げておきます。

• • 書ける場所が限られる。lazy import はファイルのトップレベルにだけ書けます。関数の中や try の中、from x import * のような書き方には使えません。
• • エラーが出るタイミングが後ろにずれる。存在しないモジュールを lazy import しても、import 行ではエラーになりません。初めて使ったときに初めて失敗します。
• • import した瞬間に何かをするモジュールと相性が悪い。読み込まれた時点で登録処理などをするライブラリは、使うまでその処理が走りません。

なお、lazy import と明示的に書いた分は、特別なオプションなしでもそのまま遅延されます。ソースを書き換えずにプログラム全体をまとめて遅延化したい場合は、起動オプション -X lazy_imports=all、または環境変数 PYTHON_LAZY_IMPORTS=all を使います。リリース候補で実際に試したところ、この値は all（すべてのimportを遅延にする）と normal（既定。lazy と書いた行だけ遅延する）の2つでした。それ以外を渡すと invalid value; expected 'all' or 'normal' と言われて起動しません。先ほどのスクリプトを lazy を書かないまま -X lazy_imports=all で動かすと、読み込まれるモジュールは124個から32個へ落ちました。ソースを1行も触らずに同じ効果が出ます。全体を all にすると、先ほど挙げた「import時に登録処理をするライブラリ」などで思わぬ副作用が出ることがあるので、まずは lazy キーワードで狙った行だけ遅延させるのが安全です。

文字化けが消える？UTF-8が標準の文字コードに（PEP 686）

3.15では、文字コード（テキストをコンピュータが扱うための符号）の標準が UTF-8 になります。UTF-8は世界中の文字を扱える事実上の標準的な文字コードです。

これまでのPythonは、open() でファイルを開くときに encoding を指定しないと、OSの地域設定（ロケール）に従っていました。日本語版Windowsでは、これがUTF-8ではなく cp932 という古い文字コードになっていて、UTF-8で書かれたファイルを読むと文字化けする、という事故が起きがちでした。3.15では、この既定値がUTF-8に統一されます。

# 3.15 で実行（encoding を指定していない）
import sys
print("sys.flags.utf8_mode:", sys.flags.utf8_mode)   # => 1

with open("sample.txt", "w") as f:   # encoding= を書いていない
    print("default open() encoding:", f.encoding)     # => utf-8
    f.write("日本語テキスト")

3.15では、UTF-8モードを表す sys.flags.utf8_mode が、何も指定しなくても 1（オン） になっていました。3.12では同じ確認をすると 0（オフ） です。

正直に書いておくと、LinuxやmacOSのように元からUTF-8の環境では、体感の差はほとんどありません（もともと open() はUTF-8で開けていました）。この変更が効くのは主にWindowsです。「encodingを指定し忘れたら文字化けした」というあの定番のトラブルが、デフォルトで起きにくくなる、というのが本質です。

逆に、古い文字コードのファイルを前提にしていたコードは、3.15で挙動が変わる可能性があります。元の「ロケールに従う」挙動に戻したいときは、環境変数 PYTHONUTF8=0 を設定するか、起動時に -X utf8=0 を付けます。個別のファイルだけ元の挙動にしたいときは open(..., encoding="locale") と書けます。

稼働中でも性能を測れる新しいプロファイラ（PEP 799）

プロファイラとは「プログラムのどこで時間がかかっているか」を測る道具です。3.15には profiling.sampling という新しいプロファイラが標準で入りました。一定間隔で「今どこを実行しているか」をサンプリングする方式で、プログラムをほとんど遅くせずに測れるのが特長です。

これまでの cProfile は、測りたいコードをあらかじめ仕込んでおく必要がありました。新しいプロファイラは、すでに動いているプログラムに後から接続して測れるのが大きな違いです。「本番でなぜか重いプロセス」に、プログラムを止めずにプロセス番号を指定して接続できます。

# スクリプトを実行しながら測り、インタラクティブなflamegraphを出力
$ python3.15 -m profiling.sampling run -r 10khz \
    --flamegraph -o flamegraph.html workload.py

# すでに動いているプロセス（PID 12345）に後から接続して測る
$ python3.15 -m profiling.sampling attach 12345 --mode cpu

試しに、フィボナッチ数列を計算する重めのスクリプトを毎秒1万回のペースでサンプリングしてみました。結果は、処理時間の 83.7% が再帰的なフィボナッチ計算に費やされている、と一目で分かる形で出ました。下のflamegraph（炎のグラフ。横幅がそのまま「そこで使った時間の割合」を表します）は、実際に出力されたものをそのまま埋め込んでいます。バーをクリックすると掘り下げられます。

↑ Python 3.15の profiling.sampling が生成したflamegraph（別タブで開く）

出力形式は他にも、従来の cProfile 風の表（--pstats）、行ごとの負荷を色で示すヒートマップ（--heatmap）、ターミナル上でリアルタイムに見る表示（--live）などが選べます。「全体時間」だけでなく「CPUを使っていた時間だけ」「GILを持っていた時間だけ」といった測り方も指定できます。なお、これまでの cProfile 系は profiling.tracing という名前に整理されました。

Windowsでは実行そのものが速くなる

ここまでは「起動」の速さの話でしたが、3.15ではプログラムの実行そのものが速くなる変更も入りました。しかも、こちらは対象がWindowsに限られます。3.15から、公式が配布する64ビット版Windowsのインタプリタ（Pythonのコードを解釈して実行する本体）が、tail-calling interpreter（末尾呼び出し型インタプリタ）という新しい作りに切り替わったためです。

これまでのインタプリタは、命令を1つの巨大な分岐（switch文）でさばいていました。この作りはコンパイラにとって最適化しづらく、性能の頭打ちの原因になっていました。tail-calling方式は、命令のひとつひとつを小さな関数に分け、次の命令へ「バトンを渡す」ように呼び出していきます。こう書き換えると、コンパイラが各命令を効率よく機械語に落とし込めるようになります。LinuxやmacOS向けのビルドでは、コンパイラ（Clang）が対応していたため以前から使えていましたが、Windowsで使うMSVC（Microsoftのコンパイラ）が長らく未対応で、Windowsだけが取り残されていました。

その壁が、Visual Studio 2026で追加された [[msvc::musttail]] という指定によって外れました。CPython開発者のKen Jin氏の計測では、Windows（x86-64）で平均15〜16%、ベンチマークによっては40%近く速くなったと報告されています（spectralnormで約1.48倍、nbodyで約1.35倍、Djangoのテンプレート処理で約1.18倍など）。数字はあくまで特定のベンチマークでの値ですが、CPythonのインタプリタが二桁パーセント速くなるのは珍しく、Windowsでサーバーやバッチ処理を回している人にはうれしい変化です。

うれしいのは、これを享受するのにコードの書き換えが一切いらない点です。3.15の公式Windowsバイナリを使うだけで自動的に効きます。Linux・macOSではもともと有効だったので、体感が変わるのは主にWindowsユーザーです。実行環境をWindowsに置いている場合、3.15へ上げるだけで地力が底上げされる、と考えておいてよいでしょう。

地味に効く新機能（内包表記の展開・新しい型・親切なエラー）

内包表記の中で展開できる（PEP 798）

リストの中にリストが入っている入れ子構造を「1段ならす（平坦化する）」とき、これまでは for を2回書く必要がありました。3.15では * を使って素直に書けます。

lists = [[1, 2], [3, 4], [5]]

# これまで（forを2回）
old = [x for sub in lists for x in sub]

# 3.15（* で展開）
new = [*sub for sub in lists]

print(new)   # => [1, 2, 3, 4, 5]

辞書をまとめる {**d for d in dicts} のような書き方もできます。劇的な変化ではありませんが、「あの入れ子のfor、毎回読みづらかった」という人には地味にうれしい改善です。

変更できない辞書と「目印」の値が組み込みに

中身を変更できない辞書 frozendict（PEP 814）と、「値がない」ことを表す目印を作る sentinel（PEP 661）が、追加のインストールなしで使えるようになりました。

# 変更できない辞書
config = frozendict(host="localhost", port=8080)
config["port"] = 9090
# => TypeError: 'frozendict' object does not support item assignment

# 「値が渡されなかった」を None と区別して表せる目印
MISSING = sentinel("MISSING")
print(MISSING)   # => MISSING

frozendict は変更できないので、辞書のキーにしたり、書き換えられたくない設定として安全に渡せます。sentinel は「引数が省略された」のか「None が明示的に渡された」のかを区別したいときに便利で、これまで各自が自前で用意していたものが標準になりました。

エラーメッセージが他言語経験者にやさしくなった

他の言語から来た人がやりがちな間違いに対して、正しいメソッド名を提案してくれるようになりました。実際に3.15で動かすと、こう出ます。

>>> [1, 2, 3].push(4)
AttributeError: 'list' object has no attribute 'push'. Did you mean '.append'?

>>> "hello".toUpperCase()
AttributeError: 'str' object has no attribute 'toUpperCase'. Did you mean '.upper'?

>>> {}.put("a", 1)
AttributeError: 'dict' object has no attribute 'put'. Use d[k] = v.

JavaScriptの .push() やJavaの .put() を、Pythonの正しい書き方にそっと案内してくれます。1つ実測でのメモを残しておくと、この提案文はエラーを画面に表示するときに付くもので、except で捕まえて str(例外) をそのまま出しても提案は出ません（traceback モジュール経由で整形すると出ます）。

3.15で使えなくなる古いコード（移行時の注意点）

古いバージョンから3.15へ一気に上げると、これまで動いていたコードが動かなくなることがあります。長く非推奨だった機能が、3.15でいくつか正式に削除されました。同じスクリプトを3.12と3.15で実行して、何が消えたかを実際に確認しました。

実行結果はこうなりました。[GONE] が「削除されて動かない」、[OK] が「まだ使える」です。

# Python 3.15.0rc1 で再実行（2026年8月）
  [GONE] sre_compile module: ModuleNotFoundError
  [GONE] sre_parse module: ModuleNotFoundError
  [GONE] sre_constants module: ModuleNotFoundError
  [GONE] pathlib.PurePath.is_reserved(): AttributeError
  [GONE] http.server.CGIHTTPRequestHandler: AttributeError
  [GONE] types.CodeType.co_lnotab: AttributeError
  [OK]   locale.getdefaultlocale()

6月にベータ2で試したときと同じ結果です。上の6つは正式版でも削除されたままだと考えて差し支えありません。

sre_compile などは正規表現の内部実装用モジュールで、普通は直接 import しません。ただ、一部のライブラリが内部で触っていることがあるので、3.15で急に動かなくなったライブラリがあれば、ここが原因かもしれません。

「3.15で削除」と言われていた locale.getdefaultlocale() は残ります

表の最後の行だけ、6月の記事から結論が変わりました。locale.getdefaultlocale() は、実行環境の言語と文字コードを調べる関数です。3.12で使うと、名指しでこう警告されます。

# Python 3.12.14
DeprecationWarning: 'locale.getdefaultlocale' is deprecated and
slated for removal in Python 3.15.
Use setlocale(), getencoding() and getlocale() instead.
（3.15で削除される予定です。setlocale()、getencoding()、getlocale()を使ってください）

この警告を見て、書き換えを予定していた方は多いはずです。ベータ2の時点では「警告どおり削除されるはずなのに、まだ残っている」という中途半端な状態でした。ところがRC1で確認すると、警告そのものが出なくなっていました。

# Python 3.15.0rc1
>>> import warnings, locale
>>> warnings.simplefilter("always")
>>> locale.getdefaultlocale()
('C', 'UTF-8')      # 警告なし

公式ドキュメントを追うと、答えが書いてありました。この関数は非推奨の指定そのものが取り消されています（CPythonの課題 gh-130796、Victor Stinner氏による変更）。削除が先送りされたのではなく、削除する方針が撤回されたということです。

実務上の意味ははっきりしています。この関数のためだけに書き換えを予定していたなら、その作業はもう要りません。3.12や3.13で出ている警告は、3.15に上げた時点で消えます。逆に言えば、3.12の警告文だけを信じて一括置換をかけると、必要のない差分を作ることになります。

「ドキュメントに削除予定と書かれていても、実際にそうなるとは限らない」というのは、ベータやRCを実際に動かしてみないと分からない部分です。非推奨の警告は予告であって確定ではない、という一例として覚えておくと役に立ちます。

このほか、正規表現の re.match() も「文字列の先頭から一致を調べる」という意味が紛らわしいとして、re.prefixmatch() という名前が新しく用意され、re.match() はゆるやかに非推奨になりました（今すぐ消えるわけではありません）。

3.15へアップグレードすべき？

正式版は2026年10月1日、この記事を書いている時点で残り約5週間です。今すぐ本番を上げる話ではありませんが、3.15は「待つ価値のあるバージョン」だと思います。とくに遅延importは、起動の遅さに悩んでいたコマンドラインツールや、たくさんのライブラリを読み込むアプリにとって、わかりやすい効果があります。Windowsで動かしている場合は、上で見たとおり実行そのものも速くなるので、上げるだけで得をする場面が多いはずです。

一方で、UTF-8の標準化と古いAPIの削除は、移行時に挙動が変わる可能性がある部分です。やることはシンプルで、リリース候補を入れて自分のコードやテストを一度通してみるだけです。機能はすでに確定しているので、いま試して通れば、10月の正式版でもそのまま通ります。uv python install 3.15.0rc1 で並行して入れられるので、今のPythonはそのままにしてCIで試すのがおすすめです。本記事の検証コードはGitHubのリポジトリにまとめてあるので、手元での確認の出発点に使ってください。

逆に、いま急いでやらなくてよいことも1つはっきりしました。3.12が「3.15で削除する」と警告している locale.getdefaultlocale() の書き換えです。削除の方針が撤回されたため、この警告に合わせた修正は不要になりました。非推奨の警告をまとめて潰す作業を予定しているなら、この1件は外して構いません。

高速化という観点では、今回触れなかったJITコンパイラの改善も大きいです。そちらはPython 3.15 JIT、軌道に復帰にまとめています。また、Python開発の屋台骨であるツール周りの動きとしてはOpenAIがruff・uvの開発元を買収した話もあわせてどうぞ。

検証環境と参照元

検証環境: 初回の計測は Python 3.15.0b2（2026年6月11日ビルド） / Linux aarch64 / 比較対象は Python 3.12.13。2026年8月の追試は Python 3.15.0rc1（2026年8月14日ビルド） / Linux aarch64 / 比較対象は Python 3.12.14 で、遅延importの起動時間、削除されたAPI、UTF-8モードの既定値、新しく入った型と関数の動作を同じ手順で測り直しています。数値はいずれも手元で計測した実測値です。Windowsの実行高速化（平均15〜16%）は当方のLinux環境では測れないため、CPython開発者 Ken Jin 氏の計測値を引用しています。

• • 検証コード一式（GitHubリポジトリ） ― この記事の全コードと実行結果
• • What's New In Python 3.15（公式ドキュメント）
• • PEP 790 – Python 3.15 Release Schedule
• • PEP 810 – Explicit lazy imports（遅延import）
• • PEP 686 – Make UTF-8 mode default / PEP 799 – Sampling profiler / PEP 798 – Unpacking in comprehensions
• • PEP 814 – frozendict（変更できない辞書） / Deprecations（非推奨・削除の一覧）
• • Ken Jin — Windowsでのtail-callインタプリタ高速化の計測（Windowsの15〜16%高速化の出典）
• • JetBrains — Explicit Lazy Imports Are Coming to Python 3.15