こんにちは。UPSIDERでアプリ開発を担当している田中です。
先日、株式会社UPSIDER / 株式会社SODA / 株式会社ビットキーの3社合同で開催された 「AI NativeなFlutter開発の現在地〜業務導入の壁と、デザイン・テストへの応用〜」 というイベントで登壇する機会をいただきました。同じFlutterでも、組織規模やプロダクトの性質によって開発の型は大きく異なります。「だからこそAIをどこに組み込み、どう設計し、どう回すか」の答えも変わってくる。そんな中で、各社の開発プロセスはどう変化したのか、リアルな取り組みと現在地が共有されたイベントでした。
その中で私は 「品質を保ちながら、プロダクトの核に迫るための取り組み」 というテーマで登壇しました。法人カード「UPSIDER」/ 「PRESIDENT CARD」のアプリ開発を担当する Mobile Groupにおいて、Flutter開発・backend / infra・QA・分析・CI/CDの各領域でどのようにAIを組み込み、どこは人に残しているのか。本レポートでは、そのときお話しした内容を補足も交えながら整理してお伝えします。
なお、当日は時間の都合でFlutter開発・分析・CI/CDを中心にお話ししました。backend/infra・QAの取り組みについては資料には含めていたものの、当日は触れきれなかった部分です。この記事では資料ベースで補足としてお伝えします。
📎 登壇資料はこちらで公開しています。
アプリ開発全体の話については、以下の記事もぜひあわせて読んでください。
Mobile Groupの置かれている状況
まず前提として、UPSIDERのMobile GroupはMobileといいつつ、アプリだけを作っているチームではありません。
担当領域は、
- 複数のアプリ（UPSIDER / PRESIDENT CARD、今後展開予定のホワイトレーベル）
- それらに紐づくbackendの開発
- infrastructureの構築・運用
- BigQueryを使った分析
- QA の設計・実施
と多岐にわたります。Mobileを中心とした一貫した体験を設計・展開するグループという前提があり、アプリのレイヤーだけでは閉じない仕事の取り方をしています。
この少人数で広い領域をカバーするという前提が、私たちのAI活用の重要性に直結しています。
どこにAIを使っているか
Mobile Groupでは、デザイン・企画・開発・分析・QAと、ほぼすべての工程で AIを使っています。とはいえ、ただ使うだけでは品質を保てません。どの工程でも共通して持っている考え方が2つあります。
- 任せていいものと、任せきってはいけないものを切り分ける
- 意図とのズレを再現させない、検出する仕組み作りに重点を置く
AIは便利ですが、すべてを任せられるわけではありません。どこを任せ、どこに人が残るのかを意識的に設計することが、品質を保ったままスピードを上げるための前提になります。
ここからは、領域ごとにBefore / Afterを整理しながら、私たちが実際にやっていることをお話しします。
AI前の Flutter開発 / AI後の世界
OpenAPI Generator まわり
Before
OpenAPI GeneratorでAPIクライアントを生成していましたが、enumなど生成結果がDartから使いづらく、アプリ側で再定義が必要でした。生成 → 再定義というステップが常に発生していて、地味に重い作業でした。
After
OAS（OpenAPI Specification）から必要な型と通信コードを推測し、skillとして定義して生成する流れに変更しました。
- 小さいAPI群から段階的に移行し、skillも都度調整
- 再定義作業から解放され、人が読みやすい形で出力できるように
- ただし、OASが不十分だとクラス名などに影響が出るため、設計に時間をかける必要がある
コードを生成させるだけでなく、その入力となる OASの設計をきちんとすることが、AI後の世界では一層重要になっているという実感があります。
Security risk
セキュリティまわりは、secrets / API keyの埋め込み、logへの機微情報混入、deep link / URL schemeの取り扱い、権限境界など、重要なポイントがいくつもあります。
私たちのアプローチはシンプルです。
- Claude Codeでsecurity観点のobservationを走らせる
- 見つけたものは修正させずに、まずtask化する
- 観点 / 該当箇所 / 想定リスクを残す
- 人が優先度・修正方針を判断したうえで対応する
定期実行とtask化にしているのは、例えばPRなどで都度AIに修正させてしまうと diffが混在し、正常な判断ができなくなる可能性があるためです。AIで気づきの網を広げ、判断と意思決定は人に残すという方法をとっています。
AI前の backend, infra開発 / AI後の世界
backendと infrastructureでは、AI導入前後で「AIに任せられる範囲」の変わり方が異なります。
Before
- Backend: チームに知見が溜まっており、各々が実装とレビューを回せていた
- Infrastructure: 前提知識・運用知見が必要で、infra teamに実装自体を任せることも多かった
After
- Backend: チームがレビューできるところまで育っているので、AIに多くを任せられる
- Infrastructure: AIと一緒に実装することで、自チームで実装を完結できるようになった。ただし専門家のレビューが引き続き最重要
ここで大事だと考えているのは、AIは100のpromptには100以上で返すが、1のpromptには 100は返してくれないということです。AIに何かを任せるには、その領域に対する100を投げられる側の知見がチームに必要です。知見が浅い領域を AIで完結させるのは危険で、チームの状況を冷静に見極めることが、AI活用の前提になります。
AI前の QA / AI後の世界
Before
- QAのテストケース設計は実装者が実施し、レビューを実施していた
- 目が滑りやすく、足りていない部分に実施中に気づくこともしばしばあった
After
- TicketやPRを参照しながら、markdown形式でテストケースを起こすskillを作成
- 人はそれを見てレビューを実施し、仕様とのずれを判断する
- マージするとworkflowがQaseにそれらをsyncし、人が実施可能な状態にする
テストケースをゼロから書くのではなくAIが起こしたものをレビューする形に変えたことで、観点の抜け漏れがレビュアー視点で見つけやすくなりました。実装者がそのままテスト設計をすると、自分の思い込みに引きずられがちな課題に対する解決策とすべく、今後も試行錯誤しながら進めていきたいと考えています。
AI前の分析 / AI後の世界
Before
- 分析はBigQuery、クエリは人間が手動で記述
- クエリ最適化が不十分で、不要なデータ取得によりコストが増大
- 負荷が高いため、分析が後回しになりがち
After
- Ruleに基づき AIがクエリを自動生成する形式へ移行
- 特にクエリ最適化に効果を発揮（コストとパフォーマンスの両面）
- エンジニアが数字を見ながら次に何を作るかを決める側に注力できるように
ここは個人的にも、AI導入の効果がいちばん体感しやすかった領域です。クエリを書くこと自体は本質ではなく、本質は数字を見て次の意思決定をすること。前者を AIに任せられるようになったことで、後者にちゃんと時間を使えるようになりました。
AI前の CI/CD / AI後の世界
Workflow
Before
- Workflowは手動作成 + 人のレビュー
After
- Workflowの記述は AIに任せる + AIレビュー + 人のレビュー
ここで注意しているのが、Workflow特有のセキュリティ上の問題はBefore/Afterどちらでも起こりうるという点です。
- privileged tokenの流出経路
- untrusted input（issue / PR タイトルなど）の不適切な使用
- third-party actionのバージョン固定なし
こうしたパターンに対してはzizmorで静的解析を実施し、人とAIのレビューに加えてもう一段の検出層を設けています。
Claude Code Action
UPSIDERでは、リリース前に全変更内容を報告・共有する運用があります。「なぜ・何をして・どんなriskがあるか」を説明する必要があり、これは品質を保つうえで欠かせないプロセスですが、その分リリース前は大変でした。
Before
- 変更内容をリリース前に洗い出し、メンバー全員で記述 + レビューしていた
After
- Whyは人間が書く。ただしAction側でWhyが足りているかをチェックさせる
- What / RiskはAIがコードから推測 → 人がチェックしてマージ
- リリース前に、PRのdescriptionから辿って書き起こす
ここでも考え方は同じで、なぜやるのかという意思の部分は人に残し、何を変更したか、どんなリスクがあるかという事実の整理はAIに任せています。
まとめ
ここまで、Mobile GroupがFlutter / backend / infra / QA / 分析 / CI/CDの各領域で、AIをどう使い、どこを人に残しているかをお話ししてきました。
全体を通して伝えたかったことはシンプルです。
- クエリやrisk検知、分析など、AIに任せられる業務は多い
- 全体と今後を見据えて 何をなぜ実施するのか といった判断は、引き続き人に残る
- 得意・不得意な領域がそれぞれにあり、それらを判断しながら業務を効率化する
そしてその先にあるのは、エンジニアは「何を作るかを決める側」に近づくという姿だと考えています。実装やクエリ、ワークフローの記述といった部分をAIに任せられるようになったぶん、私たちは「次に何を作るのか」「なぜ作るのか」を考える時間に投資できるようになりました。これはMobile Groupのような少人数で広い領域をカバーするチームにとって、特に大きな変化です。
UPSIDERのアプリは、これからホワイトレーベル展開などを通じて、扱う領域がさらに広がっていきます。その中で、品質を保ちながらプロダクトの核に迫り続けるために、人とAIの役割分担を引き続きアップデートしていきたいと考えています。
他社の登壇から得た学び
今回のイベントは3社合同ということで、他2社の登壇者の方からも多くの刺激をいただきました。
2回作る AIプロトタイピングを業務で活用するコツ
プロトタイピングの手法として興味深い部分が多い発表でした。1回目を捨てる前提で作るというのは一見ハードルが高いように見えますが、実際のところトータルで考えてみると、1回目をそのまま育てた場合に後々負債としてリファクタリングしたり改善したりするコストを踏まえれば、コストはゼロ、あるいは移行コストなども踏まえれば、むしろマイナスにまでできるのではないか、と感じました。
SODAさんとは、チーム構成やfrontend / backendのlayerを超えて開発を進めていくという点でも共通する部分が多く、懇親会でお話しした際にも参考になる部分が多かったです。
Flutter初心者が生成AIで大規模アプリ開発をキャッチアップした工夫
私が当日触れきれなかったものの、infraの節で書いた専門家の意見が結局重要というポイントと共通するメッセージをお話しされていたのが、とても印象的でした。AIを使うにあたって、そもそも質問するだけの知識がない状態からどのように進めるべきか、という難しさが丁寧に言語化されていて、聴いていてとても面白い発表でした。
懇親会でも、このテーマで深くお話しさせていただきました。AIに任せきれるだけの知識量は実は多くて、その領域まで至るまでに何が必要かというのは、技術スタックやチームによって答えが変わる問題だと感じています。
We Are Hiring
UPSIDER Engineering Deckはこちら📣
