Flutter3.38アップグレードにおけるiOSとAndroidの影響範囲 背景 Flutter3.38アップグレードの手順 パッケージのバージョン依存関係調整 依存関係の解消によって副次的問題が発生 1. Dart SDK バージョン 2. Ferryエコシステム（GraphQLクライアント） 3. Freezed（コード生成） 4. Firebase（iOS 13対応のため2.x系を使用） 5. その他の重要な更新 6. Isar Plus（データベース）モデル修正 解決した依存関係の競合 競合1: isar_db_generator 競合2: intl バージョン 競合3: source_gen バージョン 競合4: build バージョン 競合5: gql_exec バージョン 競合6: ferry バージョン 競合7: web パッケージ（iOS 13対応のための調整） 競合8: Firebase iOS 15要件 参考リンク 既存コードの改修作業 1. isar_plus 移行に伴うimport文の変更 2. isar_plus 移行に伴うPodfileの変更 3. NDKバージョンの明示的指定 4. Android app の namespace（AGP 8.x 必須） 5. サブプロジェクトへの namespace 注入 6. BuildConfig の有効化 7. Freezed 3.x マイグレーション（全モデルに abstract 修飾子） 8. retrofit / ParseErrorLogger 対応 9. Android 旧埋め込み (PluginRegistry.Registrar) 削除対応 10. iOS CocoaPods更新 Flutter バージョン別 カート追加時パフォーマンス比較レポート 比較サマリー 結論 主な改善要因（推測） 今後の検討 まとめ 1. テスト 2. iOS 11-12ユーザーへの対応検討 最後に 　こんにちは、開発本部 開発２部 RetailHUB NetSuperグループに所属するホーク🦅アイ👁️です。 背景 　現在提供しているネットスーパーアプリはFlutter＋Dartで実装しております。一方で、昨年2025年11月1日までに対応が必要であったGoogleからの メモリの16KBページサイズをサポートせよ という通知を延長申請して2026年5月31日まで対応を保留にしていました。2026年2月現在、この延長期限も近づいてきていることを理由にFlutterのバージョンを3.38系にアップグレードすることになりました( こちら の公式ブログにも3.38から標準対応したとあります)。 Flutter3.38アップグレードの手順 　通常、Flutterのバージョンをアップグレードする際の流れとしては、以下の2点を気にする必要があり実際にそのプロセスを踏まないといけないことも少なからずあります。 パッケージ依存関係の解消 既存ソースコードで改修 　今回、対象のソースコードで利用しているFlutterバージョンは3.24.1と古めのバージョンであるためバージョン差分が大きく、2点とも対応が発生しました。以下にその2点の対応について詳細を記していきます。 パッケージのバージョン依存関係調整 　目的はあくまでAndroidアプリの16KBページサイズに対応することなのでAndroidアプリのビルドをまず意識した以下のバージョンを調整しました。 Flutter,Dartのバージョンを上げる Flutter3.38.9、Dart3.10.8にしました DevTools 2.51.1 Gradleのバージョンを上げる 8.7にしました AGPのバージョンを上げる 8.5.1にしました Kotlinのバージョンを上げる 2.0.21にしました NDKバージョンを明示指定 29.0.14206865にしました その他利用ライブラリの対応バージョンをtrial and errorで上げる 現状のバージョンのままでビルドしてみてエラーが出たら上げるを繰り返しました 依存関係の解消によって副次的問題が発生 　今回、Androidアプリのためにアップグレードをするので必要なライブラリパッケージも必要最低限のものだけを最小限でアップグレードすることを心がけたのですが、意図せずiPhoneアプリ側の方にも影響を及ぼしてしまうことが判明しました。具体的には以下のことが発生しました。 iOSの最小メジャーバージョン番号が12から13以上に引き上げ 　直接的な引き上げ条件は、 Flutter公式 によれば、swiftコードを利用する場合とありますがFlutter3.38自体がそれに該当するということ( 参考ページ )でした。というわけで、必然的にFlutter3.38にしないといけない場合はiOS最小対応バージョンも13以上になるということでした。 　最終的には以下に挙げるバージョン対応で一旦、すべての依存関係の競合を解決し、 pub get 、コード生成、iOS CocoaPodsインストールがすべて成功しました。 1. Dart SDK バージョン 変更 : >=3.7.0 <4.0.0 → >=3.8.0 <4.0.0 理由 : json_serializable と freezed の最新版が要求 2. Ferryエコシステム（GraphQLクライアント） パッケージ 最終バージョン 理由 ferry ^0.16.1 ferry_generator 0.12.0+3との互換性 ferry_generator ^0.12.0+3 build 4.0対応 build_runner ^2.10.3 build 4.0対応 gql_code_builder_serializers ^0.1.0 ferry_generator 0.12.0+で必須 gql_exec ^1.0.0 ferry_generator依存関係 gql_http_link ^1.0.0 gql_execとの互換性 gql_transform_link ^1.0.0 gql_execとの互換性 3. Freezed（コード生成） パッケージ 最終バージョン 理由 freezed ^3.2.5 build 4.0対応 freezed_annotation ^3.0.0 freezed 3.x対応 4. Firebase（iOS 13対応のため2.x系を使用） パッケージ 最終バージョン 理由 firebase_core ^2.32.0 iOS 13サポート（3.x+はiOS 13必須） firebase_analytics ^10.10.7 firebase_core 2.x互換 firebase_crashlytics ^3.5.7 firebase_core 2.x互換 firebase_messaging ^14.7.10 firebase_core 2.x互換 & webパッケージ互換 firebase_remote_config ^4.4.7 firebase_core 2.x互換 firebase_app_installations ^0.2.5+7 firebase_core 2.x互換 Firebase iOS SDK : 10.25.0（iOS 13+をサポート） 5. その他の重要な更新 パッケージ 最終バージョン 理由 intl ^0.20.2 flutter_localizations要求 retrofit_generator ^10.2.1 source_gen 4.0対応 json_annotation ^4.9.0 json_serializable要求（dependenciesに追加） 6. Isar Plus（データベース）モデル修正 isar_plus v4のAPI変更に対応： 変更後（isar_plus v4スタイル）: @collection class EventLog { EventLog({required this .id}); final int id; // Auto-increment id (isar_plus v4) late String data; } 主な変更点: @Collection() （大文字）→ @collection （小文字） Id id = Isar.autoIncrement → final int id とコンストラクタで受け取る 実際のauto-increment IDは isar.collection.autoIncrement() で生成 解決した依存関係の競合 競合1: isar_db_generator 問題 : isar_db_generator パッケージが存在しない 解決 : isar_db は元の isar_generator を使用することを確認 競合2: intl バージョン 問題 : flutter_localizations が intl 0.20.2 を要求 解決 : intl を ^0.20.2 に更新 競合3: source_gen バージョン 問題 : isar_plus が source_gen ^4.0.2 を要求、 retrofit_generator ^8.1.0 が source_gen ^1.3.0 を要求 解決 : retrofit_generator を ^10.2.1 に更新（source_gen 4.0対応版） 競合4: build バージョン 問題 : build_runner >=2.9.0 が build ^4.0.0 を要求、 freezed ^2.x が build ^2.3.1 を要求 解決 : freezed を ^3.2.5 に更新（build 4.0対応版） 競合5: gql_exec バージョン 問題 : gql_transform_link が古い gql_exec を要求、 ferry_generator 0.12.0+3 が gql_exec ^1.0.0 を要求 解決 : gql_exec 、 gql_http_link 、 gql_transform_link をすべて1.x系に更新 競合6: ferry バージョン 問題 : ferry ^0.14.2+1 が ferry_exec ^0.3.1 を要求、 ferry_generator 0.12.0+3 が ferry_exec ^0.7.0 を要求 解決 : ferry を ^0.16.1 に更新 競合7: web パッケージ（iOS 13対応のための調整） 問題 : isar_plus が web ^1.1.0 を要求、Firebase 4.x系が web ^0.5.1 を要求 解決 : Firebaseパッケージを2.x系にダウングレード（iOS 13サポートのため） 競合8: Firebase iOS 15要件 問題 : Firebase 4.x系（firebase_core 4.0+）はiOS 15を最小要件とする 解決 : Firebase 2.x系（firebase_core 2.32.0）を使用してiOS 13をサポート 参考リンク isar_plus v4 ドキュメント ferry_generator changelog freezed 3.0 migration Firebase Flutter changelog firebase_core 3.0.0 breaking changes 既存コードの改修作業 　前述にある依存パッケージライブラリをアップグレードすることで破壊的変更が発生してしまった全箇所をエラーがなくなるまで対応していくという作業も相当数発生しました。 1. isar_plus 移行に伴うimport文の変更 　 package:isar/isar.dart → package:isar_plus/isar_plus.dart に変更 2. isar_plus 移行に伴うPodfileの変更 ios/Podfile で isar_flutter_libs → isar_plus_flutter_libs に変更 3. NDKバージョンの明示的指定 追加 : ndkVersion "29.0.14206865" （安定版最新。r28+ で 16KB アライメント対応のため r29 を使用） ファイル : app/build.gradle 理由 : NDK r28以上で16KBアライメントがデフォルト対応。固定していた 28.0.12674087 ではなく、安定版最新 29.0.14206865 を推奨 4. Android app の namespace（AGP 8.x 必須） 追加 : namespace "tv.every.fresh" ファイル : app/build.gradle 理由 : AGP 8.x ではモジュールに namespace の指定が必須。未指定だと「Namespace not specified」でビルド失敗する。 5. サブプロジェクトへの namespace 注入 追加 : Android library プラグインで namespace 未指定のサブプロジェクトに、 AndroidManifest.xml の package を namespace として設定 ファイル : build.gradle （root） 理由 : AGP 8.x では全モジュールに namespace 必須。古いパッケージは namespace 未指定のため「Namespace not specified」でビルド失敗する。pub cache は編集しないため、root の subprojects.plugins.withId("com.android.library") で manifest の package を注入する。 6. BuildConfig の有効化 追加 : 全 Android サブプロジェクトで buildFeatures.buildConfig true ファイル : build.gradle （root） 理由 : AGP 8.x では BuildConfig がデフォルト無効。custom BuildConfig を使うパッケージがあったため「defaultConfig contains custom BuildConfig fields, but the feature is disabled」でビルド失敗する。root の subprojects.afterEvaluate で全モジュールに有効化する。 7. Freezed 3.x マイグレーション（全モデルに abstract 修飾子） 対象 : @freezed を付けた全てのモデルクラス 対応 : Freezed 3.0 マイグレーションガイドに従い、 全てのクラス定義に abstract 修飾子を追加 変更例 : // 変更前 @freezed class Shop with _$Shop {...} // 変更後 @freezed abstract class Shop with _$Shop {...} 理由 : Dart 3.10 コンパイラ下で non_abstract_class_inherits_abstract_member エラーを解消するため。Freezed 3.x の生成コード（mixin の抽象メンバー）と互換させるには、公開クラスを abstract class にすることが必要。 実施方法 : 上記のとおり、該当する全モデルファイルで class → abstract class に手動で置換。 検証 : 本対応後に iOSビルド成功し、iOS Simulator(26.2)でアプリ起動を確認済。 8. retrofit / ParseErrorLogger 対応 対象 : retrofit パッケージをimportしているREST APIを実装したdartファイル(ex. rest_api.dart) 現象 : 旧 retrofit 4.1.0 + retrofit_generator 10.2.1 で生成したコードが型 ParseErrorLogger を参照するが、 package:retrofit/http.dart のみの import では参照できずコンパイルエラーになる 対応 : retrofit : ^4.1.0 → ^4.9.2 に更新（Dart 3.8 対応バージョン、ParseErrorLogger は package:retrofit/retrofit.dart で提供） rest_api.dart : import 'package:retrofit/retrofit.dart'; を追加し、生成コード（part ファイル）から ParseErrorLogger を参照可能にする。 package:retrofit/http.dart は retrofit.dart に含まれるため削除可 結果 : build_runner 再生成後も手動修正不要でビルド可能 9. Android 旧埋め込み (PluginRegistry.Registrar) 削除対応 Flutter 3.38 では v1 Android 埋め込み API（ PluginRegistry.Registrar / registerWith ）が削除されている。以下のパッケージを更新済み。 path_provider : ^2.1.3 → ^2.1.5 （path_provider_android 2.2.5+ を要求し、v1 削除済み） shared_preferences : ^2.2.3 → ^2.3.4 （shared_preferences_android 2.2.3+ で v1 削除済み） url_launcher_android : ^6.0.38 → >=6.3.3 <6.3.27 （6.3.3 で v1 削除。6.3.27+ は androidx.browser 1.9.0 が AGP 8.9.1 を要求するため 6.3.26 以下に制限） compileSdkVersion : 34 → 36（path_provider_android 等が SDK 36 を要求。 app/build.gradle ） 10. iOS CocoaPods更新 iOS最小デプロイメントターゲットをiOS 13.0にFixしました。 platform :ios , ' 13.0 ' config.build_settings[ ' IPHONEOS_DEPLOYMENT_TARGET ' ] = ' 13.0 ' Flutter バージョン別 カート追加時パフォーマンス比較レポート 　新しいバージョンになったのでそれだけでどれだけ既存アプリのパフォーマンスにも影響を及ぼしたか気になったのでFlutter DevToolsでプロファイリングしてTimeline Eventsを3.24.1と3.38.9でベンチマーク比較してみました。 　以下は、 同じカート追加アクション で取得したDevToolsの計測データを用い、 Flutter 3.24.1 と Flutter 3.38.9 のパフォーマンスを比較したレポートです。 項目 Flutter 3.24.1 Flutter 3.38.9 総フレーム数 96 107 比較サマリー 指標 Flutter 3.24.1 Flutter 3.38.9 差分 傾向 平均FPS 19.8 fps 48.3 fps +28.5 fps ✅ 大幅改善 平均フレーム時間 50.47 ms 20.71 ms -29.76 ms ✅ 約59%短縮 平均ビルド時間 7.23 ms 1.25 ms -5.98 ms ✅ 約83%短縮 平均ラスター時間 26.86 ms 15.32 ms -11.54 ms ✅ 約43%短縮 平均Vsyncオーバーヘッド 5.96 ms 1.46 ms -4.50 ms ✅ 約75%短縮 最大フレーム時間 274.89 ms 85.51 ms -189.38 ms ✅ 約69%短縮 最大ビルド時間 115.16 ms 18.66 ms -96.50 ms ✅ 約84%短縮 最大ラスター時間 145.56 ms 41.46 ms -104.10 ms ✅ 約72%短縮 Janky率 100.0% 88.8% -11.2pt ✅ 改善 重度Jank率 (>33ms) 38.5% 4.7% -33.8pt ✅ 大幅改善 結論 Flutter 3.38.9 は 3.24.1 と比較して、カート追加時のパフォーマンスが全体的に大きく改善しています。 平均FPSが 19.8 → 48.3 と約2.4倍になり、体感の滑らかさが向上しています。 ビルド時間・ラスター時間・Vsyncオーバーヘッドのいずれも短縮。 最大フレーム時間は 274.89ms → 85.51ms（約69%短縮） と、改善が確認できます。 重度Jank率は 38.5% → 4.7% と約1/8に減少。 主な改善要因（推測） Flutterエンジン・Skiaの最適化 ビルドパイプラインの効率化（ビルド時間の大幅短縮） Vsyncまわりのオーバーヘッド低減 今後の検討 3.38.9 時点でも Janky率 88.8%、平均FPS 48.3 であり、60fps目標にはまだ余裕があります。 ラスターが主なボトルネックのため、画像最適化・RepaintBoundary・Clip削減などの施策を続けると、さらに改善の余地があります。 まとめ 　本ブログでは、Android15以降でサポートされている16KBページサイズに対応するためFlutterのバージョンを3.38系にアップグレードすると既存アプリにどのような影響を及ぼすことになるかについてお話ししました。 　一旦は、両OSともビルドが成功してアプリ起動までは確認が取れたのでこれから5月31日まであまり日がないですが以下のようなThe next stepsに基づいて進めていく予定であることをお知らせして結びとさせていただきます。 1. テスト 単体テストの実行 統合テストの実行 手動テスト（特にデータベース操作とGraphQL操作） 2. iOS 11-12ユーザーへの対応検討 アプリストアで古いバージョンを継続提供 ユーザーへの事前通知 段階的な移行計画 最後に エブリーでは、ともに働く仲間を募集しています。 テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！ corp.every.tv

はじめに こんにちは、リテールハブ開発部の杉森です。 近年、AIを活用した開発ツールが急速に普及しています。私たちのチームでも積極的にAIツールを導入し、要件定義でのユーザーストーリー作成、設計ドキュメントの生成、コードの自動補完、テストコードの生成など、各開発フェーズの作業効率化を図ってきました。 しかし、個々の作業は確かに早くなっているのに、プロダクト開発フロー全体を見ると期待したほどの生産性向上を実感できないという課題に直面しました。 本記事では、この課題に対するアプローチとして導入を検討しているAI-DLC（AI-Driven Development Lifecycle）について紹介します。 AI-DLCとは AI-DLCは、AWSが提唱するAIネイティブな開発方法論です。方法論のホワイトペーパーで理論的な枠組みが定義されており、これを実装するためのワークフローがaidlc-workflowsとしてGitHub上で公開されています。 AWSの公式ブログでは、現在のAI活用における2つのアンチパターンが指摘されています。 AI-Assisted: 人間が設計を主導し、AIはコード補完など狭い範囲の支援にとどまる。生産性向上は限定的で、AIの能力を十分に引き出せない AI-Managed: 複雑な問題をAIに丸投げし、自律的にすべてを解決することを期待する。出発点が曖昧なためAIが多くの仮定を立て、プロトタイプ以外ではほぼ機能しない AI-DLCは、これらのアンチパターンに対するアプローチとして設計されています。AIが作業計画の作成やタスク分解を主導し、人間がその内容を検証・承認し、AIが承認された計画に基づいて実行するというサイクルで、開発ライフサイクル全体を進めます。 AI駆動開発ライフサイクル（AWS公式ブログ） aidlc-workflows（GitHub） 従来の開発手法との違い AI-DLCは、既存の開発手法にAIを後付けするのではなく、AIを前提とした開発プロセスをゼロから設計しています。ホワイトペーパーでは、以下の設計思想が示されています。 AIが会話を主導する: 従来は人間がAIに指示を出していたが、AI-DLCではAIがタスク分解や提案を行い、人間は承認・判断に集中する Intent / Unit / Bolt: ビジネス目標（Intent）を作業単位（Unit）に分解し、数時間〜数日の短いサイクル（Bolt）で実装を回す。ScrumのSprintに近いが、サイクルが短い 各ステップで人間がチェックする: AIの出力を段階ごとに検証し、誤りを早期に検出する。ホワイトペーパーでは「損失関数のように機能する」と表現されている 設計技法を方法論に組み込む: ScrumやKanbanがチームに委ねていたDDD等の設計技法を、方法論の一部として標準化する aidlc-workflowsの設計原則 aidlc-workflowsは、上記の設計思想を実装するにあたり、以下の5つの設計原則に基づいています。 原則 説明 No Duplication 設定やルールを一箇所で管理し、重複を排除する Methodology First 特定のツールに縛られず、方法論そのものを軸にする Reproducible ルールを明文化し、使うAIモデルが変わっても結果がぶれないようにする Agnostic IDE・エージェント・モデルを問わず動作する Human in the Loop 重要な判断には必ず人間の承認を挟む 3フェーズ構成 AI-DLCは、以下の3つのフェーズで構成されています。 INCEPTION PHASE: WHATとWHYの決定 CONSTRUCTION PHASE: HOWの実装 OPERATIONS PHASE: デプロイと監視（aidlc-workflows上は未実装） INCEPTION PHASE 「何を作るか（WHAT）」「なぜ作るか（WHY）」を決定するフェーズです。方法論のホワイトペーパーでは「Mob Elaboration」というプラクティスとして定義されており、共有画面を使ってチーム全体でAIの質問と提案を検証します。AIがビジネス意図（Intent）を明確化する質問を投げかけ、ユーザーストーリー、非機能要件、リスク記述を生成し、凝集度の高い作業単位（Unit）へ分割します。 aidlc-workflowsでは、このフェーズが以下のステージに細分化されています。 ステージ 説明 Workspace Detection プロジェクトの状態を分析（新規/既存の判定） Reverse Engineering 既存コードベースの理解（Brownfieldの場合） Requirements Analysis 要件の収集と整理 User Stories ユーザーストーリーの作成 Workflow Planning 実行計画の策定 Application Design アプリケーション設計 Units Generation 作業単位への分割 CONSTRUCTION PHASE 「どう作るか（HOW）」を決定し、実際にコードを生成するフェーズです。方法論のホワイトペーパーでは、Domain Design（ビジネスロジックのドメインモデリング）→ Logical Design（非機能要件を含むアーキテクチャ設計）→ Code & Unit Tests（コードとテストの生成）→ Deployment Units（デプロイ可能な成果物の構築）という流れで進みます。「Mob Construction」でチームがリアルタイムで技術的決定とアーキテクチャの選択を行います。 aidlc-workflowsでは、このフェーズが以下のステージに細分化されています。 ステージ 説明 Functional Design 機能設計（ユニットごと） NFR Requirements/Design 非機能要件の設計 Infrastructure Design インフラ設計 Code Generation コード生成 Build and Test ビルドとテスト OPERATIONS PHASE デプロイと監視を担当するフェーズです。方法論としては定義されていますが、aidlc-workflowsには含まれておらず、将来的にワークフローが追加される予定です。 対応プラットフォーム 公式では以下のプラットフォームがサポートされています。 Kiro CLI Amazon Q Developer IDE plugin Kiro IDE（Coming Soon） 試してみる 導入の背景 私たちのチームの課題は、まさにAI-Assistedパターンに該当します。AIを個々の作業の効率化には活用できているものの、生産性向上は限定的にとどまっていました。 私たちのチームでは、Kiro CLIをすぐに使える環境ではなかったため、Claude Code向けにカスタマイズして使用しました。AI-DLCはツールに依存しない設計を謳っているため、ルールファイルを調整すれば他のAIツールでも問題なく適用できると考えています。 Claude Code向けのカスタマイズ 以下のようにClaude Code向けにカスタマイズしました。 1. カスタムコマンド（スキル）の作成 .claude/commands/aidlc.md にワークフロー定義を配置し、 /aidlc コマンドで起動できるようにしました。 .claude/ ├── commands/ │ ├── aidlc.md # メインワークフロー │ ├── aidlc-pr.md # PR作成用 │ └── aidlc-archive.md # アーカイブ用 └── aidlc-rule-details/ ├── common/ # 共通ルール ├── inception/ # INCEPTIONフェーズ ├── construction/ # CONSTRUCTIONフェーズ └── operations/ # OPERATIONSフェーズ 2. ルールファイルの分割 各ステージの詳細指示を .claude/aidlc-rule-details/ 以下に分割配置しています。これにより、AIが必要なタイミングで必要なルールのみを読み込み、コンテキストを効率的に使用できます。 クーポン機能を題材にした検証 AI-DLCの有効性を検証するため、小売向けアプリのクーポン機能開発を題材に検証を実施しました。 検証概要 対象システム: Flutter + Laravel + Vue.js + Goで構成されたマルチプラットフォームアプリ 題材: ポイント後付けクーポンと即時値引きクーポンの2種類 検証範囲: モバイルアプリ、管理画面、バックエンドAPI、バッチ処理 チーム構成: PdM1人+エンジニア2人 検証の進め方 「クーポン機能を追加したい」というビジネス意図（Intent）を起点に、AI-DLCのフェーズに沿って進めました。 INCEPTION PHASE（3人で実施）: AIが要件を深掘りする質問を投げかけ、ユーザーストーリーや非機能要件を生成。PdMとエンジニアがその内容を検証・修正し、作業単位（Unit）に分割 CONSTRUCTION PHASE（1人で実施）: Unitごとにドメイン設計、コード生成、テスト生成を実施。各ステージでAIの出力を確認し、承認・修正を繰り返した 今回は検証目的だったこともあり、各フェーズ半日ずつの計1日で実際に動くものまで作成できました。Inceptionフェーズの要件・設計をより作り込み、Constructionフェーズではガードレールの整備やAIが自律的に改善できる体制を組むことで、さらに短縮できる余地があると感じています。 実際の様子 AIからの深掘り質問（Inceptionフェーズ） Requirements Analysisでは、AIが要件の曖昧な部分を選択肢付きで質問してきます。以下はその一例です。 AI : クーポン利用状態の管理について確認させてください。ユーザーがクーポンを「利用」した後の状態管理はどうなりますか？ A) 1回利用したら即座に使用済みになる（再利用不可） B) 有効期限内であれば何度でも利用可能 C) クーポンごとに利用回数を設定可能（1回、3回、無制限など） AI : クーポンの種類と適用範囲について確認させてください。 A) 全ての種類が両方のクーポンタイプで使用可能 B) クーポンタイプごとに使用可能な種類が決まっている このように、AIが仕様の選択肢を提示し、人間が判断するというサイクルでRequirements Analysisが進みます。初回の質問10問、追加の深掘り質問6問を経て、要件定義ドキュメントが生成されました。 人間による設計修正（Inceptionフェーズ） Application Designでは、AIが設計の選択肢を提示し、人間が判断するケースがありました。 人間 : アクティブユーザーではないユーザーにもレコードが作成されてしまいませんか？ AI : 2つの選択肢があります。 A) クーポン公開時に全ユーザー分のuser_couponsレコードを作成 B) クーポン利用開始時にのみuser_couponsレコードを作成 人間 : B 生成されたユーザーストーリー（Inceptionフェーズ） User Storiesでは、管理者向け6件、会員ユーザー向け6件、システム向け1件の計13件が生成されました。以下はその一部です。 US-01: クーポン新規作成 As a 管理者 I want to 管理画面から新しいクーポンを作成したい So that 会員ユーザーに対してキャンペーンを提供できる Acceptance Criteria: クーポンタイプ（ポイント後付け/即時値引き）を選択できる クーポン名と説明文を入力できる 有効期限（開始日・終了日）を設定できる 対象店舗を選択できる 生成されたコード（Constructionフェーズ） Constructionフェーズでは、Unitごとにドメイン設計 → コード生成 → テスト生成が進みます。最終的に以下の規模のコードが生成されました。 Unit 対象 生成ファイル数 主な成果物 Backend Laravel 51ファイル Enum, Model, Migration, Service, Controller, Test Dashboard Vue.js 16ファイル Composable, Component, Schema, Page Mobile Flutter 38ファイル Entity, Repository, Provider, Widget, Page わかったこと / 今後の展望 良いと感じた点 実際にAI-DLCを触ってみて、以下の点が良いと感じました。 Human in the Loopの実現: AIが実行し、人間が監視するという関係性が明確。各ステージで人間の承認が必要なため、重要な意思決定は人間がコントロールできる コンテキストの保存と再開: aidlc-state.md でプロジェクトの状態を追跡しているため、セッションが途切れても前回の続きから再開できる ドキュメント化による追跡可能性: audit.md にすべてのやり取りが記録されるため、なぜその決定をしたのかを後から追跡できる 適応的なワークフロー: プロジェクトの複雑さに応じて、実行するステージが自動的に調整される 試した上で見つかった課題 Inception前の準備の必要性 今回「クーポン機能を追加したい」というリクエストからInceptionを開始しましたが、背景知識や「なぜこの機能が必要なのか」がアウトプットに反映されにくいことがわかりました。また、要件の解像度が低い状態でInceptionを始めると、議論が発散しやすくなります AI-DLCのInceptionに入る前に、ビジネス背景や目的を整理するステップが必要だと感じました。 仕様とAI実装のギャップ Inceptionフェーズで仕様を決め切った上でも、以下の2つの問題が発生しました。 仕様の記載漏れ: Inceptionフェーズで決めた仕様に漏れがあり、Constructionフェーズで初めて気づくケース。例えば、APIレスポンスのラッパー形式やお気に入り店舗のパラメータなど、実装段階で判明した考慮漏れがありました 仕様通りに実装されない: 仕様として記載されているにもかかわらず、AIが異なる実装をするケース。例えば、既存の認証方式と異なるパターンで実装したり、既存のアーキテクチャパターンに従わない実装が生成されることがありました 前者は要件定義やアプリケーション設計の精度を上げていく必要があります。今回検証だったので細部まで確認できていないところがありました。そのため、実業務に導入した場合はよりこの部分に時間を使うべきだと思いました。 後者はモデルの進化を待ちつつ、コンテキストの渡し方の工夫や、実装が仕様に準拠しているかを監査するサブエージェントの整備など、ガードレールを張っていくことが必要だと感じました。 コンテキスト管理の課題 AIツール固有の課題として、コンテキスト管理の難しさがあります。実装フェーズではコードの読み書きが多く発生するため、auto-compact（コンテキストの自動圧縮）が頻発しました。その結果、audit.mdへの書き込みが不安定になったり、要件定義ファイルへの指摘を繰り返してもアウトプットに反映されないことがありました。 対策として、コンテキストの使用量を抑えるためにルールファイルを分割して必要なタイミングでのみ読み込む方式にしたり、サブエージェントを活用して処理を分散させるなどの工夫が必要です。 レビュー負荷への対応 AIのアウトプット量が増えることで、人間のレビュー負荷が増大するという課題があります。この課題に対しては、以下のアプローチを検討しています。 レビューを軽減するプロセスの構築: 自動テストやLintの活用 AIの出力品質を上げる工夫: プロンプトの改善、ルールの整備 段階的なレビュー: 各ステージでの承認による分散 これらの最適解は、チームやプロダクトによって異なるため、継続的に改善していく必要があります。 最後に AI-DLCは、AIを活用した開発における「ボトルネックを特定し、解消していく」ためのフレームワークとして有望だと感じています。 今回見えてきた課題はAI-DLCのフレームワーク自体の問題ではなく、AIと人間が協働する上で必然的に発生する問題です。今後も継続的に活用しながら、チームに最適な形にカスタマイズしていきたいと考えています。

こんにちは。 ファインディ株式会社でソフトウェアエンジニアをしている西村です。 普段私たちが開発しているファインディのプロダクトの裏側や、開発メンバーが日々どのように働いているのかをお伝えするために、Findy Tech Talkという技術系のオフラインイベントを開催しています。 その第一弾となる 「開発メンバーが語るFindy Conferenceの裏側とこれから」を開催しました！ findy-inc.connpass.com 今回は3名が登壇し、Findy Conferenceを支える技術基盤（受付システム・GraphQL設計・権限管理）、開発前に「適切なツッコミ」を入れて最速で価値を届けるアプローチ、そしてFindy初のモバイルアプリをReact Nativeで立ち上げた経緯について話しました。 この記事では、各登壇の内容をダイジェストでお届けします。 登壇内容 Findy Conferenceを支える技術基盤の裏側 最速で価値を出すためのプロダクトエンジニアのツッコミ術 ゼロから始めた Findy 初のモバイルアプリ開発 まとめ 登壇内容 Findy Conferenceを支える技術基盤の裏側 西村は「Findy Conferenceを支える技術基盤の裏側」と題して、話しました。 Findy Conferenceとは、カンファレンスの準備・開催・運営の管理プラットフォームであり、3つの立場が異なるユーザーが使うシステムです。 主催者 参加者 スポンサー企業 異なる立場のユーザーが使うシステムであるため、各ユーザーに応じた機能を提供しつつ、円滑なカンファレンス運営を支援することが求められます。 カンファレンスを開催するまでにある課題を3つに絞って紹介します。 1つ目は、ネットワークが不安定でも止めない参加者受付機能です。 当日の会場では常にネットワークが安定しているとは限りません。例えば、多数の参加者が一斉にWi-Fiへ接続を試みるため、ネットワークが不安定になりがちです。 参加者の入場処理が失敗してしまい、記録が正しく行えなくなります。また、受付スタッフは通常の受付業務ができなくなり、カンファレンスの運営に影響が出てしまう。 そこで、Findy Conferenceでは、受付した参加者のデータをLocalStorageに保存する設計を採用しました。 navigator.onLine でネットワーク接続を検知し、復旧次第バックエンドへ同期する仕組みです。 ネットワークが不安定な環境でも、受付業務を止めることなくスムーズに入場記録を行えるようになりました。 2つ目は、Findy Conferenceに合うGraphQLスキーマ設計についてです。 冒頭で書いた通り、3つの異なる立場のユーザーが存在します。 Findy Conferenceでは、主催者・参加者・スポンサー企業の画面をサブドメインで分けています。 そのため、GraphQLのスキーマ設計においても、各ユーザーが必要とするデータを効率的に取得・権限管理できるように工夫が必要でした。 そこで、Findy Conferenceでは、次のような設計方針を採用しました。 このスキーマ設計によって、後述する権限管理を容易にし、各ユーザーが必要とするデータを効率的に取得できるようにしています。 3つ目は、GraphQLでどのように権限管理するのかについてです。 Findy Conferenceでは主催者画面にユーザーロールごとに権限管理しています。 GraphQLでは カスタムディレクティブ を使うことで簡単に権限管理をすることができます。 Findy Conferenceでは @auth のディレクティブを使い、次のように権限管理を表現しています。 module Types module Admin class Conference < Types :: Admin :: BaseObject field :id , Int , null : false field :conference_participated_users , Types :: Admin :: ConferenceParticipatedUser .pagination_type, directives : { :: Directives :: Admin :: Auth => { roles : [ FULL_ACCESS , VIEW_ONLY ] } } end end end このRubyコードをGraphQLのスキーマに変換すると次のものになり、 @auth のディレクティブが使われていることを確認できます。 """ カンファレンスID """ id : Int ! """ カンファレンス参加者情報 """ conferenceParticipatedUser ( """ カンファレンス参加者ID """ id : Int ): ConferenceParticipatedUser @ auth ( roles : [ "full_access" , "view_only" ] ) 以上、3つの課題をもとに、Findy Conferenceをどう開発してきたかを少しでも伝われば幸いです。 今後もカンファレンスを裏から支え続けるプロダクトとして成長していきます。 最速で価値を出すためのプロダクトエンジニアのツッコミ術 エンジニアマネージャーの大原が「最速で価値を出すためのプロダクトエンジニアのツッコミ術」と題し、迅速にユーザーに価値を届けるための開発前のアプローチについて紹介しました。 迅速にユーザーへ価値を届けるには、開発前にロードマップや企画に対して「適切なツッコミ」を入れることが重要だと思います。 ツッコミなしで進めると「機能が増えてリリースが遅れる」「使われない機能になる」といった問題が生じてしまいます。 そのツッコミを入れる際の重要な観点として、2つの視点を紹介しました。 1つ目は「 目的達成のための最小工数になっているか 」です。 要望があったときに、実装を想像して、仕様を分解し、どれくらい工数がかかるかを考えます。 その上で、本当に今必要か、使用頻度は高いかなどを検討し、仕様を最小限必要なものにブラッシュアップしていきます。 具体例として、Findy Conferenceでは、参加申込→当日運営→運用・拡大と機能を最小限にして段階的にリリースすることで、短期でのリリースを達成しました。 2つ目は「 三方よしになっているか 」です。 施策や機能を考えるときに、ユーザー、自社、関係者にとって良いものかを確認し、自社都合のみの施策や利害不一致を避けることが大事です。 ユーザー体験が向上し、その結果事業にインパクトが出るような施策が理想だと考えています。 最後に、ツッコミの質を高めるために大事なこととして、次の3つを挙げました。 仕様・実装を把握し、技術的な制約を即座に指摘出来るようにする ユーザーの声を聞くことで、ユーザー課題の解像度を上げる 事業モデルを理解することで、事業インパクトを理解出来るようにする 今後もこういった観点を大事にしながら、最速で価値のあるサービスを提供していきたいと思います。 ゼロから始めた Findy 初のモバイルアプリ開発 モバイルエンジニアの加藤が「ゼロから始めた Findy 初のモバイルアプリ開発」と題し、当社初のモバイルアプリ「 Findy Events 」の立ち上げについて紹介しました。 まず、私達がどのような思想でモバイルアプリ開発を始めるに至ったのか、その背景についてです。 AIの進化が目覚ましい昨今だからこそ、オフラインの場でしか手に入らない生きた情報や、かけがえのないつながりがあると考えました。 そこで、「 オフラインにおけるつながりを最大化し、エンジニア同士の知識・経験の共有を促進する 」ことをモバイルアプリが提供する本質的な価値と位置づけました。 次に、このアプリを0→1で立ち上げるために挑戦した具体的なプロセスについて話をしました。 開発当初、社内にモバイルアプリ開発の実績がなく、現役のモバイルエンジニアも自身一人だけという状況でした。 そのため、要求&要件定義や技術選定だけでなく、社内での開発環境・管理ルールの策定といった土台作りから始める必要がありました。 要求&要件定義では、エンジニアとして、企画のすり合わせから、UI・UXの議論まで深く入り込み、徹底してモバイルアプリならではの体験作りに拘りました。 これは、エンジニア向けのプロダクトを開発しているファインディだからこそ、利用ユーザー目線での解像度の高い意見を出すことができたのだと思います。 また、モバイルアプリ開発のためのメインフレームワークの選定についても紹介しました。 チーム全体のリソースを鑑みて、Cross Platformによる開発を前提としたものの、「Flutter」と「React Native」のどちらを選定すべきなのかは非常に悩んだポイントです。 次のように、国内での採用事例数やモバイルエンジニアとしての習熟のしやすさなど、いくつかの指標を比較することから始めましたが、最終的には「組織のアセット」×「モバイルエンジニアとしての自身のナレッジ」を活かせる「React Native」を採択しました。 この選定により、立ち上がりに苦労した部分もありましたが、次の2点のような大きな収穫があったため、Betterな選択ができたと考えています。 Webフロントエンドの有識者による質の高いレビューを通じて、多くの学びを得ることができた Webフロントエンドと親和性の高い技術の理解が進んだことで、他のWebフロントエンドのコードが読めるようになった また、2025年12月に、Android版をリリースし、「 Findyユーザー感謝祭2025〜今年の"しくじり"を供養しよう〜 」で実際に触って頂きました。 直接、ユーザーの操作を見たり、感想やご意見を頂けたことで、「伸びしろ」を感じることができました。 今後は、「ユーザーが迷わないUI・UXを突き詰めて、その利便性から、自然とアプリを利用してもらえる」そんなアプリへと、成長させていきたいと考えています。 まとめ 今回のFindy Tech Talkでは、Findy Conferenceを支える技術基盤、プロダクトエンジニアとしてのツッコミ術、そしてモバイルアプリ開発の立ち上げについてお話ししました。 当日、イベントに足を運んでくださった参加者のみなさん、本当にありがとうございました。頂いたアンケート結果を、次回開催の参考とさせていただきます。 残念ながら今回のイベントに参加出来なかったみなさんも、次回イベント開催時には是非ご参加ください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからご覧ください。 herp.careers