はじめに
開発環境のツールバージョン管理に asdf を使ってきましたが、最近話題になっている mise に興味を持ち、試してみたところ非常に快適だったため本格的に移行しました。
この記事では、実際に半年程度 mise を使ってみた感想や asdf との違い、移行手順、使用上の注意点などをまとめます。
結論：miseは学習コストが低く、体感的に快適
- 初期構築が圧倒的に簡単
-
.tool-versionsに加えてmise.tomlによる明示的記述も可能 -
mise install一発で必要なツールをまとめて導入 - shimを使わずPATHで直接ランタイムを呼び出すため、動作が軽快
-
asdfと互換性があるため、既存プロジェクトからの移行もスムーズ
asdf に感じていた課題
asdf は多くの言語・ツールのバージョン管理を一元的に扱える、非常に優れたマルチランタイムマネージャーです。
豊富なプラグインエコシステムや direnv との相性の良さ、カスタマイズ性の高さなど、今もなお多くの開発者に支持されています。
私自身も asdf を活用してきましたが、以下のような点で日常的に感じていた小さな課題をきっかけに、 mise への移行を試してみました。
- コマンドが私にとって直感的ではないので、覚えづらい
-
.tool-versionsの内容とpluginの関連性が初心者にはわかりにくい - 新規環境構築時に
asdf installが失敗することがある - shimを経由した実行により若干の遅延を感じる場面がある
miseの特徴と強み
| 特徴 | 内容 |
|---|---|
| pluginの自動取得 |
.tool-versions に書くだけでlazy installされる |
mise.toml |
明示的にTOML形式でツールとバージョンを記述可能 |
| PATH直実行 | shimスクリプトを使わず直接PATHから実行されるため高速 |
| asdf互換 |
.tool-versions やplugin資産をそのまま流用可能 |
| タスクランナー内蔵 |
mise runでMakefile代替のようなタスク実行が可能 |
| 環境変数の定義・管理 |
.envやmise.tomlで環境変数のセット・読み込みが可能 |
asdf → mise への移行手順
前提
- macOS 14.7
- GNU bash, バージョン 5.3.3(1)-release (aarch64-apple-darwin23.6.0)
- Homebrew 4.5.12
公式の手順(参考)
1. miseのインストール
brew install mise
2. .tool-versions をそのまま利用、もしくは mise.toml を追加
[tools]
node = "20.0.0"
python = "3.12.0"
3. 必要なツールをインストール
mise install
4. シェルへのPATH統合
echo 'eval "$(mise activate zsh)"' >> ~/.zshrc
補足：パフォーマンスについての最近の傾向
mise はパフォーマンスに定評のあるツールですが、最近では asdf にも Go 製の実装が登場しており、以前ほどの速度差はない可能性があります。
とはいえ、mise が体感的に「速い」と感じる理由として、shim（中継スクリプト）を経由せず PATH で直接実行する構造が挙げられます。
asdf: <your command> → shim → runtime
mise: <your command> → PATH直実行（mise activateで管理）
公式比較：mise vs asdf（mise公式ベース）
mise の比較ページでは以下のように説明されています：
-
.tool-versionsはそのまま利用でき、asdfプラグインも扱えるが、既存の asdfインストールは再構築が必要。 - Go実装になった asdf-go はパフォーマンスが改善されたものの、mise の shimレス設計が依然として体感速度に有利。
まとめ：asdfとmiseの比較表（2025年時点）
| 比較軸 | asdf（最新） | mise |
|---|---|---|
| 実行速度 | Go製実装により改善中 | shimレス設計により体感的に高速 |
| shimの仕組み | shimスクリプトを経由 | PATHで直接呼び出し（activate方式） |
| plugin管理 | ショートネームとGit URL対応 | lazy installで自動取得 |
| 記述形式 |
.tool-versions のみ |
.tool-versions or mise.toml
|
| 初期構築 | plugin installが必要 |
mise install 一発でOK |
| シェル統合 |
asdf shell, global/local
|
mise activate でPATH設定 |
| タスクランナー | 外部（make等） | built-inでタスク管理可能 |
| 環境変数管理 | 外部（direnv等） | built-inでenv管理可能 |
| 開発状況 | 活発（Go実装開発中） | 活発（独自路線で進化中） |
mise 応用編：タスクランナー・環境変数管理まで
1. タスクランナーとしての mise run
mise にはビルトインのタスクランナー機能があり、Makefile や npm scripts の代替として使えます。
[tasks.build]
description = "Build the App"
run = "npm run build"
[tasks.test]
description = "run test"
run = "pnpm test"
depends = ["build"]
env = { NODE_ENV = "test" }
実行例：
mise run test
また、引数なしで mise run を実行すると、インタラクティブな選択画面が表示されて便利です（タスク名を覚える必要がなく、説明文も確認できます）：
mise run
Tasks
Select a task to run
❯ build Build the App
test run test
/
2. 環境変数の安全な管理（experimental）
これまで mise での環境変数管理は使ったことがありませんでしたが、今回記事を書くにあたって試してみました。特に、チーム開発における .env ファイルの安全な共有という観点から、今後の活用可能性を検討しています。
mise では mise.toml や .env に加え、暗号化された .env.json を読み込むことも可能です。
ステップ1：.env.json作成と設定
{
"EXAMPLE_SECRET":"example"
}
[env]
_.file = ".env.json"
ステップ2：暗号化の準備と実行
mise use sops@
mise use age@
age-keygen -o ~/.config/mise/age.txt
sops encrypt -i --age "<Public Key>" .env.json
mise env
出力結果：
export EXAMPLE_SECRET=example
ステップ3：編集・確認
export SOPS_AGE_KEY_FILE=~/.config/mise/age.txt
# 編集
sops edit .env.json
値を変更して保存します：
1 {
2 ▸---"EXAMPLE_SECRET": "example2"
3 }
# 環境変数確認
mise env
出力結果：
export EXAMPLE_SECRET=example2
- 暗号化された
.env.jsonをGitにコミットしても安全 -
mise activateだけで復号・読み込み可能
※なお、今回試したように mise + sops/age を用いた環境変数管理は便利ですが、秘密鍵をそのままメンバー間で共有するのはセキュリティ上好ましくありません。
代替として、age の「複数人対応暗号化」や、CI/CD側での復号実行などの運用を検討するのが現実的だと感じました。
age の複数人対応暗号化について（チーム活用向け）
今回、試験的に mise＋sops/age で環境変数暗号化を試してみましたが、より実用性を高める手法として age の公開鍵を複数指定して暗号化するアプローチを検討しています。これにより、秘密鍵をメンバーで共有せずに、安全な運用が可能になります。
例えば、以下のように複数の公開鍵を使って暗号化できます：
sops encrypt -i --age "<publicKeyA>,<publicKeyB>" .env.json
この構成なら、各メンバーは自分専用の秘密鍵だけをローカル保持し、必要に応じて復号可能です。CI/CD用に秘密鍵を集約する必要もなく、よりセキュアなチーム運用が期待できます。
特に CI/CD パイプラインや 公開鍵ベースのアクセス制御を活用するチームには有効な手法だと感じました。運用負荷も比較的低く、導入を検討する価値があると思います。
もしチームで
miseの環境変数管理を活用している方がいれば、運用方法などぜひ知りたいです！