Python 3.15 の新機能は？いつ出た？UTF-8 の既定化・入れ方【2026年10月】

Python 3.15 は、2026年10月9日に出た Python の最新の安定版です（2026年10月時点）。公式がいちばん大きな変更として挙げているのは、import を使うときまで遅らせる lazy import、変えられない辞書 frozendict、既定の文字コードが UTF-8 になること、などです。

この記事は、Python を使っていて、3.15 で何が変わったか、上げてよいか、どう入れるかを知りたい人に向けて、公式の資料に書かれていることを整理します。Python という言語そのものの使われ方や代表的なフレームワークは、需要の高い人気プログラミング言語＆フレームワーク【将来性】で紹介しています。公式の文書は正式版のあとも書き換わるので、2026年10月10日に確かめた内容です。

この記事でわかること

Python 3.15.0 は2026年10月9日に出て、バグ修正は約2年、セキュリティ修正は2031年10月ごろまで続く予定であること
既定の文字コードが UTF-8 になる変更（PEP 686）の中身と、影響が出るのは「encoding を書かずに開いたファイルが UTF-8 でないとき」であること
lazy import・frozendict・sentinel・内包表記のアンパックなど、新しい書き方と、わかりやすくなったエラーメッセージ
速さの数字は条件つきであることと、ふつうの 3.15 には GIL があること
Mac・Windows・uv での入れ方と、古い uv だと RC（正式版の候補）が入ることがあること

この記事で確かめた版（2026年10月時点）

公式の文書: What's New in Python 3.15 は、2026年10月10日に更新された版を読みました
出力例: macOS（Apple Silicon）で、Python 3.15.0 と 3.14.8 を uv 0.13.0 で入れて動かした結果です。python.org のインストーラは使っていません。出力の中の /path/to/ は、作業フォルダの場所を置き換えたものです
Windows: 公式の文書のとおりに書いています。Windows で動かした結果は載せていません

Python 3.15 はいつ出た？サポートはいつまで？
1. 開発の日程
2. サポートはいつまで？
Python 3.15 の主な新機能は？（公式の一覧）
既定の文字コードが UTF-8 に：何が変わる？（PEP 686）
lazy import（遅延 import）とは？書き方と制限
frozendict・sentinel・内包表記のアンパック：新しい書き方
エラーメッセージ・色・標準ライブラリの変更
Python 3.15 は速くなった？JIT・Windows 版・GIL の話
上げる前に見る所：消えたもの・非推奨・動きが変わったもの
Python 3.15 の入れ方（Mac・Windows・uv）
よくある質問
まとめ
参考資料

Python 3.15 はいつ出た？サポートはいつまで？

正式版の Python 3.15.0 は、2026年10月9日に出ました。python.org の記録では、2026年10月9日 13:54:59（UTC。世界の標準時）で、日本時間では10月9日の 22:54 です。公式の What's New も、冒頭で「2026年10月9日に出た」と書いています。

3.15 は、Python のいちばん新しい安定版（stable release）で、言語・実装・標準ライブラリの変更が混ざっています。リリースのページは、3.14 と比べて 5,643 のコミット、1,012 人の貢献者による版だと書いています。

開発の日程

開発の日程は、PEP 790（3.15 のリリースの計画を書いた文書）に書かれています。PEP は、Python の機能や決まりごとを提案する文書のことです。次の日付は、計画の表に書かれている実績の日付です。RC は、正式版の候補（release candidate）のことです。

段階	日付
開発の開始	2025-05-07
アルファ 1	2025-10-14
ベータ 1（ここから新機能は入らない）	2026-05-07
RC 1	2026-08-04
RC 2	2026-09-01
RC 3	2026-10-02
正式版	2026-10-09

新しい版は12か月ごとに出す決まり（PEP 602）で、3.15 の開発期間は17か月でした。このあとの修正版（3.15.1 など）は、2か月ごとに出ます。ひとつ前の3.14 系の最新は 3.14.8 で、2026年9月30日（UTC。日本時間では10月1日）に出ています。次の 3.16 は2027年10月6日の予定で、いまは main ブランチが 3.16 になっています（新機能を受け付けるのはここだけです）。予定の日付は動くことがあります。

サポートはいつまで？

3.15 は、約2年のあいだ、だいたい2か月ごとにバグ修正の版が出ます。3.17.0 が出るころに、3.15 の最後のバグ修正版が出ます。そのあとの3年は、セキュリティの修正だけがソースの形で配られ、3.15.0 から5年後の2031年10月ごろまで続きます。

開発者ガイドは、状態を3つに分けています。

bugfix: バグ修正とセキュリティ修正を受け付け、およそ2か月ごとに新しいバイナリ（インストーラーなど）が出る
security: 2年たつと（3.13 より前の版は18か月）、セキュリティ修正だけを受け付ける。バイナリはもう出ない
end-of-life: リリースから5年でサポートが終わる

2026年10月10日時点の開発者ガイドの表では、各版は次のようになっています。サポート終了の日付は、斜体（予定）で書かれていて、調整されることがあります。

版	状態	サポート終了
3.15	bugfix	2031-10（予定）
3.14	bugfix	2030-10（予定）
3.13	security	2029-10（予定）
3.12	security	2028-10（予定）
3.11	security	2027-10（予定）
3.10	end-of-life	2026-10-01（最後の版は 3.10.22）

3.10 は、2026年10月1日にサポートが終わりました。

Python 3.15 の主な新機能は？（公式の一覧）

公式の What's New は、いちばん大きな変更として、lazy import（遅延 import）、組み込みの frozendict と sentinel、UTF-8 が既定の文字コードになること、内包表記の中のアンパック、free-threaded 版向けの安定 ABI を挙げています。標準ライブラリでは、新しいプロファイル用のパッケージと、Tachyon という高頻度のサンプリング型プロファイラ、コマンドの出力の色の増加です。プロファイルは、プログラムのどこに時間がかかっているかを測ることです。

公式の一覧を、分類ごとに並べます。

分類	変更	PEP
インタープリタ	sentinel 型を組み込みに追加	661
インタープリタ	UTF-8 が既定の文字コードに	686
インタープリタ	内包表記の中のアンパック	798
インタープリタ	起動を速くするための、明示的な lazy import	810
インタープリタ	frozendict 型を組み込みに追加	814
インタープリタ	起動時の設定ファイル	829
インタープリタ	実験的な JIT コンパイラの大きな改良	―
インタープリタ	エラーメッセージの改善	―
標準ライブラリ	プロファイル用のパッケージ（profiling）	799
標準ライブラリ	Tachyon（高頻度のサンプリング型プロファイラ）	799
標準ライブラリ	色が増えた	―
型ヒント	TypedDict の追加の項目に型を付ける	728
型ヒント	TypeForm で型そのものに注釈を付ける	747
型ヒント	型の仕組みの disjoint base	800
C API・ビルド	PyBytesWriter／終了処理からの保護／free-threaded 版の安定 ABI／フレームポインタが既定で有効	782／788／803・820・793／831
配り方	python.org の Windows 64 ビット版が tail-calling インタープリタを使う。macOS 版が free-threading を既定で入れる	―

型ヒントは、変数や関数に型を書き添える書き方です。C API・ビルドの行は、Python の拡張モジュールを作る人向けの変更なので、この記事では取り上げません。

公式は、What's New は全部の仕様ではなく概要だと書いています。上げるときは、同じページの「Porting to Python 3.15」の節も見るよう案内しています。また、PEP は機能ができあがったあとは更新されないことが多いので、詳しい仕様は PEP より文書のほうを見るよう書かれています。

以降の節では、初心者にも関係が大きいものを順に説明します。

既定の文字コードが UTF-8 に：何が変わる？（PEP 686）

文字コード（encoding）は、文字をコンピュータの中のバイト（数字の並び）に直す決まりです。テキストファイルを読み書きするとき、Python は、どの決まりを使うかを知る必要があります。open() で encoding を書かなかったときに使われるのが、既定の文字コードです。

公式は、3.15 から、Python はシステムの環境に関係なく UTF-8 を既定の文字コードに使うと書いています。たとえば open('flying-circus.txt') のように encoding を書かずにファイルを開くと、UTF-8 で読み書きします。

誰に影響が出る？

変わるのは、encoding 引数を書かなかったときだけです。公式は、版をまたいで同じに動かすには、encoding をいつも書くよう勧めています。

PEP 686 は、影響を受ける人を次のように書いています。多くの Unix 系の OS は UTF-8 のロケール（OS の地域・言語の設定）を使っていて、Python はロケールが C や POSIX のときは前から UTF-8 モードになっていました。そのため、この変更が影響するのは、おもに Windows の利用者です。

Windows の文書は、Windows は今もシステムの文字コードに昔からの文字コード（ANSI コードページ）を使っていると書いています。UTF-8 モードを切ると、Python はテキストファイルの既定に ANSI コードページを使います。日本語版の Windows でどの文字コードが使われているかは、この記事で確かめた公式の資料には書かれていませんでした。

PEP 686 は、既定の文字コードに頼っているプログラムでは、UnicodeError（文字コードを変換できないエラー）、文字化け、気づかないデータの破損が起こりうると書いています。

影響が出る例を、macOS で動かして確かめました。cp932（日本語の文字コードのひとつ）で書いたファイルを、encoding を書かずに開くと、3.15.0 は UTF-8 として読もうとして、エラーになります。encoding="cp932" を書けば読めます。

with open("sjis.txt", "w", encoding="cp932") as f:
    f.write("こんにちは\n")
try:
    with open("sjis.txt") as f:
        print(f.read())
except UnicodeDecodeError as e:
    print("UnicodeDecodeError:", e)
with open("sjis.txt", encoding="cp932") as f:
    print(f.read(), end="")

Python 3.15.0・macOS で動かした出力です。

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x82 in position 0: invalid start byte
こんにちは

公式は、既定の文字コードが UTF-8 になるのは、システムの環境に関係なく、と書いています。Windows では動かして確かめていません。

Mac では見た目が変わらない

手元の macOS では、LANG=ja_JP.UTF-8 のときも、LANG が空（C ロケール）のときも、3.14.8 の open() の既定がすでに UTF-8 だったので、見た目の違いは出ませんでした。次は、LANG=ja_JP.UTF-8 の macOS で、3.14.8 と 3.15.0 に次のスクリプトを動かして比べた結果です。sys.flags.utf8_mode は、UTF-8 モードの状態を読む値で、1 なら有効です。

import sys, locale
print("utf8_mode:", sys.flags.utf8_mode)
print("getpreferredencoding(False):", locale.getpreferredencoding(False))
print("getencoding():", locale.getencoding())
with open("sample.txt", "w") as f:
    print("open() default encoding:", f.encoding)

動かした Python	`sys.flags.utf8_mode`	`open()` の既定の文字コード
3.14.8	0	UTF-8
3.15.0	1	utf-8
3.15.0（`-X utf8=0` を付けた）	0	UTF-8

どの場合も、open() の既定は UTF-8 でした。LANG を空（C ロケール）にして動かすと、3.14.8 でも utf8_mode が 1 になりました。PEP 686 の「ロケールが C か POSIX のときは前から UTF-8 モード」という説明のとおりです。

どう直す？どう探す？

encoding をいつも書く。 公式の勧めです。たとえば UTF-8 のファイルなら open("data.txt", encoding="utf-8") と書きます。古いファイルを読むときは、そのファイルを保存した文字コードを書きます。Python が扱える日本語の文字コードの名前には、cp932（別名 932・ms932・mskanji・ms-kanji・windows-31j）と shift_jis（別名 csshiftjis・shiftjis・sjis・s_jis）があります
影響を受ける所を探す。 オプトイン（自分で有効にする）の警告 EncodingWarning を使えます。-X warn_default_encoding を付けて動かすか、環境変数 PYTHONWARNDEFAULTENCODING を設定すると、既定の文字コードが使われた所で警告が出ます（3.10 から）
OS のロケールの文字コードを使いたいときは、encoding='locale' と書く。 3.10 から使えます
急いで前の動きに戻すときは、UTF-8 モードを切る。 環境変数 PYTHONUTF8=0、またはコマンドのオプション -X utf8=0 です。UTF-8 モードを切れるのは、Python を起動するときだけです

2 の例です。次のファイルで、encoding を書いた 2 つ目の open では警告が出ません。3.15.0 でも 3.14.8 でも、同じ警告が出ました。

with open("sample.txt", "w") as f:
    f.write("abc")
with open("sample.txt", "w", encoding="utf-8") as f:
    f.write("abc")

python -X warn_default_encoding warn_demo.py で動かしたときの出力です（Python 3.15.0・macOS）。

/path/to/warn_demo.py:1: EncodingWarning: 'encoding' argument not specified
  with open("sample.txt", "w") as f:

4 の注意です。Windows の公式の文書は、PYTHONUTF8 を Windows の既定の環境変数に入れると、そのパソコンの Python 3.7 以降のアプリすべてに効くと書いています。昔の文字コードに頼るアプリがあるなら、環境変数は一時的に設定するか、-X utf8 のオプションを使うのがよい、というのが公式の勧めです。

PEP 686 の直し方の指針には、ほかに次もあります。

locale.getpreferredencoding() を使っている所は、"utf-8" か locale.getencoding() に変えることを考える
UTF-8 モードでアプリをテストする

Windows で前から UTF-8 だったものと、"mbcs"

Windows の文書によると、UTF-8 モードを切っていても、コンソールの入出力（標準入出力）とファイル名の文字コードには、前から UTF-8 が使われています。UTF-8 モードのままでも、ANSI コードページは "mbcs" という名前の文字コードで使えます。

UTF-8 モードでは、open() などが UTF-8 を既定で使いますが、エラーの扱いは strict のままです。バイナリのファイルをテキストとして開くと、おかしなデータを返すのではなく、例外になりやすいと、公式は書いています。

なぜ UTF-8 に？

PEP 686 が挙げる理由は、UTF-8 が事実上の標準になったことです。Python のソースファイルの既定は UTF-8 で、JSON・TOML・YAML も UTF-8 を使い、Visual Studio Code や Windows のメモ帳などたいていのエディタが既定で UTF-8 を使う、と PEP は書いています（これは PEP の主張で、各エディタの文書では確かめていません）。また、Unix の利用者も、既定の文字コードが OS で違うことを忘れて、UTF-8 のファイルを encoding="utf-8" なしで読みがちで、既定がそろっていないことが多くのバグの元になっていた、と書かれています。

lazy import（遅延 import）とは？書き方と制限

import は、ほかのモジュール（Python のファイル）を読み込んで使えるようにする書き方です。公式は、大きな Python のアプリは起動が遅くなりがちで、import がその大きな原因のひとつだと書いています。モジュールを import するとき、Python はファイルを探し、ディスクから読み、バイトコード（Python が動かす形に直したもの）にして、トップレベルのコードを全部動かします。依存が深いアプリでは、その実行では使わないコードのために、数秒かかることもあります。

3.15 の lazy import は、この読み込みを後回しにする書き方です。import の前に、新しいソフトキーワード lazy を付けます。Python は、その名前を最初に使うときまで、モジュールの読み込みを遅らせます。公式は、import をファイルの先頭にまとめて書けて、読み込む手間は使うモジュールの分だけになる、と説明しています。import と from ... import の両方に使えます。

次は、公式の例をもとにしたスクリプトです。sys.modules は、読み込み済みのモジュールの一覧で、json が入っているかで読み込まれたかがわかります。

import sys
lazy import json
lazy from pathlib import Path
print("Starting up...")
print("json in sys.modules before use:", "json" in sys.modules)
data = json.loads('{"key": "value"}')
print("json in sys.modules after use:", "json" in sys.modules)
print(data)
p = Path(".")
print(p)

Python 3.15.0・macOS で動かした出力です。json が読み込まれるのは、使った行（json.loads）のあとでした。

Starting up...
json in sys.modules before use: False
json in sys.modules after use: True
{'key': 'value'}
.

同じスクリプトを Python 3.14.8 で動かすと、新しい書き方なので SyntaxError になりました。

  File "/path/to/lazy_demo.py", line 2
    lazy import json
         ^^^^^^
SyntaxError: invalid syntax

読み込みに失敗したときは、使った所でエラーになる

lazy import した名前の読み込みに失敗すると（モジュールが無いときなど）、エラーは import の行ではなく、最初に使った所で出ます。トレースバックには、名前を使った所と、元の import の行の両方が出ます。存在しないモジュールを lazy import した次のスクリプトで確かめました。

lazy import no_such_module_xyz
print("import line passed")
no_such_module_xyz.hello()

Python 3.15.0・macOS で動かした出力です。

import line passed
Traceback (most recent call last):
  File "/path/to/lazy_missing.py", line 1, in <module>
    lazy import no_such_module_xyz
ImportError: lazy import of 'no_such_module_xyz' raised an exception during resolution

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/path/to/lazy_missing.py", line 3, in <module>
    no_such_module_xyz.hello()
    ^^^^^^^^^^^^^^^^^^
ModuleNotFoundError: No module named 'no_such_module_xyz'

import の行を通ったあとで、エラーが出ています。lazy import を使うと、import の間違いが見つかるのが遅くなる点に気をつけてください。

使える場所の制限

lazy import が使えるのは、モジュールの一番上（モジュールスコープ）だけです。関数の中、クラスの中、try/except/finally の中で使うと SyntaxError になります。* の import（lazy from module import *）と __future__ の import も、lazy にできません。関数の中に書いた次のスクリプトは、3.15.0 で動かすと "SyntaxError: lazy import not allowed inside functions" になりました。

def f():
    lazy import json

ソースを変えずに全体を lazy にする、3.15 より前の版も支える

ソースを変えずに全体を lazy にするには、コマンドのオプション -X lazy_imports、または環境変数 PYTHON_LAZY_IMPORTS を使います。値は all（すべての import が lazy）と normal（既定。ソースに lazy を書いた所だけ）です（動かしては確かめていません）
3.15 より前の版も支えるコードでは、lazy と書く代わりに、モジュール名の文字列を __lazy_modules__ に並べます。次のスクリプトを 3.15.0 で動かすと、json は使うまで読み込まれませんでした

import sys
__lazy_modules__ = ["json"]
import json
print("json in sys.modules:", "json" in sys.modules)
json.dumps({})
print("json in sys.modules:", "json" in sys.modules)

json in sys.modules: False
json in sys.modules: True

lazy は「ソフトキーワード」なので、lazy = 1 のように変数名にも使えます。これは公式の文には書かれていなくて、3.15.0 で動かして確かめました。

frozendict・sentinel・内包表記のアンパック：新しい書き方

frozendict：変えられない辞書

3.15 で、変えられない（イミュータブルな）辞書の型 frozendict が組み込みに入りました。作ったあとは変更できません。dict の子クラスではなく、object を直接継承します。キーと値がすべてハッシュ可能（hash() で値を出せる）なら、frozendict もハッシュ可能です。入れた順は保ちますが、比べるときは順を見ません。

a = frozendict(x=1, y=2)
print(a)
b = frozendict(y=2, x=1)
print(hash(a) == hash(b))
print(a == b)
print(isinstance(a, dict))
try:
    a['z'] = 3
except TypeError as e:
    print("TypeError:", e)

Python 3.15.0・macOS で動かした出力です。順の違う a と b は、ハッシュも == も等しく、代入するとエラーになります。isinstance(a, dict) は False でした。

frozendict({'x': 1, 'y': 2})
True
True
False
TypeError: 'frozendict' object does not support item assignment

3.14.8 で同じスクリプトを動かすと、"NameError: name 'frozendict' is not defined. Did you mean: 'frozenset'?" になりました。3.14 には frozendict がありません。

標準ライブラリの copy・decimal・json・marshal・plistlib（書き出しだけ）・pickle・pprint・xml.etree.ElementTree が、frozendict を受け付けるようになりました。

注意が1つあります。isinstance(arg, dict) で辞書かを調べているコードは、frozendict を通しません。通したいときは、isinstance(arg, (dict, frozendict)) にするか、isinstance(arg, collections.abc.Mapping) にします。後者は、MappingProxyType のような、ほかのマッピング型も通します。

sentinel：「値が無い」を表す専用の目印

組み込みに sentinel 型が入りました。ほかと重ならない目印の値（センチネル）を、短い表示で作れます。コピーしても同じもののままで、型の式で縦棒（|）と組み合わせられ、モジュールと名前で import できる場所にあれば pickle できます。MISSING = sentinel("MISSING") のように作り、repr= で表示を変えられます。比べるときは is を使います。真偽値は真で、自分自身とだけ等しくなります。

次は、関数の引数の既定値に使う例です。「引数が渡されなかった」と「None が渡された」を分けられます。この使い方の例は、動かして確かめるために作ったもので、公式の文書の例ではありません。

MISSING = sentinel("MISSING")
print(MISSING)
def greet(name=MISSING):
    if name is MISSING:
        return "name was not given"
    return f"hello, {name}"
print(greet())
print(greet(None))

Python 3.15.0・macOS で動かした出力です。

MISSING
name was not given
hello, None

内包表記の中で `*` と `**` のアンパック

リスト・集合・辞書の内包表記とジェネレータ式で、* と ** のアンパック（中身を展開すること）が使えるようになりました。入れ子の内包表記や itertools.chain() の代わりに使えます。

lists = [[1, 2], [3, 4], [5]]
print([*L for L in lists])
dicts = [{'a': 1}, {'b': 2}, {'a': 3}]
print({**d for d in dicts})

Python 3.15.0・macOS で動かした出力です。[*L for L in lists] は [x for L in lists for x in L] と同じ結果です。{**d for d in dicts} は辞書を1つにまとめ、同じキーはあとの値になります。

[1, 2, 3, 4, 5]
{'a': 3, 'b': 2}

エラーメッセージ・色・標準ライブラリの変更

属性の打ち間違いに、ヒントが出る

組み込みの型で、近い名前が見つからない AttributeError のとき、3.15 は、ほかの言語（JavaScript・Java・Ruby・C#）でよく使うメソッド名の表を見て、Python での書き方を教えてくれます。たとえば、リストに .push を使うと、.append を勧めます。

python -c "[1, 2, 3].push(4)" を Python 3.15.0 で動かした出力です（macOS）。

Traceback (most recent call last):
  File "<string>", line 1, in <module>
    [1, 2, 3].push(4)
    ^^^^^^^^^^^^^^
AttributeError: 'list' object has no attribute 'push'. Did you mean '.append'?

同じコードを Python 3.14.8 で動かすと、ヒントはありません。

Traceback (most recent call last):
  File "<string>", line 1, in <module>
    [1, 2, 3].push(4)
    ^^^^^^^^^^^^^^
AttributeError: 'list' object has no attribute 'push'

ほかの例です。3.15.0 で動かして、公式の文面と同じ出力を確かめました。

書いたコード	3.15 のメッセージの後ろの部分
`'hello'.toUpperCase()`	Did you mean '.upper'?
`{}.put('a', 1)`	Use d[k] = v.
`(1, 2, 3).append(4)`	Did you mean to use a 'list' object?
中の属性に目的の名前がある（公式の例の `container.area`）	Did you mean '.inner.area' instead of '.area'?

辞書の .put のように、メソッドではなく文法で書くものは、その書き方を出します。タプルのように変えられない型に、変えるメソッドを呼ぶと、変えられる型（リスト）を勧めます。del で属性を消すときの打ち間違いにも、近い名前が出ます（この例は動かしては確かめていません）。

注意があります。手元（Python 3.15.0・macOS）では、このヒントは、エラーが画面に表示されるときに付きました。except AttributeError as e: で受けて、e を print や f-string で表示すると、"'list' object has no attribute 'push'" と出て、Did you mean の部分は出ませんでした。公式の文書でこの仕組みを説明した所は、確かめた資料には見つかりませんでした。

色が増えた

python --help などのヘルプが、カラーになりました。色は環境変数で制御できます。対話モード（REPL）では、Tab の補完候補が種類ごとに色分けされ、from ... import で Tab を押すと、モジュールの中の名前も出ます（色と対話モードは、動かしては確かめていません）。

tomllib・re・math.integer

tomllib: TOML（設定ファイルの書式）を読む標準のモジュールです。TOML 1.1.0 に対応しました。1.0.0 の文書は同じように読めます。インラインテーブルの中で、改行と末尾のカンマが書けることや、時刻の秒を省けることが加わっています。3.15.0 で、改行と末尾のカンマのあるインラインテーブルと t = 14:15 を tomllib.loads() で読めました。pyproject.toml というファイルの読み方は、pyproject.toml とは？の記事で説明します
re: re.match() と re.Pattern.match() は「ソフト非推奨」になり、新しい名前 re.prefixmatch() が入りました。意味をはっきりさせるための別名です。公式は、match() を消す予定は無いと書いています。古い版も支えるコードは match() のまま、新しいコードは prefixmatch() が勧められています
math.integer: 整数の引数のための数学の関数をまとめた新しいモジュールです（PEP 791）。3.15.0 で公開されている名前を調べると、comb・factorial・gcd・isqrt・lcm・perm の6つでした（これは手元の結果で、What's New に一覧はありません）

プロファイル用のパッケージと Tachyon

プロファイル（どこに時間がかかっているかを測ること）の道具が、profiling パッケージにまとまりました。profiling.tracing は、cProfile から移した、関数の呼び出しを全部記録する方式です。profiling.sampling は、新しいサンプリング方式で、名前は Tachyon です。cProfile は、互換のため別名として残ります。import cProfile, profiling.tracing は、3.15.0 で通りました。

Tachyon は、動いている Python のプロセスに、コードを変えず、再起動もせずに付けて測れます（PID を指定する attach など）。公式は「低負荷（low-overhead）」の分析と説明しています。公式の文書には「負荷がほとんどない（virtually zero overhead）」という言い方もありますが、この記事では「負荷の小さい」と書きます。Tachyon は動かしては確かめていません。

Python 3.15 は速くなった？JIT・Windows 版・GIL の話

先に、確かめられなかったことを書きます。「Python 3.15 全体で何％速くなった」という数は、この記事で確かめた公式の資料に見つかりませんでした。What's New にあるのは、JIT・Windows 版・base64 などの、部分ごとの数だけです。この記事では、速さを動かして測っていません。以下の数は、すべて公式の文書の数で、何と何を比べたかを添えています。

JIT コンパイラ：まだ実験的

JIT コンパイラは、Python のコードを、動かしながら機械語（CPU がそのまま動かせる形）に直す仕組みです。公式は、3.15 で実験的な（experimental）JIT コンパイラが大きく改良されたと書いていて、JIT は今も「実験的」です。

速さの数は、公式のベンチマーク（pyperformance）の結果として、What's New とリリースのページに書かれています。

x86-64 の Linux では、JIT は、最適化をすべて有効にした通常のインタープリタより、幾何平均で 7〜8％ 速い
AArch64 の macOS（Apple Silicon の Mac）では、JIT は、tail-calling インタープリタより 11〜12％ 速い
JIT ありのビルドと、なしのビルドの差は、x86-64 の Linux と AArch64 の macOS で、だいたい 15％遅くなる場合から、2倍以上速くなる場合まで幅がある（unpack_sequence という小さなベンチマークを除く）

幾何平均は、倍率の平均を出すときに使う平均の出し方です。この数は JIT についての数で、「Python が 7〜8％速くなった」という意味ではありません。JIT が、python.org のインストーラや uv で入れた Python で、既定で有効になっているかは、確かめた資料に書かれていませんでした。JIT のビルドに LLVM が必要になるのは CPython をビルドするときだけで、Python を使うだけの人は LLVM を入れなくてよい、と公式は書いています。

Windows 64 ビット版の tail-calling インタープリタ

python.org の Windows 64 ビット版は、新しい tail-calling インタープリタで作られています（MSVC 18 という Microsoft のコンパイラの新機能を使っています）。公式は、Windows x86-64・AMD Ryzen 7 5800X・Visual Studio 18.1.1 で、従来の switch-case のインタープリタより、pyperformance の幾何平均で 15〜20％速かったと書いています。この数は、この条件で測った結果です。Windows では動かして確かめていません。

base64

base64 の変換は、エンコードで 2倍、デコードで 3倍速くなったと、公式は書いています（CPU のパイプラインの最適化によるものです。測った条件は書かれていません）。

GIL はなくなった？ふつうの 3.15 には GIL がある

GIL（グローバルインタープリタロック）は、Python の中でスレッドが同時に動く場面を制限する仕組みです。free-threading は、この GIL を外した CPython のビルドで、3.13 から用意されています。スレッドを CPU のコアで並列に動かせますが、公式は、すべてのソフトが自動で速くなるわけではなく、スレッドを前提に作ったプログラムが、コアの多いハードウェアで速くなると書いています。

3.15 でも、ふつうの Python には GIL があります。 変わったのは配り方で、macOS の python.org のインストーラが、3.15 から、free-threading の版（python3.15t）も既定で一緒に入れるようになりました（インストールの種類の画面の Customize ボタンで外せます）。ふつうの 3.15.0 と、free-threading の 3.15.0 で、GIL が有効かを調べた結果です（uv で入れた Python・macOS）。

$ uv run --no-project --python 3.15 python -c "import sys; print(sys._is_gil_enabled())"
True
$ uv run --no-project --python 3.15t python -c "import sys; print(sys._is_gil_enabled())"
False

free-threading の版かどうかは、python -VV の表示に "free-threading build" と出るかでわかります。GIL が本当に外れているかは、sys._is_gil_enabled() で調べます。

$ uv run --no-project --python 3.15t python -VV
Python 3.15.0 free-threading build (main, Oct  9 2026, 15:11:36) [Clang 22.1.3 ]

free-threading の版には、注意が2つあります。公式の macOS の文書は、1本のスレッドで動かす処理では、通常の版より少し遅くなる（追加の負荷がある）と書いています。どれくらい遅いかの数は書かれていません。また、拡張モジュールを含む外部のパッケージが対応していないことがあり、そのときは GIL が再び有効になります。

uv では、版のうしろに t を付けると free-threading の版を指します。uv python install 3.15t で入り、コマンドは python3.15t です。uv python install 3.14 のように書けば、3.14 以降は GIL のある版が優先されます。Windows の Python install manager では、末尾に t の付いたタグで free-threading の版を入れます（Windows では動かして確かめていません）。

上げる前に見る所：消えたもの・非推奨・動きが変わったもの

ここにあるのは一部です。全部の一覧は、What's New の「Removed」「Deprecated」「Porting to Python 3.15」の節にあります。初心者の人にも関係がありそうなものに絞りました。

3.15 で消えたもの

消えたもの	代わり・補足
`http.server` の `CGIHTTPRequestHandler` と、`python -m http.server` の `--cgi`（3.13 で非推奨）	3.15.0 では `from http.server import CGIHTTPRequestHandler` が ImportError になった（手元）
`sre_compile`・`sre_constants`・`sre_parse` のモジュール	3.15.0 では import すると ModuleNotFoundError になった（手元）
文書に無かった `glob.glob0()`・`glob.glob1()`	`glob.glob()` に `root_dir` を渡す
`pathlib.PurePath.is_reserved()`	Windows の予約された名前を調べるなら `os.path.isreserved()`
`platform.java_ver()`（3.13 で非推奨）	―
`datetime` の `strptime()` で、書式に `%d`（日）があって年の指定が無いときの動き	ValueError になる（3.13 から非推奨）。動かしては確かめていません
import の仕組みの `load_module()`（3.4 から非推奨）と `zipimport.zipimporter.load_module()`	`exec_module()`
`NamedTuple("Point", x=int, y=int)` のようなキーワード引数での作り方（文書に無かったもの）。`TypedDict("TD")` で項目0個の型を作る書き方。`@typing.no_type_check_decorator`	クラスの形か、関数の形（`TypedDict("TD", {})` など）で書く
モジュールの `__cached__` 属性（3.13 から非推奨）は、設定も参照もされなくなった	`__spec__.cached`

今は動くが、いずれ消えるもの（非推奨）

非推奨のもの	消える予定	代わり
`profile` モジュール	3.17	互換の `profiling.tracing`
標準ライブラリのモジュールの `__version__`・`version`・`VERSION` 属性（argparse・csv・json・logging・re・pickle・platform など）	3.20	`sys.version_info`
コマンドのオプション `-b`・`-bb`（Python 2 から 3 への移行の助けだったもの）	3.17 から何もしなくなる	―
`hashlib` のコンストラクタに `string=` で初めのデータを渡すこと	3.19	位置引数で渡す
`http.cookies` の `js_output`	3.19	`output`

profile モジュールは、警告を表示する指定 -W default を付けて import すると、次の警告が出ました（Python 3.15.0・macOS）。

<string>:1: DeprecationWarning: The profile module is deprecated and will be removed in Python 3.17. Use profiling.tracing (or cProfile) for tracing profilers instead.

3.16 で消える予定のものも、What's New の中にあります（前から非推奨になっているものです）。一部を挙げます。

asyncio のポリシーの仕組み（asyncio.set_event_loop_policy() など）。代わりに asyncio.run()、または loop_factory を渡した asyncio.Runner を使う
asyncio.iscoroutinefunction()。代わりに inspect.iscoroutinefunction() を使う
真偽値のビット反転 ~True・~False（結果が -2 と -1 になって、わかりにくいため）。代わりに not x を使う
array の 'u' の書式コード。代わりに 'w' を使う

動きが変わって、コードの直しが要るかもしれないもの

「Porting to Python 3.15」の節は、コードの変更が要るかもしれない変更とバグ修正をまとめた節です。その一部です。

sqlite3.connect() は、最初の database 以外の引数がすべてキーワード専用になりました。timeout= のように、名前を付けて渡します
argparse で、add_argument('-f', '-foo') のように短いオプションと「ハイフン1つの長いオプション」を渡すと、dest（値の入る名前）は長いほうから決まるようになりました（'f' ではなく 'foo'）。前の動きにするなら、dest を書きます
base64.urlsafe_b64decode() は、入力の詰め物（パディング）が無くても通るようになりました。必須にするなら padded=True を渡します
unittest の assertWarns()・assertWarnsRegex() が、合わない警告を飲み込まなくなりました。前は隠れていた警告が、テストで出てくることがあります

上げる前の確認

encoding を書かずに open() している所がないか。前の節の EncodingWarning で探せます
消えたものを使っていないか。上の表のほか、What's New の「Removed」の節を見る
非推奨の警告（DeprecationWarning）が出ていないか見る
使っている外部のパッケージが 3.15 に対応しているか。この記事では調べていないので、各パッケージの案内で確かめる

Python 3.15 の入れ方（Mac・Windows・uv）

入れ方は、Mac は python.org のインストーラ、Windows は Python install manager、どの OS でも使えるのが uv、の3つを取り上げます。Windows の手順は公式の文書のとおりで、Windows では動かして確かめていません。

Mac：python.org のインストーラで入れる

python.org のダウンロードのページ（2026年10月10日時点）では、macOS 向けに "Python 3.15.0" をダウンロードできます。公式の macOS の文書によると、インストーラは .pkg の形式で、Apple Silicon と Intel のどちらの Mac でも動く universal2 です。macOS 10.15 以降向けです。インストールされた Python はその Mac の全ユーザーから使えるので、管理者の権限のあるユーザーで入れます。

入れ終わったら、/Applications/Python 3.15/ のウィンドウにある Install Certificates.command をダブルクリックして、インストールを完了させます。動かすコマンドは python3.15 か python3 です。この記事では、python.org のインストーラは使っていません。

Mac に最初から入っている /usr/bin/python3 は、Apple の開発ツール（Xcode など）のためのもので、たいてい古い版です。公式は、変えたり消したりしないよう書いています。手元の /usr/bin/python3 は 3.9.6 でした。

リリースのページには、macOS 27.0 についての注意もあります。macOS 27.0 の動きの変更が原因で、IDLE や tkinter を使うアプリが、ダイアログを開くメニューを選んだときに固まることがある、と書かれています。今の Python のすべての版に関わるとみられています。IDLE など Tk を使うアプリに頼っているなら、回避策が出るまで macOS 27.0 を入れるのを待つか、自分の使い方で問題が出ないかを確かめることを考えてもよい、と公式は書いています。

インストーラは、free-threading の版（python3.15t）も一緒に入れます。ふつうの python3.15 には GIL があります（前の「GIL はなくなった？」の節）。

Python のインストールのほかの方法（公式サイトから入れる方法と pyenv）は、FastAPI の実装手順の記事の「Python のインストール」の節にも書かれています。リンク先の記事の例は 3.12 系（pyenv install 3.12.3）です。

Windows：Python install manager で入れる

Windows は、公式の中で言い方が分かれています。どれも公式のページで、出どころは次のとおりです。

出どころ	書かれていること
Windows の文書（docs.python.org）	CPython の開発チームの Python は、Python Install Manager で入れる。python.org/downloads か Microsoft Store から入れられ、2つは同じもの。昔からのフルインストーラは、3.14 で非推奨になり、3.16 以降は作られない
python.org のダウンロードのページ（2026年10月10日時点）	Windows の欄は、"Download Python install manager" が先に出る。"Or get the standalone installer for Python 3.15.0" と、3.15.0 単体のインストーラも選べる
3.15.0 のリリースのページ	上のボタンは "Download Python install manager"。ページ下の Files の表には、"Windows installer (64-bit)" の行があり、"Recommended" と書かれている

この記事は、Windows の文書の書き方に合わせて、Python install manager を主に説明します。3.15 には従来のインストーラもまだありますが、3.16 からは作られない、と文書は書いています。

Python 3.15 が対応する Windows は、Windows 10 以降です（Microsoft の延長サポートの間だけ対応する決まりで、PEP 11 に書かれています）。

Python install manager の使い方は、公式の文書では次のとおりです。

python.org/downloads か、Microsoft Store から Python install manager を入れます
入れると、python・py・pymanager のコマンドが使えるようになります。初めて Python 本体を入れるとき、PATH（コマンドを探す場所の一覧）に足すかを聞かれることがあります。既定の場所は %LocalAppData%\Python\bin です
版を指定して入れるのは py install です。3.15 なら py install 3.15 と書きます。入っている版の一覧は py list で見ます。版を選んで動かすには、py -V:<TAG> の形を使います（文書の例は py -V:3.14 ... で、3.15 なら py -V:3.15 です）

py install 3.15
py list
py -V:3.15

公式は、プロジェクトごとに仮想環境を作ることを勧めています。作るのは python -m venv <env path>、使うときは <env>\Scripts\Activate です。Python install manager は、新しい版に自動で更新されます。消しても、入れた Python 本体は消えません。

uv で入れる：古い uv だと RC が入ることがある

uv は、Python 本体も入れられる道具です。uv の入れ方やプロジェクトの作り方は、Python の uv とは？で説明しています。版を指定して入れるのは uv python install 3.12 の形で、3.15 なら uv python install 3.15 です。uv の文書は、入れた Python は PATH に足されると書いていて、例は python3.15 です。uv が入れるのは版つきのコマンド（python3.15）だけで、python と python3 も入れるには、実験的な --default を付けます。

気をつけたいのは、入れられる Python の版が、uv の版ごとに決まっていることです。 uv の文書は、"The available Python versions are frozen for each uv release. To install new Python versions, you may need upgrade uv." と書いています。新しい Python を入れるには、uv を上げる必要があることがある、という意味です。

手元で uv python install 3.15 を動かすと、入る 3.15 は uv の版で違いました。uv の最新版は 0.13.0 で、PyPI に載ったのは2026年10月9日 19:45（UTC。日本時間では10月10日 4:45）です。その前の版が 0.12.24（2026年10月8日）です。

uv の版	手元の結果（macOS）
0.12.10	入れられる 3.15 の一覧に出るのは 3.15.0rc2（入れては確かめていません）
0.12.24	`uv python install 3.15` で、3.15.0rc3 が入った
0.13.0	`uv python install 3.15` で、3.15.0 が入った

0.12.11 から 0.12.23 は試していないので、「0.13.0 より前は必ず RC が入る」とは言えません。次の順で入れて、確かめるのが安全です。

uv --version で、uv の版を見ます
古ければ、uv を上げます。公式のインストーラで入れた uv は、uv self update で上げられます（動かしては確かめていません）。ほかの入れ方で入れたときの上げ方を含め、Python の uv とは？の「アップデートとアンインストール」の節に書いています
uv python install 3.15 で入れます
表示が 3.15.0 になっているかを確かめます

0.12.24 で uv python install 3.15 を動かした出力です（macOS）。

Downloading cpython-3.15.0rc3-macos-aarch64-none (download) (26.3MiB)
 Downloaded cpython-3.15.0rc3-macos-aarch64-none (download)
Extracting cpython-3.15.0rc3-macos-aarch64-none (extract) (26.3MiB)
 Extracted cpython-3.15.0rc3-macos-aarch64-none (extract)
Installed Python 3.15.0rc3 in 1.25s
 + cpython-3.15.0rc3-macos-aarch64-none (python3.15)
warning: `/path/to/.bin24` is not on your PATH. To use installed Python executables, run `export PATH="/path/to/.bin24:$PATH"` or `uv python update-shell`.

0.13.0 で動かした出力です。秒数やサイズは、そのときの値です。

Downloading cpython-3.15.0-macos-aarch64-none (download) (26.4MiB)
 Downloaded cpython-3.15.0-macos-aarch64-none (download)
Extracting cpython-3.15.0-macos-aarch64-none (extract) (26.4MiB)
 Extracted cpython-3.15.0-macos-aarch64-none (extract)
Installed Python 3.15.0 in 1.17s
 + cpython-3.15.0-macos-aarch64-none (python3.15)
warning: `/path/to/.bin` is not on your PATH. To use installed Python executables, run `export PATH="/path/to/.bin:$PATH"` or `uv python update-shell`.

どちらの出力にも PATH の警告が出ています。手元では、uv の置き場を作業用のフォルダに向けて動かしたためです。ふつうに入れた uv で警告が出るかは、PATH の設定しだいです。同じ警告の説明は、Python の uv とは？の「つまずきやすい所」にもあります。

入った版は、python -VV で確かめます。手元で、uv で 3.15 を指定して動かした出力です。

$ uv run --no-project --python 3.15 python -VV
Python 3.15.0 (main, Oct  9 2026, 15:11:47) [Clang 22.1.3 ]

PATH が通っていれば、python3.15 -VV でも確かめられます。表示が 3.15.0 になっていれば、正式版です。

RC（3.15.0rc3）が入っている所で、uv 0.13.0 の uv python install 3.15 を動かすと、3.15.0 が別に入りました。rc3 は消えずに残ります。RC を消す手順は、確かめていません。

uv が入れる Python について、uv の文書は次のように書いています（uv の文書の言い方のままです）。"Python does not publish official distributable binaries. As such, uv uses distributions from the Astral python-build-standalone project." 一方、python.org は、Windows と macOS のインストーラを配っています（この記事の上の節）。

Python の uv とは？の記事は、uv 0.12 系（例の Python は 3.14.7）で書いたものです。uv は、互換を壊す変更のときにマイナー版（0.12 から 0.13 のように真ん中の数字）を上げる決まりなので、0.13 で変わった所があるかもしれません。何が変わったかは、この記事では確かめていません。

よくある質問

Python 3.15 はいつ出た？

正式版の 3.15.0 は、2026年10月9日に出ました（python.org の記録では 13:54:59 UTC。日本時間では22:54）。このあとの修正版（3.15.1 など）は、2か月ごとに出ます。バグ修正は約2年、セキュリティ修正は2031年10月ごろまで続く予定です。

Python 3.15 をインストールするには？

Mac は python.org の .pkg のインストーラ、Windows は Python install manager（py install 3.15）、どの OS でも uv（uv python install 3.15）で入れられます。uv が古いと RC（3.15.0rc3 など）が入ることがあるので、uv を上げてから入れて、python3.15 -VV で 3.15.0 かを確かめます。Windows の手順は、公式の文書のとおりで、動かしては確かめていません。

JIT で Python は速くなる？

公式の数は、条件つきです。JIT は、x86-64 の Linux で、公式のベンチマークの幾何平均で、通常のインタープリタより 7〜8％速いと書かれています。ただし JIT は今も実験的で、3.15 全体で「何％速くなった」という数は、確かめた資料に見つかりませんでした。

Python 3.15 で GIL はなくなった？

なくなっていません。ふつうの 3.15.0 には GIL があります。変わったのは、macOS の python.org のインストーラが、GIL なしで動く free-threading の版（python3.15t）も既定で一緒に入れるようになったことです。

UTF-8 が既定になると、何が変わる？Windows は？

encoding を書かずに open() したファイルを、UTF-8 で読み書きするようになります。変わるのは encoding を書かなかったときだけで、影響が出るのは、そのファイルが UTF-8 でないときです。PEP 686 は、影響が出るのはおもに Windows の利用者だと書いています。encoding をいつも書くのが、公式の勧めです。

まとめ

Python 3.15.0 は、2026年10月9日に出ました（日本時間では22:54）。バグ修正は約2年、セキュリティ修正は2031年10月ごろまで続く予定です。3.10 は2026年10月1日にサポートが終わりました
既定の文字コードは、システムの環境に関係なく UTF-8 になりました。影響が出るのは、encoding を書かずに開いたファイルが UTF-8 でないときで、PEP 686 は、おもに Windows の利用者に関わると書いています。encoding をいつも書くのが公式の勧めで、探すには EncodingWarning を使います
新しい書き方として、lazy import、frozendict、sentinel、内包表記の中のアンパックが入りました。AttributeError には、近い書き方のヒントが付きます（手元では、画面に表示されるときだけ付きました）
速さの数は、条件ごとです。JIT の 7〜8％は、x86-64 の Linux で、公式のベンチマークの幾何平均の数で、JIT は今も実験的です。ふつうの 3.15 には GIL があります
入れ方は、Mac が python.org のインストーラ、Windows が Python install manager、どの OS でも uv です。uv が古いと RC が入ることがあるので、uv を上げてから入れて、python3.15 -VV で 3.15.0 かを確かめます
上げる前に、encoding を書いていない open()、消えたもの、非推奨の警告を見ます。外部のパッケージが 3.15 に対応しているかは、この記事では調べていません
3.15.1 以降の修正版が出ると、版の行が変わります。公式の文書も書き換わるので、使う前に、公式の最新の情報も確かめてください