アプリの導入/開発事例や活用/成功事例について

実在企業のアプリ事例は、技術選定や投資判断の精度を高める材料になります。発注企業の視点で見ると、導入・開発・活用の事例から、技術形態や言語の選び方と着手点の考え方を読み取れます。全体像はアプリ開発の完全ガイドもご覧ください。

ネイティブからハイブリッド統合へ移行した事例

アプリ開発費は、手法・対応OS・機能規模によって300万円規模から3,000万円規模まで変わります。技術形態を後から変えると、二重運用コストが発生することもあるため、最初の選定は慎重に行う必要があります。

ネイティブで作ったアプリをFlutterへ移し、コア機能はネイティブに残す方法がハイブリッド統合です。二者択一ではなく、両者の利点を組み合わせる選択肢として捉えられます。

ING銀行の認証をネイティブに残した移行事例

INGホールセールバンキングの法人向けアプリ「InsideBusiness App」は、月間4.2万人を超える法人ユーザーに使われています(出典:学術ケーススタディ)。同社は、機能ごとに技術形態を分けました。

  • UI:iOSとAndroidのネイティブアプリからFlutterへの移行。
  • 認証:mTokenなど重要機能は、ネイティブSDKの継続利用。

これにより、UIの開発効率を高めつつ、銀行アプリに必要なセキュリティと性能を保てます。

アプリ容量の肥大化を受け入れた判断

ハイブリッド統合では、アプリの容量が増えるという代償がありました。移行後は、iOSが40.1MBから79MBへ、Androidが29.2MBから141MBへ増えています(出典:学術ケーススタディ)。

クロスプラットフォームのフレームワークは独自の描画エンジンを含むため、ネイティブに比べて容量が増える傾向があります。別の学術研究では、単純なiOSアプリがSwiftで1.3MB、Flutterで28.5MBでした。その差は約22倍です。

容量の増加を受け入れた背景には、開発効率と、ユーザーが重視する条件を照らし合わせた判断がありました。

  • 保守効率:二つのOSのUIを単一コードにまとめて扱える利点を、ING銀行が重視した点。
  • 利用者の重視点:容量より安定性と機能を重視する、との見方もあります。

技術選定では、自社のユーザーにとって何が許容できるかを基準にします。容量や性能を数値で比べたい場合は、関連記事『アプリ開発のメリット・デメリットと判断基準について』もご覧ください。

ポイント

技術形態は、UIや認証など機能ごとに分けて考えると判断しやすくなります。一方で、容量が増える代償もあるため、自社のユーザーにとって許容できるかを基準にしてください。

国内大手のFlutter・クロスプラットフォーム採用事例

BtoC、BtoB、SaaSの各モデルに対応する技術形態を3枚のパネルで示した図解。
利用者や対象OSに応じて、選ぶ形態が分かれます。

Flutterをはじめとするクロスプラットフォームは、国内企業の本番アプリでも採用されています。大規模なアプリでも使えるのかという不安を和らげ、技術選定の選択肢を広げる事例です。

メルカリ・スシロー・ユニクロなどの採用実例

国内でFlutterを採用したアプリには、メルカリの新サービス「ハロ」、スシロー、じゃらん、マイナビ2025があります。

ユニクロ、サイバーエージェントのWINTICKET、DeNAのVoice Pocochaも採用しています。採用業種は幅広く、スポット案件や飲食、旅行予約などに及びます。さらに、人材、アパレル、エンタメにも広がっています。

採用の背景にある開発効率と性能は、下の4つの面で確認できます。

  • 開発体制:採用企業には、iOS/Androidを素早く同時に、少人数で開発・保守するニーズがあります。
  • 工数:単一コードから両OS向けに作れるため、二つのネイティブチームより開発の手間と保守負担を大きく圧縮します。
  • 描画性能:1,000要素のスクロールはFlutterが2.1ms/フレーム、React Nativeが3.8ms/フレームです(出典:オブライト)。
  • メモリ:同等ECアプリでFlutter180MB対ReactNative210MBと報告されており、大手の採用を後押しする本番水準の性能です。

BtoC・BtoB・SaaS別の形態選定の傾向

ビジネスモデルによって、技術形態の選び方には傾向があります。自社のユーザーと利用環境に合う選択肢は、BtoC・BtoB・SaaSごとの違いから考えられます。

  • BtoC:開発効率と更新スピードを重視し、クロスプラットフォームを選ぶケースが目立ちます。
  • BtoB:対象OSを限定できる業務では、片方のOSから先行して作る判断もできます。
  • SaaS:Webアプリで利用を検証してから、定着後にモバイルアプリ化する方法があります。

たとえば、BtoCではメルカリやユニクロのような採用例があります。一方、BtoBや物流・製造の現場では、業務用Android端末に統一するなど、対象OSを絞れる場合があります。

SaaSをまずWebで提供すれば、OSを問わず価値を検証でき、初期投資も抑えられます。利用者、端末、利用頻度と自社のビジネスモデルから考えると、後悔のない技術選定につながります。

ポイント

大規模なアプリでも使えるかどうかは、採用事例で確かめられます。BtoCか、対象OSを絞れるBtoBかによって、技術形態の目安は変わります。

AI駆動開発と分割発注でコストを圧縮した事例

定型コードへのAI活用、熟練者のレビュー、発注先の分割、発注側の統括を並べた図解。
作業の分担と品質管理を組み合わせて費用を抑えます。

技術形態の選定と並び、発注企業の関心が高いのが開発費の抑え方です。AI活用は、アプリ開発のコスト構造を変える可能性があります。

市場相場の1/3に圧縮したAI駆動開発事例

ある案件では、市場相場の700〜1,500万円(13〜18人月相当)を、実質8人月、500万円程度まで圧縮しました(出典:ぷらすわん合同会社)。

仕様に沿う定型コードや画面実装をAIに任せると、工数が減り、人月ベースの開発費も下げられます。ただし、AIに丸投げすれば安くなるわけではありません。

  • コード生成:Claude Codeなどで、仕様に沿う定型コードや画面を実装します。
  • 品質管理:熟練者が生成コードを見極め、設計やアーキテクチャを判断して初めて、品質とコストを両立できます。

AIは、熟練者の生産性を高める道具として使うのが前提です。そのため、発注側はAIの出力をレビューする担当者が誰かを、ベンダーに確認しておく必要があります。

フリーランス+小規模専門会社の分割発注

分割発注で費用を抑えるには、発注先の構成と、全体を束ねる体制の両方を設計しておく必要があります。

  • 発注先:フリーランスと小規模専門会社に分け、一社委託で生じる中間マージンを減らします。
  • 統括:品質と進捗を束ねるのは発注側です。責任者が曖昧だと、統合の負担やトラブルで費用が膨らみます。

発注先別の人月単価の目安は、フリーランスが60〜80万円、中小開発会社が80〜120万円、大手SIerが150〜300万円です(出典:ぷらすわん調べ)。

単価差の多くは、組織の維持費や多重下請けの中間マージンによるものです。そのため、発注方法を工夫すれば、削減できる余地があります。

自社にディレクション人材がいない場合は、上流から伴走できるパートナーと組むほうが、総コストを下げられることもあります。また、誰に何を任せ、誰が束ねるかを決めておくことが欠かせません。

ポイント

AIで工数を減らせても、丸投げでは安くなりません。費用を抑えるには、熟練者のレビューと、発注先の構成、全体を束ねる体制をあわせて設計することが目安になります。

KMP段階統合とネイティブ回帰の事例

UIを各OSのネイティブで作り、ビジネスロジックをKMPで共通化するレイヤー図。
共通化の対象を絞ると、OSごとのUIを保てます。

慎重にクロスプラットフォームを活用した事例と、ネイティブへ戻った開発者の声があります。

BMWが全体工数の約20%でKMPを段階統合した事例

KMP(Kotlin Multiplatform)は、画面全体ではなく、ビジネスロジックだけを共通化する方法です。BMWの車載システムでは、導入を全体工数の約20%に抑えた事例が報告されています(出典:技術ケース)。

  • 導入範囲:リスクの低い一部から共通化し、効果を見ながら範囲を広げます。
  • 影響の限定:要件に合わない場合も、段階導入なら、広がる範囲を小さく抑えられます。
  • UIと性能:UIは各OSのネイティブで作り、自由度や性能を保ちます。慎重に進めたい大規模アプリほど段階導入が有効です。

クロスプラットフォームからネイティブへ回帰した声

開発者コミュニティには、クロスプラットフォームで限界にぶつかり、ネイティブへ戻る人もいるとの声があります(出典:開発者コミュニティ)。ネイティブ回帰が選ばれる理由と、技術形態を見直す場面には、いくつかの傾向があります。

  • 開発現場:「ネイティブのエラーのほうがデバッグしやすい」「大企業ではObjective-CやJavaが今も最強」といった意見。
  • 要件:OSの最新機能を早く使う場合や極限の性能が必要な場合は、ネイティブに優位性があります。
  • 段階移行:MVP(必要最小限の製品)期はWebやクロスプラットフォームで検証し、利用が定着した後、OS深部の機能に合わせてネイティブへ移る進め方です。

クロスプラットフォームが常に最適とは限りません。ネイティブへの回帰は失敗ではなく、要件に応じた再選択と捉えられます。

最初の技術選定は変えられないと思い込まないことが欠かせません。また、失敗パターンと回避策は、関連記事『アプリ開発の失敗・課題・注意点・リスクについて』もご覧ください。

ポイント

KMPで共通化する範囲は、リスクの低い一部から始めて効果を見ながら広げるのが目安です。ネイティブへ戻る判断は、要件に応じた再選択として捉えると筋が通ります。

まとめ

成功事例に共通するのは、必要な機能とビジネスモデルから技術形態や言語を選び、開発効率を高めながらコア機能の性能を守っている点です。

たとえば、ING銀行は認証をネイティブに残してUIをFlutterへ統合しました。メルカリやユニクロなどは、クロスプラットフォームで両OSの開発効率を高めています。

AI駆動開発と分割発注で市場相場の1/3に圧縮した例や、BMWがKMPの範囲を絞った例もあります。また、要件の変化を受けてネイティブへ戻った例も、合理的な再選択として見られます。

技術の新しさではなく、自社のビジネス要件との一致を基準にします。ユーザー、デバイス、利用頻度を踏まえ、効果の見えやすい範囲から、現実的な形態で始めるのがよいでしょう。

riplaは、フルスクラッチ受託と国内開発に、元事業会社の知見を組み合わせています。そのうえで、ビジネスから逆算した技術選定と、現場に定着するアプリづくりを一貫して支援します。

全体像の確認には、アプリ開発の完全ガイドをご活用ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。