この記事でわかること
nvmやpyenv、rbenvのように言語ごとにバージョン管理ツールを使い分けている環境を、1本のCLIに置き換えられないか探す中で見つけたのが「mise」（https://github.com/jdx/mise ）です。この記事は公式GitHubリポジトリとCHANGELOGを一次情報としつつ、実際にリリースバイナリを取得してこの検証環境で動かした記録です。
- この記事でわかること：miseが何を管理するツールで、設定がどこに集約されるか。
- 実際にv2026.9.13のバイナリを取得し、`mise doctor`や`mise registry`で確認できた具体的な数字。
- `mise.toml`にタスクと環境変数を書いて、依存関係付きで実行してみた結果。
- 設定ファイルを無条件に実行しないための`trust`という安全機構。
- asdfとの関係：`.tool-versions`とasdf shell-pluginインターフェースへの対応。
miseとは：Tools・Env・Tasksを1つのCLIにまとめる開発環境マネージャー
GitHubリポジトリの説明文は「dev tools, env vars, and tasks in one CLI」です。公式ドキュメントの解説ページによると、名前の由来はフランス料理用語の「mise en place」（調理前の下ごしらえ）で、開発に取りかかる前の準備を整えるという発想からきています。プロジェクトの`mise.toml`は「作業開始に必要なツール、環境、コマンドを記録する」ファイルだと説明されています。
公式が挙げる主な機能は4つです。（1）Tools：Node.js、Python、Goなど数百のランタイム・CLIツールをプロジェクトごとに異なるバージョンでインストールし、ディレクトリ移動に応じて自動で切り替える、（2）Environments：プロジェクト単位の環境変数を定義し、dotenvファイルやシークレット、Pythonの仮想環境なども有効化する、（3）Tasks：ビルド・テスト・lintなどのコマンドに名前・依存関係・引数を付けて管理する、（4）Bootstrap：OSパッケージやdotfiles、サービスなどマシンのセットアップ自体を宣言する、というものです。ライセンスはMITで、LICENSEファイルには開発者Jeff Dickey氏の著作権表記があります。
設定は`mise.toml`ひとつに集約される
nvmやpyenvは言語ごとに別のツール・別の設定ファイル（`.nvmrc`、`.python-version`など）を使いますが、miseはツールのバージョン、環境変数、タスクの3つをすべて`mise.toml`という1ファイルに書きます。公式ドキュメントは「この設定をコミットしておけば、シェルでもエディタでもCIでも同じセットアップを使い回せる」と説明しています。
この一元化は、後述するタスクランナーと組み合わさると効いてきます。特定バージョンのNode.jsやGoを使う設定と、そのツールを前提にしたビルド・テストコマンドを同じファイルに書けるため、「このリポジトリで何を使ってどう動かすか」がREADMEを読まなくても`mise.toml`を見ればわかる状態になります。
実際にリリースバイナリを取得して動かしてみる
この検証環境ではインストールスクリプト（`mise.run`）や公式ドキュメントサイト（`mise.jdx.dev`）にネットワークポリシー上アクセスできなかったため、GitHub Releasesから`mise-v2026.9.13-linux-x64.tar.gz`を直接取得しました。展開した`mise`バイナリを実行すると、バージョンは`2026.9.13 linux-x64 (2026-09-24)`と表示されました。検証を行った2026年9月24日当日にリリースされたビルドです。
`mise doctor`を実行すると、ビルド情報として`Target: x86_64-unknown-linux-gnu`、`Rust Version: rustc 1.94.0`、`Profile: release`が確認でき、Rust製であることが実機の出力から裏取りできました。同じ出力には「aqua: baked in registry tools: 2309」という行もあり、mise自身のショートハント一覧である`mise registry`コマンドの出力（実測1,056件）とは別に、バックエンドの一つである`aqua`プロジェクトのレジストリだけで2,309件のツールが同梱されていることもわかりました。`mise registry`の各行を見ると、1つのツール名に対して`aqua:`、`asdf:`、`cargo:`、`go:`、`github:`、`vfox:`など複数のインストール方法（バックエンド）が併記されており、miseはこれらのバックエンドを束ねる形で数百〜千を超えるツールに対応していることが読み取れます。
タスクランナーを試す：依存関係と環境変数の注入
実際に次のような`mise.toml`を書いて`mise run build`を実行しました。
```toml [env] GREETING = "hello from mise" [tasks.hello] description = "say hello" run = "echo $GREETING" [tasks.build] description = "build step" depends = ["hello"] run = "echo building..." ```
結果は`[hello] $ echo $GREETING` → `hello from mise` → `[build] $ echo building...` → `building...`という順で出力され、`depends`で指定した依存タスクが先に実行されたことと、`[env]`で定義した`GREETING`が子プロセスに渡っていたことの両方を確認できました。`mise env`コマンドでも`export GREETING='hello from mise'`が出力され、シェルにそのままevalして環境変数を反映する使い方も可能なことがわかります。
もう一つ実機で確認できたのが、未知の設定ファイルをいきなり実行しない仕組みです。`mise.toml`を新規に置いたディレクトリで最初にタスクを動かそうとすると、`Config files in ... are not trusted. Trust them with 'mise trust'.`という趣旨のエラーが出ることがあり、`mise trust`を明示的に実行して初めてタスクや環境変数が有効になります。他人のリポジトリをcloneしてすぐ`mise run`する運用では、この確認ステップが任意コード実行の抑止になる設計だと理解しました。
asdfとの関係：`.tool-versions`とasdf shell-pluginに対応
公式FAQは「mise supports `.tool-versions` and the asdf shell-plugin interface on Unix.」と明記しています。つまり、既存のasdf運用で使っていた`.tool-versions`ファイルをそのまま読める互換性があり、asdf用に作られたシェルプラグインの仕組みにも対応しています。一方でコマンド体系はmise独自で、バージョン切り替えは`mise use`、環境変数の設定は`mise set`というように、asdfのサブコマンドとは名前が異なる点はFAQ自身が注意点として挙げています。
既存プロジェクトに導入する場合は、`.tool-versions`を残したままmiseのバイナリだけ入れ替えて動作を確認し、チームの合意が取れてから`mise.toml`への移行やタスク定義の追加に進む、という段階的な移行がしやすい設計だと読み取れます。
導入前に確認しておきたい点
この検証環境はネットワークポリシー上GitHub APIへのアクセスが制限されており、`aqua`バックエンド経由でのツールインストール（`mise use jq@1.7.1`など）を試すと`403 Forbidden`でインストールが失敗しました。miseの多くのバックエンドはGitHub Releases APIに強く依存しているため、社内プロキシやファイアウォールでGitHub APIへのアクセスを絞っている環境では、事前にどのホストへの通信が必要かを確認しておく必要があります。
また、CHANGELOGを見る限りリリース頻度はかなり高く、確認できた直近だけでも2026-09-17（2026.9.11）、2026-09-20（2026.9.12）、2026-09-24（2026.9.13）と数日おきに更新されていました。CIやチームで導入する場合は、`mise.toml`側でmise自体やツールのバージョンをどこまで固定するか、更新をどう追従するかを決めておくと運用が安定しそうです。
まとめ
miseは、言語ごとに分かれがちなバージョン管理・環境変数・タスク実行を`mise.toml`という1つの設定ファイルと1本のCLIに統合するツールです。実際にバイナリを取得して動かしてみると、Rust製であることや、aquaをはじめ複数のバックエンドを束ねて数百〜数千のツールに対応している実装がdoctorコマンドの出力から確認でき、タスクの依存関係実行や環境変数の注入、未信頼な設定ファイルを実行前に確認する`trust`機構も期待通りに動作しました。
asdfの`.tool-versions`をそのまま読める互換性があるため、既存のasdf運用からの段階的な移行もしやすい設計です。一方でGitHub APIへの依存度が高いツールという性質上、社内ネットワークの制限がある環境では事前の疎通確認をおすすめします。
参考リンク
- mise 公式サイト
- https://mise.jdx.dev/
- mise 公式GitHubリポジトリ（README・LICENSE）
- https://github.com/jdx/mise
- CHANGELOG（バージョン履歴）
- https://github.com/jdx/mise/blob/main/CHANGELOG.md
- FAQ（asdfとの関係を含む）
- https://github.com/jdx/mise/blob/main/docs/faq.md
- About（ツールの目的と主な機能）
- https://github.com/jdx/mise/blob/main/docs/about.md
- LICENSE（MIT License）
- https://github.com/jdx/mise/blob/main/LICENSE
