tyとは？Astral製の爆速Python型チェッカーを実際にインストールして型エラーを検出してみた

Pythonのパッケージ・プロジェクト管理ツール「uv」や、Rust製の高速linter／formatter「Ruff」を開発しているAstral社が、型チェッカー「ty」も手がけていることをご存知でしょうか。公式リポジトリ（astral-sh/ty）のREADMEは、tyを「An extremely fast Python type checker and language server, written in Rust」と説明しています。mypyやPyrightに代わる選択肢として開発が進められており、READMEには「10x - 100x faster than mypy and Pyright」という性能面の主張も書かれています。

この記事は、公式リポジトリ（README・CHANGELOG・LICENSE・docsディレクトリ内のドキュメント）を一次情報としています。公式サイト（docs.astral.sh）とブラウザ版Playground（play.ty.dev）は、このクラウド環境のネットワークポリシー上アクセスできなかったため、それらのWeb版の挙動は未確認です。一方で、ty本体はuvx経由で実際にダウンロード・実行でき、型エラーを含むサンプルコードでの検出、設定ファイルによるルールレベルの変更、終了コードの挙動、mypy・Pyrightとの簡易的な実行時間の比較までを、実際にこの環境で動かして確認しました。本文中「実際の出力」「実際に計測」と明記した部分のみが、このクラウド環境で得た結果です。

tyとは：Astralの3本目のRust製ツール

READMEによると、tyは「Astral（uvとRuffの開発元）が支える」型チェッカー兼言語サーバーです。uvがパッケージ・プロジェクト管理、Ruffがlintとフォーマットを担うのに対し、tyは静的型チェックという3本目の役割を担います。ライセンスはMITで、LICENSEファイルの著作権表記は「Copyright (c) 2025 Astral Software Inc.」でした。READMEは2026年11月時点で「ty is currently in beta」と明記しており、バージョン表記も0.0.xという独自のポリシーを採用しています。「Version policy」の章には「ty does not yet have a stable API; breaking changes, including changes to diagnostics, may occur between any two versions」とあり、まだ安定版ではないことがはっきり書かれています。ちなみにFAQには発音についての項目もあり、「tee - why」と読む、スタイルは常に小文字の「ty」で書く、と案内されています。

実際にuvxでインストールし、型エラーを検出してみた

READMEの「Getting started」は、インストール不要で試せるuvx経由の実行を最初に案内しています。

uvx ty check

このクラウド環境にはすでにuvが入っていたため、そのまま次のサンプルコードを用意して実行しました。

def greet(name: str) -> str:
    return "Hello, " + name

def add(a: int, b: int) -> int:
    return a + b

result = add("1", 2)
message: int = greet("world")

class Animal:
    def speak(self) -> str:
        return "..."

class Dog(Animal):
    def speak(self) -> str:
        return "Woof"

def describe(a: Animal) -> str:
    return a.speak()

describe(Dog())
describe(42)

uvx ty check .を実行すると、初回はtyのバイナリ（16.0MiB）がダウンロードされたのち、次のとおり3件の型エラーが報告されました（実際の出力）。

error[invalid-argument-type]: Argument to function `add` is incorrect
 --> sample.py:7:14
  |
7 | result = add("1", 2)
  |              ^^^ Expected `int`, found `Literal["1"]`
info: Function defined here
 --> sample.py:4:5
  |
4 | def add(a: int, b: int) -> int:
  |     ^^^ ------ Parameter declared here

error[invalid-assignment]: Object of type `str` is not assignable to `int`
 --> sample.py:8:16
  |
8 | message: int = greet("world")
  |          ---   ^^^^^^^^^^^^^^ Incompatible value of type `str`
  |          |
  |          Declared type

error[invalid-argument-type]: Argument to function `describe` is incorrect
  --> sample.py:22:10
   |
22 | describe(42)
   |          ^^ Expected `Animal`, found `Literal[42]`
info: Function defined here
  --> sample.py:18:5
   |
18 | def describe(a: Animal) -> str:
   |     ^^^^^^^^ --------- Parameter declared here

Found 3 diagnostics

引数の型違い（invalid-argument-type）、宣言した型と異なる値の代入（invalid-assignment）、サブクラスの引数で基底クラスを期待する箇所への誤った値の渡し方まで、エラーの該当箇所に加えて「どこで宣言された型と矛盾しているか」を示すinfo:行も併記されます。問題のないファイルに対しては、次のように短く結果が返りました（実際の出力）。

All checks passed!

終了コードとルールレベル：ty.tomlで挙動を変えてみる

公式ドキュメントのexit-codesリファレンスには、次の終了コードが定義されています。

終了コード	意味
0	warning以上の違反が見つからなかった
1	warning以上の違反が見つかった
2	CLIオプションや設定が不正、またはIOエラー
101	内部エラー

実際に、型エラーのあるサンプルでは終了コードが1、問題のないファイルでは0になることを確認しました。さらに、各ルールにはerror・warn・ignoreの3段階のレベルがあり、pyproject.tomlの[tool.ty.rules]、またはプロジェクト直下のty.tomlの[rules]で個別に変更できます。実際に次のty.tomlを置いてinvalid-assignmentを警告扱いに下げてみました。

[rules]
invalid-assignment = "warn"

再実行すると、該当箇所の表示がerror[invalid-assignment]からwarning[invalid-assignment]に変わりました（実際の出力の該当行）。

warning[invalid-assignment]: Object of type `str` is not assignable to `int`
 --> sample.py:8:16

ドキュメントの説明どおり、warningだけになっても既定では終了コードは1のままで、--exit-zero-on-warningを付けた場合だけ0になる設計です。また、個々のルールの説明はty explain rule <ルール名>で確認できます。ty explain rule invalid-assignmentを実行すると、該当ルールが「Stable (since 0.0.1-alpha.1)」であることや、何が問題かを示す次の説明が返ってきました（実際の出力）。

# invalid-assignment

Default level: error | Stable (since 0.0.1-alpha.1)

## What it does

Checks for assignments where the type of the value is not assignable to the type of the assignee.

CLIの構成：checkのほかにserver・version・explainがある

ty --helpを実行すると、サブコマンドの一覧が表示されます（実際の出力）。

Commands:
  check    Check a project for type errors
  server   Start the language server
  version  Display ty's version
  explain  Explain rules and other parts of ty
  help     Print this message or the help of the given subcommand(s)

ty version（または--version）を実行したところ、このクラウド環境にはty 0.0.100がインストールされました。serverサブコマンドは言語サーバーを起動するためのもので、エディタのLSPクライアントから呼び出されることを前提にしており、エディタを持たないこのクラウド環境では実際の起動確認はしていません。

エディタ連携と言語サーバー機能：ドキュメント上の記載で、この環境では未検証

docs/features/language-server.mdによると、tyはGo to Definition・Go to Declaration・Go to Type Definition・Go to Implementation・Find all references・ドキュメント/ワークスペースシンボル検索といったコードナビゲーション機能、コード補完（未インポートのシンボルに対するauto-import提案を含む）、インレイヒント、そして編集中のファイルに絞って高速に再解析する「fine-grained incremental analysis」を備えるとされています。docs/editors.mdには、Astral公式のVS Code拡張（VS Code Marketplaceで配布）、Neovim向けのnvim-lspconfig設定、PyCharmなどへの統合方法が案内されています。VS Code拡張は既定でPython拡張（Pylance）側の言語サーバーを無効化する仕組みになっており、両方を使いたい場合はpython.languageServerとty.disableLanguageServicesを設定で明示的に切り替える必要がある、とも書かれています。これらはいずれもドキュメントの記載内容で、エディタを使わないこの検証環境では実際の動作を確認していません。

簡易的に計測した実行時間：mypy・Pyrightとの比較

README記載の「10x - 100x faster than mypy and Pyright」という主張は、home-assistant/coreのような大規模プロジェクトをキャッシュなしで型チェックしたベンチマークに基づくものです。このクラウド環境でそれと同規模の検証を行うのは現実的ではないため、代わりに前述の22行のサンプルファイル1つに対して、uvx経由でty・mypy・Pyrightをそれぞれ実行し、簡易的にtimeコマンドで実行時間を計測しました（実際に計測。いずれも1回のみの実行で、ごく小さなファイルが対象のため、プロセス起動オーバーヘッドが結果の大半を占めている可能性が高く、公式ベンチマークの再現ではありません）。

ツール	バージョン	実行時間（real）
ty	0.0.100	0.069秒
Pyright	1.1.414	0.841秒
mypy	2.4.1（compiled）	0.748秒

検出された型エラーの件数と内容（引数の型違い3件）はty・mypy・Pyrightの3者で一致しており、エラーメッセージの文言や形式だけが異なっていました。今回のごく小さな実行例では、tyがmypy・Pyrightよりおおむね1桁速いという結果になり、方向性としてはREADMEの主張と矛盾しませんが、対象ファイルが極端に小さいため「10倍〜100倍」という具体的な倍率そのものを検証できたわけではない点は明記しておきます。

活発な開発速度：直近は3日間隔でリリース

CHANGELOG.mdによると、本稿執筆時点の最新版0.0.100は2026年11月9日公開で、1つ前の0.0.99は同年11月6日公開でした。0.0.100には、TypedDictの無効なキーを示す診断を3種類のルールに分割するなどの破壊的変更（Breaking changes）、ParamSpecデコレータの部分適用に関する修正、各種メモリ使用量の改善が含まれています。CHANGELOGに記載されたContributorsには、このCHANGELOGを書いたコミットのタイミングで@mtshiba・@charliermarsh・@AlexWaygood・@MichaReiser・@sharkdp・@carljmの名前が並んでいました。このうち@sharkdpは、Rust製CLIツールfd・batの作者としても知られるアカウントです。なお、READMEの「Contributing」の章には「Development of this project takes place in the Ruff repository at this time」とあり、Rustで書かれた型チェッカー本体のソースコードはastral-sh/tyリポジトリではなくastral-sh/ruffリポジトリ側で開発されている、という構成も確認できました。

向いている場面・まだ注意が必要な場面

• 向いている：すでにuvやRuffを使っていて、同じAstral製のツールチェーンで型チェックも試したい場合。uvx ty checkだけでインストール済み環境を汚さずに試せるため、既存プロジェクトへの導入検討のハードルは低めです
• まだ注意が必要：READMEとCHANGELOGに明記されているとおり、0.0.xというバージョン体系のままbeta運用が続いており、診断の名前やルール構成を含む破壊的変更がリリースごとに入り得ます。CIに組み込む場合は、バージョンを固定しないと診断結果が変わってビルドの成否が揺れる可能性があります

この記事で確認できなかったこと

繰り返しになりますが、公式サイト（docs.astral.sh）とブラウザ版Playground（play.ty.dev）は、このクラウド環境のネットワークポリシー上アクセスできませんでした。そのため、ドキュメントサイト上の表示や、Playgroundの実際の操作感は確認できていません。また、VS Code・PyCharm・Neovimとのエディタ統合、コード補完やインレイヒントといった言語サーバー機能は、エディタを持たないこの環境では実際の動作を試せていません。実行時間の比較も、22行の小さなサンプル1つを1回計測しただけの簡易的な結果であり、README記載の「10x - 100xの高速化」という具体的な数値そのものを再現したものではない点を重ねて明記します。

まとめ

tyは、uvとRuffで知られるAstralが開発する、Rust製の型チェッカー兼言語サーバーです。実際にuvx ty checkでサンプルコードの型エラーを検出できたこと、ty.tomlでルールレベルを変更すると出力と終了コードの挙動が変わること、簡易計測ではmypy・Pyrightより高速に動いたことを、このクラウド環境で実際に確認できました。一方で、0.0.xというバージョン体系のまま破壊的変更が入り得るbeta運用であること、エディタ統合や公式サイト・Playgroundの挙動は今回の環境では検証できなかったことは、導入前に把握しておきたい点です。

参考にした一次情報

• GitHub公式リポジトリ：astral-sh/ty（README、LICENSE）
• CHANGELOG.md（0.0.99・0.0.100のリリースノート）
• docs/reference/exit-codes.md（終了コードの定義）
• docs/reference/configuration.md（ty.toml・pyproject.tomlでの設定）
• docs/features/language-server.md（言語サーバー機能の一覧）
• docs/editors.md（VS Code・Neovim・PyCharmとの連携方法）
• 本文中のuvx ty check・ty version・ty --help・ty explain rule invalid-assignment・ty.tomlによるルール変更・mypy/Pyrightとの実行時間比較は、この記事の検証時点で実際にこのクラウド環境でty 0.0.100・mypy 2.4.1・Pyright 1.1.414を使って得たものです。