本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第1弾として、システムアーキテクチャで最初に決めるアプリケーション形態の選定について解説する記事です。
PCインストール型・ブラウザ越し・スマホアプリ──この問いの答えが、雇う人間のスキル・売り方・撤退時の損失まで下流設計をほぼ全て縛ります。本記事ではネイティブ／Web（SaaS/PaaS/IaaS/FaaS）／ハイブリッドの3分類、内側の細分化、ケース別の判断基準を解説します。
このカテゴリの他の記事
そのシステム、どこで動かしますか
新規プロジェクトの最初の1週間で、必ず一度は問われる問いです。「そのシステム、どこで動かしますか」この問いは単なる技術選定ではなく、ビジネスの形そのものを決めます。
PCソフトとして販売するのか、サブスクリプション（月額課金で継続利用させる販売方式）のWebサービスにするのか、スマホアプリにするのか。答え次第で、開発者のスキルセットも、営業の戦い方も、顧客サポートの体制も、全部変わります。
「PCソフトを配る」以外の選択肢がほぼなかった時代から、Webとクラウドとスマホが揃った今までで、この問いの答えは一気に広がりました。1990年代までは、アプリケーションといえば店頭でパッケージを買ってインストールするものでした。2000年代にブロードバンドとブラウザが成熟してWebアプリが現実解になり、2007年のiPhone登場でスマホアプリが新たな主戦場になり、2010年代のクラウド普及でサーバー調達が従量課金になりました。選択肢が広がった分だけ、間違えたときの後戻りは重くなっています。
形態はあとから直せません。直そうとするなら、ゼロから作り直す覚悟が要ります。Webアプリとして作ったものを後からネイティブに移植するのは、UIの作り直し・オフライン対応の追加・ストア審査対応を含めると、実質的に新プロジェクトと同じ工数が発生します。
業界では「途中で形態を変える」プロジェクトをいくつも聞きますが、終わった頃にはチームの半分が辞めていた、という話も珍しくありません。だからこそ、最初の形態選定は他のどの技術判断よりも慎重に行う価値があります。形態選定は、あとから直すと事実上の作り直しです。初週で言語化できないなら、着手を1週間遅らせるほうが安いです。
3つの基本形態
アプリケーション形態の選択肢は、大きく3つに分類されます。どれかが全部勝ちということはなく、得意分野と刺さらない分野がはっきり分かれています。
flowchart LR
USER([ユーザー端末])
SERVER([サーバ])
NATIVE["ネイティブ<br/>(端末で直接実行)<br/>Windows/iOS/Android"]
WEB["Web<br/>(サーバで実行)<br/>Gmail/Notion/Slack"]
HYBRID["ハイブリッド<br/>(端末で実行 + Web技術)<br/>Electron/Flutter/RN"]
USER -.|高速・ハードウェア制御|.- NATIVE
USER -.|配布の摩擦ゼロ|.- WEB
USER -.|配布◎+クロスプラットフォーム|.- HYBRID
NATIVE -. インストール .-> USER
HYBRID -. インストール .-> USER
WEB --> SERVER
classDef native fill:#dbeafe,stroke:#2563eb;
classDef web fill:#fef3c7,stroke:#d97706;
classDef hybrid fill:#fae8ff,stroke:#a21caf;
class NATIVE native;
class WEB web;
class HYBRID hybrid;| 形態 | 稼働場所 | 代表例 |
|---|---|---|
| ネイティブアプリケーション | クライアント端末 | Windowsソフト・iOSアプリ |
| WEBアプリケーション | サーバー側 | Gmail・Notion・Slack（Web版） |
| ハイブリッドアプリケーション | クライアント端末（WEB技術で実装） | Electron・Flutter・React Native |
この3分類は、「コードがどこで実行されるか」という観点での分け方です。ネイティブはユーザーの端末の上で直接動き、Webはサーバー上で動いてブラウザに結果を届け、ハイブリッドは「端末上で動くが中身はWeb技術」という折衷です。
稼働場所の違いは、配布方法・性能特性・更新の手間・プラットフォーム依存性のすべてに波及します。
「とりあえずこれ」で選んではいけません。なぜこの形態なのかを一言で言えないまま着手したプロジェクトは、途中で設計が歪んで戻れなくなります。特にスタートアップや新規事業では、形態選定を先送りにして「まずはプロトタイプを」と始めた結果、プロトタイプの形態がそのまま本番になって後悔するパターンを何度も見ます。プロトタイプは最終形態で作るのが鉄則です。
ネイティブアプリケーション
ネイティブアプリケーションとは、端末のOS（Operating System、Windows や macOS、iOS などの基盤ソフトウェア）上で直接動くアプリです。Windowsの .exe、macOSの .app、iPhone/Androidのアプリ。要するにブラウザを経由しないもの全般がここに入ります。
コンピュータの歴史の大半は、この形態が主役でした。1970年代のメインフレーム時代から1990年代のPC時代まで、「ソフトを使う」とは「物理メディアからインストールする」と同義でした。
ネイティブの主な種類は次の通りです。
- PCソフト（会計ソフト・画像編集ソフト・ゲーム等）
- スマホアプリ（LINE・Instagram・カメラアプリ等）
- 組み込みシステム（ATM・自販機・カーナビ等）
- バッチ処理（夜間一括処理・ETL処理等）
ネイティブの最大の武器は性能とハードウェア直接制御です。GPU（Graphics Processing Unit、画像処理専用の演算チップ）を叩いてリアルタイムレンダリングを回す、カメラのセンサーに生アクセスする、Bluetooth で機器を細かく制御する、ローカルストレージを全速力で読み書きする。こうした要件は、ブラウザのサンドボックス（安全のためWebコードの実行権限を制限する仕組み）越しでは現実的に実現できません。
動画編集ソフト・ゲーム・3Dモデリングツール・組み込み機器・高頻度取引システムなどが、いまもネイティブの独壇場である理由はここにあります。
一方で、弱点は配布と更新に集中しています。ストア審査を通す必要がある、ユーザーに更新操作を促さねばならない、OSごとに実装を分ける必要がある。この3つが運用の足枷として重くのしかかります。
Apple の App Store 審査で2週間待たされた挙げ句リジェクトされて差し戻し、という経験をしたチームは、二度とネイティブを「気軽に」選ばなくなります。Webやハイブリッドが広がったのは、この足枷から逃げたかったからでもあります。それでも、ネイティブでしか解けない問題は今も存在し続けているというのが2026年時点の現実です。
組み込み・ゲーム・クリエイティブ系は今もネイティブの主戦場です。0.1秒の遅延とハードウェア直接制御が絡むなら、迷わずここを選びます。
WEBアプリケーション
WEBアプリケーションは、HTML・CSS・JavaScript をブラウザで動かす形態です。Gmail、Notion、Google Docs、Slack、Figma。URLを開くだけで使え、インストールも更新操作も要りません。
この「摩擦ゼロで届けられる」性質が、新規プロジェクトのデフォルト候補をWebに固定しました。
Webの技術的な転換点は2つあります。1つは2005年頃の Ajax（Asynchronous JavaScript and XML、ページ全体をリロードせずサーバーと通信する技術）普及で、非同期通信によって「ページ遷移せずに画面を更新する」ことが可能になり、Web でもネイティブに近いインタラクションが作れるようになりました。
もう1つは2010年代後半の SPA（Single Page Application、最初に読み込んだ1ページ内で画面遷移を完結させる方式）の成熟で、Gmail や Notion のような「Webだが体感はアプリ」な製品が一般化しました。
開発側から見たWebの最大の武器は、配布の苦労が構造的に消えることです。デプロイ（作ったコードを本番サーバーに配置する作業）1回で全世界のユーザーが即最新版になる。バグを見つけたら30分で修正版を届けられる。この機動性は、ストア審査で数日〜数週間待たされるネイティブとは比較になりません。
SaaS ビジネスが過去20年で爆発的に拡大した背景には、この「即時配布」が支えるリーンな開発サイクルがあります。
WEBアプリケーションは、提供形態でさらに4種類に分岐します。
- SaaS（Software as a Service） ― 完成済みアプリをそのまま使わせる
- PaaS（Platform as a Service） ― 開発環境ごと貸し出す
- IaaS（Infrastructure as a Service） ― 仮想サーバーを貸し出す
- FaaS（Function as a Service） ― 関数だけ預かって呼ばれた時に動かす
乗り物で例えるなら、SaaSは配車タクシー、PaaSはカーシェア、IaaSは月極駐車場、FaaSは呼べば来るタクシー。どこまで自分で整備したいか、それだけが違います。どれを選ぶかで、自社で管理する範囲（＝責任を負う範囲）と、自由度が反比例します。
Webの強みは「インストール不要・即配信」の1点。ここに全てのビジネス的優位が紐づいています。
SaaS（Software as a Service）
SaaS は、完成済みアプリをインターネット越しに貸すモデルです。Gmail、Notion、Slack、Google Workspace、Salesforce。ブラウザとログインさえあれば、ユーザーは1秒で使い始められます。ソフトウェアを「所有」するのではなく「利用」する形態で、月額・年額のサブスクリプション課金が基本です。
SaaS が登場した意義は、単に「Webで動く」ことではありません。本質はマルチテナント型アプリケーション。1つのアプリケーションで複数の顧客（テナント）のデータを論理的に分離して提供する方式です。
顧客ごとに別々のサーバーを立てるのではなく、共通のインフラを全顧客で共有することで、ベンダーはスケールメリットを最大化でき、顧客は安価にサービスを受けられます。1999年に Salesforce がこのモデルを提示したとき、従来のパッケージソフト業界は「データを他社と同じサーバーに置くなどありえない」と一蹴しましたが、今や業務ソフトウェアの主流は完全にSaaSに移行しました。当時の「ありえない」は、四半世紀経った今では「当たり前」になっています。
| メリット | デメリット |
|---|---|
| 世界中にサービス提供可能 | カスタマイズ性が低い |
| 手軽（インストール不要） | ベンダー障害の影響を受ける |
| クライアント性能に依存しない | ベンダー依存（ロックイン） |
| 常に最新の機能 | 継続費用・オフライン不可 |
技術側の定義（マルチテナント型アプリ）とビジネス側の定義（サブスク型のWebサービス全般）はしばしばズレます。ビジネス現場で「これもSaaSだよね」と言われたとき、相手がどちらの意味で使っているかはいちいち確認しておくのが無難です。
シングルテナント（顧客ごとに独立インスタンス）なら運用負荷は跳ね上がり、ほぼ受託開発の延長になります。この2つを混同したまま提案書を書くと、見積もりがオーダーで狂います。
BtoB/BtoCの新規プロダクトはSaaS一択から入るのが定石です。外す理由を1分で書き出せなければ、外さないほうが安全です。
PaaS（Platform as a Service）
PaaS は、アプリの実行環境をまるごと借りるモデルです。OS・ミドルウェア（アプリとOSの間に入って共通機能を提供するソフト）・ランタイム（プログラムを動かす実行系）・スケーリング（負荷に応じてサーバーを増減させる機構）が一式セットアップ済みで、開発者はコードだけ書けばよい状態で渡されます。
git push したらデプロイが完了し、負荷が上がれば自動でインスタンスが増える。この体験を最初に定着させたのが、2007年にサービス開始した Heroku でした。
PaaS の肝は、「OSやミドルウェアを触る時間」を開発者の仕事から消すことにあります。サーバーOSのアップデート、nginx（高性能なWebサーバーソフト）の設定、SSL 証明書の自動更新、デプロイスクリプトの整備。こうした「アプリの本質的価値と無関係な雑務」を、PaaS ベンダーがまとめて代行してくれる。
個人開発者やスタートアップにとって、この時間の買い戻しは決定的な価値があります。夜中に証明書の更新を忘れてサービスが落ちた経験が一度でもある人なら、PaaS の価値は説明不要で伝わります。
| メリット | デメリット |
|---|---|
| 開発効率向上 | IaaSより自由度が低い |
| コスト削減（初期投資不要） | ベンダー依存 |
| 環境の複製が簡単 | オフライン環境で動かせない |
| 自動スケーリング | 独自要件への対応が難しい |
代表例は Heroku（元祖、ただし2022年に無料枠廃止で個人開発の主役から退いた）、Vercel（Next.js特化）、Fly.io・Render・Railway（Heroku無料枠廃止後の受け皿として個人開発で伸びた新勢）、Cloudflare Pages、Salesforce Platform、そして AWS/GCP/Azure のマネージドサービス群（App Runner、Cloud Run、App Service 等）。
2026年時点で個人開発の第一候補は Fly.io / Render / Railway、商用スタートアップの第一候補は Vercel（フロント）+ Cloud Run / App Runner（バック）の組み合わせです。
新規アプリは原則PaaSから始めます。IaaSに降りる判断は、「なぜPaaSでは駄目か」を1分で説明できるときだけ許されます。PaaS を選ばない正当な理由は限られます。特殊なカーネルモジュール（OSの中核を拡張する低レイヤ部品）が要る、GPUインスタンスが要る、VPC内（Virtual Private Cloud、クラウド上に論理的に隔離したプライベートネットワーク）の既存リソースと直結する必要がある、コンプライアンス上OSイメージの中身を監査する必要がある。これらに該当しないなら、PaaSが無難です。
「なんとなくIaaSのほうが安そう」で降りると、運用コストが人件費で跳ね返ってきます。月3万円のIaaSが、人件費込みで実質月30万円になる構造を見落とすと、経営判断そのものを間違えます。
OSを自分で触る理由がない案件は、全部PaaSで始めるのが鉄板です。迷いどころではありません。
IaaS（Infrastructure as a Service）
IaaS は、仮想サーバー（物理マシン上にソフトウェア的に切り出した擬似サーバー）をインターネット越しに借りるモデルです。AWS EC2、Google Compute Engine、Azure Virtual Machines。「サーバーを月額で借りる」という、一番わかりやすい形態です。
2006年に AWS EC2 がローンチされるまで、サーバーといえば物理マシンを買って電源とネットワークを引くオンプレミス（自社設備で運用する形態）が常識でした。初期投資数百万円、リードタイム数週間。EC2 はこれを「数分・クレジットカード決済」に変えました。
スタートアップがゼロからプロダクトを立ち上げられるようになった根本的な変化は、ここから始まっています。物理サーバー発注の常識が崩れて、試作に必要な資金と時間が劇的に下がり、Airbnb や Dropbox や Slack は全て EC2 の時代の子として生まれました。この変化がなければ、ユニコーン（評価額10億ドル超の未上場スタートアップ）と呼ばれる企業群の多くは存在しなかったはずです。
| メリット | デメリット |
|---|---|
| 高い自由度（何でもできる） | 専門知識が必要 |
| オンプレミスより安価 | OS・ミドルウェアの管理が必要 |
| ハードウェア不要 | セキュリティ対策は自前 |
| BCP対策がしやすい | PaaSよりコスト増加しやすい |
ただし2007年の Heroku 登場以降、「PaaSのほうがさらに楽だ」が広まって、抽象度が高い方へ需要が流れました。2013年の Docker（アプリと実行環境を軽量な箱＝コンテナに詰めて配布する仕組み）、2015年の Kubernetes（複数のコンテナを束ねて自動配置・自動復旧させるオーケストレーションツール）普及で「コンテナを PaaS 的に動かす」構成が一般化し、素の IaaS を選ぶ必然性はさらに下がりました。
いま素の IaaS を選ぶのは、コンプライアンス要件か、PaaSでは実現できない特殊要件があるときに限られます。「勉強になる」でIaaSを選ぶのは甘い選択です。業務時間で学ぶべきはアプリの価値であって、OSパッチの当て方ではありません。
FaaS（Function as a Service）
FaaS は、関数1つだけを預けて、呼ばれたときだけ実行してもらうモデルです。AWS Lambda（2014年登場）、Google Cloud Functions、Azure Functions、Cloudflare Workers が代表格で、使っていない時間は1円もかからない完全従量課金です。「サーバーレス」という言葉が定着したのは、このモデルが広まってからです。
FaaS の核心は、インフラを「常時動いているもの」から「呼ばれたときだけ動くもの」に再定義したことにあります。従来のサーバーは、アクセスがゼロでも立ち上げている限り課金が発生しました。FaaS は「実行時間 × メモリ量 × リクエスト数」だけで課金するため、月数回しか叩かれない処理のコストがほぼゼロになります。
夜間バッチ、Webhook（外部サービスからイベント発生時に呼ばれるHTTPコールバック）処理、管理用API、画像サムネイル生成。こうした間欠的なワークロードで、FaaS は圧倒的に有利です。
| メリット | デメリット |
|---|---|
| 実行環境を意識せず実装できる | カスタマイズ性が低い |
| 従量課金で安価（実行分だけ） | コールドスタート（初回遅延） |
| 自動スケール・無限並列 | デバッグが難しい |
| 迅速に稼働可能 | 長時間処理に制限（数分単位） |
一方、常時稼働のWebサーバーをFaaSでやるのは典型的な筋が悪い選択（相性が悪く結果的に損をする選択）です。アクセスが途切れるとコンテナが破棄され、次のリクエストで再起動が必要になるコールドスタート（未起動の関数が呼ばれたとき起動〜実行まで遅延する現象）問題が刺さります。
Node.js なら初回100〜500ms、JVM 系なら2〜5秒のペナルティが毎回乗ります。これはユーザー体験を確実に削る要素で、ユーザーは自分の操作が重いのか自分の回線が遅いのかを区別してはくれません。「なんか遅い」と思われた時点で負けです。常時稼働のAPIなら素直にPaaSやコンテナサービスを選ぶべきです。
常時稼働型APIにFaaSを使ってはいけません。最初に間違えやすい地雷で、あとからコールドスタート対策で徹夜する羽目になります。
ハイブリッドアプリケーション
ハイブリッドアプリケーションは、Web技術（HTML/CSS/JS）で作ったものを、ネイティブアプリの皮をかぶせて配布する形態です。スマホ向けが主戦場で、iOS と Android を1つのコードで賄えるのが最大の武器です。2つのOSそれぞれに別チームを雇う体力がないプロジェクトにとって、ハイブリッドは事実上の標準解になっています。
ハイブリッドには大きく2つの系譜があります。1つは WebView 型（Cordova、Ionic）で、ネイティブアプリの中にブラウザを埋め込んで Web ページを表示する方式です。実装が楽な反面、動作がブラウザそのもので重くなりがちです。
もう1つは ネイティブ描画型（React Native、Flutter）で、JavaScript や Dart で書いたコードをネイティブのUI部品にマッピングして描画します。動作が軽く、ネイティブに近い体験を得られます。2026年の現場では、ネイティブ描画型が主流です。
ハイブリッドの特徴をまとめると以下の通りです。
- OSに依存せず動作可能（最大の特徴）
- Web系エンジニアが開発できるため人材確保が容易
- ネイティブアプリより動作が重くなりがち
- ブラウザに近い操作感で違和感が出る場合あり
代表は React Native（Meta）、Flutter（Google）、Ionic、Electron（デスクトップ）。Flutter と React Native は、iOS/Android を別チームで回す体力がない案件の本命で、人を2倍雇う代わりにフレームワークに頼る選択です。ネイティブ相当の体験が要る一部機能だけネイティブで書き、残りをハイブリッドで済ませる折衷も普通に通ります。実際、Instagram や Discord は React Native と一部ネイティブの混在構成で運用されています。
ハイブリッドの地雷として知られているのが、ネイティブ機能の深いところへのアクセスです。Bluetooth の細かい制御、カメラの深度センサー、Push通知の細部。こうした領域では、ハイブリッドのプラグインがネイティブAPIの更新に追いつかず、ある日突然動かなくなることがあります。「OS更新後にアプリが落ちる」事件の多くは、実はこのプラグイン周りで発生しています。
iOS/Android両対応はハイブリッドから検討するのが定石です。ネイティブを選ぶなら「なぜハイブリッドでは駄目なのか」を即答できるときだけです。
WEB vs ネイティブの決め手
Web とネイティブの分岐は、要するに性能と配布の綱引きです。どちらに振るかが決まれば、残りは自動的に埋まります。判断を迷ったときは、以下の観点で比較します。
| 観点 | Webアプリ | ネイティブアプリ |
|---|---|---|
| 配布・更新 | URL開くだけ | アプリストア経由 |
| クロスプラットフォーム | ◎ | ×（再実装が必要） |
| 性能 | 中〜高 | 最高 |
| ハードウェア直接制御 | 限定的 | 完全 |
| オフライン動作 | 限定的（PWA） | ◎ |
| 初回起動速度 | 遅い | 速い（インストール済み） |
「0.1秒の遅延が致命傷」「ハードウェア直接制御」「オフライン必須」の3つのいずれかが外せないならネイティブ。それ以外はWeb。これが経験則です。ゲーム・動画編集・CADソフト・医療機器のUI・金融トレーディング端末などは、0.1秒の遅延がそのまま価値の劣化になるので、いまもネイティブ以外の選択肢は実質的にありません。
判断に迷ったら、似た業務を既に作っている会社がどちらで作っているかを調べるのが一番早い方法です。同業他社が全てWebで提供しているのに自分だけネイティブで作る、あるいはその逆。こうした逆張りには、ほぼ例外なく後悔が待っています。先行者の判断には、市場が教えてくれた合理性が詰まっています。
それを無視するなら、その判断を覆すだけの根拠が手元になければなりません。「なんとなく差別化したい」は根拠にならず、技術選定の理由にはなりません。
PWA（Progressive Web Apps、Webをネイティブに近い体験で提供する技術）は「ほぼネイティブ」を実現できますが、iOSでの機能制限が多いです。フル機能が必要ならハイブリッドかネイティブへ進みます。
ケース別の選定指針
形態は「誰が・どこで・何をしたいか」で9割決まります。典型的なケースと推奨形態を整理します。
一般的なケース
| ケース | 推奨形態 |
|---|---|
| 利用者・端末・場所に依存しないサービス | WEBアプリ（SaaS） が基本 |
| 0.1秒レベルの遅延が致命的な業務 | ネイティブアプリ（PCソフト） |
| スマートフォン向けサービス | スマホアプリ または ハイブリッド |
社内業務システムは Web 一択です。端末を問わず使え、更新が全員に同時に届き、運用の負担が最小になります。オンプレ時代にありがちだった「特定のバージョンのIEでしか動かない謎の業務ソフト」は、2020年代にはサポート終了と共に完全に葬られました。今から業務系を新規に作るなら、Webから外れる理由を探すほうが難しいです。
ゲームや動画編集ソフトはネイティブ以外に現実的な解がなく、この手の領域でWebを選ぶのは筋が悪い判断です。ブラウザでも WebGL（Webブラウザ上で3D描画を行うAPI）や WebGPU（次世代のWeb向けGPUアクセスAPI）で3D描画は可能ですが、AAAゲーム（大手スタジオが制作する最高品質タイトル）レベルの体験を Web で提供する試みは、何度も挑戦されては実用化の壁に跳ね返されています。Google Stadia（2019-2023）の撤退が象徴的で、大資本でも性能と遅延の壁は崩しきれませんでした。
尖ったケース
もう少し特殊なケースを整理します。ここはWebに無理やり寄せると破綻する領域です。
| ケース | 推奨形態 |
|---|---|
| 街中・店舗に専用端末を設置して使わせたい | ネイティブ / 組み込みシステム |
| 大量データを一括で加工処理したい | ネイティブ（バッチ処理） |
| 開発用プラットフォームをユーザーに提供したい | 大手クラウドが既に展開済みで新規参入は非推奨 |
ATM・自販機・カーナビのような専用端末は、リアルタイム制御と高い信頼性、そしてネットワーク切断時にも動き続けることが要求されます。組み込み系ネイティブ以外は現実解ではありません。こうした領域に Web ベースで参入する試みは、ラボレベルでは時々見ますが、量産に耐える信頼性を満たした事例はほぼありません。
PaaS 事業への新規参入は、AWS/GCP/Azure が分け合っている市場で、個人・小規模が勝負する場所ではありません。やめておけ、が本音です。例外はニッチな特化型（Vercel の Next.js 特化、Supabase の Firebase 対抗など）で、明確な差別化軸がある場合のみ勝負が成立します。漠然と「汎用PaaSを作りたい」と始めたスタートアップは、これまで見てきた限り全部消えました。
フェーズ別の形態選定
同じプロダクトでも、フェーズが違えば正解が変わります。MVP（Minimum Viable Product、最小限機能の検証版）で Electron を選んだのに成長期で Web に作り直し、という事例は珍しくありません。フェーズと形態の相性をいつ・何を・どこまでで整理すると次の通りです。
| フェーズ | 月アクティブユーザー目安 | 推奨形態 | 判断軸 |
|---|---|---|---|
| MVP・検証 | 〜1,000 | WEBアプリ（SaaS + Edge/Serverless） | 配布摩擦ゼロ・1日1デプロイ |
| 初期成長 | 1,000〜10万 | WEBアプリ（SaaS + CDN + マネージドDB） | スケールはクラウド任せ、コード側に集中 |
| スケール期 | 10万〜100万 | WEB + 必要に応じてハイブリッドスマホ | CV率でスマホアプリ化を判断（ブラウザで30%切ったら検討） |
| エンタープライズ | 100万〜 | WEB + ネイティブ + 組み込み（用途別） | 性能・コンプライアンス要件で複数形態を許容 |
MVP で Electron・React Native・Flutter を最初から選ぶのは大抵過剰です。ブラウザで触れる Web を作ってから、「ユーザーの7割がスマホから来ている」「継続利用の7割はオフライン」などの実測値が揃ったあとにネイティブ化する順序が現実的です。順序を逆にすると、検証フェーズをスマホストア審査（iOS 数日〜数週間）に溶かします。
スケール期での判断の分岐点は、ブラウザ経由のコンバージョン率（CV率、サイト訪問者のうち目的のアクション＝購入や登録に至った割合）が 全体の30%を切るかどうか です。モバイルトラフィックの7割以上がアプリ経由になったタイミングで、ブラウザ版の体験劣化がビジネスを削っている可能性が高く、このときに初めてネイティブ化の投資対効果が合います。逆に言えば、ここに達するまではブラウザ版を磨き込むほうが賢明です。
MVPでネイティブはほぼ罠です。Webで仮説検証してから形態を上げるのが順序で、逆は地獄を見ます。
形態移行の鬼門・禁じ手
形態を途中で変える判断は、事実上の作り直しです。それでも変えざるを得ない場面で踏みがちな罠を整理します。
| 禁じ手 | なぜダメか |
|---|---|
| Web → ネイティブを「そのまま移植」 | WebのDOM前提UIをネイティブに写すと性能も体験も劣化。UIは作り直しが前提 |
| ネイティブ → Web をリリース直前に決める | iOS/Android の動作仕様差・オフライン前提がWebで再現できず間に合わない |
| Electron/RN/Flutter を「両OS対応できるから」だけで採用 | ネイティブ機能（Bluetooth・カメラ深度・Push通知の細部）でプラグインが追いつかず地獄 |
| FaaS を常時稼働API の移行先にする | コールドスタートで毎回UXを削る。Edge Runtime かコンテナが本命 |
| ハイブリッドアプリをストア審査なしで配布 | iOS は Enterprise 配布でも審査・署名の制約あり。TestFlight/MDM の前提確認を飛ばすと詰む |
形態移行の鉄則は「両形態を3〜6ヶ月併走させる」ことです。旧形態を止めながら新形態を作るのは、障害発生時に戻る場所がなくなる典型的な地雷です。新形態のリリース直後は必ず想定外の問題が噴き出します。
旧形態が生きていれば一時的にそちらへフェイルバックできますが、先に止めていれば全面障害になります。移行前夜に「旧サーバーはもう止めちゃいました」と報告されたときの、あの冷や汗は二度と味わいたくない類のものです。
もう1つの鉄則は、移行のスコープを絞ることです。全機能を一気に移行する「ビッグバン移行」は、よほどの小規模でない限り失敗します。機能単位・ユーザー単位・リージョン単位で段階的に切り替えるストラングラーパターン（既存システムを段階的に置き換え、最終的に旧システムを絞め殺すように廃止する設計手法）が基本で、新旧両方が同時稼働する期間を前提に設計する必要があります。
形態移行は、併走期間を確保できない段階で着手してはいけません。退路を断った移行は博打であって、設計ではありません。
AI時代の視点
AI駆動開発（バイブコーディング、自然言語で指示するだけでAIがコードを書き上げる開発スタイル）が前提になった今、選定軸は人間の学習コストからAIの流暢さへ重心が移りました。
AIは自分が学習したデータの量と質に生成精度が比例します。Webは学習データが世界最大で、AIの生成精度がずば抜けて高い領域です。新規案件がWebに寄る流れは、ここからさらに強まります。
| AI時代に有利 | AI時代に不利 |
|---|---|
| Webアプリ（情報量・標準技術） | 各OS固有のネイティブ（情報量が分散） |
| React Native / Flutter 等のハイブリッド（1コード複数OS） | iOS/Android別実装（重複コストがAIでも変わらない） |
| IaaS+コンテナ+IaC（構成をコードで管理） | GUI操作前提のPaaS・独自管理コンソール |
| FaaS（コードだけ書けば良い）・Wasm（WebAssembly、ブラウザ等で動く高速な実行バイナリ形式） | 自前の複雑な実行環境構築 |
AI時代に有利な技術の共通点は、「コードで完結する」ことです。コードで書かれているものはAIが読めて書けますが、GUI上のクリック操作や独自コンソールでの設定は、AIが代行できない領域として残ります。IaC（Infrastructure as Code、インフラ構成をコードで管理する方式）がAI時代に相対的に価値を増したのは、この性質によるものです。
数年前まで「Terraform で全部書くのは大げさ」と言われていたのが、AIが入った今は「書いてないほうが大げさ」に逆転しました。
ただし物理（レイテンシ・ハードウェア・オフライン）は、AIが来ても1ミリも解決しません。AIに「レイテンシを10msにしろ」と言っても、光速の壁は越えられません。AIが楽に書ける形態と、要件を満たす形態の交点。これが新しい軸です。
GUI操作・独自管理コンソールへの依存は、AI時代の重い足枷です。コードで表現できないものは、これからも不利なままです。
AI時代のトレンド ― バックエンド最小化構成
AIが個人開発者を押し上げた2020年代後半、フロントはリッチに・バックは限界まで削る構成が一気に定着しました。アイドル課金ゼロの関数実行環境と CDN（Content Delivery Network、世界各地のサーバーに静的ファイルを分散配置して高速配信する仕組み）配信のフロントを組み合わせ、常時稼働のサーバーを持たない。個人でも月数ドル〜無料枠で本番運用が成立するようになり、参入障壁は歴史的な水準まで下がりました。これは1990年代の「自宅サーバーで個人サイト」以来の、個人開発にとっての地殻変動です。
ただし「バックエンド最小化＝FaaS一本」ではありません。いまこの構成は3つに分岐しています。FaaS（呼ばれたときだけ関数実行）、Edge Runtime（CDN拠点のサーバーで動く軽量ランタイム）、BaaS（Backend as a Service、認証・DB・関数を1社に寄せる方式）。アイドル課金ゼロは共通ですが、LLMストリーミングとの相性、ロックインの深さはそれぞれ違います。
| 構成 | 代表例 | 強み | 弱み |
|---|---|---|---|
| FaaS型 | AWS Lambda | 情報量豊富・各クラウドに類似サービス | コールドスタート・15分タイムアウト |
| Edge Runtime型 | Cloudflare Workers・Vercel Edge | コールドスタートほぼゼロ・ストリーミング得意 | Node互換が部分的・重い計算は不向き |
| BaaS型 | Supabase・Firebase・Convex | 認証・DB・関数を一括提供 | ロックインがきつい（Firebase/Convex）・料金の段差が急 |
LLM（Large Language Model、大規模言語モデル）応答のストリーミングが普及してから、Edge Runtime が主役交代しました。生成AI のレスポンスはトークン単位で数秒〜数十秒かけて流れてくるため、コネクションを維持しながら少しずつクライアントに転送する必要があります。
純粋なFaaS はこの用途にコールドスタートと最大実行時間の制約が刺さり、非同期バッチ寄りに後退しました。2026年時点でAIチャット・AI補助機能を組み込むWebサービスは、Edge Runtime を採用する割合が年々増えています。
BaaSのロックインには製品ごとの差があります。Firebase と Convex は独自APIとデータモデルに深く依存する設計で、剥がすなら実質作り直しです。一方 Supabase は Postgres + PostgREST + GoTrue 等のオープンソースの組み合わせで、セルフホスト可能・標準SQLで書けるため、撤退コストが相対的に軽い。
「BaaSは全てロックインが強い」は乱暴で、Supabase は「逃げ道のある BaaS」として位置付けると精度が上がります。新規採用時は「ベンダー停止時に何日で移行できるか」を見積もってから決めるのが安全です。
LLMストリーミングが絡む新規案件は、Edge Runtime がまず候補です。FaaSはバッチ・Webhook処理に住み分けます。
「勉強になる」で IaaS を選んだ週末（業界事例）
個人開発で小さな SaaS を立ち上げようとして、「勉強になる」という理由で AWS EC2 を借り、週末の2日を nginx と systemd（Linux の常駐プロセスを管理する仕組み）とドメインの設定に溶かし、PostgreSQL を手で起動し、Let’s Encrypt（無料のSSL証明書発行サービス）の更新 cron を書いて、ようやく Hello, World をインターネットに出したところで力尽きた。という話は、この業界の定番の通過儀礼として知られています。
当時すでに Heroku は、同じことを git push heroku main の1コマンドで済ませる無料枠を持っていました（2022年11月に無料枠は廃止され、今は Fly.io・Render・Railway あたりが同じ役割を引き継いでいます）。個人開発で「PaaSを選ばない理由を書き出せないなら、PaaSで始める」が唯一まともな判断だと、両方を触った人ほど口を揃えます。
形態選定は知識として知っていても、両方の環境を実際に触るまで実感は湧かない。典型的なパターンです。
「勉強」と「プロダクト開発」は別物として扱うのが健全です。インフラの勉強は業務時間外の素振りで、プロダクトを世に出す本番ラインはPaaSで始める。両者を混ぜると、本来プロダクトに投下すべき時間がインフラの雑務で蒸発します。蒸発した時間は返ってきません。2日溶かしたあと、Herokuに乗り換えて30分でデプロイが終わったときの虚無感は、一度味わうと二度と繰り返したくない類のものです。
「勉強になる」は最もコストの高い選定理由です。業務に持ち込めば、必ず誰かの時間を溶かします。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
アプリケーション形態を確定させるために、プロジェクト開始時に次の項目をクリアにしておきます。
- アプリケーション形態（Native / Web / Hybrid）
- Webの場合のサービス形態（SaaS / PaaS / IaaS / FaaS）
- 対応プラットフォーム（Windows / Mac / iOS / Android / Linux）
- オフライン動作要件
- 要求性能レベル（レイテンシ・スループット）
- 配信・更新の頻度と方式
- 初期コストと運用コストの上限
これらはプロジェクト開始の1週目に決めるべき項目です。先送りすると、下流の技術選定（言語・フレームワーク・クラウドベンダー）が仮決めのまま進み、形態が確定した時点で大規模な手戻りが発生します。形態選定は、後続の判断すべてを縛る最上流の意思決定だと認識しておく必要があります。
よくある失敗
- 流行だけでSaaSに寄せる ― 本当はデスクトップネイティブ向きの業務を無理やりWebにして、性能不足で評判を落とすパターン。動画編集・3Dモデリング・大量データ処理を安易にWeb化すると、ブラウザの制約（メモリ上限・タブクラッシュ）で必ず詰まります
- iOS/Androidでネイティブ別実装 ― 2倍の工数をかけて2倍の不具合を生む典型。ハイブリッドで十分だった案件は多い。両OS別実装が正当化されるのは、ゲームや金融系など「1msの差が致命的な領域」と、既にネイティブ開発者を大量に抱える大企業だけです
- FaaSで常時稼働API ― コールドスタートが毎回UXを削る。常時稼働型は素直にPaaSへ。1日数万リクエストを超える API なら、FaaS より Cloud Run や ECS Fargate のほうが総コストで下回ることが多いです
- 「勉強になる」でIaaS ― OSパッチ・証明書更新・ログローテ、全部「勉強」と思っていると、肝心のアプリが1ミリも進まない。PaaSで始めていれば最初のリリースが2週間は早まる
最終的な判断の仕方
形態はあとから変えられません。だから最初に 「何を一番優先するか」 を決めて、それを満たせない形態を潔く切り捨てるところから始めます。
物理要件（レイテンシ・ハードウェア制御・オフライン）を満たせない候補を消し、残った中でユーザー層と開発・運用リソースを突き合わせる。この順番が崩れると、あとで必ず揺り戻しが来ます。
ここにもう1本、AI時代の軸が加わりました。同じ要件を満たせる形態が2つあるなら、コードで完結するほう（Web/コンテナ/IaC） を選びます。GUI操作と独自コンソール依存はAIに任せられず、学習コストが人間側に重く残り続けるからです。この観点は2020年代前半まではノイズ程度の論点でしたが、AI駆動開発が前提となった今では第一級の判断軸になりました。
選定の優先順位をまとめると次の通りです。
- 物理要件で候補を絞る（満たせないものは除外）
- 到達範囲（全世界のブラウザか、特定端末か）でカテゴリを決める
- 開発リソース（人数・予算・スキル）で現実解に落とす
- AIとの相性を最後の差別化軸にする
「とりあえず流行で」は、いちばん高くつく選び方です。形態選定は、自社の強みをどこに賭けるかの意思表示でもあります。迷ったら Web で作る。ネイティブを選ぶ理由は、その場で書き出せるときだけです。
まとめ
本記事はシステムアーキテクチャで最初に決めるべきアプリケーション形態の選び方を解説しました。如何だったでしょうか。
迷ったらWeb。ネイティブの理由がその場で書き出せないなら、Webで始めるのが最適解です。形態はあとから変えられない最上流の意思決定なので、初週で言語化できるまで議論する価値があります。
次回はアプリケーション形態の次に決める「デプロイモデル」（オンプレ/クラウド/ハイブリッド）を解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（6/89）