本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第1弾として、システムアーキテクチャで最初に決めるアプリケーション形態の選定について解説する記事です。
PCインストール型・ブラウザ越し・スマホアプリ──この問いの答えが、雇う人間のスキル・売り方・撤退時の損失まで下流設計をほぼ全て縛ります。本記事ではネイティブ／Web／ハイブリッドの3分類と、ケース別の判断基準を解説します。
本記事のテーマについてさらに詳しく知りたい方は『システム設計のセオリーと実践方法がこれ1冊でしっかりわかる教科書』・『世界一わかりやすい IT業界のしくみとながれ』も参考にしてみてください。
この記事の結論
- 迷ったらWebを選ぶ
- ネイティブにする理由をその場で書き出せないなら、Webで始める
- MVPをネイティブ・ハイブリッドで作らない（検証はWebで）
- 形態は後から変えられない最上流の判断。初週で言語化する
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもアプリケーション形態とは何か
アプリケーション形態とは、ざっくり言えば「そのソフトウェアをユーザーにどうやって届けて使ってもらうかの基本形」です。
飲食店の業態を想像してください。店舗型（ネイティブアプリ）はお客さんに来店してもらう代わりに最高の体験を提供できます。デリバリー専門（Webアプリ）なら来店不要で手軽ですが、できることに制約があります。フードトラック（ハイブリッドアプリ）はどちらの良さも取り入れつつ、両方の制約も抱えます。ソフトウェアも同じで、PCインストール型・ブラウザ経由・スマホアプリのどれで届けるかが、開発の進め方・売り方・運用体制まで全て決めます。
なぜ形態の選択が重要なのか
もし形態選定を曖昧なまま進めたらどうなるか。Webアプリとして作ったものを後からネイティブに移植するのは、UIの作り直し・オフライン対応の追加・ストア審査対応を含めると、実質的に新プロジェクトと同じ工数が発生します。形態はあとから直せません。
答え次第で、開発者のスキルセットも、営業の戦い方も、顧客サポートの体制も全部変わります。業界では「途中で形態を変える」プロジェクトをいくつも聞きますが、終わった頃にはチームの半分が辞めていた、という話も珍しくありません。特にスタートアップで「まずはプロトタイプを」と形態選定を先送りした結果、プロトタイプの形態がそのまま本番になって後悔するパターンは頻出です。プロトタイプは最終形態で作るのが鉄則です。
3つの基本形態
選択肢は大きく3つに分類されます。どれかが全部勝ちということはなく、得意分野と刺さらない分野がはっきり分かれています。
| 形態 | 実行環境 | 向くケース |
|---|---|---|
| ネイティブ | OS上（OS固有APIで構築） | ゲーム・3D・ハードウェア直接制御 |
| Web | ブラウザ上 | SaaS・業務系・SEO重視サイト |
| ハイブリッド | OS上（Web技術で構築） | iOS/Android両対応を少人数で |
ネイティブ ― 性能とハードウェア制御の独壇場
ネイティブアプリケーションは、端末のOS上で直接動くアプリです。Windowsの .exe、iPhone/Androidのアプリ、そしてATM・カーナビのような組み込みシステムもここに入ります。
最大の武器は性能とハードウェア直接制御です。GPUを叩いてリアルタイムレンダリングを回す、カメラのセンサーに生アクセスする、Bluetoothで機器を細かく制御する──こうした要件は、ブラウザのサンドボックス（安全のためWebコードの実行権限を制限する仕組み）越しでは現実的に実現できません。動画編集・ゲーム・3Dモデリング・組み込み機器・高頻度取引システムがいまもネイティブの独壇場である理由はここにあります。
一方で弱点は配布と更新に集中しています。ストア審査を通す必要がある、ユーザーに更新操作を促さねばならない、OSごとに実装を分ける必要がある。App Storeの審査で2週間待たされた挙げ句リジェクトされる経験をしたチームは、二度とネイティブを「気軽に」選ばなくなります。
Web ― 摩擦ゼロで届けられる
WEBアプリケーションは、HTML・CSS・JavaScriptをブラウザで動かす形態です。Gmail・Notion・Slack・Figma。URLを開くだけで使え、インストールも更新操作も要りません。デプロイ1回で全世界のユーザーが即最新版になり、バグを見つけたら30分で修正版を届けられる。この「摩擦ゼロの配布」が、新規プロジェクトのデフォルト候補をWebに固定しました。SaaSビジネスが過去20年で爆発的に拡大した背景も、この即時配布が支えるリーンな開発サイクルにあります。
Webアプリの提供形態はさらに4種類に分岐します。乗り物で例えるなら、SaaSは配車タクシー（完成済みアプリをそのまま使わせる）、PaaSはカーシェア（開発環境ごと貸す）、IaaSは月極駐車場（仮想サーバーを貸す）、FaaSは呼べば来るタクシー（関数だけ預かって呼ばれた時に動かす）。どこまで自分で整備したいかが違うだけで、自由度と管理責任が反比例します。
実務上の要点は3つです。
- 新規プロダクトはSaaS形態が定石です。1つのアプリで複数顧客を論理分離するマルチテナント型が基本で、顧客ごとに独立インスタンスを立てるシングルテナントは運用負荷が桁違いに増え、ほぼ受託開発の延長になります。この2つを混同したまま提案書を書くと見積もりがオーダーで狂います
- 自分たちのアプリを載せる基盤は原則PaaSから始めます。OS・ミドルウェア・証明書更新といった雑務をベンダーが代行してくれるためです。素のIaaSに降りるのは、特殊なカーネルモジュール・GPU・コンプライアンス監査など「なぜPaaSでは駄目か」を1分で説明できるときだけ。「なんとなくIaaSのほうが安そう」で降りると、月3万円のIaaSが人件費込みで実質月30万円になる構造を見落とします
- FaaS（AWS Lambda等）は間欠的な処理専用です。夜間バッチ・Webhook処理・サムネイル生成のような「月数回〜時々動く処理」では従量課金が圧倒的に有利ですが、常時稼働のAPIに使うとコールドスタート（未起動の関数が呼ばれたとき起動までの遅延）が毎回ユーザー体験を削ります。常時稼働ならPaaSかコンテナサービスを選びます
なお、LLM応答のストリーミングが絡む新規案件では、コールドスタートがほぼゼロのEdge Runtime（Cloudflare Workers・Vercel Edge）が第一候補になっています。認証・DB・関数を一括提供するBaaS（Supabase・Firebase）も個人〜小規模の強力な選択肢ですが、製品によってロックインの深さが大きく違うため、「ベンダー停止時に何日で移行できるか」を見積もってから採用するのが安全です。
ハイブリッド ― 2OSを1コードで
ハイブリッドアプリケーションは、Web技術で作ったものにネイティブアプリの皮をかぶせて配布する形態です。iOSとAndroidを1つのコードで賄えるのが最大の武器で、2つのOSそれぞれに別チームを雇う体力がないプロジェクトの事実上の標準解です。
系譜は2つあります。ネイティブアプリの中にブラウザを埋め込むWebView型（Cordova・Ionic）は実装が楽な反面動作が重く、コードをネイティブUI部品にマッピングして描画するネイティブ描画型（React Native・Flutter）は軽くてネイティブに近い体験になります。2026年の現場ではネイティブ描画型が主流で、InstagramやDiscordのように一部機能だけネイティブで書く混在構成も普通に通ります。
地雷として知られているのがネイティブ機能の深いところへのアクセスです。Bluetoothの細かい制御・カメラの深度センサー・Push通知の細部では、プラグインがネイティブAPIの更新に追いつかず、ある日突然動かなくなることがあります。「OS更新後にアプリが落ちる」事件の多くはこのプラグイン周りで発生しています。
WEB vs ネイティブの決め手
Webとネイティブの分岐は、要するに性能と配布の綱引きです。
| 観点 | Webアプリ | ネイティブアプリ |
|---|---|---|
| 配布・更新 | URL開くだけ | アプリストア経由 |
| クロスプラットフォーム | ◎ | ×（再実装が必要） |
| 性能・ハードウェア制御 | 限定的 | 最高・完全 |
| オフライン動作 | 限定的（PWA） | ◎ |
経験則はシンプルです。「0.1秒の遅延が致命傷」「ハードウェア直接制御」「オフライン必須」のいずれかが外せないならネイティブ、それ以外はWeb。ゲーム・動画編集・CAD・医療機器UI・金融トレーディング端末は遅延がそのまま価値の劣化になるため、いまもネイティブ以外の選択肢は実質ありません。ブラウザでもWebGL / WebGPUで3D描画は可能ですが、AAAゲームレベルの体験をWebで提供する試みはGoogle Stadia（2019-2023）の撤退が象徴するように、性能と遅延の壁に跳ね返され続けています。
判断に迷ったら、似た業務を既に作っている会社がどちらで作っているかを調べるのが一番早い方法です。同業他社が全てWebなのに自分だけネイティブ（またはその逆）という逆張りには、ほぼ例外なく後悔が待っています。「なんとなく差別化したい」は技術選定の理由になりません。
どう選べばいいのか ― 規模別の3シナリオ
形態は「誰が・どこで・何をしたいか」で9割決まります。典型的な3つのケースで考えてみます。
個人開発・スタートアップなら ― 検証は必ずWebで
MVP段階でElectron・React Native・Flutterを選ぶのは、大抵の場合過剰だと思います。まずはブラウザで触れるWebを作って、「ユーザーの7割がスマホから来ている」のような実測値が揃ってからネイティブ化を検討すれば十分です。順序を逆にしてしまうと、一番大事な検証フェーズをストア審査（数日〜数週間）に溶かすことになってしまいます。基盤はPaaS / BaaS（Vercel+Supabase等）に寄せ、インフラ作業をゼロに近づけるのがこの規模の生存戦略です。
中小SaaSなら ― Webを磨き、アプリ化は数値で判断
業務系・BtoB SaaSはWeb一択です。端末を問わず使え、更新が全顧客に同時に届きます。スマホアプリ化を迷う場合の分岐点は、ブラウザ経由のコンバージョン率が全体の30%を切るかどうかです。モバイル利用の大半がアプリを求めるようになった段階で初めてハイブリッド（Flutter / React Native）追加の投資対効果が合います。そこに達するまでは、ブラウザ版を磨き込むほうが賢明です。
大企業・エンタープライズなら ― 用途別に複数形態を併用
社内業務システムはWeb一択（「特定バージョンのIEでしか動かない業務ソフト」の教訓）ですが、店舗の専用端末・工場の制御系・性能要件の厳しい業務は組み込み系ネイティブが現実解です。用途ごとに形態を使い分け、コンプライアンス要件・調達・保守体制まで含めて選定します。ATM・自販機・カーナビのような領域は、ネットワーク切断時にも動き続ける信頼性が要求されるため、Webベースの参入は量産に耐えた事例がほぼありません。
フェーズ別の目安
同じプロダクトでも、フェーズが違えば正解が変わります。
| フェーズ | MAU目安 | 推奨形態 |
|---|---|---|
| MVP・検証 | 〜1,000 | Web（PaaS / Serverless） |
| 初期成長 | 1,000〜10万 | Web（+CDN+マネージドDB） |
| スケール期 | 10万〜100万 | Web+必要に応じてハイブリッド |
| エンタープライズ | 100万〜 | Web+ネイティブ+組み込み（用途別） |
AI判断軸 ― コードで完結するか
AI駆動開発が前提になった今、選定軸は人間の学習コストからAIの流暢さへ重心が移りました。
AIの学習データにおいて、Webアプリ（HTML/CSS/JavaScript+バックエンドAPI）の実装例はネイティブアプリの数十倍存在します。React+Next.jsでのSaaS構築やAPI設計はAIが高精度で生成できる一方、iOS（Swift）やAndroid（Kotlin）のネイティブはOS固有のライフサイクル管理やパーミッション設計でAIが間違えやすく、ストア審査対応やPush通知の設定はバージョンごとに仕様が変わるため、AIの生成コードが古い方式になっていることがあります。「迷ったらWeb」の経験則は、AI時代にはさらに強化されています。
クロスプラットフォームFWにも同じ構図があります。React NativeやFlutterは1つのコードベースで2OSをカバーするため、AIに渡すコンテキストも1セットで済みます。プラットフォーム別に2つのコードベースを持つと、AIに同じ修正を2回指示することになり、不整合のリスクが生まれます。
もう1つの軸は「構成がコードで完結するか」です。GUI操作・独自管理コンソールへの依存はAIが支援できない領域で、同じ要件を満たせる形態が2つあるなら、コードで完結するほう（Web / コンテナ / IaC）を選ぶのが原則になります。
やってはいけないこと
形態を途中で変える判断は事実上の作り直しです。特に危険な5つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| Web→ネイティブを「そのまま移植」 | DOM前提のUIを写すと性能も体験も劣化する → UIは作り直し前提で計画する |
| FaaSを常時稼働APIに使う | コールドスタートが毎回UXを削る → Edge Runtimeかコンテナにする |
| 性能要件を無視してWebに寄せる | 動画編集・3D・大量データ処理はブラウザの制約で詰まる → 要件が確定した時点でネイティブを選ぶ |
| 「勉強になる」でIaaSを選ぶ | OSパッチ・証明書更新で肝心のアプリが進まない → 本番ラインはPaaSで始める |
| 旧形態を止めてから新形態へ移行 | 障害時に戻る場所がなく全面障害になる → 両形態を3〜6ヶ月併走させ、段階的に切り替える |
移行のスコープにも鉄則があります。全機能を一気に移す「ビッグバン移行」はよほどの小規模でない限り失敗します。機能単位・ユーザー単位で段階的に置き換えるストラングラーパターンが基本で、新旧の同時稼働期間を前提に設計します。退路を断った移行は博打であって、設計ではありません。
筆者メモ ― 「勉強になる」でIaaSを選んだ週末
個人開発で小さなSaaSを立ち上げようとして、「勉強になる」という理由でAWS EC2を借り、週末の2日をnginxとsystemdとドメインの設定に溶かし、Let’s Encryptの更新cronを書いて、ようやく Hello, World をインターネットに出したところで力尽きた──この業界の定番の通過儀礼として知られる話です。同じことはPaaSなら git push 1コマンドで済みます（かつてのHeroku無料枠の役割は、今はFly.io・Render・Railwayが引き継いでいます）。
「勉強」と「プロダクト開発」は別物として扱うのが健全です。インフラの勉強は業務時間外の素振りで行い、プロダクトを世に出す本番ラインはPaaSで始める。両者を混ぜると、本来プロダクトに投下すべき時間がインフラの雑務で蒸発します。「勉強になる」は最もコストの高い選定理由です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。これらはプロジェクト開始の1週目に決めるべき項目です。先送りすると、下流の技術選定（言語・フレームワーク・クラウドベンダー）が仮決めのまま進み、形態が確定した時点で大規模な手戻りが発生します。
- アプリケーション形態（Native / Web / Hybrid）
- Webの場合のサービス形態（SaaS / PaaS / IaaS / FaaS）
- 対応プラットフォーム（Windows / Mac / iOS / Android / Linux）
- オフライン動作要件
- 要求性能レベル（レイテンシ・スループット）
- 配信・更新の頻度と方式
- 初期コストと運用コストの上限
言語化した答えをADR（Architecture Decision Record）として残す方法は、以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事はシステムアーキテクチャで最初に決めるべきアプリケーション形態の選び方を解説しました。如何だったでしょうか。
迷ったらWeb。ネイティブの理由がその場で書き出せないなら、Webで始めるのが最適解です。形態はあとから変えられない最上流の意思決定なので、初週で言語化できるまで議論する価値があります。
次回はアプリケーション形態の次に決める「デプロイモデル」（オンプレ/クラウド/ハイブリッド）を解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS アプリケーション開発 も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（12/95）