筆者の判断を先に置く。エディタに常駐して入力の裏で走り続ける型チェッカは、Python の書き味を一段引き上げる価値がある。保存のたびに数秒待つ mypy の運用に慣れた身からすると、Meta が Rust で書いた Pyrefly が 1.0 に到達し「毎キーストロークで走らせられる速度」を掲げた意味は小さくない。Python 3.15 のリリース候補が8月に迫るこのタイミングで、筆者は自作アプリのコードベースに Pyrefly を足し、mypy との違いを実務目線で確かめた。乗り換えるべきか、併用に留めるかの判断材料を整理する。
目次
Python 3.15 RC は8月4日、正式版は10月1日
PEP 790 によると、Python 3.15 の最初のリリース候補（rc1）は2026年8月4日、rc2 が9月1日、正式版が10月1日に予定されている。機能凍結はすでに5月7日の Beta 1 で済んでおり、いまは仕上げの段階だ。
rc は「これで出す」という意思表示に近い。ここから正式版までに入るのは基本的に不具合修正で、新機能は原則追加されない。読者が自分のプロジェクトで3.15 対応を試すなら、依存ライブラリの追随状況を見ながら rc で早めに走らせておくと、正式版の当日にあわてずに済む。
Pyrefly 1.0 とは何か
Pyrefly は Meta が開発し Rust で書かれた Python 型チェッカで、2026年5月に安定版の 1.0 へ到達した。もとは Instagram の型付き Python コードベース向けに2017年から育ってきたツールで、現在は 公式リポジトリで公開されている。
公式が掲げる数字は具体的だ。1秒あたり185万行を超える速度で型チェックし、PyTorch のようなプロジェクトでは mypy や pyright の15倍速いという。エディタ上では、ファイル保存後の再チェックが10ミリ秒未満で返るとされる。Instagram の2,000万行規模の Python コードベースで、既定の型チェッカとして使われている実績がある。
看板の「毎キーストローク」は、入力が止まるたびに全体を検査し直しても待ちが発生しない、という主張だ。
なぜ「常時オン」が効くのか
型チェックは、遅いと「コミット前にたまに走らせるもの」になり、速いと「入力中ずっと走らせるもの」になる。この差は、型エラーに気づくタイミングを丸ごと前に倒す。筆者の経験では、間違った引数の型を書いた瞬間に赤線が出る環境と、テスト実行まで気づかない環境とで、1日の手戻りの量がはっきり違ってくる。
例えば dict の値をうっかり Optional のまま関数へ渡してしまうミスは、実行時に None 参照で落ちて初めて発覚しやすい。入力の裏で型チェッカが走っていれば、その行を書き終えた数秒後に指摘が出る。返り値の型が想定と食い違ったときも、呼び出し側まで赤線がつながって見えるので、どこで前提が崩れたかを追いやすい。デバッグに溶けていた時間を、コードを書く時間へ振り替えられる。これが常時オンの実利だ。
Pyrefly と mypy を並べて見る
両者の性格を表で整理する。
| 観点 | Pyrefly | mypy |
|---|---|---|
| 実装言語 | Rust | Python |
| 速度 | 毎秒185万行超。大規模で桁違いに速い（公式値） | 実用十分だが大規模ではフルチェックに時間がかかる |
| エディタ統合 | VS Code / PyCharm / Neovim / Zed 等に LSP で常駐 | dmypy（デーモン）で高速化。常時オンは設計の主眼外 |
| 成熟度・実績 | 2026年に1.0。Instagram の2,000万行で運用 | 長年の実運用と豊富な型スタブ資産 |
| 設定・移行 | pyrefly init で mypy / pyright 設定から移行 |
周辺ツールの前提として定着していることが多い |
| 向いている人 | 新規・大規模、エディタ常駐の即時性が欲しい人 | 既存資産があり枯れた挙動を優先したい人 |
mypy の強みは枯れていることだ。長く使われてきたぶん、型スタブや周辺プラグインが揃い、挙動の癖も知られている。Pyrefly の強みは速度と即時性にあり、大きなコードベースほど効いてくる。
導入して並行させる
導入はパッケージを入れて初期化するだけだ。既存の mypy を消す必要はない。同じコードに両方を走らせ、差分を見る形が安全だ。
# uv を使っているプロジェクト
uv add --dev pyrefly
uv run pyrefly init # 既存 mypy / pyright 設定から移行
uv run pyrefly check
# pip の場合
pip install pyrefly
pyrefly init
pyrefly check設定は pyproject.toml に [tool.pyrefly] テーブルで書ける。検査対象と Python バージョンを固定しておくと、チームで挙動が揃う。
[tool.pyrefly]
project-includes = ["src"]
project-excludes = ["**/tests/fixtures"]
python-version = "3.13"
[tool.pyrefly.errors]
bad-assignment = true設定キーはバージョンで変わりうるので、最新の使い方は公式ドキュメントで確認してほしい。並行運用のあいだは、次の3点を突き合わせると判断が固まる。速度の体感差、mypy だけ／Pyrefly だけが拾う検出差分、既存の型スタブや設定がそのまま活きるか、の3つだ。
筆者の使い分け
新しく起こすプロジェクトや行数の多いコードベースでは、Pyrefly の速度がそのまま開発テンポに乗る。エディタ常駐で赤線が即座に返る環境は、書きながら設計を直す作業と相性がいい。バイブコーディングの進め方で触れた、AI に書かせたコードを人が型で締める流れとも噛み合う。
既存の mypy 資産が積み上がっているプロジェクトなら、当面は併用が現実的だ。CI では従来どおり mypy を通しつつ、手元のエディタには Pyrefly を常駐させる。日々の気づきは Pyrefly が速く返し、最終的な合否は慣れた mypy で担保する形にすると、移行リスクを抱えずに速さの恩恵だけ先取りできる。
単独プロジェクトなら思い切って Pyrefly に寄せてみる価値はある。小さいコードベースは移行コストも小さく、合わなければ戻せばいい。
3.15 RC の棚卸しも同じ機会に
型チェッカの乗り換え検証と、3.15 への対応調査は、どちらも足回りの点検という同じ作業だ。rc の期間に依存ライブラリのビルド可否を試し、型チェッカを差し替えた状態で通るところまで一度に見ておくと、正式版が出たあとの移行がなめらかになる。本番採用そのものは、主要ライブラリが3.15 に追随したのを確認してからで遅くない。rc1 の8月4日から正式版の10月1日まで2か月ある。この期間を、型チェッカの選定と3.15 の下調べをまとめて進める助走に使うのが、いちばん段取りがいい。
並行運用でつまずきやすい点
実際に両方を走らせると、検出結果は完全には一致しない。型推論のエンジンが別物だから、片方だけが警告を出す箇所が必ず出てくる。よく当たるのは、mypy 用のプラグイン（django-stubs のようにフレームワーク固有の型情報を注入する仕組み）に依存した検査だ。この種のプラグインは mypy を前提に作られており、Pyrefly 側で同じ精度が出るかはプロジェクトごとに確かめる必要がある。筆者も全フレームワークで裏を取ったわけではないので、この相性は自分のスタックで一度走らせて見るのが確実だ（未検証の領域は正直に潰していくしかない）。
Pyrefly のほうが厳しく推論して、新しい警告を出すこともある。既存コードに大量の指摘が一気に出たら、[tool.pyrefly.errors] で特定のエラー種別を段階的に有効化し、直せる範囲から潰していくと現実的だ。全部いっぺんに緑へ持っていこうとして手が止まるより、優先度の高い型だけ先に締めるほうが前に進む。
FAQ
Q. mypy を捨てる必要はある？
いらない。CI は mypy のまま、エディタだけ Pyrefly という併用で速さの恩恵は取れる。両者は同じ pyproject.toml に同居できる。
Q. pyright との関係は？
pyright も高速寄りの型チェッカで、Pyrefly は pyrefly init による pyright 設定からの移行に対応する。エディタ体験の優劣は、自分の言語サーバ環境で並べて試すのが早い。
Q. Python 3.15 で Pyrefly は動く？
公式は幅広い Python バージョンを対象にしているが、3.15 rc 段階での完全な対応は未検証だ。python-version を明示したうえで、rc のうちに一度走らせて確かめておきたい。
まとめ
Pyrefly 1.0 が示すのは、型チェックが「たまに走らせる重い処理」から「入力の裏で常時走る相棒」へ移りつつある流れだ。まず並行運用で速度と検出差分を測り、自分の開発テンポが変わるかを確かめよう。新規・大規模なら Pyrefly の速さがそのまま効き、既存 mypy 資産があるなら併用から入ればいい。Python 3.15 rc の対応調査も同じ機会にまとめて片づけると無駄がない。
