Pixi（ピクシー）は、prefix.devが開発するRust製のパッケージ・環境管理ツールです。conda-forgeのcondaパッケージとPyPIのパッケージを1つの設定ファイル（pixi.toml）で管理し、Windows・macOS・Linuxそれぞれの解決結果をロックファイルに記録し、各OSで同じ構成の環境を再現します。イラストSNSの「pixiv」、化粧品ブランドの「Pixi Beauty」、2D描画ライブラリの「PixiJS」とは別物です。
この記事では、Pixi 0.81.0（2026年9月15日リリース）をmacOS上で実行した結果をもとに、インストールからpixi init・pixi add・pixi runの使い方、pixi.lockの扱い、condaとPyPIを混ぜたときの挙動、environment.ymlからの移行までを順に説明します。
まとめ｜Pixiの要点
- condaとPyPIを1ファイルで管理：Pythonそのものもcondaパッケージとして
pixi add python=3.12で入ります。PyPIのパッケージはpixi add --pypiで同じpixi.tomlに書かれます。 - 環境はプロジェクトごと：環境は各プロジェクトの
.pixiディレクトリに作られ、condaのようなactivateは要りません。pixi runがその環境でコマンドを実行します。 - ロックファイルが自動で付く：
pixi addのたびにpixi.lockが更新され、パッケージのURLまで記録されます。CIでは--lockedを付けると、設定とロックのずれをエラーで止められます。 - 同じパッケージを両方に書くとcondaが勝つ：PixiはcondaのパッケージとPyPIのパッケージを順に解決します。両方に同じパッケージがあればcondaのものが入り、PyPI側の版指定と食い違うと解決自体が失敗します。
- 依存がPyPIだけで完結するならuvで足りる：CUDA・GDAL・HDF5のようにC/C++ライブラリを伴うパッケージや、R・C++を混ぜるプロジェクトがPixiの出番です。PyPIだけで完結するならuvの方が手数が少なく済みます。
Pixiとは｜prefix.devが開発するconda・PyPI両対応のツール
Pixiはcondaエコシステムのパッケージを扱うツールです。既定のチャネルは、公式サイトの記載で3万を超えるパッケージを持つconda-forgeです。Pythonのほか、C/C++（clang・boost・opencv）、Java（openjdk）、Rust、Node.js、gitやripgrepのようなCLIツールもcondaパッケージとして入ります。ライセンスはBSD-3-Clause、ソースはGitHubのprefix-dev/pixiで公開されています。
中身は2つの解決器の組み合わせです。condaパッケージはprefix.devのRustライブラリ群（rattler）で解決し、PyPIのパッケージはAstralのuvをライブラリとして組み込んで解決します。公式の解説には「Pixi doesn't install uv (the tool) itself」とあり、uvを別途インストールする必要はありません。
速度については、prefix.devが2024年3月1日のブログで「環境をゼロから解決・インストールする場合、micromambaの約3倍、condaの10倍超速い」（M2 MacBook Proでの計測）と公表しています。開発元による2年以上前の版での計測なので、目安として扱ってください。
版は0.x系のまま、2026年7〜9月だけで15回リリースされています（0.72.0が7月1日、0.81.0が9月15日）。サブコマンドの名前や設定のキーが版ごとに変わることがあるため、チームではpixi --versionを揃えてから使い始めてください。
conda・pip・Poetry・uvとの機能比較
公式サイトの比較表を出発点に、各ツールの2026年10月時点の公式ドキュメントで補正すると次のとおりです。5つの中でタスクランナーを内蔵するのはPixiだけです。
| 機能 | Pixi | conda | pip | Poetry | uv |
|---|---|---|---|---|---|
| Python本体のインストール | ○ | ○ | × | △（実験的） | ○ |
| 複数言語のパッケージ | ○ | ○ | × | × | × |
| ロックファイル | ○ | △（26.5以降） | △（実験的） | ○ | ○ |
| タスクランナー | ○ | × | × | × | × |
公式の表ではPoetryのPython導入、condaとpipのロックファイルが×ですが、いずれも後から機能が加わっています。Poetryは2.1.0でpoetry python installを実験的機能として追加しました。condaは26.5で、condaとPyPIのパッケージを含む環境を複数OS分まとめてロックできるようになったとconda.orgのブログが説明しています。pipのpip lockは実験的機能で、生成したロックは実行したPythonの版とプラットフォームでしか有効と保証されません。
condaとpipの違いそのものはpipとcondaの違いと使い分け｜Anaconda・Miniconda・商用ライセンスまで解説、PyPIだけを扱うツールはuvとは？Pythonの環境構築・パッケージ管理・バージョン管理の使い方を徹底解説とPoetryとは？Python依存管理の仕組みと2.5系の使い方・uvとの選び方で詳しく説明しています。
Pixiを選ぶ場面と選ばない場面
Pixiを選ぶのは、PyPIのwheelだけでは環境が揃わないときです。GDAL・HDF5・NetCDF・CUDA Toolkitのように、Pythonパッケージの下にC/C++/Fortranのライブラリが要る場合、conda-forgeはそれらを一緒に配布します。PythonとRを同じ環境で動かす研究用のプロジェクトや、公式サイトが特徴に挙げるROS 2（RoboStack経由）のロボティクス開発も向いています。
選ばないのは、依存がPyPIだけで完結するWebアプリやライブラリです。この場合uvで足り、condaパッケージの解決を挟まない分だけ構成が単純になります。また、社内でAnacondaのdefaultsチャネルを契約して使っている組織では、既定がconda-forgeであるPixiに切り替えると入るビルドが変わります。チャネル設定を揃えてから移行してください。複数言語の開発環境をまとめて再現したいだけなら、miseやNixベースのDevboxも候補になります。Python以外の部分も含めて開発基盤を組み直す場合は、フルスクラッチ開発の支援で環境構築から相談を受けています。
Pixiのインストール方法｜macOS・Linux・Windows
公式スクリプトとパッケージマネージャー
macOSとLinuxは公式のインストールスクリプトを使います。pixiのバイナリは~/.pixi/binに置かれ、シェルの起動スクリプトにPATHが追記されます。インストール後はターミナルを開き直してください。
# macOS・Linux
curl -fsSL https://pixi.sh/install.sh | sh
# curlが無い環境
wget -qO- https://pixi.sh/install.sh | sh
# Windows（PowerShell）
powershell -ExecutionPolicy Bypass -c "irm -useb https://pixi.sh/install.ps1 | iex"Windowsのバイナリは%UserProfile%\.pixi\binに入ります。公式のインストール手順には、ほかにbrew install pixi（Homebrew）、winget install prefix-dev.pixi、scoop install main/pixi、GitHub ReleasesのMSIインストーラーが載っています。
版の固定・更新とインストール先の変更
スクリプト版は環境変数で挙動を変えられます。チームで版を揃えるときはPIXI_VERSION、ホームディレクトリ以外に置くときはPIXI_HOMEやPIXI_BIN_DIRを指定します。
# 版を指定して入れる
curl -fsSL https://pixi.sh/install.sh | PIXI_VERSION=v0.81.0 bash
# 更新（スクリプトで入れた場合）
pixi self-update
pixi self-update --version 0.81.0Homebrewやcondaで入れた場合はpixi self-updateではなく、brew upgrade pixiのように入れたツールの側で更新します。
Pixiの使い方｜init・add・runで環境を作る
pixi initで作られるファイル
pixi init demoを実行すると、demoディレクトリにpixi.toml・.gitignore・.gitattributesの3つができます。0.81.0で生成されたpixi.tomlは次のとおりです（authorsはGitの設定から入ります）。
[workspace]
authors = ["Your Name <[email protected]>"]
channels = ["conda-forge"]
name = "demo"
platforms = ["osx-64"]
version = "0.1.0"
[tasks]
[dependencies]platformsには実行したマシンの種類（ここではIntel Macのosx-64）だけが入ります。他のOSのメンバーがいるなら、後述のpixi workspace platform addで足してください。設定ファイルの名前はpixi.tomlで、YAML形式のpixi.yamlはありません。また、先頭の表は以前[project]でしたが、0.57.0（2025年10月20日）のCHANGELOGで非推奨となり、[workspace]へ置き換えるよう案内されています。古い解説記事のpixi.tomlを写すときは表の名前を確認してください。
pixi addによるPythonとパッケージの追加
Pythonもnumpyもpixi addで入れます。PyPIから入れるパッケージには--pypiを付けます。
cd demo
pixi add python=3.12 numpy
pixi add --pypi requests実行後のpixi.tomlには、依存がconda側とPyPI側に分かれて書かれます。python=3.12は"3.12.*"に、版を指定しなかったnumpyは解決した版を下限にした範囲に書き換わります。
[dependencies]
python = "3.12.*"
numpy = ">=2.5.4,<3"
[pypi-dependencies]
requests = ">=2.34.2, <3"このときパッケージはプロジェクト直下の.pixi/envs/defaultに入り、pixi.lockも同時に書かれます。pixi installを別に打つ必要はありません。
pixi run・pixi shell・タスクの定義
pixi runは、プロジェクトの環境を有効にした状態でコマンドを実行します。よく使うコマンドはpixi task addでタスクとして登録できます。
pixi task add hello "python -c 'import numpy, requests, sys; print(sys.version.split()[0], numpy.__version__, requests.__version__)'"
pixi run hello
# ✨ Pixi task (hello): python -c ...
# 3.12.15 2.5.4 2.34.2タスクはpixi.tomlの[tasks]に書かれるので、test = "pytest"のように直接書いても同じです。対話的に作業したいときはpixi shellで環境に入り、exitで抜けます。condaのconda activateに当たるコマンドはなく、Bash・Zshの設定ファイルやCIで有効化したいときはeval "$(pixi shell-hook)"のように、pixi shell-hookが出力する有効化スクリプトを読み込みます。PowerShellでは(pixi shell-hook) | Out-String | Invoke-Expressionです。
pixi.tomlとpixi.lockで環境を再現する仕組み
pixi.lockに記録される内容
pixi.lockはYAML形式で、環境ごと・プラットフォームごとに、入るパッケージのURLを1件ずつ記録します。上の例（python・numpy・requests）では、osx-64の1プラットフォームだけで31件のパッケージが並び、ファイルは480行でした。先頭は次のような形です。
version: 7
platforms:
- name: osx-64
environments:
default:
channels:
- url: https://conda.anaconda.org/conda-forge/
indexes:
- https://pypi.org/simple
packages:
osx-64:
- conda: https://conda.anaconda.org/conda-forge/osx-64/numpy-2.5.4-py312h66ee8b4_0.conda
- conda: https://conda.anaconda.org/conda-forge/osx-64/python-3.12.15-h6907cb8_1_cpython.condapixi initが作る.gitattributesにはpixi.lock merge=binary linguist-language=YAML linguist-generated=true -diffと書かれています。ロックファイルはGitにコミットして共有する前提で、マージ時に行単位で混ぜないよう設定されています。.gitignoreは.pixi/*を除外するので、環境の実体はコミットされません。
lockedとfrozenの違い
CIや本番で「ロックファイルどおりに入れる」ための指定が2つあります。pixi.tomlのpythonを"3.13.*"に書き換え、ロックは3.12のまま、という状態で試すと違いがはっきりします。
| コマンド | 結果 | 使いどころ |
|---|---|---|
pixi install --locked |
エラーで停止 | CIで設定とロックのずれを検出 |
pixi install --frozen |
ロックの3.12.15を導入 | ロックを正として再現 |
| オプションなし | ロックを3.13.16へ更新 | 手元の開発 |
--lockedのときに出たメッセージは「lock file not up-to-date with the workspace」でした。--frozenは設定ファイルの変更を無視するので、設定を直したのにロックを更新し忘れた、という事故を見逃します。CIでは--lockedを使い、ずれたら手元でpixi install（またはpixi lock）してロックをコミットし直す運用にしてください。
pixi updateとpixi upgradeの違い
名前が似ていますが、触るファイルが違います。pixi updateはpixi.tomlの範囲内でロックを新しくします。pixi upgradeは、公式のコマンドリファレンスにあるとおり「loosens the requirements」、つまりpixi.tomlの制約自体を緩めて最新版へ書き換えます。
python = "3.12.*"の状態でpixi upgrade --dry-run pythonを実行すると、変更予定はPython 3.15.0でした。pixi updateなら3.12系にとどまります。Pythonのマイナーバージョンを上げる意図がないときにupgradeを打つと、Pythonの版まで上がる点に注意してください。--dry-runを付ければ、書き換えずに変更内容だけ確認できます。
condaとPyPIを混ぜるときの注意点｜conda優先の解決順
Pixiはまずcondaの依存を解決し、その結果を前提にPyPIの依存を解決します。公式は理由を「PyPIのパッケージはインストール先のベース環境が必要だから」と説明し、その帰結として「両方で入手でき、両方に指定されている場合はcondaのパッケージを入れる」と書いています（Conda & PyPI）。
実際に、condaでnumpyを入れた環境にpixi add --pypi numpyを足しても、pixi.tomlの[pypi-dependencies]にnumpyが増えるだけで、ロックと環境にはcondaのnumpy 2.5.4が残りました。pixi listで見ると、numpyの取得元はconda、requestsはpypiです。
pixi list
# numpy 2.5.4 py312h66ee8b4_0 7.90 MiB conda https://conda.anaconda.org/conda-forge
# requests 2.34.2 228.90 KiB pypi https://pypi.org/simpleただし、PyPI側の版指定がまったく無視されるわけではありません。condaで決まった版はPyPIの解決で固定扱いになるため、両者が矛盾すると解決が止まります。公式の例では、conda側をtyping_extensions = "*"（4.15.0に解決）、PyPI側をtyping_extensions = "==4.14"にすると「failed to solve the pypi requirements」で失敗します。直接書いた依存でなくても、condaパッケージが引き込んだ依存とPyPIパッケージの要求がぶつかれば同じ失敗になります。
この順序から、実務では次の判断になります。
- C拡張を持つ大物はcondaで入れる：numpy・scipy・pytorch・gdalのように、ネイティブライブラリと版を合わせる必要があるものはconda側に置きます。
- PyPIにしかないものだけ
--pypiにする：社内パッケージやconda-forgeに無いライブラリが対象です。同じパッケージを両方に書くとcondaの版が使われ、PyPI側の版指定と矛盾すれば解決が失敗します。 - PyPI版の特定ビルドが必要なら、conda側から外す：PyPIのwheelを使いたいときは、conda側の依存から消したうえで、そのパッケージを依存に持つcondaパッケージが無いか
pixi treeで確認します。
複数の環境と複数OSへの対応｜featureとplatforms
featureによるテスト用環境の分離
テストやドキュメント生成でしか使わないパッケージは、feature（機能単位の依存のまとまり）に入れ、環境として組み合わせます。
pixi add --feature test pytest
pixi workspace environment add test --feature test
pixi run -e test pytest --version
# pytest 9.1.1pixi.tomlには[feature.test.dependencies]と[environments]の表が増えます。注意したいのは、環境にまだ組み込まれていないfeatureへpixi addすると、版がpytest = "*"のまま固定されない点です。0.81.0では実行時に「pixi upgrade --feature test pytestで解決して版を固定してください」という案内が出ました。環境を先に作ってからpixi addするか、案内どおりupgradeを実行してください。
platformsによる他OS向けロックの生成
macOSで開発し、LinuxのCIとWindowsのメンバーでも同じ環境を使う場合は、対象のプラットフォームを足します。
pixi workspace platform add linux-64 win-64 osx-arm64これでpixi.lockに4つのプラットフォーム分の解決結果が入ります。Intel Macで実行すると1.5秒ほどで終わり、キャッシュにはWindows向けのパッケージが1件も落ちていませんでした。他のOS向けのパッケージはロックに記録されるだけで、ダウンロードされるのはそのOSでpixi installしたときです。Windowsだけ入れたいパッケージは[target.win-64.dependencies]の表に書き分けます。
condaからの移行｜environment.ymlとpyproject.toml
pixi init --importによるenvironment.ymlの取り込み
condaのenvironment.ymlは、pixi init --import environment.ymlでpixi.tomlに変換できます。次のファイルを変換しました。
name: legacy-env
channels:
- conda-forge
dependencies:
- python=3.11
- pandas
- pip
- pip:
- rich結果は、nameがワークスペース名に、pip:の下が[pypi-dependencies]に入る形でした。版を書いていないパッケージは"*"になります。
[workspace]
channels = ["conda-forge"]
name = "legacy-env"
platforms = ["osx-64"]
[dependencies]
python = "3.11.*"
pandas = "*"
pip = "*"
[pypi-dependencies]
rich = "*"Pixiの環境ではPyPIのパッケージをPixi自身が入れるので、pipを依存に残す必要は通常ありません。channelsにdefaultsが入っている場合は、ライセンス条件を確認したうえでconda-forgeへ置き換えるかを決めてください。
pyproject.tomlによるPixi設定の管理
Pythonパッケージとして配布するプロジェクトなら、pixi init --format pyprojectでpyproject.tomlに設定を書けます。PEP 621の[project]はそのまま残り、Pixi固有の設定は[tool.pixi.workspace]や[tool.pixi.pypi-dependencies]に入ります。生成直後の[tool.pixi.pypi-dependencies]には、プロジェクト自身を編集可能モードで入れるpp = { path = ".", editable = true }（ppはプロジェクト名）が書かれていました。
プロジェクト外でツールを使う｜pixi global・pixi exec・スクリプト実行
pixi global installは、CLIツールをツールごとの専用環境に入れ、コマンドだけをPATHに出します。pixi global install ruffを実行すると、~/.pixi/envs/ruffに環境ができ、~/.pixi/bin/ruffから呼べるようになりました。入れたツールの一覧は~/.pixi/manifests/pixi-global.tomlに書かれます。このファイルを別のマシンへ持っていきpixi global syncを実行すると、同じツール群を入れ直せます。
一度だけ使うならpixi execが向いています。一時環境を作って実行するだけで、プロジェクトのファイルは作りません。
pixi exec --spec python=3.13 python -c "import sys; print(sys.version.split()[0])"
# 3.13.16単体のPythonスクリプトは、PEP 723のメタデータを書いてpixi run --scriptで実行できます。依存はスクリプトの先頭に書くので、pixi.tomlは要りません。
# /// script
# requires-python = ">=3.11"
# dependencies = ["rich>=13.9.2"]
# ///
import rich, sys
rich.print(f"python {sys.version.split()[0]} [bold]ok[/bold]")これをhello.pyとしてpixi run --script hello.pyを実行すると、作業ディレクトリに何も作らずに「python 3.15.0 ok」と表示されました。初回の実行でrequires-pythonを満たす版が解決され、公式の説明どおり、以後はメタデータを満たす限りその解決結果が再利用されます。新しい版へ更新するときはpixi update --script hello.pyを実行し、版を固定したいときはrequires-pythonを狭く書きます。0.81.0では、URL（GitHub Gistを含む）を直接渡して実行することもできるようになっています。
よくある質問
pixi-packとは何ですか？
pixi.lockをもとに、環境のパッケージを1つの.tarにまとめるツールです。Pixi本体ではなくQuantCoがGitHubのQuantco/pixi-packで公開しています（BSD-3-Clause・2026年10月時点の最新は0.7.11）。受け取った側はpixi-unpack environment.tarで環境を再現します。元の環境がなくてもロックファイルからパックを作れる点がconda-packとの違いで、linux-64のマシンでwin-64向けのパックを作ることもできます。
Pixiの設定ファイルはpixi.yamlですか？
いいえ、pixi.tomlです。TOML形式で、pyproject.tomlの[tool.pixi]の表に書くこともできます。ロックファイルのpixi.lockはYAML形式なので、取り違えないようにしてください。
PixiとuvはPythonの開発でどちらを使うべきですか？
依存がPyPIだけで完結するならuv、ネイティブライブラリを伴うパッケージをconda-forgeから入れたい場合やPython以外の言語も管理したい場合はPixiです。PixiはPyPIの解決にuvをライブラリとして使っているので、PyPI側の解決の仕組みは同じです。
PixiでPythonのバージョンを指定・変更できますか？
できます。pixi add python=3.12で指定し、変えるときはpixi add python=3.13のように指定し直します。プロジェクト全体の版を上げずに一度だけ別の版で動かすなら、pixi exec --spec python=3.13 pythonを使います。
conda activateのように環境を有効化するには？
pixi shellで環境に入ります。pixi runを使えば有効化せずにコマンドを実行できるので、普段は有効化しない使い方が基本です。Bash・Zshの起動時やCIで有効化したい場合はeval "$(pixi shell-hook)"、PowerShellでは(pixi shell-hook) | Out-String | Invoke-Expressionを使います。
