システム開発

クロスプラットフォームアプリ開発技術の比較（React Native、Flutter、KMP…etc.）

公開 : 2022.07.25

最終更新 : 2026.04.23

# モバイル/Webアプリ

本記事は、多数あるアプリ作成方法の中から最適なものを選択するためのポイントを解説していく連載記事の1つです。

過去の2つの記事は主に「非エンジニア」の方向けに書いていましたが、本記事からやや技術的な知識を持つ方向けの内容に寄っていきます。
もちろん多くの方に読んでいただきたいと思いますが、よくわからない方は無理にこの記事を読んだだけで判断せず、専門知識を持った方と相談しながらどの手法を採用すべきかを考えていただければ幸いです。

連載記事

スマホで動作するアプリの全体像

下図はスマホで動作するアプリの全体像です。先の記事ではWebアプリとモバイルアプリの違いや、ネイティブアプリとクロスプラットフォームアプリの違いを説明しました。
本記事ではクロスプラットフォームアプリをさらに細分化して、実装方式による違いを説明します。図の通り、本記事ではクロスプラットフォームアプリを、ネイティブUI型、独自UI型、Web View型、ガワアプリと4種類に分けてみました。

まずその中の2つ、ネイティブUI型と独自UI型から説明します。

ネイティブUI型と独自UI型

ネイティブUI型と独自UI型の違いは、UIの描画処理をどこで行うかです。

人が目にするアプリのUIを画面に表示すること（描画処理を行うこと）をレンダリングと言います。このレンダリング処理をどこで行うかが、ネイティブUI型と独自UI型の違いです。

ネイティブUI型

ネイティブUI型の場合、OSが提供するネイティブのUI部品を呼び出し、OS側でレンダリングを行います。そのためアプリ側ではレンダリングを正確にコントロールすることが難しいです。
ネイティブUI型の代表的なフレームワークとしては、React Nativeが挙げられます。

ネイティブUI型のメリット・デメリット

React Nativeに代表されるネイティブUI型のメリットは、OSに適したUIで描画されるためユーザーが操作しやすくなることです。
iOSであればiOSが持っているネイティブのレンダリング処理を使用するため、iOSユーザーが使いやすいUIで表現されます。Androidの場合も同様です。

次にネイティブUI型のデメリットですが、開発時のコードは共通であっても、レンダリング処理をOSに依存するため、デザインの完全統一ができないことが挙げられます。同じアプリでもOSが異なると少し異なるUIで表現されてしまうのです。
デザインの統一が難しいのでOS毎に個別に設定するコードが必要になり、その分開発コストが少し増える可能性もあります。

独自UI型

独自UI型のメリットとしては、OS間でのUI統一、高い描画性能、デザイン主導の開発のしやすさなどが挙げられます。

ネイティブUI型ではOS側にレンダリング処理がありますが、独自UI型ではアプリ側にレンダリング処理が入っています。OSに依存しないため共通のUIを描画できます。
独自UI型の代表的なフレームワークとしては、Flutterが挙げられます。

独自UI型のメリット・デメリット

Flutterに代表される独自UI型のメリットは、OSに依存しないUI統一、安定した描画性能、デザイン主導の開発のしやすさ等が挙げられます。

ネイティブUI型には異なるOS間でデザインが統一できないというデメリットがありましたが、独自UI型ならそのような問題はありません。

次に独自UI型のデメリットですが、OSが新しく追加したUI要素への対応に時間がかかることが挙げられます。
例えば、iOS 26で導入されたLiquid Glassのような新しいUIの場合、フレームワーク側が公式対応するか、有志のライブラリの安定版が公開されるまで時間を要する傾向があります。

クロスプラットフォームの代表的なフレームワーク

続いて、クロスプラットフォームの代表的なフレームワークについて見ていきます。

前節でUI型の違いを説明しましたが、ここでは各フレームワーク固有の特徴に焦点を当てます。それぞれに特徴や優れた点がたくさんありますが、代表的なものに絞って記載します。

React Native

React Nativeは、Meta社（旧Facebook）が作成したアプリ作成フレームワークです。開発言語はTypeScript（JavaScript）を使用しています。

React Native利用のメリット

多くのWebエンジニアが使う言語であるTypeScriptで開発できるため、Webエンジニアにとって比較的扱いやすいことです。
モバイルエンジニアに比べて、Webエンジニアは母数が多いため、TypeScriptを扱える技術者は集めやすい傾向にあります。

現在ではExpo（React Native開発のためのフレームワーク・プラットフォーム）を用いた開発が標準構成であり、Expo独自の機能を使えることもメリットとして挙げられます。

また、2024年10月にデフォルトで有効化されたNew Architectureにより、それ以前によく指摘されていたパフォーマンス課題も改善傾向にあります。

React Native利用のデメリット

TypeScript（JavaScript）を基盤とする巨大なエコシステムを持つため、利用可能なライブラリの選択肢が豊富であるというメリットがある反面、品質やメンテナンス状況にばらつきがあり、プロジェクトに最適なライブラリを評価・選定するコストが高いという側面があります。

また、近年はExpoへの依存度が高まっている点もデメリットとして挙げられます。Expoの学習コストはもちろん、開発規模によっては料金コストがかかる点はデメリットです。
Expoの代表的な機能であるEASビルドやOTA配信の使用量に応じた従量課金制となっており、個人開発や小規模プロジェクトであれば無料枠で運用できますが、ビルド頻度や配信量が増えると有料プランへの移行が必要になります。

Flutter

Flutterは、Google社が作成したフレームワークです。開発言語はDartを使用しています。

Flutterのメリット

Flutterはマテリアルデザインに準拠したウィジェット群を標準で豊富に提供しているため、マテリアルデザインのUIを素早く構築できることがFlutterの大きなメリットです。（実装時に設定すればiOSのUIデザインに寄せることも可能です。）

また、ホットリロード機能やDevToolsなどの開発者向けの機能が優秀で、使用感として癖が少なく開発体験が良い点が特徴です。

Flutterのデメリット

先に「独自UI型の説明」でも触れましたが、OSが新しく追加したUI要素への対応に時間がかかることはデメリットとして挙げられます。

比較的シェアが小さく馴染みのないDart言語を採用することに対して抵抗感を持たれやすい点もデメリットのひとつです。
ただし、Dartは当初JavaScriptの課題を解決するための代替言語を目指して開発された経緯もあり、TypeScriptやJava経験者には親しみやすい言語です。
また、ドキュメントの充実度やAIコーディング支援ツールの発達もあって、実践的な習得のハードルは以前より下がっています。

Kotlin Multiplatform（KMP）

KMPは、JetBrains社が開発するクロスプラットフォーム技術です。開発言語はKotlinを使用しています。
KMPはReact NativeやFlutterとは異なるアプローチを取っており、UI層ではなくビジネスロジック層（データ処理、API通信、業務ルールなど）を共通化することを主眼としています。
UI層は各プラットフォームのネイティブ技術（iOSならSwiftUI、AndroidならJetpack Compose）で個別に実装するのが基本構成です。

KMPのメリット

最大のメリットは、ネイティブの操作感を保ちながら、ロジックの開発工数を削減できることです。
UIを各OSのネイティブ技術で作るため、OSアップデートで追加される新しいUI要素にも即座に対応でき、OS標準の操作感を損ないません。

また、既存のネイティブアプリに対して、段階的に導入しやすい点も大きな強みです。
React NativeやFlutterは全面的な書き換えを前提とする構成が一般的ですが、KMPは既存コードを残したまま共通化したいロジック部分だけ移行できます。

KMPのデメリット

デメリットとして、UI部分は各プラットフォームで個別実装する必要があるため、完全な工数削減にはならないことが挙げられます。
React NativeやFlutterのように「1つのコードで両OS向けのアプリ全体を作る」ことを強く期待する場合は適しません。

また、KMPの安定版のリリースは2023年11月と比較的新しく、両者と比べて、技術記事やドキュメント類が相対的に少なく、学習時や問題解決時にリソースを探す手間がかかる、または情報が見つからないというケースが考えられます。
同様に比較的新しい技術のため各種ライブラリなども発展途上の物が多く、数も少ない現状です。

※ UIまで共通化したい場合は、同じくJetBrainsが提供するCompose Multiplatform（CMP）と組み合わせる選択肢もあります。
CMPはAndroidのJetpack Composeをベースにした独自UI型のフレームワークで、2025年5月にiOS向けも安定版となりました。

ただし、現状はJetpack Composeの全機能がそのまま使えるわけではなく、プラットフォームごとの差異も未だ多く残っています。
「UIも含めて完全に共通化したい」という要件では、成熟度の高いFlutterと比較検討されることも多く、現時点ではFlutterと比較すると選択の幅は狭いのが実情です。
Kotlinエコシステムで一貫して開発したいチームや、既存のAndroid Composeアプリを他プラットフォームに展開したい場合には有効な選択肢となります。

フレームワーク選択のポイント

ここからは、どのフレームワークを採用するか迷われている場合の、選択のポイントを紹介します。
各フレームワークは三者三様の特徴を持ち、一概に優劣を決められないほど成熟してきた技術領域です。
「どれが優れているか」より「自社の状況に最も合うのはどれか」という観点での判断が重要です。以下の3つの切り口で整理します。

①開発チームのスキルセットから考える

Webエンジニア（React/TypeScript経験者）が多い場合 → React Native
特定のスキルセットの縛りがなく、開発体験と生産性の高さを重視したい場合 → Flutter
Androidエンジニア（Kotlin経験者）が多い場合 → KMP

②UI方針から考える

ネイティブのUIを保ちたい場合 → KMP > React Native
両OSで統一されたUIを実現したい場合 → Flutter

③戦略的な観点から考える

既存ネイティブアプリがあり、段階的に、または、ロジック部分だけ共通化したい → KMP
アプリ全体を全面的に共通化したい → Flutter、React Native

また、長期的な観点では、エンジニアの採用しやすさ・技術の将来性やトレンドも重要な要素です。3つのフレームワークはいずれもクロスプラットフォーム開発の主要な選択肢として注目されており、長期的な人材確保や運用・保守の面にも影響するため、押さえておきたいポイントです。

※実際にはもっと多様な選択のポイントや考慮すべき制約がありますが、この記事ではわかりやすく単純な例を用いた説明に留めています。

Web View型とガワアプリ

続いて、Web View型とガワアプリについて説明していきます。

Web View型

Web View型はモバイルアプリの中でWebアプリを動かすイメージです。
アプリの中にはWeb View（ブラウザに相当するもの）があり、その中でWebアプリを動かして機能を提供するのがWeb View型です。

Webアプリは基本的にカメラやBluetoothなど端末側の機能（ネイティブ機能）を利用したくても制約があるのですが、この問題を解消するために、Web View型のフレームワークにはPluginという仕組みが用意されています。Pluginを通すことで、Webアプリでもネイティブ機能を利用することができます。

Web View型の代表的なフレームワークとしては、かつてApache Cordovaが広く使われていましたが、人気の低迷、主要サービスのサポート終了などもあり、Cordovaの思想を引き継ぐ形で登場したCapacitor（Ionic社）が、Web View型の主流となっています。Capacitorはモダンなフロントエンドフレームワーク（React、Vue、Angularなど）との統合がしやすく、Web技術の延長でモバイルアプリを開発できる点が特徴です。

Web View型のメリット・デメリット

Web View型のメリットは、Webエンジニアが既存のスキルセットでモバイルアプリを開発できることです。また、既存のWebアプリがある場合、その資産を活かしやすい点も強みです。

一方でデメリットは、Web Viewを介して描画するため、上記のクロスプラットフォームフレームワークと比較するとパフォーマンスが劣る傾向があることです。
また、Pluginが用意されていない高度なネイティブ機能は使用できないか、追加実装が必要になる場合があります。

ガワアプリ

【注意】以降の記述は2026年現在ではあまり採用されない技術であり、採用してもストア審査に引っかかる可能性のある内容です。ただし、技術的な特性を理解しておくことは、比較検討を行う上で有益なため、2022年の公開当時の内容をあえて残しています。
参照：App Review Guidelines : 4.2 Minimum Functionality

ガワアプリというのは、アプリ内のWeb Viewを通じてWebサーバーに置いてあるプログラムを要求する仕組みです。サーバーにあるWebアプリを呼び出して実行し、アプリ側はそれを描画しているだけです。
ガワアプリの「ガワ」は「外側」や「何かを包む皮」の「ガワ」を指しているようです。要は外側だけモバイルアプリっぽく見せているが、実際はアプリ側にはほとんど機能を持たず、Webを表示することを主機能としているアプリです。

Web View型とガワアプリの違いは、アプリの中にWebアプリを持っているのか、サーバーにアクセスしてWebアプリを呼ぶだけなのかという点です。

ガワアプリのメリット・デメリット

ガワアプリのメリットは、サーバーからWebアプリを呼ぶだけなので既存のWebアプリをモバイルアプリのように動作させられることです。また、「ガワ」には手を加えずサーバー側のアプリを更新すれば済むアプリ更新の容易さもメリットです。

一方、デメリットとしては、Web View型と同様にパフォーマンスが低いこと、およびネイティブ機能を基本的に使用できないことが挙げられます。そもそも冒頭の注意書きの通り、現在ではストア審査でリジェクトされるリスクが高く、新規採用は推奨されません。

Web View型を選択する際のポイント

ここからは、Web View型がプロジェクトに適しているかを判断する際のポイントを紹介します。

前述の通り、ガワアプリは新規採用を推奨しないため、以下はWeb View型の採用可否を検討するための観点となります。

①既存Web資産の活用を重視するか

既にWebアプリやレスポンシブ対応のWebサイトがあり、モバイルアプリ用に一部修正して転用したい場合、Web View型は有力な選択肢となります。

一部のネイティブ機能はPluginで補いつつ、UI部分の大半はWebアプリのコードを活かせるため、開発コストを大きく抑えられます。

一方、ゼロから新規開発する場合は、パフォーマンスや開発体験の面でReact NativeやFlutter、KMPのほうが有利なケースが多くなります。

②求められるパフォーマンス・機能レベル

高度なネイティブ機能や高いパフォーマンスを必要としない情報閲覧・フォーム入力・簡易なコンテンツ配信などの用途であれば、Web View型で十分対応できます。

一方、長いリストの高速スクロール、重いアニメーション、カメラの高度な制御、リアルタイムな3D描画などが必要な場合は、Web View型では性能的に厳しい場合があります。こうした要件があるプロジェクトは、ネイティブUI型・独自UI型のフレームワークが適しています。

③そもそもモバイルアプリである必要があるか

Web View型は「モバイルアプリとして配布したいが、中身はWeb技術で作りたい」場合の選択肢です。逆に言えば、モバイルアプリとして配布する必要がなければ、Webアプリのまま提供するという選択肢もあります。

Webアプリにホーム画面への追加やオフライン動作、プッシュ通知などのアプリ的な体験を加える仕組みとしてPWA（Progressive Web App）が挙げられます（連載次回で紹介します）。

PWAはストア審査が不要で、URLを通じてすぐに配信・更新できるため、ストア経由の配布が必須でない用途であれば有力な選択肢となります。ただし、PWAはあくまでWebアプリであり、ストアで配布して「アプリとしてインストールしてもらう」ことを前提とする場合や、より幅広いネイティブ機能を使いたい場合には、Web View型のほうが適しています。

このため、Web View型の採用を検討する前に、まず「そもそもモバイルアプリとして配布する必要があるのか、Webアプリ（PWA）で十分ではないか」を整理することをおすすめします。

まとめ

本記事では、クロスプラットフォームでモバイルアプリをつくる場合の実装方式による違いや選択のポイントをご紹介しました。

どの手法を採用するか正しく判断を下すためには、アプリに求める機能性、開発コスト、保守のしやすさ、技術の将来性…などさまざまな観点を持って考える必要があります。
そのため、ビジネスサイドの方とITサイドの方、両者が参加するプロジェクトチームで協議するのがお勧めです。
外部ベンダーに開発を依頼する場合は実装方式の相談にも乗ってくれるようなパートナーを選定するのが良いでしょう。

NCDCは、モバイルアプリを用いたサービスの全体像を検討するところから、アプリ開発の要件定義、UX/UIデザイン、実装まで一元的にお客様をご支援することを得意としています。
目的に応じた適切な技術の選定からご相談いただけますので、モバイルアプリの開発を検討されている方はぜひお問い合わせください。