10月28日、Meta（engineering.fb.com）が「Python Typing Survey 2026: AI Tools and the Shifting Checker Landscape」と題した記事を公開した。回答者の61%がAIを使って型を書き、Stack Overflowへの参照は2年間で半減（46.4%→22.9%）——Python型付けの現場は、ここ2年で劇的に変化した。MetaのPyreflyチームが主導するこのサーベイは1,794件の回答を集めており、AIツールの普及がチェッカー選択や型ヒントの利用実態に与えた影響を詳細に分析している。
サーベイの概要と背景
Pythonタイピングサーベイは3年連続で実施されており、今回の2026年版はMetaのPyreflyチームが主導する形で設計・実施された。1,794件の回答を集め、回答者の76.4%はPython歴5年以上のベテランだ。
なお、このサーベイはMetaが開発する型チェッカーPyreflyのプロモーション文脈と同時期に公開されている。サーベイ自体は幅広い実態調査として設計されているが、主催者がチェッカー競争の当事者でもある点は読む際に留意したい。※編集部の考察
型ヒントの利用頻度自体は3年間ほぼ横ばい（85〜88%）だったが、チェッカーの選択と、AIとの関係性に顕著な変化が現れた。
AIが型を書き、チェッカーエラーを直す
最も変化が大きかったのがAI絡みのデータだ。
「AI生成コードをより正確・信頼できるにするため型ヒントを使う」と答えた割合は、2025年の18.5%から2026年には38.4%へ倍増した。また、42.5%の回答者がAIに型ヒントを書かせており、32.6%はAI生成コードの品質向上目的で型を書いている。AIを使った型関連の4つの活動のうち少なくとも1つを行っていると答えた割合は**61.0%**に達した。
一歩進んで、AIコーディングツールが自動でチェッカーを実行してエラーを修正するワークフローも広がっている。チェッカーの実行方法を回答した1,517人のうち24.4%が「AIコーディングツールがチェッカーを呼び出している」と答えた。そのうち61.6%がAIにチェッカーエラーを修正させており、他の回答者での同率（19.3%）を大きく上回る。
ただし、AIが型を書くことへの懸念も率直に寄せられた。
「AIは手を抜いて何にでも
objectを使うので、AIが書いた型ヒントを直している。」
「
#type: ignoreコメントを乱発する怠惰なコーディングエージェント。」
「型ヒントはAI支援コーディングに役立つか」という問いに対して「よくわからない」と答えた割合は**29.8%**。次に多い「実行時保証」に対する不確実回答（7.7%）の約4倍に達しており、AIと型チェックの関係についてはまだ実証的な知見が乏しい。MetaのPyreflyチームは、この問いに向けてType Checking in Agentic Workflowsと題した発表を2026年のPython Typing Summitで行っている。
チェッカーの勢力図が塗り変わった
型ヒント利用頻度が安定している一方、チェッカーの選択は「はるかに不安定」だったとサーベイは表現する。2024年調査ではこんな声が寄せられていた。
「高速なMypyが欲しい。速度不足がエコシステムの断片化を招き、他のチェッカーはMypyプラグインをサポートせず挙動も異なる。」
2026年になると、Pyrefly（Meta製）やty（Astral製）など新世代のチェッカーが台頭し、チェッカー選択の理由として「速度・パフォーマンス」が56.5%でトップとなった。
複数チェッカーを使い分ける開発者も増加しており、2チェッカー以上を選択した割合は2025年の46.0%から**2026年には49.9%**に上昇した。
実際にどう使い分けているかについて、開発者からは具体的な声が届いている。
「チームメンバーがIDEを統一していないので開発時は複数チェッカーを使うが、リント（ローカル・CI）はMypyで統一している。」
「ローカルではPyrightを使う。Pyrightだけがコードベース内のニッチな型パターンを完全に理解できるから。CI/CDではPyreflyを先に走らせ、Pyreflyが失敗したファイルだけPyrightを実行して速度を稼いでいる。」
複数チェッカーの利用には摩擦もある。複数の静的チェッカーを使っていると答えた738人のうち42.7%がチェッカー間の挙動の不整合を困難として挙げた。
ライブラリの型情報不足が最大の課題
最も多く選ばれた困難は「サードパーティライブラリの型情報が不足している」（65.1%）だった。型スタブが提供されていても、Django・SQLAlchemy・Pydantic・NumPy・pandas・Polarsといったフレームワークやデータサイエンス系ライブラリのデコレータ・メタプログラミング・動的挙動が型チェッカーで正確に表現しきれないという声が繰り返し挙がった。
「Djangoはブラックマジックをやりすぎていて、型チェッカーが動くのが不思議なくらいだ。」
MetaのPyreflyチームはQuansightと協力してpandas-stubsやNumPyへの貢献を進めている。
型ヒントの使用頻度によっても困難の内訳は異なる。型を「頻繁に」使うグループでは70.0%がライブラリ型情報不足を問題視する一方、「たまに」使うグループが最も多く挙げたのは型システムの複雑さ・冗長さ（41.6%）だ。
ミッシングフィーチャーとしてはCallable構文の改善が45.7%でトップとなり、標準化作業の優先候補として挙げられている。
情報源がStack OverflowからLLMと公式ドキュメントへ
情報収集先にも大きな変化が出た。
| 情報源 | 2024年 | 2026年 |
|---|---|---|
| Stack Overflow | 46.4% | 22.9% |
| LLMチャット | 26.0% | 41.7% |
| Pythonタイピングドキュメント | 56.2% | 65.9% |
| チェッカー固有ドキュメント | 52.2% | 60.5% |
Stack Overflowの利用率は2年間で半減した一方、LLMチャットへの移行は明確だ。Stack Overflowが「死んだ」わけではなく、型付けに関する質問においては相対的な存在感が急速に薄れているという状況である。その分、公式ドキュメントやエラーメッセージの質がより重要になる。サーベイは「エラーメッセージに短い説明と例へのリンクを付けること」「LLMに良い情報を提供するためにもドキュメントリンクが有効」と指摘する。
エディタ統合については、82.9%がエディタ上でリアルタイムに型チェックを実行しており、最多エディタはVS Code（59.3%）だった。
サーベイの生データと集計結果はPython Typing Survey 2026のZIPファイルとしてダウンロード可能だ。
詳細はPython Typing Survey 2026: AI Tools and the Shifting Checker Landscapeを参照していただきたい。
