---
title: "miseとは？mise.tomlでツール・環境変数・タスクを束ねる導入手順【2026年版】"
url: "https://www.issoh.co.jp/tech/details/17621/"
published: 2026-09-15
updated: 2026-09-15
categories: ["開発"]
publisher: "株式会社一創"
---

# miseとは？mise.tomlでツール・環境変数・タスクを束ねる導入手順【2026年版】

miseは、Node.jsやPythonといった開発ツールの版、プロジェクト固有の環境変数、ビルドやテストのタスクを1つのコマンドで扱うRust製のツールです。読み方は「ミーズ」で、フランス料理の下ごしらえ（mise-en-place）が名前の由来になっています。ディレクトリを移動するだけで案件ごとの版へ切り替わるため、nvmとdirenvとMakefileに分かれていた役割をまとめられます。導入手順、mise.tomlの探索順序、activateとshimsの選び分け、mise.lockによる固定、CIでの共有までを公式ドキュメントで追い、受託開発で入れてよい条件と見送る場面まで整理しました。

## まとめ：miseが効く開発現場と、入れても効果が薄い現場の線引き

miseで時間が浮くのは、1人が複数案件を行き来し、案件ごとにNode.jsやPythonの版が揃っていないチームです。mise.tomlをリポジトリへ入れておけば、参加初日の手順は「miseを入れる」「リポジトリでmise installを叩く」の2手で済みます。READMEの「Node 20を入れてからnvmで切り替えて」という説明文が要らなくなる、というのが実際の効き目でしょう。

逆に、開発も実行もDockerイメージの中で完結するチームでは得るものが小さくなります。ツールの版はDockerfileで固定済みだからです。導入するなら、activateとshimsのどちらでPATHを通すか、lockfileを有効にするかの2点を最初に決めてください。曖昧なまま配ると、手元では動くのにCIやcronだけ落ちます。

## mise-en-placeがツール・環境変数・タスクを1つのCLIで束ねる仕組み

miseは単体で完結するバイナリとして配布されます。[GitHubのjdx/miseリポジトリ](https://github.com/jdx/mise)はRust製・MITライセンスで、2026年9月時点のスター数は33.9kです。

### ツール管理・環境変数・タスク実行を1つのバイナリで賄う全体像

公式リポジトリはmiseを「Dev tools, env vars, and tasks in one CLI」と説明しています。担当は3領域。Node.js・Python・Goなどツール版の管理、プロジェクト単位の環境変数と.envの読み込み、ビルドやテストのタスク実行です。

従来はバージョン管理にasdfやnvm、環境変数にdirenv、タスクにMakefileと道具が分かれていました。miseはこれをmise.tomlの`tools`・`env`・`tasks`の3セクションで表現します。パッケージマネージャ自体の版をどこで固定するかは別の論点なので、[pnpmとは？共有ストアの仕組みとv12のRust実装・モノレポ運用を解説](https://www.issoh.co.jp/tech/details/17573/)と合わせて決めてください。

### Packslipやaquaなど2026年時点で選べるバックエンドの現状

ツールの入手経路は「バックエンド」で決まります。[公式のBackendsページ](https://mise.jdx.dev/dev-tools/backends/)が挙げるのは、署名付きマニフェストのPackslip、キュレーション済みレシピのAqua、GitHub・GitLab・Forgejoのリリースアセット、HTTPとS3からの直接ダウンロード、Cargo・Go・npm・pipx・gem・.NET・Swift Package Managerなどの言語パッケージ、Condaと実験的なpkgx、プラグイン定義のvfoxとレガシー扱いのasdf、非推奨のubiです。

ここは2026年に動いた部分です。数年前の解説が勧めるubiは非推奨、asdfプラグインはレガシーへ変わりました。版番号も独特で、[リリースページ](https://github.com/jdx/mise/releases)のv2026.9.9は2026年9月15日、v2026.9.8は9月14日と、日付をそのまま使うカレンダーバージョニングで毎日のように更新されています。社内へ配るならバイナリの版を固定しておきましょう。

## インストールからmise.toml作成までの最短手順と動作確認コマンド

導入は数分で終わります。[公式のGetting startedページ](https://mise.jdx.dev/getting-started.html)の手順に沿って、シェルへの組み込みまで通します。

### curlワンライナーでの導入とシェルごとのactivate設定

インストーラはmise.runから取得します。展開先は`~/.local/bin/mise`で、シェルの起動ファイルにactivateを1行足せば準備は完了です。zshなら次のようになります。

```
curl https://mise.run | sh
~/.local/bin/mise --version
echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
exec $SHELL -l
mise doctor
```

bashなら`mise activate bash`を.bashrcへ、fishならconfig.fishへ書きます。最後の`mise doctor`は設定の読み込み状態と検出した問題を並べて返すため、切り替わらないときの最初の確認先になります。

### mise use でnode 24を固定しmise.tomlへ書き出す流れ

使う版を決めるコマンドは`mise use node@24`です。ツールが入り、カレントディレクトリのmise.tomlへ設定が書き出されます。グローバル既定にするなら`mise use --global node@24`、単発なら`mise exec node@24 -- node --version`と呼びます。

```
[tools]
node = { version = "24", postinstall = "corepack enable" }
python = "3.13"

[env]
NODE_ENV = "development"

[tasks.test]
run = "npm test"

[settings]
lockfile = true
```

postinstallにはツール導入後の処理を書けます。上の例で呼ぶcorepackの挙動は[corepackでpnpmを管理する方法｜corepack enable・prepareの使い方](https://www.issoh.co.jp/tech/details/2765/)で整理しました。設定後は`mise ls --current`で効いている版を確認します。

## mise.tomlの探索順序と環境別ファイルを使い分ける設定の組み立て

miseは1つのファイルだけを読むわけではありません。複数の場所を決まった順序で探し、深いディレクトリの設定が浅い側を上書きします。[公式のConfigurationページ](https://mise.jdx.dev/configuration.html)の順序を押さえておくと、意図しない版が効いたときの調査が早く終わります。

### mise.local.tomlとmise.tomlの優先順位と秘匿値の置き場所

優先度が高い順に、mise.local.toml、mise.toml、mise/config.toml、mise/conf.d配下、.mise/config.toml、.mise/conf.d配下、\~/.config/mise/config.toml、/etc/mise/config.tomlの8階層です。役割は次のように分けます。

- mise.toml：チーム共通の版とタスク。リポジトリにコミットする
- mise.local.toml：個人の上書きと秘匿値。gitignoreへ入れる
- \~/.config/mise/config.toml：どの案件でも使う道具のグローバル既定

APIトークンをenvセクションへ直書きしてコミットする事故は、mise.local.tomlを知らないまま使い始めたときに起こります。

### MISE\_ENVとプラットフォーム別ファイルで設定を切り替える書式

環境ごとに接続先や版を変えたい場合は、mise.development.tomlのように環境名を挟んだファイルを置き、環境変数`MISE_ENV`で選びます。MISE\_ENV=developmentなら、mise.tomlに重ねてmise.development.tomlが読まれる仕組みです。

プラットフォーム別の分岐も同じで、mise.windows.tomlやmise.macos-arm64.tomlを置けば実行環境に応じて選ばれます。WindowsとmacOSが混在する受託チームでは、共通のツール版をmise.tomlに、OS固有のパスだけをプラットフォーム別ファイルへ書くと1つのリポジトリで両方を賄えます。分岐を増やすほど読み解けなくなるため、分けるのはOS依存が避けられない設定に限る方針です。

## PATH書き換えとshimsの違い・IDEやcronで動かないときの対処

版を切り替える方法は2通りあります。既定のactivate方式と、shimsを使う方式です。[公式のShimsページ](https://mise.jdx.dev/dev-tools/shims.html)は両者の差を挙動レベルで説明しており、トラブルの多くはこの選択に起因します。

### プロンプト更新型のactivateが非対話シェルで効かない理由

activate方式は、シェルがプロンプトを出すたびにPATHと環境変数を更新します。ディレクトリ移動に反応するcdフックやenvセクションの環境変数が完全に動くのはこちらです。裏を返すと、プロンプトを出さない実行経路では何も起きません。cronのジョブ、CIのスクリプト、エディタが裏で起動するプロセスが該当します。

| 観点        | activate  | shims     |
| --------- | --------- | --------- |
| PATH更新の時点 | プロンプト表示ごと | コマンド呼び出し時 |
| envと各種フック | すべて動作     | 環境変数のみ    |
| 非対話の実行経路  | 読み込まれない   | PATH上なら動く |
| whichが返す先 | 実体のパス     | shimのパス   |

非対話の経路について、公式は`mise exec`や`mise run`で明示的に環境を読み込む方法を勧めています。

### shims方式でIDEに固定パスを渡すときに失うフックの機能

shims方式は、\~/.local/share/mise/shims以下に小さな実行ファイルを置き、呼ばれた時点で環境を読み込みます。IDEの設定画面にPythonインタプリタの絶対パスを入れる場面では、この安定したパスが役に立つでしょう。有効化は`mise activate zsh --shims`を.zprofileへ書くだけです。

代償もあります。cdやenterなどのフックはactivateでしか動かず、whichの結果もshimのパスになります。実務では、対話シェルはactivate、IDEやcronだけshimsという併用が扱いやすく、どちらを標準にするかはREADMEに明記してください。

## mise.lockでバージョンとチェックサムを固定する再現性の担保

mise.tomlに書くのは「node = 24」という要求であって、実際に入る版ではありません。24系の最新が更新されれば手元とCIでずれます。この差を埋めるのが[mise.lock](https://mise.jdx.dev/dev-tools/mise-lock.html)です。

### lockfile設定の有効化とmise install –lockedの厳密モード

ロックファイルは既定で自動生成されません。有効にするには、mise.tomlのsettingsセクションへ`lockfile = true`を書きます。ユーザー全体の既定にするなら`mise settings set lockfile=true`です。未設定だと、既存のロックファイルは更新されるものの新規作成は行われません。

記録されるのは解決後のversion、インストールに使ったbackend、元の要求を示すspecifiersです。CIで`mise install --locked`を使えば、記録に無いエントリはエラーになります。要求の書き換えが混ざったまま通過する事故を止められるので、チーム開発では厳密モードを既定にしてください。

### プラットフォーム別チェックサムが効く場面と壊れやすい更新手順

mise.lockはプラットフォームごとにメタデータを持ちます。macos-arm64やlinux-x64といった単位で、SHA256またはBlake3のchecksum、アーティファクトのurl、検証方法を示すprovenanceが並ぶ構造です。配布元が差し替わったときに気づけます。

つまずくのは、macOSの開発者だけがロックを更新してコミットしたときです。LinuxのCI向けエントリが無ければ、厳密モードのCIはそこで止まります。版を上げる作業は、対象プラットフォームぶんのエントリが揃っているかを確認してからマージする手順にしてください。

## GitHub ActionsとGitLab CIで同じmise.tomlを共有する設定例

CIでは対話シェルを有効化する必要がありません。[公式のContinuous integrationページ](https://mise.jdx.dev/continuous-integration.html)は、開発環境と同じmise.tomlを読み、mise execまたはmise run経由でコマンドを走らせる構成を示しています。

### jdx/mise-action@v4を使うGitHub Actionsの最小構成

GitHub Actionsには[jdx/mise-action](https://github.com/jdx/mise-action)が用意されています。チェックアウト直後に1ステップ足すだけで、mise.tomlのツールがセットアップされます。

```
name: test
on:
  pull_request:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: jdx/mise-action@v4
      - run: mise exec -- npm ci
      - run: mise exec -- npm test
```

ロックファイルを使っているなら、アクションのwithブロックへ`install_args: --locked`を足します。setup-nodeやsetup-pythonを言語ごとに並べていたワークフローが、この2行に縮みます。

### ラッパースクリプトとキャッシュキーで固めるCI実行環境の再現性

アクションが使えないGitLab CIでは、mise本体の入手方法から決める必要があります。公式が示すのは、ローカルで`mise generate install-script -l -w`を実行してbin/miseというラッパーを生成し、リポジトリへコミットするやり方です。CIジョブはそれを呼ぶだけで、miseの版までリポジトリ側で固定できます。

キャッシュキーにはOSとアーキテクチャ、mise設定、ロックファイルを含めます。公式のGitLab例ではprefixにmise-debian13-amd64を置き、filesにbin/mise・mise.toml・mise.lockの3つを指定しています。キャッシュ復元後も`mise install`は毎回走らせましょう。

## asdf・nvm・Devboxと比べたmiseの守備範囲と移行時の注意点

miseは万能の置き換えではありません。似た道具はそれぞれ守備範囲が違い、乗り換える価値があるかは案件の形で変わります。

### .tool-versions互換でasdfから移行するときに変わる挙動

asdfからの移行は、.tool-versionsをそのまま読めるぶん出発点が楽です。[公式のComparison to asdf](https://mise.jdx.dev/dev-tools/comparison-to-asdf.html)によると、miseはレガシーのasdfプラグインにも対応し、nodejsやgolangという旧来のツール名も認識します。toml設定では正規名のnodeとgoを使う点だけ注意してください。

挙動が変わるのは版を解決する時点です。asdfは呼び出しのたびにshimで解決し、miseはプロンプトかディレクトリ移動のフックでPATHを更新して以降は実体を直接呼び出す仕組みです。asdfプラグインがツール管理のたびにシェルコードを実行するのに対し、miseは内蔵のダウンロード経路で外部プラグイン無しに多くのツールを入れられる、という安全面の違いも挙げられています。Windowsについては、miseが対応ツールとバックエンドでネイティブに動く一方、レガシーのasdfシェルプラグインはUnix環境を要求します。

### Nixベースのdevboxや言語専用ツールとの使い分けの基準

選択軸は、固定したい対象がどこまでかです。miseが扱うのは開発ツールの版と環境変数で、OSのライブラリまでは踏み込みません。システムライブラリごと固定するなら、Nixを土台にする[Devboxとは？Nixを使う開発環境構築ツールの仕組み・インストール・使い方](https://www.issoh.co.jp/tech/details/8323/)のほうが射程に合います。

単一言語で完結する案件なら言語専用ツールで足ります。JVM系ならJDKとGradleをまとめて扱う[SDKMAN!](https://www.issoh.co.jp/tech/details/11413/)があり、Node.jsだけならnvmで困りません。miseの利点が出るのは、1つのリポジトリでNode.jsとPythonとTerraformが同居する案件です。開発機ごと配る考え方もあり、[Omarchy](https://www.issoh.co.jp/tech/details/9203/)のような配布形式も選択肢に入ります。

## 受託開発の現場でmiseを採用してよい条件と見送るべき2つの場面

ここからは判断の話です。道具の機能ではなく、チームの形から採否を決めます。

### 複数案件を並行する受託開発チームでmiseが効く3つの前提条件

効果が出るのは次の3つが揃うチームです。1人が複数のリポジトリを日常的に行き来していること。案件ごとに言語やツールの版が揃っていないこと。CIでも同じ版を使いたいこと。3つとも当てはまるなら、mise.tomlとmise.lockをコミットするだけでセットアップ手順書の大半が不要になります。

1つしか当てはまらないなら導入コストのほうが上回ります。分かれ目は案件数ではなく版のばらつきです。属人化した構築手順を仕組みへ移す作業は、[保守運用・内製化支援](https://www.issoh.co.jp/service/system/maintenance/)で引き受けている典型的な相談の1つです。

### Dockerで固めた環境や単一言語の案件で導入を見送る判断基準

見送ってよい場面は2つです。1つは開発も実行もコンテナ内で完結し、ホストにはエディタとDockerしか置かない構成。ツール版はDockerfileで固定済みで、miseを重ねても管理場所が2つに増えるだけになります。

もう1つは、単一言語かつ版を上げない保守案件です。Node.js 18で固定したまま3年動いているシステムに、切り替えの仕組みを持ち込む理由はありません。判断は「切り替えが日常的に発生するか」で決めてください。発生しないなら入れない。曖昧にすると、誰も使わない設定ファイルがリポジトリに残ります。

### 導入初週にありがちなPATH汚染とバージョン取り違えの失敗例

導入直後の失敗は2つに集約されます。1つ目は、Homebrewやnvmで入れた同じツールが残ったままactivateを足し、PATHの前後関係で意図しない版が呼ばれる状態です。`mise doctor`で効いている設定を確認し、旧来の管理ツールの初期化行はコメントアウトしてから移行しましょう。

2つ目は、グローバル設定の版に依存したまま案件用のmise.tomlを書き忘れ、手元だけ動いてCIが落ちるパターンです。\~/.config/mise/config.tomlに置いてよいのは、どの案件でも使う汎用の道具に限ります。案件で使う版は必ずリポジトリ側のmise.tomlへ書き、lockfileを有効にして固定する。この線引きを最初に共有しておけば、移行期間の問い合わせは減らせます。

## よくある質問

miseの導入を検討する段階でよく挙がる質問を、公式ドキュメントの記述をもとにまとめました。

### miseの読み方と名前の由来は何ですか？

読み方は「ミーズ」で、正式名称はmise-en-placeです。調理を始める前に食材と道具を並べておくフランス料理の言葉から採られています。開発を始める前にツールと環境変数とタスクを整えておく、という役割をそのまま名前にした形です。表記は小文字のmiseで、コマンド名も同じになります。

### Windowsでもそのまま使えますか？

公式のasdf比較ページは、miseが対応するツールとバックエンドについてネイティブWindowsで動作すると説明しています。一方、レガシーのasdfシェルプラグイン経由でしか入らないツールは一般にUnix環境を必要とします。Windows中心のチームで採用するなら、使いたいツールが内蔵バックエンドで入るかを先に確認してください。

### asdfの.tool-versionsをそのまま読めますか？

読めます。公式ドキュメントは、miseが.tool-versionsを読み、レガシーのasdfプラグインにも対応すると明記しています。nodejsやgolangという旧来のツール名も認識されますが、toml形式で書くときはnodeとgoという正規名を使ってください。.tool-versionsは環境変数やタスクを表現できないため、移行後はmise.tomlへ寄せると設定が1か所にまとまります。

### mise installとmise useの違いは何ですか？

mise useは、指定した版をインストールしたうえでカレントディレクトリのmise.tomlへ設定を書き出すコマンドです。mise installは設定ファイルの内容に従ってツールを入れるだけで、設定そのものは変更しません。新しく版を決めるときはmise use、既存のリポジトリを手元へ展開するときはmise installという使い分けになります。

### Dockerイメージの中でもmiseを使うべきですか？

イメージ内のツール版をDockerfileで固定できているなら、無理に重ねる必要はありません。管理する場所が2か所に増えます。使う価値があるのは、ホスト側の開発とコンテナ内の実行で同じmise.tomlを共有したい場合です。判断軸は、版の定義を1か所に集められるかどうかに置いてください。

## 関連記事

- [Devboxとは？Nixを使う開発環境構築ツールの仕組み・インストール・使い方](https://www.issoh.co.jp/tech/details/8323/)：システムライブラリごと固定する選択肢です
- [JVM開発者がSDKMAN!を導入すべき理由とバージョン管理の課題解消](https://www.issoh.co.jp/tech/details/11413/)：JVM系専用ツールとの比較に使えます
- [corepackでpnpmを管理する方法｜corepack enable・prepareの使い方](https://www.issoh.co.jp/tech/details/2765/)：postinstallで呼ぶcorepackの詳細です
- [pnpmとは？共有ストアの仕組みとv12のRust実装・モノレポ運用を解説](https://www.issoh.co.jp/tech/details/17573/)：パッケージマネージャ側の版の管理です
- [Omarchyとは？Rails開発者DHHが作った「おまかせ」Arch Linux環境](https://www.issoh.co.jp/tech/details/9203/)：環境一式を配る別のやり方です

---

出典: [miseとは？mise.tomlでツール・環境変数・タスクを束ねる導入手順【2026年版】](<https://www.issoh.co.jp/tech/details/17621/>)（株式会社一創）