本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ケーススタディ」カテゴリ追補として、モバイルアプリ専業のケースを解説する記事です。
Webと違いモバイルアプリは「2つのOS（iOS/Android）」「ストア審査」「課金プラットフォーム手数料」「E2E暗号化への期待」という固有の構造を持ちます。本記事ではネイティブ vs クロスプラットフォームの判断、ストア審査の罠、Push通知設計、In-App Purchase の現実までを整理します。
このカテゴリの他の記事
モバイルアプリの固有制約
Webとの最大の違いは2OSへの同時提供です。同じ機能を別技術スタックで作るか、共通スタックで2OSを覆うかが最初の判断になります。
flowchart TB
APP[モバイルアプリ専業]
A[① 2OS対応<br/>iOS + Android]
B[② ストア審査<br/>Apple / Google]
C[③ 30%手数料<br/>App内決済義務]
D[④ Push / 端末固有機能<br/>センサ・カメラ・位置]
APP --> A
APP --> B
APP --> C
APP --> D
classDef root fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef cons fill:#fee2e2,stroke:#dc2626;
class APP root;
class A,B,C,D cons;ネイティブ vs クロスプラットフォーム
| 方針 | 代表技術 | 強み | 弱み |
|---|---|---|---|
| ネイティブ | Swift（iOS）/ Kotlin（Android） | OS新機能即対応・最高性能 | 2OS別開発で工数2倍 |
| クロス（React Native） | TypeScript | Web人材を流用、UIライブラリ豊富 | OS新機能の遅れ・チューニング難 |
| クロス（Flutter） | Dart | 1コードベース・UI性能良好 | Dartの人材市場が薄い |
| クロス（Kotlin Multiplatform） | Kotlin | iOSにもKotlin、ロジック共有特化 | iOS UIは別途必要 |
| WebView ラッパ（Capacitor） | TypeScript | Web資産流用最大 | UX劣化・審査リスク |
2026年時点の本命はFlutter または React Nativeで、ネイティブはOS新機能を即取り込む必要がある領域（金融・カメラ・地図）に絞るのが合理解です。WebView ラッパはApple審査でリジェクトされやすいため、新規プロジェクトでは避けるのが無難です。
推奨スタック
| 領域 | 推奨 | 理由 |
|---|---|---|
| クライアント | Flutter / React Native | 2OS同時開発、人材市場が厚い |
| バックエンド | Node.js / Go + Firebase / Supabase | スピード重視、認証・Push統合 |
| 認証 | Firebase Auth / Auth0 / Clerk | ソーシャル連携・電話番号認証 |
| Push通知 | FCM (Firebase Cloud Messaging) | iOS/Android共通 |
| 課金 | RevenueCat | App Store/Google Playの差を吸収 |
| クラッシュレポート | Firebase Crashlytics / Sentry | OS別の落ちパターン把握 |
| 配布 | TestFlight / Firebase App Distribution | β版配布の標準 |
| CI/CD | GitHub Actions + Fastlane | ストア配布の自動化 |
ストア審査の罠
App Store Review は人間レビュアーが見るため、ガイドラインの解釈次第で1〜2週間遅延が普通に発生します。代表的なリジェクト理由を押さえておきます。
| リジェクト理由 | 対策 |
|---|---|
| 機能不足（“thin app”） | MVPでもネイティブUIを最低限作り込む |
| WebViewの過剰利用 | 主要機能はネイティブ実装に寄せる |
| In-App Purchaseを使わない決済 | デジタルコンテンツは強制IAP（30%手数料） |
| 個人情報取得の目的不明確 | プライバシーマニフェスト明記 |
| 子供向けでの広告SDK混入 | KidsカテゴリならSDK制限 |
リリース直前の「審査で1週間止まる」を前提にスケジュールを組みます。マーケティング日と審査終了日に1週間以上のバッファが必須です。
In-App Purchase と手数料
| 売上規模 | Apple手数料 | Google手数料 |
|---|---|---|
| 年100万ドル未満 | 15% | 15% |
| 年100万ドル超 | 30% | 30% |
| サブスク2年目以降 | 15% | 15% |
物理商品・サービス予約は外部決済OKですが、デジタルコンテンツ・サブスクはプラットフォーム決済が強制です。RevenueCat等のサブスク管理SaaSを使えば、両ストアの差を吸収しつつ収益分析を一元化できます。
| 課金タイプ | 必須プラットフォーム決済 |
|---|---|
| デジタル商品（コイン・スタンプ） | はい |
| サブスク（読み放題等） | はい |
| 物理商品（EC） | いいえ（Stripe等可） |
| 旅行・宿泊予約 | いいえ |
| 寄付 | いいえ |
決めるべきこと — あなたのプロジェクトでの答えは？
| 項目 | 選択肢の例 |
|---|---|
| クライアント技術 | ネイティブ / Flutter / React Native |
| バックエンド | 自社サーバ / Firebase / Supabase |
| 認証方式 | メール / SMS / SNSログイン / Passkey |
| 課金方式 | App内決済 / 外部決済（物理のみ） |
| Push通知 | FCM / APNs直 / OneSignal |
| オフライン対応 | あり / なし / 部分対応 |
| 端末固有機能 | カメラ / GPS / Bluetooth / NFC |
| 配信戦略 | 段階リリース / 全展開 |
モバイル固有の鬼門
| 禁じ手 | なぜダメか |
|---|---|
| WebView だけのアプリ | Apple “thin app” でリジェクト、UX も悪い |
| デジタル決済を Stripe 直連携 | App Store ガイドライン違反、強制リジェクト |
| OS バージョン下限を最新だけ | 既存ユーザーが使えなくなる、過去2バージョンサポートが定石 |
| Push 通知の権限を起動直後に要求 | 拒否されると後から再取得困難、文脈ある場面で要求 |
| クラッシュレポートを入れない | 本番障害が見えない、Crashlytics 必須 |
| アプリ内ハードコードAPIキー | 逆コンパイルで漏洩、サーバ経由で取得 |
| 強制アップデートを乱発 | ユーザー離脱、互換性を保てる設計を |
| iOS と Android で UI 完全一致を目指す | 両OSのHIGに違反、それぞれの作法に寄せる |
AI時代の視点
| AI時代に有利 | AI時代に不利 |
|---|---|
| Flutter / React Native（学習データ豊富） | ニッチクロスプラットフォーム |
| TypeScript / Dart 型安全 | 動的型付け中心 |
| Firebase / Supabase（コード生成精度高い） | 自社プロトコル独自実装 |
| OS標準API（HealthKit・StoreKit2） | 独自Bridge実装 |
オンデバイスLLM（Apple Intelligence・Gemini Nano）が標準化される2026年以降、クライアント側でAI推論を動かすか、サーバ側で動かすかの選定軸が新しく立ち上がります。プライバシー要件が高い領域はオンデバイス、複雑タスクはサーバ側、というハイブリッドが定石化しつつあります。
最終的な判断の仕方
モバイル専業の核心は「2OS・ストア審査・30%手数料の三重制約のもとで、UX を落とさない構成を選ぶ」ことです。Webと同じ感覚で「全部TypeScriptで」と進めると、ネイティブ機能の遅れや審査リジェクトで手戻りします。
決定軸は「OS新機能依存度」と「人材市場」の2つで、新機能依存度が高いならネイティブ、それ以外は Flutter / React Native が2026年の本命です。
選定の優先順位
- 新機能依存度を見極める — Apple Intelligence・HealthKit即対応ならネイティブ
- クロス採用なら Flutter / RN に絞る — マイナーは人材で詰む
- 課金タイプから決済方式を決める — デジタルは強制 IAP
- Push・クラッシュレポート・配布CI を最初から入れる — 後付けは事故の元
まとめ
本記事はモバイルアプリ専業のケースについて、2OS対応・ストア審査・IAP手数料・Push通知・AI時代のオンデバイス推論まで含めて解説しました。如何だったでしょうか。
技術はFlutter / RN を本命に、ネイティブは新機能依存領域だけ、ストア審査は1週間バッファ、決済は強制 IAP を前提。これが2026年のモバイル専業の現実解です。
次回は「AIプロダクト・スタートアップ」のケースについて解説します。LLM API依存・推論コスト・データ整備の特殊事情を扱う予定です。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（85/89）