1. HOME
  2. ブログ
  3. 開発ノート
  4. IoT機器向けエネルギーマネジメントダッシュボード開発ノート
BLOG

ブログ

開発ノート

IoT機器向けエネルギーマネジメントダッシュボード開発ノート

プロジェクト概要

製造現場やスマートビルディングに設置された複数のIoTセンサーから電力・温度・稼働データをリアルタイム収集し、消費傾向を可視化するエネルギーマネジメントダッシュボードをFlutter+Reactで開発した際の技術記録です。要件定義フェーズから受託先選定、システム設計、開発フロー、テスト戦略、運用保守までを一貫してまとめ、同様のシステム開発依頼を検討中の企業様向けに見積もり比較のポイントを整理しています。

要件定義と見積もり依頼準備

本システムの主なユースケースは「複数拠点の消費電力量を時系列で比較」「異常消費検知アラート」「デバイス単位での予測消費量シミュレーション」「PDF/Excelレポート自動出力」の四つです。各機能に対しGiven/When/Then形式で要件を明文化し、見積もり依頼用ドキュメントへ以下の項目を盛り込みました。
・IoTデバイス数(10~200台)とデータ送信間隔(1秒~5分)
・バックエンドAPI(受託)とフロントエンドUI(自社開発/受託)の境界
・データ保持期間(1年~5年)およびアーカイブ要件
・レポートフォーマット(PDF版、Excel版)と出力頻度
・異常検知ロジック:閾値ベース/機械学習モデルベース
これにより、Web開発会社やアプリ開発会社への相見積もり精度を高め、要件抜け漏れを防止しました。

システム設計とアーキテクチャ

本システムは「デバイス層」「エッジゲートウェイ層」「クラウドAPI層」「ダッシュボード層」の四層構成です。
デバイス層ではESP32やRaspberry PiがMQTTで温度・電力データをJSON形式で送信。エッジゲートウェイにはNode.js+Mosquittoを使い、一時バッファとデータ前処理(移動平均、外れ値除去)を行います。
クラウドAPI層はGo製gRPCサーバーとREST APIを併用。時系列DBにInfluxDBを採用し、Grafana/Prometheusとの親和性を活用。認証はOAuth2.0+JWTでユーザーごとにアクセス制御を実装。
ダッシュボード層はFlutter Webで共通UIを構築し、React製管理画面でユーザー管理・レポート出力機能を提供。データ可視化ライブラリにRechartsとHighchartsを併用し、要件に応じたグラフを選択しています。

データ収集・前処理パイプライン

IoTデバイスからのデータはまずエッジゲートウェイに集約され、Node.jsコンテナ内でストリーム処理。Kafka Streamsを導入し、各デバイス別のウィンドウ集計(1分間隔)とアラート判定をリアルタイムに実行します。統計量は平均・最大・最小値を算出し、MQTTまたはKafka経由でクラウドAPIへプッシュ。これにより、ネットワーク断発生時もエッジ上で暫定的な異常検知が可能です。

クラウド側では受信した集計データをInfluxDBへ時系列書き込みし、長期履歴はParquet形式でS3互換ストレージへアーカイブ。Athenaでのオンデマンド分析とBIツール連携を視野に入れた設計としました。

前処理と機械学習モデル連携

異常検知ロジックは閾値ベースに加え、Prophetを使った消費予測モデルを組み合わせ。Pythonマイクロサービスで定期的に学習・推論ジョブを実行し、予測値と実測値の乖離が大きい場合にアラートを生成。モデルはDockerizedし、Kubeflow PipelineでCIを回してバージョン管理と再学習を自動化しています。

これにより、設備老朽化や季節変動による異常も検知可能となり、保守運用コストの削減につながる設計を実現しました。

フロントエンド開発フロー

Flutter WebアプリはMVVMパターンで開発。Providerを使った状態管理とFreezed/JSON Serializableでモデルクラス自動生成。GraphQLサブスクリプトをApollo Clientで実装し、キャッシュ戦略(キャッシュファースト・ネットワークファースト)を機能別に切り替え可能としました。
UIデザインはFigmaでプロトタイプを作成し、ユーザーテストで可読性や操作性を改善。管理画面はReact+TypeScriptで、Ant Designのコンポーネントを活用し、ガイドラインに沿った統一感のあるデザインとしています。

CI/CDではGitHub Actionsによりプルリク毎にユニットテスト・Widgetテストを実行し、Staging環境への自動デプロイを実装。ProdデプロイはSlack承認ワークフローを通じて実行し、ダウンタイムゼロリリースを達成しました。

テスト戦略と品質保証

本システムでは、IoTデータ収集からダッシュボード表示まで多層アーキテクチャを採用しているため、各層に合わせたテスト戦略を構築しました。まずデバイスやエッジゲートウェイ層では、ESP32やRaspberry Piのセンサーデータ送信をモック化してpytestとpytest-mqttを使ったユニットテストを実行。移動平均や外れ値除去ロジックはscipyベースのテストベンチを用い、異常値パターンやネットワーク断による再接続動作を自動検証します。

クラウドAPI層では、Go製gRPCサーバーに対してGoのtestingパッケージでエンドポイント単体テストを行い、RESTエンドポイントはPostman/NewmanでContract Testを実施。時系列DB(InfluxDB)への書き込み整合性は、テスト用InfluxDBコンテナを用意し、influxdb-client-goでクエリ結果と期待値の自動比較を行います。

ダッシュボード層はFlutter側でWidgetテストを100%カバーし、Provider状態管理、GraphQLサブスクリプトのキャッシュ挙動を検証。React管理画面はJest+React Testing Libraryでコンポーネント単位のスナップショットテストとE2EテストをCypressで自動化し、UIの回帰防止を徹底しました。

パフォーマンステストにはk6を利用し、「1,000デバイスが1秒間隔で送信→クラウドAPI処理→InfluxDB書き込み→Dashboard更新」のEnd-to-Endシナリオを30分間連続実行。CPU/メモリ使用率、リクエストレイテンシ、失敗率をPrometheusに取り込み、SLI/SLOで定義した「99パーセンタイルレイテンシ300ms以内」「エラー率0.1%未満」をクリアすることをCI上で自動判定しています。

モニタリングとログ集約

本番運用では可視化とリアルタイム通知が鍵となるため、モニタリング基盤を全面的に整備しました。エッジゲートウェイのNode.jsプロセスにはWinston+Fluent Bitエージェントを組み込み、JSON形式で「受信レート」「処理遅延」「MQTT再接続回数」を構造化ログとして出力、Fluent BitでElasticsearchに転送。Kibanaダッシュボードで「デバイス別エラーレート」「再接続頻度」などを定期的にレビューしています。

クラウド側ではOpenTelemetry Go SDKをgRPCサーバーに組み込み、トレースとメトリクスをJaeger+Prometheusにエクスポート。各エンドポイントのP50/P95/P99レイテンシ、InfluxDB書き込み失敗件数、Prophet推論ジョブの成功率などをGrafanaで可視化し、Alertmanagerで「レイテンシ200ms超過が継続5分」「書き込み失敗率1%超過」をSlackチャンネルに通知。オンコールチームが10分以内に対応を開始できる体制を構築しています。

フロントエンドのパフォーマンスはGoogle’s Web VitalsをReact管理画面に組み込み、First Contentful PaintやTime to Interactiveを計測。Flutter WebではDevToolsのPerformanceメトリクスをCIジョブに取り込み、リリース前に必ず60fps維持を自動チェックしています。

セキュリティとデータ保護

IoTシステム特有のセキュリティ要件を満たすため、デバイス⇔エッジゲートウェイ間はTLS1.2+証明書ピンニングを実装。デバイスごとに発行したX.509証明書をESP32に搭載し、不正デバイスの接続を防止します。エッジ⇔クラウド間はmTLSを行い、gRPCサーバーはVaultで管理するクライアント証明書を使用。JWT認証をAPIゲートウェイ層で検証し、スコープベースのRBACを適用。

クラウドAPI層はOWASP API Security Top 10に準拠し、Rate Limiting/IP制限/WAFルールをAPI Gatewayで設定。SQL InjectionやMass Assignmentへの対策として、Goのsqlx+パラメタライズドクエリを厳守し、ORMの自動マッピングは使用せず明示的コーディングを行いました。

ダッシュボード層では、Flutter Webのローカルストレージに保存するトークンにAES-256暗号化を適用し、React管理画面はSecure HTTP-Only CookieでCSRF対策。定期的な脆弱性スキャンにTrivyとOWASP ZAP CIプラグインを組み込み、イメージ/API脆弱性を自動検出・Issue化しています。

CI/CDパイプラインと自動化

開発フローはGitOpsを採用し、GitHub Actionsで以下を自動化しています。

  • プルリクエスト時:Flutter/ReactのLint、ユニットテスト、k6パフォーマンステストのSmoke実行

  • マージ後:Dockerイメージビルド・プッシュ、Helmチャートパッケージ、Terraformプラン適用

  • ステージング:自動デプロイ後にE2Eテスト(Cypress+Flutter Driver)を実行

  • 本番:Slack承認後にアプローチブルデプロイ+ブルーグリーン切替

また、Secret管理はGitHub SecretsとVault連携で行い、IaC(Terraform)実行時に自動的に最新のシークレットを注入。GitHub ActionsはセルフホストRunnerをエッジロケーションに配置し、レイテンシを抑えつつリリースを高速化しています。

運用保守とRunbook

運用フェーズではSREチームが24×7オンコール体制で対応します。Confluence上にRunbookを整備し、主な障害シナリオに対して以下手順を具体化しました。

  • エッジゲートウェイダウン:k3s ノード再起動→kubectl rollout restart

  • MQTT接続障害:Certificate再配布→systemctl restart mosquitto

  • InfluxDB書き込み詰まり:バックアップリストア+Shard修復コマンド

  • Prophetジョブ失敗:kubectl logs確認→kubectl rollout undo

四半期ごとにChaos Engineering演習を実施し、Runbookの精度とチーム対応力を検証。インシデント後はBlameless Postmortemを実施し、JIRAで改善タスクを自動生成、Runbookに反映して平均MTTRを2時間から1時間へ短縮しました。

コストシミュレーションと予算管理

本プロジェクトの初期構築費用は以下の通り試算しました。

  • 要件定義・要件精査:300万円

  • エッジゲートウェイ開発:400万円

  • クラウドAPI/DB構築:600万円

  • ダッシュボード開発(Flutter+React):500万円

  • ML前処理&Prophet連携:300万円

  • テスト&CI/CD整備:200万円

  • モニタリング基盤構築:200万円

  • 運用サポート・Runbook作成:200万円
    合計:約2,700万円

ランニングコストは、MQTTブローカー(月額5万〜10万円)、EKS/GKE運用(月額20万〜30万円)、InfluxDB Cloud(月額10万〜20万円)、Grafana Cloud(月額5万〜10万円)を含め、年間約480万〜700万円と試算。AWS BudgetsやGCP Billingでタグ別可視化し、月次検証レポートとSlack通知で予算超過を早期検出・対策を実施します。

システム 開発会社 選び方 予算 費用 相場 発注

IoTエネルギーマネジメントダッシュボードの受託先選定では、下記の比較軸で複数社に同一フォーマットの要件定義書・WBSを提供し、見積もり比較を実施してください。

  1. IoTエッジ開発実績:ESP32/Raspberry PiでのMQTT連携事例

  2. エッジゲートウェイ構築力:Node.js+Kafka Streams運用経験

  3. クラウドAPI&DB:Go gRPC+InfluxDB構築実績

  4. フロントエンド開発:Flutter Web+React共通UI設計

  5. ML前処理&予測:Prophetまたは類似ツール導入経験

  6. CI/CD+IaC:GitHub Actions+Terraform+Helm Charts自動化ノウハウ

  7. モニタリング&運用:OpenTelemetry/Prometheus/Fluent Bit導入実績
    相場感は、小規模(1,800万〜2,500万円)、中規模(2,800万〜4,000万円)、大規模(4,500万〜6,000万円)を目安とし、固定価格型・時間単価型いずれの条件も比較検討のうえ、コスト削減と費用対効果を最大化できるパートナーを選定しましょう。

まとめ

本開発ノートでは、IoT機器からのリアルタイムデータ収集、エッジゲートウェイ処理、クラウドAPI設計、Flutter/Reactダッシュボード開発、テスト戦略、可観測性、セキュリティ、CI/CD、運用保守、コストシミュレーション、ベンダー選定ポイントまで一貫して解説しました。スマート製造現場やビルディング管理におけるエネルギー最適化プロジェクトの成功には、まずPoCで技術検証を行い、複数社の見積もり比較を通じて最適な受託先を選定してください。見積もり依頼はこちらからどうぞ。

お問合せ

不明点やお見積りの依頼などお気軽にください。




問い合わせを行う

関連記事