Flutter 3.44とは?SPM既定化とHCPPで変わる移行判断【2026年7月時点】
Flutter 3.44は2026年5月18日に安定版として公開され、Dart 3.12を同梱します。目を引く新ウィジェットは少なく、変わったのはビルドと依存管理の土台です。iOS・macOSの依存解決はSwift Package Managerが既定になり、AndroidにはHybrid Composition++が入りました。MaterialとCupertinoはフレームワーク本体で凍結され、独立パッケージへ向かいます。この記事では3.41からの差分を、移行の期限・改修コスト・採用可否という実務の判断軸で整理します。
まとめ:Flutter 3.44で今すぐ動くべき変更と据え置ける変更の線引き
3.44の中心はSwift Package Managerの既定化です。CocoaPodsのtrunkは2026年12月2日に読み取り専用へ移行すると公式ブログが予告しており、この記事の公開時点(2026年7月27日)で残り約4か月。iOSアプリを継続配信する案件では、期限のあるタスクとして先に着手する対象になります。
Androidのプラットフォームビュー(WebViewや地図)で描画のちらつきやタッチのずれを抱えているなら、Hybrid Composition++が解決の候補です。ただしオプトインであり、AGP 9のKotlin組み込みと衝突するビルド構成では先にGradle側の整理が要ります。
据え置いてよいのはMaterial・Cupertino分離への対応。3.44では凍結されただけで、material_ui/cupertino_uiへの実移行は将来の安定版です。破壊的変更はExtendSelectionByPageIntentの削除とTextDecorationのfinal化が代表で、影響範囲は狭く、機械的な置換で片づく規模でした。
Flutter 3.44の位置づけ|3.41からの差分が示す変更の質
バージョン番号の刻みは小さくても、触っている層が違います。まず3.44が何のリリースだったのかを押さえます。
2026年5月18日の安定版リリースとDart 3.12の同梱
Flutter 3.44.0は2026年5月18日に安定版として公開されました。同梱されるDart SDKは3.12.0で、その後の3.44系パッチではDart 3.12.2が組み合わされています。Google I/O 2026に合わせた発表で、公式ブログとリリースノートの双方が同じ内容を扱っています。
Dart 3.12側の追加は、プライベート名前付きパラメータの構文と実験扱いのprimary constructors。言語機能そのものは移行判断を左右しませんが、analysis_options.yamlでlintを厳しく設定しているプロジェクトでは、新構文に合わせた警告の増減が起きる点だけ想定しておいてください。
972コミット・178コントリビューターが示す3.44の性格
このサイクルでマージされたのは178名による972コミットで、内訳は新規ウィジェットの追加より既存の穴埋めが中心でした。0x0サイズ環境でのクラッシュ修正(EditableText、Container、Heroほか)やP3からsRGBへの色変換の修正といった具合で、こうした修正の多さが「土台のリリース」という性格を示しています。
3.41から3.44へ|開発者体験の改善から基盤の作り替えへの転換
2026年2月の3.41は、DevToolsやウィジェット周りの使い勝手を押し上げる内容が中心でした。前版で何が変わったかはFlutter 3.41が示した開発者体験の改善ポイントで扱っているため、本記事は3.44固有の差分に絞ります。
3.44で入れ替わったのは、依存管理(CocoaPods→SwiftPM)、Android合成方式(HCPP)、UIライブラリの所属(本体→独立パッケージ予定)という3つの土台。アプリのコードを書き換えなくても、ビルド設定とCIが影響を受けます。バージョンを上げるコストの見積もり方が、3.41までとは質的に変わったと捉えてください。
Swift Package Manager既定化とCocoaPods終息が迫る移行期限
3.44でもっとも期限が明確なのがここです。技術的な良し悪しより、いつまでに何を終えるかの話になります。
SwiftPM既定化で変わるiOS・macOSの依存解決とフォールバック挙動
iOS・macOSの依存管理は、Swift Package Managerが既定になりました。flutter createで作った新規プロジェクトはSwiftPM構成で生成され、既存プロジェクトはFlutter CLIが移行を自動で扱います。SwiftPMへ未対応のプラグインが含まれる場合はCocoaPodsへのフォールバックが働き、警告が出る仕組みです。
そのため3.44へ上げた直後にビルドが止まる事態は起きにくい設計です。ただし警告を放置すると、CocoaPods側の期限が来たときに逃げ場がなくなります。SwiftPMの基本構造やPackage.swiftの書き方はSwift Package Managerの使い方とCocoaPodsからの移行手順にまとめました。両者の依存が衝突するケースの検出も3.44で入っています。
CocoaPods trunkが読み取り専用になる2026年12月2日の意味
CocoaPods公式ブログは、trunk(podspecの中央レジストリ)を2026年12月2日に読み取り専用へ移行すると告知しました。11月1日から7日にかけて読み取り専用モードの試験運用も予定されています。
読み取り専用になっても既存のビルドは止まりません。止まるのは新規公開と新バージョンの登録。つまり期限後に困るのは、依存しているOSSライブラリが不具合修正を出したのに、CocoaPods経由では受け取れないという状況です。CocoaPodsの基本構造と依存解決の仕組みを前提に組んだCI設定が残っているなら、11月の試験運用期間を検証の締切として逆算してください。
flutter build swift-packageで既存ネイティブ側へ組み込む手順
3.44ではflutter build swift-packageが追加され、FlutterモジュールをSwiftパッケージとして書き出せるようになりました。ネイティブのiOSアプリへ画面単位でFlutterを埋め込む、いわゆるadd-to-app構成での組み込み方が変わります。
- Flutterモジュール側で
flutter build swift-packageを実行し、成果物のパッケージを得る - Xcodeのプロジェクトへローカルパッケージとして追加し、ターゲットに紐づける
- 既存のCocoaPods由来のFlutter関連podを外し、重複した参照が残っていないか確認する
- CI側のビルドスクリプトから
pod installの呼び出しを外す
詰まりやすいのは3番。add-to-app構成では、ネイティブ側のPodfileにFlutterのpodhelperを読み込ませる書き方が広く使われてきました。この記述が残ると、SwiftPMとCocoaPodsの両方がFlutterエンジンを解決しにいきます。移行時はPodfileの差分を必ずレビュー対象へ入れてください。
Hybrid Composition++で変わるAndroid描画とオプトイン条件
Androidでネイティブビューを混ぜている案件だけが対象の変更です。該当しないなら読み飛ばして構いません。
–enable-hcppとマニフェスト設定|HCPP有効化の2つの入口
Hybrid Composition++(HCPP)はオプトインです。有効化の入口は2つ。開発中に試すならflutter run --enable-hcpp、アプリとして常時有効にするならAndroidManifest.xmlへio.flutter.embedding.android.EnableHcppというメタデータをtrueで書きます。
既定では無効なので、3.44へ上げただけでは描画方式は変わりません。HCPP起因の不具合を疑うときはフラグを外すだけで従来の挙動へ戻せます。切り戻し手段が明確なので、検証は先にフラグ有効で通しテストを回すのが早い順序です。
VulkanとSurfaceControlへの合成委譲が効く画面と効かない画面
HCPPは、Vulkanの低レベルAPIでハードウェアバッファのスワップチェーンを構成し、レイヤーの合成をAndroid OS側のSurfaceControlへ委ねます。従来のHybrid Compositionが抱えていた、ネイティブビューをFlutterのレイヤーへ都度取り込むコストが減る設計です。
効くのは、WebView・地図・カメラプレビュー・動画プレイヤーといったSurfaceViewベースのコンポーネントをスクロール領域へ埋め込んでいる画面。スクロール時のフレーム落ちとタッチ入力のずれが改善対象になります。純Flutterウィジェットだけで構成された画面には効きません。判断は簡単です。AndroidViewの利用箇所をgrepして、ゼロなら対象外と切ってください。
AGP 9とKotlin組み込みが壊すビルドとpubspecの最小バージョン制約
HCPPの前提としてAndroid Gradle Plugin 9系が絡みます。AGP 9はKotlinを組み込みで持つようになったため、build.gradleでorg.jetbrains.kotlin.androidプラグインを手動適用している構成は競合してビルドが落ちます。手動適用の記述を外すのが対処です。
ABIフィルタの扱いも変わりました。フィルタはdefaultConfig側で設定される形になり、独自のフィルタを維持したい場合は-Pdisable-abi-filtering=trueを渡す必要があります。プラグインを配布している側は、HCPP対応を含むAPIを使うならpubspec.yamlのFlutter制約を3.44以上へ引き上げてください。制約を上げずに新APIへ依存すると、古いFlutterで解決された利用者の環境でコンパイルエラーになります。
Agentic Hot ReloadとGenUIが変えるFlutter開発ループの実像
3.44でもっとも話題になった部分ですが、実装者への影響は範囲を限定して捉える必要があります。
MCPサーバー経由でエージェントがホットリロードまで担う仕組み
Agentic Hot Reloadは、Dart・Flutter向けのMCPサーバーを介して、コーディングエージェントが起動中のアプリを自動検出・接続し、UIコードの変更後にホットリロードまで実行する仕組みです。3.44サイクルでは、MCPサーバー側の依存検索の堅牢化と、ツール定義の統合によるトークン消費の削減も入りました。使うにはエージェント側でMCPサーバーを登録する設定が要ります。フレームワークを上げるだけで働く機能ではないため、移行タスクとは切り離して扱ってください。
A2UI準拠のGenUIとGenkit Dartプレビューが担当する範囲
GenUIはオープンなA2UIプロトコルの上に構築され、エージェントがMarkdownの文字列ではなく実際のFlutterウィジェットを組み立てて返せるようにするものです。関連パッケージのダウンロードは年初から500%増と公表されています。
Genkit DartはGoogle・Anthropic・OpenAIの各プロバイダへ対応するプレビュー版で、型安全な構造化出力とツール呼び出しが扱えます。いずれもプレビュー段階であり、既存アプリの3.44移行を検討している段階なら評価対象から外して構いません。
Widget Previewsのメモリ最大50%削減とDevToolsのWASM既定化
開発ツール側では、DevToolsのWASMコンパイルが既定になりました。Widget Previewsはメモリ消費を最大50%削減し、IDE上での常時起動が現実的になっています。統合テストの作成やローカライズのセットアップについてコーディングエージェントへ手順を与えるAgent Skillsも追加されました。エージェントを開発フローへ組み込んでいるチームなら3.44へ上げる動機の一つですが、そうでないチームには移行判断の材料になりません。
Material・Cupertino凍結と破壊的変更が生む改修コストの見積もり
移行コストの見積もりは、破壊的変更の一覧より「どこを探せばよいか」で決まります。
material_ui・cupertino_uiへの分離が示す今後のバージョン管理
MaterialとCupertinoの両ライブラリは、3.44時点でフレームワーク本体において凍結されました。今後はmaterial_uiとcupertino_uiという独立パッケージへ移り、本体とは別のサイクルでバージョンが上がっていきます。本体に同梱された形での更新は3.44が最後という位置づけです。
含意は2つ。デザインシステム側の更新をFlutterのリリースサイクルに縛られず受け取れる一方、pubspec.yamlで管理する依存が1つ増えます。凍結の段階では既存コードの書き換えは不要。次の安定版で分離パッケージが非deprecated扱いになると告知されているため、移行タスクが発生するのはその時点です。今から独自テーマの構造を作り替える判断は、コストの前倒しにしかなりません。
選択系Intent削除とTextDecoration finalが要求する書き換え
3.44の破壊的変更で改修が発生しうるのは主に2点です。1つ目はExtendSelectionByPageIntentの削除で、代替はExtendSelectionVerticallyToAdjacentPageIntent。テキスト選択のキーバインドを独自定義しているエディタ系アプリだけが対象になります。
2つ目はTextDecorationのfinal化。下線と取り消し線を合成するために独自クラスを継承していた場合は、TextDecoration.combine()を使う形へ書き換えます。どちらも該当箇所は限られ、コンパイルエラーとして検出されるため、見落として本番に流れるタイプの変更ではありません。見積もりに乗せるなら数時間の単位です。
ページ遷移ビルダーのimport再編と一括置換で潰せる修正範囲
もう1つ、ページ遷移ビルダー周りのimport整理が入りました。CupertinoPageTransitionsBuilderなどの参照元が再編されているため、該当する記述を検索して置き換えます。IDEの自動importに任せると意図しないパッケージを引くことがあるので、置換後の差分はレビューしてください。ツール側では--web-hot-reloadフラグも非推奨になりました。
合計しても、平均的な業務アプリで発生する修正は限定的。3.44移行の工数を押し上げるのは破壊的変更ではなく、次章で扱うSwiftPMとビルド周りの検証時間だと見積もってください。
Flutter 3.41からの移行手順とCI・依存パッケージの検証順序
順序を間違えると原因の切り分けができなくなります。iOS側とAndroid側を同時に動かさないのが原則です。
検証環境の切り分け|FVMでの並行運用とCIパイプラインの二重化
初手は、3.41と3.44を同一マシンで切り替えられる状態を作ること。FVM(Flutter Version Management)などでバージョンを固定し、CIも既存パイプラインを残したまま3.44用のジョブを別に立ててください。ビルドが落ちたとき、原因がFlutter本体なのか自社の設定なのかを比較で切り分けられます。
依存パッケージのSwiftPM対応確認と未対応時に取る暫定運用
次にpubspec.yamlの依存を棚卸しします。iOSネイティブコードを含むプラグインが、SwiftPM対応済みかを1つずつ確認する工程です。未対応のものはCocoaPodsへフォールバックするため、ビルド時の警告ログをそのまま一覧として使えます。
未対応プラグインが残った場合の選択肢は3つ。上流のリポジトリへ対応状況を確認して待つ、代替パッケージへ差し替える、フォークして自社でSwiftPM対応を入れる。判断の期限は前述の2026年12月2日です。待つ判断を取るなら、11月の試験運用期間までに動きがなければ差し替えへ切り替える、という条件を先に決めておいてください。
Apple SiliconネイティブCLIとRosetta前提のCI設定の見直し
3.44では、macOS向けのコマンドラインツールとiOSデバイスとの通信バイナリがすべてARMネイティブ化されました。Rosettaのインストールが不要になり、Intel版x86 Macのサポート終了も見据えた変更です。影響が出るのはCI側。ビルドマシンのセットアップスクリプトにsoftwareupdate --install-rosettaを含めている構成や、arch -x86_64を明示してツールを呼んでいる箇所は不要になります。
iOS側ではもう1点、プラグインのUIScene移行に関する警告が3.44で出るようになりました。この移行そのものは3.38で導入された論点で、Flutter 3.38.xで入ったiOS UISceneDelegate対応に手順をまとめています。警告が出たプラグインは、SwiftPM対応の確認と同じタイミングで棚卸ししてください。
受託開発の現場でFlutter 3.44へ上げる条件と見送る条件
ここは判断を言い切ります。全案件を一律に上げる進め方は取りません。
今すぐ上げるべき3条件|iOS配信・Android WebView・エージェント運用
次のいずれかに当てはまるなら、3.44移行を今期のタスクへ入れます。
- iOSアプリを継続的に配信しており、2027年以降も保守が続く案件。CocoaPods trunkの読み取り専用化が期限として効くため、先送りするほど選択肢が減る
- AndroidでWebView・地図・カメラプレビューをスクロール領域へ埋め込んでおり、描画のちらつきやタッチのずれが課題として上がっている案件。HCPPが直接の解決候補になる
- コーディングエージェントを開発フローへ組み込み済みで、MCPサーバー経由の運用が回っているチーム。Agentic Hot ReloadとAgent Skillsの効果が出る
優先順位は上から。1つ目は期限がある話なので、他の2つより先に着手すべき対象です。
見送ってよい2条件|凍結前提の巨大UI資産と年内リリース直前の案件
逆に、次の2条件に当たるなら3.44移行は見送ります。1つ目は、MaterialのThemeを深く拡張した独自デザインシステムを抱えている案件。3.44で凍結、次版で分離という段取りが公表されている以上、いま上げてUI周りを検証しても、次版で同じ検証をもう一度回すことになります。分離が確定してから一度で移すほうが総工数は減る計算です。
2つ目は、3か月以内にリリースを控えた案件。SwiftPM移行はビルドと配信の経路そのものを触るため、審査提出直前に入れる変更ではありません。リリース後の最初のスプリントへ回してください。「とりあえず最新版に追従する」という運用だけは避けます。
外部委託でFlutter 3.44移行を任せるときの見積もり項目と成果物
移行を外部へ委託する場合、見積もりに入れるべき項目は工数の内訳より検証範囲の定義です。最低限、次の4つを成果物として合意してください。SwiftPM移行後のiOS・macOSビルドが通ること、依存プラグインごとのSwiftPM対応状況の一覧、HCPP有効/無効それぞれでのAndroid実機確認結果、CIパイプラインの更新差分。
見積もりが「バージョンアップ一式」で丸められている場合は、依存プラグインの棚卸しが含まれているかを確認してください。ここが工数の大半を占めます。Flutter / React Nativeのクロスプラットフォーム開発支援では、こうしたバージョン移行の切り分けから配信ラインの再構築までを対象に相談を受け付けています。着手前にプラグイン一覧とCI構成を共有できると、見積もりの精度は上がる関係です。
よくある質問|Flutter 3.44の移行時期とバージョン選択の疑問
3.44への移行を検討する際に判断が分かれやすい点を、5問に整理しました。
Flutter 3.44はいつリリースされましたか?
安定版の公開は2026年5月18日です。同梱されるDart SDKは3.12.0で、その後に出た3.44系のパッチリリースではDart 3.12.2が組み合わされています。Google I/O 2026に合わせた発表でした。この記事の公開時点(2026年7月27日)では3.44系が最新の安定系列です。
3.41から3.44へ上げるとコードの書き換えは必要ですか?
アプリ側のコード修正は、多くの案件で限定的です。押さえるのはExtendSelectionByPageIntentの削除(代替はExtendSelectionVerticallyToAdjacentPageIntent)とTextDecorationのfinal化(合成はTextDecoration.combine())、ページ遷移ビルダーのimport再編の3点。いずれもコンパイルエラーで検出されます。工数がかかるのはコードではなく、SwiftPM移行に伴うビルド設定とCIの検証です。
CocoaPodsはいつまで使えますか?
trunkが読み取り専用へ移行するのは2026年12月2日、その前段として11月1日から7日に試験運用が予定されています。読み取り専用化後も既存のpodspec取得とビルドは継続できますが、新規公開と新バージョンの登録が止まるため、依存ライブラリの更新を受け取れなくなる形です。Flutter 3.44では未対応プラグインがCocoaPodsへフォールバックする挙動なので、警告ログを移行対象の一覧として使えます。
Hybrid Composition++は有効にすべきですか?
プラットフォームビューを使っていない画面では効果がないため、まずAndroidViewの利用箇所を確認してください。ゼロなら対象外です。WebViewや地図をスクロール領域へ埋め込んでいて描画やタッチに課題があるなら、--enable-hcppで試す価値があります。オプトインなのでフラグを外せば従来動作へ戻せますが、AGP 9系ではKotlinプラグインの手動適用と衝突する点に注意が要ります。
Agentic Hot ReloadやGenUIは3.44に上げるだけで使えますか?
使えません。Agentic Hot Reloadは、コーディングエージェント側でDart・Flutter向けMCPサーバーを登録する設定が前提です。GenUIとGenkit Dartは別パッケージとして提供され、Genkit Dartはプレビュー段階。仕様変更の可能性を織り込んで評価する対象になります。フレームワークの移行タスクとは切り離し、別の検討として扱ってください。
関連記事
- FlutterとReact Nativeの違いと選び方|2026年の判断基準:バージョン移行の前段として、そもそもFlutterを継続採用するかの判断材料になります
- Flutterにおけるアーキテクチャ設計の基本と重要性:移行コストを左右する既存コードの構造をどう組むかを扱っています
- Riverpodとは何か?Flutterの状態管理ライブラリとしての特徴や他ライブラリとの違い:バージョン追従の影響を受けやすい状態管理の選定基準が分かります
- Dartとは?Flutterとの関係・将来性と開発会社を選ぶ5つの判断軸:3.44が同梱するDart 3.12の位置づけを言語側から確認できます
- Flutter 3.38で正式サポートされたHooks(Native Assets)とは:ネイティブコード連携の仕組みを押さえるとビルド周りの変更を追いやすくなります