Flutter初心者が生成AIで大規模アプリ開発をキャッチアップした工夫 〜元ネイティブエンジニアが実践した、技術転換の高速道路〜 / Flutter with LLM: A Former Native Engineer's Fast Track to Large-Scale Apps

登壇者名：酒井文也
登壇したイベントタイトル：AI NativeなFlutter開発の現在地〜業務導入の壁と、デザイン・テストへの応用〜
登壇したイベントのURL：https://upsider.connpass.com/event/387477/

Transcript

1. Flutter初心者が生成AIで大規模アプリ開発をキャッチアップした工夫 株式会社ビットキー 酒井文也 2026/05/18 元ネイティブエンジニアが実践した、技術転換の高速道路
2. 2 酒井 文也 Sakai Fumiya @fumiyasac 2016.09 2019.03 2023.01 30歳の誕生日からiOSアプリ開発の勉強をスタート この時はまだWebエンジニアをしていました ソーシャルゲームやWebサービスの開発に従事 仕事→iOSアプリ開発の勉強 or 勉強会参加の毎日 数社でiOSアプリ開発を経験の後に独立 iOSアプリ開発を軸に据えて様々な開発現場を経験 2021年からはAndroidアプリ開発にも挑戦 国内最大級のハンドメイドマーケットアプリの開発に シニアエンジニアとして従事 iOS＆Androidアプリ開発を中心に幅広く新機能開発や 既存機能改善に携わっていました Now 2026年2月にビットキーに入社 homehub開発部 homehub Mobileに所属 現在は「homehub」のモバイルアプリ開発を担当 Flutter歴 = 社歴 自己紹介 ※長いのでモバイルアプリエンジニアになってからを抜粋して紹介します
3. つなげよう。 人は、もっと自由になれる。 Bitkey Recruiting Book © Bitkey inc All rights reserved. Mission・Vision
4. 現在、事業展開している２つのプロダクト 現在は「暮らし」「働く」という２つの事業領域において、 hubシリーズ（プロダクト群）をリリースし、 様々なステークホルダーに対して、プラットフォーム・プロダクト・サービスを展開しています。 フレキシブル オフィス オフィス テナント テンポラリーユー ス ビル(オーナー) ワーカー 不動産管理会社 マンション オーナー 管理組合 デベロッパー 居住者 暮らしサービス デリバリー会社 対象カスタマー/ユーザー
5. 「暮らし」 homehubは「暮らし」に関わる様々な体験を実現する。 その中心にあるのがスマートロック
6. 今日お話しすること 6 本セッションでは、未経験の技術スタック＋大規模コードベースという環境下で、いかに生成 AIを「伴走者」として活用し、キャッチアップの速度を 上げたかについてお話しします。 1. 技術転換の背景と直面した壁 - 「わからない」を3段階で整理する 2. 生成AIの具体的な活用方法 - GitHub Copilot・Notion MCPの実践的な使い方 3. プロジェクト理解を深める取り組み - AIを活用したドキュメント作成 4. AIと自分の境界線 - 鵜呑みにしない、疑う、検証する 5. 業務知識・仕様理解の重要性 - AIだけでは埋まらないギャップ 6. 「怖くない」と思えるまでの道のり - 業務面・学習面での自主的な取り組み
7. 7 技術転換の背景と直面した壁 「何がわからないのか」を切り分けることから始めた
8. 入社後に直面した挑戦 8 ビットキーへの入社後、以下のような環境に飛び込むことになりました。 1. 未経験の技術スタック - Flutter / Dart を実務で本格的に使うのは初めて 2. 大規模なコードベース - homehubモバイルアプリは物理デバイス連携を含む複雑な構成 3. 独自のアーキテクチャ - Riverpodによる状態管理、ネイティブ連携など、プロジェクト固有の設計思想 4. 業務ドメインの理解 - IoT・スマートロック等、ハードウェアと密接に関わるドメイン知識 個人的なキャッチアップは個別に実践していたが、やはりそれだけでは「壁」を感じる場面も多かった。 そこで重要だったのは、 「何がどのくらいわからない」 のかを切り分けること。 技術転換の背景と直面した壁
9. 「わからない」の3つのレベル キャッチアップの過程で感じた「壁」を整理すると、以下の 3つに分類できました。 • Lv.1: やりたい事はわかるが、 Flutter/Dartでの実現方法がわからない ◦ 例: 「この画面遷移をFlutterではどう書くの？」「Dartでのnull安全はどう扱う？」 ◦ 対処: 素直にやりたい事を AIに聞けば答えが返ってくるケースが多い • Lv.2: Flutter/Dartでできそうな事はわかるが、要件での実現方法がわからない ◦ 例: 「Widgetの組み方はわかるが、この仕様をどう落とし込む？」 ◦ 対処: 要件とFlutterの知識を組み合わせる必要があり、 AIへの質問にも工夫が要る • Lv.3: 何をどうすれば良いかが正直わからない ◦ 例: 「そもそもどこから手を付ければ …」 ◦ 対処: 「最初の一手」が出ない。ここが AI活用の真価が問われる場面 技術転換の背景と直面した壁 9
10. Lv.3への対処:「最初の一手」をAIに任せる Lv.1・Lv.2は「素直にやりたい事を聞けば良い」が、 Lv.3はそもそも質問の仕方すらわからない状態。 • 「最初の一手を AIに任せてみる」というアプローチ ◦ 完璧な答えを求めるのではなく、思考の起点として AIを活用する ◦ AIの回答から拡張して見える景色が広がる ことが多かった ◦ 「何を聞けばいいかわからない」状態でも、まず現状を AIに伝えてみる 入社後に直面した挑戦 10 「このファイル群の中で、〇〇の処理に関連しそうな箇所を教えてください。 まず全体像を把握したいです。」 具体的なプロンプト例 最初の一手が出ると、そこから Lv.2 → Lv.1へと自然にレベルが下がっていくことが多い。
11. 11 生成AIの具体的な活用方法 GitHub Copilot と Notion MCP を「伴走者」として使いこなす
12. 利用しているAIツールと開発フロー 生成AIの具体的な活用方法 12 ツール 主な用途 活用場面 GitHub Copilot コード補完・修正提案・コードリーディング支援 実装・レビュー・調査 Notion MCP 要件に合致する箇所の特定・ドキュメント連携 要件確認・仕様調査 • メインで活用しているツール • 開発フローの中でのAI活用ポイント 要件確認 該当箇所の特定 修正方針の検討 実装 レビュー Notion MCP Copilot & Notion MCP Copilot Copilot Copilot • Notion MCPと連携して要件に合致する箇所を早めに特定 し、開発効率を上げる • 開発箇所の特定と修正対応をセットで進めるのが最近の基本スタイル • 既存コードの振る舞いで重要そうな部分にはUnitTestの作成を依頼 することもある
13. QA評価戻り（バグ修正）でのAI活用 生成AIの具体的な活用方法 13 QA評価からのフィードバック対応（不具合調査）では、以下のようなアプローチで効率よくバグの原因を特定しています。 • プロンプト設計のポイント ログ情報をプロンプトに含める ことが鍵。再現手順・ログ・関連コードをセットで渡す。 プロンプト構成イメージ [エラーログ] [関連コード] 1. 〇〇画面を開く 2. △△ボタンをタップ → エラー発生 → 関連コード・エラーログ・再現手順を元に、原因箇所を推定してください。 • なぜ効果的か • AIがコードとログの両方を横断的に分析 できる • 人間だと見落としがちなスタックトレースの深い階層 まで追跡してくれる • 原因の候補を複数提示してくれるため、調査の方向性を絞りやすい [再現手順] Exception: xxx at yyy.dart:123 … （該当箇所のコードを貼付）
14. 14 プロジェクト理解を深めるための取り組み 大規模コードベースを「地図化」する
15. プロジェクト理解で押さえた2つの重要テーマ 大規模コードベースを闇雲に読むのではなく、 個人的に優先度の高いテーマを 2つ定め、そこから理解を広げていく戦略を取りました。 • テーマ1: ネイティブ処理と連携する箇所・処理の概要 ◦ homehubモバイルアプリはアプリの性格上、 物理デバイスとの連携処理 が重要なポイント ◦ ネイティブ（iOS/Android）が関係する処理の概要を 先に把握 しておくことで日常的な改修やコードリーディングの土台になる ◦ 元ネイティブエンジニアとしての知見を活かせる領域でもあり、 理解の足がかり にしやすい • テーマ2: Riverpodを利用した状態管理処理の概要 ◦ Riverpodはプロジェクトによって運用方法の違いが出やすい 部分 ◦ 基本的な書き方を踏まえた上で、 プロジェクト固有の使われ方 を把握する必要がある ◦ これを押さえておくと、新しい画面や機能のコードを読む際の理解がスムーズに進む プロジェクト理解を深めるための取り組み 15
16. AIを活用した簡易ドキュメント作成 プロジェクト理解を深めるための取り組み 16 テーマに沿った理解を深めるため、 AIを利用してプロジェクト固有のドキュメント を作成しています。 • 作成済 or 作成中ドキュメント • ドキュメント作成の効果 • コードを読むだけでは得にくい全体像の「見える化」 ができる • 自分だけでなく、チームメンバーの参考資料 にもなり得る • 作成過程そのものが深い理解に繋がる （AIの出力を精査・編集することで学びが生まれる） ドキュメント名 内容・目的 Native機能利用箇所まとめ （作成済） homehubアプリ & 関連アプリでのネイティブ機能利用箇所を網羅的に整理 Riverpod入門ガイド （作成済） プロジェクトのコードベースに即した Riverpodの使い方ガイド Firestore/Backend連携まとめ （作成中） FirestoreやBackend（サーバーサイド）との連携部分を整理 物理デバイス関連処理まとめ （作成中） 物理デバイスに関連する処理の詳細を整理
17. 17 AIに任せる部分と自分で考える部分の境界 「鵜呑みにしない」ための具体的な判断基準
18. AIの答えを「疑う」— 確度を見極める2つの判断基準 AIに任せる部分と自分で考える部分の境界 18 AIの回答を鵜呑みにせず、 検証の基準を明確に持つ ことが重要だと感じています。 • 判断基準1: 複数回試行による確度の検証 • 判断基準2: コメント出力による検証 • 出力されたコメントが判断材料になることが多い • コメントと実際の処理に大きな乖離 がある場合 → 「暫定的な対応として実装された可能性が高い処理」と判断 • 乖離がある場合はその修正は採用しない という結論に至る パターン 判断 3〜5回の試行で同じ箇所 にCopilotが修正を加える 確度が高い → 採用を検討 試行の度にCopilotの修正にブレが生じる 確度が低い → 鵜呑みにしない • 同じ質問を複数回投げて、回答の一貫性を確認する • ブレが大きい場合は「果たしてその通りか？」と立ち止まる 「修正箇所に関するコメントを書くように」とAIに指示する
19. コメント検証テクニック — 具体的なイメージ AIに任せる部分と自分で考える部分の境界 19 • なぜこの方法が有効か • AIが「理解して」修正しているのか、「パターンマッチで」修正しているのかを見分けられる • コメントの品質 ≒ AIがその文脈をどの程度理解できているかの指標になる • AIに出力を依頼するプロンプト例 「この修正箇所について、なぜこの変更が必要なのか、 処理の意図を含めたコメントを書いてください。」 具体的なプロンプト例 • 検証のポイント 状態 コメントの内容 判断 😆良好 処理の意図が明確で、コードの振る舞いと一致している 採用候補として検討 🧐要注意 コメントが曖昧、または処理と微妙にズレている 追加調査が必要 😨危険 コメントと実際の処理が大きく乖離している 採用しない
20. 有識者への確認 — AIだけで完結しない判断 AIに任せる部分と自分で考える部分の境界 20 AIによる検証だけでなく、 人への確認 も重要な判断材料です。 • なぜ有識者への確認が必要か ◦ 規模の大きいプロジェクトでは、 コードを追うだけでは判断がつきにくい場面 がある ◦ コードに現れない経緯や成り立ち（歴史的背景） が判断に必要な場合もある ◦ AIはコードの「現在の姿」は読めるが、「なぜこうなったか」の文脈は把握しきれない • 個人的に丁度良い温度感 ◦ AIの出力 = 叩き台・候補 として扱う ◦ 最終的な採否は自分の判断 + 有識者の知見 で決める ◦ 特にアーキテクチャに関わる変更や、業務ロジックに深く関わる部分は慎重に AIによる修正はあくまで判断材料である
21. 21 業務知識と仕様理解の重要性 AIを活用する前提条件としての理解
22. 業務知識がないと「場当たり感」が出てしまう 業務知識と仕様理解の重要性 22 AIに任せる際にも「業務知識」への理解がないと、正解に辿り着くまでに時間がかかる ことが、これまでの経験でも多くありました。 • 直面した課題 • 小さな修正を任せるにしても、業務知識が不足していると修正に「場当たり感」 が出てしまう • AIを活用しているにもかかわらず、的を射た修正ができず戸惑う場面 が多かった • 特に入社当初は、AIの出力が正しいかどうかを業務観点から判断できない ことが問題だった • 業務知識の不足が引き起こす悪循環 業務知識が不足 AIへの質問が曖昧になる 修正が「場当たり的」になる AIの回答も的外れになる 手戻りが発生 時間がかかる 解決策として、ステップを踏んだ AI活用のアプローチを取り入れることが有効。 参考記事: https://zenn.dev/fumiyasac/articles/ba2b0a19f563f0
23. ステップを踏んだAI活用のアプローチ 業務知識と仕様理解の重要性 23 業務知識の理解度に応じた 段階的な AI活用で、「場当たり感」を解消する。 • 4つのステップ • ポイント • Step 1を飛ばしてStep 3に行くと「場当たり感」が出る • Step 1〜2で十分な文脈を持った状態 でAIに質問することで、AIの出力精度も上がる • Step 4の検証結果をStep 1に戻してフィードバックループを回す Step 内容 主なインプット先 Step 1 業務仕様を理解する ドキュメント・有識者・ Notion Step 2 技術的な実現方法を理解する コードリーディング・AI Step 3 AIを活用して実装に落とし込む Copilot・MCP Step 4 実機確認・QA評価で検証する 実機・QAフィードバック
24. 仕様理解と基本理解がやっぱり一番大切 業務知識と仕様理解の重要性 24 AIによってキャッチアップ時間の短縮 や開発の高速化 を実現できた一方で、仕様理解や基本理解に関しては これまで以上に目を向ける必要が あると感じています。 • 特に「複雑な仕様」の機能開発において ◦ 仕様理解や基本理解が 曖昧なまま 進めてしまうと、意図しない状態 を生み出す原因になる ◦ AIは与えられたコンテキストに基づいて回答するため、 前提が間違っていれば、出力も間違う ◦ 仕様の「なぜ」を理解せずに「何を」だけ AIに聞いても、本質的な解決にならない • 心がけていること ◦ 「腹落ち」していない状態で AIの出力を採用すると、後から大きな手戻りになりやすい ◦ 逆に「腹落ち」した状態であれば、 AIの出力を正確に評価・取捨選択 できる 常に仕様理解や基本理解に立ち返りながら、「理解が腹落ちした状態」でAIと向き合っていくのが前提
25. 25 FlutterとAIの相性、そして手に馴染む開発へ 業務と技術の「つなぎ目」を AIで補完する
26. FlutterとAIの相性についての所感 FlutterとAIの相性、そして手に馴染む開発へ 26 個人的にはとても手に馴染み、相性はとても良い と感じています。 • 特に効果を感じる場面 • 「つなぎ目」をAIで補完するイメージ • 業務要件を理解した上で、その要件をFlutterでどう実現するかの橋渡しをAIが担う • 実務では実機確認や QA評価で仕様を満たすコードにするのは勿論 • 有識者の知見や見解 とも照らし合わせながら進める 場面 AIの効果 QA評価戻り（フィードバック対応） ログ+コードをセットで渡すことで素早く原因特定。修正 PRまでの時間を短縮。 細かな調整対応 プロンプト設計次第で、 UIの微調整を素早くPRの形にできる。 コードリーディング 既存コードの意図や構造を質問形式で把握できる。 UnitTest作成 重要な振る舞いに対するテストの雛形を素早く作成できる。 業務 AIを用いて補完しながら実装を進めるイメージ に近い使い方が割合として多い ✖ 技術
27. バックエンド理解への応用 — 伴走者としてのAI FlutterとAIの相性、そして手に馴染む開発へ 27 Flutter側の開発だけでなく、 Flutterアプリに関連するBackend処理の理解 にもAIが大いに役立っています。 • AIが「伴走者」として活躍した場面 • AIを活用した認知負荷の軽減 • 経験のない言語で書かれたコード を読む際に、AIは優秀な伴走相手になってくれた ◦ 例: Backend側のGo/Python等のコードを読み解く必要があった場面 • 複雑な仕様を読み解く 際に、AIにコードの振る舞いを要約・解説してもらう • API連携部分の理解をAIに補助してもらい、Flutter側の実装方針を決定 する AIの活用方法 効果 「見える化」 複雑な処理フローを図解・要約してもらい、認知負荷を下げる 「最初の一手」の候補出し 何から手を付ければよいかのハードルを下げる 「翻訳者」として 不慣れな言語・フレームワークのコードを自分の理解に変換する 上手く活用すると開発のハードルは確実に下がる
28. ただし、前提は変わらない FlutterとAIの相性、そして手に馴染む開発へ 28 AIの活用によってキャッチアップや開発のスピードは確実に上がった。しかし、その一方で忘れてはいけないこと。 業務理解や技術そのものに関する理解は、AIのサジェスチョンを正しく判断する上で、今まで以上に求められる。 • AIの限界を理解した上での活用 ◦ AIはコンテキストを与えれば素早く回答できるが、コンテキストそのものは人間が持つ必要がある ◦ 「AIが出した答えが正しいかどうか」を判断できるのは、業務・技術の理解がある人間だけ ◦ AIの進化に伴い、人間側に求められるリテラシーも同時に上がっている
29. 29 「怖くない」と思える所まで持っていくために 自主的に取り組んでいる業務面・学習面の工夫
30. 業務面での取り組み 「怖くない」と思える所まで持っていくために 30 実務で「怖くない」と思えるために、自主的に取り組んでいることを紹介します。 • 細かな調整・修正対応を繰り返す • 小さなタスクを着実にこなすことで、コードベースの理解範囲を広げていく • 一つひとつのタスクから得られる知識や課題に関する知見を積み上げていく • 基本処理やガイドラインを理解する • Flutterプロジェクトで利用されている基本処理の作法 を身につける • チームのコーディングガイドラインを理解し、「郷に入っては郷に従え」 を実践 • 基本が分かると、応用的な実装でも見通しが立ちやすくなる • プロジェクトコードベースのドキュメントを作成・編集する • AIを活用してドキュメントを生成し、それを自分で精査・編集 する • 作成プロセス自体が深い理解につながる & チームへのアウトプットにもなり、貢献実感が得られる
31. 学習面での取り組み 「怖くない」と思える所まで持っていくために 31 業務とは別に、自主的な学習としても工夫を凝らしています。 • 簡易サンプル作成 + 解説ノートのサイクル • Flutterを利用した画面が3〜5程度の簡易的なサンプル を生成AIで作成する • そのコードを自分で読み込んで解説ノートを作る • 理解した内容を実務のコードリーディングに活かす • なぜ「コードを読む」ことを重視するのか • 実務のコードを理解するには、まず「コードを読む力」 が必要 • 生成AIでサンプルを作るだけでなく、そのコードを自分で読み解くプロセス が重要 • コードを読む機会を意識的に増やす ことで、読解力が実装力に繋がっていく • サイクルの効果 読むことができないコードは書くことができない AIサンプル作成🤖 コードリーディング󰳕 解説ノート作成📝 実務への応用⚙
32. まとめ — 本セッションの要点 32 本セッションでお伝えした内容を振り返ります。 テーマ キーメッセージ 「わからない」の分類 Lv.1〜3に切り分け、Lv.3では「最初の一手」を AIに任せる AI活用の実践 GitHub Copilot + Notion MCPで開発フロー全体を効率化 プロジェクト理解 テーマを定め、AIでドキュメントを作成し「地図化」する AIとの境界線 複数回試行・コメント検証で確度を見極め、鵜呑みにしない 業務知識の重要性 ステップを踏んだAI活用で「場当たり感」を解消する 仕様理解 「腹落ち」した状態で AIと向き合うことが前提条件 自主的な取り組み 業務面・学習面の両輪で「怖くない」を目指す まとめ＆伝えたいメッセージ
33. 伝えたいメッセージ • AIは万能ではないが、正しく付き合えば最高の「伴走者」になる ◦ AIに任せるべきこと : 最初の一手の提示、コードの見える化、認知負荷の軽減、パターン的な修正 ◦ 自分でやるべきこと : 業務理解、仕様の「腹落ち」、最終的な判断、有識者への確認 • 技術転換は「高速道路」に乗れば怖くない ◦ 生成AIという「高速道路」は確実に存在する ◦ ただし、高速道路に乗るためには 「業務知識」という運転免許 が必要 ◦ そして、目的地（ゴール）を知っているのは 自分自身 • 元ネイティブエンジニアが実践した、技術転換の高速道路 ◦ AI = 伴走者であり、判断の主体は自分自身 / 業務知識と仕様理解が、 AIを活かす土台になる / 「怖くない」と思えるまで、小さな積み 重ねを続ける まとめ＆伝えたいメッセージ 33 ご清聴ありがとうございました！質疑応答・感想などお気軽にどうぞ！
34. Copyright © Bitkey Inc. All rights reserved. 34 We Are Hiring ! 左の2次元コードから ご連絡ください！