mypyとpyrightの違いと使い方｜設定例・CI導入・出力比較

mypyとpyrightは、どちらもPythonの型ヒントをもとにコードを実行せずに誤りを見つける「静的型チェッカー」で、mypyはPython公式に近い標準的な実装、pyrightはMicrosoft製でVS Code（Pylance）の中身にもなっている実装です。同じコードでも、注釈のない関数を調べるかどうか、分岐後の型をどう推論するかといった考え方が違うため、片方では通るコードがもう片方では指摘されることがあります。

この記事では、mypy 2.3.1とpyright 1.1.414に同じサンプルコードをかけて、出力をそのまま並べて比較します。さらに、コピペで使える pyproject.toml（[tool.mypy] と [tool.pyright]）、既存コードに段階的に入れる手順、pre-commitとGitHub Actionsの設定、実行時間の実測、VS Codeとの関係、types-* スタブの入れ方、つまずきやすいエラーの直し方までまとめました。型ヒントそのものの書き方は扱わず、「ツールをどう使うか」に絞っています。

mypyとpyrightの比較早見表

どちらを選ぶかの判断表

迷ったら「エディタで使っているものをCIにも使う」が基本です。VS Codeなら pyright、それ以外や既存のmypy資産があるなら mypy を選び、必要になったらもう片方を足すのが手戻りの少ない進め方です。

インストールして最初に実行する

検証環境は Python 3.11.15、mypy 2.3.1（compiled: yes）、pyright 1.1.414 です。仮想環境（.venv）を作ってから入れます。

python3 -m venv .venv
. .venv/bin/activate
pip install mypy==2.3.1 pyright==1.1.414
mypy --version
pyright --version

mypy 2.3.1 (compiled: yes)
pyright 1.1.414

pip版のpyrightはNode.js上で動く本体を呼び出すラッパーです（Node.jsが無い環境では初回に取得します）。npmで入れる場合は npm i -g pyright です。終了コードは、どちらもエラーがあれば1、なければ0なので、そのままCIの合否に使えます。

同じコードを両方にかけて検出の違いを見る

Optional・再代入・ナローイング・注釈なし関数・戻り値推論・Any・TypedDict・Protocol・overload・ジェネリクス・到達不能コードを1ファイルに詰め込んだサンプルです。reveal_type() はチェッカーが「その式をどの型と見ているか」を表示する関数で、実行時には存在しませんが型チェック時だけ使えます。

"""sample.py : mypy と pyright に同じコードをかけて違いを見る"""
from typing import Any, Protocol, TypedDict, TypeVar, overload


# 1. Optional（None を含む戻り値）をそのまま使う
class Item:
    def __init__(self, name: str) -> None:
        self.name = name


def find_item(items: list[Item], name: str) -> Item | None:
    for item in items:
        if item.name == name:
            return item
    return None


def case1_optional(items: list[Item]) -> str:
    found = find_item(items, "pen")
    return found.name  # None の可能性


# 2. 分岐で別の型を代入
def case2_reassign(flag: bool) -> None:
    if flag:
        value = 3
    else:
        value = "three"
    reveal_type(value)


# 3. isinstance で分岐した後の型（union か join か）
def case3_join(val: str | int) -> None:
    if isinstance(val, str):
        result = val
    else:
        result = val
    reveal_type(result)


# 4. 注釈なし関数（本文をチェックするか、呼び出し側で推論するか）
def case4_untyped(a, b):
    return a + b


def case4_body():
    return 1 + "a"  # 注釈なし関数の中の明らかな誤り


def case4_caller() -> None:
    n = case4_untyped(1, 2)
    reveal_type(n)
    n.upper()  # int に upper() はない


# 5. 戻り値型の推論
def case5_make_count():
    return 42


def case5_use() -> None:
    label = case5_make_count() + "件"  # int + str
    reveal_type(label)


# 6. Any
def case6_any(raw: Any) -> None:
    raw.anything()  # Any には何をしても通る
    text: str = raw
    reveal_type(text)


# 7. TypedDict
class Order(TypedDict):
    order_id: int
    note: str


def case7_typeddict() -> None:
    order: Order = {"order_id": 1}  # note が足りない
    print(order["memo"])  # 存在しないキー


# 8. Protocol
class HasArea(Protocol):
    def area(self) -> float: ...


class Square:
    def __init__(self, side: float) -> None:
        self.side = side

    def area(self) -> float:
        return self.side**2


class Label:
    text = "label"


def total_area(shapes: list[HasArea]) -> float:
    return sum(s.area() for s in shapes)


def case8_protocol() -> None:
    total_area([Square(2.0)])
    total_area([Label()])  # area() がない


# 9. overload
@overload
def parse(value: int) -> int: ...
@overload
def parse(value: str) -> str: ...
def parse(value: int | str) -> int | str:
    return value


def case9_overload(raw: Any) -> None:
    parse(1.5)  # float は overload にない
    reveal_type(parse(raw))


# 10. ジェネリクス
T = TypeVar("T")


def first(items: list[T]) -> T:
    return items[0]


def case10_generics() -> None:
    reveal_type(first([1, 2, 3]))
    mixed = [1, 3.4, ""]
    reveal_type(mixed)
    pair = (1, "stop")
    reveal_type(pair[1])


# 11. 到達不能コード
def case11_unreachable(count: int) -> str:
    if isinstance(count, int):
        return "number"
    return "other"  # ここには到達しない

mypy（既定設定）の出力

$ mypy sample.py
sample.py:20: error: Item "None" of "Item | None" has no attribute "name"  [union-attr]
sample.py:28: error: Incompatible types in assignment (expression has type "str", variable has type "int")  [assignment]
sample.py:29: note: Revealed type is "int"
sample.py:37: error: Incompatible types in assignment (expression has type "int", variable has type "str")  [assignment]
sample.py:38: note: Revealed type is "str"
sample.py:52: note: Revealed type is "Any"
sample.py:63: note: Revealed type is "Any"
sample.py:70: note: Revealed type is "str"
sample.py:80: error: Missing key "note" for TypedDict "Order"  [typeddict-item]
sample.py:81: error: TypedDict "Order" has no key "memo"  [typeddict-item]
sample.py:107: error: List item 0 has incompatible type "Label"; expected "HasArea"  [list-item]
sample.py:120: error: No overload variant of "parse" matches argument type "float"  [call-overload]
sample.py:120: note: Possible overload variants:
sample.py:120: note:     def parse(value: int) -> int
sample.py:120: note:     def parse(value: str) -> str
sample.py:121: note: Revealed type is "Any"
sample.py:133: note: Revealed type is "int"
sample.py:135: note: Revealed type is "list[object]"
sample.py:137: note: Revealed type is "str"
Found 7 errors in 1 file (checked 1 source file)

pyright（既定＝standard）の出力

$ pyright sample.py
sample.py
  sample.py:20:18 - error: "name" is not a known attribute of "None" (reportOptionalMemberAccess)
  sample.py:29:17 - information: Type of "value" is "Literal[3, 'three']"
  sample.py:38:17 - information: Type of "result" is "str | int"
  sample.py:47:12 - error: Operator "+" not supported for types "Literal[1]" and "Literal['a']" (reportOperatorIssue)
  sample.py:52:17 - information: Type of "n" is "Literal[3]"
  sample.py:53:7 - error: Cannot access attribute "upper" for class "Literal[3]"
    Attribute "upper" is unknown (reportAttributeAccessIssue)
  sample.py:62:13 - error: Operator "+" not supported for types "Literal[42]" and "Literal['件']" (reportOperatorIssue)
  sample.py:63:17 - information: Type of "label" is "Unknown"
  sample.py:70:17 - information: Type of "text" is "str"
  sample.py:80:20 - error: Type "dict[str, int]" is not assignable to declared type "Order"
    "note" is required in "Order" (reportAssignmentType)
  sample.py:81:11 - error: Could not access item in TypedDict
    "memo" is not a defined key in "Order" (reportGeneralTypeIssues)
  sample.py:107:17 - error: Argument of type "list[Label]" cannot be assigned to parameter "shapes" of type "list[HasArea]" in function "total_area"
    "Label" is incompatible with protocol "HasArea"
      "area" is not present (reportArgumentType)
  sample.py:120:5 - error: No overloads for "parse" match the provided arguments (reportCallIssue)
  sample.py:120:11 - error: Argument of type "float" cannot be assigned to parameter "value" of type "str" in function "parse"
    "float" is not assignable to "str" (reportArgumentType)
  sample.py:121:17 - information: Type of "parse(raw)" is "Unknown"
  sample.py:133:17 - information: Type of "first([1, 2, 3])" is "int"
  sample.py:135:17 - information: Type of "mixed" is "list[Unknown]"
  sample.py:137:17 - information: Type of "pair[1]" is "Literal['stop']"
9 errors, 0 warnings, 9 informations

ケース別：どちらが何を検出したか

既定設定では、pyrightの方が「注釈のないコード」に強く、mypyの方が「型を1つに決める」ことに厳格です。どちらが正しいというより設計思想の違いなので、チームでどちらかに揃えることが大切です。

strictにすると何が増えるか

mypy --strict は複数のフラグをまとめて有効にするスイッチです。mypy --help に一覧が出ます。

--strict   Strict mode; enables the following flags:
           --disallow-any-generics, --disallow-subclassing-any, --disallow-untyped-calls,
           --disallow-untyped-defs, --disallow-incomplete-defs, --check-untyped-defs,
           --disallow-untyped-decorators, --warn-redundant-casts, --warn-unused-ignores,
           --warn-return-any, --no-implicit-reexport, --strict-equality, --extra-checks

--warn-unreachable はstrictに含まれないので、到達不能コードも見たいときは足します。同じサンプルにかけると、既定の7件から14件に増えました（差分だけ抜粋）。

$ mypy --strict --warn-unreachable sample.py
sample.py:42: error: Function is missing a type annotation  [no-untyped-def]
sample.py:46: error: Function is missing a return type annotation  [no-untyped-def]
sample.py:47: error: Unsupported operand types for + ("int" and "str")  [operator]
sample.py:51: error: Call to untyped function "case4_untyped" in typed context  [no-untyped-call]
sample.py:57: error: Function is missing a return type annotation  [no-untyped-def]
sample.py:62: error: Call to untyped function "case5_make_count" in typed context  [no-untyped-call]
sample.py:144: error: Statement is unreachable  [unreachable]
Found 14 errors in 1 file (checked 1 source file)

pyrightのCLIには --strict フラグがなく、設定ファイルの typeCheckingMode かファイル先頭の # pyright: strict で切り替えます。strictでは「型がわからない（Unknown）」ことそのものが指摘対象になり、9件から21件に増えました（差分だけ抜粋）。

$ pyright sample.py   # pyrightconfig.json: {"typeCheckingMode": "strict"}
  sample.py:42:5 - error: Return type is unknown (reportUnknownParameterType)
  sample.py:42:19 - error: Type of parameter "a" is unknown (reportUnknownParameterType)
  sample.py:42:19 - error: Type annotation is missing for parameter "a" (reportMissingParameterType)
  sample.py:43:12 - error: Return type is unknown (reportUnknownVariableType)
  sample.py:53:5 - error: Type of "upper" is unknown (reportUnknownMemberType)
  sample.py:62:5 - error: Type of "label" is unknown (reportUnknownVariableType)
  sample.py:81:11 - error: Argument type is unknown
    Argument corresponds to parameter "values" in function "print" (reportUnknownArgumentType)
  sample.py:135:17 - information: Type of "mixed" is "list[int | float | str]"
  sample.py:142:8 - error: Unnecessary isinstance call; "int" is always an instance of "int" (reportUnnecessaryIsInstance)
21 errors, 0 warnings, 9 informations

コピペ用の設定ファイル（pyproject.toml と pyrightconfig.json）

1つの pyproject.toml に両方の設定を置けます。「本体はstrict、古いモジュールとテストは緩める、スタブのないライブラリは黙らせる」という実務でよく使う形です。

[project]
name = "app"
version = "0.1.0"
requires-python = ">=3.11"

# ---------- mypy ----------
[tool.mypy]
python_version = "3.11"
files = ["src", "tests"]          # 対象。mypy 実行時に引数なしでこれを見る
mypy_path = "src"                  # src レイアウトの解決用
strict = true                      # --strict 相当（個別フラグをまとめて有効化）
warn_unreachable = true            # 到達不能コードを警告（strict には含まれない）
show_error_codes = true            # [error-code] を表示（2.x では既定で on）
pretty = false                     # true にするとソース行つきで表示
exclude = ["build/", "dist/"]

# 未整備の古いモジュールは段階的に：まず本文チェックだけ、注釈は要求しない
[[tool.mypy.overrides]]
module = ["app.legacy", "app.legacy.*"]
disallow_untyped_defs = false
disallow_incomplete_defs = false
check_untyped_defs = true

# 型スタブのないサードパーティは import エラーを抑止
[[tool.mypy.overrides]]
module = ["somelib", "somelib.*", "yaml"]
ignore_missing_imports = true

# テストは untyped 呼び出しを許可
[[tool.mypy.overrides]]
module = ["tests.*"]
disallow_untyped_calls = false

# ---------- pyright ----------
[tool.pyright]
include = ["src", "tests"]
exclude = ["**/__pycache__", "build", "dist"]
pythonVersion = "3.11"
typeCheckingMode = "strict"        # off / basic / standard(既定) / strict
strict = ["src/app/core.py"]       # 特定ファイルだけ strict にすることも可
venvPath = "."                     # 仮想環境のある親ディレクトリ
venv = ".venv"                     # 仮想環境の名前（コマンド行 --venvpath でも可）
reportMissingImports = "error"
reportMissingTypeStubs = "none"    # スタブなしのライブラリを許容
reportUnknownMemberType = "warning"
reportUnknownArgumentType = "warning"

# 一部ディレクトリだけ設定を変える
[[tool.pyright.executionEnvironments]]
root = "src/app/legacy"
reportMissingParameterType = "none"
reportUnknownParameterType = "none"
reportUnknownVariableType = "none"

JSONで持ちたい場合の pyrightconfig.json は次のとおりです（pyproject.toml と両方あるとJSONが優先されます）。

{
  "include": ["src", "tests"],
  "exclude": ["**/__pycache__", "build", "dist"],
  "pythonVersion": "3.11",
  "typeCheckingMode": "strict",
  "venvPath": ".",
  "venv": ".venv",
  "reportMissingImports": "error",
  "reportMissingTypeStubs": "none",
  "reportUnknownMemberType": "warning",
  "reportUnknownArgumentType": "warning",
  "executionEnvironments": [
    {
      "root": "src/app/legacy",
      "reportMissingParameterType": "none",
      "reportUnknownParameterType": "none",
      "reportUnknownVariableType": "none"
    }
  ]
}

この設定で src/app/core.py（注釈あり）、src/app/legacy/report.py（注釈なし、import somelib あり）、tests/test_core.py を含むプロジェクトを検証しました。mypyは引数なしで files を読み、pyrightは include を読みます。

$ mypy
Success: no issues found in 6 source files

$ pyright
src/app/legacy/report.py
  src/app/legacy/report.py:1:8 - error: Import "somelib" could not be resolved (reportMissingImports)
  src/app/legacy/report.py:7:9 - warning: Type of "append" is partially unknown
    Type of "append" is "(object: Unknown, /) -> None" (reportUnknownMemberType)
  ...
2 errors, 3 warnings, 0 informations

pyrightには mypy の ignore_missing_imports のような「モジュール名ごとの抑止」がないため、存在しないライブラリのimportは行単位の # pyright: ignore[reportMissingImports] か、executionEnvironments の reportMissingImports = "none" で扱います。行コメントを付けると 0 errors になりました。

既存コードへ段階的に導入する手順

一度に strict を有効にすると、指摘が数百件になって手が止まりがちです。「まず通す → 範囲を広げる → strictへ」の順で進めます。

抑止コメントの書き方と「効いていないコメント」の検出

存在しない関数を呼ぶ行に、3通りのコメントを付けて両方にかけました。

from app import core


def demo() -> None:
    core.missing_func()  # 1) 存在しない関数（そのまま）
    core.missing_func()  # type: ignore[attr-defined]
    core.missing_func()  # pyright: ignore[reportAttributeAccessIssue]
    count: int = 1  # type: ignore[assignment]
    print(count)

$ mypy src/app/ignores.py    # strict なので warn_unused_ignores が有効
src/app/ignores.py:5: error: Module has no attribute "missing_func"  [attr-defined]
src/app/ignores.py:7: error: Module has no attribute "missing_func"  [attr-defined]
src/app/ignores.py:8: error: Unused "type: ignore" comment  [unused-ignore]
Found 3 errors in 1 file (checked 1 source file)

$ pyright src/app/ignores.py  # reportUnnecessaryTypeIgnoreComment を "warning" に設定
src/app/ignores.py
  src/app/ignores.py:5:10 - error: "missing_func" is not a known attribute of module "app.core" (reportAttributeAccessIssue)
  src/app/ignores.py:8:23 - warning: Unnecessary "# type: ignore" comment (reportUnnecessaryTypeIgnoreComment)
1 error, 1 warning, 0 informations

両方を使うチームでは # type: ignore[error-code] に統一すると、コメントが1つで済みます。エラーコードは mypy の出力末尾の [...]、ルール名は pyright の出力末尾の (...) をそのまま書きます。

pre-commit と GitHub Actions で自動実行する

pre-commit（ローカルで実行して確認）

pre-commit 4.6.2 で、mypyとpyrightの両方を走らせる設定です。mypyのフックは隔離された環境で動くため、必要なスタブは additional_dependencies に書きます。

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v2.3.1
    hooks:
      - id: mypy
        additional_dependencies: ["types-PyYAML"]   # 必要なスタブはここに
        args: ["--config-file=pyproject.toml"]
        pass_filenames: false                         # pyproject の files= を使う
  - repo: https://github.com/RobertCraigie/pyright-python
    rev: v1.1.414
    hooks:
      - id: pyright

$ pip install pre-commit
$ pre-commit install
pre-commit installed at .git/hooks/pre-commit

$ pre-commit run --all-files
[INFO] Installing environment for https://github.com/pre-commit/mirrors-mypy.
[INFO] Installing environment for https://github.com/RobertCraigie/pyright-python.
mypy.....................................................................Passed
pyright..................................................................Passed

find_task(tasks, 1).title（Noneの可能性がある戻り値をそのまま使う）を追加してコミットすると、両方のフックで止まりました。

$ git commit -m "add first_title"
mypy.....................................................................Failed
- hook id: mypy
- exit code: 1

src/app/core.py:26: error: Item "None" of "Task | None" has no attribute "title"  [union-attr]
Found 1 error in 1 file (checked 6 source files)

pyright..................................................................Failed
- hook id: pyright
- exit code: 1

src/app/core.py
  src/app/core.py:26:32 - error: "title" is not a known attribute of "None" (reportOptionalMemberAccess)
1 error, 0 warnings, 0 informations

GitHub Actions（未実行：公式ドキュメントに沿った構成）

この記事の環境からはGitHubに接続できないため、次のワークフローは実行していません。actions/checkout v7、actions/setup-python v7 の書き方に沿っています。.mypy_cache をキャッシュすると2回目以降が大幅に短くなります。

# .github/workflows/typecheck.yml
name: typecheck
on:
  pull_request:
  push:
    branches: [main]

jobs:
  mypy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: "3.12"
          cache: pip
      - run: pip install -e . mypy==2.3.1 types-PyYAML
      - uses: actions/cache@v4
        with:
          path: .mypy_cache
          key: mypy-${{ runner.os }}-${{ hashFiles('pyproject.toml') }}
      - run: mypy            # pyproject.toml の files= を使う

  pyright:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v7
        with:
          python-version: "3.12"
      - run: pip install -e .
      - uses: jakebailey/pyright-action@v3   # Node.js を用意して pyright を実行
        with:
          version: 1.1.414

jakebailey/pyright-action を使わない場合は、actions/setup-node@v7 のあとに npm i -g pyright@1.1.414 && pyright でも同じです。

実行時間を実測する

2コアのLinuxコンテナで、同じコードを time で計測しました。結果は環境とコードの形に大きく左右されるので、「順序」ではなく「キャッシュの効き方」に注目してください。

$ time mypy rich
real    0m3.206s
$ time mypy rich          # 2回目
real    0m0.143s
$ time pyright rich
real    0m13.944s
$ pyright --stats rich | grep -E 'Parse|Bind|Check'
Parse:                0.53sec
Bind:                 0.63sec
Check:                9.95sec

pyrightの公式ドキュメントは「mypyより3〜5倍速い」と説明しており、多くのベンチマーク記事でもそう報告されていますが、この環境（2コア、mypycでコンパイル済みのmypy 2.3.1）ではmypyの方が速く、キャッシュありの2回目は0.15秒でした。pyrightの強みは、エディタ内で変更部分だけを再解析する言語サーバーとしての速さにあり、CLIの1回きりの実行では差が出にくいことがあります。CIでは mypyは .mypy_cache をキャッシュ、pyrightは差分ではなく全体を毎回と覚えておくと設計しやすくなります。

VS Code（Pylance）との関係と、スタブ（types-*）の入れ方

VS CodeのPython補完や赤線を出しているPylanceは、pyrightをエンジンにした拡張機能です。設定 python.analysis.typeCheckingMode の既定は off（エラー表示なし）で、basic / standard / strict に上げるとCLIのpyrightと同じ指摘が出ます。プロジェクトに pyrightconfig.json や [tool.pyright] があるとPylanceもそれを読むので、設定をファイルに置けばエディタとCIの結果が揃います。mypyをエディタで使うときはMicrosoft製の拡張「Mypy Type Checker」（ms-python.mypy-type-checker）を入れると、保存時にmypyの指摘が表示されます。

mypy --install-types でスタブを入れる

PyYAMLのように「ライブラリ本体に型情報がなく、typeshedに types-* パッケージがある」ものは、mypyがヒントを出します。

$ mypy load_config.py
load_config.py:1: error: Library stubs not installed for "yaml"  [import-untyped]
load_config.py:1: note: Hint: "python3 -m pip install types-PyYAML"
load_config.py:1: note: (or run "mypy --install-types" to install all missing stub packages)
Found 1 error in 1 file (checked 1 source file)

$ mypy --install-types --non-interactive load_config.py
Installing missing stub packages:
.venv/bin/python3 -m pip install types-PyYAML
Successfully installed types-PyYAML-6.0.12.20260906

Success: no issues found in 1 source file

pyrightは同じファイルで 0 errors でした。pyrightはスタブがなくてもライブラリのソースを読んで推論するため、standardでは何も言わず、strictでは reportMissingTypeStubs として指摘します（types-* が無いライブラリの例）。

$ pyright use_toolz.py    # typeCheckingMode: strict
  use_toolz.py:1:6 - error: Stub file not found for "toolz" (reportMissingTypeStubs)
  use_toolz.py:1:19 - error: Type of "groupby" is partially unknown
    Type of "groupby" is "(key: Unknown, seq: Unknown) -> dict[Unknown, Unknown]" (reportUnknownVariableType)

よくあるつまずきと対処

仮想環境違いは実際に再現できます。toolz を .venv にだけ入れた状態で、仮想環境を有効にせずに実行した出力です。

$ .venv/bin/pyright use_toolz.py        # PATH の python が仮想環境の外
use_toolz.py
  use_toolz.py:1:6 - error: Import "toolz" could not be resolved (reportMissingImports)
1 error, 0 warnings, 0 informations

$ . .venv/bin/activate && pyright use_toolz.py
0 errors, 0 warnings, 0 informations

mypyでは、パッケージを入れる前の結果が .mypy_cache に残っていたために import-not-found が出続け、rm -rf .mypy_cache で import-untyped（本来の指摘）に変わりました。「入れたのに見つからないと言われる」ときは、まずキャッシュを疑うと早く解決します。

新しいチェッカー：ty と pyrefly

2025年以降、Rustで書かれた新しい型チェッカーが登場しています。ty（Astral社。ruff／uvの開発元。PyPI 0.0.84、プレビュー段階）と pyrefly（Meta社。PyPI 1.3.2）で、どちらも pip install ty / pip install pyrefly で入り、ty check / pyrefly check で実行します。同じrichのコードを同じ環境で計ると、tyは0.73秒、pyreflyは0.71秒でした（mypy 3.2秒、pyright 13.9秒）。ただし検出内容や設定項目はまだ変化が大きく、ライブラリ側の対応もこれからなので、現時点では「mypyかpyrightを本線にして、速度が必要なところで試す」位置づけが現実的です。

よくある質問

Q. mypyとpyrightは両方入れるべきですか？ A. 必須ではありません。エディタで使っているもの（VS Codeならpyright）を本線にして、1つに揃えるのが基本です。ライブラリを公開する場合や、両方のユーザーに配慮したい場合に、CIで両方を回す価値が出てきます。この記事の .pre-commit-config.yaml はそのまま両方を実行できます。

Q. Any と Unknown は何が違いますか？ A. Any は「何でも受け入れる」と明示した型で、両方のツールでチェックを通します。Unknown はpyrightだけの呼び方で、注釈がなくて型が決められなかった「暗黙のAny」を指します。strictモードでは Unknown が残ること自体が指摘されるため、注釈を足す場所がわかります。mypyはこの区別をしません。

Q. # type: ignore は最終手段ですか？ A. 段階的な導入では積極的に使って構いません。必ずエラーコードを付け（# type: ignore[union-attr]）、warn_unused_ignores で不要になったものを検出する運用にすると、あとから減らしていけます。コード全体を対象から外す exclude よりも、行単位の方が見通しがよくなります。

Q. Python 3.9のコードもチェックできますか？ A. mypy 2.0以降は --python-version 3.9 をサポートしていません（3.10以上）。3.9向けにチェックしたい場合は mypy 1.20系を使うか、pyrightの pythonVersion = "3.9" を使います。

まとめ

• mypyは「型を1つに決める」ことに厳格、pyrightは「注釈のないコードも推論する」ことに強い。同じサンプルで既定の検出数は7件と9件、strictでは14件と21件
• 分岐後の型は mypyがjoin（object）、pyrightがunion（str | int）。reveal_type() で確かめられる
• 設定は pyproject.toml の [tool.mypy] と [tool.pyright] に集約し、エディタとCIで同じファイルを読ませる
• 段階導入は 「通す → 注釈なしの中身も見る → 新規だけstrict → 全体strict」。抑止は # type: ignore[code] に統一
• pre-commitに mirrors-mypy と pyright-python を入れると、型エラーのあるコミットはローカルで止まる（実行結果つき）
• 実行時間はこの環境で mypy 3.2秒（キャッシュあり0.14秒）、pyright 13.9秒。CIでは .mypy_cache をキャッシュする
• VS CodeのPylanceはpyright。既定の typeCheckingMode は off なので、standard 以上に上げると指摘が見える

株式会社RJCでは、型チェッカーのようなコードの品質を支える道具を、プロジェクトの中で仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。