本文へスキップ
NeoLogic
NeoLogic

「スマホで使うならアプリ」はまだ早い。Webアプリ・スマホアプリ・PWAの選び方

利用端末、カメラ、位置情報、通知、通信が切れたときの動作を同じ条件で比べます。PWAの保存と同期を含む要件票に、自社で必要な機能を記入。実機で確かめてから方式を選ぶためのガイドです。

スマートフォンで使うWebアプリ・PWA・スマホアプリを比較する。

Webアプリ・スマホアプリ・PWAは、使う端末、圏外で保存・送信が必要か、通知やカメラなどの端末機能、配布と更新の手間から選びます。ブラウザで足りる業務まで専用アプリにする必要はありません。

たとえば、社員がスマホで点検結果を入力し、事務担当者がPCで見る。こうした仕組みを考えるとき、「スマホで使うからアプリを作ろう」と決めると、ブラウザで足りるのか、インストールが必要なのかを検討できなくなります。先に整理したいのは、誰がどの端末で、通信が切れたときも何を続けたいかです。

たとえば、写真付きの点検を毎日行い、圏外では端末へ保存して、開き直して送信できればよいなら、PWAを試す余地があります。一方、通信できる場所で月一回申請するだけならブラウザ利用のWebアプリ、画面ロック中も位置を記録するなら専用アプリを優先して検証します。スマホで使う点は同じでも、必要な動作が候補を変えます。

写真付きの点検業務で、方式を比べます(想定例)。方式を決める前に、最も厳しい必須条件が対象端末で動くかを確かめます。

圏外で閉じた点検票を、翌朝も続けられるか

点検業務で確認したいのは、デモ中に一度保存できることだけではありません。説明用に、点検票F-101の本文と写真二枚を持ち歩く場面を考えます。候補ごとに同じ端末・OS・利用者で、次の順番を通します。

  1. 通信できる間にログインし、必要な点検票を開く。
  2. 圏外にして本文と写真二枚を保存し、アプリを閉じる。
  3. 翌朝相当の条件で開き直し、未送信の内容と写真を確認する。
  4. 通信を戻して送信し、管理側で本文と二枚を開く。二度送っても増えないかも見る。
  5. 端末交換を想定し、未送信分をどこから回収するかを担当者と確かめる。

表には「圏外対応○」と一文字で書かず、未送信分が消えた操作、通知を受け取れた条件、復旧に必要だった作業を残します。この手順は未実施の比較課題で、Web・PWA・ネイティブのいずれかの成功を保証するものではありません。

MDNのオフライン・バックグラウンド処理の説明では、画面を開いていない間の処理にもブラウザ側の制約があります(2026年10月26日確認)。バックグラウンド送信を前提にする案と、利用者が開いて送信完了を確認する案を分けると、現場が必要とする手間を比較できます。

URLを開く、ホーム画面へ追加する、アプリを入れる

Webアプリはブラウザで操作する仕組みです。スマホの画面幅に合わせた表示と操作を設計すれば、URLから使う形も検討できます。PWA(Progressive Web App)はWebアプリの一種で、インストールやホーム画面からの起動などの体験を加えます。ホーム画面から起動しても、使える機能はOS・ブラウザと実装の条件に依存します。

専用スマホアプリは、iOS・Android向けに導入するアプリです。OSごとに作るか、共通の技術で作るかは、届け方とは別の設計判断です。PWAにもストア配布の経路があり、専用アプリにも組織向け配布があります。MDNのPWAガイドはWeb技術との関係を説明し、AppleのCustom Apps資料は組織向けの限定配布と審査を説明しています。

比べる点 ブラウザ利用のWeb ホーム追加型PWA 専用スマホアプリ
使い始め方 URLを開いてログインする URLからホーム画面へ追加する手順も案内する ストアや組織向けの経路で導入する
通信が切れたとき 閲覧用の保存と入力保存を別に実装する 写真や入力の保存・再送を実装し、開き直しも試す 保存・同期を実装し、画面を閉じた後の制限も調べる
端末の機能 対応ブラウザと利用許可が条件 PWAにしただけでWebの対応範囲が広がるわけではない OSの機能を使えるが、権限や実行制限は残る
配布・更新・通知を含む、検証担当者向けの比較

表1 代表的な三つの利用形態を、同じ条件で比べる

比較軸 ブラウザ利用のWebアプリ ホーム追加型のPWA 専用スマホアプリ
利用端末 PC・スマホの対象ブラウザで利用。画面・入力方法を調整する。 Webと同じくOS・ブラウザに依存。追加・単独起動の手順も試す。 対象OS向けに導入。PCの管理画面を別途Webにする構成も候補。
配布 URLを案内。ログインと利用権限を設計。 URLから利用し、必要に応じてホーム画面へ追加。対応環境ではストア経由も。 ストアや組織向け経路で導入。資格・審査・端末管理条件を確認。
更新 サーバー側を更新。開いたままの画面やキャッシュの旧版を考慮。 Web更新に加え、通信・キャッシュを扱う仕組みの更新待ちと切替を設計。 アプリ更新を配布。旧版が残る期間とサーバーとの互換性を確認。
通知 OS・ブラウザ・利用形態・許可に依存。通常タブで使えるかを試す。 iPhone等のWeb通知はホーム画面追加等の条件を調べる。 通知の許可とOS設定を試す。通知を見なかった時の対応も決める。
対応環境での試験 対象ブラウザで入力、権限拒否、画面幅、更新後の動作を試す。 Webの入力・権限拒否・画面幅・更新後の試験に加え、ホーム追加・再起動・通信断・保存・更新切替を試す。 導入経路、OS更新、権限、画面ロック、旧版との併存を試す。

写真・位置・通知を、どんな場面で使うか

カメラ・位置情報は、機能名より使う場面を書く

「カメラが必要」だけでは方式を決められません。作業中に写真を撮るのか、細かい撮影制御まで必要なのかを分けます。ブラウザでも撮影や現在地の取得に対応できます。ただし、利用する端末、安全な接続、カメラや位置情報の許可設定を確かめる必要があります。「現在地を一度取得する」と「画面を閉じても位置を継続記録する」も別の要件です。

要件票には「できないと業務が止まる機能」と「代替できる機能」を分けて書きます。たとえば点検写真は必須、現在地は任意で住所入力に置き換えられる、という整理です。専用機器との接続が必須なら、機器名と接続方法を伝え、対象OSとブラウザで利用できるかを開発会社に照合してもらいます。

通知は、導入・許可・見なかった時の手順までが要件

Apple/WebKitのWeb Push説明では、iOS・iPadOS 16.4でホーム画面に追加したWebアプリへの対応が導入され、通知の許可要求には利用者の直接操作が必要とされています。16.4は対応導入時の版です。対象端末で現在の動作を確かめます。「URLを一度開いてもらうだけ」と「ホーム追加と通知許可まで案内する」では、利用開始の手順が違います。

通知を必須にするなら、許可しなかった人や通知を見なかった人にどう対応するかも決めます。たとえば、アプリ内の未処理一覧で見られるようにし、期限を過ぎたら担当者が別経路で連絡する設計です。通知機能の存在と、全員への伝達完了を分けて扱います。

通信断では「見られる」と「記録が残る」を分ける

PWAにすれば自動でオフライン対応するわけではありません。画面を表示するためのキャッシュと、入力・写真を端末に残す仕組みは分けて設計します。MDNのオフライン動作ガイドも実装が前提です。ブラウザ保存には容量・削除条件があるため、「保存した」と表示できる条件を対象端末で確認します。

さらに「再び開いたら送信できる」と「閉じたまま必ず送信される」は違います。画面を閉じた後の同期は端末やブラウザによって対応が異なり、処理が止まったり、実行時間が制限されたりします。閉じたままの同期が必須なら、再起動して送信する代替手順を受け入れられるかが、方式を分ける条件になります。

点検業務の端末と条件を要件票に書く

「iPhone対応」「Android対応」だけでは検証範囲が定まりません。機種、OSとブラウザの版、ブラウザ内で開くかホーム画面から開くか、個人所有か社給かを記録します。社給端末では管理担当者に、アプリ追加、通知、カメラ、端末内保存の社内制限を確認します。共有端末では、交代時のログアウトと保存データの扱いも要件です。

表2 設備点検の要件票

この条件ならPWAを先に試す案です。写真の保存・送信・更新の結果を確かめてから、採用を決めます。

項目 記入済み見本
利用端末 社給iPhone+Safari、社給Android+Chrome。管理者はPC。機種・OS・ブラウザの詳細版は不明で、台帳を見てから確定。
配布と更新 ホーム画面追加の案内が可能、ストア掲載は不要と仮定。更新時は保存済み入力を失わずに切り替える。
端末固有機能 点検写真は必須。現在地と通知は任意。位置は住所入力、通知は未処理一覧で代替する。
通信断時の動作 最大2時間の通信断、1日20件、各件に写真1枚を仮定。画面を開き直して送信する運用を許容する。
対応環境での試験 事前準備後の通信断、入力・写真保存、再起動、送信、旧版からの更新を実機で試す。
記録日・版 公開資料:2026-09-15時点。機種・OS・ブラウザ・アプリの試験版は不明。
根拠と条件外 資料は末尾の参考出典(PWA・カメラ・オフライン・同期・保存容量・更新の各資料)。端末内保存が社内規程で禁止される場合は、この案の条件外。
候補と判断理由 PWAを先に試作する案。ホーム追加を案内でき、閉じたままの同期は必須でないため。保存・写真・更新の試験に合格するまで採用確定しない。

専用アプリでも権限やOSの実行制限は残ります。GoogleのAndroidバックグラウンド位置情報ガイドは、必要性と権限の確認に加え、取得頻度の制限を説明しています。対象OSごとに必須条件を満たせるか確かめます。

配布と更新、使い続けるための費用

同じ利用者・機能・対応端末・保守期間で見積りを依頼します。初期開発、配布準備、更新と再試験、利用者案内、サーバー運用、終了時のデータ引き継ぎに分けて比較します。ストアに出さないWebでも、サーバーやブラウザ変更への対応を含めます。

専用アプリでは、申請用の情報作成、審査への対応、配布アカウント、複数OSでの試験、更新しない利用者への案内を決めます。共通の技術を使う計画でも、どの試験と保守が共通化され、何がOS別に残るかを聞きます。AppleのApp Review Guidelinesには最低限の機能性の条件があり、Webサイトを包むだけの構成も審査対象です。

Web・PWAでは、更新をサーバーに置いた時点と、利用者の画面が新版に切り替わる時点を分けて試します。入力途中のデータを失わない切替、旧版との互換性、更新失敗時の戻し方を見積りに含めます。

特に通信断対応の費用は、「過去の情報を読むだけ」か「写真付きで入力し、再接続後に反映する」かで比較範囲が違います。オフライン不要ならブラウザ利用案を再検討でき、閉じたままの送信が譲れないならPWA案を見直します。対象端末の一覧は管理担当者、機能の条件はMDN・Apple・Google、実装範囲と試験費は開発会社から情報を集めます。

採用を左右する条件を、対象端末で試す

最初の試作では、ホーム画面の見栄えより「失敗すると採用できない条件」を優先します。上の点検例なら、対象端末で写真付きの記録を通信断中に保存し、開き直して続けられるかが先です。端末台帳で許可されている最も古い版も対象に含め、成功した環境だけを対応範囲に数えます。

試験記録には、端末・OS・ブラウザ・アプリの版、利用形態、権限と通信条件、期待する結果、実際の結果、試した日を残します。「未検証」は「対応」と別に扱い、必須条件が不合格なら方式または業務手順を変えます。未対応機能を後から追加できる前提で契約を確定しません。

機能の動作に加え、実際の利用者が入力を完了できるかも試します。Web画面はW3CのWCAG 2.2にあるリフロー、キーボード操作、操作対象の大きさなどを適用条件とともに確認します。WCAGはWebコンテンツの基準として使い、専用アプリの画面は別途確認します。

方式を決める際は、採用理由と一緒に「どの条件が変わったら見直すか」を残します。ホーム追加が禁止された、通知が任意から必須になった、通信断中に写真を扱うようになった、といった変化が再検討の合図です。スマホで使うという希望を、端末・操作・配布の確認できる条件に直すことで、依頼する範囲も明確になります。

空欄版と記入例を含む方式選定の要件票・検証票(Excel)を使って、利用条件と試験結果を記録できます。

検証担当者向け:技術資料と対象環境

撮影はMDNのgetUserMedia、現在地の取得はGeolocation API、閉じた後の同期はBackground Synchronization APIの説明を読みます。専用機器では提供SDKと対応OSも照合してください。更新待ちと切替はGoogleのservice worker更新ガイドが参考になります。

公開仕様は2026年9月15日時点です。iOS・iPadOS 16.4は、ホーム画面Web通知の対応が導入された版です。使う機種・OS・ブラウザの版と、ホーム画面から開くか通常のタブかをそろえて実機で確認します。点検例の詳細版は未確定です。

関連記事・相談先

目的や例外の洗い出しは、開発相談前の要件整理|受注から出荷の記入例で説明しています。既製サービスを使うか独自開発するかは、届け方とは別の判断です。SaaS・パッケージ・独自開発|3年・5年の費用比較で、利用年数と終了時の費用を含めて比べられます。

再送や重複、障害からの再開など連携先の条件は、API連携の要件|待ち時間・再送・二重実行で整理できます。圏外での入力や写真保存が具体的な要件になったら、次の相談先へ進めます。

圏外でも使える現場入力の開発について相談する

参考出典

あわせて読む