🙌

納期直前、「あの案件のライブラリが競合して動かない！」で絶望したあなたへ

に公開
Python
PowerShell
Windows
Python 3
venv
tech

お疲れさまです、@WinAutoMeister（ウィンオートマイスター）と申します。

このブログではWindows PCとPowerShellしか使えない、DockerやPoetryの導入は許可されないといった開発現場で戦っているエンジニアの皆さんの困りごとを解決することを目的に解説しています。

1. はじめに：納期直前の絶望を5分で終わらせる最強のvenv術

あなたのPCは今、案件のファイルで"密"になりすぎてライブラリの競合が起こっていませんか？
納期直前に「本番環境で動かない！」という絶望を味わうのは現場エンジニアの宿命かもしれません。

この記事ではPythonの仮想環境（venv）をフォルダごとに作成し、ライブラリ競合の悩みを即座に解消する手順を解説しています。

最後に自動で環境を構築するスクリプトを紹介しているので、ぜひ目を通してみてください。

2. 【コピペでOK】案件専用Python環境を3ステップで構築

Windows標準機能だけで完結する最も安全な環境分離の初手を提供します。
またpyenv-winやDockerのような導入が難しいツールを使わず、Pythonに標準搭載されているvenv (仮想環境: Virtual Environment)を使って案件ごとに専用の環境フォルダを作ります。

ステップ1：作業フォルダを作成する

新しい案件用のフォルダをエクスプローラーで作成してください。

例：C:\projects\○○社xx年度システム更改

ステップ2：PowerShellで仮想環境（.venv）を作成する

作成したフォルダ（例：C:\projects\○○社xx年度システム更改）でPowerShellを起動し、次のコマンドで仮想環境を作成します。

python -m venv .venv

案件用フォルダの中に .venv という名前のフォルダが作成され、その案件専用のライブラリを保存する入れ物となります。

コマンド実行後の成功画面

ステップ3：仮想環境を有効化する

仮想環境のフォルダが作成されたら、次に以下のコマンドを実行して有効化します。

.\.venv\Scripts\activate

成功するとPowerShellのプロンプトの先頭に (.venv) のような文字が表示されます。

アクティベート後のプロンプト画面

これでこれからインストールするライブラリはすべてこの.venvフォルダ内に閉じ込められ、他の案件やPC本体のPython環境に一切影響を与えません。

応用：必要なライブラリのインストール

有効化された環境でコードに必要なライブラリを追加インストールします。

プロジェクトでrequirements.txtが整備されている場合はそちらからインストールしてください。

例：requests ライブラリをインストールする場合

pip install requests

3. 最強の安心材料：「フォルダごと消せる」という解放感

なぜこのvenvを使った環境分離が最強の安心材料になるのでしょうか？

それはプロジェクトの成果物と開発環境が完全に独立した「フォルダ」にまとまるからです。

案件が完了した際に、もう二度と使うことのないライブラリや設定ファイルをまるでゴミ箱に捨てるように安心して削除できます。

PC全体に散らばったライブラリを一つずつ手作業でアンインストールする必要はありません。

このシンプルさがあなたの開発環境を常にクリーンに保ち、ライブラリの競合からくる「謎の不具合」に悩まされる時間から解放してくれます。

現場での無駄な消耗を減らし、残業時間を減らすための最も確実な手順の一つです。

4. 残業を半分にするなら：【ワンクリック時短ツール】Powershellスクリプト

これでライブラリ競合の悩みは解消しました。

しかし案件のたびにこれらの手作業を繰り返すのは面倒ですよね？

  1. フォルダを作る
  2. PowerShellを起動する
  3. 仮想環境をコマンドで作成する(python -m venv .venv)
  4. 仮想環境をアクティベートする(.\.venv\Scripts\activate)

そう思ってこれらの手順1・2・3の面倒な手作業を全て自動化できるワンクリック時短ツールを用意しています。

次のコードをcreate_venv.ps1 (文字コードはSJIS)で保存、右クリック→「powershellで実行」しましょう。

プロジェクト名を入力すればデスクトップに案件フォルダと仮想環境が自動で作成されます。

作成後はデスクトップの案件フォルダごと好きなフォルダに移動すればOKです。

# 実行ポリシーを一時的に変更
Set-ExecutionPolicy RemoteSigned -Scope Process

# デスクトップに作るProjectsフォルダのパス
$ProjectsPath = [System.Environment]::GetFolderPath('Desktop') + "\Projects"

# Projectsフォルダがなければ作成
if (-not (Test-Path $ProjectsPath)) {
    New-Item -ItemType Directory -Path $ProjectsPath
}

# フォルダ名を入力してもらう
$ProjectName = Read-Host "プロジェクト名（フォルダ名）を入力してください"
$NewProjectPath = Join-Path $ProjectsPath $ProjectName

# フォルダを作成して、その中に移動
New-Item -ItemType Directory -Path $NewProjectPath
Set-Location $NewProjectPath

# 仮想環境（.venvフォルダ）を作成
python -m venv .venv

Write-Host ""
Write-Host "✅ デスクトップの`Projects`フォルダ内に、$ProjectName フォルダと仮想環境を作成しました。" -ForegroundColor Green
Write-Host "次のコマンドで仮想環境を有効にしてください:" -ForegroundColor Yellow
Write-Host "cd $NewProjectPath"
Write-Host ".\.venv\Scripts\activate"

# PowerShellの画面を閉じないように待機
Read-Host "Enterキーを押すと終了します"

スクリプト実行後のプロンプト画面

5. 【予告】現場エンジニアの「本当の消耗」を解消する次の一手

ここまででライブラリの競合からくる「謎の不具合」から解放されました。開発環境はクリーンに保たれ、精神的な負担も大きく減っているはずです。

しかし現場エンジニアの消耗は「環境構築の繰り返し」だけではありません。

  • プロキシ・ファイアウォールの壁: 仮想環境の作成を自動化したものの、開発現場特有の厳重なプロキシ設定のせいでpip installが通らずに何時間も解説サイトや設定ファイルを往復した経験はありませんか？
  • チーム標準化の消耗: 新規プロジェクトのたびに初期ライブラリのバージョンや開発ツールの設定をメンバー全員が手動で合わせるという誰も幸せにならない作業に時間を使っていませんか？

これらの現場特有の、見えない消耗こそが、あなたの残業を決定づけている真の原因です。

現場のエンジニアがコードを書くことだけに集中できるための究極のツールを準備中です。

Discussion