ノーコード・ローコード・AI支援型コード主体開発を、UI/UX・検収品質・操作応答時間から分析
micomia株式会社（本社：兵庫県神戸市、代表取締役：畑井 駿佑）は、アプリ・Webシステム9事例をもとに、ノーコード・ローコード・AI支援型コード主体開発の特徴を比較した独自調査レポート「UI/UXを軸としたアプリ開発方式の比較調査」を執筆しました。
本調査では、単に「開発できるか」「初期開発をどれだけ短縮できるか」だけではなく、実際の商用アプリ・システムにおいて重要となるUI/UX、検収時の品質、運用後の改善性、処理速度などの観点から開発方式を整理しています。
9事例のうち、検収記録を比較可能な8事例について不具合件数や傾向を集計しました。さらに、Firebaseを共通バックエンドとしてFlutterFlow、Bubble、Flutter、Reactで同等の簡易アプリを構築し、同じデータ操作を行った場合の操作応答時間も比較しています。
本リリースでは調査結果の概要を公開します。
個別事例の詳細、不具合の分類、開発方式ごとの考察、コード主体へ移行した事例、調査上の限界などを含むレポート全文は一般公開せず、micomia公式サイト「資料請求」からお申し込みいただいた方へ提供します。
資料請求：https://micomia.com/download
■調査の背景
アプリやWebシステムを開発する方法は、以前より大きく増えています。
FlutterやReactなどを利用してコードを記述する開発に加えて、FlutterFlowやBubbleなど、画面上の操作を中心にアプリケーションを構築できるノーコード・ローコードツールも利用されています。
さらに近年では、生成AIを技術調査やコード作成、テスト、不具合調査などに活用しながら、コード主体で開発する方法も選択肢の一つになっています。
一方で、システムやアプリを発注する企業側から見ると、それぞれの違いを開発前に判断することは簡単ではありません。
「ノーコード・ローコードとスクラッチ開発は何が違うのか」
「ローコードでも商用サービスを長期間運用できるのか」
「初期開発費を抑えることと、将来的な保守性をどのように考えるべきか」
「生成AIを使った開発では、品質や開発効率はどう変わるのか」
こうした疑問に対し、開発費や開発期間だけではなく、実際の運用まで含めた情報が必要だと考えました。
商用アプリでは、開発が完了した後も、多様な端末やOS、文字サイズ、通信環境への対応、認証、外部API、データ保存、通知、決済、エラー発生時の復旧などが必要になります。
機能一覧上では「実装済み」であっても、操作のたびに待ち時間が発生する、保存したデータが反映されない、エラーの理由が利用者に伝わらない、特定の利用環境だけで正常に動作しないといった問題が残れば、利用者が受ける体験は大きく変わります。
そこでmicomiaでは、開発方式によってどのような違いが確認されたのかを整理しました。
■今回の調査について
本調査は、比較調査のために各アプリを新たに開発したものではありません。
当社が実際に開発、移管、保守または改修に関与した商用アプリ・Webシステムについて、案件の開発経緯、顧客から受領した検収報告、Issue管理記録、技術的な制約、移行判断、調査時点の運用状況などを後から整理した複数事例調査です。
対象とした実務事例は9案件で、そのうち検収記録を比較可能な8案件について、不具合件数や不具合の種類を整理しました。
また、実案件同士では機能規模や技術構成が異なるため、処理速度については別途、条件を統一した簡易アプリによる比較を実施しています。
主な比較対象は、ノーコード・ローコードを利用した開発と、AI支援型を含むコード主体開発です。
なお、顧客情報および案件情報保護の観点から、企業名、サービス名、業界、利用規模、特徴的な機能、画面、検収記録など、特定につながる情報を開示できかねますのであらかじめご了承ください。
■調査結果１. 検収記録を確認できた8事例を比較
検収記録を取得できた8案件について、不具合を整理しました。
集計時には、追加機能の要望、顧客都合による仕様変更、後から撤回された指摘、操作上の誤認などを不具合から除外し、合意した仕様どおりに動作しないものや、保存・表示・認証・外部連携などに問題があるものを対象としています。
今回対象とした4件のノーコード・ローコード利用案件では、厳密な不具合件数の合計が44件、1案件あたりの平均が11.0件、中央値が9.0件となりました。
一方、AI支援型コード主体開発4案件では、厳密な不具合件数の合計が10件、1案件あたりの平均が2.5件、中央値が0.5件となりました。
ただし、この数字だけをもって「コード主体で開発すれば不具合が減る」と結論付けることはできません。
各案件では機能数、複雑性、担当エンジニア、顧客側の検収範囲、検収期間、記録方法などが異なります。
また、AI支援型コード主体開発の一部案件は同じ実装者が担当しているため、開発方式だけでなく、担当者の経験や設計・テスト方法が結果へ影響している可能性があります。
そのため、本調査では不具合件数を品質の参考指標として扱い、件数だけでなく、不具合の内容や発生後に原因を追跡・修正できたかについても確認しています。
■調査結果２. データの保存・取得・更新などが主要な品質課題に
詳細な不具合内容を共通基準で分類できた事例では、データの作成・取得・更新・削除などに関連する「データ・CRUD」の問題が多く確認されました。
そのほかにも、認証・権限、UI・操作性、UI・表示、入力制御・業務ロジック、外部サービス連携、パフォーマンス・安定性など、複数のカテゴリにわたる問題が確認されています。
アプリ・システムでは、単純に「データを保存する機能が存在する」だけでは十分ではありません。
保存した内容が正しく画面へ反映されること、認証状態が適切に管理されること、APIやデータベースから取得した結果が利用者へ正しく表示されること、処理に失敗した場合にエラー内容や次に行う操作が理解できることまで含めて、ユーザー体験が構成されます。
特に実際の利用者が増えると、開発中には確認できなかった端末差や設定差、通信環境などによって問題が顕在化する場合があります。
本調査では、UI/UXを画面の見た目だけではなく、保存・表示の確実性、応答速度、エラーからの回復、端末差への適応、継続的に改善できる状態まで含めて評価しています。
■調査結果３. 「不具合が発生しないこと」だけでなく「修正できる状態」が重要
今回の事例では、ノーコード・ローコードからコード主体へ移行した案件も複数確認しています。
移行理由は案件ごとに異なり、画面表示、データ処理、外部サービス連携、操作時の待ち時間、端末差への対応など、複数の要因がありました。
ここで、本調査では「コード主体へ移行すれば不具合が発生しなくなる」とは考えていません。
コード主体の開発でも、設計や実装上の判断によって不具合は発生します。
一方で、不具合が発生した場合に、どの処理で問題が起きているかを調査し、状態管理やエラー処理、データ取得、外部連携などをコードとして確認しながら修正できることは、継続的な運用において重要になります。
特に、長期間サービスを運営しながら機能追加を続ける場合には、単に現在動いていることだけでなく、数か月後、数年後にも原因調査や改修を継続できるかという視点が必要です。
■調査結果４. 同じFirebaseでもフロントエンドによって操作応答時間に差
実案件では、アプリごとにバックエンド、データ量、機能、利用端末などが異なるため、そのまま処理速度を比較することはできません。
そこで本調査では、別途簡易的な検証用アプリを作成しました。
FlutterFlow、Bubble、Flutter、Reactの4方式で同等のアプリを構築し、バックエンドにはすべてFirebaseを使用しています。
FlutterFlowとFlutterはモバイルアプリを開発する際の選択肢として、BubbleとReactはWebシステムを開発する際の選択肢として比較しました。
今回この組み合わせを採用したのは、クライアント側でどの開発媒体を採用するかによって、同一のデータ処理でも利用者が体感する操作速度に差が生じるかを確認するためです。
検証用アプリは一画面で構成し、テキストの登録、保存済みデータの一覧表示、編集、削除ができるシンプルな仕様としました。
バックエンドはすべてFirebase、ネットワークは同じ会社Wi-Fiを使用しています。
計測対象はCreate、Update、Deleteの3操作で、それぞれ同一条件で5回ずつ計測しました。
BubbleおよびFlutterFlow側で自動計測を実装する場合、計測処理自体の実装や正確性を検証するための追加工数が必要となるため、今回は方式間の条件を統一する目的ですべて手動計測としています。
■操作応答時間の中央値
[表1: https://prtimes.jp/data/corp/168594/table/8_1_b21b5760dc0c4a5154c33602e388c4f9.jpg?v=202608121545 ]
モバイルアプリ動作比較
モバイルアプリ開発の比較では、FlutterFlowの中央値がCreate 0.96秒、Update 1.03秒、Delete 0.98秒でした。Flutterでは、Create 0.106秒、Update 0.085秒、Delete 0.086秒でした。
[表2: https://prtimes.jp/data/corp/168594/table/8_2_baf11b1201e800a0165b59c5966fe830.jpg?v=202608121545 ]
Webアプリ動作比較
Web開発の比較では、Bubbleの中央値がCreate 0.86秒、Update 0.89秒、Delete 0.88秒でした。
Reactでは、Create 0.128秒、Update 0.122秒、Delete 0.102秒でした。
今回の条件では、FlutterおよびReactの方が、FlutterFlowおよびBubbleより短い操作応答時間となりました。
バックエンドをFirebaseに統一した小規模な一画面アプリでも差が確認されたことから、バックエンドだけではなく、フロントエンドの開発方式や画面反映処理も利用者が感じる速度に影響する可能性が示されました。
一方、この結果には注意が必要です。
今回は同一会社Wi-Fi環境で、各方式・各操作を5回ずつ手動計測した簡易的な比較です。
異なる端末、ブラウザ、ネットワーク、データ量などを網羅したものではありませんので、今回得られた数字をFlutterFlow、Bubble、Flutter、Reactそれぞれの一般的・普遍的な性能値として扱うことはできません。
本調査では、実案件で確認されていた操作時の待ち時間を補足するための、統一条件下における探索的な比較データとして位置付けています。
■ノーコード・ローコードを否定する調査ではありません
今回の調査は、ノーコード・ローコードそのものを否定することを目的としていません。
標準的な機能を短期間で構築したい場合、PoCやMVPとして仮説検証を優先する場合、利用者が限定される業務ツールなどでは、ノーコード・ローコードが合理的な選択肢になる場合があります。
実際に先行研究では、FlutterFlowを利用することでクライアント側の開発工数を大きく削減できる可能性も確認されています。
一方で、利用期間が長くなる、利用者が増える、外部サービスとの連携が複雑になる、状態管理が増える、独自UIが必要になる、即時性が求められる、継続的な追加開発を行うといった条件では、選択時に確認すべき項目が増えていきます。
重要なのは、開発方式そのものに優劣を付けることではなく、サービスの性質や将来的な運用を踏まえて選択することだと考えています。
■AI支援型コード主体開発について
今回の調査では、当初から生成AIを開発工程へ取り入れながらコード主体で開発した案件についても対象としました。
ここでいうAI支援型コード主体開発は、プロンプトを入力してAIが生成したアプリをそのまま利用する方式とは異なります。
従来からコード開発を行っているエンジニアが、技術調査、コード生成、リファクタリング、テスト観点の整理、不具合調査などにAIを利用しながら、要件、設計、レビュー、テスト、セキュリティ確認、本番反映については人が管理する方式です。
AI支援型コード主体開発の案件でも不具合は発生しており、AIを利用するだけで品質が保証されるものではありません。
重要なのは、AIが出力したコードを開発者が理解できること、必要に応じて修正できること、システム全体を管理可能な状態に保つことです。
生成AIによって「コードを書く時間」だけを見るのではなく、要件整理、設計、レビュー、テスト、修正、セキュリティ確認、本番投入まで含めた「商用品質へ到達するまでの総工数」で評価する必要があると考えています。
■今回の調査から考えるアプリ開発方式の選び方
本調査では、開発方式の選択にあたって、予算や納期だけではなく、利用期間、利用規模、外部連携、状態管理、性能要件、UIの独自性、保守移管の可能性、障害発生時の事業への影響などを確認する必要があると整理しました。
短期間の仮説検証であれば、ノーコード・ローコードを利用して市場へ早く提供することが合理的な場合があります。
一方、多数の利用者が長期間利用し、認証、通知、決済、AI、外部APIなどを組み合わせながら継続的に改善するサービスでは、アプリ固有の挙動をコードとして把握・制御できることの重要性が高まります。
今回の実務事例、検収記録、簡易的な処理速度比較からは、UI/UXを重視する商用アプリでは、
「作れるかどうか」だけではなく、「利用者が快適に使い続けられる状態を、継続的に維持・改善できるか」という観点で開発方式を選択することが重要であると考えています。
■レポート全文は資料請求者限定で提供
本リリースでは、調査結果の概要のみを公開しています。
レポート本編では、調査方法、不具合の集計基準、ノーコード・ローコード・コード主体開発の定義、FlutterFlow・Bubble・Adalo等の特徴、先行研究、匿名化した実務事例、検収時不具合の詳細分析、コード主体への移行事例、AI支援型コード主体開発の考察、処理速度の全計測結果、開発方式を選択するための判断基準、本調査の限界などを掲載しています。
顧客案件の不具合や開発状況に関する分析を含むことから、レポート全文はWeb上で一般公開しません。
「UI/UXを軸としたアプリ開発方式の比較調査」
発行：micomia株式会社
発行時期：2026年8月
形式：PDF
提供方法：資料請求者限定
資料請求はこちら：https://micomia.com/download
■今後について
今回の処理速度比較は、Firebaseを共通バックエンドとした簡易アプリによる初回の検証です。
今後は、計測回数の増加、自動計測、Read処理の測定、複数端末・ブラウザでの比較、ネットワーク条件の変更、データ件数を増加させた場合の比較など、条件を広げた検証を予定しています。
micomiaでは、アプリ・システム開発会社として実際の商用案件から得られた知見に加え、可能な範囲で定量的な検証データを蓄積し、発注企業が自社のサービスに適した開発方式を判断するための情報を継続して発信してまいります。
■micomia株式会社について
micomia株式会社は、兵庫県神戸市を拠点に、スマートフォンアプリ、Webシステム、AI機能、Webサイトなどの企画・設計・開発を行う開発会社です。
要件整理からUI/UX設計、実装、テスト、リリース、公開後の保守・追加開発まで一貫して支援しています。
会社名：micomia株式会社
代表者：代表取締役 畑井 駿佑
所在地：兵庫県神戸市中央区磯辺通4丁目1-8 ITCビル4F
事業内容：アプリ開発、システム開発、AI開発、Webサイト制作
公式サイトURL：https://micomia.com/
レポート資料請求URL：https://micomia.com/download