AI 時代に学ぶ好きなルール・嫌いなルール Linter 編
皆さんは ruff の PGH003 (# type: ignore にエラーコードを強制するルール) を使っていますか？
AI が # type: ignore を安直に書いてくる今、これは AI 時代に必要不可欠ではないでしょうか？
AI が日常的にコードを書くようになった今、Linter の役割そのものは変わらないものの、ルール選定の判断軸は変わってきていると考えています。
AI がコードを書くようになる前、Linter は主に人間のミスを防ぐガードレールとして機能してきました。Typo や未使用変数、命名規則、複雑度メトリクスといったこれらのチェックは、基本的には人間がコードを書くことを想定されたルールだと思います。
しかし AI 時代に入った今、状況は変わってきていると思っており、AI は形式は完璧に守る一方で、難しい判断は安直に逃げる傾向があると感じます。AI はタイポや命名規則違反はしない一方で、# type: ignore の安直な追加や、Any 型で型推論を省くパターンを何度か目にしました。そのため Linter についても、ガードレールとしてどんなルールを ON / OFF にすべきかという判断軸の見直しが迫られていると感じます。
ここでは、Python の Linter エコシステム (ruff / mypy など) を題材に、そのルール体系をざっくり捉えた上で、AI 時代の前と後で Linter のルール選定がどう変わるかについて、自分の意見を話せたらと思います。
具体的には、下記について話したいです。
(1) Linter (ruff / mypy など) のルール体系の概観
(2) AI 時代の前後における Linter の役割の変遷
(3) AI 時代に重要度が上がるルール
(4) AI 時代に意味が薄れるルール
このトピックに関するあなた自身の経験を教えてください
業務では ruff や mypy といった Linter を運用しています。ruff はルールを全て有効にしたうえで個別に不要な設定を除外していく形で運用し、除外する設定については除外する理由をコメントに残す形にしています。
また、現職では Claude Code を使用しています。Claude Code が参照する AGENTS.md には、チームの規約として、# type: ignore や # noqa でチェックによる警告を抑制するようなやり方を基本的に禁止する記載を入れていて、コード側で適切な形を取ることを徹底しています。これにより適切な型アノテーションの付与を促し、型安全なコードを実装しています。
Claude Code や Codex といった AI を用いてコードを書くことが一般的な昨今、人間がコードを書く前提で設定されたルールやエコシステムについて、AI に合わせた調整が必要だと考えたため、このプロポーザルを提案しました。
この発表を通じて、参加者とどんな議論が可能ですか？
例えば、下記のような討議ができるといいなと思っています。
(1) そもそも人間がコードを書く場合、AI がコードを書く場合で Linter のルールを調整すべきなのか？ 同じような問題意識を感じているか？ といった根本的な部分
(2) 仮に Linter ルールの調整が必要だとすれば、どのようなルールの重要性が変わるのか？ それは自分が考えているものと同じ方向性なのか、違うのか
(3) AI によって調整すべきルールが変わるのか？ Cursor / Claude Code / Codex / GitHub Copilot で何らかの傾向が存在するのか
(4) Linter だけでなく、安全で堅牢なコードを AI が書けるようにするためにどんな施策が考えられるか (例えば Claude Code の AGENTS.md のような)
これまでバックエンド・インフラエンジニアとして開発に従事してきました。
通信会社系 SIer で、関連研究所の研究内容に関する PoC 作成や、事業会社向け開発に従事し、AWS を中心としたクラウドインフラ構築・運用、Python / Java による開発、IaC 化や CI/CD によるテスト自動化、セキュリティ基準への準拠や性能改善などに取り組みました。
また、スクラムマスターとしてアジャイル開発を推進したり、社内研修の企画・実施を通じて組織の開発力強化にも携わってきました。
2025 年 10 月に株式会社 Recustomer に入社し、現在はバックエンドエンジニアとして、Python による Hexagonal Architecture + DDD をベースとした型安全な実装、堅牢な開発に取り組んでいます。