FlutterKaigi2026

Flutterのゴールは、常に「画面が存在するすべての場所」でFlutterアプリを動かすことでした。その雄大な計画を確実に実現するための、私たちのロードマップに関する3つの発表をぜひお聞きください。

大規模なコードベースの維持管理は大変な作業になり得ます。

開発をスムーズに進めるために何ができるのか、一緒に見ていきましょう！

今回のセッションでは、以下のトピックを取り上げます：

- `analysis_server_plugins` を使った独自の静的解析ルール、クイック修正、リファクタリングの作成

- `build_runner` と `analyzer` を使った、自プロジェクト向けコードジェネレーターの作成

- `devtools_extensions` を使った、Flutter DevTools へのカスタムタブの追加

どれも最初は難しそうに聞こえるテーマかもしれませんが、心配いりません。本セッションの目的は、「こうしたツールは誰でも作れること」、そして「ごく短時間で作成できること」を実感していただくことです。

「これってネイティブじゃないと無理ですよね？」

Liquid Glassのようなガラス表現、波紋や歪みエフェクト、動きのある背景など、思わず「どうやって作ったの？」と聞きたくなるUIを見るたびに、そう思っていました。

しかし実際には、その多くは Fragment Shader を使うことでFlutterでも実現できます。

一方で、Shaderは「難しそう」「グラフィックスの知識が必要そう」と感じられがちで、実際にFlutterアプリへ取り入れている事例はまだ多くありません。さらに、アプリへ組み込もうとすると、パフォーマンスや描画タイミング、Shaderの管理方法など、実践ならではの課題も見えてきます。

本セッションでは、Fragment Shaderを使ってFlutterアプリの表現力を大きく向上させる方法を、実際のデモを交えながら紹介します。

具体的には以下の内容を扱います。

FlutterでFragment Shaderを利用する方法

実際のアプリで活用できるUI演出とユースケース

Flutter Framework内部でShaderがどのように利用されているのか

Androidで実際に修正したShader関連バグの調査・修正事例

Liquid Glassをはじめとする最新UI表現の実装方法

カスタムShaderの作成方法や、fluttershaders.comを活用したShaderの探し方

単なるShaderの使い方を紹介するだけではなく、「なぜこの表現が実現できるのか」、そして「実際のプロダクトでどう活用するのか」という視点から、Flutterにおける描画の仕組みについても掘り下げます。

このセッションを通じて、Fragment Shaderを"難しいグラフィックス技術"ではなく、Flutterアプリを一段上の体験へ引き上げるための実践的な武器として活用するための知見を持ち帰っていただければと思います。

Flutterアプリの認証は、pub.devのパッケージで済ませるのが定番だと思います。しかし、そうしたパッケージの多くも、中身はネイティブSDKのラッパーです。システムブラウザの起動、Universal Linksのコールバック、Keychain / Keystoreでのトークンと鍵の保管。生体認証もPasskeyも、その正体はOSのAPIです。方式が何であれ、認証の「守る」仕事の大部分は、もともとネイティブの領域にあります。

Bill One経費アプリでは、この前提に立ち、アプリ本体の認証をFlutter/Dart側には書かず、Swift/Kotlin製の内製SDKに閉じ込める道を選びました。DPoP(RFC 9449)の署名鍵をSecure Enclave / Keystoreの外に出さずに扱える。ネイティブ製の他プロダクトともSDKを共有できる。セキュリティ対応をアプリ本体のコードから切り離し、SDK側で一元管理できる。境界をネイティブ側に引くことで、これらが手に入ります。

一方で、Swift/Kotlinの2言語で同じロジックを二重に保守する悩みも生まれます。これに対しては、共通処理を1つのコアに集約し、OS固有の処理だけをDelegateパターンでネイティブ側に委ねる、という作り方ができます。現在、そのコアをRustで実装するアプローチも進めており、この設計もあわせて紹介します。

本セッションでは、OIDC Authorization Code Flow / DPoP / Universal Linksを内製SDKとして実装した経験をもとに、「認証をどこに置くか」という境界設計の考え方をお話しします。

- なぜ認証をFlutter側に書かないのか：鍵管理・OS連携・再利用性・責任分界から考える判断基準

- ネイティブSDKとFlutterの境界設計：MethodChannel Pluginの実装パターン

- iOS(Swift)先行→Android(Kotlin)移植で直面した仕様差異と、二重実装の悩み

- 二重実装から抜け出す選択肢：共通ロジックを1つのコアに集約し、OS固有機能だけをDelegateで呼び出す作り方（UniFFIによるバインディング）

聞き終えたとき、「自分のプロダクトなら認証をどこに置くか」を考える材料が揃っている状態を目指します。

想定視聴者：

- Flutterアプリの認証設計・セキュリティに悩んでいる方

- ネイティブとFlutterの境界設計や、ロジック共通化に興味がある方

◼︎ このトークで話すこと

昨年のFlutterKaigiで、弊社の須永が「顧客価値をSLO/KPIで定義し、Flutterで設計を逆算する」話をし、「長期的なキャリア支援プラットフォームへ」という挑戦を掲げました。今年はその挑戦を実際に進めた話です。新卒と中途を一つのアプリに統合する開発で直面した課題を、どんな技術でどう解き、どうなったかまで、課題→技術→結果でお話しします。

◼︎ 前提

新卒と中途はもともと別アプリでしたが、一貫してキャリアを支えるために2026年に一つのアプリへ統合しました。いまは1アプリ・1リポジトリで、登録動線までは共通、その先は基本的に事業ごとに分かれます。共通部分の変更は両方に影響します。これを、各自が既存プロダクトの責任者を兼ねる少人数のチームで開発しています。このあとの手法は、すべてこの「1リポジトリ・少人数・共通部分あり」という前提の上に成り立っています。

◼︎ 課題1：2つの事業を、一つのアプリで開発する

【課題】

根幹の体験は新卒でも中途でも共通で作りたい一方、事業フェーズの違う中途と新卒では必要な機能も計画も違う。共通と個別が入り混じった開発を一つのプロジェクトで進めるのが難しい。

【解決】

アプリの中を層で分け、共通の体験と事業ごとの機能を切り分けて扱えるようにした。機能が増えても各層の責務が崩れないことを狙ってこの形にした。

【結果】

共通体験と事業別機能を、それぞれの計画で並行して足せるようになった。

◼︎ 課題2：開発とリリースが、互いを止めないようにする

【課題】

1アプリ・1リポジトリにしたことで、片方の開発が他方のリリースを止め、コンフリクトが増え、片方の不具合が全体に響く。

【解決】

developを常にリリース可能に保つブランチ運用と機能フラグでブロックとコンフリクトを抑え、何かあればRemote Configのフラグで旧バージョンへ即座に切り戻せるようにした。モバイルでもWebのように素早く戻せる状態を作りたかったのが理由。

【結果】

チーム間でリリースがブロックし合う状況を減らせた。

◼︎ 課題3：増える画面と機能の一貫性を、仕組みで守る

【課題】

統合で画面も機能も増え、共通部分を両チームが触るので、デザインや実装がばらつきやすい。

【解決】

見た目とコードの一貫性を仕組みで揃え、実装の前にデザインと仕様を突き合わせてズレを先に潰す。

【結果】

一貫性の崩れと、後工程での手戻りを抑えられた。

◼︎ 課題4：少人数で、作り続けられるようにする

【課題】

機能もリリースも増える中、少人数で回し続ける必要がある。

【解決】

定型作業のscript化、開発環境のばらつき解消、AIを使ったワークフローで、日々の開発を効率化する。

【結果】

定型作業の時間を減らし、機能開発に時間を回せるようになった。

◼︎ まとめ

個々の技術の使い方ではなく、顧客に届けたい体験（事業の課題）を起点に技術を選ぶ考え方。昨年は単体アプリの体験品質で示したこの考え方を、今年は複数の事業を一つに統合する構造レベルに広げました。

ほとんどの Flutter 開発者は、バックエンドが必要なときには今でも Node.js や Python を選びます。しかし 2026 年の現在、フルスタック Dart は本番環境での使用に耐えうるレベルに達しており、単一の言語、共有されるデータモデル、そしてサーバーとアプリの間で API コントラクトの不整合が一切起きないというメリットをもたらしています。

このセッションでは、完全な Dart のみでエージェント型アプリケーションを構築します。Serverpod バックエンドで Gemini の呼び出しをオーケストレーションし、構造化されたウィジェットの指示を返します。そして、それを Flutter のフロントエンドで受け取り、実行時に独自のインターフェースを動的に構成します。デモで使用するのは、私が作成して pub.dev で公開したオープンソースのパッケージ `genui_catalog` です。これは、JSON スキーマとイベントバインディングが事前に組み込まれた、本番対応の 17 個の GenUI コンポーネントを提供しています。参加者は誰でも、`flutter pub add genui_catalog` を 1 回実行するだけで、このデモを簡単に再現できます。

ユースケースとして取り上げるのは、西アフリカのクリニック向けに構築された実際の Flutter ヘルスケアプラットフォームである、医療トリアージアシスタントです。Serverpod のアーキテクチャを端から端まで網羅し、GenUI パイプラインに組み込み、さらに Firebase や BaaS と比較した際の本番環境でのリアルなトレードオフについて議論します。

▎ 概要

「Flutterはリリースビルドでシンボルが消えるから解析されにくい」——そんな漠然とした安心感を持っていませんか？ 本セッションでは、意図的に脆弱な実装を仕込んだ自作アプリをreFlutterで解析し、関数名・APIエンドポイント・ハードコードされた秘密情報がどこまで復元できるのかをデモで示します。そのうえで「暴かれた箇所をどう直すか」という攻→守の流れで、本番アプリの不正対策に取り組んだ経験も踏まえ、難読化の効果と限界、秘密情報の持ち方、Play Integrity / App Attestを組み合わせた多層防御を解説します。攻撃者視点を一度体験すると、防御策の優先順位は自ずと見えてきます。

▎ 想定視聴者

- 自分のFlutterアプリがどこまで解析されうるか知りたい方

- APIキーや認証まわりの実装に漠然とした不安がある方

- 難読化・改ざん検知などの不正対策の導入を検討している方

E2E テストには、メンテナンスコストが高いという課題があります。私たちのプロダクトでは約 70 シナリオを毎朝Firebase Test Lab上で定期実行していますが、かつては失敗のたびにログと録画を確認して人力で修正するのに疲弊していました。

そこで、失敗時のコンテキスト、ステップ・スクリーンショット・ログ・画面階層を丸ごと自動記録するレポート層を組み込み、全結果とそれぞれの詳細を一つのダッシュボードに集約する取り組みを行いました。

このレポートはそのまま AI の入力にし、一次トリアージ・修正提案は AI へ。AI でやれることは AI に任せ、精度が要るところだけ人間がやる。この分業で、E2E の運用は少しずつ「つらくない仕事」に変わっていきつつあります。

本セッションでは、Flutter公式integration_test から Patrol への移行判断と対応、失敗のコンテキスト一式を自動収集するレポート層の設計と実践方法、失敗テストトリアージの手法を解説します。AI と人間で E2E 運用を分業する実践を、うまくいっていないことも含めて共有します。

【想定視聴者】

- E2E テストの導入を迷っている方

- E2E テストの導入・運用で疲弊している方

- AI をテスト運用に組み込みたいが、何から整備すべきか知りたい方

録音から文字起こし、要約までをすべて端末内で完結させる音声議事録アプリを、Flutterでどこまで作れるのか。

本セッションでは、実際に動くサンプルアプリの実装と実測データをもとに、その可能性と限界を検証します。対象はiOS/Androidです。

文字起こしには自社開発のAIモデルを端末上で動かし、要約にはiOSのFoundation Models、AndroidのGemini NanoといったOS標準のオンデバイスAIを利用します。

これらをFlutterから扱う実装を解説するとともに、以下を実測データで示します。

- オンデバイス文字起こしの日本語認識精度と処理速度 — クラウドの文字起こしサービスとの差

- オンデバイスSLM（小型言語モデル）による日本語要約の品質とコンテキスト長の上限 — 長時間会議への対応の限界

- オンデバイスAIの利用条件と制約 — モデルの可用性確認、ダウンロード、バックグラウンド実行の制限

オンデバイスAIで何がどこまで実用に耐えうるのか——対面会話の録音・解析アプリ「MiiTel RecPod」の開発で得た知見を交えつつ、オンデバイスAIの実力と限界をお伝えします。

音声はテクノロジーと対話する最も自然な方法の一つになりつつあり、Flutterを使えば、今すぐそれをアプリに組み込むためのツールが手に入ります。このセッションでは、音声認識のための音声テキスト変換（STT）と、自然な応答のための音声合成（TTS）を組み合わせることで、Flutterで音声対応アシスタントを構築する方法を探ります。利用可能なFlutterのプラグインやAPIを取り上げ、クラウド型とオフライン型のソリューションを比較しながら、オーストリア方言への対応といった落とし穴についても焦点を当てます。

ライブデモを通じて、STTとTTSをFlutterアプリに統合する方法、応答性の高い音声インタラクションを実現するためのアーキテクチャの構築方法、そして音声が主な入力手段となった際に直感的と感じられるUIの設計方法をご覧いただきます。セッションの終わりには、アクセシビリティ、生産性の向上、本格的な音声アシスタントのいずれの目的であっても、Flutterアプリに対話機能を拡張するための知識が身についているでしょう。

現在、WebとFlutterの両方へ配布するデザインシステムの構築を担当しており、そこで初めてFlutterに触れています。

色や余白のトークンは両プラットフォームへそのまま展開できましたが、文字間隔（letter-spacing）で壁に当たりました。Figmaでは「フォントサイズの5%」という比率で定義されますが、FlutterのTextStyle.letterSpacingが受け取るのは文字間へ追加する論理ピクセル値で、比率をそのまま渡せません。CSSのように0.05emと書くこともできません。

本LTでは、FlutterではfontSizeとletterSpacingがどちらも論理ピクセルで表現されることを手がかりに、fontSize × 0.05の換算でFigmaどおりの見た目を再現する方法と、その換算をデザインシステムが生成するTextStyleヘルパーに内包させてアプリ側に意識させない設計を、実際に運用中のコードを交えて紹介します。

「デザイントークンは共通化できても、各プラットフォームへの適用方法までは共通化できない。だからトークンでは意味を共有し、Flutter向けの変換はデザインシステムに集約する」という考え方を持ち帰ってもらうことを目指します。Flutterを学び始めたWebエンジニアだからこそ見つけられた、Webとの違いの話です。

Ideal・Empty・Loading・Error・Partial という "Five UI State" は画面設計の代表的なフレームワークですが、生成 AI が絡む機能では、この5状態の意味が大きく変わります。

Loading は数百ミリ秒ではなく数十秒かかり、ストリーミングで「Partial が主役」になる。Error はネットワーク起因だけでなく「AI の回答品質が低い」という曖昧な失敗を含む。Empty は「まだ何もない」ではなく「何を入力すればいいか分からないユーザーを導く場」になる — AI 機能の UI が難しいのは、従来の5状態の設計パターンがそのまま通用しないからです。

本セッションでは、AI 機能における Five UI State のあり方を再定義し、Flutter での実装パターンとともに紹介します。ストリーミング応答を Partial 状態としてモデリングする sealed class 設計と Stream ハンドリング、長時間 Loading を耐えられる体験にする進捗表示・スケルトンの工夫、生成失敗・低品質応答・途中キャンセルを扱う Error 設計、そしてユーザーを最初の一歩に導く Empty（プロンプト提案）のデザイン。ChatGPT や Gemini などの実プロダクトの UI 分析と、実際の Flutter 実装コードの両面から解説します。

AI 機能を「とりあえずチャット UI」で終わらせず、状態設計から体験を作りたい方に向けたセッションです。

対象: AI 機能の実装を控えている・改善したい Flutter エンジニア、UI 状態設計を体系的に学びたい方

Jetpack ComposeやSwiftUIでは、UIをアプリ全体から切り離して確認するプレビュー機能が広く使われています。2025年にはFlutterにもWidget Previewerが登場し、エミュレーターを起動せずにWidget単位でUIを確認できるようになりました。

ただし、開発中の確認だけのために@Previewを整備すると、保守対象が増えてしまいます。そこで、作成したプレビューをVisual Regression Testing（VRT）にも再利用し、UI確認と意図しない見た目の差分検出を一つの定義で実現します。

本セッションでは、@Previewをbuild_runnerで静的解析し、VRT対象の自動生成、スクリーンショット比較、GitHubのPR上で差分表示までを行うアイデアを紹介します。あわせて、WidgetbookなどのFlutterで広く採用されるUIカタログとの使い分けについても整理します。

動画を再生すると、なぜかアプリが重くなる。動画を扱う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のレンダリングの仕組みやパフォーマンス改善に興味がある方

Flutter アプリを開発していると、QA フェーズで「小さな画面サイズの端末では仕様通りに情報が表示されない」「文字サイズを大きく設定するとレイアウトが崩れる」といった指摘を受けることがあります。実際に、私たちが開発・運営するマッチングアプリ Omiai では、横幅の狭い端末でお相手の検索結果画面を表示した際、居住地の都道府県名が省略され、お相手がどこに住んでいるのか分からなくなる問題が発生しました。これは実装前に「収まらないとき」の振る舞いを仕様として定義する必要がある問題でした。

スマートフォンにはさまざまな画面サイズが存在し、さらにアクセシビリティ機能によって文字サイズも変化します。そのため、レスポンシブ対応は実装だけで解決できる課題ではありません。どの情報を必ず表示し、どの情報は省略してよいのか、幅が足りない場合は改行するのか、省略記号 (…) を表示するのか、あるいは縦積みに切り替えるのかといった、「収まらないとき」の振る舞いを実装前に仕様として定義する必要があります。

Omiai では、PdM が表示優先度を決定し、デザイナーが幅不足時の UI の振る舞いを設計し、エンジニアが Figma の Auto Layout とコメントを用いてレスポンシブ仕様を定義しています。Auto Layout だけでは表現できない振る舞いをコメントとして明文化することで、AI コーディングエージェントが仕様どおりに実装でき、人は仕様をもとに実装結果をレビューできる状態を実現しています。

AI コーディングエージェントの普及により UI の実装は高速になりました。一方で、レスポンシブ仕様が曖昧なままでは実装結果はばらつき、レビューや QA での手戻りにつながります。実装前にレスポンシブ仕様を定義することで、実装者や AI の判断に依存しない開発を実現できます。

本セッションでは、レスポンシブ対応が属人化している Flutter アプリ開発チームに向けて、「収まらない」を仕様として定義する実践的な方法を紹介します。要件定義から Figma、Flutter 実装、表示確認まで一貫した開発フローを通して、属人化しないレスポンシブ対応の進め方を解説します。

具体的には、以下の内容を紹介します。

- iOS / Android における画面サイズとアクセシビリティがレスポンシブ対応へ与える影響

- 「収まらない」を仕様として定義する方法（表示優先度、改行、省略、縦積み）

- Figma の Auto Layout とコメントを使ったレスポンシブ仕様の定義方法

- LayoutBuilder、Expanded、Flexible、Wrap、Text.maxLines、TextOverflow.ellipsis を用いた、レスポンシブ仕様の Flutter 実装への落とし込み

- Widgetbook を利用した複数画面サイズ・文字サイズでの表示確認方法

本セッションを聴講することで、「レスポンシブ対応は実装で頑張るものではなく、実装前に仕様として定義するもの」という考え方と、その仕様を Flutter へ落とし込む具体的な実践方法を持ち帰ることができます。

本LTでは、本番運用中のアプリをCocoaPodsからSPMへ安全に移行したい方に向けて発表します。

CocoaPodsが2026年12月に読み取り専用となり、新規バージョンの公開ができなくなります。

それに伴い、FirebaseやSentryなど、多くのアプリから使われているSDKもCocoaPodsへの新バージョン公開を停止します。

そのため、SPM移行はすべてのFlutter iOSアプリにとって避けられない課題となりました。

メドレーが実践したSPM移行では、pubspec.yamlへの数行の設定追加で完了するはずでしたが、予期しない問題が次から次へと発生しました。

この一連のつまづきと、つまづきにどのように対応したのか、実際の経験を共有します。

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 年はどうなる？

言語機能の「中止」はネガティブニュースではなく、言語設計の価値観が最も露出する瞬間です。その面白さをお届けします。

Flutterアプリには、単純な参照検索では捉えられない利用関係が数多く存在します。Widgetのoverride、RiverpodやFreezedによるコード生成、ルーティング用アノテーション、integration_test、Widgetbookのstory、プラグインの自動登録などが挙げられます。これらを考慮せずに未使用コードを判定すると、実際に必要なコードまで削除候補として報告してしまいます。

本セッションでは、Dart / Flutter の Dead Codeを検出する OSS Package 「kareki」の開発を通じて得た知見をもとに、Flutterの「暗黙的な参照」を静的解析でどのように扱えるかを解説します。

リアルタイムのマルチモーダル通信は、Gemini Liveを筆頭に、ユーザーとAIのインタラクションのあり方を再定義しつつあります。しかし、公式のWebおよびモバイル用SDKが開発を進める一方で、Flutterエコシステムには、リアルタイムかつ双方向の音声・テキストストリーミングに対応する、専用かつ包括的なソリューションが欠けていました。

このギャップを埋めるため、私はGeminiのLive APIの全機能をDartエコシステムにもたらすFlutterパッケージ「flutter_gemini_live」を開発し、オープンソースとして公開しました。

本セッションでは、`gemini_live`パッケージを紹介し、実際のアプリケーションへの実装からオープンソースの継続的な維持管理に至るまで、そのライフサイクル全体を詳しく解説します。具体的には、以下の内容を取り上げます。

- `gemini_live`を使用し、ボイラープレート（定型コード）を最小限に抑えて、リアルタイムの音声AIをFlutterアプリに今すぐ統合する方法

- Dartにおいて低遅延の音声ストリーミングと双方向WebSocketをシームレスに処理する背後にある技術アーキテクチャ

本番アプリに次世代の音声機能を今すぐ追加したい場合でも、APIの仕様変更に追随するオープンソースプロジェクトを持続可能に維持する方法を学びたい場合でも、本セッションは実践的な指針となるでしょう。

アプリの差別化がかつてなく求められる昨今、アニメーションは単なる装飾ではなく、プロダクトの品質とユーザー体験を決定づけるコア要素となっています。レンダリングエンジン、Impeller がモバイルのスタンダードとなった今、私たちはどのような表現に挑戦できるでしょうか。

本セッションでは、実プロダクトの UX に調和しつつ、ユーザーの目を惹く「創造的なアニメーション」の構築プロセスと実装戦略を紐解きます。泥臭くなりがちな複雑なアニメーションの試作や数式計算において、近年台頭する AI ツールを相性の良いパートナーとしてどのように組み込み、クオリティと開発速度を両立させているかにも触れます。

さらに、一歩先を行く未来の選択肢として、Fragment Shader を用いた視覚効果のデモや取り組みを紹介します。GPU の力を引き出し、Flutter の表現力の限界をどう超えていくかについて一緒に考えましょう！

バクラク申請・経費精算のFlutterアプリは、仕様をコードで表すことを積み重ねてきました。不正な状態を作れなくするsealed class、取り違えやすいIDを区別するextension type、業務ルールをbool/enum値を返すSpecificationパターン。仕様書や実装者の記憶、ガイドラインに頼らず、コード自身が仕様を表現する設計です。

しかし、仕様をコードで表すという規律は、それを支えるルールや仕組みがなければ徐々に失われます。これまでは、実装者の注意とレビューにより維持してきました。コーディングエージェントが実装する時代に、実装者がすべての業務仕様・アーキテクチャ・開発規律を把握しているという前提は成り立ちません。AIに実装を任せるには、必要な知識を渡し、安全に実装できる仕組み、レビューで得た学びを次の実装へ活かすループが必要です。

本セッションでは、この仕組み全体を**AIハーネス**と呼び、次の4層に分けて設計します。

1. 不正な状態や値を作れなくする — 型: 読み込み中・成功・失敗を表す型や、日本円と外貨を分離する型をsealed classで表現します。申請ID, 明細IDのような取り違えやすい値はextension typeで分け、variant追加時の処理漏れやIDの混同をコンパイラエラーにします

2. アーキテクチャ上の規律から外れたコードを入れない — lint: analysis_server_pluginベースの独自lintで、ガイドラインだけでは守れない違反を検知します。sealed classやenumのswitchでワイルドカードによる網羅性チェックの迂回を禁止するルールを例に、lint設計と導入を解説します

3. 型で表せない業務ルールを実行可能な仕様にする — Specification・テスト・CI: 「どの条件なら申請できるか」のように型だけでは制約できない業務ルールを、bool/enum値を返すSpecificationとして実装します。

Specificationを利用するバリデーションの入力、判定結果、エラータイプをテストケースとして記述し、期待する挙動を実行可能な仕様として表現できます。さらに、対応するテストのないSpecificationが追加された場合はCI失敗とし、テストのない業務ルールの混入を防ぎます。

4. コードから読み取れないアーキテクチャ知識を渡す — SkillとSubagents: 複数の機能にまたがる処理の流れや、画面種別ごとの状態管理方針などを18のSkillに構造化し、実装前のプランと実装後の変更を5つのSubagentsが検証します

このハーネスは作って終わりではありません。PRレビューの指摘を定期的に収集し、新たなルールの種とします。繰り返し指摘され、機械的に判定できるものはlintやCIへ移します。ルール文書、Skill、lint、テストを継続的に更新・整理し、人が注意して守るものを段階的にコードベースの仕組みへ変えています。

本セッションでは、型・lint・テスト・CI・Skillを個別に紹介するのではなく、何をどの層で表現し、どの順番で導入し、どう育てるかを、実際のDartコードとCIの実装を使って解説します。参加者は、自分たちのFlutterコードベースで何をどの層に置き、AIに任せられる範囲をどう広げるかを判断するための設計指針を持ち帰れます。

生成AIの次に来る「フィジカルAI」——AIが物理世界に手を伸ばし、ロボットが再び注目されています。ならば、そのロボットと人をつなぐインターフェースは何で作るのか。私たちはそれを Flutter で作りました。

本LTのテーマは、協働ロボットのインターフェースをFlutterで開発するための システム設計 です。題材は、小型協働ロボットのパレタイジング（箱積み）を制御するGUIを Flutter Web / Dart / Riverpod で開発・実運用してきた事例です。

2年以上本プロジェクトのメインUI担当として関わった体験をもとに、他プロジェクトでも再利用できる形で一例を示ればと思います。Palletizy 開発元の会社 (株式会社 Closer様) には発表の了承を得ております。

メインで話すポイントとして、Web開発ではおなじみの 「クライアント ↔ バックエンド」という開発の分離 を、そのままロボットに持ち込んだことです。当初は Flutter のコード上で ROS (ロボットミドルウェア）の通信を書いてましたが、両者の間に gRPC-Web（ソケット）の境界を1枚引くことで、ロボット固有の通信をインターフェースの向こう側へ押しやり、Flutter側は「よくあるクライアント/サーバー構成」として設計できる ようにしました。結果として、ROSの知見がないモバイルアプリ開発者が参画しやすい構成になりました。また、実機のダミーを用意することで、実機がなくてもFlutterの世界だけで開発ができ、画面とロジックを高速に磨き込めます。

10分で、次の3つを持ち帰ってもらう構成です。

・Flutterアプリを 物理世界（ロボット）のインターフェース として捉える視点

・ロボット特有の複雑さを 通信境界（gRPC-Web）で切り離し、「クライアント ↔ バックエンド」という馴染みのある形に落とし込む設計

・実機なしでFlutterに閉じて開発・テストできる 開発体験

派手なAIの話ではなく、目の前のロボットを実際に動かしているFlutterアプリを、どう設計したかという地に足のついた話です。フィジカルAI時代に「Flutterで物理世界とつなぐ」ための、一つの設計の型を持ち帰ってください。

---

また、本プロジェクトでは Linux アプリ → WEBアプリにプラットフォーム移管や、 3Dビュー作成、 2Dエディタ作成、操作の新規性で特許を取った話など、 発表題材にしやすいテーマがいくつもあります。時間が余ればここも言及できればと思ってます。

Unity、Unreal Engine、Godotなど、モバイルやデスクトップ向けのゲームが作れるエンジンはいくつもあります。

実はこれらとFlutterを組み合わせることが出来、ホットリロードが可能になることをご存知でしょうか？

このセッションではゲームエンジンのデバッグ手段としてのFlutter連携の話をしつつ、Toyotaが公開予定のOSSゲームエンジン「Fluorite」が何故Flutterを選んだのかについて、技術的な側面から推測します。

概要

Dart FFIは、DartからC ABIに準拠したネイティブコードを直接呼び出す仕組みです。CだけでなくGoやRustなど、C ABIに準拠できる言語で書かれた処理を、そのままFlutterアプリに取り込めます。

Dart/Flutterの世界に閉じていると、他の言語で既に書かれた処理の再利用や、サーバーに集約しづらいロジックをWeb・Appで共通化して動かすといった選択肢は見えにくくなります。

本セッションでは、Dart FFIの仕組みから実践的な活用まで、実際の検証をもとに解説します。

想定視聴者

・Dart FFIやネイティブコード連携に興味がある方

・複数プラットフォームでロジックを共通化する手法に興味がある方

■セッション内容概要

2026年、Google I/OでMaterialとCupertinoがFlutterのコアから切り離され、コアは「意見を持たない、真っ白な描画キャンバス」になりました。import 'package:flutter/material.dart' が当たり前だった世界から、既製のウィジェットに頼らず自分で表現を作る力が、これまで以上に問われる時代へと変わりつつあります。

では、Materialが無い「真っ白なキャンバス」に、私たちはどうやって絵を描けばいいのでしょうか？　答えはFlutterの根底にある RenderObject にあります。本セッションでは、Widget/Element/RenderObjectの3つのツリーを改めて解剖し、RenderBox を自ら実装して、Materialでは作れない独自のレイアウト・描画・インタラクションをライブコーディングで構築します。

具体的には以下の内容について解説します。

・Material/Cupertinoのコア分離が意味すること

・Widget / Element / RenderObject の3つのツリーの役割

・レイアウトプロトコルの本質（constraints down, sizes up）

・RenderBox を自作する：performLayout → paint → hitTest

・CustomPaintでは越えられない壁と、RenderObjectで越える方法

・Material非依存で自作デザインシステムを組む実利（breaking change回避）

本セッションはレイアウトの交渉やヒットテストまで一段深く降りる"本物"の自作ウィジェットを扱います。既製部品の外へ一歩踏み出したい方の武器になれば幸いです。

■想定視聴者

・既製ウィジェットの外で独自の表現を作りたい方

・RenderObject・レイアウトプロトコルの仕組みを理解したい方

・自作デザインシステムを設計・運用したい方

バグは直したいけれど、報告を見ても「どの画面か分からない」「再現手順が足りない」「そもそも再現しない」——そんな経験はないでしょうか。報告する人と後で直す人の間には、意外と大きな情報の溝が発生する場合もあり、エンジニア側での修正やそもそもの再現手順の確認に時間を要する場合もあります。

iOSアプリでは社内向けに、アプリ内から情報を自動で集めてバグチケットを起票する仕組みを運用しています。これをFlutterでも作れるのか試してみたところ、Flutterならではの面白い工夫がいくつも必要でした。本LTではその実装に関連して次の3点を紹介します。

1. 画面上の各Widgetを枠で囲んで対象となるWidget選ぶを仕組み

2. 再現が難しいバグのスクショや動画の取得で確実に動画を取得するために、「静止画リングバッファ+デバイスで動画化」で発生した不具合の動画を作成する方法

3. Widget階層・ログ・環境情報などの実行時の情報も一緒にチケットに添付する方法

報告する人の手間を減らしつつ、開発者が最初から直せる情報が揃う状態を目指します。

想定視聴者

- バグ報告と実際の修正の“溝”に困っている方

- 開発者体験（DX）やQAの効率化に興味がある方

- FlutterのElement / RenderObjectや、画面キャプチャ・動画化の裏側が気になる方

ぜひ、“報告しやすくて直しやすい”アプリづくりの入り口を、一緒に覗いてみましょう。

「アプリは作れる。でもバックエンドとAWSが壁になる。」 --- そんな経験はありませんか?

Flutter でアプリを作るとき、認証・データベース・ストレージといったバックエンドが必要になった途端、開発のスピードは落ちがちです。バックエンドのコードに加えて、それを動かすクラウドインフラの構築まで求められるからです。

2026年6月に AWS からパブリックプレビューとして発表された AWS Blocks は、この課題への新しい答えです。認証・データベースなどのバックエンド機能を「Block」という部品として宣言するだけで、アプリケーションコードからAWSインフラが自動生成されます(IfC: Infrastructure from Code)。CloudFormation も CDK も書く必要はなく、AWSアカウントがなくてもローカルでフルスタックに動作します。そして Dart / Flutter はネイティブサポート対象。型安全な Dart クライアントが生成され、Flutter エンジニアも今すぐ使い始められます。

この LT では、10分に凝縮して以下をお伝えします。

- AWS Blocks とは何か、IfC という考え方の超速解説

- Block の宣言から Flutter アプリで動くまでの実演デモ

- 今日から自分で試すための最初の一歩

「AWSはちょっと苦手」という方こそ、まずはこの10分でAWS Blocks の可能性を目撃してください。詳しく知りたくなったら、そこからが始まりです。

生成AIの登場により、エンジニアの学び方は大きく変わりました。

AIを使えば、実装方法やエラーの解決方法、パッケージの使い方など、多くの「答え」を素早く得られるようになり、私自身も生成AIを活用しながら短期間で実務や個人開発に挑戦してきました。

一方で、振り返ると私の成長を大きく後押ししたのは、AIが答えをくれた瞬間ではありませんでした。

Webアプリケーション開発を学んでいた私がFlutterを始めたきっかけは、現役Flutterエンジニアとの出会いでした。その後、FlutterKaigiや勉強会に参加し、多くのFlutterエンジニアと交流する中で、「なぜその設計を選ぶのか」「現場ではどのような技術が使われているのか」「こんなアプローチもあるのか」といった、生成AIだけでは得にくい"視点"に触れることができました。

その視点との出会いは、FlutterKaigi 2026の運営への参加や、Swiftへの挑戦、さらにはより成長できる環境を求めて大阪から東京へ転居するという決断など、新たな一歩を踏み出すきっかけにもなりました。

もちろん、生成AIだけでも多くのことは学べます。しかし、私自身の経験では、人との対話によって初めて見える選択肢や考え方が、次の挑戦につながりました。

生成AIは「How（どう実装するか）」を教えてくれます。一方で、「What（何を学ぶべきか）」「Why（なぜその選択をするのか）」という視点は、人との対話やコミュニティとの関わりの中で広がっていくものだと私は考えています。

本LTでは、AIネイティブ世代の学生Flutterエンジニアとして実践している学習方法をもとに、AIで得られる「答え」とコミュニティで得られる「視点」の違いを通して、AI時代だからこそ実践したいFlutterエンジニアとしての学び方についてお話しします。

【こんな方におすすめ】

・FlutterやDartを学び続けているすべての方

・生成AIを活用して開発・学習をしている方

・「もっと良い実装や設計があるのでは？」と考えたことがある方

・技術だけでなく、新しい視点やアイデアも吸収したい方

・AI時代のエンジニアとして、自分の学び方を見つめ直したい方

・AIネイティブ世代の学生エンジニアが、どのように学び・成長しているのか知りたい方

【このLTでお話しすること】

・AIネイティブ世代の学生が実践しているFlutterの学習スタイル

・AIで得られる「答え」と、コミュニティで得られる「視点」の違い

・Flutterとの出会い、FlutterKaigiへの参加、Swiftへの挑戦を通して得た学び

・AI時代だからこそ実践したい、AIとコミュニティを組み合わせたFlutter学習法

Flutter Webで作ったアプリを既存のWebサービスへ組み込みたい——そんなとき、flutter build web の成果物を配置するだけでは本番運用はできません。

私たちは脳トレサービス「脳タイム」で、ナンプレ・将棋・ソリティアなど20以上のゲームをすべてFlutterで開発し、「npmパッケージとして配布されるWeb SDK」としてNext.js製サービスへ組み込み、本番運用しています。

その過程では、

・Flutter Engineを安全に破棄できない

・ホストSPAとブラウザ履歴が競合する

・Dart↔JavaScript間の初期化タイミングでクラッシュする

・CanvasKitのロードが初回表示を圧迫する

・20以上のタイトルを少人数で保守し続けるとビルド・検証が破綻する

など、「Flutterアプリ」ではなく「SDK」として配布・運用するからこそ直面する課題が数多くありました。

このセッションでは、20以上のゲームを運用してたどり着いたFlutter Web Embedding Architectureを、実運用で得た知見とともに紹介します。

【想定視聴者】

・Flutter Webを既存のWebサービスへ組み込みたい方

・Flutter Webを実サービスで運用・配布する設計に興味がある方

・Flutter WebとJavaScriptの連携、ライフサイクル設計に悩んでいる方

・Flutter Webの採用可否を技術的な観点から判断したい方

【このセッションで持ち帰れること】

・Flutter WebをSDKとして設計・配布するための考え方

・Flutter Webをホストアプリケーションと安全に共存させる方法

・JavaScriptとの境界(API契約)の設計方法

・Flutter Webを複数タイトル・長期運用するための実践的なノウハウ

【お話しする内容】

1. Flutter WebをSDKとして配るとは

・なぜゲームエンジンではなくFlutterを選び、SDKとして配布する構成にしたのか

・なぜiframe構成を採用したのか

・FlutterアプリではなくSDKとして設計する考え方

2. Embeddingのライフサイクル設計

・same-origin iframeによる安全なmount / dispose

・Android ChromeのWebGLコンテキストリーク

・iOS Safariの長押しルーペなど実機依存の落とし穴

3. ホストとの契約設計

・setUrlStrategyによる履歴管理

・js_interopによるイベント通知

・callback契約とLateInitializationError対策

・ready Promiseによる初期化同期

4. SDKの配布とパフォーマンス設計

・npmレジストリでの配布

・バージョン付き配信パスによるキャッシュ戦略

・CanvasKit(WASM)のCDN配信

・dart2wasm + skwasmビルドの本番運用と、埋め込み構成ならではの制約

・prefetchによる初回ロード改善

5. 20以上のゲームを運用するための仕組み

・ゲーム単独起動エントリポイント

・スクリーンショットE2Eによる品質保証

・SDK化によって得られた保守性

最後に、このSDK契約をFlutter Add-to-Appやモバイル向けFlutter SDKへ展開する構想についても紹介します。

Flutter Webを既存Webサービスへ組み込む際には、アプリを配布するのではなく、「SDK」として設計するという視点が重要になります。

本セッションでは、20以上のゲームを継続運用して得た知見をもとに、Flutter Webを既存Webサービスへ安全に組み込むための設計パターンを共有します。

AIコーディングによってFlutterアプリの実装速度が上がる一方、増え続けるコードを誰が、どのようにレビューするのかが新たな課題になっています。本セッションでは、CodeRabbitを使ったAIコードレビューに、Flutter/DartのMCPサーバーから得られるフレームワークやプロジェクトのコンテキストを組み合わせ、Flutter固有の実装をより正確にレビューする方法を紹介します。また、レビュー品質を個人の経験に依存させず、チーム共通の品質基準として運用するための考え方も解説します。

さらに、品質改善をプルリクエストのマージで終わらせず、本番運用までつなげます。CodeRabbit Agent for SlackとSentryを連携し、アラートを起点に問題の調査、修正案の作成、プルリクエストの作成までを進める流れを紹介します。開発時のレビューと本番で得られたフィードバックを循環させ、Flutterチームが継続的に品質と開発速度を高めるためのループエンジニアリングを実現します。

Claude Code Skillsを使うことで、AIエージェントに開発ノウハウやワークフローを持たせられるようになりました。

本セッションでは、Maestro MCP を利用したE2Eテスト作成をベースに、Flutterアプリ向けE2Eテストで繰り返し行う調査・判断・修復のノウハウをClaude Code Skillとして実装した事例を紹介します。

このSkillには、Maestro MCPを利用したテスト生成・実行に加え、

- Flutterコードを調査し、既存のSemantics(identifier)を優先して利用してUIを識別する

- Semantics(identifier)が不足している場合は追加を提案し、より安定したUI識別を行う

- E2Eテストを生成・実行する

- 失敗時はスクリーンショットやUI情報を基に原因を分析する

- テストケースを修正・再実行する

といった、Flutterアプリ向けE2Eテストで実際に繰り返し行うワークフローや判断基準を組み込みました。

セッションでは、Flutterコードの調査、既存のSemantics(identifier)の活用、不足している識別子の追加提案、テスト失敗時の原因分析から修復まで、Claude Code Skillへ組み込んだワークフローを紹介します。あわせて、それらをSkillとして実装する中で得られた知見も共有します。

Flutterアプリを題材に、E2EテストのノウハウをClaude Code Skillへどのように実装し、AIエージェントによる継続的なテスト作成・修復を実現したのか、その考え方と実践を持ち帰っていただければと思います。

React Nativeでアプリ・Webのリリースを経験した私が、7月から新プロジェクトでFlutter（Dart）での開発を始めました。私自身、Flutterは初学者の状態からのスタートでしたが、React Native（TS/JS）の知見がある立場で感じた、Flutter開発における学びを共有します。

本セッションでは、両フレームワークのUI構築と状態管理の思想における共通点と相違点に焦点を当てます。JSXによるコンポーネント定義やReact Hooksによる状態操作の経験が、FlutterのWidgetツリーやRiverpodの世界にどう応用できるのか。学習時の驚きや技術的な気づき、そしてFlutterならではの利点をお伝えします。

ヘルスケアプラットフォームアプリ、クリフォアでは、リリースのたびに手動で確認していた重要な操作フローを、自動で継続的に検証できるようにしたいと考え、チームでE2Eテストの導入を始めることにしました。採用したのは、FlutterアプリのE2Eテストを実現するフレームワークであるPatrolです。

Patrolで主要導線を一通り動かせる状態まで進めました。ただ「動いた」ことと「運用に乗せられる」ことの間には距離があり、いざ継続運用を見据えると、解消すべき課題がいくつも見えてきました。

本LTでは、実際にPatrolでE2Eテストを組んで動かす中でぶつかった課題を具体的に共有します。

ネイティブとWebViewが混在する構成ならではの難しさ、画面の文言に依存したセレクタが壊れやすい問題、テストアカウントの使い回しで状態が引き継がれる問題、など。

あわせて、それぞれに対して今後どう向き合っていこうとしているか、現時点での方針も共有します。「E2Eテストは動かせた。でもここからどう運用に乗せるか」で悩んでいる方の参考になればと思います。

＜想定視聴者＞

・Patrolで実装したE2Eテストを、継続的な運用に乗せたい方

・Flutterアプリの自動テストの「実装のその先」に関心がある方

・E2Eテストは書けたが、壊れやすさ・不安定さに悩んでいる方

・コアバリューにWebViewを採用しているFlutterアプリのE2E運用に悩んでいる方

DartとFlutterの開発チームが、多角的な評価手法を用いてAIツールをどのように分析しているかをご紹介します。ツールの最適化やAIエージェントへの信頼構築に向けて、機能性や開発者のストレス（摩擦）をどのように数値化しているのか、その取り組みをご覧ください。

パッケージを活用すれば、より少ないコードで、よりスピーディにFlutterアプリを開発できます。しかし、パッケージへの依存は、私たちが対処すべきセキュリティリスクを招く要因にもなり得ます。

皆さんは、`pubspec.lock`に記載されたすべてのパッケージのソースコードを、隅々までチェックしているでしょうか。アップデートされた新しいバージョンが、本当に安全だと言い切れるでしょうか。

本セッションでは、パッケージの依存関係を通じてどのようなインシデントが起こり得るのか、そしてそれらのリスクをどう軽減すべきかについてお話しします。背景知識としての「OWASP モバイルアプリセキュリティ」の紹介に加え、npmやpipといった他のエコシステムで実際に起きた事例も取り上げます。

セキュリティリスクを過小評価すべきではありませんが、過剰に反応する必要もありません。

想定される攻撃シナリオを整理し、pubの仕組みを解説することで、実際のFlutterアプリ開発において、セキュリティリスクに対してどのように現実的な判断を下し、対処していくべきかをお示しします。

Flutterの「add-to-app（既存アプリへのFlutter追加）」機能を使えば、既存のネイティブアプリにFlutterを組み込むことができます。しかし、公式ドキュメントやツールがカバーしているのは、導入プロセスのほんの一部に過ぎません。境界を越えたナビゲーション（ネイティブ画面とFlutter画面の遷移）には公式に認められた標準規格がなく、高度な学習資料もネット上にはほとんど存在しません。そのため、私たちが話を聞いたどのチームも、それぞれ孤立した状態で同じような解決策をゼロから作り直しているのが現状です。

LeanCodeでは、銀行をはじめとする様々な業界の大手クライアントに対し、大規模なネイティブアプリへのFlutter統合を支援してきました。クリーンでモダンなネイティブのコードベースはもちろん、KotlinやSwiftすら導入されていないレガシーなプロジェクトにも取り組んできました。また、add-to-appを本番環境で運用している他のエンジニアリングチームへの構造化インタビューも実施し、これまでの経験を集約して、共通の課題（ペインポイント）を特定することに努めてきました。

本セッションでは、現在私たちが開発している「Inlay」というオープンソースのフレームワークについて紹介します。これは、ネイティブとFlutter画面間の型安全なナビゲーションや、マルチエンジン間での状態の自動同期を実現し、複雑なマルチエンジン管理レイヤーを隠蔽するものです。私たちはこのフレームワークが、最新のSwiftUIやJetpack Composeを用いたコードベースから、レガシーなJavaやObjective-Cのアプリまで、あらゆる環境で機能することを実プロジェクトを通じて検証してきました。

この講演では、私たちのフレームワークを採用するかどうかにかかわらず役立つ、add-to-appアーキテクチャの実践的なパターンを学ぶことができます。ナビゲーションの構成方法、Flutterコードの配信手法、そして最も重要なこととして、日々の開発を止めずに移行を進め、将来的に純粋なFlutterアプリへスムーズに完全移行するための計画の立て方について解説します。

FlutterのGenUI SDKを使えば、体験の核となるエージェントと同じくらい動的で表現力豊か、そして一人ひとりに寄り添ったUIを構築できます。

多くのFlutterアプリは、ウィジェットツリーをDartコードとして記述し、アプリのバイナリに含めてビルドします。本セッションでは、Flutterを一つのUIランタイムとして利用し、JSONで定義された画面を実行時に解釈して、ネイティブFlutterウィジェットとしてレンダリングするアーキテクチャを解説します。

このアーキテクチャでは、画面レイアウト、スタイル、テーマ、コンポーネント構成をJSONで定義し、ビジネスロジックは埋め込みJavaScriptランタイムで実行します。UIとロジックをネイティブコードから分離することで、Flutterランタイム自体を固定したまま、画面単位のバージョン管理、JSON差分配信、OTA（Over-The-Air）アップデートを実現しています。

本セッションでは、このランタイムの設計思想に加えて、実運用で得られた以下の知見を共有します。

• JSONスキーマ設計

• ランタイム検証

• 差分更新方式

• パフォーマンス最適化

• リアルタイムデータ処理

• このアーキテクチャが適するケースと適さないケース

取り上げる事例は、macOS、Windows、Web、Android、iOSなど、複数プラットフォームへの展開を前提に設計された商用金融トレーディングシステムです。金融システムでは、リアルタイム市場データ、高い可用性、厳格なセキュリティ制約が同時に求められます。本セッションでは、そのような要求の高い環境において、JSONベースのUIランタイムをどのように設計し、どのような課題に向き合ってきたのかを紐解きます。

さらに近年では、AIエージェントがUIやアプリケーションコードを生成することも一般化しつつあります。しかし自由形式のコード生成では、安全性、整合性、権限境界、データ接続などの検証コストが急速に増大します。

一方、ランタイムスキーマが明確であれば、AIの生成対象も制約できます。UIはJSONスキーマに従い、ロジックはサンドボックス化されたJavaScriptで実行され、データ接続は検証済みのバインディングのみ許可されます。このようにAIの出力先を検証可能なランタイムへ限定することで、安全にUI、ロジック、データ接続を生成・更新できるようになります。

本セッションでは、Flutterを単なるアプリケーション開発フレームワークとしてではなく、JSON UI、SDUI、OTAアップデート、そしてAIが生成したUIとロジックを安全に実行するためのランタイムプラットフォームとして活用する設計と実践をお伝えします。

住宅向けスマートロックプラットフォーム「homehub」では、自社開発のbitlockシリーズをはじめ、MIWA PiACK・Alpha ed lock・TebraXなど、メーカーも通信仕様も異なる多種多様なスマートロックデバイスとの連携をFlutterアプリから実現しています。物理的な鍵の代わりにスマートフォンで施解錠を行うという体験の裏側には、Flutterの標準的なアプリ開発では馴染みの薄い技術領域との格闘があります。

本セッションでは、こうした課題に向き合うために設計・運用されてきた自社製Flutterプラグインを中心に、ネイティブ連携アーキテクチャの実践をお話しします。すべてのデバイス通信を単一のMethod Channelに集約する設計判断とその理由、iOS（Swift）とAndroid（Kotlin）それぞれで異なるネイティブ側の実装戦略と設計思想の違い、そして複数のBLEプロトコルやデバイス種別ごとに異なるコマンド体系をどのように抽象化し、アプリ側から統一的に扱えるようにしているかを、実際のコードを交えて解説します。

BLE通信ならではの実践的な課題にも踏み込みます。スキャンから接続・認証・コマンド実行・切断までの一連のライフサイクルをどう安全に管理しているか、デジタルキーの暗号化とキャッシュの仕組み、そしてプロダクション運用の中で遭遇したBLE接続の不安定さやデバイス固有の挙動にどう対処してきたかなど、現場で得られた知見をお伝えします。

また、BLE直接接続にとどまらないユースケースについてもご紹介します。位置情報を活用してユーザーが自宅に近づくだけで自動的に解錠される「手ぶら解錠 」機能におけるiOS / Androidのプラットフォーム差異の吸収、WiFi / LTEゲートウェイを経由した遠隔施解錠、BLE経由でのファームウェア更新など、スマートロックならではの要件がFlutterのネイティブ連携設計にどう影響しているかをお話しします。最後に、ネイティブ実装から純Dartへの段階的な移行を支える仕組みと、その戦略についても共有します。

Flutterでのハードウェア連携やIoT開発に関心のあるエンジニアの皆さまにとって、持ち帰れるものがあるセッションにしたいと思います。

折りたたみデバイスは、もはや単なる「客寄せパンダ」ではありません。一つの確立されたフォームファクタとなりました。しかし、クロスプラットフォーム開発者にとって、それは「動的な画面サイズ」「物理的なヒンジ」「テーブルトップモードなどの特殊なポスチャ（形態）」といった、恐るべき変数を意味します。

本セッションでは、Androidネイティブの仕組みとFlutterウィジェットの間のギャップを埋めていきます。FlutterがどのようにJetpack WindowManagerをラップしているのかといった内部構造の解説から、ヒンジ検知におけるKotlinとDartの実装比較、そして `dual_screen` エコシステムの活用方法までを掘り下げます。

Flutterのハードウェア制御能力に懐疑的なAndroid開発者の方も、画面の「折り目」に戦々恐々としているFlutter開発者の方も、本セッションを終える頃には、アプリを折りたたみ対応させる難易度が（あるいはその意外な簡単さが）はっきりと見えてくるはずです。

私たちがターゲットとしている医療現場では、電波状況に左右されず、いつでも快適にアプリを使っていただくための工夫が欠かせません。

そこで有効なのが「オフラインファースト」での設計です。

しかし、オフラインファースト設計はデータ同期や競合解決の難易度が高く、バックエンドとのインターフェースまで含めて慎重に設計する必要があります。

本LTでは、オフラインファースト設計の実践例と、私が実践においてハマった落とし穴、そしてその回避策を紹介します。これからオフラインファースト設計を取り入れる方に正攻法を持ち帰っていただくことを目指します。

ユーザー入力をトリガーとしてサーバーの応答を待たずにUIを先行更新する「楽観的更新」の導入は、優れたユーザー体験を担保する上で不可欠な設計パターンになっています。

しかしながら、楽観的更新を単純に実装すると、APIリクエストの乱発によるサーバー負荷の増大や非同期処理の競合を誘発してしまいます。加えて、Flutterプラットフォームにおいては、これらの一連の制御を統合的にカプセル化する標準機能や決定版となるライブラリは未だ確立されていません。

本セッションではこの課題に対し、外部ライブラリに頼らずDartネイティブの機能のみで堅牢なアーキテクチャを構築するアプローチを紹介します。

クライアントサイドの快適な応答性を維持しつつ、サーバー負荷を最小限に抑える仕組み作りについて、エッジケースへの対策を交えながら、Flutterにおける状態管理全般の設計知見まで体系的に共有します。

日本語

Flutterアプリのパフォーマンスを測るとき、私たちは「120 FPSで滑らかに動作しているか」「カクつき（Jank）がないか」を優先して確認しがちです。しかし、どれほど滑らかに動いていても、裏でユーザーのスマホのバッテリーを激しく消費し、端末を熱くさせているとしたら、それは本当に優れたアプリと言えるでしょうか。

実は近年、Flutterの公式リポジトリでも「消費電力（perf: energy）」に関するIssueの議論が活発になっています。ただ、スマホの実際の消費電力をコードから正確に測ることは簡単ではありません。そこで本セッションでは、DevToolsのタイムラインやGPUの動きをヒントにして、アプリがどれくらい電力を消費しているかを予測・評価するアプローチを紹介します。

ついつい使ってしまう BackdropFilter や ShaderMask などの描画負荷の高いWidgetが、なぜ、どのように端末の電力を奪っていくのか。その仕組みを整理しながら、ユーザーのスマホにも、そして環境にも優しい「エコなFlutterアプリ」を作るための実践的なヒントを共有します。

English

When optimizing Flutter apps, we often focus purely on smoothness—checking if the UI hits 120 FPS without any jank. But even if an app glides effortlessly, can we consider it truly optimized if it silently drains the user's battery and heats up their phone?

Within the Flutter ecosystem, discussions around power consumption have become increasingly prominent under the official perf: energy issue label. Since directly measuring battery power in code is tricky, this talk introduces how we can analyze DevTools timelines and GPU workloads as a practical proxy to estimate energy impact.

We will look into why rendering-heavy elements like BackdropFilter and ShaderMask are so power-hungry behind the scenes, and share realistic tips on how to build energy-conscious Flutter applications that protect both user hardware and overall resource efficiency.

この1年間で、私たちは flutter.dev、docs.flutter.dev、そして dart.dev のすべてを、Dartでウェブサイトを構築するためのオープンソース・フレームワークである「Jaspr」へ移行しました。本講演では、この移行劇の全貌をお伝えするとともに、数百万人のFlutter開発者を支えるドキュメントサイトとしてJasprがその重責を果たせたのかどうかを検証します。

アジェンダ：

- 各ウェブサイトの移行時に直面した課題

- 最終的に得られたメリットとデメリット

- Jasprを大規模にドッグフーディング（自社利用）したことが、フレームワーク自体にどのような影響を与えたか

また、今回の移行という現実のニーズから生まれた、開発者体験（DX）、パフォーマンス、フルスタック機能の向上に焦点を当てたJasprの最新機能や今後追加予定の機能をいち早くご紹介します。

アプリ開発を行っている方でも、ウェブ開発を行っている方でも（あるいはその両方でも）、本講演を通じてJasprがFlutterエコシステムの重要な隙間をどのように埋めているかをご理解いただけます。講演が終わる頃には、Jasprの現状やプロダクション環境での信頼性、そしてご自身の技術スタックに安心して導入できるものかどうかが見えてくるはずです。

FlutterではWidget TestやGolden Testなど、UIの品質を担保するための仕組みが用意されています。しかし、「Figmaどおりに実装されているか」という観点のレビューは、多くのチームで人の目に頼っているのが現状です。

スクリーンショットを見比べながら余白やフォント、色などを確認する作業は手間がかかるだけでなく、レビュー品質も担当者の経験に左右されます。

本セッションでは、この課題に対するアプローチとして開発中の Figma VRT Review を紹介します。これは、Flutterで描画した画面とFigmaのデザインを比較し、デザイン差分をレビューできる仕組みを目指したPoCです。

PoCの実装を通して見えてきた、画像比較の難しさや差分検出の精度、Flutterならではの課題、そしてチーム開発へ組み込む際の検討事項を共有します。

Flutterアプリの課金機能について、サービス終了対応まで経験した知見をもとにお話しします。 in_app_purchase を使ったサブスク・消耗型の実装やサーバー検証、テスト・審査で踏みがちな罠から、「アプリを取り下げてもサブスクは止まらない」といったサービス終了時の課金機能の閉じ方まで扱います。 課金機能を実装からクローズまで、サービスの一生というスパンで設計・運用できる視点を持ち帰っていただくセッションです。

FlutterKaigi 2022で「15万行を100分割する」マイクロモジュール開発を紹介してから4年。

私が現在所属しているSansan株式会社のBill Oneモバイル開発チームでは、180超のpackageを7段階レイヤーに整理・細分化し、2022年から更に改善したモジュラーモノリスとして運用しています。

ある意味以前とあまり変わらない、とてもシンプルな分割原則の裏に、並行開発での影響最小化や、AI Agent統合に関する勘所が潜んでいます。

本セッションでは、2026年現在の7段階レイヤーとマイクロモジュール設計が、人間によるコーディングとAI Agentによるコーディングそれぞれにどう効くか、実例とともに紹介します。

銀の弾丸ではないが、AI時代の大規模Flutterアプリ設計に悩むエンジニアへ届く原則を共有します。

※2022年の講演を見ていなくても問題ないようにトークを構成予定です。見ていただけていた場合は、より時代の変化を楽しんでいただけるかと思います。

トークの内容（予定）:

・アーキテクチャ概要 〜7段階マイクロモジュール・アーキテクチャ〜

・AGENTS.md・docs・開発ツール連携によるアーキテクチャとAIの融合

・Dependency Injectionと、DIを活かしたモジュール単位のテスト設計

・なぜアーキテクチャ遵守を徹底させるのか 〜従順な実装を求める意味〜

多くのFlutterアプリでは、AIはクラウド専用の機能として扱われています。リクエストを送信し、応答を待ち、トークンごとに費用を支払う、という形です。しかし、オフラインでの利用シナリオや、リアルタイムのやり取り、あるいはユーザーデータをデバイス外に一切送信すべきではない機能についてはどうでしょうか？

ハイブリッドAIは、単一のアプリケーション内でクラウドモデルとオンデバイスモデルを組み合わせます。GeminiやOpenAIといったクラウドプロバイダーが複雑な推論やマルチモーダルタスクを処理する一方で、Gemma、Llama、DeepSeek、Phiなどのローカルモデルはユーザーのデバイス上で直接動作し、低レイテンシーでの応答、オフラインアクセス、そしてデータプライバシーを実現します。これまで常に課題となっていたのは、API、フォーマット、デプロイモデルが異なる2つのまったく別個のAIスタックを管理・維持することでした。

GenkitのDart SDKとそのプラグインシステムが、この問題を解決します。TFLite/LiteRTモデル用の`genkit_flutter_gemma`や、GGUF用の`genkit_llamadart`といったプラグインを使用することで、クラウドプロバイダーで使うのと同じAPIを介して、Android、iOS、macOS、Windows、Linux、Web上でオンデバイス推論を実行できます。クラウド推論とローカル推論の切り替えは、たった1行のコード変更で完了します。同じフロー、同じ構造化出力、同じツール呼び出しのまま、モデルの参照先を変えるだけで済むのです。

本記事ではまず、Genkitの概要として、そのコア概念、プラグインアーキテクチャ、そしてフロー、構造化出力、ツール呼び出し、エージェンティックワークフロー、ミドルウェアシステムといったAIオーケストレーションを構築するための機能について説明します。次に、Dart版Genkitをユニークなものにしている点、すなわちバックエンドからフロントエンドまで、Flutterアプリと同じ言語でAI機能を構築できるネイティブSDKであるという点について深く掘り下げます。最後に、ハイブリッドAIアプローチの詳細に焦点を当てます。なぜそれが重要なのか、どのようなアーキテクチャパターンが可能になるのか、そして実践においてどのように構築するのか（クラウドモデルとオンデバイスモデルの設定、両方で動作する共有フローの定義、アプリケーションロジックを変更することなく単一のGenkit APIを介してそれらを切り替える方法など）を解説します。

私は株式会社アサインで、新卒学生向け就活支援のプロダクト開発を担うエンジニアです。企業情報や企業の採用イベントを検索・閲覧できる機能を、企画からFlutter実装まで一貫して担当しました。

AIの力で、作ること自体のハードルは大きく下がりました。その分、何を作るのか、なぜ作るのかを、エンジニアが検討する場面が増えてきていると思います。このLTでは、私が実践している企画から実装まで一貫して進める新機能開発のプロセスをお話しします。事業の狙いの確認から、ユーザーインタビュー、企画、プロトタイプ、UIデザイン、設計、Flutter実装までの全体の流れを紹介した上で、中でもユーザーインタビューを、準備・実施・分析に分けてお話しします。最後に、そこで決めたことがFlutterのコードにどう繋がるかを紹介します。

ユーザーインタビューやプロトタイプ検証という言葉は知っていても、なかなか取り組む機会がなかったり、方法が分からなかったりするかもしれません。インタビューの設計や分析のドキュメント、プロトタイプ、UIデザインといった実物の一部を投影しながら話すので、そういう方の参考に少しでもなれば幸いです。

**具体的なトーク内容**

- 新機能開発の全体の流れ。事業の狙いから、インタビュー、企画、プロトタイプ、UIデザイン、設計、Flutter実装まで

- インタビューの準備。1名のプレインタビューで仮説を立て、目的・仮説・キークエスチョンを設計した過程

- インタビューの実施。学生4名に60分ずつ実施した、当日の聞き方や進め方

- 分析と企画への反映。1人の発話を鵜呑みにせず、複数人で再現した示唆を中心に企画に反映する運用

- 企画したことが設計を経て、Flutterのfreezedの型定義、OpenAPI Generatorの生成型、go_routerのナビゲーションなどに反映される

**想定する聞き手**

- Flutterエンジニア、モバイルアプリエンジニア

- 実装だけでなく、「何を作るか」を決めるところから関わってみたい人

- 個人開発で企画から実装まで全部1人でやっていて、作る前の検証のやり方を知りたい人

- チームで開発していて、自分の手元に仕様が届くまでに何が起きているのかを見てみたい人

**持ち帰ってもらえるもの**

- ユーザーインタビューの準備・実施・分析で、具体的に何をするのかの一例

- 「何を作るか」を決めるまでの全体の流れ

- 実装の手前の決定が、Flutterコードのどこに現れるかという対応

【本文】

Flutterアプリにユーザー行動を計測するイベント送信を整備したいと思っても、全画面・全操作へ手作業で実装するのは大きな負担です。

作業自体は単調でありながら、イベント名やパラメータの揺れ、実装漏れ、不要なログの追加が起きやすく、リリース後も仕様と実装の同期を維持し続けなければなりません。

マッチングアプリの Omiai でもイベント送信が十分に整備されておらず、ユーザーがどの画面で何を操作しているのかを継続的に把握できない状態が続いていました。

UI改善の仮説を立てても、判断に必要なデータが不足し、施策の優先順位付けや効果検証が難しく疎かになるという課題がありました。

そこで、Figma上で作成している、各画面のボタンや入力欄などを操作したときの挙動を記したアプリ操作仕様書を起点として、イベント送信の設計書とFlutterの実装コードをAIで生成するワークフローを構築しました。

このワークフローでは、以下の流れでイベントログを実装します。

（1）Figma上で、計測対象となる画面・操作を定義する

（2）上記の定義とイベント設計規約をもとに、イベント名や送信条件を含むログ設計書をAIで自動生成する

（3）人間がログ設計書の生成結果をレビューし、イベント漏れを防ぐ

（4）ログ設計書とイベント送信実装規約をもとに、Flutterアプリへ追加するDartコードをAIで自動実装する

（5）人間が実装結果をレビューし、実装漏れや過剰な計測を防ぐ

AIへ単純に「ログを追加して」と依頼するのではなく、Figmaの操作仕様とログ設計書を中間成果物として置くことがポイントです。仕様を起点にすることで、AIによる推測を減らし、デザイン・ログ設計・Flutter実装の対応関係を追跡できるようにしました。これにより、データ分析チームなどの他チームへのログ仕様の連携もしやすくなります。

本LTでは、実際に構築したワークフローと生成されるDartコードの例を紹介します。また、AIに任せられた部分、レビューが必要だった部分、実運用して分かった限界についてもお話しします。

最後に、整備したイベントログによって、ユーザー行動の現状把握、改善施策の優先順位付け、リリース後の効果検証がどのように変わったのかを紹介します。

【想定聴衆】

・Flutterアプリのイベントログを整備したいが、実装工数や漏れに悩んでいる方

・Figma上の仕様とFlutterの実装がずれることに課題を感じている方

・AIコーディングエージェントを、単発のコード生成ではなく開発ワークフローとして組み込みたい方

大半のFlutterアプリは、通信環境の整った状態で開発・テストされています。しかし、現実のユーザーが置かれているのはそんな環境ではありません。電波が途切れ途切れの場所でアプリを開く顧客や、ハンディースキャナーを手にWi-Fiのデッドゾーンを行き来する倉庫スタッフなどです。そうしたネットワーク下では、Dart標準のHTTPスタックを使っているだけで、知らず知らずのうちに余計なコストを支払うことになります。HTTP/3やQUICのコネクションマイグレーション（接続維持機能）が使えないため、ハンドシェイクのたびに不要なラウンドトリップが発生し、リクエストの途中でソケットが切断されるとデータの重複送信が起きてしまいます。ユーザーには、これが読み込み時のぐるぐる表示や古いデータの表示、時には二重決済として認識されますが、その原因がダッシュボード上で特定できることは滅多にありません。

また、問題はクライアント側だけではありません。現実には、驚くほど多くのバックエンドやサードパーティAPIが、HTTP/3どころかHTTP/2にすら対応していません。そのため「HTTP/3を有効にすれば解決」という単純な話ではないのです。本当に必要なのは、HTTP/1.1、HTTP/2、HTTP/3の間でスムーズにネゴシエーションを行い、相手のサーバーが実際にサポートしているプロトコルへと自然にダウングレードできるクライアントを実装することです。

本セッションでは、ライブスポーツアプリとECモール「Teez.kz」の倉庫用アプリという2つのプロダクトにおいて、Dioのインターセプターや利便性を損なうことなく、不安定なネットワークに対処させた方法をご紹介します。その秘訣は、単一のDioインスタンスを保持しつつ、プラットフォームや環境に応じて`HttpClientAdapter`を切り替えることです。Google Play開発者サービスを備えたAndroidでは、Brotli、HTTP/2、QUIC/HTTP/3を有効にしたCronet（Chromiumのネットワークエンジン）を駆動させ、iOSとmacOSでは`CupertinoClient`（`URLSession`）を使用します。さらに、Cronetが利用できない場合やデバッグ用プロキシ経由でトラフィックを通す必要がある場合は、Pure-Dart実装の`Http2Adapter`にフォールバックします。これらはすべて、`dio_compatibility_layer`上に構築されたシンプルな`makeHttpClientAdapter`ファクトリによって裏側で制御されます。

さらに、トランスポート層の最適化だけにとどまりません。リアルタイムのオッズや在庫情報の更新にはSignalRを使用していますが、ペロードサイズとクライアントでのデコード時間を削減するため、JSONからMessagePackへと移行しました。導入する価値があるかを皆さんに判断していただけるよう、独自のベンチマークハーネスから得られたビフォーアフターの数値も公開します。ライト系（書き込み）の処理については、リクエストにべき等性を持たせることで、通信の切断や自動再試行によって重複賭けや二重出庫が発生しないようにしました。

このセッションを聴けば、明日からすぐに活用できる構成を持ち帰ることができます。プラットフォームごとに最適なエンジンの選び方、Dioを再構築したりインターセプターを失うことなく実行時にアダプターを動的に切り替える方法、`Http2Adapter`に切り替えた途端に直面するgzip/Brotliレスポンスデコードの分かりにくい落とし穴とその対策、適切な接続・アイドルタイムアウトの設定、そして推測に頼らず「地下の3G回線」のような実際の悪環境で効果を正しく計測する方法をご紹介します。

**本セッションで学べること:**

1. Dart/Dioの標準IOアダプターではなぜHTTP/3、QUIC、コネクションマイグレーションが利用できず残されてしまうのか、そしてそれが実際のユーザーにどのような影響を与えるのか。

2. なぜ「HTTP/3を有効にするだけ」ではダメなのか。多くのサーバーやAPIは依然としてHTTP/1.1のままであるため、クライアント側でHTTP/1.1、HTTP/2、HTTP/3を適切にネゴシエーションしダウングレードさせる必要がある理由。

3. `dio_compatibility_layer`を活用し、単一のDioインスタンスの裏でCronet（Android）、CupertinoClient/URLSession（iOS/macOS）、Pure-DartのHTTP/2フォールバックを動作させる方法。

4. クライアントを再作成したりインターセプターを失うことなく、実行時にアダプターを動的に切り替える（プロキシ経由に変更するなど）方法。

5. `Http2Adapter`に切り替えた際に発生する、分かりにくいgzip/Brotliレスポンスデコードの問題と、その対処法。

6. JSONからMessagePackに移行してリアルタイム通信のペイロードを削減する方法（実際のデコード時間の計測結果付き）。

7. 通信切断や再試行によって意図しない副作用（二重処理など）が発生しないよう、書き込みリクエストにべき等性を持たせる方法。

8. 推測ではなく、これらの改善効果を確実に証明するためのベンチマーク手法。

**対象者およびレベル:** 中級者〜上級者向け。不安定な現実のモバイルネットワーク環境に向けて本番アプリを構築しているFlutterエンジニア、およびDioのデフォルトアダプターしか使ったことがないすべての方を対象としています。DioおよびHTTPに関する基本的な知識があることを前提としています。

**主催者向けメモ:** このセッションは、2つのプロダクトで実際にリリース・運用されているコードに基づいた、ハンズオン形式かつコード主体の発表です。CFPのガイドラインに従い、製品の宣伝は一切行いません。アプリは実社会での導入事例（アダプターの設定、コードスニペット、ベンチマーク結果など）としてのみ使用します。スライドおよびデモコードは事前に提供可能です。英語での発表に対応しており、録画・配信にも同意します。

iOS・Android 合計20万行のネイティブアプリを Flutter にリプレイスし、実装の 99% を AI が担いながらオンスケジュールでリリースしました。鍵は「AI に実装させる」ことではなく、「AI が自走できる環境を整えること」。AI の開発サイクルを 「調べる・作る・検証する」 の 3 レイヤーで設計しました。

【調べる】AI が自分で正解にたどり着く

仕様・実装ガイド・ワークフローを MCP 化した社内 Wiki、API 仕様を直接検索・取得できるMCP、Figma MCP によるデザイン確認と実装照合。AI が「人に聞かずに調べられる」状態を作りました。

【作る】効率的に任せる

CLAUDE.md でアーキテクチャ規約を宣言。作業種別ごとのカスタムスキルでワークフロー自体を自動化を実現しました。

【検証する】AI が品質を担保する

AI 自身によるコードレビュー、そして過去の不具合をAI のメモリに蓄積して同じ失敗を繰り返させない仕組みを構築しました。

概要

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 でアーキテクチャを機械的に守ることに興味がある人

概要

AIがFlutterのコードを書くようになり、1PRの差分はどんどん膨らみます。気がつくと、人間のレビューが生産量に追いつかなくなっていました。

「ならばレビューもAIに任せよう」そう進めると、今度は設計判断・ビジネスロジック・暗黙知・UX・セキュリティ方針という、AIが構造的に苦手な領域が手薄になる壁にぶつかります。

そこで私たちは、AIに置き換えるのではなく「AIと人間のレビュー分担を再設計する」道を選びました。

このLTでは、AIが弱い5領域を人間に渡すという選択と、そこに至る試行錯誤を実例で共有します。AIレビューの"次"に必ず来る問い「人間は何を見ればいいのか」への答えを、一緒に考えましょう。

想定視聴者

- AIが生成したFlutterコードのレビューに追われている方

- 「何をAIに任せ、何を人間が見るか」の線引きに悩んでいる方

- チームのレビュー分担を仕組み化したい方

ある日チームリーダー権限を存分に使って「私たちはテストコードは書きません！」宣言をしました。

そこだけを切り取ると「適当なリーダーだ」と見えてしまうかもしれませんが、もちろん自分には考えがありました。

元々我々のチームではテストコード生成をAIに任せて、一部人間がレビューするといった運用をとっていました。なぜ、一部人間がレビューするフェーズを捨てきれずにいたかというと、

- テスト品質は適切か

- テストケースの網羅性が担保されているか

- テストコードとして妥当かつ効果的なものか

を人間がやるべきという固定観念があったせいです。しかしそれは、人間が見るべきと勝手に考えていただけで、実態としてはAIに任せるための土台作りができていなかっただけでした。

そこで、暗黙知として置き去りにされていたレビュー観点をSkillとして言語化し、AIに委譲しました。結果として、スコープの決め方、境界値の選び方、「このテストは本当に壊れたら落ちるのか」という疑い方など、それぞれのエンジニアの暗黙知とされていたことをチームのナレッジに落とし込むことに成功しました。

このトークでは、276個のユニットテストと39画面分のMaestro E2Eテストを AI が生成・維持している実例をもとに、3つの核心を共有します。

**1. Skillパイプライン**

テストの「作り方」を6段階に分解し、各段階を独立したSkillにした設計。scope-layering（何をテストしないか決める）→ boundary-data-design（境界値設計）→ maestro-test-authoring（E2E作成）→ adversarial-review（敵対的レビュー）。

**2. 「直すな」の規律**

AIがテスト失敗を自動修正すると、本物のデグレ検知を潰してしまう。実行・評価フェーズでは「事実の報告に徹し、修正しない」という原則を入れた理由と効果。

**3. 敵対的レビュー**

「PASSしたテストを信用しない」— 対象機能をわざと壊しても落ちないテストを摘出する仕組み。AIにAIの成果物を疑わせるアプローチ。

「AIでテスト自動化」の先にある、テスト設計の知識をどう構造化してAIに渡すかという課題に、実プロダクトの数字と成功・失敗の両面から答えます。

機械学習や生成 AI を使った機能は「サーバーに投げる」のが定石ですが、レイテンシ・コスト・プライバシー・オフライン動作の観点から、端末上で完結させたほうがよい処理は意外と多くあります。

hacomono では、フィットネスマーケットアプリ「FitFits」（Flutter製）において、テキスト判定・画像判定・小型 LLM といった複数のオンデバイス ML/AIに取り組んできました。本セッションでは、技術検証にとどめず実プロダクトに組み込むまでの過程で得られた設計知見をお話しします。

Firebase AI Logic や flutter_ai_toolkit の登場で、バックエンドを介さずクライアントから直接 LLM を呼ぶ AI 機能を、Flutter エンジニアが自分たちの手で作ってリリースできるようになりました。サーバーサイドで LLM を呼ぶ構成も含めれば、LLM を組み込んだ機能を持つアプリケーションは、すでに珍しくないはずです。しかし、その出力は非決定的で、私たちのテスト文化 — unit test、widget test、integration test など — の前提を裏切ります。プロンプトを 1 行変えた PR に、あなたは何を根拠に approve を出しますか？モデルの世代交代が来たとき、何を確認してからアップデートしますか？

このセッションでは、Flutter エンジニアとして長く活動し、現在は LLM Ops（LLM を組み込んだ機能の評価・運用）の実務に主に取り組んでいる登壇者が、その現場で使われている評価手法（ルーブリック評価、LLM-as-a-Judge、pairwise 比較）を Flutter のテスト文化の語彙に翻訳し、「評価 (evaluation)」をテストピラミッドの新しい層として組み込む方法を紹介します。

具体的には、画像からの構造化出力やチャットのような、LLM を組み込んだ典型的な機能を題材に、Flutter のテストの仕組みと地続きの形で評価を記述・実行し、プロンプトやモデルの変更による品質の劣化をリリース前に検知するアプローチを、動くコードとともに実演します。終章では、GenUI / A2UI が生成する UI を flutter_test で検証する実験も紹介します。

LLM を組み込んだ機能を持つアプリケーションは、これからますます増えていきます。すでに取り組んでいる方には明日から試せる評価の手法を、これからの方には非決定的な機能と付き合うための考え方を、それぞれ持ち帰っていただけます。

優れたFlutterのユーザー体験（UX）を作るというのは、単に見た目の美しいインターフェースを整えたり、多言語化（ローカライズ）対応をしたりすることだけではありません。異なる言語や文化、環境の中で、実際のユーザーがアプリとどのように関わっているのかを深く理解することが本質です。

50か国以上で自身のFlutterアプリの改善を積み重ねてきた中で、開発段階では決して浮かび上がらなかったさまざまなUX課題に直面しました。音声認識の操作フローでユーザーが戸惑ったり、オンボーディングがスキップされてしまったり、右開き言語（RTL）環境でレイアウトが崩れたり、ある地域では自然に受け入れられる操作パターンが、別の地域ではストレスを生んでしまったりといった問題です。

本セッションでは、そうした実体験から得られた実践的なUX改善策と、それを支えるFlutterの実装テクニックをご紹介します。アダプティブ・レイアウト、ローカライズのアーキテクチャ、RTLを考慮したウィジェット設計、レスポンシブUI、オンボーディング戦略、そして継続的なUX改善のための具体的なアプローチについて詳しく見ていきます。さらに、生成AIを活用してローカライズ、UX評価、そして反復的な改善プロセスをどのように加速できるかについても実演します。

世界中のユーザーにとって直感的で心地よく感じられるアプリを開発するために、すぐに活用できる実用的なFlutterの設計パターンとUX戦略を持ち帰っていただけます。