モバイルアプリの技術選定やインフラ構成を検討する立場で「Flutterは終わった」という見出しを目にした方に向けて、この話を整理します。Flutter（Googleが開発するクロスプラットフォームUIフレームワーク）は数年おきに「死亡説」が流れる技術です。今回話題になったのは、Google社内の組織再編をきっかけにした「Flutterはライフサポート状態」という憶測でした。
この記事では、その憶測の中身を運用視点で分解します。話題の中心は組織再編や求人動向ですが、SRE（Site Reliability Engineering、信頼性を保ちながらシステムを運用する職能）やインフラ担当者にとって本当に確認すべきなのは、採用チームの人数ではなく技術スタックの継続性とレンダリングエンジンの投資状況です。
何が起きたと言われているのか
発端は、Google社内のエンジニアリングチーム再編です。対外的なDevRel（開発者向け広報活動）や公開ロードマップの発信が一時的に減速したタイミングと重なり、「Flutterは打ち切りに向かっている」という観測記事が増えました。
実際には社内のエンジニアリング活動自体は継続していたとされ、情報発信の空白期間がクリックベイト記事の温床になった、という説明がされています。その後DevRelの再強化、エンタープライズ導入事例の可視化、Impellerレンダリングエンジン（Flutterの描画パイプラインを刷新する新しいレンダラー）への投資強化が続いたとされています。
インフラ担当者としてまず押さえておきたいのは、Flutterが Google Ads、Google Pay、Family Link、Google Classroom といった同社の内部プロダクションアプリで使われ続けている点です。これは「サイドプロジェクトではなく本番稼働の基盤技術」という位置づけを示す材料になります。
求人数の減少は「離脱」の証拠にならない
「Flutterの求人が減っている」という主張もよく見かけますが、この解釈には注意が必要です。エンタープライズでFlutter移行が起きるとき、多くの場合iOSチームとAndroidチームを統合して1つのFlutterチームにする形が取られます。
つまり求人数の減少は、採用需要の縮小ではなくチーム統合による効率化の結果である可能性があります。SRE視点で言えば、これはオンコール体制やデプロイパイプラインの統合にも直結する変化です。ネイティブ2系統の運用体制を1系統に集約できれば、監視対象・デプロイフロー・障害対応の窓口も単純化できます。
「状態管理の乱立」問題は技術的にどう決着したか
Flutter批判のもう一つの定番が「状態管理ライブラリが多すぎる」という指摘です。ScopedModel、Provider、BLoC、MobX、Riverpodと選択肢が増え続けた経緯があり、これが「エコシステムの分裂」に見えることがあります。
ただし時系列で追うと、これは分裂ではなく段階的な技術的洗練の過程だと整理できます。2018年頃はStream（非同期データの流れを扱う仕組み）とマイクロタスクキューを多用する重量級の実装が主流でした。2020年頃はProviderとコード生成を組み合わせた方式が広がり、ライフサイクル管理が複雑化しました。
その後、単方向データフロー・ステートマシン・きめ細かいリアクティビティ（状態変化を最小単位で検知して再描画する仕組み）という「効いた手法」が残り、過剰なコード生成やマイクロタスク遅延という「効かなかった手法」が淘汰されました。Dart Signals（軽量なリアクティブ状態管理の仕組み）のような同期的で低遅延な選択肢が定着しつつある、という流れです。
関連技術との比較で見る位置づけ
クロスプラットフォーム開発の選択肢としては、React Native（JavaScriptベース）、Kotlin Multiplatform（Kotlinで共通ロジックを書く仕組み）などがあります。Flutterの特徴は、Dart言語とSkia／Impellerによる独自レンダリングでOS標準UIコンポーネントに依存しない点です。
この設計は、OSのUIフレームワークがバージョンごとに変わっても描画結果が安定するというメリットがあります。一方でネイティブUIとの完全な一致を求める要件では、素のネイティブ実装の方が適する場面もあります。技術選定時はこのトレードオフを踏まえて判断する必要があります。
インフラ・SRE視点でもう一点重要なのは、WebAssembly（Wasmコンパイル、ブラウザ上で高速実行するためのバイナリ形式）対応の進展です。FlutterアプリをWeb向けにビルドする際のパフォーマンス改善が続いているという情報があり、Web版とモバイル版で運用基盤を分割せずに済む可能性が広がっています。
今日、自分のプロジェクトで確認できること
Flutterの継続性への不安が業務判断に影響しそうな場合、次のポイントを確認すると実態が見えてきます。
- 使用しているFlutter SDKのバージョンとリリースサイクル（
flutter --versionで確認し、公式チャンネルの安定版更新頻度と照合する） - Impellerレンダリングエンジンが対象プラットフォームで有効化されているか（
flutter configの出力やプロジェクトのpubspec.yaml周辺設定を確認する） - 依存している状態管理ライブラリが活発にメンテナンスされているか（pub.devのパッケージページで最終更新日とIssue対応状況を見る）
- CI/CDパイプラインでのビルド時間・失敗率が過去数ヶ月で悪化していないか（既存の監視ダッシュボードで傾向を追う）
- 社内のiOS/Androidチームがすでに統合されているか、統合予定があるか（オンコール体制やデプロイフローの見直しが必要になるため）
IaC（Infrastructure as Code、インフラ構成をコードで管理する手法）を使ってモバイルアプリのバックエンドを構築している場合、Flutter側の変更がバックエンドAPIの契約に影響することは基本的にありません。ただしWasm対応やImpellerの安定化に伴い、CDNキャッシュ戦略やビルド成果物のサイズが変わる可能性はあるため、リリースノートの確認は継続しておくと安心です。
まとめ
Flutterの「死亡説」は、組織再編に伴う情報発信の空白と、求人数という表面的な指標の誤読から繰り返し生まれてきた経緯があります。技術選定やインフラ設計の判断材料としては不十分です。
判断の軸にすべきは、Google内部での本番導入実績、Impellerなどコアエンジンへの投資継続、状態管理エコシステムの成熟度の3点です。次のアクションとして、自プロジェクトのFlutter SDKバージョンと依存パッケージの更新状況を確認し、チーム統合が進んでいるならオンコール体制の見直しも合わせて検討してみてください。