PWAのシステム開発の発注/外注/依頼/委託方法について

PWAのシステム開発を発注・外注するなら、PWA化の範囲だけでなく、オフライン入力・データ同期・認証・通知・運用保守まで要件に分解して比較することが重要です。

「PWAなら低予算でスマートフォンアプリを作れるのか」「開発会社へ何を伝えれば見積を比較できるのか」「請負と準委任のどちらで契約すればよいのか」と悩む企業担当者は少なくありません。PWAはURLで配布できる便利な方式ですが、単にManifestとService Workerを追加すれば業務アプリとして安全に運用できるわけではありません。本記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較、検収と保守まで、PWAのシステムを外注するときの実務を順番に解説します。

▼全体ガイドの記事
・PWAのシステム開発の完全ガイド

PWAのシステムは何を発注するものですか？

PWAのシステムは、Webアプリを基盤にしながら、端末への追加、キャッシュ、オフライン利用、通知などを段階的に実装するシステムです。したがって、発注対象は「PWA対応」という一言ではなく、業務画面、業務API、認証基盤、データベース、Manifest、Service Worker、監視、保守を含む構成全体になります。

Manifestにはアプリ名、アイコン、起動URL、表示モードなどを定義し、Service Workerでは通信の制御やキャッシュ、オフライン時の画面表示、復旧後の同期などを実装します。MDNは、インストール可能なWebアプリにはManifestが必要である一方、Service Workerはインストールの必須条件ではなく、オフライン体験のために多く使われる技術だと整理しています（出典: MDN「Making PWAs installable」、2026年参照）。

業務システムでは、案件・顧客・在庫・点検情報の参照と登録、写真、位置情報、バーコード、承認、帳票、通知、管理者向け画面までが発注範囲になり得ます。特に「通信が切れたら何を表示するか」「入力データを端末に残すか」「同じデータを複数人が更新したらどうするか」を決めなければ、オフライン対応の見積は後から膨らみやすくなります。

店舗巡回、営業訪問、倉庫の棚卸、設備点検、イベント受付、社内ポータルのように、利用場所や端末が分散している業務では、URLで配布できるPWAが候補になります。iOSとAndroid、PCを一つのWebコードベースで展開しやすく、ストア審査を待たずに更新できるため、利用者が多い業務でも段階的に展開しやすい方式です。

ただし、Bluetooth・NFC・高度なカメラ制御、AR、GPUを使う処理、OS固有のバックグラウンド処理、ストア課金などはネイティブアプリが適する場合があります。PWAを選ぶときは「アプリの代わりになるか」ではなく、通信環境、データの鮮度、端末機能、配布方法、セキュリティ水準を業務ごとに評価します。

発注形態はパッケージ・クラウド・個別開発から選びます

PWAの発注形態は、既存のWebシステムを拡張するのか、クラウドやSaaSを組み合わせるのか、新しい業務システムを個別開発するのかで考えます。価格だけでなく、業務への適合度、将来の変更自由度、データの所有権、保守体制、ベンダーから移行できるかを同じ条件で比べることが大切です。

すでにレスポンシブ対応されたWebシステムがあり、ホーム画面への追加、静的ファイルのキャッシュ、オフライン時の案内、基本的な通知だけを追加したい場合は、既存WebシステムのPWA化が候補になります。画面やAPIを再利用できれば、新規開発より短期間でPoCを始めやすくなります。

一方で、古いJavaScriptライブラリ、認証方式、APIの状態管理、画面ごとのキャッシュ設計が整理されていない場合は、PWA機能を足す前に改修が必要です。「PWA化一式」とまとめず、Manifest、HTTPS、Service Worker、キャッシュ戦略、オフライン対象画面、ブラウザテストを個別の作業項目として見積に記載してもらいます。

認証、データベース、API、監視、CDN、CI/CDなどをクラウドサービスで組み合わせる方式は、初期から全機能を自社で作らずに済む可能性があります。標準業務が中心であれば、SaaSを使いながら不足する画面やAPIだけを外注する構成も現実的です。利用者数、データ量、バックアップ、障害時の復旧時間、クラウド費用の上限を先に確認します。

クラウドを使う場合でも、サービスを組み合わせた責任分界は発注側が確認します。通知が届かないときに送信基盤、ブラウザ、端末設定、アプリ側のどこを調べるのか、障害時の連絡窓口とログの保存期間をRFPに書きます。安価に始められても、解約時のデータ出力や別サービスへの移行費用が高い場合があるため、契約前に確認します。

既存のSFA、ERP、基幹データベース、会計、認証基盤などと複雑に連携し、独自の承認や現場運用を再現するなら、個別開発が候補になります。画面の見た目だけでなく、API、権限、監査ログ、データ移行、同期失敗時の再送、管理者機能まで一つの業務システムとして設計できます。

ただし、スクラッチ開発は自由度が高い分、要件定義、テスト、保守、担当者の引き継ぎが必要です。最初から全社共通基盤を完成させようとせず、1部門・1業務・1〜3個のKPIを対象にPoCを行い、使われた機能だけを本番開発へ広げる進め方が安全です。

PWAのシステム発注・外注を進める5つの手順

PWAの外注は、目的と対象業務の整理、現状の棚卸し、RFPの作成、提案・見積比較、PoCと契約の順に進めます。技術名から始めるのではなく、利用者がどの画面で何を入力し、通信断や承認差し戻しが起きたときにどう業務を継続するかを先に整理します。

「PWAを導入する」ことは目的ではありません。営業訪問後の入力時間を短くしたい、紙の点検票からの転記をなくしたい、店舗巡回の報告を当日中に共有したいなど、業務上の成果に置き換えます。KPIは、入力完了までの時間、転記ミス件数、通信復旧後の同期完了率、承認までの日数、利用者の継続率など、導入前後で測れるものを1〜3個に絞ります。

同時に、利用者の端末、OS、ブラウザ、電波状況、共有端末の有無を確認します。倉庫では地下や冷蔵設備の周辺で通信が途切れる場合があり、訪問業務では移動中に入力する場合があります。オンラインだけで済む管理画面と、オフラインでも使う現場画面を分けると、過剰な同期機能を発注せずに済みます。

紙、Excel、メール、既存SFA、ERP、基幹データベース、会計、認証基盤を業務フローに沿って並べます。利用者がログインし、対象情報を取得し、現場で入力し、上長が承認し、結果を帳票や他システムへ渡すまでを図にすると、PWAの画面とAPIの境界が見えます。

連携要件では、どのシステムを正とするのか、連携頻度はリアルタイムか日次か、失敗時に再送できるか、データの重複をどう防ぐかを決めます。利用者数、同時接続数、1日あたりの登録件数、写真の容量、保存期間、データ移行件数も初期に把握します。ここが曖昧なままだと、委託先ごとに異なる前提で見積を出すため、金額を比べられなくなります。

提案資料やデモ画面だけで発注を決めず、自社の業務に近いサンプルデータと端末でPoCを行います。オンライン、低速回線、完全オフライン、通信復旧、二重送信、セッション期限切れ、端末容量不足、複数ユーザーの同時更新を一つずつ試します。オフライン入力を採用するなら、送信キューの状態、再送の条件、失敗データの確認方法、競合更新の解決方法を画面で確認します。

PoCの受入条件は「動いた」ではなく、業務成果で決めます。例えば、指定した点検項目を端末に保存できること、通信復旧後に重複なく登録されること、同期失敗を管理者が発見できること、iOSとAndroidの対象端末で主要操作が完了することなどです。PoCで判明した制約を本番見積に反映すれば、後工程の追加請求と納期のずれを減らせます。

RFPと要件整理ではPWA固有の条件を分解します

RFP（提案依頼書）は、開発会社に機能を考えてもらうための依頼書ではなく、発注側が解決したい課題と比較条件をそろえる文書です。目的、対象範囲、利用者、現行システム、希望スケジュール、予算の考え方、提案に求める成果物、評価方法を明記し、機能要件と非機能要件を分けて記載します。

機能要件には、ログイン、権限別メニュー、顧客・案件・在庫・点検情報の検索と登録、写真、位置情報、バーコード、承認、差し戻し、帳票、通知、管理者画面を記載します。各機能について、対象利用者、入力項目、必須条件、エラー表示、保存先、監査ログの要否を明らかにします。既存APIを使う場合は、API仕様書、認証方式、レート制限、エラーコード、接続試験の担当もRFPに含めます。

PWA固有の条件では、インストール導線、Manifestの項目、Service Workerのスコープ、静的ファイルとAPIのキャッシュ戦略、オフライン対象画面、IndexedDBなどの端末保存、送信キュー、同期、プッシュ通知、アプリ更新、緊急停止を分けます。「オフライン対応」と書くだけでは、閲覧だけか、入力と登録までか、写真も対象かが分からないためです。

非機能要件には、対応OSとブラウザ、画面表示速度、同時接続数、可用性、バックアップ、復旧時間、ログ保存期間、脆弱性診断、暗号化、アクセス制御、監視、問い合わせ対応時間を含めます。スマートフォン、タブレット、PCをすべて対応するのか、対象機種を限定するのかでもテスト工数は変わります。

Service Workerは、キャッシュした古い画面をユーザーへ返し続ける可能性があります。そのため、バージョン管理、キャッシュ削除、ロールバック、緊急停止、ログ確認の方法を運用要件にします。OWASPは、Service Workerを自ドメインからHTTPSで配信し、スコープを限定し、機密情報を含むレスポンスをキャッシュしないことを推奨しています（出典: OWASP「HTML5 Security Cheat Sheet」、2026年参照）。

提案時に求める成果物は、画面一覧、画面仕様、データモデル、API仕様、インフラ構成、セキュリティ設計、テスト計画、運用手順、操作マニュアル、ソースコード、デザインデータ、バックアップと移行手順まで具体化します。成果物の所有権、利用許諾、契約終了時のデータ返却、第三者サービスのライセンスも確認します。

受入基準は、正常系だけでなく、通信断、重複送信、同期失敗、権限不足、セッション切れ、古いキャッシュ、端末紛失、通知拒否を含めます。発注側が準備するテストデータ、委託先が実施するテスト、発注側が行う受入テストを分けると、検収時に「そこまで含まれると思わなかった」という認識差を抑えられます。

契約形態は請負と準委任を要件の確定度で使い分けます

PWAの開発では、要件整理、現場ヒアリング、試作、画面設計、開発、運用改善が混在します。契約名だけで判断せず、何を成果物として納品し、どの時点で検収し、仕様変更と障害対応を誰が負担するのかを契約書・仕様書・個別発注書でそろえます。

準委任契約は、一定期間の専門作業やプロジェクト支援に対して報酬を支払う考え方です。現場ヒアリング、業務分析、RFP作成支援、UI検証、PoC、アジャイルな改善など、開始時点で完成形を固定しにくい作業に向いています。

準委任では、作業時間だけでなく、会議体、週次報告、成果の確認方法、担当者の役割、追加作業の承認方法を決めます。完成品の品質を無条件に保証する契約ではないため、PoCを終える条件、次の開発へ進む判断基準、終了時に引き渡す設計書やソースコードを明確にします。

請負契約は、合意した成果物を完成させ、検収を受けることを前提に進める契約です。確定した画面、管理機能、連携機能、テスト仕様書、操作マニュアルなどを納品する場合に向いています。PWAでは、オフライン入力、同期処理、通知、Service Workerの更新などを検収対象へ含めることが重要です。

契約前に、検収日、受入テスト、瑕疵対応の期間、軽微な修正の範囲、仕様変更時の再見積、遅延時の扱い、第三者サービス障害時の責任分界を確認します。「PWA対応済み」という状態ではなく、対象ブラウザでどの機能が動くことを保証するのかを機能ごとに記載します。

実務では、要件定義・現場検証・試作を準委任で行い、合意したMVPの開発と受入を請負で行う組み合わせが使いやすい場合があります。運用監視は保守契約、クラウドはサービス利用契約、追加機能は個別の請負または準委任というように、責任と料金が異なる範囲を分ける方法です。

契約終了後に自社で継続できるよう、ソースコード、設計書、テスト結果、インフラ設定、ログ、データのエクスポート、第三者サービスのアカウント管理を確認します。契約終了時のデータ返却や移行に高額な費用がかかる条件は、発注時点で比較対象に含めます。

PWAのシステム開発費用と相場は範囲を分けて見積もります

PWAだけを対象にした公的な統一相場はありません。以下は、2026年に公開されている開発会社の概算と、リサーチノートに整理した業務システムの費用構造を組み合わせた予算検討用のレンジです。画面数、連携数、データ移行、オフラインの深さ、セキュリティ、テスト対象、保守範囲で変わるため、確定価格ではありません。

既存WebサイトにManifest、HTTPS、基本Service Worker、静的キャッシュ、ホーム画面への導線を追加する場合は、100万〜400万円程度が公開されている目安です（出典: GXO「PWA（Progressive Web App）開発の費用相場」、2026年）。同じPWA化でも、基本対応、動的キャッシュ、オフライン画面、プッシュ通知、IndexedDBによるデータ管理まで含めるかでレンジが変わります。

既存システムの認証やAPIがそのまま使える場合は下限に近づきやすい一方、古いフロントエンドの改修、APIの追加、権限設計、写真や入力データの同期、iOS Safariの実機試験を含めると上限側へ広がります。見積書では、PWA固有の作業と既存システムの改修を別項目にします。

新規PWA開発は、フロントエンド、バックエンド、認証、データベース、PWA固有機能を新しく作るため、200万〜800万円程度、期間2〜6か月という公開目安があります（出典: GXO「PWA（Progressive Web App）開発の費用相場」、2026年）。小規模の情報表示やフォームだけなら下限に近く、認証、通知、データ同期、外部API、管理画面、複数端末の実機検証を加えると上限側へ移ります。

リサーチノートでは、5〜25画面程度の新規業務PWAを200万〜800万円、既存Webへの基本PWA化を100万〜400万円、通知・認証・業務API連携を300万〜600万円、ヘッドレス刷新や大規模連携を800万〜3,000万円以上の比較レンジとして整理しています。これは案件の規模と機能範囲を比較するための数字であり、特定の会社が提示する一律価格ではありません。

初期費用だけでなく、クラウド、データベース、CDN、監視、バックアップ、通知基盤、脆弱性診断、問い合わせ、OS・ブラウザ対応、軽微な改善を分けて見積もります。リサーチノートでは、サーバー・監視・保守を月3万〜13万円程度、別の公開目安では月10万〜100万円程度としており、後者は大規模業務システムを含み得るため、小規模案件へそのまま適用しないことが重要です。

年間保守は初期開発費の15〜20%程度を目安にする整理もありますが、24時間監視、障害対応、脆弱性対応、追加開発を含むかで変わります。3年間の総額を試算し、初年度の導入費が安い提案だけでなく、通知件数の増加、利用者追加、データ容量増加、契約終了時の移行費まで比べます。

委託先選定と見積比較では実績・技術・運用体制を確認します

委託先は「PWAと書かれたサービスを持っているか」だけでなく、業務要件をオフライン・同期・認証・通知・監視まで設計できるかで選びます。公開事例、担当者の経験、実装後の保守、障害時の切り分け、設計書とソースコードの引き渡しを、同じRFPで3社程度に確認すると比較しやすくなります。

開発会社へは、PWAの本番稼働実績だけでなく、対象業務、利用者数、対応端末、通信断への対応、通知の実装、外部API連携、障害後の復旧方法を質問します。株式会社TAMはPWAの開発事例で、ヒアリング、UIプロトタイプ、ユーザビリティテスト、PWA仕様設計、パフォーマンス改善までの進め方を公開しています。企画やUX検証を重視する案件では、こうしたプロセスの実績が比較材料になります。

フェンリル株式会社はWeb開発、WebAPI、CMS、コンテナ、CI/CD、クラウドなどの技術領域を公開しています。大規模なWebやクラウド基盤、既存システムとの連携を重視する場合は、担当チームの体制と自社案件に近い事例を確認します。会社名の知名度ではなく、今回の対象業務で同じ設計判断を再現できるかを見極めます。

見積比較では、要件定義、UI・UX設計、フロントエンド、バックエンド、認証、Manifest、Service Worker、キャッシュ、オフライン入力、同期、通知、外部API、テスト、データ移行、教育、リリース、監視、保守を項目化します。各項目に、含む・含まない・数量・工数・単価・納期・前提条件を記載してもらいます。

安い見積でも、iOS実機試験、通信断テスト、通知基盤、脆弱性診断、データ移行、店舗や拠点の追加、問い合わせ対応が含まれていないことがあります。価格差が機能差なのか、テストや運用の積み残しなのかを説明してもらい、同じスコープにそろえて再見積を依頼します。

業務データを端末に保存する場合は、ログアウト後の残存、共有端末、端末紛失、ブラウザプロファイル、データの暗号化、保存期間を確認します。OWASPは、localStorageやIndexedDBに認証情報や秘密情報を安易に保存しないこと、IndexedDBの内容を信頼できるデータとして扱わないことを示しています。オフライン対応の便利さだけでなく、端末側に何を保存しないかを要件にします。

顧客情報、位置情報、従業員情報などを扱う場合は、個人情報保護委員会のガイドラインを確認し、利用目的、安全管理措置、委託先の監督、漏えい時の連絡、データ削除を設計へ反映します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年参照）。発注先へは、脆弱性対応の期限、監視時間、障害連絡先、バックアップと復旧の担当、契約終了時の引き継ぎを質問します。

よくある質問

PWAの発注では、技術の可否だけでなく、費用、契約、保守、端末差分、データの扱いについて確認してから委託先を決めます。ここでは、発注前によくある質問へ直接回答します。

PWAはiOSとAndroid向けに別々のアプリを作らず、URLで配布できるため、条件によっては初期開発と配布の負担を抑えやすい方式です。ただし、オフライン入力、競合解決、通知、既存API連携、端末差分、監視まで含めると、通常のWeb画面より工数が増えます。安さだけでなく、必要な業務範囲に対する総額で判断します。

技術的には、Service Worker、Cache API、IndexedDB、送信キューなどを組み合わせて、オフライン入力と復旧後の同期を設計できます。ただし、データが消えないことを保証するには、重複送信、同期失敗、競合更新、端末容量不足、ログアウト、端末紛失まで受入テストに含める必要があります。何を端末へ保存するかを最小限にし、機密情報はキャッシュしない設計が基本です。

iOSのPWAでもホーム画面追加やWeb Pushを利用できる場合がありますが、OS・ブラウザ・追加方法・ユーザーの許諾状態による差分を確認します。WebKitはSafari 26.0で、iOS 26とiPadOS 26ではホーム画面へ追加したWebサイトを標準でWebアプリとして開く挙動を案内しています（出典: WebKit「WebKit Features in Safari 26.0」、2025年公開）。これによってManifestが不要になる場面があっても、アイコンや表示、通知、オフラインなどのPWA機能が自動で完成するわけではありません。

同じRFPを3社程度へ渡し、同じサンプルデータと受入条件で提案と見積を受けると比較しやすくなります。比較時は、PWAの実績だけでなく、業務理解、オフラインと同期、認証、通知、iOS実機テスト、セキュリティ、保守、成果物、契約終了時の移行条件を確認します。会社数を増やしすぎるより、要件をそろえて提案内容の差を読むことが重要です。

まとめ

PWAのシステム開発を発注・外注するときは、PWAという技術名だけで委託先や価格を決めないことが重要です。対象業務、KPI、利用端末、通信環境、オフライン範囲、同期ルール、認証、通知、既存システム連携を先に整理し、同じRFPで複数社を比較します。

要件では、ManifestやService Workerの実装だけでなく、キャッシュ、オフライン入力、送信キュー、競合更新、iOSとAndroidの実機試験を分解します。契約では、請負と準委任の役割、検収、変更手続き、障害対応、ソースコード、データ返却、保守の責任分界を確認します。見積では、初期費用だけでなく、クラウド、通知、監視、セキュリティ、追加開発、3年間の運用費まで比べます。

最初から全社の業務を移行するのではなく、通信断が起きやすく効果を測りやすい1業務でPoCを行います。実データに近い条件で、入力、保存、同期、通知、エラー対応、権限、端末差分を確認し、受入基準を満たした機能だけを本番範囲へ広げると、PWAの利便性と業務システムとしての安全性を両立しやすくなります。

▼全体ガイドの記事
・PWAのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。