tsserverとは何だったのか、これからどうなるのか 

中村遼大 / @nowaki28 ● フロントエンドエンジニア ● 株式会社ドワンゴで働いています 自己紹介 

VSCode使ってますか？ 

VSCodeの便利機能 ● 入力補完 ● ホバーで型情報が表示される ● 定義にジャンプ ● 参照箇所の一覧 ● シンボル・ファイルのリネーム ● コンパイルエラーを波線で教えてくれる …等々 

それVimでできるよおじさん「それVimでできるよ」 ● というかEmacsでもSublime Textでもできる ● 先ほど挙げたような機能はエディタ/IDEではなくtsserverが提供している 

今日話すこと 1. tsserverとは 2. これからどうなるのか 

tsserverとは 

Architectural Overview (Strada) https://github.com/microsoft/TypeScript-Compiler-Notes/tree/main/intro#what-is-in-the-typescript-repo 

tsserver https://github.com/microsoft/TypeScript/wiki/Standalone-Server-%28tsserver%29 The TypeScript standalone server (aka tsserver) is a node executable that encapsulates the TypeScript compiler and language services, and exposes them through a JSON protocol. tsserver is well suited for editors and IDE support. ● エディタやIDEにTypeScriptコンパイラの機能や専用API群を提供 ● JSONで通信 

tsserver https://github.com/microsoft/TypeScript-Compiler-Notes/tree/main/intro#what-is-in-the-typescript-repo 

補足: Programmatic API (Language Service API / Compiler API) TypeScriptコンパイラをプログラム中から利用するためのAPI ● Language Service API https://github.com/microsoft/TypeScript/wiki/Using-the-Language-Service-API ○ Compiler APIを土台に、エディタ支援機能を提供する API ○ Language Service Pluginで拡張可能…Vue/Svelteなど構文拡張のエントリポイント ○ tsserver = プロセス外からLanguage Serviceの機能を利用するためのスタンドアロンサーバ ● Compiler API https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API ○ TypeScriptプログラムをコンパイル (構文解析, 型検査, 変換など)するためのAPI ○ 直接ASTを触りたいような場合はこちら 

補足: Programmatic API (Language Service API / Compiler API) https://github.com/microsoft/TypeScript-Compiler-Notes/tree/main/intro#what-is-in-the-typescript-repo 

tsserver protocol: Request field 役割 seq クライアント側で採番する連番の識別子 type "request" command 実行したい操作名。e.g. "definition", "completionInfo" arguments commandごとの入力パラメータ 

tsserver protocol: Response field 役割 seq サーバ側で採番する連番の識別子 type "response" command どのcommandへの応答か request_seq 元requestの"seq"と対応 success true / false body 成功時の結果本文 

tsserver protocol: Event field 役割 seq サーバ側で採番する連番の識別子 type "event" event event種別 body eventごとの通知内容 ※Eventはサーバ→クライアントのみで、応答はない 

tsserverと喋ってみる 

ターミナルから話しかけてみる ● npmのtypescriptパッケージは tsc と共に tsserver コマンドも提供している ● npx tsserver で起動してみる 

ターミナルから話しかけてみる ● 正しい形式のリクエストを送るとちゃんと返ってきた 

テキストエディタから話しかけてみる Vimからtsserverを起動し、ファイルをopenするリクエストを送る 

テキストエディタから話しかけてみる カーソル位置とquickinfoコマンドをリクエストするTsQuickinfo関数を定義し、 Shift + kにマッピング ※quickinfo = VSCodeでホバーした変数の型が表示されるアレ 

できた ↑左下にresultの型が表示されている 

ここまでのまとめ ● tsserverとは何だったのか ○ typescriptパッケージに同梱されたエディタ向けのプログラム : tsserver ., ○ エディタと通信しコンパイラの機能を提供 （標準入出力/IPC） ■ Request / Response / Event を独自規格のJSONで表現 ● Programmatic API ○ コンパイラの機能をプログラム中から利用するための API 

これからどうなるのか 

TypeScript 7.0 (Corsa) go言語での実装(microsoft/typescript-go)への移行に伴い”tsserver”は無くなる ● LSP(Language Server Protocol)を実装した言語サーバへ ○ tsgo --lsp で起動 ● Programmatic API(Language Service API / Compiler API)の破壊的変更 ○ stable programmatic APIの提供は7.1以降: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/ ○ 特にLanguage Service Plugin周りやTransformer/Emitterは影響が大きそう 

https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/ Language Server Protocol https://microsoft.github.io/language-server-protocol/ The Language Server Protocol (LSP) defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references etc. ● Microsoftによって策定されたエディタ /IDEと言語サーバ間の通信プロトコル ● 特定のエディタや言語に依存しない ● 自動補完, 定義ジャンプや参照一覧などの機能を提供 → 標準化されたtsserver protocolみたいなもの 

AIエージェントとLSP AIエージェントもプラグインやMCP経由でLSPを利用する そのままだとfind/grep/cat等で余計なコードまでトークン化して読みがち → LSPがあると定義位置, 型, 参照一覧などを直接・正確に取得できる ● Claude Code plugin ○ Claude Codeは公式にLSP Pluginが提供されている ○ https://code.claude.com/docs/en/plugins-reference#lsp-servers ● Serena MCPなどのMCP ○ Claude pluginで対応していない言語や他のツールでも LSPが利用可能 ○ https://github.com/oraios/serena 

何故今まで標準のLSPじゃなかったの？ ● 元々LSPがtsserverのような仕組みの標準化を目指したプロジェクトだった https://code.visualstudio.com/blogs/2016/06/27/common-language-protocol ○ TypeScriptがむしろ先駆者側 ○ コンパイラがエディタ支援機能の APIを提供・公開するというのは当時としては先進的だった （他に は.NETのRoslynなど） ● LSPの仕様が固まった頃には既に高性能なtsserver protocolと専用VSCode拡張 があり、それほど優先度が高くなかった ○ 要望自体は古くから出ていた https://github.com/microsoft/TypeScript/issues/39459 ○ VSCode以外のエディタではtypescript-language-serverのような互換用ライブラリを使っている 

LSP: Request / Response / Notification https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/ ● tsserverのような独自RPCではなくJSON-RPC 2.0を採用 ● NotificationがtsserverのEvent相当 ○ サーバだけでなくクライアントも Notificationを送る（編集の反映など） ※JSONの前にContent-Lengthヘッダが付く。tsserverとは異なりリクエストにも必要 

cf. tsserver protocol 操作(command/method) tsserver LSP 定義ジャンプ definition textDocument/definition 参照検索 references textDocument/references リネーム rename textDocument/rename 補完 completionInfo textDocument/completion ホバー情報 quickinfo textDocument/hover 診断（エラー/警告） geterr textDocument/publishDiagnostics フォーマット format textDocument/formatting ファイルリネーム getEditsForFileRename workspace/willRenameFiles 

typescript-goの言語サーバとも喋ってみる ● tsserver のような別コマンドではなく、コマンドラインオプションになった: tsgo --lsp . ● クライアントからのリクエストにもContent-Lengthヘッダが必要 ● 最初にInitializeリクエストが必要 - 

で、結局何がどうなるの？ 

エコシステムへの影響を考える① ● テキストエディタのユーザ ○ エディタ支援機能の高速化 （もちろんビルドも） ○ 2026年5月現在VSCodeではTypeScript Native Preview + js/ts.experimental.useTsgo フラグで利用可能 ■ embedded language (.vueや.svelteなど) を書いている人たちが使えるようになるのはもう少し先かも ● tsserverに依存しているエディタプラグイン ○ typescript-language-serverのようなtsserver <-> LSPのアダプタを経由していれば移行はそこまで 難しくなさそう ○ tsserver <-> LSPの変換をしていたツールは基本的には不要になる？ ■ ただしTypeScript固有のコマンドや非標準のRequestがあるためプラグイン層は引き続き必要 ○ 複数のプラグインとTypeScript APIのコネクションを仲介するプラグインが必要になる？ 

エコシステムへの影響を考える② ● Programmatic API(Language Service API / Compiler API)に依存している静的解析ツールや言語サーバ e.g. typescript-eslint, ts-morph, Typia, Volar …etc ○ 2026年5月現在まだどのようなAPIになるか未確定 ■ Compiler APIの主要機能に相当する実装は既に進んでおり、 read AST系は同じ感覚で利用できそう : https://github.com/microsoft/typescript-go/tree/main/_packages/native-preview/src/api transform/emit周りではJavaScript callbackをロードする口が無い以上 Typia等は影響が大きそう : https://github.com/microsoft/typescript-go/issues/516 ○ Volar等はLanguage Service PluginでLanguage Serviceレイヤの挙動を書き換えていたが... ■ （直近の動向）まだ議論中だが、 Pluginではなくembedded language側にLSPサーバとしてクライアントとやり取りする 責務を移譲する方針が提案されている : https://github.com/microsoft/typescript-go/issues/2824 ● https://code.visualstudio.com/api/language-extensions/embedded-languages#request-forwarding で紹介されている Request Forwardingのアプローチが近いだろうか 

まとめ 

今日のまとめ ● tsserverとは何だったのか: ○ typescriptパッケージに同梱されたテキストエディタ向けのプログラム : tsserver ., ○ 独自の規格でエディタと通信し、 TypeScriptコンパイラの機能をエディタ支援向けに提供 ● これからどうなるのか: ○ 標準化されたLSPサーバに置き換わる : tsgo --lsp . ○ Programmatic APIが互換性の無い新しいものになる（ TypeScript 7.1以降） ■ tscが直接ロードする仕組み(Language Service Plugin)に依存していたりTransformer/Emitterの挙動をカス タムしていたりするツールには再設計が求められる 

ご清聴ありがとうございました