昔のCGI世代がドン引き！驚愕の今どき開発環境｜Python仮想環境 / uv / npmの全体像

20年ぶりに開発現場へ戻ってきて、一番驚いたのはAIではありませんでした。

もちろん、AIにも驚いています。エラーを貼れば説明してくれる。コードを見せれば、どこを直せばよいか一緒に考えてくれる。昔なら本を開き、検索し、ログを読み、数時間かけて調べていたことを、今はかなり短い時間で整理できます。

でも、PythonやWeb開発を少しずつ触り始めて、最初に本当に「時代が変わったな」と感じたのは、実はAIそのものではありません。

仮想環境でした。

昔の感覚で言うと、開発環境というのはかなり重たいものでした。サーバー全体に何かを入れる。パスを通す。ライブラリの場所を気にする。バージョンが合わない。設定ファイルを見る。うまく動かないとログを見る。

ところが今は、どうやら考え方がかなり違うようです。

• プロジェクトごとに環境を分ける
• 必要なライブラリをそのプロジェクトにだけ入れる
• 環境の状態をファイルで管理する
• 別のPCでも同じ環境を再現しやすくする
• コマンドひとつで必要なものを揃える

この考え方を知ったとき、私はかなり驚きました。

「え、開発環境ってこんなに変わってたの？」

この記事では、昔CGIやUNIXを触っていた人間の視点から、今どきの開発環境の全体像を整理してみます。細かいコマンドの完全解説ではありません。まずは、Pythonの仮想環境、uv、Node.jsの npm、npx が、全体としてどういう考え方なのかをつかむことを目的にします。

昔の開発環境は、サーバー全体を触る感覚だった

昔、CGIやPerl、初期のPythonなどを触っていたころは、開発環境というより、サーバーそのものを触っている感覚が強かったように思います。

たとえば、Webで何かを動かそうとすると、Apacheの設定を見たり、cgi-bin の場所を確認したり、スクリプトのパーミッションを変えたり、ファイルの先頭に #!/usr/local/bin/perl や #!/usr/local/bin/python のような shebang を書いたりしていました。

今思い返すと、やっていることはかなりシステム寄りです。

• Webサーバーの設定
• 実行権限
• パス
• ライブラリの場所
• ログ
• 文字コード
• Internal Server Error

プログラムを書く前に、そもそも動く場所を作るところで力を使っていました。

もちろん、それはそれで勉強になりました。環境がどう動いているのかを身体で覚えるには、昔のやり方にも意味がありました。ただ、久しぶりに戻ってきた人間からすると、当時の感覚のまま今のPythonやWeb開発を見ようとすると、最初に少し混乱します。

なぜなら、今は「サーバー全体に何かを入れて、そこで全部を動かす」という感覚ではなく、プロジェクトごとに専用の環境を持つという考え方がかなり中心になっているからです。

今はプロジェクトごとに専用の工具箱を持つ時代

仮想環境という言葉を最初に聞いたとき、私は少し構えてしまいました。

「仮想」と言われると、仮想マシンやDockerのようなものを想像してしまいます。何か大げさなものを起動して、その中に別のOSがあって、というイメージです。

でも、Pythonの仮想環境でまず理解すべきことは、そこまで大げさな話ではありません。

ざっくり言えば、プロジェクトごとに専用の工具箱を持つということです。

昔は、家族みんなで一つの工具箱を使っているような感覚でした。

• 誰かが新しい工具を入れる
• 誰かが古い工具を入れ替える
• どの工具がどの作業で必要だったのか分からなくなる
• ひとつ壊すと、ほかの作業にも影響する

これが、PCやサーバー全体にライブラリを入れている状態に近いと思います。

一方、今の仮想環境はこうです。

• AプロジェクトにはA専用の工具箱
• BプロジェクトにはB専用の工具箱
• Aで使う工具はAの箱に入れる
• Bで使う工具はBの箱に入れる
• 片方を変えても、もう片方に影響しにくい

この考え方を知ると、仮想環境のありがたさが少し見えてきます。

Python公式ドキュメントでも、venv はそれぞれ独立したPythonパッケージを持つ軽量な仮想環境を作る機能として説明されています。つまり、プロジェクトごとに依存パッケージを分けるための標準的な仕組みです。

昔の感覚で戻ってきた人間からすると、これはけっこうな革命です。

Pythonの世界：venv、uv、pyproject.toml

Pythonの世界でよく出てくるのが、venv、uv、pyproject.toml です。

最初は、名前だけで少し混乱します。

venv
uv
pyproject.toml

どれも見慣れません。

ただ、役割をざっくり分けると、少し理解しやすくなります。

venv は仮想環境を作る標準機能

venv は、Python標準の仮想環境作成機能です。

たとえば、あるプロジェクトでだけ pandas や streamlit を使いたいとします。そのとき、PC全体に直接入れるのではなく、そのプロジェクト専用の環境を作り、その中に必要なパッケージを入れます。

よく見る流れは、たとえばこうです。

python -m venv .venv

これで .venv という仮想環境を作ります。

そのあと、環境を有効化して、必要なパッケージを入れます。

pip install pandas
pip install streamlit

昔の感覚だと、pip install はPC全体に何かを入れてしまうようで少し怖く感じます。でも仮想環境の中で実行していれば、そのプロジェクト専用の環境に入るので、影響範囲が限定されます。

これが重要です。

ライブラリを入れること自体が怖いのではなく、どこに入るのかを分けられるようになったということです。

uv はPython環境管理をかなりまとめてくれる道具

最近触って驚いたのが、uv です。

uv は、Astralが開発しているPythonのパッケージ・プロジェクト管理ツールです。公式ドキュメントでは、高速なPython package and project manager と説明されています。

これを昔の感覚で見ると、かなり不思議です。

たとえば、以前なら次のようにいろいろ意識していたことがあります。

• Pythonのバージョン
• 仮想環境
• パッケージのインストール
• 依存関係
• 実行コマンド
• 開発用ツール

uv は、このあたりをかなりまとめて扱えるようにしてくれます。

たとえば、プロジェクト内でStreamlitを使いたければ、次のように追加できます。

uv add streamlit

そして実行するときは、次のようにできます。

uv run streamlit run app.py

この uv run が、昔の感覚からするとけっこう衝撃でした。

「そのプロジェクトの環境の中で実行する」ということを、コマンドとして自然に表現できるからです。

昔は、パスがどうなっているか、どのPythonを呼んでいるか、どこにライブラリが入っているかをかなり気にしていました。今も本当は理解したほうがよいのですが、少なくとも最初の一歩としては、uv run によってかなり扱いやすくなっています。

pyproject.toml はプロジェクトの設定ファイル

pyproject.toml も最初は謎でした。

昔なら、Pythonの依存関係というと requirements.txt のイメージがありました。そこに必要なライブラリを書いておき、別の環境で pip install -r requirements.txt と実行する。

今でも requirements.txt は使われますが、最近のPythonプロジェクトでは pyproject.toml がよく出てきます。

ざっくり言えば、プロジェクトの設定や依存関係を書くファイルです。

細かい仕様は今後ゆっくり見ていくとして、最初はこう理解しています。

Pythonプロジェクトの説明書のようなもの

どのパッケージが必要なのか。
どんなツールを使うのか。
どういうプロジェクトなのか。

そういった情報を、プロジェクト側に持たせる考え方です。

ここでもやはり大事なのは、環境を個人のPC任せにしないということです。プロジェクトに必要な情報をファイルとして持たせることで、別のPCでも再現しやすくなります。

Web / Node.jsの世界：npm、package.json、node_modules、npx

Python側に venv や uv がある一方で、WebやNode.jsの世界には npm、package.json、node_modules、npx があります。

これも最初はかなり混乱します。

npm
package.json
node_modules
npx

名前が多いです。

ただ、考え方としてはPythonの仮想環境や依存管理にかなり似ている部分があります。

npm はNode.jsのパッケージ管理ツール

npm はNode.jsの世界でよく使われるパッケージ管理ツールです。npm公式ドキュメントは、npm registry、Webサイト、CLIに関する情報を提供しています。

たとえば、Webアプリのプロジェクトを見ていると、よくこういうコマンドが出てきます。

npm install
npm run dev

最初に見たときは、正直よくわかりませんでした。

「何を install しているのか」
「run dev とは何を動かしているのか」
「どこに何が入るのか」

昔の感覚だと、またPC全体に何かを入れてしまうのではないかと少し不安になります。

でも、基本的にはそのプロジェクトに必要なパッケージを node_modules に入れ、package.json に書かれたスクリプトを実行している、と考えると少し見えてきます。

package.json はNode.jsプロジェクトの説明書

Node.jsの世界で、Pythonの pyproject.toml に少し近い役割を持つのが package.json です。

npmの公式ドキュメントでは、package.json はパッケージ情報を書くJSONファイルとして説明されています。また、依存パッケージやスクリプトなど、プロジェクトに関わる情報を持つファイルとして使われます。

ざっくり言えば、これもプロジェクトの説明書です。

• このプロジェクトの名前
• 必要なライブラリ
• 開発時に使うコマンド
• ビルドするときのコマンド
• 実行するときのコマンド

こうした情報が入っています。

Pythonで pyproject.toml を見るように、Node.jsでは package.json を見る。
そう考えると、少し落ち着きます。

node_modules はプロジェクト用の部品置き場

npm install を実行すると、node_modules というディレクトリができます。

最初に見ると、かなり巨大で驚きます。

「こんなに大量のファイルが入って大丈夫なのか」

と思います。

でも、これはそのプロジェクトで使うJavaScriptのパッケージ群です。Pythonで仮想環境の中にライブラリを入れるのと同じように、Node.jsではプロジェクト内の node_modules に依存パッケージが入ります。

つまり、ここでも考え方は似ています。

プロジェクトに必要な部品を、そのプロジェクトの近くに置く

昔のように、サーバー全体やPC全体に何でも入れてしまうのではなく、プロジェクトごとに必要なものを管理するわけです。

npx は一時的にコマンドを実行する感覚

npx も最初はよくわかりませんでした。

npm公式ドキュメントでは、npx はnpmパッケージ由来の任意のコマンドを実行するためのコマンドとして説明されています。

ざっくり言えば、パッケージに含まれるコマンドを実行するための仕組みです。

たとえば、何かの開発ツールを一時的に実行したいときに出てきます。昔の感覚だと、コマンドを使うにはまずグローバルにインストールして、パスを通して、という発想になりがちです。

でも今は、必ずしもそうではありません。

必要なときに、そのプロジェクトの文脈でコマンドを実行する。
これも、かなり今どきの考え方だと感じました。

PythonとNode.jsは、考え方がかなり似てきている

PythonとNode.jsは別の世界です。

PythonにはPythonの文化があり、Node.jsにはNode.jsの文化があります。コマンドも違います。設定ファイルも違います。パッケージの置き場所も違います。

でも、今どきの開発環境として見ると、考え方はかなり似ています。

目的	Python側	Node.js側
プロジェクト設定	pyproject.toml	package.json
依存関係の管理	uv add / pip install	npm install
パッケージ置き場	.venv など	node_modules
コマンド実行	uv run	npm run / npx
環境の再現	lockfile / 設定ファイル	package-lock.json など

もちろん完全に同じではありません。細かい仕組みは違います。

ただ、昔の感覚で戻ってきた人間にとって大事なのは、まずここです。

どちらも、プロジェクトごとに必要なものを管理し、同じ環境を再現しやすくする方向に進んでいる

この全体像が見えると、uv や npm という名前への抵抗感が少し下がります。

GitHubから持ってきて動かす流れも変わった

昔、他人のプログラムを動かすのはなかなか大変でした。

ソースコードを持ってくる。
必要なライブラリを調べる。
バージョンを合わせる。
設定ファイルを読む。
パスを直す。
エラーを見る。

かなりの作業です。

今でも簡単とは言いません。でも、プロジェクト側に環境情報がまとまっていると、流れはかなり整理されます。

Pythonなら、たとえばこういう流れになります。

git clone <repository-url>
cd <project>
uv sync
uv run python app.py

または、Streamlitならこうです。

uv run streamlit run app.py

Node.jsなら、よく見る流れはこうです。

git clone <repository-url>
cd <project>
npm install
npm run dev

もちろん、実際にはプロジェクトごとに差があります。OSの違い、PythonやNode.jsのバージョン、外部サービスの設定などで詰まることもあります。

それでも、昔と比べると大きく違うのは、必要な情報をプロジェクト側に持たせる文化が強くなっていることです。

これはありがたいです。

昔は、環境構築そのものが職人芸のようなところがありました。今も職人芸は残っていますが、少なくとも「再現しやすくする」方向にかなり進んでいるように感じます。

AI時代は、環境構築の学び方も変わった

ここにAIが加わると、さらに状況が変わります。

昔は、環境構築で詰まると、エラーメッセージを見て、検索して、英語の掲示板を読んで、ドキュメントを読んで、試して、また失敗していました。

今は、エラーをAIに貼れます。

たとえば、こういうエラーが出たとします。

ModuleNotFoundError: No module named 'streamlit'

このとき、AIに聞けます。

このエラーは何ですか？
初心者向けに説明してください
次に確認すべきことを教えてください

実際に私も、Streamlitを動かそうとして command not found や Failed to spawn に遭遇しました。そのときも、AIに聞きながら uv add streamlit を実行し、uv run streamlit run app.py で動かすところまで進めました。

昔なら、ここでかなり時間を使っていたと思います。

もちろん、AIの答えをそのまま信じるのは危険です。環境に関わるコマンドは、何をしているのか理解しながら実行する必要があります。

でも、AIは「次に何を見るべきか」を整理してくれます。

これは大きいです。

昔は、こうでした。

環境構築
↓
調査
↓
実装

今は、少し違います。

git clone
↓
uv sync / npm install
↓
エラーが出る
↓
AIに聞く
↓
直す
↓
実装に進む

完全に楽になったわけではありません。
でも、孤独感はかなり減りました。

まず覚えるべき全体像

ここまで見てきて、昔のCGI世代がまず押さえるべき全体像は、たぶんこれです。

1. PC全体ではなく、プロジェクト単位で考える

今どきの開発環境では、PC全体に何でも入れるのではなく、プロジェクトごとに必要なものを管理する考え方が中心です。

Pythonなら仮想環境。
Node.jsなら node_modules や package.json。

細かい仕組みは違っても、基本は似ています。

2. 必要なものは設定ファイルに書く

Pythonなら pyproject.toml。
Node.jsなら package.json。

プロジェクトに必要なライブラリやコマンドを、設定ファイルとして持たせます。

これにより、別のPCや別の人が同じ環境を再現しやすくなります。

3. 実行もプロジェクトの文脈で行う

Pythonなら uv run。
Node.jsなら npm run や npx。

どの環境で、どのコマンドを実行しているのかを意識することが大事です。

4. AIに聞きながら進められる

エラーが出ても、昔のように一人で何時間も悩む必要は少なくなりました。

エラーを貼る。
状況を説明する。
次に見る場所を聞く。

これだけでもかなり進みやすくなります。

5. でも、魔法ではない

仮想環境も、uv も、npm も、AIも、魔法ではありません。

仕組みをまったく理解しなくても大丈夫、という意味ではありません。むしろ、何がどこに入るのか、どの環境で動いているのかを少しずつ理解することは重要です。

ただ、昔よりも安全に試しやすくなった。
壊しても戻りやすくなった。
エラーを相談しやすくなった。

そこが大きいと思います。

20年前の自分に言いたいこと

20年前の自分に言うなら、たぶんこうです。

「今は、環境を丸ごと壊しながら覚える時代ではないらしいぞ」

昔は、何かを入れるたびに少し怖さがありました。

パスが変わる。
ライブラリが上書きされる。
別のプログラムが動かなくなる。
サーバー全体に影響する。

もちろん、今でも環境構築で詰まることはあります。でも、プロジェクトごとに環境を分ける考え方を知ると、かなり気が楽になります。

仮想環境は、初心者を難しくするためのものではなく、むしろ守るためのものなのかもしれません。

uv や npm も、最初は呪文に見えます。

uv run streamlit run app.py

npm install
npm run dev

でも、その裏にある考え方は意外とシンプルです。

このプロジェクトに必要なものを用意して、このプロジェクトの文脈で実行する

そう考えると、少し怖さが減ります。

最後に

昔のCGI世代が今どきの開発環境に戻ってくると、最初はかなり戸惑います。

venv
uv
pyproject.toml
npm
package.json
node_modules
npx

知らない言葉が次々に出てきます。

でも、全体像としては少し見えてきました。

今どきの開発環境は、PC全体を汚さず、プロジェクトごとに専用の環境を持つ考え方になっている。必要なライブラリやコマンドは、プロジェクト側の設定ファイルで管理する。実行も、そのプロジェクトの文脈で行う。

これは、昔のUNIXやCGIの感覚で戻ってきた人間には、かなり大きな変化です。

そして、そこにAIが加わります。

昔は一人で調べていた。
今はAIに聞きながら進められる。

昔は環境構築で力尽きることがあった。
今は小さく作って、動かして、直しながら進められる。

もちろん、まだ完全に理解しているわけではありません。uv も npm も npx も、これから少しずつ見ていく必要があります。

でも、少なくともこう思いました。

「え、開発環境ってこんなに変わってたの？」

そして同時に、少し安心しました。

20年ぶりに戻ってきても、全部が分からないわけではない。
昔の経験がそのまま使えるわけではないけれど、考え方の土台は少し活きる。

次回以降は、Pythonの仮想環境、uv、npm、npx などを、もう少し個別に見ていこうと思います。