--- title: "pip install flaskの手順｜仮想環境の作成からエラー対処まで" url: "https://www.issoh.co.jp/tech/details/3858/" published: 2024-10-16 updated: 2026-08-28 categories: ["Python"] publisher: "株式会社一創" --- # pip install flaskの手順｜仮想環境の作成からエラー対処まで PythonのマイクロWebフレームワークであるFlaskのインストールは、`pip install Flask` の一行で終わります。実際に詰まるのはその前後です。仮想環境を作らずに実行して `externally-managed-environment` で止まる、複数のPythonが入っていて別の環境に入ってしまう、インストールは通ったのに `flask run` が起動しない。この記事では、pipでFlaskを入れる手順をFlask 3.1系の要件に沿って整理し、つまずきやすい失敗を原因別に切り分けます。 ## まとめ Flaskのインストールで押さえる要点は4つです。第一に、Flask 3.1系はPython 3.9以降を必要とします。Flask 3.1.0でPython 3.8のサポートが打ち切られました。第二に、インストールは必ず仮想環境の中で行ってください。Ubuntu 23.04以降やDebian 12以降、Homebrew版Pythonでは、仮想環境の外で `pip install` を叩くとPEP 668によりエラーで拒否されます。第三に、動作確認は `flask --version` と最小アプリの起動までをワンセットにします。第四に、`FLASK_ENV` を設定するデバッグ手順はもう使えません。Flask 2.3.0でこの環境変数は削除済みで、現在は `--debug` オプションを使います。 以降では、この4点を実際のコマンドと、失敗したときのエラーメッセージ別の対処に落として解説します。 ## pipによるFlaskインストールの手順 ### Python 3.9以上という要件の確認手順 Flask公式ドキュメントは「Flask supports Python 3.9 and newer」と明記しています。PyPI上の最新版は3.1.3で、公式changelogに記載されたリリース日は2026年2月18日です。パッケージメタデータの `Requires-Python` も `>=3.9` になっています。手元のバージョンは次のコマンドで確認できます。 ``` python3 --version # Windows の場合 py -3 --version ``` Python 3.8以下だった場合、注意が必要なのは「エラーで止まってくれない」点です。Flask 3.1系は入りませんが、pipは条件を満たす旧版を探しにいき、`Requires-Python` が `>=3.8` であるFlask 3.0.3を黙ってインストールします。インストール自体は成功するため、古い版が入ったことに気づかないまま最新版向けの解説を読み進めることになります。Python 3.8以下の環境では、インストール後に必ずバージョンを確認してください。 ### 自動で同時に入る依存パッケージ `pip install Flask` を実行すると、Flask本体だけでなく動作に必要な依存パッケージが自動で入ります。公式が「These distributions will be installed automatically when installing Flask.」として挙げているのは次の6つです。 | パッケージ | 役割 | | ------------ | ------------ | | Werkzeug | WSGIの実装 | | Jinja | テンプレート言語 | | MarkupSafe | 描画時の入力エスケープ | | ItsDangerous | セッションクッキーの署名 | | Click | flaskコマンドの提供 | | Blinker | シグナル機能の提供 | WerkzeugはPythonアプリとWebサーバーをつなぐ標準インターフェースであるWSGIを実装した部分で、開発サーバーの実体もここにあります。Python 3.10未満の環境では、これらに加えて `importlib-metadata` も入ります。パッケージメタデータ上の条件が `python_version < "3.10"` となっているためで、余計なものが混ざったわけではありません。 いっぽう `python-dotenv` と `Watchdog` は自動では入らない任意の依存です。前者は `flask` コマンド実行時に `.env` ファイルを読ませたいとき、後者は開発サーバーのリローダーを高速化したいときに、個別にインストールします。 ### 仮想環境の作成と有効化 Flask公式は「Use a virtual environment to manage the dependencies for your project, both in development and in production」として、開発・本番の双方で仮想環境の使用を求めています。Pythonに標準搭載されている `venv` モジュールを使い、プロジェクトフォルダの直下に `.venv` を作るのが公式の手順です。 ``` # macOS / Linux mkdir myproject cd myproject python3 -m venv .venv . .venv/bin/activate # Windows mkdir myproject cd myproject py -3 -m venv .venv .venv\Scripts\activate ``` 有効化に成功すると、シェルのプロンプト先頭に `(.venv)` が付きます。この表示が出ていない状態で次のインストールに進むと、システム側のPython（環境によってはユーザーサイト）にパッケージが入るか、後述のエラーで拒否されるかのどちらかです。作業を終えて仮想環境から抜けるときは `deactivate` と入力してください。仮想環境そのものの位置づけや、コンテナ・仮想マシンとの隔離レベルの違いは[仮想環境とは？venv・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説](/tech/details/13536/)で整理しています。 ### pip install Flaskの実行とインストール先の確認 仮想環境を有効化した状態で、公式が示すコマンドを実行します。 ``` pip install Flask flask --version pip show flask ``` PyPIの登録名は大文字始まりの `Flask` ですが、`pip install flask` と書いても同じものが入ります（理由は後述のよくある質問を参照）。 `flask --version` はFlaskとWerkzeug、実行中のPythonのバージョンを表示します。インストール先まで確かめたいときは `pip show flask` の `Location` 欄を見てください。ここが意図した `.venv` の下を指していれば、仮想環境へ正しく入っています。システムのPythonのパスが表示されていたら、仮想環境の有効化が効いていません。 なお、インストールの最後に `notice: A new release of pip is available` と表示されることがありますが、これはpip自身の更新案内であって失敗ではありません。Flaskは正常に入っています。 ## インストールが失敗する場合の原因別対処 ### externally-managed-environmentエラーの原因と回避策 Ubuntu 23.04以降やDebian 12以降、Homebrewで入れたPythonでは、仮想環境の外で `pip install Flask` を実行すると `error: externally-managed-environment` で拒否されます。これはpipの不具合ではなく、PEP 668として標準化された保護機構です。 ディストリビューションがPythonを管理している場合、標準ライブラリのディレクトリに `EXTERNALLY-MANAGED` というマーカーファイルが置かれます。pipはこれを検出すると、仕様の定めどおり「そのPythonインタプリタのディレクトリへのインストールは仮想環境の外では無効である」旨のエラーを出して終了します。OSのパッケージ管理システムが握っているファイルを上書きし、システムツールを壊す事故を防ぐためのものです。 正しい対処は、仕様書が推奨するとおり仮想環境を作ることです。前節の `python3 -m venv .venv` を実行して有効化すれば、このエラーは出なくなります。`--break-system-packages` を付ければ黙らせられますが、仕様書自身が「その使用にはリスクが伴うことを示す語感を持たせるべきである」と述べており、フラグ名がそのまま警告になっています。開発用パッケージをシステム領域へ押し込む理由はありません。 ### ensurepip is not availableで仮想環境が作れない場合 ここで問題になるのが、Debian系ディストリビューションの構成です。前節の対処に従って `python3 -m venv .venv` を実行すると、今度は次のエラーで止まることがあります。 ``` The virtual environment was not created successfully because ensurepip is not available. ``` Debian・Ubuntuは `venv` を標準のPythonパッケージから切り離し、`python3-venv` という別パッケージとして配布しています。このパッケージが入っていないと、仮想環境の作成時に必要な `ensurepip` が見つからず失敗します。エラーメッセージ自体が導入すべきパッケージ名を案内するので、それに従ってインストールしてください。 ``` sudo apt install python3-venv ``` 複数のPythonを併存させている場合は、`python3.12-venv` のようにバージョン付きのパッケージ名を求められることがあります。表示された名前をそのまま指定するのが確実です。 ### pipコマンド未検出と別Pythonへの誤インストール `pip: command not found`（Windowsでは「’pip’ は、内部コマンドまたは外部コマンド…として認識されていません」）が出る場合と、コマンドは通るのにFlaskをimportできない場合は、どちらも「どのPythonのpipを叩いているか」という同じ原因に行き着きます。 確実なのは、pipを単独のコマンドとして呼ばず、Pythonのモジュールとして呼ぶ書き方です。 ``` python3 -m pip install Flask # Windows の場合 py -3 -m pip install Flask ``` この形式なら、`python3`（または `py -3`）で起動するインタプリタに対応するpipが必ず使われるため、「pipはPython 3.11のもの、実行しているのはPython 3.13」といったずれが起きません。複数バージョンのPythonが同居するマシンでは、この書き方を既定にしておくと事故が減ります。 インストール後に `ModuleNotFoundError: No module named 'flask'` が出るときは、実行しようとしているPythonがインストール先と違っています。`python3 -m pip show flask` の `Location` と、`python3 -c "import sys; print(sys.executable)"` の出力を突き合わせれば、どちらのPythonを見ているかが判別できます。 VS Codeで実行している場合は、ターミナルで仮想環境を有効化しただけでは足りません。コマンドパレットから `Python: Select Interpreter` を開き、プロジェクト配下の `.venv` のインタプリタを明示的に選んでください。エディタが別のPythonを見ていると、ターミナルでは通るのにエディタ上ではimportエラーの波線が消えない、という食い違いが起きます。 ### PowerShellでの仮想環境有効化エラー Windows PowerShellで `.venv\Scripts\activate` を実行したとき、「このシステムではスクリプトの実行が無効になっているため…」というエラーで止まることがあります。仮想環境の作成に失敗しているのではありません。PowerShellの実行ポリシーが `.ps1` スクリプトの実行を禁じている状態です。 ``` Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned .venv\Scripts\activate ``` `-Scope Process` を付けると、変更が現在のPowerShellウィンドウを閉じるまでの一時的なものに限定されます。マシン全体の設定を変えずに済むため、開発マシンではこの範囲に留めるのが無難です。コマンドプロンプト（cmd.exe）を使う場合は実行ポリシーの制約を受けないので、`.venv\Scripts\activate.bat` をそのまま実行できます。 ### プロキシ環境・社内ネットワークでのインストール失敗 社内ネットワークからのインストールでは、`Connection timed out` や `CERTIFICATE_VERIFY_FAILED` でPyPIに到達できないことがあります。プロキシ経由の場合は、pipに明示的に指定します。 ``` pip install --proxy http://proxy.example.com:8080 Flask ``` SSL証明書の検証に失敗するケースは、多くが社内のSSLインスペクション用の中間証明書に起因します。ここで `--trusted-host` を使って検証を外すのは応急処置にしかならず、通信内容の保護を捨てることになります。企業の証明書バンドルをpipに渡す `pip config set global.cert <証明書のパス>` の形で、検証を維持したまま通す方法を先に検討してください。 ## インストール直後の動作確認 ### 最小アプリの作成とflask runの実行 インストールが成功したかどうかは、実際にリクエストを返させるところまで確認します。プロジェクト直下に `app.py` を作ってください。 ``` from flask import Flask app = Flask(__name__) @app.route("/") def index(): return "Hello, World!" ``` 仮想環境を有効化したまま、次のコマンドで開発サーバーを起動します。 ``` flask --app app run --debug ``` `--app app` はアプリケーションを定義したモジュール名（`app.py` なら `app`）を指します。起動に成功すると `http://127.0.0.1:5000` が案内されるので、ブラウザで開いて「Hello, World!」が表示されれば完了です。 ポート5000が既に使われている場合は `Address already in use` で失敗します。macOS Monterey（12）以降ではAirPlayレシーバーが有効なときに5000番と7000番を使うため、`flask --app app run --port 5001` のように別のポートを指定するか、システム設定側で該当機能を無効にしてください。 ### FLASK\_ENVを使う古い手順が動かない理由 Web上のFlask解説には、デバッグモードの有効化として次の書き方が数多く残っています。 ``` # この手順は現行のFlaskでは動作しません export FLASK_APP=app.py export FLASK_ENV=development flask run ``` このうち `FLASK_ENV` は現在のFlaskには存在しません。公式changelogのVersion 2.3.0に「The `FLASK_ENV` environment variable, `ENV` config key, and `app.env` property are removed.」と記載されています。伏線は2.2.0にあり、そこで非推奨とされたうえで「Debug mode should be controlled directly using the `--debug` option or `app.run(debug=True)`」と方針が示されました。development環境とdebugモードを区別する設計そのものが廃止されたためです。 やっかいなのは、この環境変数を設定してもエラーにならない点です。Flaskが参照しなくなっただけなので、シェルは黙って変数をセットし、`flask run` は通常モードで起動します。「手順どおりに設定したのにホットリロードもスタックトレースも出ない」という症状の多くはこれが原因で、エラーが出ない分だけ切り分けが難しくなります。 現行の書き方は、前節で使った `--debug` オプションです。同じ2.2.0で「Add `--app` and `--debug` options to the `flask` CLI, instead of requiring that they are set through environment variables.」として追加されており、`FLASK_APP` の設定も `--app` で置き換えられます。スクリプトから起動する場合は `app.run(debug=True)` を使ってください。Flask関連の記事や書籍を参照するときは、`FLASK_ENV` が出てくるかどうかが、その内容が2023年4月のFlask 2.3.0より前のものかを見分ける実用的な目印になります。 ## インストール後の運用（バージョン固定・拡張追加・削除） ### requirements.txtによるバージョン固定と環境の再現 チーム開発や本番環境では、入るバージョンを固定します。バージョンを明示しない `pip install Flask` は実行時点の最新版を取得するため、環境ごとに別のバージョンが入る余地が残るからです。 ``` pip install "Flask==3.1.3" pip freeze > requirements.txt pip install -r requirements.txt ``` `pip freeze` は現在の環境の全パッケージをバージョン付きで書き出すので、この `requirements.txt` をリポジトリに含めておけば、他のメンバーや本番環境で同じ構成を再現できます。 ### Flask拡張パッケージの配布名とimport名の違い Flask本体は最小構成なので、データベース連携やCORS対応、ログイン管理といった機能は拡張パッケージとして個別にインストールします。 ここで足していく拡張が、Djangoでは標準に含まれます。両者の内蔵範囲の差と選び分けは[DjangoとFlaskの違いと選定条件の解説](https://www.issoh.co.jp/tech/details/17084/)で扱っています。 ``` pip install flask-sqlalchemy flask-cors flask-login ``` ここでつまずきやすいのが、配布名とimport名の表記が揃っていない点です。PyPIでの配布名はハイフン区切りの `flask-cors` ですが、Pythonコード内で書くのはアンダースコア区切りの `import flask_cors` になります。インストール側はどちらの表記でも通るので、`ModuleNotFoundError` が出たらハイフンのままimportしていないかを最初に疑ってください。 ### アップグレードとアンインストールの挙動 ``` pip install --upgrade Flask pip uninstall Flask ``` `pip uninstall Flask` はFlask本体だけを削除し、同時に入ったWerkzeugやJinjaは環境に残します。依存パッケージごときれいに消したい場合は、仮想環境のフォルダ（`.venv`）自体を削除して作り直すほうが確実です。プロジェクトごとに環境を分けておく利点は、この後始末のしやすさにも表れます。 ## pip以外の管理ツールとの使い分け Flaskを入れるだけであれば、pipとvenvの組み合わせで十分です。標準搭載で追加インストールが不要なうえ、公式ドキュメントがこの手順を前提に書かれているため、エラーが出たときも情報を見つけやすくなります。学習目的や単一プロジェクトなら、乗り換える理由はほとんどありません。 選択肢を変える価値が出るのは、条件がはっきりしている場合です。依存解決とインストールの速度が開発サイクルの足を引っ張っているなら[uvとは？Pythonの環境構築・パッケージ管理・バージョン管理の使い方を徹底解説](/tech/details/4384/)、依存関係のロックとパッケージ公開まで一貫して管理したいなら[Poetryが解決するPython依存関係管理が抱える構造的な課題](/tech/details/12303/)、機械学習系のライブラリでC/C++依存のビルドに悩まされているなら[pipとcondaの違いと使い分け｜Anaconda・Miniconda・商用ライセンスまで解説](/tech/details/7775/)が判断材料になります。 逆に、これらのツールを「新しいから」という理由だけで導入するのは勧めません。チーム内で管理ツールが混在すると、依存関係の記述先が `requirements.txt`・`pyproject.toml`・`environment.yml` に分散し、環境差異の原因を追う手間がインストール時間の短縮分を上回ります。 もう一点、`flask run` が起動する開発サーバーは本番利用を想定していません。本番へ出す段階では、WSGIサーバー（Gunicorn等）やASGIサーバーを前面に置く構成へ切り替えます。ASGI側の考え方は[Uvicornとは？FastAPIを動かすPython製ASGIサーバーの基礎から本番デプロイまで](/tech/details/4843/)で解説しています。 ## よくある質問 ### pip install flask と pip install Flask のどちらが正しいですか？ どちらでも同じパッケージが入ります。PyPI上の登録名は `Flask` ですが、パッケージ名の照合では大文字小文字の違いに加えて、ハイフン・アンダースコア・ピリオドの違いもすべて同一のものとして正規化されるためです。`pip install FLASK` と書いても結果は変わりません。この正規化ルールがあるおかげで、拡張パッケージも `flask-cors` と `flask_cors` のどちらの表記でインストールできます。公式ドキュメントの表記は `pip install Flask` なので、迷ったときはこれに合わせておけば十分です。 ### Flaskはどのバージョンを入れるべきですか？ 特別な制約がなければ最新版（2026年8月時点で3.1.3）を使ってください。既存プロジェクトへ追加する場合のみ、他のライブラリとの互換性を確認したうえで `pip install "Flask==3.1.3"` の形でバージョンを固定します。注意したいのはPython 3.8以下の環境です。Flask 3.1系は要件を満たさないため、pipはエラーを出さずに旧版のFlask 3.0.3を選びます。意図せず古い版で開発を始めないよう、インストール後に `flask --version` で確認してください。 ### 仮想環境を使わずにインストールしても問題ありませんか？ 勧められません。OSが管理するPythonへ直接インストールすると、システムツールが依存するパッケージのバージョンを書き換えてしまう恐れがあります。Ubuntu 23.04以降やDebian 12以降では、PEP 668によってそもそもエラーで拒否されます。`--break-system-packages` を付ければ強行できるものの、PEP 668自身がこのオプションを「その使用にはリスクが伴うことを示す語感を持たせるべきである」と位置づけており、名前のとおりシステム側のパッケージを壊しかねません。`python3 -m venv .venv` の一行で回避できる以上、強行する理由はありません。 ### flask runが「Could not locate a Flask application」で失敗します アプリケーションの場所をFlaskが特定できていません。`flask --app app run` のように `--app` でモジュール名を明示してください。ファイル名が `app.py` または `wsgi.py` で、かつそのディレクトリでコマンドを実行している場合に限り、自動検出が働きます。別の名前のファイル（たとえば `main.py`）なら `flask --app main run` と指定してください。古い解説にある `FLASK_APP` 環境変数も引き続き使えますが、`--app` のほうが起動対象を実行時に明示できるぶん、取り違えが起きにくくなります。 ### Flaskのインストール先はどこで確認できますか？ `pip show flask` の `Location` 欄に表示されます。仮想環境を使っていれば、プロジェクト配下の `.venv` の中を指しているはずです。想定と違う場所が出た場合は、仮想環境の有効化が効いていないか、別のPythonのpipを呼んでいます。切り分けには `python3 -c "import sys; print(sys.executable)"` を実行し、その出力と `Location` のパスが同じ環境を指しているかを突き合わせてください。両者がずれていれば、インストール先と実行環境が別々になっているという結論になります。 ## 関連記事 - [仮想環境とは？venv・コンテナ・仮想マシンの違いと隔離レベルの選び方を実装者向けに解説](/tech/details/13536/) - [pipとcondaの違いと使い分け｜Anaconda・Miniconda・商用ライセンスまで解説](/tech/details/7775/) - [uvとは？Pythonの環境構築・パッケージ管理・バージョン管理の使い方を徹底解説](/tech/details/4384/) - [Poetryが解決するPython依存関係管理が抱える構造的な課題](/tech/details/12303/) - [Uvicornとは？FastAPIを動かすPython製ASGIサーバーの基礎から本番デプロイまで](/tech/details/4843/) --- 出典: [pip install flaskの手順｜仮想環境の作成からエラー対処まで]()（株式会社一創）