Pyrefly はPythonの型検査とIDE解析を同じ言語サーバーで支える
Python 用の高速型チェッカーおよび言語サーバー。現実世界の Python を理解します。 Pydantic、Django、pytest などのフレームワークとツールのサポートが組み込まれており、モデル検証、フィールド タイプ、フィクスチャ ナビゲーション、オートコンプリートがすぐに機能します。
ひと目でわかる
- これは何？
- CLIとエディタ拡張を共通の解析基盤で扱い、MypyやPyrightから段階移行できる Meta 発の型チェッカーを確認する。
- 誰に向いている？
- Pythonコードベースで型検査とエディタの補完を一つの解析結果にそろえたいチームに向きます。Pyrefly は1.xでも新しい型エラーや互換性変更があり得るため、速度の公称値だけで全社導入を決めるべきではありません。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
CLIとLanguage Serverを同じ目的で使う
Pyrefly は Python の fast type checker and language server です。CLIで型検査を実行でき、IDEではコードナビゲーション、semantic highlighting、completion、hover、inlay hints などを提供します。VSCode、Neovim、Zedなどのエディタ拡張が案内され、解析結果を編集画面とコマンドラインで扱える構成です。README は開発状態を stable とし、release 1.0.0 を示していますが、stable は型エラーが増えないという意味ではありません。
速度の数値には測定条件がある
プロジェクトは1秒あたり185万行超を検査し、PyTorchをMypyとPyrightより15倍速く型検査すると説明しています。保存後のIDE再検査は通常10ミリ秒未満ともしています。いずれも README にあるプロジェクト側の主張で、リポジトリ規模、キャッシュ状態、ハードウェア、設定が異なる実行へそのまま適用できません。自社では初回解析と変更後解析を分け、同じコミットで時間と診断数を記録する必要があります。
現実のPythonフレームワークを対象にする
Pydantic、Django、pytest に組み込み対応し、モデル検証、フィールド型、fixture navigation、補完を out of the box で扱うとREADMEは説明しています。これはフレームワークの全機能を保証する表ではありません。特に動的な設定やプラグインを多用するコードでは、実際の型スタブと設定を置いたサンプルを作り、誤検出と見逃しを分類します。
移行用コマンドで段階を切る
既存の Mypy または Pyright から移る入口として pyrefly init、既存エラーを抑える pyrefly suppress、型注釈を生成する pyrefly infer が用意されています。一度に全リポジトリをクリーンにする設計ではなく、README は一ファイルから範囲を広げる方針を示しています。suppress の導入時には、抑制箇所を負債として一覧化し、検査を無効にした結果を成功と扱わない CI ルールを決めます。
版更新は毎月の差分を受け入れる
Pyrefly は1.x.0の minor release を毎月、critical fix向けの patchを必要に応じて出します。厳密な semantic versioning には従わず、どの版でも新しい型エラーや breaking change を導入し得ると説明しています。更新前後で lockfile、pyrefly の出力、IDE診断を保存し、必要なら suppress の差分をレビューします。素材時点の release は1.3.0-dev.3などで、安定版名だけを前提にしない確認が要ります。
拡張機能と採用判断を別に検証する
導入は pip install pyrefly、ブラウザで試せる Sandbox、IDE installation page の三つの入口です。PyTorchやJAX、大規模なMeta内のInstagramコードベースで採用されたという説明は、互換性を検討する材料ですが、自社の依存関係を代替する証明ではありません。MITライセンス、GitHub issue、CONTRIBUTING.md、ARCHITECTURE.md、Discordの隔週 office hours を確認し、CLIとエディタ拡張の配布経路を分けて管理します。導入テストでは専用仮想環境で pip install pyrefly を行い、pyrefly initが生成する設定と既存のMypy・Pyright設定を保存します。Pydanticのモデル、Djangoのview、pytestのfixtureを含む小さなプロジェクトで、CLIの診断とVSCodeの表示が同じファイル・同じ行を指すかを見ます。pyrefly inferで注釈を生成する場合は差分を自動採用せず、型が不明な箇所と実行時の型をレビューします。pyrefly suppressはエラーを消すだけなので、抑制理由と解除条件をコードレビューに残します。初回検査、1ファイル変更後、CIの並列実行を分けて測定し、READMEの185万行毎秒や15倍という自報値と比較します。1.3.0-dev.3のような開発版から更新する場合はlockfile、診断数、IDE拡張の版を固定し、MITライセンスと依存ライブラリの条件も確認します。Pyreflyの導入評価では、型エラーを減らすことと解析を速くすることを別の指標にします。まず小さなPythonパッケージでMypy、Pyright、Pyreflyの診断位置と終了コードを比較し、Pydantic、Django、pytestを含む実コードへ段階的に広げます。CLIの結果とVSCode、Neovim、ZedのLanguage Server表示が一致するかを、同じ保存操作で確認します。pyrefly initの設定をレビューし、pyrefly inferが作った注釈は実行時の値と照合してから採用します。pyrefly suppressで既存エラーを消す場合は、ファイル、行、理由、解除予定を残し、診断数が減っただけの状態を品質向上と扱いません。185万行毎秒、MypyやPyrightより15倍、保存後10ミリ秒未満という数値は、READMEの測定主張として自社コードで再測定します。月次の1.x.0更新とpatch更新を分けず、1.3.0-dev.3からの差分をCIで比較します。MITライセンス、依存パッケージ、拡張機能の更新を同じrelease記録に置き、型エラーの増加を見逃さない移行手順にします。実施記録には対象版と入力条件を残し、成功した結果だけでなく失敗した場合の出力も保存します。設定を変更した前後で同じ確認を繰り返せるようにし、READMEに書かれた機能と自分の環境で確認できた事実を分けます。採用判断では、導入できたかだけでなく、更新、障害、切り戻し、権限、ライセンスを同じ担当者が追跡できるかを確かめます。この確認では版、設定、入力、出力、エラーを同じ記録に残します。再実行して結果が変わった場合は、対象データと依存部品の差分を先に調べます。運用へ移す前に、失敗時に元へ戻せる手順と担当者を決めます。
編集部の結論
Pythonコードベースで型検査とエディタの補完を一つの解析結果にそろえたいチームに向きます。Pyrefly は1.xでも新しい型エラーや互換性変更があり得るため、速度の公称値だけで全社導入を決めるべきではありません。まず pip install pyrefly、pyrefly init、pyrefly suppress を隔離ブランチで実行し、既存エラーの件数、CIの終了コード、VSCodeやNeovimの診断表示を版ごとに比較してください。
コミュニティノート