2026年10月29日(木)から30日(金)にわたって開催される「FlutterKaigi 2026」に、長田卓馬、成尾嘉貴、田中宏和、瀬藤亮介、赤星光誓、川上健太郎、秋元慎太郎が登壇いたします。なお、サイバーエージェントは今年もゴールドスポンサーを務めます。開催期間中はスポンサーブースを設置し、当社の様々なプロダクトでFlutter開発に携わるエンジニアとお話いただけるほか、限定ノベルティを用意しておりますので、ぜひお気軽にお立ち寄りください。
登壇について
・発表者
赤星光誓｜10/29(木) 13:25 - 13:55
・セッションタイトル
「E2Eってつらくないですか？E2Eの管理コストを下げる手段とその実践」
・概要
E2E テストには、メンテナンスコストが高いという課題があります。私たちのプロダクトでは約 70 シナリオを毎朝Firebase Test Lab上で定期実行していますが、かつては失敗のたびにログと録画を確認して人力で修正するのに疲弊していました。 そこで、失敗時のコンテキスト、ステップ・スクリーンショット・ログ・画面階層を丸ごと自動記録するレポート層を組み込み、全結果とそれぞれの詳細を一つのダッシュボードに集約する取り組みを行いました。 このレポートはそのまま AI の入力にし、一次トリアージ・修正提案は AI へ。AI でやれることは AI に任せ、精度が要るところだけ人間がやる。この分業で、E2E の運用は少しずつ「つらくない仕事」に変わっていきつつあります。 本セッションでは、Flutter公式integration_test から Patrol への移行判断と対応、失敗のコンテキスト一式を自動収集するレポート層の設計と実践方法、失敗テストトリアージの手法を解説します。AI と人間で E2E 運用を分業する実践を、うまくいっていないことも含めて共有します。
【想定視聴者】
・E2E テストの導入を迷っている方
・E2E テストの導入・運用で疲弊している方
・AI をテスト運用に組み込みたいが、何から整備すべきか知りたい方
========================================================
・発表者
成尾嘉貴｜10/29(木) 14:10 - 14:40
・セッションタイトル
「動画プレイヤーはなぜカクつくのか ～Flutterのレンダリングとネイティブの境界を解剖する～」
・概要
動画を再生すると、なぜかアプリが重くなる。動画を扱うFlutterアプリの多くが通る道です。 原因を「動画が重いから」で片付けていませんか？ Flutterは画面のすべてを自分で描くフレームワークです。 そのため、ネイティブのデコーダが生成した映像フレームは、TextureまたはPlatformViewのどちらかの方法でレンダリングします。 カクつきの多くはこの「ネイティブとFlutterの境界」で発生し、UIスレッドとRasterスレッドのどちらで時間を使いすぎたかによって、原因も対策もまったく変わります。 本セッションでは、動画視聴・ライブ配信アプリを長年運用してきた実践から、動画再生中のカクつきを仕組みから解剖し、切り分け方と対策を解説します。また運用中のプレイヤーは「video_player」を使わない独自実装で、iOSとAndroidでは描画方式をあえて分けており、その理由も実例としてお話しします。
このセッションでは以下の流れで解説します：
1. Flutterが1フレームを描く仕組み —— UIスレッドとRasterスレッドの分業、フレーム落ちはどこで起きるのか
2. ネイティブの映像がFlutterに載る2つの経路 —— TextureとPlatformView、それぞれの仕組みと向き不向き
3. TextureとPlatformViewの使い分け —— 何を基準に選ぶのか
4. カクつきの切り分け —— 原因が「UIスレッド」か、「Rasterスレッド」か、「ネイティブとの通信」かを、DevToolsで特定する手順
5. 原因別の対策と実測 —— 無駄な再ビルド・広すぎる再描画・過剰なネイティブ通信を減らすと、どれだけ速くなるのか
【想定視聴者】
・動画等のネイティブ描画を扱うアプリの開発者
・Flutterのレンダリングの仕組みやパフォーマンス改善に興味がある方
========================================================
・発表者
長田卓馬｜10/29(木) 14:30 - 14:40
・セッションタイトル
「プロジェクトコードをキレイキレイしよう！暗黙的な参照を読み解く静的解析」
・概要
Flutterアプリには、単純な参照検索では捉えられない利用関係が数多く存在します。Widgetのoverride、RiverpodやFreezedによるコード生成、ルーティング用アノテーション、integration_test、Widgetbookのstory、プラグインの自動登録などが挙げられます。これらを考慮せずに未使用コードを判定すると、実際に必要なコードまで削除候補として報告してしまいます。 本セッションでは、Dart / Flutter の Dead Codeを検出する OSS Package 「kareki」の開発を通じて得た知見をもとに、Flutterの「暗黙的な参照」を静的解析でどのように扱えるかを解説します。
========================================================
・発表者
川上 健太郎｜10/29(木) 14:20 - 14:30
・セッションタイトル
「macros は死んだ。それで、コード生成の未来はどうなる？ — Dart メタプログラミング興亡記」
・概要
FlutterKaigi 2024 で「体験！マクロ時代の Flutter アプリ開発」が語られたわずか 2 ヶ月後、Dart チームは macros の開発中止を発表しました。私たちが待ち望んだ「build_runner からの解放」は、なぜ実現しなかったのか。 この LT は、その技術的な死因を 10 分で解剖する追悼と再出発の話です。
死因: 静的メタプログラミングと Hot Reload の根本的な衝突 — インクリメンタルコンパイルの中で「コードがコードを生む」ことの本当のコスト 遺産: この失敗が証明した「Dart にとって開発体験こそが憲法」という優先順位
相続人たち: augmentations、高速化される build_runner、そして dot shorthands（3.10）・primary constructors（3.12）が「そもそも生成を不要にする」方向で埋めた領域
予言: json_serializable と freezed の 2027 年はどうなる？
言語機能の「中止」はネガティブニュースではなく、言語設計の価値観が最も露出する瞬間です。その面白さをお届けします。
========================================================
・発表者
strysk｜10/29(木) 15:15 - 15:25
・セッションタイトル
「言語の境界を越えるDart FFI」
Dart FFIは、DartからC ABIに準拠したネイティブコードを直接呼び出す仕組みです。CだけでなくGoやRustなど、C ABIに準拠できる言語で書かれた処理を、そのままFlutterアプリに取り込めます。 Dart/Flutterの世界に閉じていると、他の言語で既に書かれた処理の再利用や、サーバーに集約しづらいロジックをWeb・Appで共通化して動かすといった選択肢は見えにくくなります。 本セッションでは、Dart FFIの仕組みから実践的な活用まで、実際の検証をもとに解説します。
【想定視聴者】
・Dart FFIやネイティブコード連携に興味がある方
・複数プラットフォームでロジックを共通化する手法に興味がある方
========================================================
・発表者
田中宏和｜10/30(金) 11:30 - 12:00
・セッションタイトル
「デザインレビューは自動化できるのか？─ Flutter × FigmaでUI品質保証を考える」
・概要
FlutterではWidget TestやGolden Testなど、UIの品質を担保するための仕組みが用意されています。しかし、「Figmaどおりに実装されているか」という観点のレビューは、多くのチームで人の目に頼っているのが現状です。 スクリーンショットを見比べながら余白やフォント、色などを確認する作業は手間がかかるだけでなく、レビュー品質も担当者の経験に左右されます。 本セッションでは、この課題に対するアプローチとして開発中の Figma VRT Review を紹介します。これは、Flutterで描画した画面とFigmaのデザインを比較し、デザイン差分をレビューできる仕組みを目指したPoCです。 PoCの実装を通して見えてきた、画像比較の難しさや差分検出の精度、Flutterならではの課題、そしてチーム開発へ組み込む際の検討事項を共有します。
========================================================
・発表者
秋元 慎太郎｜10/30(金) 14:00 - 14:10
・セッションタイトル
「アーキテクチャの依存ルールをLintで強制する ～自作 Analyzer Plugin でレイヤー違反を検知する～」
・概要
View・ViewModel・Model と層を分けて設計したのに、気づけば View が Model を直接 import している——アーキテクチャの依存ルールは、時間が経つと自然に崩れます。レビューで毎回目視するのも限界があり、厳格に保つのが難しいです。 では、その見張りを Lint に任せてしまえばいい。Dart公式の Analyzer Plugin システムを使えば、「この層からあの層への依存は禁止」というルールを自分で書いて、機械的に検知できます。 このLTでは、MVVM の依存ルールを強制する小さな自作 Analyzer Plugin（例：「View は Model を直接 import してはいけない」）を題材に、Lint が違反箇所をどう見つけているのかを、実際に動くプラグインで確認します。
このセッションでは以下の内容について詳しく解説します：
・アーキテクチャの依存ルールを仕組みで守る発想
・Lint が違反を見つける仕組み
・Analyzer Plugin システムの基本構成
・自作プラグインデモ — 「View → Model の直接依存」を検知するルールを実装し、違反した import にエディタ／CI で警告が出るまでのデモ
【想定視聴者】
・MVVM など層を分けた設計をしているが、依存方向が崩れた経験のある人
・自作 Lint / Analyzer Plugin でアーキテクチャを機械的に守ることに興味がある人
赤星光誓｜10/29(木) 13:25 - 13:55
・セッションタイトル
「E2Eってつらくないですか？E2Eの管理コストを下げる手段とその実践」
・概要
E2E テストには、メンテナンスコストが高いという課題があります。私たちのプロダクトでは約 70 シナリオを毎朝Firebase Test Lab上で定期実行していますが、かつては失敗のたびにログと録画を確認して人力で修正するのに疲弊していました。 そこで、失敗時のコンテキスト、ステップ・スクリーンショット・ログ・画面階層を丸ごと自動記録するレポート層を組み込み、全結果とそれぞれの詳細を一つのダッシュボードに集約する取り組みを行いました。 このレポートはそのまま AI の入力にし、一次トリアージ・修正提案は AI へ。AI でやれることは AI に任せ、精度が要るところだけ人間がやる。この分業で、E2E の運用は少しずつ「つらくない仕事」に変わっていきつつあります。 本セッションでは、Flutter公式integration_test から Patrol への移行判断と対応、失敗のコンテキスト一式を自動収集するレポート層の設計と実践方法、失敗テストトリアージの手法を解説します。AI と人間で E2E 運用を分業する実践を、うまくいっていないことも含めて共有します。
【想定視聴者】
・E2E テストの導入を迷っている方
・E2E テストの導入・運用で疲弊している方
・AI をテスト運用に組み込みたいが、何から整備すべきか知りたい方
========================================================
・発表者
成尾嘉貴｜10/29(木) 14:10 - 14:40
・セッションタイトル
「動画プレイヤーはなぜカクつくのか ～Flutterのレンダリングとネイティブの境界を解剖する～」
・概要
動画を再生すると、なぜかアプリが重くなる。動画を扱うFlutterアプリの多くが通る道です。 原因を「動画が重いから」で片付けていませんか？ Flutterは画面のすべてを自分で描くフレームワークです。 そのため、ネイティブのデコーダが生成した映像フレームは、TextureまたはPlatformViewのどちらかの方法でレンダリングします。 カクつきの多くはこの「ネイティブとFlutterの境界」で発生し、UIスレッドとRasterスレッドのどちらで時間を使いすぎたかによって、原因も対策もまったく変わります。 本セッションでは、動画視聴・ライブ配信アプリを長年運用してきた実践から、動画再生中のカクつきを仕組みから解剖し、切り分け方と対策を解説します。また運用中のプレイヤーは「video_player」を使わない独自実装で、iOSとAndroidでは描画方式をあえて分けており、その理由も実例としてお話しします。
このセッションでは以下の流れで解説します：
1. Flutterが1フレームを描く仕組み —— UIスレッドとRasterスレッドの分業、フレーム落ちはどこで起きるのか
2. ネイティブの映像がFlutterに載る2つの経路 —— TextureとPlatformView、それぞれの仕組みと向き不向き
3. TextureとPlatformViewの使い分け —— 何を基準に選ぶのか
4. カクつきの切り分け —— 原因が「UIスレッド」か、「Rasterスレッド」か、「ネイティブとの通信」かを、DevToolsで特定する手順
5. 原因別の対策と実測 —— 無駄な再ビルド・広すぎる再描画・過剰なネイティブ通信を減らすと、どれだけ速くなるのか
【想定視聴者】
・動画等のネイティブ描画を扱うアプリの開発者
・Flutterのレンダリングの仕組みやパフォーマンス改善に興味がある方
========================================================
・発表者
長田卓馬｜10/29(木) 14:30 - 14:40
・セッションタイトル
「プロジェクトコードをキレイキレイしよう！暗黙的な参照を読み解く静的解析」
・概要
Flutterアプリには、単純な参照検索では捉えられない利用関係が数多く存在します。Widgetのoverride、RiverpodやFreezedによるコード生成、ルーティング用アノテーション、integration_test、Widgetbookのstory、プラグインの自動登録などが挙げられます。これらを考慮せずに未使用コードを判定すると、実際に必要なコードまで削除候補として報告してしまいます。 本セッションでは、Dart / Flutter の Dead Codeを検出する OSS Package 「kareki」の開発を通じて得た知見をもとに、Flutterの「暗黙的な参照」を静的解析でどのように扱えるかを解説します。
========================================================
・発表者
川上 健太郎｜10/29(木) 14:20 - 14:30
・セッションタイトル
「macros は死んだ。それで、コード生成の未来はどうなる？ — Dart メタプログラミング興亡記」
・概要
FlutterKaigi 2024 で「体験！マクロ時代の Flutter アプリ開発」が語られたわずか 2 ヶ月後、Dart チームは macros の開発中止を発表しました。私たちが待ち望んだ「build_runner からの解放」は、なぜ実現しなかったのか。 この LT は、その技術的な死因を 10 分で解剖する追悼と再出発の話です。
死因: 静的メタプログラミングと Hot Reload の根本的な衝突 — インクリメンタルコンパイルの中で「コードがコードを生む」ことの本当のコスト 遺産: この失敗が証明した「Dart にとって開発体験こそが憲法」という優先順位
相続人たち: augmentations、高速化される build_runner、そして dot shorthands（3.10）・primary constructors（3.12）が「そもそも生成を不要にする」方向で埋めた領域
予言: json_serializable と freezed の 2027 年はどうなる？
言語機能の「中止」はネガティブニュースではなく、言語設計の価値観が最も露出する瞬間です。その面白さをお届けします。
========================================================
・発表者
strysk｜10/29(木) 15:15 - 15:25
・セッションタイトル
「言語の境界を越えるDart FFI」
Dart FFIは、DartからC ABIに準拠したネイティブコードを直接呼び出す仕組みです。CだけでなくGoやRustなど、C ABIに準拠できる言語で書かれた処理を、そのままFlutterアプリに取り込めます。 Dart/Flutterの世界に閉じていると、他の言語で既に書かれた処理の再利用や、サーバーに集約しづらいロジックをWeb・Appで共通化して動かすといった選択肢は見えにくくなります。 本セッションでは、Dart FFIの仕組みから実践的な活用まで、実際の検証をもとに解説します。
【想定視聴者】
・Dart FFIやネイティブコード連携に興味がある方
・複数プラットフォームでロジックを共通化する手法に興味がある方
========================================================
・発表者
田中宏和｜10/30(金) 11:30 - 12:00
・セッションタイトル
「デザインレビューは自動化できるのか？─ Flutter × FigmaでUI品質保証を考える」
・概要
FlutterではWidget TestやGolden Testなど、UIの品質を担保するための仕組みが用意されています。しかし、「Figmaどおりに実装されているか」という観点のレビューは、多くのチームで人の目に頼っているのが現状です。 スクリーンショットを見比べながら余白やフォント、色などを確認する作業は手間がかかるだけでなく、レビュー品質も担当者の経験に左右されます。 本セッションでは、この課題に対するアプローチとして開発中の Figma VRT Review を紹介します。これは、Flutterで描画した画面とFigmaのデザインを比較し、デザイン差分をレビューできる仕組みを目指したPoCです。 PoCの実装を通して見えてきた、画像比較の難しさや差分検出の精度、Flutterならではの課題、そしてチーム開発へ組み込む際の検討事項を共有します。
========================================================
・発表者
秋元 慎太郎｜10/30(金) 14:00 - 14:10
・セッションタイトル
「アーキテクチャの依存ルールをLintで強制する ～自作 Analyzer Plugin でレイヤー違反を検知する～」
・概要
View・ViewModel・Model と層を分けて設計したのに、気づけば View が Model を直接 import している——アーキテクチャの依存ルールは、時間が経つと自然に崩れます。レビューで毎回目視するのも限界があり、厳格に保つのが難しいです。 では、その見張りを Lint に任せてしまえばいい。Dart公式の Analyzer Plugin システムを使えば、「この層からあの層への依存は禁止」というルールを自分で書いて、機械的に検知できます。 このLTでは、MVVM の依存ルールを強制する小さな自作 Analyzer Plugin（例：「View は Model を直接 import してはいけない」）を題材に、Lint が違反箇所をどう見つけているのかを、実際に動くプラグインで確認します。
このセッションでは以下の内容について詳しく解説します：
・アーキテクチャの依存ルールを仕組みで守る発想
・Lint が違反を見つける仕組み
・Analyzer Plugin システムの基本構成
・自作プラグインデモ — 「View → Model の直接依存」を検知するルールを実装し、違反した import にエディタ／CI で警告が出るまでのデモ
【想定視聴者】
・MVVM など層を分けた設計をしているが、依存方向が崩れた経験のある人
・自作 Lint / Analyzer Plugin でアーキテクチャを機械的に守ることに興味がある人