FlutterはSDK本体にDart、flutterコマンド、ビルド用ツールがまとまっている。複数プロジェクトを触ると、あるプロジェクトは古いFlutter、別のプロジェクトは最新stable、検証用にはbetaやmaster、という状態になりやすい。

ここで気になるのは、単に「複数バージョンを入れられるか」だけではない。既存の手順書、CI、IDE、チームメンバーの習慣を壊さないためには、flutter analyze、flutter test、flutter pub get のような通常コマンドをできるだけ変えずに使えるかが重要になる。Node.jsのnvmに近い体験、つまりバージョンだけ切り替えて、実行コマンドはnodeのままにしたい、という観点で整理する。

調査時点は2026年5月31日。公式ドキュメントや各プロジェクトのREADMEを中心に確認した。

結論

「コマンドを変えたくない」を最優先にするなら、第一候補は次の3系統に分かれる。

  1. Flutter専用で、flutterコマンドをそのまま使いたい: Puroが扱いやすい。インストール時にPATHを整え、グローバル/プロジェクトの環境を切り替えられる。
  2. Node、Java、Pythonなどもまとめて管理したい: asdf、mise、vfoxのような汎用バージョン管理ツールが合う。flutterも通常コマンドのまま、プロジェクトごとにバージョン解決する設計に寄せやすい。
  3. FVMのエコシステムを使いたい: 標準はfvm flutter ...だが、公式ドキュメントにはflutter/dartをFVMに迂回させる方法もある。導入済みチームやIDE連携重視なら有力。ただし「最初からコマンドを変えない」体験ではPuroや汎用ツールの方が自然。

補足すると、fvm-sh/fvmは名前が似ているが、Dart製のFVMとは別物だ。fvm useでPATHを切り替え、flutter --versionをそのまま実行するREADME例があり、nvmにかなり近い。ただしPOSIXシェル前提で、WindowsはWSL扱いになるため、チーム標準にするなら対象環境を確認したい。

比較表

ツール種別通常のflutterコマンドを変えずに使えるかプロジェクト固定向いているケース注意点
FVM（Dart製）Flutter専用標準はfvm flutter。ラッパー作成でflutterに迂回可能.fvmrcFlutter専用で実績重視、IDE設定もまとめたいそのままだと手順書やCIのコマンドにfvm接頭辞が増える
PuroFlutter専用使いやすい。PATH上のflutterが選択環境を向く.puro.jsonFlutterだけ管理し、コマンドは変えたくないプロジェクトファイルは環境名を持つため、固定バージョン運用では命名ルールが大事
asdf + asdf-flutter汎用shims経由でflutter/dartをそのまま実行.tool-versions複数言語を1つの仕組みに寄せたいFlutterプラグインはコミュニティ管理。プラグイン依存関係も見る
mise汎用PATH activationまたはshimsで通常コマンドを使えるmise.tomlなどasdf系の体験を高速・統合的に使いたいFlutterはバックエンド/プラグイン選択の確認が必要。新規asdf/vfox registry採用方針も変化中
vfox汎用PATHの優先順位を変えて通常コマンドを使う設計.vfox.tomlWindows/macOS/LinuxでSDK管理をそろえたいFlutterプラグインの成熟度とチーム内の知名度を確認したい
fvm-sh/fvmFlutter専用シェルスクリプトfvm use後にflutterをそのまま使うREADME例があるシェル/PATH中心nvmに近い使い心地を最優先する個人環境POSIXシェル前提。Dart製FVMとは別物なので混同注意

判断軸1: コマンドを変えずに済むか

Flutter公式のCLIドキュメントは、通常の開発コマンドとしてflutter create、flutter analyze、flutter test、flutter run、flutter pub getなどを案内している。したがって、バージョン管理ツールを入れても、普段の操作やCIではこの形を保てる方が摩擦が少ない。

この観点で見ると、ツールは大きく2種類に分かれる。

  • PATH/shim型: flutterという実行名は変えず、PATHやshimが適切なSDKへ誘導する。Puro、asdf、mise、vfox、fvm-sh/fvmはこちらに近い。
  • プロキシコマンド型: fvm flutter analyzeのように、管理ツールのサブコマンド経由でFlutterを呼ぶ。Dart製FVMの標準導線はこちら。ただしFVMもflutter/dartをFVMへ迂回させる方法を公式に案内している。

既存のREADMEやCIがすでにflutter前提なら、PATH/shim型の方が移行は楽だ。逆に「FVMを使っていること」を明示したいチームでは、fvm flutterの方が、どのSDK解決ルールを使っているかが分かりやすい。

FVM: 実績重視。ただし標準コマンドはfvm flutter

Dart製のFVMは、Flutter SDKのバージョンをプロジェクト単位で管理する定番候補だ。公式ドキュメントでは、プロジェクトに.fvmrcが作られ、.fvm/flutter_sdkが対象SDKへのシンボリックリンクになると説明されている。VS Code設定や.gitignore更新、SDK変更時のflutter pub get実行なども設定項目として持つ。

実行時は、公式ドキュメント上では次の形が基本になる。

fvm flutter analyze
fvm flutter test
fvm dart run build_runner build

SDK解決順は、プロジェクトの.fvmrc、親ディレクトリの.fvmrc、fvm global、システムPATH上のFlutterという順で説明されている。つまり、明示的にfvm flutterを使えば、プロジェクト固定・グローバル・システムFlutterへのフォールバックが分かりやすい。

一方で、「コマンドを変えない」目的だけで見ると少し工夫がいる。FVMドキュメントには、flutterやdartコマンドをFVMに迂回させるシェルスクリプトをPATH上に置く方法がある。これを使えばflutter analyzeを内部的にfvm flutter analyzeへ回せる。ただし、既存のネイティブインストールやパッケージマネージャー由来のflutterバイナリと衝突しないように、PATHの順序と撤去手順を決めておく必要がある。

向いている判断:

  • チームでFVM利用者が多い。
  • IDE設定まで含めてFlutter専用ツールでそろえたい。
  • fvm flutterという接頭辞が増えても許容できる、またはラッパー導入をルール化できる。

Puro: Flutter専用で、通常コマンドを保ちやすい

PuroはFlutter専用のバージョン管理ツールだ。公式マニュアルでは、インストール時にPuro自身とFlutterをPATHへ追加し、既存のDart/Flutterインストールと干渉する可能性があれば警告すると説明されている。

特徴的なのは、グローバル環境を切り替えると~/.puro/envs/defaultのシンボリックリンクが更新され、そのパスがPATHに入る点だ。マニュアル上でも、puro use -g betaの後にflutter --versionをそのまま実行する例が示されている。プロジェクト単位ではpuro use betaのように実行し、.puro.jsonに環境名を保存する。

つまり、Puroは「Flutter専用で、でも普段はflutterと打ちたい」という要望にかなり合っている。puro flutterのように明示して呼ぶこともできるが、日常コマンドはflutterのままにしやすい。

向いている判断:

  • Flutterだけを管理できればよい。
  • flutterコマンドを変えたくない。
  • IDE設定も自動調整してほしい。
  • SDKのダウンロードやアップグレードを速くしたい。

注意点:

.puro.jsonはバージョン番号ではなく環境名を保存する形になる。たとえばstableという環境名を使う場合、チーム内でその環境が同じFlutterバージョンを指しているとは限らない。再現性を強くしたいなら、app-3-32-8のようにバージョンを含む環境名にする、または作成手順を明文化する方がよい。

asdf: すでに使っているなら有力

asdfは複数言語・複数ツールをまとめて管理する汎用バージョン管理ツールだ。asdf本体のドキュメントでは、shimsディレクトリをPATHに追加し、.tool-versionsをカレントディレクトリから上位に向かって探索して、実行時にバージョンを解決すると説明されている。

Flutter向けにはasdf-community/asdf-flutterがあり、READMEではFlutterプラグインがflutterとdartの両方を含むと説明されている。導入後は、たとえば次のような形になる。

asdf plugin add flutter
asdf install flutter 3.32.0
asdf set flutter 3.32.0
flutter --version

Node.jsやRuby、Javaなどもasdfで管理しているチームなら、Flutterだけ別ツールにしないメリットがある。.tool-versionsに複数ツールを並べれば、プロジェクトの開発環境を1ファイルで説明しやすい。

向いている判断:

  • すでにasdfを使っている。
  • Node、Ruby、Java、Flutterなどを同じ仕組みでそろえたい。
  • flutterコマンドをそのまま使いたい。

注意点:

Flutterプラグインはコミュニティ管理で、jqなどの依存関係がある。Flutter専用ツールに比べると、IDE設定やFlutter固有のワークフローは自分で補う場面が増える。

mise: 汎用管理を新しく選ぶなら候補。ただしFlutterの入れ方は確認する

miseは、開発ツールのインストール、PATH設定、タスク、環境変数などをまとめる汎用ツールだ。公式ドキュメントでは、通常のインタラクティブシェルではmise activateによって対象ツールのbinディレクトリをPATH前方に追加し、非インタラクティブ環境やIDEではshimsを使う選択肢が説明されている。

つまり、仕組みとしてはflutterコマンドを変えずに使う設計に向いている。miseはasdf系のプラグインやvfox系バックエンドも扱えるため、Flutterを入れる場合はバックエンドの選択を確認する。2026年時点のmiseドキュメントでは、新規registry登録におけるasdf/vfoxバックエンドの扱いに供給網セキュリティ上の方針があるため、短縮名があるか、明示指定が必要かを導入時に確認したい。

向いている判断:

  • これから汎用バージョン管理ツールを選ぶ。
  • NodeやPythonなども含め、開発環境全体をmise.tomlで管理したい。
  • shimsとPATH activationを使い分けたい。

注意点:

Flutter専用のワークフローというより、開発環境全体の管理ツールとして見る方がよい。Flutterだけのために導入するなら、PuroやFVMの方が説明コストは低い。

vfox: クロスプラットフォーム志向の汎用SDK管理

vfoxは、Node.js、Java、Flutter、.NETなどを対象にしたプラグイン型のSDKバージョン管理ツールだ。公式ドキュメントでは、プロジェクト、セッション、グローバルの3スコープを持ち、PATHの優先順位を変えることで通常コマンドが選択済みSDKを向く仕組みを説明している。

プロジェクトスコープでは.vfox.tomlに設定を保存し、.vfox/sdks/.../binをPATHの前方に置く。Node.jsの例では、vfox use -p nodejs@20.9.0の後にnode -vがプロジェクト版を参照する。この考え方はFlutterでも、flutterコマンドを変えない運用と相性がよい。

向いている判断:

  • Windows、macOS、LinuxをまたいでSDK管理のUIをそろえたい。
  • グローバル、プロジェクト、セッションの切り替えを明確に使いたい。
  • 汎用SDK管理ツールとしてvfoxに寄せたい。

注意点:

Flutter用途では、プラグインの成熟度、チーム内の知名度、CI上の導入手順を事前に試すべきだ。日本語圏やFlutterチームでの情報量は、FVMやasdfより少ない可能性がある。

fvm-sh/fvm: nvmに近いが、Dart製FVMとは別物

fvm-sh/fvmは、POSIXシェル向けのFlutterバージョン管理スクリプトだ。READMEでは「Inspired by nvm」とし、fvm use 2.10.3の後にflutter --versionをそのまま実行する例を示している。

この体験は、今回の要望にかなり近い。nvm useで現在シェルのnodeが切り替わるように、fvm useで現在シェルのflutterを切り替える発想だからだ。

ただし、Dart製FVMより知名度やエコシステムは小さく、README上の対応環境もPOSIX準拠シェル、Unix、macOS、Windows WSLとされている。WindowsネイティブのPowerShellや、IDE連携を含めたチーム標準として採用するなら、検証項目は多い。

向いている判断:

  • 個人環境でnvmに近い操作感を優先したい。
  • POSIXシェル中心で作業している。
  • fvmという名前の混同を避けて説明できる。

おすすめの選び方

個人開発で「とにかくflutterのまま」が大事

Puroを第一候補にする。Flutter専用なので概念が少なく、日常コマンドを変えずに済みやすい。POSIXシェル中心ならfvm-sh/fvmも候補になるが、Dart製FVMとの混同には注意する。

チーム開発でFlutterだけ管理したい

FVMかPuroを比較する。

  • FVM: .fvmrcでバージョンを明示しやすく、Flutterチームでの情報量が多い。標準はfvm flutterなので、コマンド変更を許容するか、ラッパーで迂回するかを決める。
  • Puro: flutterコマンドを保ちやすい。.puro.jsonが環境名ベースなので、環境名と実バージョンの対応をチームで固定する。

すでにNodeやJavaもバージョン管理している

asdf、mise、vfoxのような汎用ツールに寄せる。特に既存でasdfやmiseを使っているなら、Flutterだけ別管理にするより、flutterも同じ仕組みに入れる方がオンボーディングが簡単になる。

CIで事故を減らしたい

CIでは「暗黙のPATH切り替え」より「明示的なセットアップ」を重視する。たとえば次のどちらかに寄せる。

  • FVMなら、CI手順にfvm installとfvm flutter testを明記する。
  • PATH/shim型なら、セットアップ後にflutter --versionを必ず出力し、期待バージョンと違えば失敗させる。

ローカルではflutterコマンドのまま、CIでは明示的に管理ツール経由、という分け方も現実的だ。

まとめ

「nvmみたいにコマンドを変えずに使いたい」という条件を最上位に置くなら、Flutter専用ではPuro、汎用管理ではasdf/mise/vfox、nvm風のシェル体験ではfvm-sh/fvmが候補になる。

Dart製FVMは実績とFlutter専用機能が強い一方、標準の実行形はfvm flutterだ。公式にflutterへ迂回する方法はあるので、既存チームでFVMを選ぶ価値は十分ある。ただし、新規導入で「普段のコマンドを一切変えない」ことを最優先するなら、Puroか汎用ツールから試すのが分かりやすい。

最終的には、次の3問で決めるとよい。

  1. Flutterだけ管理したいか、Node/Java/Pythonなどもまとめたいか。
  2. READMEやCIにfvm flutterのような接頭辞を入れてよいか。
  3. プロジェクトの再現性を、バージョン番号のファイルで担保したいか、環境名や共通セットアップ手順で担保したいか。

この3つに答えると、選択肢はかなり絞れる。

参考リンク