協創型コミュニティアプリ "Livefor Space” アプリ開発の裏側

2026/2/22 SEB SUMMITで開催されたイベントで登壇しました。
https://summit.sapporo-engineer-base.dev/

Transcript

1. 2026.2.22 CAMPFIREグループ Livefor株式会社開発室 須藤 拓也 協創型コミュニティアプリ "Livefor Space” アプリ開発の裏側
2. 自己紹介 須藤 拓也 / Takuya Sudo Livefor株式会社（CAMPFIREのグループ会社） - 北海道室蘭市出身 - モバイルアプリ開発が主戦場（iOS開発は3GSの頃からスタート） - 現在はFlutter, SAM, Svelte, AWSでアプリ開発 - 最近の興味は量子コンピューター - 今年から結婚を機にやめていたキックボクシング（ムエタイ）を再開 - 肩書はアマチュアソフトクリーマー（自称） https://github.com/someone-said-so
3. 話すこと 1. アイスブレイクで話すならソフトクリーム 2. Livefor Spaceのβリリース 3. 開発チーム体制 4. モバイルアプリの技術スタック 5. リポジトリ作成時にやったこと 6. 開発の裏側 7. βリリース後の課題とLivefor Spaceのこれから 8. まとめ 私の発表では必ずソフトクリー ムの話をします。 しばしお付き合いください！
4. CAMPFIRE忘年会後日談 ソフトサーブマシン視察？
5. カルピジャーニとテイラー - CAMPFIREでは毎年12月に忘年会を都内で開催 - 翌日土曜は東京にいる貴重な機会なのでソフトクリーム巡り - 印象に残った2店舗はそれぞれの別のマシンで提供 # DOLCE TACUBO 虎ノ門ヒルズ - CARPIGIANI製のフワフワソフトクリーム # アイスクリーム ソーワ - TAILOR製のムッチリバニラソフトクリーム イタリア製とアメリカ製でそれぞれ特徴が出るのが奥深いポイント！
6. 「マシンは味の50%を左右する重要なファクター」
7. Livefor Spaceとは
8. Livefor Spaceはどんなサービス - クリエーターとそれを応援し支えるファンが一緒にものを生み出す協創体験を作り 出すアプリ - クラウドファンディングで繋がった縁を、その先も続く共感に繋げる - 例：商品のアイディアやデザインなどをファンが提供する - 貢献に対してバッジをもらえる - その貢献をバッジという形で可視化する - プロジェクトの先行アクセスや限定リターンを検討中 - バッジが自己証明の一つになる - クラウドファンディングとの親和性 - クラウドファンディング前のプレマーケティング - 企画からそのまま資金調達・宣伝に利用できる
9. 1/26にβリリースし、現在試験提供中 - 第一弾としてKOSHIKI BREWERYさんが参加中 - 鹿児島の甑島でクラフトビール製造と古民家再生を行う - 2/18にクラウドファンディング開始 - CAMPFIREのWebサイトかからアクセス可能 - https://camp-fire.jp/projects/921012/livefor_landing - 近日第二弾がオープン予定
10. 開発チーム体制
11. プロジェクト開始からリリースまで - CAMPFIREとLiveforの共同チームを結成 - リリース後に行われる施策で CAMPFIREと協調して開発を進める必要があるので共同チームを結 成 - この時に得たLiveforメンバーがCAMPFIREの知見を得ることができた - グループ会社として CAMPFIREメンバーとの交流が生まれた - App/FE/BEの領域3チームで開発 - それぞれのチームに必ず CAMPFIRE&Liveforのメンバーがいるチーム構成 - 私はその中でモバイル開発のアーキテクトを担当 βリリース後 - Liveforメンバーで開発をリード - CAMPFIREメンバーは元のチームに戻り、 Liveforメンバーで開発を進捗 - App/FE/BEの領域チームを開発チームとして一体化 - 技術的なチャレンジとしてエンジニアが領域関係なくタスクを担当する体制を目指す
12. モバイルアプリの 技術スタック
13. Livefor SpaceアプリはFlutterで開発 Livefor/CAMPFIREとも Flutterでの開発知見があっ たのでそれを活かす戦略を 採用 右は主なモバイル開発の 技術スタック 配信 Firebase App Distribution(以下、FAD) CodeMagic CI/CD Github Actions Firebase Test Lab MaaS Firebase 状態管理&DI Riverpod AI Windsurf Cursor Gemini Code Assist Test Unit Test, Widget Test, Integration Test alchemist(Visual Regression Test) Secret管理 Google Secret Manger 監視・モニタリング Sentry
14. リポジトリ 作成時に何をしたか
15. まずは開発のコンセプトを決めること アプリ開発チームで大切にしたい柱を以下にしました - 高いテスタビリティを確保する - DIにより差し替えでテストケースを容易に再現できるテストコードが書ける - Visual Regression Test（以下、VRT）によりUIの意図しない変更を検知する - そのためのアーキテクチャ設計をドキュメント化 - AI開発と親和性が高い - それぞれが使いたい AIツールを利用しているので、それぞれの rules.mdを用意 - 仕様やデザイン、タスク管理などを MCPで接続(e.g. Notion/Figma/Linear…) - 自動化できる作業は自動化する - Makefileで環境構築の手順を作っておく (環境構築はmakeコマンドで一発) - lefthookでgit操作とともに上記が走る (e.g. worktreeでfirebase設定やSecret DLを実行) - プラグインの更新は renovateにpull request(以下、PR)を作られる - ローカル環境とCI環境が同じように動くこと - GithubとのOIDC認証によりローカルと同じシェルスクリプトが CI上でも走る - 同様にCodemagicでも配信前の設定に同じシェルスクリプトを利用
16. Flutterの技術アセットを相性の良いアーキテクチャを考える - クリーンアーキテクチャとレイヤードアー キテクチャのいいとろ取り - モバイル開発で冗長なところを削る - Riverpodなどをある程度前提にしてレイヤーを 考える - 状態管理をアーキテクチャに組み込む - よくあるクリーンアーキテクチャは BE側が中心 でクライアント側の状態管理をどう定義するか の記事が少ない - なるべく単方向データフローにする - データ更新はusecaseから、読み取りは adaptorから行いUIがproviderにロジックを実 装しなくていいようにする
17. 開発の裏側
18. - API実行して401だった場合、トークンリフレッシュをして APIをリトライするか - 認証に成功したとき、端末内部にトークンを秘匿化して保存するか - JSONレスポンスが返却されたときそれをクラスにパースしたり、 4xx/5xxでエラーをスローするか - いいねを短時間にタップした時、状態変化は 3回トグルするがAPIリクエストは1回だけ - メンションのマークダウンで書かれたメッセージのメンション部分をユーザー名に変換するか - すべての未読お知らせを既読にする既読数は 0になり、アイコンの赤バッジが消えるか - メッセージを取得したら AppStateをAPIの通りに更新し、それにより別の画面のメッセージも更新されるか - ホーム画面に遷移したとき、 Firebase Analyticsのscreen_viewをイベントを送信するか - 認証情報が無効になったらログイン画面に強制遷移するか 1. 最初に一つAIが参考になるようなテストケースをしっかり書く 2. インフラストラクチャ層からプレゼンテーション層まですべての層にサンプルを作る 3. そうすることでAIが書くテストケースの精度をあげる 4. 現在、テストコードはほぼ AIが書いている(厳密な集計はしていないが体感 9割超) テストケース一例
19. 意図しないUIの変更をピクセル単位で検知することで普段は気づきにくい UI崩れをリリース前に差し止めること ができます。またコンパイルエラーでは検知できない (e.g. アセットファイルNot FoundによるRuntime Error)レン ダリングエラーも検知します。 ただCI上ではフォントが自動で置き換わるため CIで動作するgolden imageの作成には工夫が必要。 VRTが有効 1 変更によりアイコンが消える 2 変更前のgolden image 3 コード変更によるイメージ生成 4 差分出力
20. - releaseブランチからmainブランチへのPRでGithub Actionsの統 合テストが起動する - CI環境上でOIDC認証しているGoogle WorkloadでFirebase設 定や環境変数をダウンロードする - CI上でローカルと全く同じ操作で環境構築 - AndroidについてはFirebase Test Labで目的のデバイスを選択 することができる - “OS14のPixel9”のような指定がある程度可能 - このテストにより「デバッグモードでは動くけど、リリースすると 動かない」 というレアケースだが起きると深刻なケースを防止で きる - ただしメンテナンスがそこそこ大変 - 統合テストは一般的なFragile Testにあたりコストの観点からユース ケースを絞ることが重要 リリース前にiOS/Androidの起動テストをCI環境上で行う
21. すべての工程にAIが関わる 私のタスク完了までの作業フローです。メンバーによって様々な AIツールを使っているのでそれぞれ異なります が、定期的に知見を共有しています。 1. Gemini CLIでタスク分析をさせ、タスクに必要なプランを作る 2. NotionやFigmaのMCPで情報を読み取りある程度動作するコードを生成させる 3. デバッグモードでシミュレータで動かしながら微妙に違うところをVscodeのGemini Code Assistと対話しながら修正してhot reloadで確認する 4. 問題を解消したらGemini CLIにPR前の確認(静的解析やテスト)をしてもらい、その ままPRを作成してもらう 5. PRとともにGitHub AppのGemini Code Assistがサマリーとレビューを開始 6. slackに通知が届くのでレビューに対して修正を行う 7. 最後は責任を取る人柱(AIにはできない)がapproveしてタスク完了
22. - windsurf/cursor/clineのルールを一箇所にまとめつつ、どのIDEでも同じ動作する - releaseブランチを作るとそのままFADでstaging用のアプリを配信し、そのままリリースバ イナリーをApp Store/Google Play Consoleにアップロードする - Sentryで「誰が何時にどこでエラーしたか」「そのエラーは何件程度あるか」などを遠隔監 視する - Linearによる日々の成果をサマリーでまとめる その以外にも このような工夫をそれぞれのメンバーが得意なことをそれぞれのアイディ アで実行に移していきました。 チームメンバーの積極的な姿勢と豊富なアイディアがスケジュール通りの リリースに寄与しました！
23. βリリース後の課題と Livefor Spaceのこれから
24. - GitHub Actions上のITがあまり安定しない&遅い - cacheを工夫したり、buildとtest lab uploadの工程を分けることを検討中 - VRTではImage.networkやアニメーションがあるWidgetのGoldenImageを生成不可 - 現状はデフォルトでasset imageが使用されるようしている - １チームにしたもののApp/FE/BEのタスク担当が固定化を脱却できていない - キャッチアップをそれぞれが進めているがタスクとの両立が課題 現在の課題 Livefor Spaceのこれから - 可視化できた貢献をLivefor Spaceの外に広げたい - Livefor創業時に掲げたコミュニティともう一つの軸である Web3の活用 - Livefor Spaceで協創を支援するための機能開発 - アプリ内でのAI活用や共感を生む仕組みづくり - 地方でのプロジェクト創出、私の希望としてはそれが 北海道からであることを希望しています - CAMPFIREとの相乗効果とクラウドファンディング後の関係創出 - 「クラウドファンディングで支援したら終わり」ではなく、その後も続く関係性を作る
25. ご清聴 ありがとうございました 謝意、この場を借りて感謝表明！ @CAMPFIREコミュニティチームの皆様 リリースには皆様の協力が必要不可欠でした。ありがとうございました！ @KOSHI BREWERY様 ご賛同ありがとうございます。地方からの熱い想いを応援することが今後の Livefor/CAMPFIREが社会と必要なインフラになる鍵だと思っています。