この記事は Qiita Tech Festa 2026 の投稿記事です。
【連載】miseのTask機能再確認
- 第1回：LLM Agent 活用を前提としたモノレポで求められるツールチェーン
- 第2回：アーキテクチャから紐解くモノレポのタスク管理
- 第3回：CLIによる高度なタスク実行と活用術
- 第4回：mise.tomlの高度なタスク定義(本記事)
はじめに
前回の記事では、mise watch やパターンマッチなど、CLIからのタスク実行方法を中心とした内容の記載をしました。
今回は、mise.toml の定義の詳細を解説した TOML Tasks のドキュメントの内容を中心に紹介します。
プロパティを利用して、依存関係や環境変数の注入、外部スクリプトの実行などになります。
概要・前提条件
本記事では、mise.toml のプロパティの説明を行っていきます。
-
対象読者:
- (LLM Agentを活用する) モノレポ環境を構築・運用している方
- 言語非依存のタスクランナーを探している方
-
前提条件:
-
miseがインストールされていること
-
1. 成果物ベースの依存関係定義： sources と outputs
Makefile の時代からある、成果物が既にある場合はスキップする機能が mise にもあります。
mise はファイルの最終更新日時（last-modified）をチェックし、ソースファイルが更新された時だけタスクを実行させることができます。
[tasks.build]
run = "cargo build"
sources = ["Cargo.toml", "src/**/*.rs"]
outputs = ["target/debug/mycli"]
前回の記事で紹介した mise watch は、この sources を監視して自動実行する仕組みになっています。
成果物の取り扱いに注意
CI 環境でゼロから実行する場合には前回成果物のハンドリングを適切にしないと意図しない実行や、スキップを引き起こすことがあります。
また、ローカルではソースコードは変更していないが、環境変数による埋め込みの値を変更したい場合などで成果物があるためにタスクがスキップされてしまうケースがあります。この方法を使う場合は outputs を一定条件で削除する tasks.clean を定義しておくのがよいかもしれません。
2. タスクの依存関係定義: depends・depends_post と wait_for の使い分け
mise ではタスクの素直な依存関係として、事前に実行する depends と、事後に実行する depends_post が用意されています。
[tasks.deploy]
depends = ["build", "test"] # deployの前に実行
depends_post = ["cleanup"] # deployの後に実行
run = "kubectl apply -f deployment.yaml"
しかし、単なる順序指定である depends では対応しきれないケースがあります。そこで登場するのが、よりタイミングが考慮された依存関係である wait_for です。
# depends を使った場合
[tasks.lint]
depends = ["render"] # eslintを実行するためだけに、毎回重いrenderタスクが強制実行されてしまう
run = "eslint ."
# wait_for を使った場合
[tasks.lint]
wait_for = ["render"]
run = "eslint ."
wait_for は**「同じ実行コンテキストで render タスクがスケジュールされていれば、それが終わるのを待つ」**という挙動になります。
つまり、mise run lint と単独で実行した場合は render はトリガーされずすぐに lint が走ります。しかし、mise run lint render と同時に実行指定した場合などは、自動で待ち合わせをしてくれます。
3. 複数行のスクリプトの実行: run = '''...'''
mise のタスクはTOMLの中に複数行のスクリプトを直接埋め込むことも可能です(ファイルを外部化して呼び出す方法もありますが、そちらは次回説明します)。
以下の例は、複数行のスクリプトと、実行前の確認（confirm）を組み合わせた例です。
[tasks.release]
description = "新しいリリースを作成します"
confirm = "本当に新しいリリースを作成してよろしいですか？ (y/N)" # 実行前にユーザーへ確認
run = '''
#!/usr/bin/env bash
set -e
echo "Building the project..."
npm run build
echo "Tagging the release..."
git tag v1.0.0
'''
confirm オプションの挙動と活用
このタスクを実行しようとすると、ターミナル上でプロンプトが表示され、ユーザーの標準入力を待ち受けます。
破壊的変更を伴うマイグレーションタスクなどに confirm を設定しておくと、自動的な実行によるミスオペレーションの抑止になります。
4. その他のプロパティ: 変数注入・タスク実行ディレクトリ
その他にも、タスクの挙動をきめ細かく制御できるプロパティが存在します。
env と vars: タスク共通・個別の変数定義
タスク実行時のみ有効な変数を定義できます。ファイル全体（すべてのタスク間）で共有する書き方と、特定のタスク専用の書き方があります。
# ファイル内のすべてのタスクで共有されるグローバル定義
[env]
VERBOSE_ARGS = '--verbose'
[vars]
e2e_args = '--headless'
# タスク専用の定義（グローバル定義を上書き可能）
[tasks.test]
env = { FLASK_ENV = "testing" }
vars = { e2e_args = "--headed" }
# {{vars.xxx}} はテンプレート展開、$XXX は環境変数として評価される
run = "./scripts/test-e2e.sh {{vars.e2e_args}} $VERBOSE_ARGS"
env と vars の違い
-
env: 実行されるプロセス（シェルなど）に渡される 環境変数 です -
vars: コマンド文字列の中で{{vars.xxx}}のように テンプレート変数として展開 されます。mise.tomlの定義位置に応じたスコープの変数です
dir: 柔軟な実行ディレクトリの指定
タスクを実行するディレクトリを指定します。特殊記法の {{cwd}} を使えば、ユーザーが現在いるディレクトリをカレントディレクトリとして引き継ぐことができます。
[tasks.clean]
run = "rm -rf node_modules"
dir = "{{cwd}}" # デフォルトではプロジェクトルートになりますが、これを指定するとユーザーの現在地で実行されます
hide と alias: 内部タスクの整理術
ユーザーに直接叩かせるタスクではない（他のタスクから depends されるだけの内部タスク）場合は、hide = true を設定することで mise tasks の一覧から隠すことができます。また、よく使うタスクには alias で短い別名をつけることも可能です。
[tasks.cleancache]
run = "rm -rf .cache"
hide = true # 一覧には表示されない
[tasks.build]
depends = ["cleancache"]
run = "cargo build"
alias = "b" # `mise run b` で呼び出せるようになる
おわりに
mise.toml におけるタスクの定義は、単なるコマンドの羅列を超えて、依存関係、変数のスコープまでを一つのファイルで宣言的に管理できます。
前回記事の内容と組み合わせることで、モノレポのような複雑な環境でも、見通しよくタスクを定義して開発ワークフローを効率的、またキャッチアップ速度早く対応できていくと思います。