mise｜Node・Pythonのバージョン管理と環境変数・タスクを1つのCLIに

新しく入ったメンバーがリポジトリをクローンして、Node.jsのバージョンが合わずにビルドが通らない、環境変数の設定手順がREADMEと実態でずれている、テストの叩き方が人によって違う。こうした立ち上げの摩擦を、1つの設定ファイルに寄せて解消しようとするのがmiseです。jdx/miseのリポジトリはRustで書かれたMITライセンスのCLIで、READMEの冒頭では、プロジェクトのツール・環境変数・タスクを1つのmise.tomlにまとめ、新しいシェル・チェックアウト・CIジョブが同じ状態から始まるようにすると説明されています。2026年7月時点でGitHubのスターは約3万1千です。

01.miseの機能

公式サイトによると、miseが担うのは次の3つで、いずれもこれまで別々のツールで分担していた範囲です。

3つすべてを使う必要はなく、バージョン管理だけ入れて環境変数とタスクは既存のままにする導入もできます。

02.読み方・由来・旧名

名前は英語風に「ミーズ」と読みます。公式のAboutページによると、由来はフランス語の調理用語である mise-en-place で、「準備」「あらかじめ配置しておくこと」を指す表現だと説明されています。作者はJeff Dickey氏で、言語をまたいでローカル開発を楽にするために作ったツールだと書かれています。

検索していると出てくるrtxという名前は、miseの旧名です。改名を告知したGitHub Discussionでは、単純なバージョン管理ツールから開発環境全体を扱う役割へと広げたこと、そしてNVIDIAのグラフィックスカードの製品名と混同されて検索しづらいという不満が最も多かったことが理由として挙げられています。

同じ告知では移行時の注意も2点案内されているので、古い記事の設定をそのまま写すときは確認してください。

• .rtx.tomlは当面読み続けるものの、mise.tomlへのリネームが推奨されています
• RTX_*の環境変数は読まれないため、MISE_*に変える必要があります

リリースは2026.7.15のような年・月・連番のカレンダーバージョニングで、リリース一覧を見ると数日おきに更新が出ているため、古い記事に載っているオプションが使えないこともあります。

03.インストールと有効化

OSごとのインストール

公式のインストール手順には、OSやパッケージマネージャーごとの方法が並んでいます。どの環境でも通るのは配布スクリプトで、macOSならHomebrew、WindowsならScoopが案内されています。

# どのOSでも使える配布スクリプト
curl https://mise.run | sh

# macOS（Homebrew）
brew install mise

# Windows（公式が推奨する方法）
scoop install mise

# Windows（winget）
winget install jdx.mise

# Debian / Ubuntu
sudo add-apt-repository -y ppa:jdxcode/mise
sudo apt update
sudo apt install -y mise

Scoopが推奨される理由は、shims（後述するコマンドの受け皿）のディレクトリを自動でPATHに追加するためです。手動で入れた場合は%LOCALAPPDATA%\mise\shimsを自分でPATHに追加します。

activateとshimsの使い分け

有効化には2つの方式があり、選択を誤ると「入れたのにコマンドが切り替わらない」状態になります。公式のGetting Startedでは次のように役割が分けられています。

同じページには、shimsはmise activateのすべての機能に対応しているわけではない、という趣旨の注記もあります。

# bash
echo 'eval "$(~/.local/bin/mise activate bash)"' >> ~/.bashrc

# zsh
echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc

# fish
echo '~/.local/bin/mise activate fish | source' >> ~/.config/fish/config.fish

普段のターミナルはmise activate、エディタから直接起動されるプロセスやCIはshims、という併用が公式の想定です。エディタのターミナル以外から実行される処理（保存時のフォーマッタなど）で古いバージョンが使われる場合は、shimsのPATH設定が抜けていると疑います。

04.バージョン管理の基本操作

mise useはインストールと設定ファイルへの書き込みを同時に行うため、まず覚えるコマンドはこれだけで足ります。全体に効かせる場合は--globalを付けます。

# 現在のプロジェクトで使うバージョンを決める（mise.tomlに書き込まれる）
mise use node@22

# どこでも使う既定のバージョンを決める
mise use --global node@26

# mise.tomlを手で編集したあと、書かれているバージョンをまとめて入れる
mise install

# 入っているものを確認する
mise ls

# 設定を変えずに、その場だけ別のバージョンで実行する
mise exec node@20 -- node --version

書き込まれるmise.tomlは次のような内容です。Node.jsやPythonのような言語だけでなく、TerraformやkubectlのようなCLIも同じ[tools]に並びます。公式サイトでは、レジストリに1,000を超えるツールが登録されていると説明されています。

[tools]
node = "22"
python = "3.13"
terraform = "1.9"

レジストリに短い名前で載っていないツールも、取得元を指定して入れられます。公式のGetting Startedでは、npmパッケージ・pipx・GitHubのリリースから入れる例が示されています。

mise use --global npm:@anthropic-ai/claude-code
mise use --global pipx:black
mise use --global github:BurntSushi/ripgrep

05.設定ファイルの読み込み順

設定は1か所ではなく、複数の場所から重ねて読まれます。公式の設定ドキュメントによると、ディレクトリツリーを上へたどりながら読み込み、深い階層の記述が上の階層を上書きします。同ドキュメントは例として、~/src/work/myproj/mise.tomlがあれば、そこでの定義が~/src/work/mise.tomlや~/.config/mise.tomlの設定を上書きすると説明しています。

miseで始まるパスはドットファイルにもできるため、.mise.tomlや.mise/config.tomlという形も有効です。既存リポジトリで.mise.tomlを見かけたら、mise.tomlと同じものだと考えて構いません。

06.asdf・nvm・pyenvから移行するとき

.tool-versionsはそのまま読める

既にasdfを使っているなら、移行の初手は設定の書き換えではありません。公式のasdfとの比較ページは、miseをasdfのドロップイン置き換えとして使えるとし、asdfで使っていたのと同じ.tool-versionsファイルに対応していると説明しています。既存ファイルを残したままmiseを有効化して、期待どおりに切り替わるかを確認するところから始められます。

同じページによると、asdfはランタイムを呼ぶたびにshim経由で約120ミリ秒かかりますが、mise activateはshimsを使わずPATHを更新するため、この追加がありません。ディレクトリが変わったときに走る内部コマンドは、作者の環境で約10ミリ秒とされています。

.node-versionは既定で読まれない

移行で最もつまずきやすい点です。.node-version・.nvmrc・.python-versionのように言語ごとに慣習として使われてきたバージョン指定ファイルは、miseでは既定で無効で、公式の設定ドキュメントにもそう明記されています。

読ませたい場合は、公式の設定一覧にあるidiomatic_version_file_enable_tools（既定値は空のリスト）でツールを指定して有効化します。

[settings]
idiomatic_version_file_enable_tools = ["node", "python"]

プラグインからバックエンドへ

asdfは、ツールごとにコミュニティが書いたプラグインを入れて使う仕組みでした。公式のasdfとの比較ページは、そのプラグインがシェルコードであり実質的にマシン上で何でもできてしまう点、そして多くが提供元ではなく第三者製のため、プラグインごとに見知らぬ開発者を信頼することになる点を問題として挙げており、miseはこの方式に依存しません。

代わりに用意されているのがバックエンドです。公式のレジストリのページでは、機能とセキュリティの面で最も優れておりプラグインを必要としないaquaを最優先とし、github・gitlabが続く順序が示されています。同じページで、新しく登録する際にvfox・asdf・ubiのバックエンドはサプライチェーンの安全性を理由に受け付けないと明記されています。

Windowsで使えるかどうかも、この違いから決まります。比較ページは、asdfがWindowsでまったく動かない一方、miseではasdf以外のバックエンドを使うツールならWindowsに対応できると説明しています。提供元がWindows向けのバイナリを配布していることが前提になります。

07.環境変数の管理

ディレクトリに入ったときに環境変数を読み込む用途はこれまでdirenvが担ってきましたが、miseでは[env]セクションに書きます。公式の環境変数のドキュメントでは、直接の代入に加えて、.envなどのファイルからの読み込み、PATHへの追加、シェルスクリプトの実行結果の取り込みが示されています。

[env]
NODE_ENV = "development"

# .env / JSON / YAML / TOML から読み込む
_.file = ".env"

# PATHに追加する（テンプレートで設定ファイルの位置を参照できる）
_.path = ["./bin", "{{config_root}}/node_modules/.bin"]

# シェルスクリプトを実行し、exportされた変数を取り込む
_.source = "./scripts/env.sh"

値の扱いも設定側で宣言できます。同じドキュメントでは、値をログに出さないredactと、未設定ならエラーにするrequiredが説明されています。requiredには案内文を添えられるので、変数の設定漏れを実行前に理由付きで止められます。

[env]
# ログや出力からマスクする
API_TOKEN = { value = "xxxxx", redact = true }

# 未設定なら、案内文を出して止める
DATABASE_URL = { required = "PostgreSQLの接続文字列を設定してください" }

08.タスクランナーとして使う

公式のタスクのドキュメントによると、タスクは[tasks]セクションに書くか、mise-tasksディレクトリに実行可能なスクリプトとして置きます。スクリプトとして置く場合は、ファイル内のコメントで説明を書けます。

[tasks.build]
description = "CLIをビルドする"
run = "cargo build"

#!/usr/bin/env bash
#MISE description="CLIをビルドする"
cargo build

どちらの書き方でもmise run buildで実行できます。コマンド名が衝突しなければmise buildと短く書けます。同じドキュメントは、Makefileとの違いを4点挙げています。

• 依存関係を、設定なしで既定から並列に実行します
• 最終更新を比べ、変更がなければ再実行を省きます
• mise watchで、変更時に自動で走らせられます
• タスクをTOMLの文字列ではなく、シェルスクリプトのファイルとして書けます

タスクの中では、実行元のディレクトリを示すMISE_ORIGINAL_CWD、プロジェクトのルートを示すMISE_PROJECT_ROOTなどが渡されます。どこから呼ばれても同じ場所を基準にできるため、リポジトリのルート前提のスクリプトを書くときに扱いやすくなります。

09.チームでバージョンを揃えるmise.lock

node = "22"のような緩い指定は書きやすい一方、入るバージョンは入れた時期で変わるため、これを揃えるのがmise.lockです。公式のロックファイルのドキュメントは、package-lock.jsonやCargo.lockと同じ考え方だとし、チーム全員が完全に同じツールのバージョンを使う状態を作るためのものだと説明しています。既定では無効なので、設定で有効にします。

[settings]
lockfile = true

同じドキュメントによると、バージョンのほかに次の3つも記録されます。

• バックエンドが対応している場合のチェックサム
• linux-x64やmacos-arm64といったOSと環境の組み合わせごとのダウンロードURLとファイルサイズ
• 使ったバックエンド

ダウンロードURLを持つため、以降のインストールではGitHubなどの提供元を呼ばずに済み、レート制限を避けられます。CIでのインストールが不定期に失敗する場合に有効です。

10.安全に使うための設定

公開されたばかりのバージョンをそのまま取り込まない仕組みが用意されています。公式の設定一覧にあるminimum_release_ageは、サプライチェーンのリスクを抑えるためにリリース日でバージョンを絞り込み、公開されたばかりのバージョンを一定期間が経つまで無視するという趣旨の設定で、既定値は24時間です。90dのような相対的な期間でも、日付そのものでも指定できるので、社内の方針に合わせて延ばせます。

[settings]
# 公開から14日経ったバージョンだけを対象にする
minimum_release_age = "14d"

設定ファイルそのものの扱いにも境界があります。公式のmise trustのドキュメントによると、コードを実行しうる設定や環境に影響する設定を読むときは、そのファイルが信頼済みである必要があります。信頼されていない場合は確認が求められ、確認できない状況ではエラーになります。

一方、次の3つだけを書いたファイルは確認なしで読み込まれると明記されています。クローンしただけのリポジトリで確認を求められるかどうかは、設定の内容で変わります。

• min_version
• 素のバージョン文字列だけの[tools]
• テンプレートやツールオプションを含まない[tasks]

# このディレクトリの設定を信頼する
mise trust

# 状態だけ確認する
mise trust --show

11.CIとWindowsでの使い方

公式のCIのドキュメントでは、GitHub Actionsで専用のアクションを使う例が示されています。installでmise.tomlに書かれたツールを入れ、cacheでキャッシュを効かせる形です。

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: jdx/mise-action@v3
        with:
          install: true
          cache: true
      - run: mise run lint

同じドキュメントでは、運用上の要点が2つ案内されています。

• 正しいバージョンで実行されるように、mise x経由で呼ぶか、shimsをPATHに入れておきます
• 外部から来た設定を扱う場合はMISE_SAFE=1を指定します。フック・タスク・プラグインのスクリプトの実行を止めつつバージョンの解決だけを残せるため、依存更新ボットやフォークからのプルリクエストでCIを回すリポジトリで役立ちます

毎回インストールする手順を省きたい場合は、mise generate bootstrap -l -wで./bin/miseを生成してコミットする方法も案内されています。

12.miseで置き換わらないもの

範囲を取り違えると、入れたあとに期待外れになります。公式のFAQは、miseが対象とするのは開発ツールであり、アプリケーションやシステムのパッケージではないと述べています。そのため、次の3つはmiseを入れても引き続き必要になります。

• 言語のパッケージ管理：npm・pnpm・pipのような依存の解決とインストールはそれぞれのツールの担当です。miseは、そのツール自体のバージョンを固定する側に立ちます
• Pythonの仮想環境：公式のPythonのドキュメントによると、miseは既定でpython-build-standaloneのビルド済みバイナリを取得するため導入が速く、uv.lockがあるプロジェクトではpython.uv_venv_autoの設定で.venvを自動で有効化できます。仮想環境そのものやパッケージの解決はuvなどが担います
• 本番と同じ環境の再現：OSのライブラリやミドルウェアまで揃えたい場合はコンテナの領域です。miseは手元とCIで使うツールのバージョンを揃えるところまでを担います

逆に言えば、コンテナを使っている現場でもコンテナの外で動かすツール類のバージョンを揃える用途は残るため、両方を併用する構成は珍しくありません。

13.うまく動かないときの確認順

導入直後に多いのが、コマンドが見つからない、または古いバージョンが使われるという症状です。公式のトラブルシューティングは、この原因としてmiseがPATHの先頭に来ていない可能性が高いことを挙げています。確認は次の順で進めると原因に早く届きます。

同じページでは、mise activateを使っていて他のPATHが先に来る場合の対処として、常にmiseのツールをPATHの先頭に置くMISE_ACTIVATE_AGGRESSIVE=1も案内されています。恒久的に有効にする前に、which -aで何が競合しているかを特定しておくと、副作用の予想がつきます。

14.よくある質問（FAQ）

15.まとめ

miseは、ツールのバージョン・環境変数・タスクという3つの担当を1つのmise.tomlに集めるCLIです。バージョン管理だけを見ればasdfやnvmと同じ役割で、.tool-versionsをそのまま読めるため、移行の最初の一歩は軽く済みます。さらに環境変数とタスクまで同じファイルに入ると、READMEの手順と実際の環境がずれる余地が減ります。

導入時に確認しておく点は3つです。

• .node-versionのような言語ごとのバージョン指定ファイルは既定で無効です
• 対話シェルはmise activate、CIやIDEはshimsを使い分けます
• チームでバージョンを固定するならmise.lockを有効にします

この3つを押さえておくと、移行直後の「切り替わらない」「人によってバージョンが違う」という状態を避けられます。

開発環境の設定をリポジトリ側に寄せる作業は、担当者が変わっても手順が壊れない状態を作る投資でもあります。弊社では、AIをフル活用したWeb制作・運用の中で、こうした開発と運用の土台づくりのご相談も承っています。