モバイルアプリ（中規模・自前API）の推奨構成｜2026年版

先に要点

BaaSの制約を超えた中規模モバイルは、クロスプラットフォームのアプリ + 自前API + マネージドDBが2026年の基本形です。
具体的には、アプリは React Native / Flutter、APIは サーバーレス or コンテナ、認証は Auth0 / Cognito、プッシュは FCM / APNs。
[モバイル（個人・BaaS）](/playbook/mobile-baas)から移るのは、複雑なロジック・既存システム連携・BaaSロック回避が必要になったとき。
注意は BaaSより手間が増えること。サーバー側はWebアプリのパターンがそのまま使えます。

「モバイルアプリが育って、BaaSだけでは複雑なロジックや既存システム連携がさばけない」── この中規模では、裏側を自前のAPIで持つ構成に移ります。モバイル（個人・BaaS）からの一段アップです。

対象と前提

複雑なビジネスロジック、決済、既存システム連携があるモバイルアプリ
BaaSのデータモデルや制約では窮屈になってきた
複数人で開発・運用している
特定BaaSへのロックを避け、裏側を自分で制御したい

全体構成（リファレンスアーキテクチャ）

結論: 「アプリ → 自前API → マネージドDB」。サーバー側はWebアプリと同じ作りです。

読み込み中...

各層の具体的な候補は次のとおりです。

層	役割	具体的な候補(2026年)
アプリ	iOS/Android両対応	React Native(Expo) / Flutter
API(裏側)	独自ロジック・連携	サーバーレス([API個人](/playbook/api-serverless)) / コンテナ([API中規模](/playbook/api-container))
データベース	マネージドRDB	RDS / Aurora / Cloud SQL
認証	ログイン・トークン	Auth0 / Cognito / Clerk
プッシュ通知	OS別の通知配信	FCM(Android) / APNs(iOS)

裏側のAPIは、Webアプリのパターンがそのまま使えます。アクセスや負荷に応じて、サーバーレス(API（個人）)かコンテナ(API（中規模）)を選びます。APIゲートウェイの考え方はAPI Gateway+Lambdaが参考になります。

なぜこれを選ぶか

自由に作れる ── BaaSのデータモデルや制約に縛られず、複雑なロジックを実装できる
既存システムと連携しやすい ── 自前APIなら、社内システムや外部サービスとの連携を柔軟に組める
ロックを避けられる ── 特定BaaSへの依存を減らし、裏側を自分で制御できる(ベンダーロック)

セキュリティ

モバイルでも要点はWebアプリと同じです。全通信HTTPS、APIは認証必須(トークン検証)、秘密情報はアプリに埋め込まない、最小権限。とくにアプリ内に鍵やシークレットをハードコードしないこと(逆コンパイルで抜かれる)。認証はCognitoやAuth0などの既製を使い、自作しないのが安全です。

コスト感

2026-06時点の目安(公式で要確認)

BaaSより構成要素が増えるぶん、API実行・マネージドDB・認証サービス・プッシュ基盤の費用がかかります。APIはサーバーレスなら従量、コンテナなら常時起動ぶん。規模に応じて各サービスの料金を合算で概算します。BaaSの手軽さを手放す対価として、自由度と引き換えに運用コストが上がる点を見込んでおきます。

落とし穴

手間がBaaSより増える ── 認証・API・DB・通知を自分で組む。BaaSの「全部入り」の楽さは失われる
両OS対応 ── iOS/Androidの差(プッシュはFCM/APNsで別)や、ストア審査を考慮する
アプリ内シークレット ── 鍵をアプリに埋め込むと抜かれる。サーバー側で扱う
オフライン・同期 ── モバイル特有のオフライン対応やデータ同期は、設計に手間がかかる

スケール時の移行余地

ユーザーが増え、APIの負荷や可用性が課題になったら、裏側のAPIをAPI（中規模）やWebアプリ（大規模）の構成へ育てます。アプリとAPIが分離しているので、裏側だけを段階的にスケールできます。

よくある質問

Q. BaaSから自前APIへ、いつ移るべきですか？

A. 「複雑なビジネスロジックがBaaSで窮屈」「決済や既存システム連携が必要」「特定BaaSへのロックを避けたい」が現実になったときです。これらが無ければBaaS(モバイル個人)のままが手軽です。BaaSを認証やデータ基盤として残しつつ、必要な部分だけ自前APIに切り出す併用も現実的です。

Q. アプリはReact NativeとFlutter、どちらがいいですか？

A. チームのスキルで選ぶのが基本です。Web/JavaScriptの資産や人材があるならReact Native(Expo)、Dartに抵抗がなく高い描画性能や一貫性を重視するならFlutterが目安です。どちらも1つのコードでiOS/Android両対応でき、成熟しています。既存のWebチームならReact Nativeが入りやすいことが多いです。

Q. 認証は自分で作るべきですか？

A. 避けるのが安全です。モバイルの認証(トークン管理、リフレッシュ、ソーシャルログイン、生体認証連携)を正しく作るのは難しい領域です。Auth0やCognitoなどの既製サービスを使えば、これらを安全に任せられます。アプリには鍵を埋め込まず、認証はサーバー/既製サービス側で扱うのが鉄則です。

Q. プッシュ通知はどう実装しますか？

A. AndroidはFCM、iOSはAPNsという、OSごとの通知基盤を使います。多くはFCMを共通の窓口にしてiOSへも配信する形を取ります。自前APIから、ユーザーの端末トークンを管理して通知を送ります。通知の許可取得や、内容の出し分けはアプリ側で設計します。