🐋

AIコーディング時代に、Python開発環境を整えるためにやったことまとめ

に公開

はじめに

AIコーディングツール(Codex, Claude Code)を使うようになってから、小さなPythonプロジェクトを作って試す機会が増えました。何度も試行錯誤する中で、個人開発でも取り回しやすいPython開発環境の形が少しずつ見えてきました。

これまで uv、Ruff、pyright、pytest、pre-commit などについて個別に記事を書いてきました。それらをまとめた記事になっています。詳細の内容はリンクから参照いただければと思います。

開発環境の考え方

具体的な構成に入る前に、Python開発環境をどう整えるかについては、以前こちらの記事に書きました。

https://zenn.dev/zaspa/articles/fd6fb521df88f6

個人開発では、小さなプロジェクトを作って試すことが多くあります。そのたびにフォーマッター、リンター、型チェック、テスト、依存関係管理などを毎回手作業で整えていると、環境構築自体が少しずつ面倒になります。

そのため、最低限必要な開発環境をセットで揃え、簡単に再現できる状態にしておくことが大事だと考えています。この記事では、その考え方をもとに、自分が使っているPython開発環境の構成を紹介します。

全体像

やりたいこと 使うもの 詳細記事1 詳細記事2
Python環境と依存関係を管理する uv 記事リンク 記事リンク
コードの書き方を揃える Ruff 記事リンク 記事リンク
よく使うコマンドをまとめる Taskfile 記事リンク 記事リンク
型のズレに気づく pyright 記事リンク
動作を確認する pytest 記事リンク
コミット前に確認する pre-commit 記事リンク
設定を使い回す Copier 記事リンク

1. uvでPython環境と依存関係を管理する

Pythonプロジェクトの土台として、Pythonバージョン管理と依存関係管理には uv を使っています。

uv を使うと、Pythonのインストール、仮想環境の作成、依存関係の同期をまとめて扱えるため、小さなプロジェクトを何度も作るときの手間を減らせます。

基本的な構成については、RuffTaskfile とあわせてこちらの記事に書きました。

https://zenn.dev/zaspa/articles/3cc9a01f0d69f6

Docker化する場合の構成はこちらです。

https://zenn.dev/zaspa/articles/e3abf2cf19a5e3

モノレポ構成での注意点もまとめています。

https://zenn.dev/zaspa/articles/484f0a74a416b4

2. RuffでLint / Formatを揃える

コードの書き方を毎回手で揃えるのは面倒なので、Lint と Format には Ruff を使っています。

Ruff を使うと、Pythonコードのチェック、importの整理、フォーマットをまとめて扱えます。個人開発でも、保存時やコマンド実行時に自動で整えられるようにしておくと、細かい書き方で迷う時間を減らせます。

uvTaskfile と組み合わせた基本的な構成については、こちらの記事に書きました。

https://zenn.dev/zaspa/articles/3cc9a01f0d69f6

また、VS Code上で保存時にRuffを実行する設定については、こちらの記事にまとめています。

https://zenn.dev/zaspa/articles/95580ba7c0c867

3. Taskfileでよく使うコマンドをまとめる

開発中によく使うコマンドは、Taskfile にまとめています。

たとえば、RuffによるLint / Format、pyrightによる型チェック、pytestによるテストなどを、それぞれ毎回コマンドで覚えて実行するのは少し面倒です。Taskfile にまとめておくと、task checktask test のような短いコマンドで実行できるようになります。

uvRuff と組み合わせた基本的な構成については、こちらの記事に書きました。

https://zenn.dev/zaspa/articles/3cc9a01f0d69f6

また、Taskfile を使ってPython開発でよく使うコマンドを整理する考え方については、こちらの記事にまとめています。

https://zenn.dev/zaspa/articles/716cf1b85472f2

4. pyrightで型チェックする

型チェックには pyright を使っています。

Ruff ではコードの書き方は揃えられますが、引数や戻り値の型のズレ、None の扱いなどは型チェックで確認する必要があります。個人開発では最初から厳しくしすぎず、まずは standard くらいから始めると使いやすいと感じました。

Pyright の導入方法や pyproject.toml の設定については、こちらの記事にまとめています。

https://zenn.dev/zaspa/articles/143098a39ad279

5. pytestで小さくテストする

動作確認には pytest を使っています。

Pyright で型のズレには気づけますが、実際に期待どおり動くかはテストで確認する必要があります。個人開発では、小さな関数やロジックから少しずつテストを書いておくと、後から変更するときに安心しやすくなります。

pytest の導入や、pre-commit と組み合わせる設定についてはこちらにまとめています。

https://zenn.dev/zaspa/articles/0854e523e4cf3f

6. pre-commitでコミット前に確認する

コミット前の確認には pre-commit を使っています。

RuffPyrightpytest などを手動で実行していると忘れることがあるため、コミット前に自動で確認できるようにしておくと安心です。

現時点では、pytest と組み合わせた例をこちらの記事で紹介しています。

https://zenn.dev/zaspa/articles/0854e523e4cf3f

今後、pre-commit 単体の構成についても別記事で整理する予定です。

7. Copierで設定を使い回す

uvRuffTaskfilePyrightpytest などを揃えても、新しいプロジェクトを作るたびに同じ設定をコピペするのは面倒です。

そこで、よく使う構成を Copier でテンプレート化しています。

テンプレート化しておくと、最低限の開発環境をまとめて再現しやすくなり、新しいプロジェクトを始めるときの手間を減らせます。

Copierを使ったPythonプロジェクトの初期設定については、こちらの記事にまとめています。

https://zenn.dev/zaspa/articles/adf4230e859665

おわりに

個人開発では、小さなプロジェクトを何度も作るからこそ、最低限の開発環境を最初から揃えておくと扱いやすくなります。フォーマッター、リンター、型チェック、テスト、依存関係管理などをセットで用意し、再現しやすくしておくことで、環境構築の手間を減らせると感じています。

今後も、実際に使ってよかった構成や改善点があれば、この記事に追記していきます。

Discussion