Uvicornとは？FastAPIを動かすPython製ASGIサーバーの基礎から本番デプロイまで

Uvicornは、Pythonの非同期Webアプリケーションを動かすためのASGIサーバーです。FastAPIのデフォルトサーバーとして採用され、名前はユニコーン（unicorn）をもじった造語で、読み方は「ユビコーン」が一般的です。この記事では、Uvicornの読み方と役割、よく混同されるGunicornとの違いと使い分け、pip install uvicorn での導入から起動オプション、ワーカー数やNginx併用といった本番デプロイの勘所までを、2026年7月時点の最新版（0.50系）に沿って解説します。

まとめ：UvicornはFastAPIを動かすASGIサーバー、本番はGunicornやNginxと組み合わせる

結論から言うと、UvicornはFastAPIやStarletteなどASGI対応フレームワークを動かすPython製のASGIサーバーで、読み方は「ユビコーン」です。非同期I/OとWebSocketに対応し、少ないプロセスで多数の同時接続をさばけます。2026年7月時点の最新は0.50.0（Python 3.10以降が必要）ですが、更新が速いため最新版は公式で確認してください。

導入は pip install uvicorn、開発時の起動は uvicorn main:app --reload だけで動きます。本番では単体で --workers を使って複数ワーカーを立てるか、プロセス管理に強いGunicornと組み合わせます。ただし従来の uvicorn.workers.UvicornWorker はUvicorn 0.30で非推奨になり、現在は独立した uvicorn-worker パッケージの利用が推奨されています。さらにTLS終端や静的ファイル配信を担うNginxを前段に置くのが定番構成です。以下で読み方・違い・導入・本番設定を順に見ていきます。

Uvicornとは：ASGIサーバーの役割と読み方

Uvicornは、PythonのWebアプリとサーバーをつなぐASGI（Asynchronous Server Gateway Interface）という規格に準拠したサーバー実装です。受け取ったHTTPリクエストやWebSocket接続を、FastAPIやStarlette、ASGIモードのDjangoといったアプリケーションへ橋渡しします。内部でuvloopとhttptoolsを使い、非同期I/Oによって1つのプロセスで多数の接続を並行処理できるのが特徴で、リアルタイム通信や高い同時接続数が求められる用途に向きます。

Uvicornの読み方と名前の由来

Uvicornの読み方は「ユビコーン」が最も一般的で、「ユヴィコーン」と読む人もいます。英語圏では “you-vee-corn”（ユーヴィコーン）寄りに発音されることも多く、いずれも間違いではありません。名前は伝説の生き物ユニコーン（unicorn）に、非同期を意味する頭文字を掛け合わせた造語とされ、公式に厳密な発音が定められているわけではありません。検索でも「uvicorn 読み方」で調べる人が多く、読み方に迷った場合は「ユビコーン」と覚えておけば会話や資料で通じます。

ASGIとWSGIの違い（Uvicornが必要な理由）

従来のPython Webサーバーが準拠してきたWSGI（Web Server Gateway Interface）は、1リクエストを1つの処理で完結させる同期モデルで、WebSocketのような双方向通信を扱えませんでした。ASGIはこのWSGIを非同期対応へ拡張した後継規格で、HTTPに加えてWebSocketやLifespan（起動・終了フック）を標準で扱えます。FastAPIのようなasyncで書くフレームワークはASGIアプリなので、WSGIサーバーでは動かせず、UvicornのようなASGIサーバーが必要になります。逆に、FlaskやDjangoの同期ビュー中心のアプリはWSGIサーバーでも十分です。

UvicornとGunicornの違いと使い分け

「uvicorn gunicorn 違い」は検索でも頻出しますが、両者は競合ではなく役割が異なるツールです。Uvicornは非同期ASGIアプリを実行するサーバー、Gunicornは同期WSGI向けに生まれた成熟したプロセスマネージャで、ワーカーの起動・監視・グレースフルな再起動を得意とします。FastAPIなどのASGIアプリを動かすにはUvicornが必須ですが、Gunicornの堅牢なプロセス管理も本番では魅力的です。

使い分けの結論はこうです。開発中や小規模なら、Uvicorn単体に --workers を付けるだけで十分です。プロセスの死活監視やゼロダウンタイム更新までしっかり管理したい本番では、GunicornをプロセスマネージャにしてUvicornをワーカーとして動かす構成が有力な選択肢になります。「まずUvicorn単体、運用要件が固まったらGunicorn併用を検討」という順序で判断すると迷いません。なお、Uvicornを支えるFastAPI自体の特徴はFastAPIの概要と基本的な特徴で整理しています。

Uvicornのインストールと起動

pip install uvicorn と standard 版の違い

インストールは pip install uvicorn だけで完了し、最小構成のピュアPython実装が入ります。パフォーマンスと機能を重視するなら pip install uvicorn[standard] を使います。standard版には、イベントループを高速化するuvloop、HTTP解析を速くするhttptools、WebSocket実装のwebsockets、--reloadのファイル監視に使うwatchfilesなどが追加されます。本番でスループットを求める場合はstandard版が実質的な標準です。

pip install "uvicorn[standard]"

起動コマンドと主要オプション

起動は、アプリを定義したファイル（例：main.py）に対して uvicorn main:app と実行します。app はFastAPIなどのアプリケーションオブジェクトの変数名です。開発時はコード変更を自動反映する --reload、外部公開時は待受アドレスとポートを指定する --host と --port を付けます。

uvicorn main:app --reload
uvicorn main:app --host 0.0.0.0 --port 8000

本番環境でのUvicornデプロイ設定

ワーカー数（–workers）とGunicorn併用時の注意

ワーカー数は --workers で指定し、デフォルトは1です。CPUコア数を目安に増やすと同時処理能力が上がりますが、増やしすぎるとメモリ消費が膨らむため、負荷テストで適正値を決めます。Gunicornと組み合わせる場合、以前は gunicorn -k uvicorn.workers.UvicornWorker と書くのが定番でしたが、この uvicorn.workers モジュールはUvicorn 0.30で非推奨となり、将来削除される予定です。現在は独立した uvicorn-worker パッケージをインストールし、uvicorn_worker.UvicornWorker を指定するのが推奨です。なお、Gunicorn併用時はワーカー数をGunicorn側の -w で指定するため、Uvicorn側の --workers は付けません（両方に書くと二重管理になり混乱の元です）。

pip install uvicorn-worker
gunicorn main:app -k uvicorn_worker.UvicornWorker -w 4

古い記事の uvicorn.workers.UvicornWorker をそのまま使うと DeprecationWarning が出るため、これから構築する環境では新しいパッケージに切り替えておくと将来のUvicornアップデートで手戻りがありません。

タイムアウトとログレベルの調整

Uvicornはリクエストの処理時間そのものを打ち切るタイムアウトは持たず、keep-alive接続の待機時間を --timeout-keep-alive（デフォルト5秒）で調整できるのみです。そのため、重い処理を強制終了させたい場合はGunicorn併用時の --timeout（例：--timeout 120）でワーカーの処理時間上限を設けるのが実務的です。ログはデフォルトでinfoレベルまで出力されるので、本番では --log-level warning のように警告以上へ絞ると、アクセスログの肥大を抑えられます。ヘルスチェックや監視の頻度が高い環境ほど、この調整が効きます。

Nginxをリバースプロキシに置く構成

本番でUvicornを直接インターネットに公開することは推奨されません。TLS（HTTPS）終端、静的ファイル配信、リクエストのバッファリング、レート制限といった役割は、前段に置いたNginxに任せるのが定石です。NginxがHTTPSを受けて、内部の 127.0.0.1:8000 で待つUvicornへプロキシします。

server {
    listen 80;
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

WebSocketを使う場合は、プロトコルのアップグレードを通すために Upgrade と Connection ヘッダの引き継ぎと proxy_http_version 1.1 を追加します。

    location /ws/ {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

コンテナで動かすなら、この「Nginx＋Gunicorn＋Uvicorn」をまとめてイメージ化する構成が扱いやすく、コンテナ化の基礎はDockerとは何かで確認できます。

Uvicornに関するよくある質問

Uvicornの読み方は何ですか？

「ユビコーン」が一般的で、「ユヴィコーン」と読む場合もあります。ユニコーン（unicorn）をもじった造語で、公式に厳密な発音は定められていません。

UvicornとGunicornはどちらを使えばよいですか？

FastAPIなどのASGIアプリを動かすにはUvicornが必要です。開発や小規模ならUvicorn単体（--workers）で十分ですが、プロセスの死活監視やグレースフル再起動まで求める本番では、GunicornをプロセスマネージャにしてUvicornをワーカーとして併用する構成が有力です。

uvicorn.workers.UvicornWorker は使えなくなりますか？

Uvicorn 0.30で uvicorn.workers モジュールは非推奨になり、将来のバージョンで削除される予定です。現在は互換のため動きますが DeprecationWarning が表示されます。これからは uvicorn-worker パッケージをインストールし、uvicorn_worker.UvicornWorker を指定してください。

DjangoでUvicornは使えますか？

使えます。DjangoはASGIに対応しており、プロジェクト内の asgi.py のアプリケーションオブジェクトを指定して起動できます。非同期ビューやWebSocket（Channels等）を使う場合はUvicornなどのASGIサーバーが前提になりますが、同期処理中心のDjangoならWSGIサーバーでも問題ありません。

Uvicornのデフォルトのワーカー数は？

--workers を指定しない場合、デフォルトは1ワーカーです。CPUコア数を目安に増やすと同時処理能力が上がりますが、メモリ消費とのバランスを負荷テストで確認して決めるのが安全です。

関連記事

• FastAPIの概要と基本的な特徴：API構築のためのモダンな選択肢
• FastAPIとReactとDockerを使用したフルスタックアプリケーションの構築方法
• Dockerとは何か？仮想環境との違いや特徴をわかりやすく解説