2026年10月27日、マイクロソフトは「Type Server Protocol」（TSP）を正式に発表した。今回のアーキテクチャ刷新により、10年にわたりPython開発を支えてきたPyrightがPylance内部から切り離され、交換可能なコンポーネントとなった。さらに、Metaが開発するオープンソース型チェッカー「Pyrefly」が初の外部バックエンドとして全面統合された。
この変更により、Language Server Protocol（LSP）の上位に型セマンティクスを専門に扱うプロトコル層が新設された。コード補完、定義ジャンプ、インラインヒントといった従来のエディタ機能が下流の消費側に回ることで、型システムは独立したセマンティック問い合わせサービスへと昇格。その主な対象は自動解析ツールやAIコードエージェントへと拡大している。
10年のコアを疎結合化：PylanceがPyrightの単一縛りから解放
従来のアーキテクチャでは、PylanceとPyrightは密結合していた。Pyrightが構文木を走査して型推論を計算し、PylanceがVS Code上の補完、定義ジャンプ、環境管理などを担う構成だった。この設計は導入の手軽さと安定性をもたらしたが、基盤となる型解析エンジンの自由な置換を妨げていた。
TSPはこのモノリシックな構成を打破する。PylanceはPythonインテリジェンス層やGitHub Copilotとの連携を引き続き担うが、診断と型計算は独立したサービスとして抽象化された。Pyrightは標準の選択肢に留まり、TSP仕様に準拠するエンジンであれば自由に差し替えが可能になる。
この分離により、開発者は既存の充実した開発環境を捨てることなくチェッカーを刷新できる。独立したサードパーティプラグインを直接使うと、仮想環境管理やCopilotとの密な連携が失われがちだったが、PylanceがTSPを介して仲介することで、使い慣れた操作感を保ったまま高速な計算エンジンを取り込める。
秒間180万行を誇るMetaのPyrefly：大規模モノレポのボトルネックを解消
TSPの最初のパートナーとして名乗りを上げたのがMetaであり、同社の「Pyrefly」がTSP仕様に完全準拠して登場した。ベンチマークにおいて、Pyreflyは秒間180万行という圧倒的な型検査スループットを記録。数百万行規模のモノレポにおいても、型検査の所要時間は分単位から秒単位へと短縮され、全量チェックに伴うエディタの引っ掛かりを一掃した。
この性能は、InstagramをはじめとするMetaの大規模Pythonシステムを長年運用してきた工学的知見に基づいている。2017年以来、同社は動的言語の大規模な静的型付けに注力してきた。Pyreflyは単なる概念実証ではなく、過酷な実運用の検証を経て投入されたプロダクトだ。
実務での実用性を高めるため、Metaは科学計算の主要ライブラリに対する型アノテーションを徹底した。NumPyの型網羅率は約90%に達し、pandasの公開APIも全面カバーされている。動的なサードパーティ製ライブラリに対しても高精度な静的推論が可能になり、明示的な型注釈がないコードブロックでも確固たる型判定が得られる。
スナップショットと並列リード：自動化ツールの道を拓くTSPプロトコル
プロトコル設計の観点から見ると、TSPはLSPを基盤とし、同一のJSON-RPC通信メカニズムを採用している。型サーバーはバックグラウンドでワークスペースの状態を保持し、バージョンネゴシエーション、検索パス、モジュールのインポート解決を一括処理する。仕様書およびTypeScriptのインターフェース定義は、microsoft/pylance-releaseリポジトリのdocs/tspディレクトリで公開されている。
バージョン0.4.1の仕様では、「スナップショットに紐づく型計算結果」と「複数接続可能な読み取り専用チャネル」という2つの重要設計が導入された。エディタの画面描画は単一方向の診断結果で十分だが、自動解析ツールはコードの状態を並行して読み出す必要がある。マルチチャネル機構により、外部プロセスはUI編集を一切ブロックすることなく型データへ並行アクセスできる。
プロトコルは主に3種類のクエリを提供する。計算された型（computed）、宣言された型（declared）、期待される型（expected）である。これらのAPIは抽象構文木（AST）を構造化データとして平坦化し、外部ツールは軽量なRPC呼び出しだけで変数の制約を把握できる。コード文脈が決定論的なフィールドに分解されるため、AIエージェントは自らASTを解析することなく型制約を直接取得可能となった。
スムーズな移行：VS CodeでPyreflyを有効化する手順
エンドユーザーにとって、新バックエンドへの切り替えは極めてシンプルだ。前提条件として、Pylance拡張機能のバージョン2026.4.1以降、およびPyrefly 0.60.0以上が必要となる。このバージョン組み合わせによりプロトコルのハンドシェイクが確立され、読み取り専用のマルチチャネル機能が両端で安定動作する。
ワークスペースや仮想環境にPyreflyがインストールされているか、設定ファイルに[tool.pyrefly]が存在する場合、VS Codeがそれを検知して確認ダイアログを表示する。承認をクリックするだけで、診断バックエンドがPyreflyへとシームレスに切り替わる。
図1：ワークスペースにPyreflyが導入されると、VS Codeが型診断ソースとしての利用を確認する。出所：devblogs.microsoft.com
設定画面から手動で切り替えることも可能だ。設定項目「Python › Analysis: Diagnostics Source」には、Pylance、Pylance + Pyright、Pylance + Pyreflyの3つの選択肢が用意されている。この仕組みにより、必要に応じて標準エンジンへいつでも即座に戻せる自由が保たれている。
図2：Python拡張機能の設定でDiagnostics Sourceを構成し、Pylance内で利用するチェッカーを選択。出所：devblogs.microsoft.com
切り替えが完了すると、VS Code下部のステータスバーに現在の診断ソースとして「Diagnostics Source: Pylance + Pyrefly」が表示される。型検査の重労働はPyreflyが担い、UI操作やショートカットなどの快適な操作感はPylanceがそのまま提供する。
図3：ステータスバーに有効な診断バックエンドが表示され、PylanceとPyreflyの正常な連携が確認できる。出所：devblogs.microsoft.com
エコシステムの再定義：型サービスが担うAI時代のインフラ
単にエディタ上に波線を描くためだけであれば、マイクロソフトが10年熟成させたPyrightを切り離す必要はなかった。この変革の真の推進力は、大規模言語モデル（LLM）によるコーディングが求める、厳密かつ決定論的なコード文脈への需要にある。Copilotのコード補完、チャットアシスタント、MCP（Model Context Protocol）ツールはいずれも、高精度で安定した型セマンティクスを必要としている。
LLMは単純なテキスト一致だけでは、複雑なコードベースにおける動的ディスパッチを正確に追いきれない。型サーバーがプロジェクトのシンボル依存関係をグラフとして事前に計算し、スナップショットAPIを介して提供することで、コードエージェントは構造化クエリを発行して引数型や制約を検証し、生成コードのエラーを劇的に減らすことができる。
マイクロソフトはオープンプロトコルを提唱することで、エコシステムにおける決定的なポジションを確立した。型クエリの標準化は、知的エージェントとコードベースを結ぶ意味論的インターフェースの確立を意味する。型解析のサービス化は、AI開発ツールチェーン全体の土台を根本から再構築しつつある。
参考リンク：
- マイクロソフト公式Pythonブログのリリース告知
- Pyrefly公式ドキュメントおよびベンチマークレポート
