はじめに
「ちょっとしたアイデアを試してみたい」と思ったとき、どのように開発を始めるでしょうか。
おそらく「とりあえず書いてみる」というのが一般的だと思います。生成AIの活用が浸透した現在では、より「試しに書かせてみる」ということがやりやすくなりました。
一方でそのように自動的なコード生成をしているからこそ、同じ言語を使っているのに微妙な差異がプロジェクトごとに発生して、そのコンテクストスイッチが発生することになります。
自分用のテンプレートを持つメリット
この問題を解決するのが「自分用のテンプレートを持っておく」というアプローチである、というのが現在の考えです。
自分用のテンプレートをつくることで、毎回同じ水準の環境をベースにコアロジックの作成に没頭できます。
また生成AIの発達によって、この環境構築は数時間もあれば完了します。自身がどのような環境を欲することが多いかを理解してさえいれば、ツールの選定や詳細な設定はその場で選択できるでしょうし、違和感があれば最初から作りなおすことも可能です。
なおこの点については、以下のnote記事にも書いています。
本記事の位置づけ
以上が主張となりますが、本記事では私が個人開発用に準備している環境設定を紹介します。
ただし、この記事の内容をそのままコピー＆ペーストすることはおすすめしません。この設定は私の好みや用途に最適化されたものであり、ベストプラクティスではないからです。
それよりも生成AIを使って「ruffの設定を追加して」「GitHub ActionsにCI/CD環境がほしい」などと対話しながら作ったほうが自身のツールとして活用できるでしょう。
つまり以下は「正解の設定集」ではなく、「自分用テンプレートを作るときの参考資料」として読んでください。紹介する項目を見て「自分のテンプレートには何が必要か」を考え、生成AIと一緒に構築できれば十分かと思います。
※本テンプレートは個人開発、とくにローカル環境に閉じた開発がメインであり、セキュリティ面は最低限の考慮に留めています。
サンプル
私のテンプレートは以下で公開しています。参考になれば幸いです。
【重要】ワンコマンドでプロジェクトを開始できるようにする
テンプレートを作る目的は「思いついたらすぐに開発を始められる」ことです。そのためにはテンプレートを簡単に展開できる仕組みが必要になります。
私のテンプレートでは、install.shというシェルスクリプトを用意しています。たとえば以下のコマンドを実行するだけで、新しいプロジェクトが作成されます。
# 任意のディレクトリ下にプロジェクトが作成される
curl -fsSL https://raw.githubusercontent.com/koboriakira/python-project-2026/main/install.sh | sh -s my-project
このスクリプトが行っていることは、GitHubからテンプレートをダウンロードし、プロジェクト名を一括置換し、依存関係をインストールするという一連の流れです。
このような仕組みを用意しておくことで、アイデアを思いついてから実際にコードを書き始めるまでの時間を最小化できます。テンプレートの中身をどれだけ充実させても、展開に手間がかかるようでは本末転倒です。
環境設定
以下では、このテンプレートに含めている環境設定を紹介していきます。
1. パッケージ管理
現在の最新のパッケージ管理だろうuvを採用しています。依存関係、開発用ツール、ビルド設定などが一箇所にまとまるため、プロジェクトの見通しがよくなるかと思います。
2. コードフォーマット
Ruff(ruff format)を使っています。行の長さやクォートのスタイルは好みで変更すればよいでしょう。重要なのは何を選ぶかではなく、一貫したルールが自動適用される状態を作ることです。
3. リンター
同じくRuff(ruff check)を使って、複数のリンターの機能を統合しています。私のテンプレートでは以下のようなルールセットを有効にしています。
どのルールを有効にするかは好みによりますが、生成AIに「Pythonのリンターでおすすめのルールセットを教えて」と聞けば、用途に応じた提案が得られるでしょう。
4. 型チェック
私のテンプレートではmypyを採用しています。
Pythonは動的型付け言語ですが、型ヒントを活用することで実行前にエラーを検出できるようになります。型のない既存コードに後から型を付けるのは膨大な作業になるため、最初からstrictモードで始めておき、必要に応じて緩和していくのがよいかなと思います。
5. テスト環境
私のテンプレートではpytestを使い、カバレッジ測定も組み込んでいます。
6. API基盤
Web APIを提供する可能性が少しでもあるなら、最初からAPIの基盤を用意しておくと後から追加する手間が省けます。あらかじめ準備しておいたうえで「使わないなら破棄すればよい」という考えでやっています。
私のテンプレートではFastAPIを採用しています。Pythonの型ヒントをそのままAPIのスキーマとして活用できるため、型チェックとAPIドキュメントが自然に連動します。
また開発環境と本番環境で挙動を変える仕組みも入れており、Swagger UIの有効化やCORSの設定を制御しています。このあたりは本番環境にデプロイする場合はとくに見直す必要がありますが、切り替えの仕組み自体は最初から入れておくとよいでしょう。
7. フロントエンド基盤
管理画面やシンプルなUIが必要になることがあります。ReactやVueを導入するほどではないが、静的HTMLでは物足りないという場面です。
このあたりはまったく理解せずに入れてしまっている段階ですが、私のテンプレートではHTMXとJinja2を組み合わせています。
本格的なフロントエンド開発が必要になればReact等に移行してもよいですが、個人開発の初期段階ではHTMXで十分なケースが多そうな印象をもっています。
8. CI/CD
継続的インテグレーションを設定しておくと、「自分の環境では動く」という問題を防げます。プルリクエストを出すたびにテストやリンターが自動実行されるため、品質を一定に保てます。
私のテンプレートではGitHub Actionsを使い、複数のOSとPythonバージョンでテストを実行しています。
従来の個人開発であれば、このあたりの整備をサボることも多かったはずです。しかし、ただ一度設定してしまえばあとは使いわませるため、テンプレートに含めるべきです。不要なら消せばいいのですから。
9. リリース管理
バージョン番号の更新、CHANGELOGの作成、GitHubリリースの作成といった作業を手動で行うと、リリースのたびに時間を取られます。自動化しておけばコミットするだけでリリースが完了します。
私のテンプレートではrelease-pleaseを使っています。Conventional Commitsという規約に従ったコミットメッセージを書くと、それに基づいてバージョンが自動決定されます。
git commit -m "fix: バリデーションエラーを修正" # パッチバージョン
git commit -m "feat: 新しいエンドポイントを追加" # マイナーバージョン
git commit -m "feat!: APIのレスポンス形式を変更" # メジャーバージョン
mainブランチにマージされるとrelease-pleaseがリリース用のプルリクエストを自動作成し、そのPRをマージするとGitHubリリースとCHANGELOGが生成されます。
個人開発でここまで必要かは判断が分かれるところですが、これも同様に「いらないなら消せばいい」の発想で追加しています。意外とライブラリとして公開する可能性もあるものです。
10. ClaudeのCommand, hooks, Skillsなど
ここは~/.claude以下を整備するべきかもしれませんが、とりあえず入れておいても問題はないかなと現在は判断しています。
ある程度一貫した指示書が作れると、具体の各プロジェクトで指示を出すときに楽となることが多いです。
ちなみにその他だと、まだ実現できていないのですが、Pythonファイルの配置に関するディレクトリ構造やレイヤー、ドメイン駆動で行うことの宣言など、ある程度不変として扱ってよい開発スタイルについて含めておくのも有効ではないかと考えているところです。
まとめ
私が個人開発用のテンプレートに含めている環境設定を紹介しました。
繰り返しになりますが、これらをそのまま使う必要はありません。重要なのは「自分がどのような環境を欲しているか」を把握し、それをテンプレートとして持っておくことです。
生成AIを活用すれば、こうしたテンプレートは数時間で構築できます。一度作ってしまえば、新しいアイデアを思いついたときにすぐコアロジックの実装に取りかかれます。