Type Server Protocol (TSP) 概要

Type Server Protocol とは何か?

Type Server Protocol (TSP) は、タイプサーバーとクライアント (IDE など) 間の通信を容易にするために設計された、特殊な JSON-RPC プロトコルです。ホバーテキストや診断などの人間が読むためのエディタ機能を主に意図した Language Server Protocol (LSP) とは異なり、TSP は構造化された機械可読な型解析データを提供します。これにより、ツールは Markdown 文字列の脆弱な解析に依存することなく、計算された型、宣言された型、期待される型などの型情報をプログラムで消費できます。

TSP が存在する理由

LSP などの既存のプロトコルは、深い型システム統合ではなく、エディタとの対話に最適化されています。LSP のホバー情報は通常 Markdown で配信され、表示には優れていますが、自動リファクタリングツール、リンター、AI エージェントが確実に解析するのは困難です。TSP は、クラス、関数、ユニオン、モジュールを含む実際の型グラフを表す、構造化されたタグ付き型オブジェクトを返すことでこの問題に対処します。このデータを標準化することで、Microsoft は開発者がさまざまな IDE 間で一貫した動作を維持しながら、異なる型チェッカー (Pylance や Pyrefly など) を交換できるようにすることを目指しています。

コアアーキテクチャと機能

TSP は LSP のコンパニオンとして機能し、多くの場合同じ接続上で実行されます。パフォーマンスと状態を管理するために、いくつかの主要な概念を導入しています。

• スナップショットベースの解析: スナップショットは、ワークスペースの特定時点のビューを表す非負の整数です。型解析は計算コストが高いため、結果は特定のスナップショットにバインドされます。ファイルが変更されると、サーバーはスナップショットを進め、クライアントは更新された情報を要求する必要があります。
• マルチ接続モード: 大量の型クエリがメインの LSP 接続をブロックするのを防ぐために、TSP はオプションのセカンダリ IPC チャネルをサポートしています。これにより、メイン接続が可変のワークスペース状態とライフサイクルイベントを処理している間、並行して読み取り専用の型クエリを実行できます。
• 機能ハンドシェイク: クライアントとサーバーは、標準の LSP 初期化プロセス中に TSP 機能のサポートをネゴシエートし、サーバーがプロトコルをサポートしない場合の後方互換性とグレースフルデグラデーションを保証します。

プロトコルサーフェス

TSP は意図的に軽量で、Python コードへの深い洞察を提供する少数のクエリに焦点を当てています。

• typeServer/getComputedType: コードフローから推論された型を返します (例: 絞り込み後)。
• typeServer/getDeclaredType: ソースコードで明示的に定義された型を返します。
• typeServer/getExpectedType: 周囲のコンテキストによって要求される型を返します。
• typeServer/resolveImport: モジュールインポートの解決データを提供します。

コミュニティの視点

TSP の導入は、Python ツールエコシステムの断片化に関して大きな議論を引き起こしました。一部の開発者は構造化データへの移行を評価していますが、他の開発者は Microsoft 主導のプロトコルの増加について懸念を表明しています。

"このプロトコルの真の価値は、文字列ベースの情報から構造化データへの移行にあります。LSP のホバー情報は人間向けです。ツールが型情報を使用したい場合、形式を推測する必要はないはずです。重要な課題は、完全な型グラフの計算コストと、低遅延の IDE 応答性の必要性のバランスを取ることです。" — Hacker News ユーザー coindef

批評家は、このプロトコルが現在 Python の型システムに非常に特化しており、ニッチなツールのままなのか、より広範な標準に進化するのかという疑問が生じていると指摘しています。さらに、basedpyright などの代替 Python ツールの一部のメンテナーは、別個のプロトコルの必要性について懐疑的な見解を示していますが、Ruff の作成者である Astral などのチームは、相互運用性を確保するためにこれをサポートする意向を示しています。