# ネイティブアプリ・クロスプラットフォーム・PWAの選び方｜業務アプリで失敗しない技術選定｜テクノスフィア

> スマホアプリの開発方式をどう選ぶか。ネイティブ(Swift/Kotlin)・クロスプラットフォーム(Flutter/React Native)・PWAの違いを、プッシュ通知・オフライン動作・カメラ・配布方法・費用の観点で比較。業務アプリの技術選定で判断を誤らないためのフローチャート付き。

URL: https://technosphere.co.jp/blog/native-vs-pwa-app-choice

** 目次
1. 3つの選択肢と、それぞれの正体
2. 判断を分ける6つの軸
3. つまずきポイント①：iOSのプッシュ通知
4. つまずきポイント②：オフライン動作の実装コスト
5. つまずきポイント③：配布方法と審査
6. フローチャート：どれを選ぶか
7. 後から乗り換えられる設計にしておく
8. よくある質問（FAQ）
9. まとめ

## 3つの選択肢と、それぞれの正体

 スマホアプリを作ると決めた後、最初の分岐が「どの方式で作るか」です。選択肢は大きく3つあります。

```
① ネイティブ           Swift (iOS) / Kotlin (Android)
                       → OS純正の作り方。性能と機能の自由度が最大
② クロスプラットフォーム Flutter / React Native
                       → 1つのコードで両OS。UI は独自描画 or ネイティブ部品
③ PWA                  HTML/CSS/JavaScript + Service Worker
                       → 実体はWebサイト。ホーム画面に追加してアプリのように使う
```

 よくある誤解は「PWA＝安いネイティブの下位互換」というものです。実際は**できることの種類が違う**だけで、社内配布のツールならPWAのほうが運用が軽く、審査待ちもなく、更新も即時反映されるという明確な利点があります。逆に、通知を軸にした顧客向けアプリでPWAを選ぶと、後述の理由で施策が成立しません。

## 判断を分ける6つの軸

案件ごとに次の6項目を確認すれば、方式はほぼ自動的に決まります。
| 軸 | ネイティブ | クロスプラットフォーム | PWA |
| プッシュ通知 | ◎ 制約なし | ◎ 制約なし | △ iOSは条件付き |
| オフライン動作 | ◎ | ◎ | ○ 実装次第 |
| カメラ・センサー | ◎ 全機能 | ○ プラグイン依存 | △ 制限あり |
| Bluetooth・USB機器連携 | ◎ | ○ プラグイン依存 | × 実質不可 |
| 配布・更新 | △ 審査あり | △ 審査あり | ◎ URL・即時反映 |
| 開発費（両OS対応時） | 高（2つ作る） | 中 | 低 |

 表を見ると、**「Bluetooth機器とつなぐ」「センサーを細かく制御する」が要件に入った瞬間にPWAは落ちる**ことが分かります。逆に、社内の入力フォームや一覧表示が中心で、配布の手軽さと更新の速さを優先するなら、PWAで十分どころか最適です。

## つまずきポイント①：iOSのプッシュ通知

 「PWAでも通知は送れます」——これは正しいのですが、iOSでは重要な前提が付きます。

```
iOS 16.4 以降:
  ✅ Web Push は使える
  ⚠️ ただし「ホーム画面に追加」したPWAに限られる
     （Safariのタブで開いているだけでは通知が届かない）

Android:
  ✅ Chrome でそのまま Web Push が使える（ホーム画面追加は任意）
```

 つまりiPhoneユーザーには、**「共有ボタンを押して、ホーム画面に追加してください」という操作を案内し、実行してもらう**必要があります。社内向けで配布時に説明できるなら現実的ですが、一般ユーザー向けアプリでこの一手間を挟むと、通知を受け取れる人の割合は大きく落ちます。

 **判断基準はシンプルです。**プッシュ通知が施策の中心（再来店促進、緊急連絡、リマインド）なら、ネイティブまたはクロスプラットフォームを選んでください。通知が「あれば便利」程度ならPWAで問題ありません。

## つまずきポイント②：オフライン動作の実装コスト

 倉庫・工場・地下・山間部など、通信が不安定な現場で使うアプリでは「圏外でも入力できる」が必須要件になります。ここで見落とされがちなのが、**オフライン対応の本体はUIではなくデータ同期の設計**だという点です。

方式を問わず、次の問題を必ず設計する必要があります。
- **競合の解決** — 同じデータをAさんとBさんが別々にオフライン編集したら、どちらを採用するか
- **送信の再試行** — 電波が戻ったときに未送信データを自動送信し、失敗時は再試行する
- **重複の防止** — 再試行で同じデータが二重登録されないよう、クライアント側で一意IDを持たせる
- **ストレージ上限** — 端末に貯め込めるデータ量の上限と、古いデータの破棄ルール

 この設計を省くと、「圏外で入力したデータが消えた」「同じ報告が2件登録される」といった、現場の信頼を一発で失う不具合が起きます。オフライン要件がある案件では、UIより先にこの部分を詰めてください。

```
// 二重登録を防ぐ: クライアントで一意IDを発行して送る
const record = {
  clientId: crypto.randomUUID(),   // 端末側で採番
  inspectedAt: new Date().toISOString(),
  items: [...],
};
await queue.enqueue(record);       // まずローカルに保存

// オンライン復帰時にまとめて送信（サーバーは clientId で重複を弾く）
window.addEventListener('online', () => queue.flush());
```

## つまずきポイント③：配布方法と審査

 意外と見落とされるのが配布です。とくに**社内利用のアプリをApp Storeに公開したくない**ケースでは、方式選定に直結します。
| 配布方法 | 対象 | 特徴 |
| App Store / Google Play | 一般公開 | 誰でも入手可。審査に1〜2週間 |
| Apple Business Manager（カスタムApp） | iOS社内配布 | 指定組織にのみ配信。審査あり |
| MDM経由 | iOS/Android社内配布 | 端末管理と合わせて配布。MDM導入が前提 |
| Google Play 限定公開 / APK配布 | Android社内配布 | 比較的手軽 |
| PWA（URL配布） | 制限なし | 審査ゼロ・更新即時。ホーム画面追加を案内する |

 **審査は開発スケジュールに影響します。**ネイティブ・クロスプラットフォームでは、リリース後の緊急修正にも審査が挟まります（Appleの迅速化申請はありますが確約ではありません）。頻繁に更新したい業務ツールほど、PWAの「即時反映」が効いてきます。

## フローチャート：どれを選ぶか

実際の案件で使っている判断順です。上から順に見ていけば、だいたい迷わず決まります。

```
Q1. Bluetooth/USB機器やセンサーを細かく制御する？
     YES → ネイティブ（or ネイティブ拡張を含むクロスプラットフォーム）
     NO  ↓
Q2. iOSユーザーへのプッシュ通知が施策の中心？
     YES → ネイティブ / クロスプラットフォーム
     NO  ↓
Q3. App Store・Google Play で一般公開して露出を取りたい？
     YES → ネイティブ / クロスプラットフォーム
     NO  ↓
Q4. 更新頻度が高い、または審査待ちを避けたい？
     YES → PWA
     NO  ↓
Q5. 予算と期間を最小に抑えたい？
     YES → PWA
     NO  → クロスプラットフォーム（両OS対応の費用対効果が最も高い）
```

 補足として、Q1でネイティブに倒れた場合でも「片方のOSだけ先に作る」という選択肢があります。社内配布ならAndroidだけ、店舗の貸与端末がiPadならiOSだけ、といった具合に対象端末を固定できるなら、開発費は半分近くに抑えられます。

## 後から乗り換えられる設計にしておく

 技術選定でいちばん怖いのは「読み違えたときに全部作り直しになる」ことです。これは設計で相当程度、回避できます。
- **業務ロジックはサーバー側のAPIに置く** — 端末側は表示と入力に徹する。移行時に作り直すのはUIだけで済みます
- **データモデルを端末に依存させない** — 端末固有の保存形式に業務データを直接書かない
- **認証は標準的な方式で** — OAuth 2.0 / OIDC など、どの方式からでも使える形にしておく
- **まずPWAで検証してからネイティブへ** — 使われ方が読めない新規業務では、PWAで安く早く出して実際の利用状況を見る進め方が有効です

 実際に弊社では、[ブラウザだけで動く3Dアプリ](https://technosphere.co.jp/blog/threejs-mobile-3d-game)のように、Web技術でどこまでできるかを検証したうえで、必要な部分だけネイティブに寄せる進め方を採ることがあります。[実際に動くデモ](https://technosphere.co.jp/games/drone-inspector/)も公開しているので、Web技術の到達点の参考にしてください。

## よくある質問（FAQ）

### Q. PWAでもiPhoneにプッシュ通知は送れますか？

送れます。iOS 16.4以降、ホーム画面に追加したPWAでWeb Pushが使えます。ただしホーム画面への追加操作が必須で、この一手間で到達率が落ちます。通知が中心の施策ならネイティブ系が確実です。

### Q. FlutterとReact Nativeはどちらを選ぶべきですか？

既存チームがReact/TypeScriptに慣れているならReact Native、UIをiOS/Androidで完全に揃えたい・描画性能を重視するならFlutterです。特殊なハードウェア連携がある場合は、いずれもネイティブコードを書く前提で見積もってください。

### Q. 業務アプリをストアに公開せず配布できますか？

できます。配布方法の比較のとおり、Apple Business Manager・MDM・Google Play限定公開などの手段があります。社内限定ならPWAでURL配布という選択肢も有力です。

### Q. 後からネイティブに作り直せますか？

できますが、UIは作り直しになります。業務ロジックをサーバー側に寄せておくと、移行時の影響をUIだけに閉じ込められます。

## まとめ

###  この記事のまとめ
- PWAは「安い下位互換」ではなく、配布の手軽さと更新の速さで優位に立つ選択肢
- Bluetooth・センサー制御が要件に入ったらPWAは選べない
- iOSのWeb Pushは「ホーム画面に追加」が前提。通知中心の施策ならネイティブ系
- オフライン対応の本体はUIではなく同期設計（競合解決・再試行・重複防止）
- 業務ロジックをサーバー側に寄せておけば、後から方式を乗り換えても影響はUIだけ

 テクノスフィアでは、iOS/Androidネイティブ、Flutter・React Native、PWAのいずれにも対応し、機器側の組込み開発やサーバー・クラウド構築まで自社で行っています。「アプリにすべきか、Webで足りるか」の判断からご相談いただけます。

 [▶ スマホアプリ開発サービスを見る](https://technosphere.co.jp/app-development) ｜ [開発の相談をする](https://technosphere.co.jp/contact?category=web)    [技術コラム一覧に戻る](https://technosphere.co.jp/blog/)