Webエンジニアが FlutterKaigi 2026 に参加して学んだこと #flutterkaigi2026

2026年10月29日・30日に開催された FlutterKaigi 2026 に参加してきました。今回は機会をいただき、福岡からの出張参加です。2日間で聴講したセッションを中心に、イベント全体を振り返ります。

開催概要

公式サイト: https://2026.flutterkaigi.jp/

2日間を通して感じたこと

聴講したセッションは、AI の活用、品質保証、デザインと UI/UX、Flutter そのものの仕組み、ネイティブや Web との境界、プロダクトの設計と運用と、幅広いテーマにわたりました。Flutter やアプリ開発に限らない AI 活用やデザイン、リファクタリングの話も多く、フロントエンドの目線から見ても非常に勉強になりました。

以下、テーマごとに聴講したセッションを紹介します。

Flutter の今と仕組みを知る

Flutterはどこにでも広がっている

登壇は Google の Flutter DevRel チームの Craig Labenz さん。初日最後の基調セッションで、「Google は Flutter をやめてしまうのでは」という長年の問いに答える形で、3つの取り組みが発表されました。

1つ目は、Issue の整理やレビュー、コードのマージといった実績に応じて権限が上がっていく4段階のコントリビューターラダーです。AI を使って PR を書くのは歓迎しつつ、提出したコードはすべての行を本人が理解していることが求められる、という話が印象に残りました。2つ目はガバナンスで、Linux とデスクトップの実装を担う Canonical を例に、Google 以外の組織がプラットフォームのメンテナーになる仕組みが紹介されました。3つ目は Pluggable Platforms で、新しいプラットフォームがフレームワーク本体に手を入れずに、スクロールの挙動などの実装を登録できるようにする構想です。Google 一社に頼らない形で「ピクセルを描くあらゆるデバイスで Flutter を動かす」方向に進んでいることが伝わりました。

Flutterにおけるテキスト処理パイプラインの仕組み

登壇は Raouf Rahiche さん。1つの文字列が画面のピクセルになるまでを、Flutter で作った3Dの街を巡りながら解説するセッションでした。インタラクティブなスライドでの発表も印象に残りました。

最初に、絵文字1文字でも String.length が11になる例から「文字列とテキストは同じではない」ことが示されました。そこから、スクリプトごとに分割し、フォントを選び（どのフォントにもない文字は豆腐になる）、最も計算が重いシェイピング（アラビア文字の連結、カーニング、合字）、言語ごとに異なる改行、右から左へ書く言語が混ざる双方向テキスト、ラスタライズへと進みます。Flutter は縦書きやルビ、自動のハイフネーションを標準では持ちませんが、その代わりにどのプラットフォームでも同じピクセルを描けるというトレードオフを選んでいる、という整理が分かりやすかったです。日本語の文節での改行を扱うパッケージなども紹介されました。

Dioは1つ、エンジンは多数：劣悪なネットワーク環境でFlutterアプリを生き残らせる方法

登壇は Nariman さん。オフィスや家の Wi-Fi で開発していても、ユーザーはスタジアムのような混雑した場所で使うかもしれない、という前提から始まりました。

1つの Dio のまま、アダプターを作るファクトリで、Android では Cronet、iOS では URLSession を使い、Google Play 開発者サービスのない端末やデバッグ用のプロキシを通すときは Pure Dart の HTTP/2 アダプターに切り替えます。HTTP/3 を有効にするだけでは、対応していないサーバーで動かなくなるので、フォールバックまで用意するのが本当の仕事だという話でした。ほかにも、MessagePack でリアルタイム通信のデータを小さくする、リトライの回数を決める、Wi-Fi とモバイル回線の切り替えなど実際に悪い回線で計測する、といったポイントが紹介されました。

AI を組み込み、確かめる

DartとFlutterのAI評価フレームワークを今すぐ取り入れるべき理由

登壇は Google の Mariam Hasnany さん。モデルやエージェントの変更が本当に良くなっているかを、eval（評価）で確かめるという話です。eval は「AI システムに対するテスト」で、ユーザージャーニーを選ぶ、指標を決める、グレーダーで採点する、という3ステップで書けます。書き方が Flutter のテストとほとんど同じなので、思ったより取り入れやすいと感じました。

flutter_gemini_live: Gemini LiveをFlutterにもたらす

登壇は Google Developer Expert の PARK JAICHANG さん。Gemini の Live API の公式 SDK は JavaScript と Python だけで、Flutter からは Firebase のプロジェクトを用意して Firebase AI Logic を使う必要がありました。そこで API キーで直接つなげられる Pure Dart のパッケージ「gemini_live」を作った、という話です。

公式 SDK と同じ形の API にしているので、公式のサンプルを読めばそのまま Dart で書けます。Firebase AI からは import を差し替える程度で移行できる互換レイヤーもあります。変化の速い API に追いつくための保守には AI エージェントを使っていて、Dart / Flutter の MCP サーバーや Gemini のドキュメントの MCP サーバーを組み合わせ、公式 SDK の変更を検知して Dart に移植しています。パッケージ自体にも、他の開発者が使えるエージェントスキルを12個同梱しています。機能面では、ユーザーが話をさえぎったときの処理、リアルタイム翻訳、カメラ映像を1秒に1枚だけ送ってトークンを節約する工夫、短命のトークンで API キーを守る方法などが紹介されました。

Genkitを活用したFlutterでのハイブリッドAI開発

登壇は Sasha Denisov さん。前半はエッジ AI（オンデバイス AI）の説明で、通信がいらない、データが端末の外に出ない、トークン代がかからない、という利点と、LiteRT や llama.cpp などの推論ランタイムが紹介されました。自身が作った Flutter 向けのオンデバイス推論プラグインは「Flutter AI」に名前を変え、推論エンジンやベクトル DB を差し替えられる仕組みになっています。オンデバイス RAG のデモもありました。

後半のハイブリッド AI は、つまり「ルーティング」です。簡単なタスクや機密性の高いタスクは端末で、複雑なタスクはクラウドで処理します。Firebase AI Logic は「端末優先」「クラウド優先」の2つの戦略しか選べませんが、Dart 版の Genkit を使えば、同じロジックのまま推論先をクラウドと端末で切り替えられ、軽い埋め込みモデルで意図を分類して振り分けることもできます。

品質をどう守るか

AI時代のFlutter品質設計 — アプリ品質を守るQuality Layers

登壇は日本トレカセンターの尾松郁哉さん。少人数のチームで台湾、香港、アメリカへの展開を進めながら、AI で PR を出す人が増えたなかで、品質を誰がどこで守るのかという話です。

設計、コードレビュー、自動テスト、手動テスト、本番の観測、セキュリティを層として重ね、6つの事例が紹介されました。Riverpod v3 への移行後、画面を離れた後に処理が完了して本番でエラーが出た件、GIF や画像が多い画面でメモリが増えて画像の解像度とアップロード容量の基準を見直した件、サーバーサイドのエンジニアが AI で出した PR のレビューで複雑な判定を Provider に移した件、状態ごとのゴールデンテスト画像を PR に貼る運用などです。問題を見つけた層と直した層はばらばらで、1つの層で完璧に守ろうとせず、本番に出るまでに網を何重にも張るのが Quality Layers だという整理がとても参考になりました。

デザインレビューは自動化できるのか？─ Flutter × FigmaでUI品質保証を考える

登壇は WINTICKET の Hirokazu Tanaka さん。AI で1人あたりの PR は増えた一方、最後に確かめる人の側が追いつかない、という課題から始まりました。WinTicket ではレビューで繰り返し出る指摘を自動チェックのルールにしていて、その数は164件になっています。ただ、Figma どおりに作られているかは、今も人がデザインと実装を見比べています。

そこで試作したのが Figma VRT Review です。PR を作ると GitHub Actions で動き、Figma と実装の画像を並べて、余白、色、文字サイズなどの値の違いを PR にコメントします。AI エージェントにそのコメントを渡せば修正まで進められます。難しかったのは数値の比較より、Figma の要素と Flutter の Widget の対応づけで、AI に対応を選ばせ、その答えを機械的に検証する形にしています。結論は「一部は自動化できる」で、空いた時間を仕様やデザインの意図、使う人の目的を考えることに使いたい、という締めくくりでした。

デザインと UI/UX

「収まらない」を仕様にする

登壇は Omiai の Haruhiko Takada さん。小さい端末や、表示や文字を大きくする本体設定によって、検索結果の都道府県が省略されて読めなくなった事例から始まりました。

対応を実装者に任せると、省略する人、改行する人で結果がばらつき、改行で写真の高さが減るといった実装都合の仕様になってしまいます。QA や受け入れテストでの手戻りにもつながります。何を残すかはプロダクトの判断なので、ワイヤーフレームの段階で収まらない可能性がある箇所を見つけ、PdM を含めて合意しておくのが大事だという話です。仕様は Figma の Auto Layout で表現し、表現できない振る舞いはコメントで書く。実装には Flexible や Wrap、LayoutBuilder を使い、Widgetbook で画面サイズと文字サイズの組み合わせを確かめます。AI で実装が速くなっても手戻りがあれば全体は速くならない、という指摘はフロントエンドでもそのまま当てはまると感じました。

ネイティブや Web との境界

認証はもともとネイティブの領域 - Flutterアプリの認証を内製SDKに閉じ込める境界設計

登壇は Sansan のTomoki Hirayamaさん。Bill One 経費アプリで、認証を Flutter 側に書かず Swift / Kotlin の内製 SDK に閉じ込めた事例です。DPoP の署名鍵を OS の安全な領域から出さずに扱えることなどが理由で、二重実装の悩みには共通処理を Rust のコアにまとめる方法で取り組んでいます。

Flutter Webを「SDK」として配る — 20以上のゲームを支える埋め込みアーキテクチャ

登壇は daasuu さん。ナンプレや将棋など多数のミニゲームを Flutter で作り、Next.js 製の脳トレサービス「脳タイム」のページに、mount と dispose ができる部品として組み込んでいる事例です。社内に Flutter に強い人が多く、同じコードをネイティブアプリにも展開できることが Flutter を選んだ理由でした。

Flutter Web はエンジンをきれいに破棄できないため、ゲームごとに same-origin の iframe を作り、iframe ごと捨てる方式にしています。Android Chrome で WebGL のコンテキストが解放されない問題には自前で明示的に解放し、ブラウザ履歴はホスト側に任せ、iOS Safari の長押しルーペも抑止しました。ホストとのやり取りはコールバックの契約を型で公開し、配布は npm、ファイルはバージョン付きのパスで CDN から配信、CanvasKit の先読みで初回表示を速くしています。

プロダクトの設計と運用

複数ドメインを一つのアプリに統合するFlutterの設計と運用

登壇はアサインの須永高弘さん。新卒向けと中途向けに分かれていたアプリを、2026年4月に1つのアプリへ統合した事例です。

1つの変更が両方に影響しないよう、アプリを5つの層に分けて依存の方向を lint で機械的に守り、AI が実装したコードも違反がなくなるまで直す運用にしています。互いのリリースを止めないために、トランクベース開発と機能フラグを使い、フラグには期限をつけて CI で確認しています。リリース後は、操作の履歴とエラーの分類、待ち時間とカクつきの計測、画面や見出し単位でどこまで読まれたかのイベントを組み合わせ、ユーザーが離れた理由の手がかりを得ていました。設計だけでなく、リリースと計測まで含めて決めておくことが大切だというまとめでした。

FlutterKaigi2026の全てのセッションはこちらから視聴が可能です。

会場の様子

公式アプリと公式Web

当日は FlutterKaigi の公式アプリが大活躍しました。タイムテーブルの確認がしやすく、次にどのセッションを聴くかをその場で決められました。公式 Web もセッション情報が見やすく整理されていて、事前に聴講の予定を立てるときに助かりました。

グッズとイベント企画

グッズが充実していて、どれも可愛かったです。スタンプラリーなどの企画もあり、セッションの合間も会場を回る楽しみがありました。タイムテーブルには学生支援や応援 LT、クイズ大会といった企画も並び、セッション以外でも参加者が楽しめる工夫が多いイベントでした。

ブース

平日開催ということもあり学生さんの参加が多く刺激をもらいました。他社のブースはあまり回れませんでしたが、会場全体が楽しそうな雰囲気に包まれていました。懇親会は飛行機の時間の関係で参加できず、そこは少し心残りです・・・。

まとめ：Flutterに限らず幅広い学びがあった2日間でした

Flutter の内部の仕組みから、AI の活用、品質保証、デザインとの連携、プロダクトの設計まで、幅広い話を聴けました。Flutter に限らずアプリ開発全般に通じる話も多く、フロントエンドの立場からも明日から考え方を取り入れられそうなことがたくさんありました。

セッションの内容だけでなく、スムーズな運営や使いやすい公式アプリ、可愛いグッズや企画まで、参加者が楽しめるように細かく考えられたイベントでした。運営スタッフの皆さん、登壇者の皆さん、ありがとうございました。福岡からの出張参加でしたが、参加した価値を十分に感じた2日間です。来年もぜひ参加したいです。

おまけ：ランチの親子丼

初日のお昼に入ったお店の親子丼が美味しすぎて、2日目も同じお店で同じ親子丼を食べてしまいました。
浜松町付近でランチをお探しの際にはぜひ食べてみて欲しいです。

最後に

クラスメソッドでは、一緒に働く仲間を募集しています！

今回のように、タイミングが合えば平日開催のカンファレンスにも参加する機会をもらえたりもします。福岡からの出張参加もその機会をいただけたからこそでした。FlutterKaigi 2026 ではブースを出展したほか、Day2 のランチステージも担当し、技術コミュニティを応援する取り組みにも力を入れています。

DevelopersIO には社員が日々技術記事を書いていて、アウトプットを歓迎する文化があります。Flutter やモバイルに限らず、AI やクラウド、フロントエンドなど幅広い分野のエンジニアと一緒に働けるのも魅力です。

クラスメソッドが気になる方は、ぜひカジュアル面談からお気軽にお声がけください。