2026-06-15
自分の.zshrcを見返すと、言語やランタイムごとに管理ツールがバラバラに増えていました。
~/.volta）~/.cargo/env）/usr/local/go、GOPATHを手動設定）~/.deno）~/.moon）~/.bun）新しい言語を触るたびに「これはどうやって入れるんだっけ」と調べ、.zshrcにPATHや初期化処理を1ブロックずつ書き足す、ということを繰り返していました。
その結果、.zshrcはランタイム関連の設定だけで何ブロックにもなり、それぞれインストール方法もアップデート方法もコマンドも違うという状態に。
特に困るのが新しいマシンのセットアップで、ツールを1つずつインストールし直す必要があり、地味に時間がかかっていました。 バージョンを固定したいプロジェクトがあっても、ツールごとにやり方が違うので統一感もありません。
そろそろ整理したいと思い、ランタイム管理をmiseに一元化することにしました。
mise は、複数の言語・ランタイムのバージョンを1つのツールでまとめて管理できるバージョンマネージャーです。 Rust製で動作が速く、asdfの後継のような立ち位置で使われています。
前のセクションで挙げたように、これまでは言語ごとに別々のツールを使っていました。 miseを使うと、それらを同じコマンド体系で扱えるようになります。
Volta、rustup、Goの直接インストール……とバラバラだったものが、すべてmise useに統一されるイメージです。
.zshrcに言語ごとの初期化処理を書き足していく必要もなくなります。
さらに、プロジェクトのディレクトリに入ると設定に応じてバージョンが自動で切り替わるので、複数プロジェクトを行き来してもバージョンを意識せずに済みます。
バージョン管理以外にも、環境変数の管理（env）や簡単なタスクランナーの機能も持っていますが、今回はランタイムの一元管理が目的なので、まずはそこにフォーカスして移行しました。
インストールは公式のスクリプトを使いました。
インストールできたら、シェルで有効化します。
自分はzshを使っているので、.zshrcに以下を追記しました。
command -vでmiseの存在を確認してからactivateしているのは、miseが入っていない環境で.zshrcがエラーにならないようにするためです。
dotfilesを複数マシンで共有しているので、こういう小さな防御を入れておくと安心です。
設定したらシェルを再起動し、mise --versionが表示されれば準備完了です。
これまで使っていたツールを、すべてmiseに寄せていきます。
まずは.zshrcから、各ツールの初期化処理を削除します。
miseと古いツールが両方有効になっていると、which nodeがどちらを指しているのか分からなくなるので、ここは確実に外しておきます。
言語ごとに何ブロックもあった設定が、miseの数行だけで済むようになります。
.tool-versionsのような既存の設定ファイルは使っていなかったので、必要な言語をmiseでグローバルに入れ直しました。
mise use -gを実行すると、対象がインストールされてグローバルの設定ファイルに追記されます（設定ファイルの中身や使い分けは後述します）。
なお、asdfの
.tool-versionsを使っていた場合は、miseがそのまま読み込めるので移行はさらに簡単です。
移行で一番ハマったのは、古いツールのPATHやshimが残っていて、そちらが優先されてしまうことでした。
.zshrcを直したつもりでも、which nodeを確認するとまだVoltaのshimを指していたりします。
該当のexport PATHを消し、シェルを完全に再起動することで解決しました。
設定がうまくいっているか不安なときはmise doctorが便利です。
PATHの問題や設定ミスを診断してくれるので、移行直後のチェックに使えます。
移行が終わったら、あとは普段の操作を覚えるだけです。
miseの使い方はシンプルで、基本はmise useで完結します。
miseは、プロジェクトごとに使うバージョンを固定できます。
プロジェクト直下にmise.tomlを置いておくと、そのディレクトリにいる間は自動でそのバージョンが使われ、別のプロジェクトに移れば勝手に切り替わります。
そのため、すでにmise.tomlがあるプロジェクト（cloneしてきたリポジトリなど）でも、簡単にバージョンを揃えられます。
プロジェクトに入ったら、次の流れで使い始めます。
自分で書いていないmise.tomlがあると、miseは「このファイルを信頼してよいか」を確認してきます。
これは知らない設定ファイルが勝手に実行されるのを防ぐための仕組みで、内容を確認して問題なければmise trustで信頼を登録します。
そのうえでmise installを実行すると、mise.tomlに書かれたバージョンがインストールされ、あとはそのプロジェクトのディレクトリにいる間、自動でそのバージョンが使われるようになります。
チームでmise.tomlを共有しておけば、cloneしてきた人もこの2コマンドで全員同じバージョンに揃えられるわけです。
なお、一度信頼すれば次回以降は聞かれなくなります。逆に信頼を取り消したいときはmise trust --untrustを実行します。
バージョンの設定はmise.toml（グローバルはconfig.toml）というファイルで管理されます。
中身はこんな感じで、人が読んでもすぐ分かります。
使うバージョンは、このmise.tomlに書いてからmise installを実行する、という流れでインストールします。
mise useがファイルへの追記とインストールを同時にやってくれるのに対し、こちらは「設定ファイルを先に用意しておき、あとからまとめて入れる」やり方です。
そのため、このファイルをdotfilesやリポジトリにコミットしておけば、新しいマシンやチームメンバーの環境でもmise install一発で同じバージョンを揃えられます。
自分はグローバルのconfig.tomlをdotfilesで管理するようにして、マシンを新しくしてもmise installだけで開発環境が再現できるようにしました。
普段使うコマンドはこのあたりです。
ほとんどの操作がmise <サブコマンド>で統一されているので、言語ごとにコマンドを覚え直す必要がないのが快適です。
実際に移行してみて、まず驚いたのは言語の環境構築がとても簡単になったことです。
これまでは新しい言語を入れるたびにインストール方法を調べ、.zshrcに設定を書き足して……という手間がありましたが、miseに寄せてからはmise useだけで完結します。
覚えることが減り、環境構築にかかる時間も体感でかなり短くなりました。
移行作業そのものも、心配していたほど大変ではありませんでした。 特にハマることもなく、想像以上にあっさり終わったというのが正直な感想です。
良かった点をまとめると、こんな感じです。
mise useで入るので、調べ物や.zshrcいじりが要らなくなった.zshrcがスッキリした — 言語ごとに散らばっていた設定がmiseの数行にまとまったmise install一発複数の言語を触る人ほど、miseに一元化する恩恵は大きいと感じました。