開発ノート: Web Bluetooth × PWA で構築する現場資産管理モバイルアプリ
プロジェクト背景と概要
製造現場や倉庫などでは、資産の所在確認や棚卸作業に多大な工数と時間がかかり、ヒューマンエラーによる誤出荷やロスが頻発しています。本開発ノートでは、Web Bluetooth APIとProgressive Web Appを組み合わせたモバイルアプリを構築し、BLEビーコンやタグを装着した資産をスマホから直接スキャンして管理できるプラットフォームの設計・実装を紹介します。既存のネイティブアプリ開発と比較して導入コストを抑えつつ、PWAのオフライン対応・自動更新機能を活用し、現場での通信障害やバージョン管理の手間を大幅に削減します。
技術選定とアーキテクチャ設計
フロントエンドはReact＋TypeScriptベースのPWAとし、Service Workerでオフラインキャッシュを管理。BLE通信はブラウザ上で動作するWeb Bluetooth APIを利用し、追加インストール不要のまま資産スキャン機能を実現。バックエンドはNode.js＋ExpressでREST／GraphQL APIを提供し、MongoDB Atlasで資産マスタやログを一元管理します。サーバーサイドはDockerコンテナ化してKubernetes上で運用し、TerraformによるIaCで環境差異を排除。CI/CDはGitHub Actionsで自動テスト、ビルド、デプロイを行い、ステージングと本番を安定的に同期します。
PWAオフライン対応とキャッシュ戦略
現場ではネットワークが不安定になるケースが多いため、PWAのService Workerでオフラインファースト設計を徹底します。アプリシェル（HTML/CSS/JavaScript）と静的アセットはインストール時にCache First戦略でキャッシュ。動的APIデータはStale-While-Revalidate戦略を採用し、最初はキャッシュを参照しつつバックグラウンドで最新データを取得。Asset manifestとWorkboxを連携し、キャッシュバージョン管理を自動化することで、古いバージョンの配信リスクを排除し、アプリ更新時のダウンタイムをゼロに保ちます。
Web Bluetooth API連携設計
Web Bluetooth APIを用いて、BLEビーコンやタグから近接検出・RSSI（受信信号強度）を取得。ユーザーが「スキャン開始」ボタンを押すと、navigator.bluetooth.requestDeviceでフィルタリング済みデバイス一覧を表示し、選択デバイスのGATTサービスに接続。UUIDごとにキャラクタリスティックを読み取り、資産IDやステータス情報を取得します。接続管理は切断・再接続処理をSDKレイヤーでラップし、Signal Strengthが一定以下になると自動再スキャン。UIリアルタイム反映用にObservableパターンを採用し、ReactのContext経由でコンポーネントにブロードキャストします。
アイテムスキャンとデータ同期フロー
ユーザーが資産をスキャンすると、クライアント側でタイムスタンプ付きのJSONオブジェクトを生成し、IndexedDBへ一時保存。Connectivity APIでオンライン復旧を検知すると、Background Sync APIをトリガーしてRESTエンドポイントへPOSTリクエストを送信。失敗時はリトライキューに追加し、成功時はIndexedDBレコードを削除。これによりオフライン作業中のスキャン結果も漏れなく同期され、後追いでデータ整合性を確保します。
バックエンドAPI設計とセキュリティ
バックエンドAPIはGraphQLを採用し、クライアントが必要なフィールドだけを取得可能に最適化。認証はOAuth2.0＋JWTで実装し、Expressミドルウェアでトークン検証後にctx.userを注入。Role-Based Access Control（RBAC）をGraphQLリゾルバレイヤーで適用し、管理者のみマスタ更新が可能、現場ユーザーは読み取り・ログ登録のみ許可するといった細かな権限制御を実現します。通信はTLS1.2以上を強制し、CORSポリシーはtrusted originsのみに限定。API Gateway（AWS API GatewayまたはApigee）を導入し、レートリミットやWAFルールを適用して不正リクエストを防ぎます。
テスト戦略と品質ゲート
資産管理アプリでは、BLE通信やオフライン同期といった複雑な振る舞いが多いため、テストは多層的に構築します。ユニットテストでは、Reactコンポーネントのスナップショットテスト（Jest＋React Testing Library）と、Web Bluetooth APIラッパーのモックテストをMochaやSinonで実行。BLE接続成功／失敗、RSSI変動などをシミュレートし、正しいハンドリングを網羅的に検証します。
統合テストでは、docker-composeでExpress APIとMongoDBを立ち上げ、GraphQLクエリとミューテーションをApollo Clientのテストユーティリティで叩き、バックエンド連携が想定どおり動作するかを検証。さらに、PWAのService Workerキャッシュ動作はWorkboxのinjectManifestを使ったテストシナリオを自動化します。
エンドツーエンドテストにはCypressを採用し、実機に近いChrome環境でPWAインストール→オフラインモード→資産スキャン→同期動作の一連フローを自動操作。CIパイプラインでは、プルリクエストごとにすべてのテストを実行し、品質ゲートを突破しなければマージ不可とすることで、リリース品質を担保します。
可観測性と運用監視
本番運用では、フロントエンドとバックエンド双方の可観測性を整備します。クライアント側ではSentryやLogRocketを組み込み、BLE接続エラー、同期失敗、例外クラッシュをリアルタイムで収集。ユーザーセッションごとのログをTrace ID付きで送信し、再現性の高いバグ調査を可能にします。
サーバー側ではPrometheus＋Grafanaを用い、APIレスポンスタイム、エラーレート、DBクエリ時間をメトリクス化。さらに、MongoDB AtlasのPerformance AdvisorとCloud Managerでクエリプランやインデックス利用状況を可視化し、Performance Issueを早期発見。Alertmanagerで閾値超過時にSlackやPagerDutyへ通知し、SREチームが迅速に対応できる運用体制を構築します。
運用・保守体制構築
運用フェーズでは、SREプラクティスに基づくオンコール体制とRunbookを整備します。オンコールチームは2週間スプリントでローテーションし、障害対応手順をConfluenceで一元管理。BLEデバイス登録不具合や同期遅延発生時の切り分けフロー、PWAキャッシュクリア手順、サーバー再起動／スケーリング手順を詳細化。四半期に一度のゲームデイ演習でRunbookの有効性を検証し、チームの熟練度を維持します。
また、バグやフィーチャー要求はJIRAで受付し、インシデントの優先度と工数を定量化。インシデント後には必ず振り返りミーティングを実施し、原因分析（5 Whys）と改善策をRunbookに反映。運用ナレッジは社内Wikiに集約し、新規メンバーのオンボーディングコストを削減します。
データガバナンスとバックアップ戦略
資産データとスキャンログはMongoDB Atlasに保存し、Encryption at RestとField-Level Encryptionを有効化。バックアップ戦略としては、AtlasのContinuous Backupで24時間のポイントインタイムリストアを保証し、7日毎のスナップショットをAWS S3 Glacierへエクスポート。
さらに、データライフサイクルポリシーを設定し、機密性の高いログは60日後、自動的にアーカイブ先へ移動。リストア手順もTerraform＋Ansibleでコード化し、DR訓練時に自動化できる体制を構築。内部監査要件に対応するため、アクセスログと操作履歴をCloudTrailとAtlas Audit Logsで2年間保存し、SIEMツールへ転送して脅威検知を行います。
プロジェクト管理とリスクマネジメント
開発プロジェクトはアジャイル手法で進行し、2週間スプリントでJIRAボードを活用。プランニングではStory Pointで見積もり、デイリースクラムで進捗・障害を共有。スプリントレビューではステークホルダー向けデモを実施し、フィードバックを次スプリントのBacklogに反映。
リスクマネジメントにはRisk Registerを使用し、「BLEデバイス互換性」「PWAキャッシュ整合性」「オフライン同期失敗」の三大リスクを分類。各リスクに対して発生確率と影響度をスコアリングし、Mitigation Planを定義。高リスク項目にはSpikeタスクを設置し、初期フェーズで技術検証を行って工数バッファを確保します。
システム 開発会社 選び方 予算 費用 相場 発注
現場資産管理アプリの受託開発先を選ぶ際は、以下の観点で見積もり依頼を行うと効果的です。
-
Web Bluetooth対応実績：BLE通信の知見、対応デバイス実績
-
PWA開発スキル：オフライン機能、Service Worker設計の経験
-
システム設計力：GraphQL／REST API設計、認証・認可設計能力
-
CI/CD成熟度：GitHub ActionsやArgoCDによる自動化パイプライン構築実績
-
保守運用体制：SREチーム、Runbook作成経験、オンコール対応力
-
契約モデル：固定価格型と時間単価型それぞれのメリット・デメリットを提示可能か
小規模（500万〜800万円）、中規模（1,200万〜1,800万円）、大規模（2,500万〜4,000万円）での相場を参考に、開発予算内で最大の成果を出せるパートナーを選定しましょう。
コストシミュレーションと予算管理
本モバイルアプリ構築プロジェクトの初期費用は約1,200万円と試算。内訳は要件定義200万円、設計300万円、実装400万円、テスト200万円、導入支援100万円。
ランニングコストは、クラウドインフラ（月額10万〜20万円）、MongoDB Atlas運用（月額5万〜10万円）、モニタリングツールライセンス（月額5万〜10万円）を含め、年間約300万〜500万円。AWS BudgetsやAzure Cost Managementでプロジェクトタグを設定し、月次レポートで経営層へ報告。コスト超過時はSlackアラートを発動し、即座にリソース調整を行う体制を整えています。
今後の技術トレンドと展望
Web BluetoothやPWAは標準仕様の進化により、対応ブラウザが増加傾向にあります。2025年以降はChrome for iOSへのBLE対応やWeb NFCとの統合、WebMatter実装など、新規APIが次々リリース予定。さらに、エッジ連携やWebAssemblyによるBLEドライバ最適化でパフォーマンス向上も期待できます。現場資産管理に加え、IoTゲートウェイやARマニュアル連携といった拡張機能も検討し、業務効率をさらに高めるフェーズ2開発を見据えましょう。
まとめ
本開発ノートでは、Web Bluetooth APIとPWAを活用した現場資産管理モバイルアプリの構築プロセスを詳細に解説しました。要件定義から設計、実装、テスト、運用、パートナー選び、コスト管理、そして今後の技術展望までを網羅し、開発受託検討時に必要な情報を一気通貫で提供しています。まずはPoCからスタートし、複数社からの見積もり比較を経て最適パートナーと本格導入を進めましょう。見積もり依頼はこちらからどうぞ。
