FlutterがSI案件で選ばれる背景と見落とされがちな前提

近年、モバイルアプリ開発においてFlutterを採用する案件が増えています。iOS・Android両プラットフォームに対応したアプリを単一のコードベースで開発できること、高品質なUIを素早くプロトタイピングできること、そしてGoogleによる継続的なサポートが評価されています。SI企業においても、顧客からの「コストを抑えて両OSに対応したい」という要望に応える手段として提案される機会が増えています。

しかし、Flutterを採用する際には事前に把握しておくべき技術的制約がいくつか存在します。これらを見落としたまま開発を進めると、後工程での手戻りや予期しない追加コストにつながるリスクがあります。本記事では、SI企業のエンジニア・PMが特に注意すべき制約を、実際のGitHubのissueを引用しながら解説します。

なお、Flutterの開発言語であるDartはJavaScriptやKotlinと文法的に近い部分もありますが、非同期処理モデルやウィジェット設計の考え方は独自のものです。既存のWebエンジニアやネイティブエンジニアが初めてFlutter開発に入る場合、慣れるまでに1〜2ヶ月程度の学習期間を見込んでおくことが現実的です。

MaterialデザインとCupertinoの差異が現場にもたらす影響

FlutterはGoogleのMaterial Designに準拠したウィジェット群と、AppleのHuman Interface Guidelinesに対応したCupertinoウィジェット群の両方を提供しています。この二系統の存在は柔軟性を生む一方で、実際の開発現場ではさまざまな問題を引き起こすことがあります。

代表的な問題のひとつが、iOSのスワイプバックジェスチャーの無効化です。Flutterの画面遷移で広く使われるWillPopScopeウィジェットを使用すると、iOSネイティブのスワイプで前画面に戻る操作が機能しなくなります。この問題はGitHub issue #14203として2018年から報告されており、125件以上のコメントが寄せられています。ユーザー体験に直結するバグでありながら長期間にわたって残存しており、対処するにはNavigator.of(context).pop()の明示的な実装やCupertinoPageRouteへの切り替えなど、追加の工数が必要です。

また、MaterialとCupertinoのウィジェット間にはAPIレベルの差異も多く存在します。以下の表に主要なウィジェットの差異を示します。

さらに、MaterialとCupertinoのパッケージが依存関係を持っており、片方しか使わない場合でも両方のコードがバンドルに含まれる構造的問題がissue #101479で指摘されています。これはFlutter Webにおいてはmain.dart.jsのファイルサイズ増大（issue #46589）として現れ、初回ロード時間の悪化につながります。SI企業のプロジェクトでは、初期設計段階でデザインシステムをMaterialに統一するかプラットフォーム別対応を行うかを明確に決定し、後からの方針変更を避けることが重要です。

PlatformChannelが抱えるネイティブ連携の課題

FlutterがiOS・Androidのネイティブ機能やサードパーティSDKを呼び出す際は、PlatformChannel（MethodChannel）という仕組みを介して通信を行います。この仕組みによってFlutterとネイティブコードを連携させることができますが、SI案件特有の要件では複数の課題が表面化することがあります。

まず、スレッドモデルの複雑さがあります。PlatformChannelはFlutterのUIスレッドとネイティブのプラットフォームスレッド間で非同期通信を行います。issue #150525（108コメント）では両スレッドのマージが長期的な課題として議論されており、現状ではIsolateを用いた非同期処理で対応することが推奨されていますが、実装の複雑性が増します。UIスレッドのブロッキングが発生すると画面がフリーズするため、重い処理を行うネイティブAPIとの連携ではとくに注意が必要です。

次に、コードプッシュ機能が公式にサポートされていない点も重要な制約です。issue #14330はFlutterリポジトリ中でも最多クラスの288コメントを持つissueで、React NativeのCodePushに相当するホットアップデート機能の実現可能性について2017年から継続して議論されています。現状ではShorebirdなどのサードパーティ製有償ツールが存在しますが、公式サポートではないため、バグ修正やUI変更のたびにAppStore・PlayStore審査を経る必要があります。リリース頻度が高いプロジェクトでは、この制約が運用コストに直結します。

また、地図SDK・WebView・カメラなどPlatformViewを利用するウィジェットでは、Flutterのジェスチャー認識とネイティブViewのジェスチャーが競合する問題が発生することがあります（issue #37579）。決済端末やNFCリーダーといった特殊ハードウェアとの連携が求められるSI案件では、各プラットフォーム向けのPlugin実装をKotlin・Swiftで自前開発しなければならないケースもあり、ネイティブSDK連携1件あたり3〜10日程度の追加工数を見積もっておくことが現実的です。

さらに、Androidのバックボタンでアプリを終了した際にdispose()が呼ばれないケースがあるという問題（issue #40940）も長期間未解決のままです。これはリソースリークにつながる可能性があり、バックグラウンドでの動作が重要な業務アプリでは動作検証を十分に行う必要があります。

Flutter WebにおけるSEOとCORSの構造的問題

FlutterはWebプラットフォームへの対応も進めていますが、Flutter Webを採用する際には2つの重大な制約を理解しておく必要があります。それがSEO問題とCORS問題です。

SEO問題は、Flutter WebのレンダリングがCanvasベース（CanvasKit）であることに起因します。通常のWebサイトはHTMLのdivやpタグでテキストコンテンツが構成されるため検索エンジンがクロールしてインデックスできますが、Flutter WebはすべてのUIをCanvasに描画するためHTMLのテキスト構造が存在しません。issue #46789は2019年12月から継続中の問題で、883件ものリアクションが集まっており、FlutterコミュニティにとってWebの最重要課題のひとつです。Flutterチームのコメントによれば、アクセシビリティ改善が優先されており、SEO対応は後回しとなっています。SSR（サーバーサイドレンダリング）についてもissue #47600で要望が出ていますが未実装のままです。

CORS問題は、Flutter WebアプリがブラウザのCORSポリシーの制約を受けることに起因します。ネイティブアプリ向けのDartではdart:ioのHttpClientが使えますが、Flutter Webではdart:ioが使用できないため、httpパッケージやdioを使ってもブラウザ経由のHTTP通信となり、CORSプリフライトリクエストが発生します。issue #49482（97コメント）をはじめ、CORS関連の問題が複数報告されています。API連携先のサーバーがAccess-Control-Allow-Originヘッダーを返すように設定されていない場合、追加のサーバー設定が必要です。レガシーなオンプレミスAPIとの連携ではCORS設定の改修が困難なケースもあり、BFF（Backend For Frontend）パターンの導入が解決策となることがあります。

これらの制約から、Flutter Webは社内向けツールやイントラネットアプリケーションには適しているものの、SEOが重要なECサイト・コーポレートサイト・メディアサイトへの採用は避けるべきです。SEOが必要なページにはNext.jsなどのフレームワークを採用し、Flutter Webはアプリライクな操作性が求められる管理画面などに限定する使い分けが現実的です。

SI企業がFlutter採用を判断する際のチェックポイント

ここまで解説してきた制約を踏まえ、SI企業がFlutter採用を判断する際に役立つチェックポイントを整理します。

まず、プロジェクトの要件とFlutterの適性を照合することが重要です。以下の表に、Flutter採用が適するケースと適さないケースをまとめます。

次に、工数リスクの定量的な把握も欠かせません。特にPlatformChannelを使うネイティブSDK連携とFlutter WebのCORS対応は、見積もり段階で見落とされやすいリスク項目です。

中長期の保守性についても考慮が必要です。Flutterはメジャーバージョンアップでのコードの変更要求（Breaking Change）が発生しやすく、pub.devのコミュニティプラグインはメンテナンスが停止するリスクがあります。長期保守が前提のSI案件では、プラグインの品質確認と自社実装の方針を初期段階で定めることを推奨します。

Flutterは適切な用途において非常に強力な選択肢です。「クロスプラットフォームだから工数半減」という期待は禁物ですが、本記事で紹介した制約を事前に把握し、要件・チームスキル・保守計画を総合的に判断することでFlutter採用の成功確率は大きく高まります。