CPython の実験的 JIT は、3.15 時点で pyperformance の geometric mean をおよそ 4〜12% 改善した。数字だけ見れば、実験は十分に前進しているように見える。しかも PEP 836 の付録では macOS（M3 Pro）で 12.6%、x86-64 Linux でも本文では 7〜8%（付録の集計期間では 6.9%）改善と、公式の説明はかなり手応えがある。ところが、その JIT は「速くなったから残る」流れには乗らなかった。
画像: peps.python.org より
ここで見落としやすいのは、CPython では速度向上そのものが最終判断ではないことだ。Python は本体だけで完結する言語ではなく、拡張モジュール、デバッガ、プロファイラ、配布物、そして運用の癖まで含めて一つの実行基盤として扱われる。JIT が速いかどうかと、CPython の main ブランチに置き続けてよいかどうかは、別の問いとして審査される。
2026 年 6 月、Steering Council は JIT の新規開発を止め、支持可能な Standards Track PEP が通らなければ main から削除すると告げた。理由は単純な「性能不足」ではない。むしろ、速度が出始めたからこそ、保守責任や互換性の説明責任が重くなった。速くなる途中の機能を、どこまで「実験」として許すかが争点になった。
この JIT はそもそも、2024 年に 3.13 の main へ入った時点で、完成品として扱われていたわけではない。PEP 744 は Informational で、実験としての位置づけを明示していた。つまり、動くことは示したが、長期保守の約束まではしていない。その段階では許された曖昧さが、3.15 で速度が見え始めた瞬間に、逆に問題として浮かび上がった。
実験のまま main に置くと、何が面倒になるのか
Steering Council が気にしたのは、JIT の有無で CPython の振る舞いが揺れ始めることだった。インタープリタの内部を変えると、同じ Python コードでも、デバッグやプロファイリングの見え方が変わる。ユーザーから見れば「速い版」と「遅い版」ではなく、「昨日と今日で少し違う CPython」が現れる。これは実験段階ならまだしも、main に置き続けるには重い。
PEP 836 が求められた背景には、そこを言葉にしてほしいという要求があった。長期保守、互換性、性能目標、プラットフォーム対応、メモリ負荷、安全性、redistributor への影響。どれも個別には耳慣れた論点だが、JIT では全部が同時に効く。たとえば、公式バイナリは JIT をビルドしたまま無効にして配る。配布側は、いつ有効化するか、どの環境で保証するかを抱え込むことになる。
面白いのは、PEP 836 が「最初の 1 年は開発者体験を改善する」と書きつつ、トレース記録型から method-based frontend への移行を打ち出していた点だ。ここは単なる内部実装の話に見えて、実は運用の話でもある。実験の継続は、コードが速いかではなく、開発者が理解しやすいか、追試しやすいか、壊れたときに責任範囲を切り分けられるかに直結する。
さらに、Steering Council は「これは supported feature にする条件を議論しているのではない」と切り分けた。評価していたのは、JIT を正式採用するかではなく、そもそも main で実験を続けてよいかだった。この一段手前の問いが厄介で、性能が少し上がっただけでは答えられない。実験が本体に居座ると、他の変更の足を引っ張るかもしれないからだ。
5% と 20% のあいだにある、見えにくい壁
PEP 744 は、JIT が non-experimental になる条件として、少なくとも 1 つの人気プラットフォームで意味のある改善、たとえばおおむね 5% の向上を挙げていた。そこから PEP 836 では、JIT + free-threaded build で pyperformance の geometric mean を 20% 改善することを、3.17 の first beta までの目標に据えた。数字だけを見ると、かなり野心が跳ね上がっている。
ただし、この 20% は単なる「もっと頑張る」ではなく、保留を解くための最低ラインとして置かれている。さらにややこしいのは、比較対象が「非 JIT の free-threaded build の interpreter」であることだ。つまり、単純に JIT の有無だけでなく、free-threading という別の大改造とセットで成果を示せ、という話になる。ここで性能の議論は、一気に多変数化する。
この構図は、日本の現場でも身近だ。たとえば、社内サービスで Python を使っているとき、速度向上が欲しいのは当然だが、現実には障害調査の再現性や、監視ツールとの相性のほうが先に問題になることが多い。JIT が速くても、プロファイラが見えにくくなったり、配布物の検証手順が増えたりすると、導入判断は簡単には動かない。
PEP 836 の議論でも、こうした懸念ははっきり出ていた。メモリ消費の説明が足りない、32-bit Windows をどこまで面倒を見るのか、従来の挙動を保てない外部ツールにどんな対処手順を示すのか、などだ。速度の数字は見えるが、保守コストの数字は見えにくい。だからこそ、「何%速いか」だけを追うと、意思決定に必要な情報が欠ける。
そして PEP 836 には、最初の compatibility review を 3.17 の first release candidate 期に置き、上位 PyPI パッケージのテストを回す計画もあった。Steering Council はそこを「遅すぎる」と見た。もし互換性の崩れが本当に問題なら、2028 年近くまで待つのではなく、もっと早く、継続的に見るべきだという理屈だ。ここで問われているのは、速度の伸びしろではなく、いつ不具合のコストを払い始めるのかである。
先に進むほど、技術の外側が支配的になる
JIT の話は、最終的には「どの方式が一番速いか」だけでは終わらない。PEP 836 では、method-based frontend、free-threading 対応、外部ツールの修復経路、redistributor の再現可能なビルド、セキュリティレビューといった項目が並んでいた。つまり、性能の改善を入口にしながら、運用・保守・配布の制度設計へ話が移っていく。
LWN が伝えたように、JIT の作者たちは当初の PEP 744 から続く未解決事項に対し、supported な機能へ進むための道筋をまとめようとした。しかし Steering Council が求めたのは、単なる道筋ではなく、どこまでを保証し、どこから先は保証しないかの線引きだった。そこが曖昧なままだと、実験は「便利な実験」で終わるのではなく、「本体に置かれた未契約の責任」になる。
PEP 836 は withdrawn になったが、それで JIT の価値が消えたわけではない。むしろ、4〜12% の改善が出たからこそ、次に必要なのは速度の上積みではなく、継続開発を支える合意だと見えた。ここから先は、実装の巧拙よりも、どの条件が満たされたら main に残せるのかを詰める段階になる。その条件の中身は、まだ全部は語られていない。たとえば、20% という数字の内訳をどう読むのか、あるいは free-threaded 化と JIT をどう重ねるのか——その答えは、もう少し奥にある。
👉 続き（核心はここから）は PaPoo で読めます: https://papoo.work/doc/0ef0d05cff7cdf6c