スマホアプリを作るとき、iOSとAndroidをそれぞれの専用技術で作る「ネイティブ開発」にするか、Flutter や React Native のような技術で一つのコードから両OSのアプリを作る「クロスプラットフォーム開発」にするかは、費用、開発期間、保守のしやすさを大きく左右する判断です。どちらが優れているという話ではなく、アプリの性質と、作った後に誰がどう保守していくかによって適した答えが変わります。
この記事は、アプリ開発を発注・企画する立場で、開発会社から「Flutterで作りましょう」「ネイティブがおすすめです」と提案されて判断に迷っている方や、これから技術選定を行う方に向けて書いています。それぞれの仕組みと特徴、性能・端末機能・開発体制・保守費用という四つの判断軸、Flutter と React Native の違いの考え方、選定の手順と具体例を説明します。
結論を先に言えば、業務アプリや会員アプリ、予約アプリなど、画面とデータのやり取りが中心のアプリでは、クロスプラットフォームが有力な第一候補になります。一方で、カメラや各種センサーを深く使う、OSの最新機能をすぐに取り入れたい、描画性能を極限まで求める、といったアプリでは、ネイティブを選ぶ理由がはっきりあります。迷ったときは、「端末機能への依存度」と「保守を担う体制」の二つから考えると判断しやすくなります。
ネイティブ開発とクロスプラットフォーム開発の違い
ネイティブ開発とは
ネイティブアプリ の開発では、iOSなら Swift、Androidなら Kotlin のように、各OSの提供元が用意している言語と開発ツールでアプリを作ります。OSの機能を直接使えるため、端末の性能を引き出しやすく、OSの新機能にも早く対応できます。その代わり、iOSとAndroidで別々のコードを書くことになり、開発も保守も二系統分の手間がかかります。
クロスプラットフォーム開発とは
クロスプラットフォーム開発では、一つのコードから両OSで動くアプリを作ります。画面の作り方や業務ロジックの多くを共通化できるため、開発の工数を抑えやすく、機能の追加や修正も一度で済む部分が増えます。ただし、OS固有の機能を使う部分では、各OS向けの個別の実装が必要になる場面があります。
代表的な技術として、Google が中心となって開発している Flutter と、Meta が中心となって開発している React Native があります。ほかにも、共通部分だけを共有し、画面は各OSのネイティブで作る方式など、いくつかのアプローチがあります。
両者の特徴の比較
| 観点 | ネイティブ | クロスプラットフォーム |
|---|---|---|
| 開発の工数 | 両OS分が必要 | 共通化できる分を抑えやすい |
| 動作の滑らかさ | 最も引き出しやすい | 一般的な業務アプリでは十分なことが多い |
| 端末機能の利用 | 制限なく使える | 多くは対応、深い利用は個別実装が必要 |
| OS新機能への対応 | 早い | 技術側の対応を待つ場合がある |
| 見た目の統一 | OSごとの標準に合わせやすい | 両OSで同じ見た目にしやすい |
| 保守の手間 | 両OSそれぞれに必要 | 共通部分は一度で済む |
| 技術者の確保 | 各OSの専門家が必要 | 一つの技術で両OSを担当できる |
| 技術の継続性 | OS提供元が維持 | 技術を支える組織・コミュニティに依存 |
判断軸1：性能と操作感
「クロスプラットフォームは動きが遅い」という印象を持つ方もいますが、現在の主要な技術では、一覧の表示、入力フォーム、画面の切り替えといった一般的な操作で、利用者が違いを感じることは多くありません。予約、会員証、注文、社内の申請など、画面とデータのやり取りが中心のアプリであれば、性能を理由にネイティブを選ぶ必要は少ないと考えてよいでしょう。
一方で、次のようなアプリでは性能や操作感の差が問題になりやすくなります。
- 高度なアニメーションや3Dの描画を多用するゲーム性の高いアプリ
- カメラの映像をリアルタイムに処理するアプリ
- 大量のデータを端末側で高速に処理するアプリ
- 動画や音声の編集など、端末の処理能力を限界まで使うアプリ
こうしたアプリでは、ネイティブで作るか、性能が必要な部分だけをネイティブで作り、他をクロスプラットフォームで作る組み合わせを検討します。
性能について判断がつかない場合は、議論を重ねるより、懸念のある画面だけを短期間で試作して実機で確かめる方が確実です。たとえば、大量の画像を並べた一覧をスクロールする、地図の上に多数の印を表示する、といった重そうな画面を、候補の技術で作って実際の端末で動かしてみます。古めの端末や、利用者が多く使っていそうな価格帯の端末でも確認しておくと、リリース後に「一部の端末で動きが重い」という問題が出るのを防げます。試作には数日から数週間程度の工数がかかりますが、技術選定を誤って作り直すことに比べれば小さな投資です。
判断軸2：端末機能とOSの新機能
アプリがどれだけ端末の機能に依存するかは、最も重要な判断軸の一つです。
カメラでの撮影、位置情報、プッシュ通知、生体認証といった一般的な機能は、クロスプラットフォームの技術でも部品（プラグインやライブラリ）が用意されていることが多く、比較的容易に使えます。ただし、次のような場合は注意が必要です。
- Bluetoothで特定の機器と通信する、外部の測定機器とつなぐ
- バックグラウンドで長時間動作し続ける
- ウィジェットやスマートウォッチなど、アプリ本体以外の場所で動く機能を作る
- OSの最新機能を発表直後から取り入れたい
これらは、クロスプラットフォームでも実現できることが多いものの、各OS向けの個別の実装が必要になり、共通化の利点が薄れます。端末機能への依存が強い部分が全体の大半を占めるなら、最初からネイティブで作る方がすっきりする場合があります。
判断に迷う場合は、開発会社に「使いたい端末機能の一覧」を渡し、それぞれクロスプラットフォームでどう実現するのか、個別実装が必要な部分はどこかを確認してもらうのが確実です。
判断軸3：開発体制と技術者の確保
技術の選択は、作るときだけでなく、作った後に誰が保守するかにも関わります。
ネイティブで作る場合、iOSとAndroidのそれぞれに詳しい技術者が必要です。外部の開発会社に依頼する場合は問題になりにくいものの、将来的に自社で保守や機能追加を行いたい場合は、二つの技術の担当者を確保し続ける必要があります。
クロスプラットフォームであれば、一つの技術で両OSを担当できるため、少人数の体制でも回しやすくなります。特に React Native は、Web開発で広く使われている技術と考え方が近いため、Webの開発者がアプリ開発にも関わりやすいという特徴があります。Flutter は独自の言語（Dart）を使いますが、画面を作る仕組みが一貫しているため、習得すれば両OSの画面を同じように作れます。
自社で内製化を目指すのか、外部に保守を任せ続けるのか、Webの開発チームがすでにあるのか。こうした体制の前提によって、適した技術は変わります。
判断軸4：保守費用と技術の継続性
アプリは公開後も、OSの更新や規約の変更に合わせて保守し続ける必要があります。保守の手間は、技術の選択によって次のように変わります。
ネイティブでは、OSの更新への対応を両OS分行う必要がありますが、OS提供元の技術を直接使っているため、対応の方法がはっきりしています。
クロスプラットフォームでは、共通部分の保守は一度で済みますが、OSの更新に加えて、技術そのもの（Flutter や React Native）と、使っている部品の更新への対応も必要になります。部品の中には、開発が止まってしまうものもあるため、どの部品に依存しているかを把握しておくことが大切です。
また、クロスプラットフォームの技術は、それを支える企業やコミュニティの活動に依存します。現在の主要な技術は広く使われていますが、技術選定の際には、利用の広がりや更新の状況を確認しておきましょう。### 部品への依存をどう管理するか
クロスプラットフォームのアプリは、カメラや決済、地図などの機能を、外部の開発者が公開している部品を組み合わせて作ることが多くなります。部品を使えば開発は速くなりますが、その部品の更新が止まると、OSの更新に追従できなくなるおそれがあります。
対策としては、技術選定の段階で使う予定の部品を一覧にし、更新が続いているか、利用が広がっているかを確認しておくことです。重要な機能を一つの小さな部品に依存している場合は、代わりの手段があるかも確認しておくと安心です。開発会社に保守を任せる場合でも、この一覧を納品物として受け取っておけば、後から体制が変わっても状況を把握できます。
保守の全体像は スマホアプリの保守 で詳しく説明しています。
Flutter と React Native はどう選ぶか
クロスプラットフォームを選んだ場合、次に迷うのが Flutter と React Native のどちらにするかです。どちらも実用的な技術であり、多くのアプリはどちらでも作れます。判断の参考になる観点を整理します。
| 観点 | Flutter | React Native |
|---|---|---|
| 言語 | Dart | JavaScript / TypeScript |
| 画面の描き方 | 独自の描画で両OSの見た目をそろえやすい | 各OSの部品を使う考え方が基本 |
| Web開発との親和性 | 別の技術として習得が必要 | Webの技術者が関わりやすい |
| 見た目の一貫性 | 両OSで同じ見た目にしやすい | OSごとの標準的な見た目になじみやすい |
| 向いている体制 | アプリ専任のチーム | Webとアプリを同じチームで開発する体制 |
実務的には、技術そのものの優劣よりも、開発会社や自社のチームがどちらに慣れているか、Web側の開発に何を使っているかで決めることが多くなります。慣れた技術で作る方が、品質も速度も安定するからです。技術の詳細な仕様は変わりやすいため、選定の時点で最新の状況を開発会社に確認してください。
選定の手順
技術の選定は、次の手順で進めると判断の根拠が明確になります。
- アプリで実現したい体験を整理する：主要な画面と機能を書き出し、利用者にとっての価値を明確にします。
- 使いたい端末機能を一覧にする：カメラ、位置情報、通知、外部機器との通信、バックグラウンド動作などを洗い出します。
- 性能が求められる部分を特定する：描画やリアルタイム処理など、性能が利用体験を左右する部分があるかを確認します。
- 保守の体制を決める：外部に任せ続けるのか、将来は内製化するのか、Webの開発チームと統合するのかを決めます。
- アプリである必要を確認する：そもそもWebで足りないかを検討します。比較の考え方は PWAとネイティブアプリの比較 で扱っています。
- 候補の技術で実現性を確認する：端末機能の一覧をもとに、開発会社に技術ごとの実現方法と個別実装が必要な部分を確認します。
- 数年分の保守を含めて比較する：開発費だけでなく、保守の手間と体制を含めて判断します。
新規事業の最初の版を作る場合は、スピードと後の拡張性のバランスも考慮します。検証の結果によって作り直す可能性があるなら、慣れた技術で素早く作ることを優先し、本格的な開発の段階で改めて技術を見直すという考え方もあります。
具体例：二つのアプリで判断が分かれたケース
架空の一般例として、同じ会社が二つのアプリを検討したケースを考えます。
一つ目は、店舗向けの会員アプリです。機能は会員証の表示、ポイント、クーポン、お知らせのプッシュ通知、店舗検索でした。端末機能は通知と位置情報程度で、性能が求められる部分もありません。運営は外部に任せつつ、将来的には社内のWebチームでも機能追加をしたいという意向がありました。この場合はクロスプラットフォームが適しており、Webチームとの親和性も考慮して技術を選びました。
二つ目は、工場の点検作業で使うアプリです。現場の測定機器とBluetoothで接続して値を読み取り、電波の届かない場所でもオフラインで記録し、後でまとめて送信する必要がありました。利用端末も会社が支給する特定の機種に限られていました。この場合、外部機器との通信とオフライン動作が中心で、共通化の利点が小さいため、支給端末のOSに絞ったネイティブ開発を選びました。
もう一つ、中間的な選択をした例もあります。三つ目に検討したのは、利用者が商品を撮影して状態を記録する査定アプリでした。画面の大半は一覧と入力フォームで、クロスプラットフォームで十分に作れる内容です。一方で、撮影時に明るさや傾きを判定して撮り直しを促す機能だけは、カメラの映像をリアルタイムに処理する必要がありました。
この場合は、アプリ全体をクロスプラットフォームで作り、撮影の画面だけを各OSのネイティブで実装して組み込む構成にしました。共通化の利点を保ちつつ、性能が必要な部分だけに個別の手間をかける考え方です。ただし、二つの技術が混在すると保守の担当者に求められる知識が増えるため、ネイティブで作る範囲はできるだけ小さく、境界をはっきりさせておくことが大切です。
同じ会社でも、アプリの性質によって最適な選択が変わるという例です。
選定時のチェックリスト
- 主要な画面と機能を書き出したか
- 使いたい端末機能を一覧にし、深く使うものを特定したか
- 性能が利用体験を左右する部分があるか確認したか
- iOS・Androidの両方が本当に必要か確認したか
- 保守を外部に任せるのか、内製化するのか決めたか
- Webの開発チームとの関係を考慮したか
- 開発会社が提案する技術での開発経験を確認したか
- 使う部品（ライブラリ）の更新状況を確認したか
- 開発費だけでなく、数年分の保守を含めて比較したか
よくある失敗とその避け方
失敗1：費用だけでクロスプラットフォームを選ぶ 端末機能を深く使うアプリでクロスプラットフォームを選ぶと、個別実装が積み重なり、結果として両OSを別々に作るのと変わらない手間になることがあります。端末機能の一覧を先に作り、共通化できる割合を確認してから判断しましょう。
失敗2：「ネイティブの方が高品質」と思い込む 品質は技術の種類よりも、設計とテストの丁寧さで決まる部分が大きいものです。一般的な業務アプリで、根拠なくネイティブを選ぶと、開発費と保守費が両OS分かかり続けます。
失敗3：開発会社の得意な技術を確認しない 提案された技術での開発経験が少ないと、想定外の問題に時間を取られます。過去にどんなアプリをその技術で作ったのか、具体的に確認しておくと安心です。
失敗4：作った後の体制を考えていない 外部の開発会社に依頼して作ったものの、将来の内製化を考えたときに、自社で採用しにくい技術だった、というケースがあります。保守の体制は、技術選定の段階で決めておくことが重要です。
よくある質問
Q. 途中でクロスプラットフォームからネイティブに切り替えることはできますか？
可能ですが、基本的にはアプリを作り直すことになります。一部の画面や機能だけをネイティブで作り、組み合わせる方法もあります。最初の選定で端末機能と性能の要件を確認しておくことが、切り替えのリスクを減らす最善の方法です。
Q. クロスプラットフォームで作ると、審査に通りにくくなりますか？
技術の種類によって審査の基準が変わることは基本的にありません。審査で問われるのは、課金の方法、個人情報の扱い、機能の十分さといった内容です。ストアの規約は変わることがあるため、最新の情報を確認してください。
Q. Webアプリと同じコードでアプリも作れますか？
一部の技術では、Webとアプリでコードの一部を共有できます。ただし、画面の作り方や操作の流れはWebとアプリで異なることが多く、完全に同じコードで両方を作るのは現実的でない場合もあります。どの部分を共有するのかを具体的に検討しましょう。
Otsumuに相談できること
機能が標準的で、開発会社の提案内容と技術の選定理由に納得できているのであれば、この記事の判断軸で確認するだけで十分なことが多いです。社内にアプリの開発経験がある方がいれば、端末機能の一覧をもとに自社で判断を進められます。
一方で、端末機能への依存度が判断しにくい、複数社の提案で技術がばらばらで比較できない、将来の内製化も見据えて技術を選びたい、といった場合には、事業の計画と技術の両方を踏まえた判断が必要です。
Otsumuでは、作りたい体験と事業の計画を伺ったうえで、必要な機能を絞り込み、技術の選定から開発、リリース後の保守まで一貫して支援しています。AIを活用した開発で、少人数・短期間で形にすることを重視しています。アプリ開発については スマホアプリ開発 のページをご覧ください。費用の考え方は スマホアプリ開発の費用は何で決まるか でも整理しています。
技術選定の段階からの相談も歓迎しています。30分の無料相談 でお気軽にお声がけください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01