mise 入門ガイド

mise とは

mise（ミーズ）は、開発ツールのバージョン管理・タスク実行・環境変数の設定を 1 つにまとめたコマンドラインツールです。

プロジェクトごとに、必要なツールもそのバージョンも違う。動かすための手順も、渡すべき設定値も違う。そしてその大半は、コードではなく README と口頭の申し送りに置かれています。

こうした問題を、設定ファイル 1 つにまとめて解決するのが mise です。

• ツールのバージョン管理 — nvm・pyenv・rbenv などを 1 つに置き換える
• タスクランナー — package.json の scripts に相当するものを、言語に依存せず書ける
• 環境変数 — ディレクトリに入ったときだけ効く環境変数を定義できる

3 つが別々のツールだったものが、mise.toml 1 ファイルに収まります。

この 3 つが、それぞれどういう不便を消してくれるのか。1 つずつ具体的に見ていきます。

ツールのバージョンが揃わない

新しく入った人がリポジトリを clone して、書いてあるとおりにコマンドを打つ。それが動かない。調べてみると、その人の手元の Node.js が 20 で、プロジェクトが前提にしていたのは 22 だった。よくある話です。

厄介なのは、エラーメッセージがバージョンの話をしてくれないことです。構文エラーや「そんな関数は無い」とだけ言われるので、そこからバージョン違いを疑うまでに時間が溶けます。

nvm や pyenv でも解決できます。ただし切り替えは手作業です。nvm use を打ち忘れたまま作業を始めれば、結局同じことが起きます。

mise は、mise.toml のあるディレクトリに入った瞬間に切り替えます。打ち忘れる操作がありません。

cd ~/work/blog      # ここで node が 26 になる
cd ~/work/old-app   # ここで 22 に戻る

コマンドの入り口がばらばら

開発サーバーは bun dev、マイグレーションは ./scripts/migrate.sh、リリースは make release。どれも間違ってはいません。ただ、どこに何があるのかは 3 つのファイルを開かないと分かりません。

README に一覧が書いてあることもありますが、更新が止まっているのが常です。

mise を使うと、入り口が 1 つになります。

mise tasks       # このプロジェクトで打てるものが全部出る
mise run dev

package.json の scripts と違うのは、JavaScript のプロジェクトでなくても使えることです。シェルスクリプトでも、別ファイルに切り出したものでも、同じ一覧に並びます。

環境変数が手渡しになっている

.env.example をコピーして .env を作る。手順書に書かれた export をシェルに打つ。どちらも打った人の環境にだけ効くので、次に困るのは打ち忘れた人です。

もっと危ないのは逆のパターンで、打ったまま忘れる場合です。あるプロジェクトで export DATABASE_URL=... した状態のまま別のプロジェクトに移り、そちらのスクリプトが前のデータベースを向いてしまう。これは実際に起こります。

mise の [env] は、そのディレクトリの中でだけ有効です。出れば消えます。

cd ~/work/blog
echo $DATABASE_URL   # postgres://localhost:5432/dev
cd ~
echo $DATABASE_URL   # 空

この記事で扱うのは、この 3 つのうち 1 つ目のツールのバージョン管理だけです。残りの 2 つはそれぞれ書くことが多いので、別の記事にしました。タスク編と環境変数編です。

mise のインストール

使っている OS で選んでください。

curl -fsSL https://mise.run | sh

winget install jdx.mise

macOS で Homebrew を使っているなら brew install mise でも入ります。Windows では winget のほかに scoop install mise と choco install mise があり、すでに使っているパッケージマネージャに合わせるのが後々楽です。

入ったかどうかは、バージョンを聞いてみるのが手っ取り早いです。

❯ mise --version
2026.9.4 windows-x64 (2026-09-09)

このように、バージョン・プラットフォーム・ビルド日が返ってくれば成功です。command not found になる場合は、まだ PATH が通っていません。インストーラーが最後に出す案内のとおりに、シェルを開き直してから試してください。

ツールを入れて、使う

ツールを入れるコマンドは mise install です。@ の後ろにバージョンを書きます。

❯ mise install node@22
...
mise ✓ node@22.23.2  28.3s  node-v22.23.2-win-x64.zip
mise ████████████████ 1/1 · installed 1 tool in 28.3s
mise WARN  node installed but not activated — it is not in any config file.
To install and activate, run:
  mise use node

別のバージョンも並べて置けます。入っているものは mise ls で一覧できます。

❯ mise install node@20
...
❯ mise ls
node  20.20.2
node  22.23.2

ただし、入れただけでは node と打っても動きません。インストールの最後に出ていた not activated の警告がそれで、mise が入れたツールは PATH に置かれていないからです。実行するには mise exec を挟みます。

❯ node --version
bash: node: command not found
❯ mise exec node@22 -- node --version
v22.23.2

-- の前が「どのツールで」、後ろが「何を実行するか」です。

ここまでは、正直なところ Homebrew や apt でツールを入れて使うのと大きく変わりません。バージョンを並べて持てるのは便利ですが、それだけなら nvm や pyenv でもできます。

ここからが mise の本領

mise が他と違うのは、設定が「打った人」ではなく「ディレクトリ」に結びつくところです。そのための道具が 2 つあります。

mise activate — 打たなくても切り替わるようにする

シェルの設定ファイルに 1 行足します。

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

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

# プロファイルが無ければ作ってから追記する
if (-not (Test-Path $PROFILE)) { New-Item -ItemType File -Path $PROFILE -Force }
Add-Content -Path $PROFILE -Value '(&mise activate pwsh) | Out-String | Invoke-Expression'

これを入れると、mise exec が要らなくなります。ディレクトリに入った時点で、そこで使うバージョンに PATH が差し替わるからです。blog に node = "26"、old-app に node = "22" と書いた mise.toml を置いて、有効化したシェルで行き来してみます。

❯ cd blog
❯ node --version
v26.8.2
❯ cd ../old-app
❯ node --version
v22.23.2

nvm use のような打ち忘れる操作が無くなる、というのがここでの要点です。

mise use — 設定をファイルに残す

では、そのディレクトリで使うバージョンはどこに書いてあるのか。それが mise.toml で、それを書くコマンドが mise use です。

❯ mise use node@22
mise by @jdx – installing 1 tool
mise ⇢ node@22.23.2  96ms · already installed
mise ████████████████ 1/1 · installed 0 tools · 1 already installed in 130ms
mise C:\Users\Jam\AppData\Local\Temp\misedemo\work\app\mise.toml tools: node@22.23.2

このコマンドは 2 つのことを同時に行います。Node.js 22 をインストールし、mise.toml に書き込む。ここでは入れてあったので、インストールは飛ばして書き込みだけが行われました。

❯ cat mise.toml
[tools]
node = "22"

ここが mise install との違いです。自分の環境にツールを置くだけで終わらせず、プロジェクトの設定として残す。それが mise use です。

このファイルをコミットすれば、次に clone した人は mise install だけで同じバージョンが揃います。「Node は 22 を使ってください」と口頭で伝える必要がなくなります。

そのツールはどこから来るのか — バックエンド

mise install node@22 と打ったとき、mise はどこから node を取ってくるのか。ここを知らないと、この節の後半で紹介するような形で足を取られます。

mise は 1 つの方法でツールを取ってくるわけではありません。バックエンドと呼ばれる入手経路を複数持っていて、ツールごとに使い分けています。

短い名前がどこに解決されるか

node や ffmpeg のような短い名前を書いたとき、どの経路になるかは mise のレジストリが決めています。調べるコマンドがあります。

❯ mise registry node
core:node

複数の候補を持つツールもあります。

❯ mise registry ripgrep
aqua:BurntSushi/ripgrep cargo:ripgrep

候補が並んでいるときは左から順に試されます。ripgrep なら、まず aqua のビルド済みバイナリを取りにいって、駄目なら cargo で手元ビルドに落ちる、という順です。

短い名前を信じて 9 分待たされた話

このブログのリポジトリで ffmpeg が必要になったとき、素直にこう書きました。

mise install ffmpeg@latest

9 分経っても終わりませんでした。ログにはこう出ていました。

ffmpeg@9.0.1  installing tzdata  525.0s

タイムゾーンのデータベースは、動画のエンコードとは何の関係もありません。理由はレジストリを見れば分かります。

❯ mise registry ffmpeg
conda:ffmpeg

conda パッケージとして解決されるので、依存ツリーごと展開していたわけです。ffmpeg 自体は 1 つの実行ファイルで済むのに、パッケージマネージャの都合でそうなっていません。

経路を自分で指定する

GitHub Releases から直接取れば済む話でした。

mise install "github:BtbN/FFmpeg-Builds[exe=ffmpeg]@autobuild-2026-09-08-23-15"

112 秒で終わりました。mise.toml にはこう書きます。

[tools]
"github:BtbN/FFmpeg-Builds" = { version = "autobuild-2026-09-08-23-15", exe = "ffmpeg" }

exe=ffmpeg が必要なのは、mise が既定でリポジトリ名から実行ファイル名を推測するためです。ここでは FFmpeg-Builds.exe を探しにいって見つからず、失敗します。

バージョンを固定しているのにも理由があります。このリポジトリが配っているのはリリース版ではなく日付つきの master ビルドで、latest にすると公開されるたび（ほぼ毎日）に数百 MB を取り直すことになります。

どれを選ぶか

• 迷ったら短い名前のままでよい。たいていのツールは妥当な経路に解決されます
• 遅い・入らないと感じたら mise registry で経路を確認する。原因はここにあることが多い
• 検証を重視するなら aqua。展開する前にチェックサムと署名を確認します
• レジストリに無い、または新しすぎるものは github:。その代わり、実行ファイル名とバージョンの面倒は自分で見ることになります

よく使うコマンド

mise ls              # 入っているもの
mise ls-remote node  # 入れられるバージョン
mise install         # mise.toml のものを揃える
mise upgrade         # 更新する
mise doctor          # 設定の診断

まとめ

• mise install は自分の環境に入れるだけ、mise use はプロジェクトの設定として残す
• mise activate を入れておけば、ディレクトリに入るだけで版が切り替わる
• 遅い・入らないと感じたら mise registry でバックエンドを疑う

「手元では動く」を減らすための道具です。設定ファイルが 1 つ増える代わりに、口頭とREADMEで伝えていた前提がコードになります。