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

生成AIによって、Flutterアプリのコードを書く方法は大きく変わりました。
一方で、AIによるコードレビューやテストだけで、アプリの品質を守り切ることはできません。

AI で PR を出せる人が増えた。
では、アプリの品質を誰が・どこで守るのか？

日本トレカセンターでは、CodeRabbitによるコードレビュー、Unit / Widget Test、E2E、QA、そしてDatadog RUMによるProductionの観測まで、**異なる役割を持つ複数の「Quality Layers」**を重ねてFlutterアプリの品質を支えています。

本セッションでは、Riverpod v3への移行後にProductionで発生したエラーなど、実際のFlutterアプリで経験した問題を題材に、「なぜその問題を手前のレイヤーでは防げなかったのか」「次はどのレイヤーで検知・防止できるようにするのか」を追いながら、私たちの品質設計を紹介します。

さらに、Productionで得られたエラーやユーザー体験の情報をAIで調査し、Flutterの実装・レビュー・テストへ戻していくFeedback Loopについても扱います。

AI時代のFlutter開発において、一つのツールやAIに品質を任せるのではなく、Review・Test・E2E・QA・ProductionそれぞれのQuality Layerをどう設計し、どうつなげるのか。 実際の失敗と改善から考えます。

Transcript

1. Engineering FlutterKaigi 2026 AI時代の Flutter品質設計 アプリ品質を守るQuality Layers @omatty198（尾松） 日本トレカセンター / プロダクト部 モバイル リードエンジニア JTCC Engineering zenn.dev/omatty198 github.com/omatty198 x.com/omatty198 01
2. Engineering 自己紹介 日本トレカセンターで プロダクト開発に取り組んでいます AIで小さなチームを加速させる 組織づくりに関心があります @omatty198（尾松） 日本トレカセンター プロダクト部 / モバイル リードエンジニア JTCC Engineering 経歴 イグニス・MIXI・Popshoot 好き 個人開発・データ分析 GTD・自動化 出身 兵庫県丹波市 趣味 ゲーム（APEX / スプラ3）・サウナ 02
3. Engineering JTCCホールの「JTCC」って？ Japan Trading Card Center 日本トレカセンター トレーディングカードの オンラインオリパサービス ポイント購入 → オリパを引く 当選後の選択：発送 または 再ガチャ JTCC Engineering 03
4. Engineering 日本トレカセンター 創業 年間 3年 x00億円 2023年4月設立 2026年、3カ国・地域へ進出 台湾 香港 アメリカ 2026年5月 提供開始 2026年7月 提供開始 2026年10月 提供開始 日本を含め、4カ国・地域で展開 JTCC Engineering 04
5. Engineering 台湾のリアルイベントにも出展 CARDPASS TAIWAN 2026 トップスポンサーとして 出展しています 台北 / 2026年10月17‒18日 JTCC Engineering 05
6. Engineering ブースには長い行列 ブースに並ぶ来場者 JTCC Engineering ブースでの撮影風景 06
7. Engineering Team体制 PdM 5名 フルスタックエンジニア 4名 モバイルエンジニア（Flutter） 2名 ＋ 業務委託3名 QAエンジニア 1名 データアナリスト 1名 デザイナー 2名 人が全然足りていません JTCC Engineering 07
8. Engineering 海外展開・リアルイベント・日々の開発 人が全然足りない カヲスな状況 AI で PR を出せる人が増えた。では品質を、誰が・どこで守るのか？ JTCC Engineering 08
9. Engineering 今日いちばん伝えたいこと 丁寧に責務を分けて 改善を続ける 細部までこだわって、 ユーザーに価値を届ける JTCC Engineering 09
10. Engineering Agenda 1. 品質を守る設計 11‒18枚目 Quality Layers・AI開発の全体像 2. 本番観測とコードレビュー 19‒27枚目 本番観測とレビューから、設計・コードへ 3. 画面検証とセキュリティ 28‒35枚目 状態別の画像と、確認した根拠を共有 4. ユーザーへの価値 36‒39枚目 体験への工夫と、僕らが大切にしたいこと JTCC Engineering 10
11. Engineering Quality Layers 学びを活かす 本番コード・アーキテクチャ コードレビュー (Code Review) 自動テスト （Unit・Component・Widget / Integration / E2E Test） 手動テスト （ストーリー・リグレッションテスト・探索的テスト） 本番環境の観測 （Production Observation） Security 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 11
12. Engineering コードレビューからコードへ 学びを活かす 本番コード・アーキテクチャ コードレビュー (Code Review) 自動テスト （Unit・Component・Widget / Integration / E2E Test） 手動テスト （ストーリー・リグレッションテスト・探索的テスト） 本番環境の観測 （Production Observation） Security 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 12
13. Engineering 自動テストからコードとコードレビューへ 学びを活かす 本番コード・アーキテクチャ コードレビュー (Code Review) 自動テスト （Unit・Component・Widget / Integration / E2E Test） 手動テスト （ストーリー・リグレッションテスト・探索的テスト） 本番環境の観測 （Production Observation） Security 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 13
14. Engineering 手動テストから上位の層へ 学びを活かす 本番コード・アーキテクチャ コードレビュー (Code Review) 自動テスト （Unit・Component・Widget / Integration / E2E Test） 手動テスト （ストーリー・リグレッションテスト・探索的テスト） 本番環境の観測 （Production Observation） Security 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 14
15. Engineering 本番観測から上位の層へ 学びを活かす 本番コード・アーキテクチャ コードレビュー (Code Review) 自動テスト （Unit・Component・Widget / Integration / E2E Test） 手動テスト （ストーリー・リグレッションテスト・探索的テスト） 本番環境の観測 （Production Observation） Security 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 15
16. Engineering Securityからコードへ 学びを活かす 本番コード・アーキテクチャ コードレビュー (Code Review) 自動テスト （Unit・Component・Widget / Integration / E2E Test） 手動テスト （ストーリー・リグレッションテスト・探索的テスト） 本番環境の観測 （Production Observation） Security 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 16
17. Engineering 開発で使っているAIツール Cursor Devin 実装 タスク実行・PR Claude Code Repository 実装・調査 コード・テスト Codex 実装・検証 OpenCode 共通手順を利用 1. 品質を守る設計 Rules / Skills PR作成時のスキル例 /app-kanten-coverage QAの観点確認 /app-pr-screenshots Golden Test対応 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ CodeRabbit コードレビュー Datadog 本番の観測・調査 4. ユーザーへの価値 17
18. Engineering RulesとSkillsを共有する Cursor Devin 実装 タスク実行・PR Claude Code Repository 実装・調査 コード・テスト Codex 実装・検証 OpenCode 共通手順を利用 1. 品質を守る設計 Rules / Skills PR作成時のスキル例 /app-kanten-coverage QAの観点確認 /app-pr-screenshots Golden Test対応 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ CodeRabbit コードレビュー Datadog 本番の観測・調査 4. ユーザーへの価値 18
19. Engineering ここからは、 6つの改善事例 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 19
20. Engineering 事例1 Riverpod 3 の Ref disposed 本番コード・Architecture 反映 本番観測 Datadog で Ref disposed Error が頻発。 閉じた画面の state を更新していた Code Review 自動テスト 反映 Architecture 画面と処理の寿命を、設計で分ける 手動テスト 本番環境の観測 発見 Security（全層にかかる観点） 1. 品質を守る設計 発見 2. 本番観測とコードレビュー クリティカルな問題はなかったが、Riverpod 3 の移行ガイドへの 追従漏れがあった。待機中に閉じる条件の自動テストは今後 3. 画面検証とセキュリティ 4. ユーザーへの価値 20
21. Engineering 待機中に画面を閉じるケースを確かめる 画面を閉じた後、その更新は必要か？ 01 取得を開始 結果を待機させる 02 03 → 画面を閉じる → 取得が完了 待っている間に離れる 破棄後の動作を見る 設計・レビュー：画面と処理の寿命を確認 自動・手動テスト：例外と、必要な処理の完了を確認 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 21
22. Engineering 画面の寿命と、処理の寿命を分ける 変更前 変更後 Future<void> reload() async { Future<void> reload() async { final items = await repo.fetch(); final items = await repo.fetch(); // 待機中に画面が閉じられても更新する if (!ref.mounted) return; state = AsyncData(items); state = AsyncData(items); } } 表示のための更新 → 画面がなければ捨てる（ref.mounted） 画面がなくても必要な処理 → 画面より寿命の長いproviderにする ※ 説明用の擬似コード 1. 仕組み 2. 本番観測から 3. レビュー・テスト 4. Securityから 5. まとめ 16
23. Engineering 事例2 サムネイルの Memory Warning 本番コード・Architecture 反映 Code Review 自動テスト 手動テスト 反映 本番観測 発見 Security（全層にかかる観点） 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 22
24. Engineering 再現条件をそろえて、原因を調べる この経験から、確認したい観点 どの条件か 端末・ビルド・表示する画像をそろえる どの操作か 一覧をスクロールし、詳細と往復する 何が変わるか エラーとメモリの変化を対応させる 原因や改善効果は、計測してから判断する 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 23
25. Engineering サムネイルの解像度とアップロード容量 コード 運用 背景 背景 サムネイルの解像度の 定義が雑だった GIFを多用していた 対策 対策 各端末が許容できる サムネイルの解像度を定義する アップロードするファイルの 容量上限（MB）を定義する 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 24
26. Engineering 事例3 判断が集まった変数定義 本番コード・Architecture 反映 Code Review 発見 発見 Code Review サーバーサイドエンジニアが AI で書いた PR 自動テスト で、変数定義に判断が集中 反映 Architecture 判断ごとに、名前の付いた Provider へ分ける 手動テスト 本番観測 Security（全層にかかる観点） 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 25
27. Engineering 変数定義に、判断が集まっていた 変更前：build()内の一部を抽象化した擬似コード final rules = !featureEnabled || contextKey == null ? const AsyncData<Rule?>(null) : ref.watch(displayRulesProvider(contextKey)); final visibleItems = !useRules ? items : rules.when( data: (rule) => rule == null || !rule.isEnabled ? items : items.where((item) => item.isVisible && (rule.kinds.isEmpty || rule.kinds.contains(item.kind)) && (!rule.membersOnly || isMember) && (query.isEmpty || item.name.contains(query))).toList(), loading: () => keepPrevious ? previousItems : <Item>[], error: (_, _) => fallbackEnabled ? items : <Item>[], ); レビューで「これ複雑すぎる」と指摘 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 26
28. Engineering 表示する値と、判断する責務を分ける 変更後（擬似コード）：画面は名前の付いたProviderを購読 final rules = ref.watch(displayRulesProvider(contextKey)); final visibleItems = ref.watch(visibleItemsProvider(query)); 適用判定 利用条件やフラグの評価をまとめる 候補の抽出 取得状態と、絞り込みの判断をまとめる Code Review → Architecture：責務を分け直す 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 27
29. Engineering 事例4 状態別の Golden 画像 本番コード・Architecture 本番コード・Architecture 反映 発見 自動テスト Golden Test で状態別の画面を画像化 Code Review Code Review 自動テスト 発見 反映 Code Review 画像を PR に貼り、意図と違う表示を直す 手動テスト 本番観測 Security（全層にかかる観点） 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 28
30. Engineering Golden Testとは？ 例：ストア起動中の表示 用意した状態を描画して、 基準画像と比べる 差分が出たら、 意図した変更かをレビューする 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 29
31. Engineering PRで、変更前後の画像を共有する Before After ストア 起動中 無効化 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 30
32. Engineering 言語を変えて、同じ状態を確かめる 英語（After） 1. 品質を守る設計 2. 本番観測とコードレビュー 繁体字（After） 3. 画面検証とセキュリティ 4. ユーザーへの価値 31
33. Engineering 画像と操作、それぞれで確かめる Unit / Widget ロジックとUIの振る舞い 結合テスト / E2E 複数の層の連携と、一連の操作 Golden Test 状態ごとの見た目 手動テスト 操作と体験 画像で分かることと、操作で確かめることを分ける 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 32
34. Engineering 事例5 Securityの確認をコードへ 学びを活かす 本番コード・アーキテクチャ コードレビュー (Code Review) 自動テスト （Unit・Component・Widget / Integration / E2E Test） 手動テスト （ストーリー・リグレッションテスト・探索的テスト） 本番環境の観測 （Production Observation） Security 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 33
35. Engineering 事例6 SDK・ライブラリ更新 Architecture 本番コード・Architecture 反映 発見 Security 10/23、Dart / Flutter の TLS 脆弱性（High）が公開 Code Review 自動テスト 反映 手動テスト 反映 反映 自動テスト・手動テスト patch はテストを通して自動マージ、 重要な SDK は固定して QA 本番観測 Security（全層にかかる観点） 1. 品質を守る設計 2. 本番観測とコードレビュー 発見 3. 画面検証とセキュリティ 4. ユーザーへの価値 34
36. Engineering 6つの事例を、Quality Layers で振り返る Architecture 事例1 Ref disposed 事例2 メモリ 事例3 変数定義 事例4 Golden 画像 事例5 機密情報 事例6 SDK 更新 反映 反映 反映 反映 反映 反映 Code Review 発見 自動テスト 発見 手動テスト 本番観測 反映 反映 発見 反映 発見 Security 発見 発見 どの層も、見つける場所であり、戻す場所でもある 1. 仕組み 2. 本番観測から 3. レビュー・テスト 4. Securityから 5. まとめ 33
37. Engineering Quality Layersで振り返る 学びを活かす 本番コード・アーキテクチャ 設計・コードを見直す コードレビュー (Code Review) 事例3・4 自動テスト 状態・条件を追加 （Unit・Component・Widget / Integration / E2E Test） 手動テスト 操作・環境を見直す （ストーリー・リグレッションテスト・探索的テスト） 本番環境の観測 事例1・2 （Production Observation） Security 1. 品質を守る設計 事例5・6 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 35
38. Engineering ユーザーに向いた工夫 品質改善を、体験を考える時間につなげたい 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 36
39. Engineering PRを出す、その前後に 設計への理解 レビュアーへの敬意 本番からの学び 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 37
40. Engineering 丁寧に責務を分けて 改善を続ける 細部までこだわって、 ユーザーに価値を届ける 日本トレカセンター / プロダクト部 モバイル リードエンジニア @omatty198（尾松） 1. 品質を守る設計 2. 本番観測とコードレビュー 3. 画面検証とセキュリティ 4. ユーザーへの価値 38
41. Engineering ご清聴 ありがとうございました 日本トレカセンター / プロダクト部 モバイル リードエンジニア @omatty198（尾松） 1. 品質を守る設計 2. 実際の改善事例 3. 見える検証と改善 4. ユーザーへの価値 39
42. Engineering 参考文献（1/3） セキュア・バイ・デザイン 安全なソフトウェア設計 https://book.mynavi.jp/ec/products/detail/id=124056 リーダブルコード https://www.oreilly.co.jp/books/9784873115658/ Flutter公式：テストの種類と役割 https://docs.flutter.dev/testing/overview Riverpod公式：3.0への移行 https://riverpod.dev/docs/3.0̲migration OWASP MASVS：依存ライブラリの既知の脆弱性 https://mas.owasp.org/MASVS/controls/MASVS-CODE-3/ JTCC Engineering 40
43. Engineering 参考文献（2/3） Opening Keynote -経営者からみたエンジニアキャリアYouTube · 17:59〜 youtube.com/watch?v=wFS5midxUg0&t=1079s AIのお陰で最近辛かった個人開発がまた楽しくなった TAKUYA · 丁寧に手を抜く blog.craftz.dog/002d264b8f43/ 「ここにいたんだ」をくれてありがとう。 えりん · note JTCC Engineering note.com/eriko̲2525/n/n649bd12991cc 41
44. Engineering 参考文献（3/3） 私が億万長者になった日 Ray Yamazaki · Medium medium.com/@rayyama/…-4614d3f4a255 the senior engineer death spiral Sunil Pai sunilpai.dev/posts/the-senior-engineer-death-spiral/ 33歳モバイルエンジニア道 nakajijapan · iOSDC Japan 2016 JTCC Engineering youtube.com/watch?v=JzdWU9-P9zA 42