📝

FlutterKaigi 2025 参加レポート

に公開
Flutter
Model Context Protocol
SLO
FlutterKaigi
LLM
idea

2025年11月13日に開催された日本最大級のFlutterカンファレンス「FlutterKaigi 2025」に参加しました。本記事はその参加レポートとして、セッションのメモや感想をまとめたものです。
個人的なメモや感想になるので、セッションについて詳しいことが知りたい場合は登壇者の方に聞くのが良いと思います。

FlutterKaigi 2025 概要

特に印象に残ったセッション

特に学びが多かった、あるいは自分の業務に直結すると感じたセッション。

  • Flutter DevToolsで発見！本番アプリのパフォーマンス問題と改善の実践
    • DevToolsの使い方については、以前自分でも使ったことがあり便利だと思った内容だった。
    • 発表の中で出てきた不具合内容と改善点について、担当しているアプリでも心当たりがあるため、調査の上で修正対応を進めたい。
  • 顧客価値を実現するFlutter：KPI・SLOから考えるキャリア支援アプリのUIUX設計
    • 「信頼性、応答性、継続可能性」という観点を、自分の担当サービスにも落とし込んで考えたい。非常に内容が濃く、ぜひ資料を読み返したいので資料公開してください・・・。
  • モバイル端末で動くLLMはどこまで実用的なのか
    • ローカルLLMに関しては全く知見がなかったため、概要だけでも知ることができて良かったです。何ができて、現状では何が利用の障壁になっているのかを学べました。

参加セッションのメモと感想

挨拶・Keynote

(10:00 - 10:30 / 2F ASSIGN Hall または RevenueCat Hall)

感想
カンファレンスへの参加を通じて人生が変わったというお話でした。積極的にLT会やカンファレンスに参加し、勉強したいことを発表して他者に教えることで知識が深まり、交流を生んでいくサイクルを積極的に繰り返していてすごい。

昔から勉強会は発表する側に回るべきと言われていましたが、なかなか重い腰が上がっていませんでした。まずは技術記事の公開頻度を増やすことから始めたい。

セッションメモ

  • 勉強したいことがあったら、他の人に教える
  • Material と Cupertino のパッケージ分離
  • 作成するプラットフォームが大事なのではなく、ユーザーが使いやすいことが大事
  • 人が人を変える

Flutter DevToolsで発見！本番アプリのパフォーマンス問題と改善の実践

(11:45 - 12:45 / 2F ASSIGN Hall)
@Gotchi0001

セッション概要

  • Flutter DevToolsを使った効果的なパフォーマンス調査手法
  • Riverpodによる状態管理で陥りがちなアンチパターンとその対策
  • 画像キャッシュサイズの最適化による描画パフォーマンス向上

感想
Flutter DevToolsを使って実務でパフォーマンス改善を行った体験談でした。
解決手法として触れられていた、状態監視の方法としてwatchを局所化する（.selectを利用する）点に関しては、自身のコードでも心当たりがあるため見直しを行いたい。
また、メモリ膨張によるアプリクラッシュの可能性についても、現在報告を受けている原因不明のクラッシュと関連があるかもしれないため、調査・対応を行いたい。

セッションメモ

  • 状態監視の方法に問題があり、不要なbuildが実行されていた
    • watchを局所化する（.selectの利用）
  • メモリリークやメモリ膨張の可能性
    • Memory chartで確認
  • 画像キャッシュの期間指定、サイズ指定
  • Highlight Oversized Imagesの活用

自社テンプレートを実践で使って感じた強みとツラミ

(13:30 - 14:00 / 2F ASSIGN Hall)
@Aosanori620

感想
複数プロジェクトで共通ライブラリを利用する話かと思いましたが、プロジェクトの共通テンプレートを作成したという内容でした。
GoRouterはよく話題に上がるため、自分のプロダクトでも導入可能か一度調査したい。
また、Melosやmiseでのツール管理は積極的に行っていませんでしたが、将来的に他の人がプロジェクトを触る可能性を考えると、環境整備ツールの導入は見直すべきだと感じた。

セッションメモ

  • Feature-Firstで共通部分をcoreとして切り出す
  • GoRouterの採用
  • リポジトリ作成時に自動的に初期設定issueを生成するworkflow
  • 変更されたパッケージをPRのlabelで自動的に設定する
  • TalkerとCrashlyticsを用いてログ送信を実現
  • FVMからmiseへ（公式のGitHubActionsあり）
  • アプリ内部の依存をSPM, Melos7へ

Mobile MCP × Dart VM Service Extensionで実現するAI駆動E2Eテスト整備と自動操作

(14:15 - 14:45 / 1F Skia)
@yu12k25i

感想
Claude Codeから様々なMCP Serverを利用して自動でE2Eテストを整備してみたというお話でした。
AIによる自動操作は、実行速度の問題もあり、プロダクトにそのまま導入するのは現状では難しそう。
ただし、テストシナリオの作成や検証部分をAIで自動化・効率化できるだけでも価値はあるかもしれない（シナリオの保守コストも高いため）。

セッションメモ

  • AIによるデバイス自動操作でE2Eの実装を楽にする方法を提案
  • DartVMServiceで画面情報を取得し、FlutterDriverで実行
  • AIにテストシナリオを書かせる
    • Gherkin記法（ソフトウェアの振る舞いを自然言語で定義）
  • WidgetTreeは情報が多すぎるため、Semantic Treeベースの情報を返すMCPサーバーを作成
    • labelとValueKeyをセットで利用し、Widgetを区別させる
  • ネイティブダイアログ（通知許可など）はFlutterMCPでは操作不可 → MobileMCPを使う
  • 課題：実行時間が遅い、終了条件の定義が難しい
  • E2E整備のうち、テストシナリオ検証で自動操作を利用
  • プロダクションレベルでの活用にはまだ課題が多い

顧客価値を実現するFlutter：KPI・SLOから考えるキャリア支援アプリのUIUX設計

(15:15 - 15:45 / 2F ASSIGN Hall)

須永 高弘＠アサイン CTO

感想
SLO(サービスレベル目標)を適切に選定・評価することでどのような効果が得られるか、というお話でした。
「信頼性」など、少しのミスで指標が大きく変動するため目標に入れにくい項目も、適切に選定・監視する仕組みの重要性を感じました。
「信頼性」と「応答性」に関しては、自分のアプリでも計測方法を整備し、監視体制を作りたいです。また、継続日数によるユーザー行動の変化（ヒートマップ）も分析してみたいと思いました。
一番資料を見返して参考にしたいと思ったセッションなので、なにとぞ資料の公開を・・・。

セッションメモ

  • レイヤードアーキテクチャ
  • 信頼性、応答性、継続可能性
  • 信頼性:
    • セッションあたりのFatalエラー率 ≤= 0.1%以下
    • クラッシュ経験者はリテンション率に悪影響がある (0.1%〜0.05%に抑える)
    • FlutterはUI上の不備に繋がりやすいため、的確にハンドリングしUnhandled Exceptionに発展させない
    • GoogleCloudMonitoringAlert
    • フォーム離脱率の低減：入力を即座にDriftに保存（500ms経過したら保存、7日経過 or ログアウトで削除など）
  • 応答性:
    • 体感レイテンシ < 200ms (Google推奨基準)
    • TTIの短縮 3,000ms以下
    • LCP 2.5秒以下
    • 通信完了を待たず、最小限の意味がある画面を表示 (Simmer / Skeleton)
    • OptimisticUIによる体感速度向上
    • 差分ロード、キャッシュの活用
    • INP, TTIを計測し、タスク完了率への影響を検証
  • 継続可能性:
    • ディープリンク遷移成功率 > 99.0%
    • 文脈完全性率 > 99.5%
    • 認証や前提条件を go_router.redirect で利用
  • まとめ:
    • 作りたい価値を定量的に計測して提供できるか
    • 重要KPIに直結するSLOの選定・強化
    • 顧客価値とSLOの往復によって、技術と体験の深化の循環を生み出す

LT Sessions (16:00 - 16:30 / 1F Skia)

iOSのAssistive Accessって何？Flutterでも気をつけたいUIの話

  • @ynoseda
  • 認知に優しいUIになる機能。ONにすると表示がかなり変わる。
  • 暗黙の状態を無くす（Human Interface Guideline参照）。
  • isAssistiveAccessEnabled をMethodChannel経由で取得し、不要なワークフローを削除するなどの対応が可能。
  • 実機でしか確認できず、スクショも不可。
    Assistive Accessを有効にしているユーザーがいる可能性を考慮し、一度動作検証が必要だと感じた。

ユーザーのアクションを伴うWidgetのGoldenTest

  • VRTテストで利用。
  • Sliverでは画面表示部分しかレンダリングされないため、Finderから取得できない。
  • scrollUntilVisible を増やす、maxScroll や ValueKey を使うなどの工夫が必要。

Flutterアプリ運用の現場で役立った監視Tips 5選

@ostk0069

  • 高ディメンジョンな状態を作る（SharedPreferencesの中身、端末スペック(Low/Middle/High)などを監視に追加）
  • アラート通知する情報を精査する（バージョンを追加するなど）
  • バージョンごとに監視する体制を作る
  • 新規エラーはAIが勝手に調査するフローを作る（Devinが一時調査・issue作成・修正）
  • 監視指標を段階リリースの評価に使う（母比率の推定による計算）
  • 感想：アプリ規模が大きくなる前に、SLOの話とあわせて監視体制の構築は必須だと感じた。

モバイル端末で動くLLMはどこまで実用的なのか

(16:45 - 17:15 / 1F Skia)
@KyoheiG3

感想

  • LLM自体が巨大なサイズになることや、端末スペック依存が顕著になるため、一般的なプロダクトへの組み込みはまだ現実的ではなさそう。
  • インストールできる端末をかなり限定した上で、実験的なプロダクトに組み込むのが限界かもしれない。
  • 素直にiOS (Apple Intelligence) / AndroidのネイティブAI機能を使う方が良さそうだと感じた。

セッションメモ

  • 課題：デバイスのバッテリー消費、デバイスのスペック依存
  • メモリサイズが大きく必要 (例: largeHeap=true。審査リジェクトの可能性も高い)
  • 巨大なモデルのアプリへのバンドルは不可能
  • 初回起動時などに別途ダウンロードする仕組みが必要

LT Sessions (17:30 - 18:00 / 1F Impeller)

FlutterにおけるFigma Dev Mode MCP活用Tips

  • @keigomichi
  • プロンプトからFigmaのデザインデータを取得し、AIエージェントがコードを作成する。
  • get_design_context
  • 精度の良いDartコードをAIが作るために：
    • デザインデータの質を上げる（フレームに意味のある名前をつける、挙動をAnnotationで付与するなど）
    • デザインシステムを構築する（FlutterではCodeConnectが使えないため create_design_system_rules で紐づける）
  • get_figjam でFigJamのデータを元に作成することも可能。

おわりに

パフォーマンス改善、SLO設計、AI活用、テスト自動化など、多岐にわたる分野の最新の知見に触れることができ、非常に有意義な一日でした。
特にパフォーマンスや監視体制については、すぐにでも自分のプロジェクトに持ち帰って活かしたい内容が多くありました。

登壇者の皆様、運営スタッフの皆様、素晴らしいカンファレンスをありがとうございました。

Discussion