FlutterKaigi 2025 参加レポート

はじめに

こんにちは！
株式会社ミラボでモバイルアプリ開発をしている西島です。
前回投稿からだいぶ間が空いてしまいました💦

11/14(金)に開催された、FlutterKaigi 2025 に現地参加してきましたので、昨年と同様、記録に残したいと思います。
(アーリーバードチケットでしたが、前夜祭には参加できませんでした💦)

(前回のFlutterKaigi 2024のレポートはこちら)
https://zenn.dev/milabo/articles/52456624bb8dba

📝 FlutterKaigiの簡単な紹介と参加の目的

FlutterKaigi とは

• Flutter/Dartをメインに扱う日本の技術カンファレンス
• Flutterエンジニアの有志による実行委員会により、Flutter/Dartの知見や情報の共有、コミュニケーションを目的に開催

参加の目的

• 新たな発見や学びを得る
• 刺激を受ける

各セッションの所感

視聴したセッションはどれも素晴らしいものでしたが、個人的に特に印象に残ったセッションをピックアップして所感を記載します。

• 登壇資料は、記事執筆時点で公開されていて見つかったものに関してはリンクを貼付します
  • 記事公開以降に追加で発見したものは、適宜追記します
• 各セッションの動画は、後日YouTubeにアップされるのではないかと思いますので、追ってリンクを追加します

あの日のHot reloadはなぜ動かなかったのか？ 〜OSセキュリティ(W^X)とJITコンパイラの攻防〜

登壇資料

iOS 26でHot reloadが動作しない問題は何となく知ってはいましたが、自分の担当するアプリでは、

• 早期にFlutter 3.35に対応したこと
• 一方、iOS 26対応への着手が遅れたこと(恥ずかしながら💦)

が重なったことで、個人的には実害なく、問題視していませんでした。
セッションでは、この問題の発端から解決までのタイムライン、Discussionや該当のコミットを追うことで、裏でどのような攻防があったのかということが窺い知れました。
また、普段あまり意識することなく、当たり前のように恩恵を受けているJIT/Hot Reloadの仕組みについて、概要的にでも知ることができたのは有意義でした。

Flutterビルドキャッシュの内部構造とテスト高速化への応用

(セッション順ではないのですが、関連性のある内容なので、前に持ってきます)
Dart SDK内でのDart→Kernel(.dill)の流れについての概要的なお話から始まり、この.dillがビルドキャッシュとして活用されること、いかにしてビルドキャッシュの恩恵を受けてビルドを高速化するか？というお話でした。
特に興味深かったのは、

—dart-defineの構成をそのままキーにするので、並び順や値が変わってもキャッシュの恩恵が受けられない
(コンパイル時定数であるため、変化するとコンパイル結果が変わりうるため、キャッシュが無効になる)

という点でした。

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

実際の問い合わせからの原因調査〜DevToolsを使用した原因特定・改善の実例やDevTools機能についてご紹介いただきました。
実例として、UIのカクツキ問題に対して、DevToolsでパフォーマンス測定して、最終的には状態管理(Riverpod)の問題に辿り着いたプロセスが特に興味深く感じました。
もうひとつの実例も含めて、今後自分が直面しうる話であり、本筋のDevToolsとは違う話にはなりますが、事例を踏まえて、実装やコードレビュー、テストなどの観点に含めることも大事かと思いました。
同時に、DevToolsは必要があればなんとなく使ってみる、くらいのスタンスでしたが、受けられる恩恵が大きく、もっと積極的に活用する意識を持ちたいと思いました。

Flutterで挑む次世代認証：Flutter銀行アプリにおける導入実録とその教訓

パスキーは、自分の複数の担当アプリで導入余地がありそうでなこともあり、個人的には目玉のひとつとして臨んだセッションでした。
ご紹介いただいた中で感じたのは、セッション前からうすうす感じていた通り、Flutterでのパスキーの実装自体はそこまで困難なものではなく、むしろ機能導入・運用・保守面での課題が大きそうだということです。

• 端末側の制約や必要設定が多い
• パスワードマネージャーへの依存
• エラー原因特定の難しさ

と言ったものが課題として挙げられていました。
特に、「端末側の制約や必要設定が多い」という中でも、ユーザーが自身で設定すべき項目が多いというのがあり、おそらくかなり苦労されているのだろうなというのと、自分が対応するにしても、ここが最大の課題になるのではないかと思っています💦

RenderObject とは何か？animated_to に学ぶレイアウト計算と描画の仕組み

直接RenderObjectを取り扱うには複数の注意点があり、きちんと理解の上でないと危険なのですが、我々がその危険を冒さなくても、animated_to というパッケージをちゅーやんさんが開発してくれています✌️
https://pub.dev/packages/animated_to

担当するアプリは、積極的にアニメーションを取り入れるような性質のものではなく、それこそRenderObjectを直接触ってアニメーションを実装するようなことはないのですが。。。
animated_to で解決する範囲であれば、やってみてもいいかなとちょっと思っています🤫

アニメーションの話は抜きにしても、レイアウトや描画の仕組みの部分の説明などは本質的に学ぶ点が多く、普段の開発でもそこを意識することの恩恵はありそうだと感じました。

それでは聞いてください「Impeller導入に失敗しました」

登壇資料

アプリのクラッシュレートを含め、問題の予兆をキャッチする手段を用意し、活用することの重要性を改めて感じました。
手元で再現しないけど、実ユーザーからの声で発覚する不具合というのは結構あるのですが、そのような報告からは十分な情報を得られないことも多く、情報を少しでも多く得られるようにしておくことは大事だと、事あるごとに思っています。

セッションとは関係ないところで、登壇者の方とはアフターパーティでお話をさせていただき、所属組織や環境の違いはあれど、似たような課題があったりと、共感できる点が多く、盛り上がりました。
またお会いできましたら、いろいろとお話しできればと思います🙇

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

登壇資料

5選のTipsのうち、特に以下の3つが気になりました。

• 高ディメンションな状態を作る
  • SharedPrefrenceの中身
  • 端末のスペック Low/Middle/High
    • メモリ容量、コア数などで分類する
• バージョンごとに監視する体制を作る
• 新規エラーはAIが勝手に調査するフローを作る

今回、自分が参加したセッションのいくつかで、監視について耳にしています。
自分の担当アプリでも、監視の導入・強化を予定しているところで、高い関心を持っていますので、こうしたセッションは非常に参考になります。

アクセシビリティ、まだ完璧じゃないけど──"今から"できること

登壇資料

アクセシビリティ対応は、担当アプリでも対応しなければならないトピックであり、↑のパスキーのセッションと同じく目玉のセッションのひとつと位置付けていました。

「アクセシビリティ、大事なのはわかってる。だけど、どうしても後回しになってしまう」──そんな経験、ありませんか？

というのがまさに直面する課題と一致していました。
セッション内でも言及されていましたが、
後回しになりやすい原因として、

• 仕様の曖昧さ
• 優先度の見えにくさ
• スケジュールの都合

というのがあって、これもまさにその通りかなと。

ただ、ご紹介いただいたスクリーンリーダーはとっかかりのテーマとしてはやりやすそうというのと、スクリーンリーダーに限らず、小さな単位や改善でもいいので、言い訳して後回しにせずに、ちょっとずつやっていこうという、前向きな気持ちにはなれました💪

(あと、登録だけしてほとんど使っていなかったmixi2を、もっと使ってみようと思いました)

おわりに

今回で3回目のFlutterKaigiの参加でしたが、今回も非常に学びと刺激に溢れていました。
登壇者・運営・スポンサーの皆様、本当にありがとうございました🙇
FlutterKaigi 2026 も楽しみにしています‼️
↓の件も含めて🥷
https://x.com/FlutterNinjas/status/1988972304504877369?s=20