スマートメーターデモ 変更履歴（公開用）
このファイルはデモの設計・実装・ドキュメントに対する変更を記録します。
公開ドキュメント
Ver.2
https://qiita.com/Shumpei_Kubo/items/581261ab3848fc8c120b
Ver.1
https://qiita.com/Shumpei_Kubo/items/65691b8b38767674bd92
[v3.2] — 2026-07-30
変更概要
業界専門家との技術ディスカッションを踏まえ、デモのストーリー構成を強化しました。
変更内容
| ファイル | 変更の種類 | 概要 |
|---|---|---|
README.md |
追記 | 冒頭に「このデモが伝えること」セクションを新設。電力自由化の背景・Confluent 3条件・「オーバースペック」注釈を追加 |
DEMO_OVERVIEW.md |
追記 | §0「このデモを見せる前に」を新設。電力自由化の背景、Confluent適用 3条件、掲示板型 vs 郵便型比喩を整理 |
ARCHITECTURE.md |
追記 | 「掲示板型 vs 郵便型」比較表・「Confluent 適用判断ガイド」を追加 |
4_dashboard_map_tokyo23.html |
追記 | サイドバー下部に「なぜ Confluent？3条件」パネルを追加 |
[v3.1] — 2026-07-30
変更の背景・契機
DEMO_OVERVIEW.md のデータリネージュセクション（§5）が旧来のアスキーアート形式であり、
v3.0 で追加した新フィールド（cumulative_kwh・delta_kwh・is_outage_recovery 等）や
ksqlDB の差分計算・マルチコンシューマー構成が反映されていなかったため、Mermaid 図に全面刷新した。
変更内容
変更ファイル: DEMO_OVERVIEW.md
旧来のアスキーアート1図 + テーブル + テキスト構成を、以下5つの Mermaid 図に置き換えた。
| セクション | 図の種類 | 内容 |
|---|---|---|
| 5-1. システム全体フロー | flowchart LR |
①データ生成→②Confluent→③ksqlDB→④サーバー→⑤ブラウザ の5段階。ksqlDB 経路とローカル集計経路の2パスを明示 |
| 5-2. フィールドレベルのデータリネージュ | flowchart LR |
全11フィールドの生成→Kafka通過→ksqlDB変換→集計→表示 の流れをフィールド粒度で追跡。cumulative_kwh → LAG() → delta_kwh（Confluent上差分計算）を可視化 |
| 5-3. 停電バーストシナリオ | sequenceDiagram |
フェーズ1（通常）→フェーズ2（停電・蓄積）→フェーズ3（復旧バースト）の3段階を時系列で表現。実測値（0.5秒・93,000件/秒）を記載 |
| 5-4. フィールドの変化まとめ | テーブル | 旧4列（生成/Kafka/集計後/表示）→新5列（生成/Kafka/ksqlDB/集計後/表示）に拡張。v3.0追加フィールドをすべて反映 |
| 5-5. end-to-end レイテンシ | gantt |
通常フロー（1〜2秒）とバーストフロー（0.5秒送信後に後段は通常ペース）を時間軸で比較 |
旧形式との主な差分
| 項目 | 旧（v3.0以前） | 新（v3.1） |
|---|---|---|
| 図の形式 | アスキーアート | Mermaid（GitHub / Obsidian 等で自動レンダリング） |
| フィールド数 | 7フィールド（kwh 中心） |
11フィールド（cumulative_kwh・delta_kwh 等 v3.0追加分を網羅） |
| ksqlDB の扱い | 記述なし | LAG() 差分計算・二系統集計を図に明示 |
| 停電バーストの表現 | 記述なし | Sequence 図で3フェーズを時系列可視化 |
| レイテンシ表現 | テキスト箇条書き | Gantt 図で通常時・バースト時を比較 |
[v3.0] — 2026-07-30
変更の背景・契機
以下の3つのインプットをもとに、デモ全体を業界実態に即した内容へ刷新した。
| インプット | 概要 |
|---|---|
| 電力業界関係者との技術ディスカッション (2026-07-29) | 積算値方式・停電バースト・マルチコンシューマーなど実業務の知見を収集 |
| 東京電力 スマートメータープロジェクト資料 | PLC通信・コレクタ構成・30分値・2,900万台規模などの実態 |
| 経産省 次世代スマートメーター仕様書 Rev5.1 (2026-03-27) | 1分値収集・停電即時通知・LTE-Mハイブリッド・双方向計量などの新仕様 |
変更内容
1. データモデルの変更（積算値方式への移行）
変更ファイル: smart_meter_generator.py / smart_meter_generator_tokyo23.py
変更前の問題
-
kwhフィールドを「その10秒間の消費量」として直接生成していた - 実際のスマートメーターは積算値（odometer型） のみを保持・送信するという実態と乖離していた
変更後
| フィールド | 変更内容 |
|---|---|
cumulative_kwh |
新規追加。起動時に1000〜9999 kWhで初期化し、バッチごとにインクリメント。実際のメーターが送信する積算値を模倣 |
kwh |
今回バッチの増分（デモ表示用・ksqlDB LAG() のフォールバック値として併送） |
value_type |
新規追加。"provisional"（速報値）/ "confirmed"（確定値） |
is_outage_recovery |
新規追加。停電復旧時の蓄積データ送信フラグ（bool） |
sequence_no |
新規追加。バースト時の順序保証・重複排除用の送信連番 |
実態との対応
実際のメーター送信: cumulative_kwh（積算値のみ）
消費量の計算: 受信側（HES or Confluent上のksqlDB）が差分計算
例) 12:00 → 1234.567 kWh
12:30 → 1237.089 kWh
差分 → 2.522 kWh（30分間の消費量）
2. ksqlDB クエリの全面刷新（Confluent上での差分計算）
変更ファイル: 3_ksqldb_queries.sql
変更前: kwh（瞬間消費量）を直接集計するシンプルなウィンドウ集計のみ
変更後: 6ステップ構成に拡充
| Step | ストリーム/テーブル名 | 役割 |
|---|---|---|
| 1 | smart_meter_stream_tokyo23 |
生データストリーム定義（cumulative_kwh を受信） |
| 2 | smart_meter_delta |
LAG() で積算値→差分計算（Confluent上で実施） |
| 3 | district_power_1min |
速報集計（1分ウィンドウ・速報ダッシュボード用） |
| 4 | district_power_30min_confirmed |
確定値集計（30分ウィンドウ・課金計算用） |
| 5 | outage_recovery_events |
停電バースト検知フィルター（is_outage_recovery=true 抽出） |
| 6 | meter_alerts |
異常メーター抽出（CP4D / Maximo 連携用） |
訴求ポイント: 同一トピック（smart_meter_tokyo23）を3つの Consumer Group が独立消費する「掲示板型」マルチコンシューマー構成を実装した。
smart_meter_tokyo23
├── Consumer Group A → district_power_1min（速報ダッシュボード）
├── Consumer Group B → district_power_30min_confirmed（課金確定値）
└── Consumer Group C → meter_alerts（異常検知・AI分析）
3. ダッシュボードサーバーの起動モード整理
変更ファイル: 4_dashboard_server.py / 4_dashboard_server_tokyo23.py
変更前: --local-aggregate（デフォルト）/ --offline の2モード
変更後: 3モードに整理し、ksqlDB モードをデフォルトに変更
| フラグ | トピック | 集計場所 | 用途 |
|---|---|---|---|
--ksqldb（デフォルト） |
district_power_1min |
Confluent上のksqlDB | 本番推奨。差分計算はConfluent側で完結 |
--local-aggregate |
smart_meter_tokyo23 |
Pythonサーバー側 | ksqlDB クラスター不要の簡易デモ |
--offline |
なし（ローカル生成） | Pythonサーバー側 | Kafka 接続不要のオフラインデモ |
4. Producer への停電バースト機能追加
変更ファイル: 2_produce_to_confluent_tokyo23.py / 2_produce_to_confluent.py
追加フラグ
# 60分間の停電を想定した復旧バースト送信
python 2_produce_to_confluent_tokyo23.py --outage-recovery --outage-minutes 60
# 送信内容
# - 345台 × 360バッチ（60分÷10秒）= 124,200件を一括送信
# - is_outage_recovery=true フラグ付き
# - バースト送信時刻は停電中の過去時刻を再現
# - sequence_no で順序保証
バッファ設定も追加（BufferError 対策）
"queue.buffering.max.messages": "500000", # バースト送信用にキュー拡大
"queue.buffering.max.kbytes": "1048576", # 1GB
停電シナリオ自動演出スクリプト: outage_scenario.py を新規作成
3段階を自動で演出：
- 通常運転（30秒・3バッチ送信）
- 停電（20秒間 送信ゼロ・カウントダウン表示）
- 復旧バースト（蓄積データを一括送信）
5. ダッシュボード HTML へのバーストインジケーター追加
変更ファイル: 4_dashboard_map_tokyo23.html
追加要素
| 追加内容 | 説明 |
|---|---|
| 「受信レート（件/秒）」KPI | 1秒ごとにスループットを計測・表示 |
| 「累計受信件数」KPI | 接続後の総受信件数を表示 |
| 停電復旧バーストインジケーター |
outage_recovery_count > 0 を検知すると画面下部に赤バナーが点灯・点滅。is_outage_recovery=true フラグ検知 | Confluent が高負荷を吸収中 と表示 |
6. ドキュメントの刷新
変更ファイル: ARCHITECTURE.md / DEMO_OVERVIEW.md / README.md
主な追記内容：
- 実際の5段階通信経路図（メーター→PLC→コレクタ→WAN→HES→Confluent→各システム）
- 「10秒間隔はデモ映え用」の明示的な注記（実際は30分値/1分値）
- 本番スケール対比表
| 指標 | 本デモ | 東京電力管内（現行30分値） | 東京電力管内（次世代1分値） |
|---|---|---|---|
| メーター数 | 345台 | 約2,900万台 | 同左 |
| 送信レート | 34.5件/秒 | 約16,100件/秒 | 約484,000件/秒 |
| 停電1時間分バースト | 約12,420件 | 約17.4億件 | 約17.4億件 |
-
次世代スマートメーター（Rev5.1）の記述追加
- 1分値収集が標準仕様に（2024年度〜順次展開）
- 停電発生のリアルタイム通知（数秒以内）が仕様化
- LTE-M とのハイブリッド通信経路
- 双方向計量（太陽光逆潮流）の標準化
デモ実施記録（2026-07-30）
実施内容
| # | シナリオ | 結果 |
|---|---|---|
| 1 | 東京23区版 通常デモ起動 | 345台・10秒間隔・ブラウザ接続確認 |
| 2 | 停電バースト（単発） | 124,200件を1.2秒で送信。約105,000件/秒。通常比約3,000倍 |
| 3 | 停電→復旧シナリオ（3段階自動演出） | 通常30秒→停電20秒→バースト0.5秒。10,350件を93,000件/秒で送信 |
実測値
| 指標 | 通常時 | バースト時（60分停電想定） |
|---|---|---|
| 送信レート | 34.5件/秒 | 約105,000件/秒 |
| 1回の送信件数 | 345件/バッチ | 124,200件 |
| 件数倍率 | 基準 | 約360倍 |
| レート倍率 | 基準 | 約3,000倍 |
| Confluent蓄積総件数（累計） | — | 1,749,445件 |
確認された Confluent 訴求ポイント
- 高スループット吸収: 3,000倍のバーストを受け取りながら後段への直撃を防いだ
- バッファリング: バースト後も後段（ダッシュボード）は自分のペース（1秒集計）で消費できた
-
データ保持・再処理: 蓄積データは7日間保持。
auto.offset.reset=earliestで過去データの再計算が可能 - マルチコンシューマー: 同一トピックを速報用・確定値用・異常検知用が独立して消費できる構成
変更ファイル一覧
| ファイル | 変更種別 | 主な変更内容 |
|---|---|---|
smart_meter_generator.py |
修正 | 積算値モデル・新フィールド追加 |
smart_meter_generator_tokyo23.py |
修正 | 同上（東京23区版） |
2_produce_to_confluent.py |
修正 |
--outage-recovery フラグ追加・コメント修正 |
2_produce_to_confluent_tokyo23.py |
修正 | 同上・バッファ設定追加 |
3_ksqldb_queries.sql |
全面書き換え | LAG() 差分計算・速報/確定二系統・バースト検知追加 |
4_dashboard_server.py |
修正 |
--ksqldb モード追加・デフォルト変更 |
4_dashboard_server_tokyo23.py |
修正 | 同上・TOPIC_NAME → RAW_TOPIC 参照修正 |
4_dashboard_map_tokyo23.html |
修正 | バーストインジケーター・スループット KPI 追加 |
ARCHITECTURE.md |
修正 | v3.0へ更新・5段階通信経路図・積算値解説追加 |
DEMO_OVERVIEW.md |
修正 | デモ映え注記・本番スケール表・バースト手順追加 |
README.md |
修正 | デモシナリオ説明刷新・バーストデモ手順追加 |
outage_scenario.py |
新規作成 | 停電→復旧バースト 3段階自動演出スクリプト |
CHANGELOG.md |
新規作成 | 内部用変更履歴ファイル |
CHANGELOG_PUBLIC.md |
新規作成 | 本ファイル（公開用） |
[v2.0] — 2026-07（東京23区版追加）
- 東京23区版（23区・345台）を高松市版に追加
-
smart_meter_generator_tokyo23.py新規作成 -
2_produce_to_confluent_tokyo23.py新規作成 -
4_dashboard_server_tokyo23.py新規作成 -
4_dashboard_map_tokyo23.html新規作成（Leaflet.js バブル地図） - トピック
smart_meter_tokyo23（23パーティション）追加
[v1.0] — 2026-07（初版 高松市版）
- 高松市5地区・36台のスマートメーターデモを初期構築
-
smart_meter_generator.py・2_produce_to_confluent.py・4_dashboard_server.py作成 - ksqlDB クエリ（
3_ksqldb_queries.sql）作成 - 棒グラフ版（
4_dashboard.html）・地図版（4_dashboard_map_takamatsu.html）作成 - トピック
smart_meter_readings（5パーティション）使用