2026.08.18 開発

Flutterの環境構築｜Windows・macOS別のSDK導入とflutter doctor診断【2026年8月時点】

Flutterの環境構築は、手順そのものより「どこまで入れるか」を決めていないことで長引きます。SDKを展開してPATHを通すだけなら数十分ですが、Androidの実機ビルドやiOSの署名まで含めると必要な作業は倍以上に増えます。この記事で扱うのは、2026年8月時点の公式配布データを実測したうえで整理した、Windows・macOSそれぞれの手順と、flutter doctor に残った未完了項目をどこまで潰すべきかの判断基準です。

まとめ：Flutterの環境構築はディスク容量と対象プラットフォームで決まる

先に結論を三つ置きます。第一に、導入方式は編集ツールに任せる方法と配布アーカイブを手で展開する方法の二択で、個人の学習用なら前者、チームで版を揃えるなら後者を選びます。切り替えの基準は、その端末で版を固定する必要があるかどうかです。

第二に、ディスクの見積もりを甘く見ないでください。公式の配布アーカイブは圧縮された状態でWindows版が約1.8GB、macOSのApple Silicon版が約2.1GBあります。これはFlutter本体だけの数字で、Android StudioとAndroid SDK、macOSならXcodeが別途必要です。空き容量が数GBしかない端末で始めると、途中で止まります。

第三に、flutter doctor の未完了項目を全部消す作業は不要です。Androidアプリだけを作るならiOS向けの項目は残ってよく、逆にiOSだけならAndroidのライセンス承諾を後回しにできる範囲です。何を作るかを先に決めておけば、詰まりやすい箇所の大半は回避できます。以下、それぞれの根拠と実際の手順を順に確認します。

Flutterの環境構築で最初に決める導入方式と対象プラットフォーム

公式のインストール案内は、編集ツール経由の簡易導入と、アーカイブを自分で配置する手動導入の二本立てです。どちらを選んでも入るSDKは同じもので、違うのは取得と配置を誰がやるかだけになります。

編集ツール任せの導入と配布アーカイブ手動展開の使い分け基準の判断

編集ツール経由の場合、VS CodeにFlutter拡張を入れた状態でコマンドパレットから Flutter: New Project を実行すると、SDKの場所を尋ねられます。ここでSDKの取得を選ぶと配置先フォルダの選択ダイアログが出て、取得後に Add SDK to PATH を押せばPATH設定まで完了です。前提として、WindowsではGit for Windowsの導入が要ります。

手動導入は、公式アーカイブを取得して任意の場所へ展開し、PATHを自分で通す手順です。手数は増えますが、置き場所と版を明示的に決められる点が違います。複数の案件を並行して持つ端末や、CIと手元の版を合わせたい場面では手動導入のほうが扱いやすくなります。なお端末内で複数の版を切り替える専用ツールも存在しますが、まず一つの版で通すところから始めるほうが切り分けは容易です。

迷ったときの判断はこうです。学習目的で一台だけ用意するなら編集ツール任せ。チームの標準環境として配る、または既存プロジェクトに参加するなら手動導入で版を指定する。後者を選ぶと、次に述べる版の確認が意味を持ちます。

3.47.0とDart 3.13.0が現行版となる2026年8月時点の状況

公式のリリース情報を直接参照すると、2026年8月18日時点の安定版はFlutter 3.47.0、同梱されるDart SDKは3.13.0、公開日は2026年8月12日でした。過去の版が必要な場合はSDKアーカイブの一覧から個別に取得します。

flutter --version
dart --version

導入直後にこの二つを実行して、意図した版が出るかを確かめます。会社支給端末で以前の導入が残っていると、PATHの並び順によって古い版が優先されることがあります。版が想定と違ったときに疑うのは、まずPATHの重複です。

版ごとの変更点そのものは本記事では扱いません。直前の安定版で何が変わったかはFlutter 3.44とは？SPM既定化とHCPPで変わる移行判断にまとめています。

配布アーカイブの実測サイズから逆算するディスク容量を確保する判断基準

容量の話は感覚で語られがちなので、配布物の実バイト数を確認しました。以下は公式配布サーバーへのHTTPヘッダ要求で2026年8月18日に取得した3.47.0のアーカイブサイズです。

Windows約1.8GB・macOS約2.1GBという配布物の実測値

配布物 おおよその容量 実バイト数
Windows版 zip 約1.8GB 1,927,280,652バイト
macOS版 Apple Silicon 約2.1GB 2,257,377,039バイト
macOS版 Intel 約2.1GB 2,256,069,926バイト
Linux版 tar.xz 約1.5GB 1,572,146,400バイト

いずれも圧縮された状態の数字です。展開すればさらに増え、加えて初回ビルド時にはプラットフォーム向けの資材が取得されます。Flutter本体だけで数GBを見ておくのが現実的な出発点になります。

この数値は回線の面でも意味を持ちます。1.8GBを超える取得は、共有回線の事務所で複数人が同時に始めると遅延が目立つ状況です。研修などで一斉に導入する予定があるなら、時間帯をずらすか、あらかじめ配布物を社内に置いておく段取りが要ります。

展開後とビルド生成物で膨らむ作業領域の見積もりと配置場所の判断

作業領域はSDK本体だけでは終わりません。Androidを対象にするならAndroid StudioとAndroid SDK、エミュレータのシステムイメージが加わります。macOSでiOSを対象にするならXcodeとiOSプラットフォームの資材が入り、これは単体でもFlutter本体を上回る規模です。さらにプロジェクトごとにGradleのキャッシュや依存パッケージが積み上がっていきます。

置き場所の判断は三点で決めます。パスに空白や日本語を含めないこと、書き込みに管理者権限が要る場所を避けること、そしてクラウド同期の対象フォルダの外に置くことです。三点目は見落とされやすい箇所で、同期フォルダの配下にプロジェクトを置くとビルドのたびに生成物が同期対象となり、端末の負荷と同期の待ち時間が増えます。

実務では、SDKとプロジェクトをどちらもユーザーフォルダ直下の作業用ディレクトリにまとめる構成が扱いやすい形です。会社の端末管理でユーザーフォルダが同期対象になっている場合は、同期から除外するパスを先に確保しておいてください。

WindowsでのSDK展開とPATH設定でつまずきやすい箇所

Windowsでの手動導入は、展開・PATH追加・確認という三段階です。手順自体は短いものの、PATHの扱いで止まる例が多く見られます。

配布アーカイブの展開先フォルダ選定と環境変数Pathへの追加手順

PowerShellでアーカイブを展開し、ユーザー環境変数のPathへbinディレクトリを追加します。

Expand-Archive -Path flutter_windows_3.47.0-stable.zip -DestinationPath $env:USERPROFILE\develop
$env:USERPROFILE\develop\flutter\bin

二行目は追加するパスそのものです。設定画面からシステムの詳細設定を開き、ユーザー環境変数のPathへこの値を新規追加します。公式手順では、追加した項目を一覧の上のほうへ移動させることが案内されています。他の開発ツールが同名のコマンドを持っている場合に、意図しないほうが先に解決されるのを防ぐためです。

追加後は端末とエディタを開き直します。開いたままのターミナルには古い環境変数が残っており、そこで flutter が見つからないという状態が起きます。導入直後にコマンドが通らないときは、まず新しいウィンドウで試してください。

Windowsデスクトップ向けビルドに要るVisual Studioの構成

Windowsで動くデスクトップアプリまで作る場合は、Visual Studioの導入が別途必要です。ここで求められるのはVisual Studio Codeではなく、統合開発環境のVisual Studio本体で、インストーラーで「C++によるデスクトップ開発」のワークロードを選びます。コマンドラインの識別子は Microsoft.VisualStudio.Workload.NativeDesktop です。

すでにVisual Studioが入っている端末でも、このワークロードが未選択なら診断コマンドがエラーを出します。その場合はインストーラーの変更から追加します。逆に、モバイルアプリしか作らない予定であればVisual Studioは要りません。診断結果に出るVisual Studio関連の項目は、Windowsデスクトップを対象にしないなら未解決のまま進められます。

もう一点、3.47.0からはWindows向けの描画にImpellerが既定で使われるようになりました。以前の版で作ったデスクトップアプリを新しいSDKでビルドし直す場合は、描画結果を目視で確認する工程を入れておくと安全です。

macOSでのコマンドラインツールとXcode周りの初期設定

macOSはFlutter本体の導入より、Apple側のツール設定に手間がかかります。iOSアプリを対象にするなら避けて通れない部分です。

xcode-selectとxcodebuildで済ませる初回起動時の設定

まずコマンドラインツールを入れ、続いてXcode本体の初回起動処理とライセンス承諾、iOSプラットフォームの取得を順に実行します。

xcode-select --install
sudo sh -c 'xcode-select -s /Applications/Xcode.app/Contents/Developer && xcodebuild -runFirstLaunch'
sudo xcodebuild -license
xcodebuild -downloadPlatform iOS

二行目のパスは、Xcodeを既定以外の場所に置いている場合は読み替えます。四行目でiOSのプラットフォーム支援とシミュレータの実行環境が取得され、これを飛ばすとシミュレータの起動時に不足を指摘されます。Flutterのプラグインがネイティブコードを含む構成に対応するため、CocoaPodsの導入も併せて必要です。

PATHの設定はホームディレクトリの .zprofile に追記する形が案内されています。追記後はZshのセッションを開き直してから確認コマンドを実行します。なお公式配布にはApple SiliconとIntelの両方の版がありますが、Intel向けは今後縮小していく方向が示されており、新規に用意する端末はApple Siliconを前提に選ぶほうが無難です。

iOSシミュレータと実機を動かすために要る署名と信頼の設定手順

シミュレータは open -a Simulator で起動します。別のOS版のシミュレータが要る場合はXcodeの管理画面から追加取得が必要です。ここまでは無償の範囲で完結します。

実機へ転送する段になると、Apple IDとデベロッパープログラムへの登録、そして署名用の証明書が必要になります。端末側では設定からデベロッパーモードを有効にして再起動し、Macに接続したときの「このコンピュータを信頼しますか」に応答します。転送後、端末の設定にあるVPNとデバイス管理から証明書を有効にし、開発用アプリの項目で信頼を与えるところまでが一連の流れです。

この工程は初回のみ必要ですが、証明書の期限や端末の初期化で再実行になります。検証端末を複数人で共有している現場では、誰の証明書で信頼を与えたかを記録に残しておくと後の切り分けが速くなります。

Android向けツールの導入とライセンス承諾までの実作業手順

Androidを対象にする場合、Flutter単体では足りずAndroid Studio側の設定が伴います。WindowsでもmacOSでも作業内容は共通です。

SDK ManagerでAPI 36と併せて入れる四つのツール群

Android Studioの安定版を導入したら、SDK Managerを開いてプラットフォームとツールの両方を確認します。公式が指定しているのはAPIレベル36のプラットフォームと、以下のツール群です。

区分 導入する項目
プラットフォーム APIレベル36
ビルド SDK Build-Tools
コマンド操作 SDK Command-line Tools
端末接続 SDK Platform-Tools
検証環境 Android Emulator
ネイティブ CMakeとNDK

このうちCommand-line Toolsは選択漏れが起きやすい項目です。未導入のままだと次のライセンス承諾コマンドが動かず、原因が分かりにくいエラーで止まります。エミュレータを使う予定があるなら、仮想化支援の有効化とAPIレベル36以上のシステムイメージの取得も併せて済ませます。

flutter doctor –android-licensesで詰まる場面の対処

SDKの導入が終わったら、ライセンス承諾を実行します。

flutter doctor --android-licenses

表示される各ライセンスに同意していくと、すべて承諾済みである旨のメッセージが出ます。ここで止まる原因は概ね三つに絞られます。ひとつはCommand-line Toolsの未導入、ふたつめはJavaの実行環境がAndroid Studio同梱のものと別を指している状態、みっつめは社内のプロキシでSDKの取得自体が完了していないケースです。

実機で動かす場合は、端末側で開発者オプションとUSBデバッグを有効にし、Windowsでは端末メーカーのUSBドライバを入れます。接続できているかは flutter devices で確認します。ここに端末名が出れば、あとは通常のビルドコマンドで転送できる状態です。

flutter doctorの出力を読み解いて未完了項目を切り分ける

診断コマンドは、環境が完璧かどうかではなく「何が不足しているか」を並べる道具です。全項目に印が付くまで作業を続ける必要はありません。

開発対象ごとに判断する解決不要な警告と対処が要る警告の線引き

flutter doctor -v

詳細表示を付けると、各項目がどのパスを見て判定しているかまで出ます。以下は代表的な項目と、未解決のまま進めてよい条件の対応です。

診断項目 未解決でも進める条件
Flutter本体 解決が必要
Android toolchain Androidを作らないなら可
Android Studio Androidを作らないなら可
Xcode iOSとmacOSが対象外なら可
Visual Studio Windows版を作らないなら可
Chrome Web出力が対象外なら可
接続デバイス 実機を使わないなら可
ネットワーク到達性 解決が必要

判断の順序は、対象プラットフォームを先に確定させることです。業務系のモバイルアプリで両OSに配布するならAndroidとXcodeの両方を解決し、社内配布のAndroidのみならXcode側は放置して構いません。ブラウザ向けの出力を選択肢に入れるかどうかは制約の理解が先に要るため、Flutter Webとは？CanvasKitとWasmの描画差・SEO制約・採用条件で採用条件を確認してから決めてください。

ネットワーク制限下の社内環境で発生する取得失敗の切り分け手順

診断項目のうち、ネットワーク到達性の失敗だけは対象プラットフォームに関係なく解決が要ります。SDKの更新も依存パッケージの取得も、この経路が通っている前提で動くためです。

社内網で止まる場合、疑う先は三箇所あります。プロキシの設定がコマンドライン側に渡っていない、証明書の検査でHTTPSの接続が切られている、配布ドメインが許可一覧に入っていない、のいずれかです。原因ごとに対処の担当部署が変わるため、エラーメッセージに出るホスト名を控えて情報システム部門へ渡すのが早道になります。

暫定策として個人の回線を使う判断は避けてください。導入時だけ通っても、依存パッケージの更新やビルド資材の取得はプロジェクトが続く限り発生します。最初の一台で経路を通しておけば、二台目以降の導入時間は大きく縮みます。

3.47系で変わった最低要件と受託開発で確認する環境定義の項目

環境構築は一度で終わる作業ではありません。SDKの更新で必要な条件が動くため、どの範囲を対象にするかを最初に決めておくと後の手戻りが減ります。

3.47で上がったmacOSの最低要件と対応プラットフォーム範囲

3.47.0では、macOSアプリの最低対応バージョンが10.15から12へ引き上げられました。Xcodeの新しい版に対応するための変更です。あわせてAndroid Gradle Pluginの9系への対応が進み、新規プロジェクトのテンプレートもその前提へ更新されています。古い版で作ったプロジェクトを持ち込む場合は、この二点が移行作業の入口になります。

対象 2026年8月時点の対応範囲
Android APIレベル24から37
iOS 15から26
Windows 10と11
macOS 12から26
ChromeとEdge 直近2バージョン
Safari 15.6以降

この表は配布先の下限を決めるときの材料です。たとえば業務用のAndroid端末が古いままなら、APIレベル24が下限である点を先に確認しておく必要があります。フレームワーク自体を長期に採用してよいかという上位の判断は、Flutterの将来性を数値で判断するで扱っている指標を参照してください。

外注や新規参画の前に文書化しておく開発環境の定義と確認の項目

受託でも内製でも、環境の定義を文書化しておくと参画初日の消耗が減ります。押さえる項目は四つです。ひとつ、SDKの版とチャネル。ふたつ、対象プラットフォームとその下限バージョン。みっつ、各OSで必要なツールの版（Xcode・Android Studio・Visual Studio）。よっつ、CIで使っている版と手元の版を一致させる方法です。

四つ目が抜けると、手元では通るのにCIで失敗するという切り分けの難しい状況が生まれます。逆にここが揃っていれば、新しい開発者の環境構築を半日で終えられる状態です。実装に着手した後の設計判断、たとえば状態管理の選定についてはRiverpodとは何か？Flutterの状態管理ライブラリとしての特徴で整理しています。

一創ではFlutter / React Nativeによるクロスプラットフォーム開発として、対象プラットフォームの線引きと環境定義の整理から設計する方針をとっています。既存のアプリを引き継ぐ形での相談も受け付けています。

よくある質問

Flutterの環境構築にはどれくらいの容量が必要ですか？

Flutter本体だけで、圧縮された配布アーカイブがWindows版で約1.8GB、macOSのApple Silicon版で約2.1GBあります。展開後はこれを上回り、さらにAndroid StudioとAndroid SDK、macOSならXcodeが加わります。プロジェクトごとの依存パッケージやビルド生成物も積み上がるため、余裕のある空き容量を用意してから始めてください。

flutter doctorの警告は全部消す必要がありますか？

対象プラットフォーム次第です。Androidだけを作るならXcodeとVisual Studioの項目は未解決のままで進められますし、その逆も成り立ちます。対象に関係なく解決が要るのは、Flutter本体とネットワーク到達性の二つだけと考えてください。作るものを決めずに全項目を埋めようとすると、使わない環境の設定で時間を消費します。

WindowsでiOSアプリの開発はできますか？

iOS向けのビルドと署名にはXcodeが要るため、Windows単体では完結しません。コードを書いてAndroidやWeb向けに動作を確認する部分までは可能ですが、実機転送とApp Storeへの提出にはmacOS環境が必要です。iOS対応が確定している案件では、開発端末の調達か、macOSのビルド環境を用意する段取りを企画段階で織り込んでおきます。

Android Studioを入れずにVS Codeだけで開発できますか？

編集とビルドの操作はVS Codeだけでも行えますが、Androidを対象にするならAndroid SDKとライセンス承諾は必要です。SDKだけをコマンドラインツール経由で用意する方法もあるものの、SDK Managerとエミュレータの管理画面が使えるぶん、Android Studioを併せて入れておくほうが切り分けは容易になります。

複数バージョンのFlutterを同じ端末で使い分けられますか？

可能です。配布アーカイブを版ごとに別のフォルダへ展開してPATHを切り替える方法のほか、版の切り替えを担う専用ツールも存在します。ただし切り替えの仕組みを入れる前に、案件ごとにどの版を使うかを決めて記録しておくことが先です。版が特定できていない状態で仕組みだけ導入しても、混乱は解消しません。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る