📱
CA.flutter #3 ～Flutterエンジニアが開発スピード/開発生産性を上げるには～ レポート
公開
2025-04-03
更新
2025-04-03
文章量
約4511字
2025年3月21日、サイバーエージェント主催の「CA.flutter #3」が開催されました。今回のテーマは「開発スピード・開発生産性」。クロスプラットフォームフレームワークであるFlutterを活用するうえで、どのように効率よく、かつ高品質な実装を実現するかをテーマに、オフライン・オンライン合わせて多くのFlutterエンジニアが集まりました。本稿では、3つのセッションの内容を中心に当日の雰囲気をレポートします。
1. はじめに
オープニングでは司会のサイバーエージェント・小田琢磨氏より、今回のイベントの目的や進行方法などが紹介されました。オンライン視聴者向けにはYouTube LiveとSlido、オフライン参加者向けには懇親会での質疑交流など、さまざまなアプローチで盛り上げる試みが案内されました。
登壇者は以下の3名です。
赤星 光誓（株式会社WinTicket） 「custom_lintで始めるチームルール管理」
岸本 亮太（AI事業本部 アプリ運用カンパニー） 「GitHub Codespacesで実現するブラウザ上でのFlutter開発」
関澤 瞭（AI事業本部 アプリ運用カンパニー） 「AIコードエディタの基盤となるLLMのFlutter性能評価」
今回は、Flutterにおけるチームでの開発効率を上げるためのlintの活用や、GitHub Codespacesを使った新しい開発スタイル、さらにはLLM（大規模言語モデル）をフラッターでどう評価し活用するか、という話題が取り上げられました。
2. セッション1：custom_lintで始めるチームルール管理（赤星 光誓）
概要
株式会社WinTicketにてFlutterエンジニアを務める赤星氏からは、「チーム開発で固有ルールを守るためのLintをcustom_lintで実装し、レビューを効率化している」という事例が共有されました。
主なポイント
custom_lintとは何か
Dart/Flutter向けに独自のLintルールを設定できるパッケージ
cliでのエラー検知やQuick Fix機能に対応し、チーム独自のコード規約などを自動で enforceできる導入の経緯
レビューで細かい指摘（たとえば
HookWidgetを使わないのにHookConsumerWidgetを継承している、など）を頻繁にするのは大変チームルール（例：強制的に
!でnullableを上書きしない、アンダーバーテストが抜けていないかなど）をリント化したい結果的にコードレビュー時の不要なやりとりを省き、本質的な設計レビューに集中できる
custom_lintの辛いところ
初回セットアップ時やCI実行時にビルド時間が大きく増大する可能性がある
カスタムルール導入時、既存コードとの整合をどう取るか（すべて修正するか、局所的にIgnoreするか）で運用コストが発生
作者のレミ氏によると、公式のAnalyzerプラグインシステムが近いうちに登場しそうで、カスタムリント自体はメンテナンスフェーズに入っているらしい
今後の展望
公式の新アナライザーがどのようなAPIを提供するかに注目
カスタムlintは“とりあえず始める”のに十分価値があるが、将来的には公式プラグインへの移行を視野に入れる必要がある
「nil」という自作のLintパッケージを今後も保守していく予定
Q&A抜粋
Q:
analyzerによるコード解析が重くなった場合、具体的な対処策は？ A: 決定打はまだないが、新しい公式アナライザープラグインシステムで大幅に改善される可能性がある。今は“耐え時”かもしれない。Q: 独自ルールを決める際、強制力はどのように決めた？ A: 基本は「何を解決したいのか」が先にあって、それを実現する形でルールを作る。必要な強さは自然に定まることが多い。
赤星氏は「集中すべきところに集中できる環境を整えるためにはLintが有効。新アナライザーが登場しても知見は活きる」と強調していました。
3. セッション2：GitHub Codespacesで実現するブラウザ上でのFlutter開発（岸本 亮太）
概要
AI事業本部の岸本氏は「GitHub Codespaces（以下、Codespaces）」を活用し、ブラウザのみでFlutter開発を完結させる方法を詳しく解説。ローカル環境を構築しなくても、DockerコンテナベースでFlutterのビルド・実行・コミットが行えるメリットが紹介されました。
主なポイント
GitHub CodespacesとDevcontainer
GitHubが提供するクラウド開発環境。VSCodeのエクステンションなどが活用可能で、コンテナ内でFlutter SDKやAndroid関連のパッケージをインストールできる
devcontainer.jsonで依存パッケージや初期コマンド（例:flutter pub get）などを指定し、チーム内で統一した開発環境を共有できるブラウザ上でのビルド実行
シミュレータや実機連携は困難だが、
flutter run -d web-serverでFlutter Webを起動すればCodespaces内でポートを解放し、ブラウザからアプリ確認可能ホットリロードはなく、コンソール操作のリロードが必要。しかし、小規模修正なら十分運用できる
スマホ・タブレット端末を使った開発
iPadなどキーボード付きタブレットなら比較的楽。
iPhoneなど画面が小さいデバイスではVSCode UIが窮屈だが、サイドバーや行番号などを非表示にする設定で最低限の操作は可能
タスク定義 (
tasks.json) を駆使してGUIベースでビルドを実行し、生成したAPKを直接ダウンロードしてインストールする方法もアリクラインなどAIエージェントの活用
Codespaces上でのAI支援（Copilot, Cursor CLIなど）との相性が良い。
隙間時間に開発でき、複数のCodespacesを立ち上げてエージェントを並列活用するなどの発展も考えられる
Q&A抜粋
Q: ローカルでなくCodespacesをメイン開発に使うメリットは？ A: チーム内で同一環境を共有しやすい。PMや他職種に対してもコードを触れる環境を即用意できる。新メンバーのオンボーディングも容易。
Q: ブラウザだけでなくスマホでの操作は本当に実用的？ A: 正直に言えば画面が小さく操作感はつらい。ただタスク定義やAIエージェント駆動によって実装を補うと、隙間時間に小さな修正を行う程度なら可能。
岸本氏は「短時間で環境を用意し、誰でも同じ設定を使えるのは大きなメリット。AIエージェントと併用すれば隙間時間の開発も実現可能」と語り、今後の活用が期待されました。
4. セッション3：AIコードエディタの基盤となるLLMのFlutter性能評価（関澤 瞭）
概要
最後はAI事業本部アプリ運用カンパニー所属の関澤氏が登壇。LLM（大規模言語モデル）の評価手法を解説しつつ、Flutter開発支援性能をどのように測れるかを試行した話を紹介しました。
主なポイント
LLM評価とは
入力と出力をもつタスクを定義し、モデルが「正解」にどの程度一致するか、あるいは「より望ましい回答」を出せるかを調べる
コード生成やコード修正などのタスク別に評価指標（コンパイルエラーの有無、テスト通過率、UIが期待通りか）を決める
Flutter特有の評価をどうするか
例：
RiverpodやHookWidgetなど固有のパッケージを活用できるかUI生成タスク：ビルドが通るか、生成UIが指定どおりかをテスト
データセットを作るとき、Flutter固有のコードを大量に集める必要がある（GitHubなどをクローリングする可能性）
実験例
GPT-4に対してウィジェット生成タスクを与える → 大部分は正しく生成できるが、一部のライブラリを使う際に不整合
原因は学習データに含まれていない、あるいはプロンプトが不十分などが推察される
今後の展望
フラッター開発者コミュニティが協力してデータセットを整備すれば、LLMを使ったフラッター開発支援がより強力に
評価手法を個人・企業問わず共有し、モデル改善に繋げることでFlutter開発の生産性が大幅に向上する可能性がある
Q&A抜粋
Q: フラッター向けに特化したLLMは今後登場しそう？ A: 歴史的には特化モデルから汎用モデルへ移行している。汎用LLMを微調整（プロンプトエンジニアリングなど）して特化モデル的に使う流れが有力かもしれない。
Q: 商用データセットとしての扱いは可能か？ A: データセットのライセンス次第。公開リポジトリなどから収集する場合、利用規約を確認する必要がある。
関澤氏は「アカデミアでは特化型のデータセットは作りにくいので、現場から盛り上げることが鍵。皆で評価を工夫して、FlutterのLLM活用を強化していきたい」と呼びかけました。
5. 全体を踏まえた感想—「枠組みづくり」と「実践力」で生産性を高める
今回のCA.flutter #3では、チーム独自のlintルールやGitHub Codespaces活用、そしてLLMを使ったFlutter開発支援まで、幅広い視点から「開発スピード・生産性向上」の具体策が提示されました。3つのセッションを通じて感じられたキーワードは、「枠組みづくり（lint・Devcontainer・評価軸）」 と 「実践力（AIツールや新しい開発環境をどう使いこなすか）」 の両輪です。
枠組みづくり： custom_lintなどのルール整備は「コードレビューを本質的な議論に集中させる」というメリットが目立ちました。さらにCodespacesやDevcontainerを使って統一開発環境を準備することで、オンボーディングやチームコラボが滑らかになります。
実践力： LLMを介したコードエディタが急速に普及する今、モデルごとの特性を理解して使いこなすかが大事になってきています。評価指標やデータセット作成を現場のエンジニアが行う姿勢は、開発効率のみならず新たなイノベーションを引き寄せる可能性を示しています。
Flutterがクロスプラットフォームフレームワークとして進化を続けるなか、これらの取り組みは 「大きな技術の波を、具体的な作業レベルでどう使いこなすか」 という実装者視点を鮮明に映し出すものでした。今後もCA.flutterは定期的に開催される予定とのことで、Flutterエンジニアたちが最前線でどんな知見を蓄え、共有していくのかが注目されます。
以上、CA.flutter #3「開発スピード・開発生産性を上げるには」のレポートでした。ご登壇者の皆様、参加者の皆様、そして運営の皆様に感謝しつつ、Flutterエコシステムの新たな挑戦にますます期待を寄せたいと思います。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
