🔖 キーワード索引

この用語と一緒に検索・参照されやすいタグ。 関連ページに飛ぶときの手がかりにも使えます。

このページで繰り返し出てくる用語。 窓で集計する道具（上の 3 つ）、 速さの制約（次の 3 つ）、 画面を誤読させない工夫（その次の 4 つ）、 実装に使うライブラリ（最後の 3 つ）の順に並べた。

🎨 直感で掴む

「リアルタイム可視化」を最初に学ぶときは、 厳密な定義よりイメージを優先しましょう。 以下は具体例・比喩を用いた直感的理解の入口です。

• 株価ボードや地下鉄の運行状況がそのまま例。 「今この瞬間」を見せる。
• 更新頻度＝人間の意思決定速度で決める。 1 秒更新が必要な場面は実はそう多くない。
• 「速い更新」と「多すぎる情報」は別問題。 サマリ指標で集約する設計力が要る。

🎨 直感で掴む — リアルタイム可視化

リアルタイム可視化は「到着し続けるデータを 1〜10 秒以内に画面に反映する」可視化の枠組み。 IoT・株価・SNS・スポーツ計測などで使われる。 SSDSE-B-2026 のような年次集計データは「リアルタイム」ではないが、 「毎年の更新で図が自動でリフレッシュされる」ダッシュボードは同じ設計思想。

🎨 リアルタイム可視化 — 「動くグラフ」の真の難所

リアルタイム可視化 (Realtime Visualization) とは、 ストリーミング的に到来するデータを 1 秒以下のレイテンシで描画し続ける手法。 IoT センサ、 株価、 SNS トレンド、 公共交通モニタリング、 災害情報共有などで必須。

「単に matplotlib をループで叩く」のとは違う。 真の難所は次の 5 点。

1. レイテンシ: データ到着 → 描画完了 までの遅延。 100ms 以下が目標
2. メモリ膨張: 全データを保持すると数時間で OOM。 sliding window や reservoir sampling で間引く
3. 古いデータの扱い: 1 時間前のデータをどう減衰させるか (EMA, decay)
4. 同時接続スケーリング: 1000 人がダッシュボードを見ても落ちないか (WebSocket, pub/sub)
5. UI 認知負荷: チラツキ、 過剰アニメーション、 視覚的記憶の干渉

📐 定義・数式

やさしい説明で掴んだ感覚を、ここで ストリーム集計（スライディングウィンドウ） の定義式に対応づけます。下の式は左辺 $\bar{x}_t$ が何で決まるかを右辺で書き下したもので、x̄（平均）、Σ（合計）、分数（割り算） が現れます。それぞれの記号が何の量を指すのかは、次の「🔬 数式を言葉で読み解く」で 1 つずつ確かめてください。

📐 定義・数式 — リアルタイム可視化

📐 数式: スライディングウィンドウ・EMA・Reservoir

スライディングウィンドウ平均

$$ \bar x_t^{(W)} = \frac{1}{W} \sum_{i=t-W+1}^{t} x_i $$

指数移動平均 (EMA)

$$ \mathrm{EMA}_t = \alpha \cdot x_t + (1 - \alpha) \cdot \mathrm{EMA}_{t-1}, \quad \alpha = \frac{2}{W + 1} $$

Reservoir Sampling (Algorithm R, Vitter 1985)

$$ P(\text{要素 } x_t \text{ がサンプルに残る}) = \frac{k}{t} $$

$t$ 件目を見た時点で、 サイズ $k$ のリザーバの中に保持される確率は一様 $k/t$。 全データを保存せずとも、 一様ランダムサンプルが維持できる。

🔬 数式を言葉で読み解く — EMA の挙動

• $\alpha$: 新値の重み (0 < α < 1)。 大きいほど新しい値に敏感、 小さいほど滑らか
• $\alpha = 2/(W+1)$: ウィンドウ幅 $W$ 相当の単純平均と同じ「実効平均長」になる伝統的設定
• $(1-\alpha) \cdot \mathrm{EMA}_{t-1}$: 過去の蓄積を指数的に減衰
• メモリ効率: 過去全データを保持せず、 直前の EMA 値 1 つだけで OK → O(1) メモリ
• レイテンシ: 計算量 O(1) → 何 Hz でも更新可能

🔬 数式を言葉で読み解く — Reservoir Sampling

• キーアイデア: $t \leq k$ なら全部入れる、 $t > k$ なら確率 $k/t$ で入れ替える
• 帰納的に: 入った後、 次のステップで「上書きされない」確率も考慮すると、 最終的に全要素が等確率 $k/N$ で残る
• 応用: ストリーミングデータから一様サンプル可視化、 ヒストグラムの維持、 anomaly detection の baseline 抽出

🔬 数式を言葉で読み解く

📐 章の 2 つの式を、 東京都の総人口（A1101）を「1 年度 = 1 件」として到着順に流す擬似ストリームで読む。 最新の到着を 2023 年度、 窓幅を W = 3 とする。

和の範囲 $i=t-W+1$ から $t$ が 1 つずれるたびに、 入る値は最新の 1 件、 抜ける値は最古の 1 件だけである。 そのため窓平均は全件を足し直さなくても $\bar{x}_{t} = \bar{x}_{t-1} + (x_t - x_{t-W})/W$ で更新できる。 2022 年度の窓平均 14,031,864.67 人から、 2023 年度に入る 14,086,000 人と抜ける 2020 年度の 14,047,594 人の差 38,406 人を 3 で割った 12,802 人を足すと 14,044,666.67 人になり、 表の値と一致する。 レイテンシの式の側から見ると、 この「足して引くだけ」の更新が $T_{\text{process}}$ を件数によらず一定に保つ仕組みである。

🧮 実値で計算してみる

ダッシュボード設計の典型レイヤ：

🧮 SSDSE-B-2026 をストリーム化して可視化

SSDSE-B-2026 (年度×都道府県 のパネル) を擬似ストリームとして再生し、 リアルタイム可視化の挙動を学ぶ。 1 年分 = 1 イベント (47 県分) と見立てて 0.5 秒間隔で配信。

📥 入力データ:

🐍 matplotlib FuncAnimation でストリーム可視化

🎯 このコードでやること: SSDSE データを年度順に「1 年あたり 0.5 秒」で送り出し、 47 都道府県の人口推移をリアルタイムに折れ線描画する最小例。

📥 入力: SSDSE-B-2026 全行 (564 行)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

import pandas as pd
import matplotlib.pyplot as plt
from matplotlib.animation import FuncAnimation

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.dropna(subset=['A1101']).sort_values(['Prefecture','SSDSE-B-2026'])
prefs = df['Prefecture'].unique()[:5]  # 5 県だけ可視化 (見やすさ)
years = sorted(df['SSDSE-B-2026'].unique())

fig, ax = plt.subplots(figsize=(10, 5))
lines = {p: ax.plot([], [], label=p)[0] for p in prefs}
ax.set_xlim(years[0], years[-1])
ax.set_ylim(0, df[df['Prefecture'].isin(prefs)]['A1101'].max() * 1.1)
ax.legend()
ax.set_xlabel('SSDSE-B-2026'); ax.set_ylabel('人口 (人)')

def update(frame_year):
    for p in prefs:
        sub = df[(df['Prefecture']==p) & (df['SSDSE-B-2026']<=frame_year)]
        lines[p].set_data(sub['SSDSE-B-2026'], sub['A1101'])
    ax.set_title(f'年度: {frame_year}')
    return list(lines.values())

ani = FuncAnimation(fig, update, frames=years, interval=500, blit=False, repeat=False)
ani.save('rtv_demo.gif', writer='pillow', fps=2)
print('saved rtv_demo.gif')

📤 実行例:

💬 prefs は unique()[:5] で取っているので、人口の大きい県ではなく並べ替えで先に来る 5 県（三重・京都・佐賀・兵庫・北海道）が描かれ、どれも右下がりの線になる。東京都などを見たいときは prefs を名前で指定する。FuncAnimation は最も学習コストが低い手法。 ただしブラウザ表示には GIF/MP4 化が必要。 本番ストリーミングには bokeh/Dash 系を選ぶ。 SSDSE のように既知データを「擬似ストリーム再生」する練習に最適。

🧮 数式に値を入れて手で計算する: 更新頻度とデータポイント数

合成データでリアルタイム可視化のメモリ使用量を計算する。

Step 1: パラメータ

Step 2: 計算

🐍 Python で再現

1
2
3
4
5
6
7

hz = 10
point_b = 20
hours = 1
points = hz * 3600 * hours
mem_kb = points * point_b / 1024
print(f"ポイント数: {points:,}")
print(f"メモリ: {mem_kb:.1f} KB")

📤 実行結果

💬 手計算 (Step 2) 703 KB と Python 出力が完全一致。

🧮 窓平均の足し引き更新と EMA を東京都の総人口で手計算する

上のメモリ計算に続けて、 📐 章のスライディングウィンドウ平均と EMA を実データで手計算し、 同じ値を Python で再現する。 データは SSDSE-B-2026 の東京都 A1101（総人口）を年度の昇順に並べたもの。

Step 1（2021 年度の窓平均、 W = 3）：(14,007,000 + 14,047,594 + 14,010,000) ÷ 3 = 42,064,594 ÷ 3 = 14,021,531.33 人。

Step 2（2022 年度へ足し引き更新）：入る 14,038,000、 抜ける 14,007,000。 14,021,531.33 + (14,038,000 − 14,007,000) ÷ 3 = 14,021,531.33 + 10,333.33 = 14,031,864.67 人。

Step 3（2023 年度へ足し引き更新）：14,031,864.67 + (14,086,000 − 14,047,594) ÷ 3 = 14,031,864.67 + 12,802 = 14,044,666.67 人。

Step 4（EMA、 α = 2/(W+1) = 0.5）：2012 年度の値を初期値にして 2022 年度まで回した EMA は 14,013,472.77 人。 2023 年度は 0.5 × 14,086,000 + 0.5 × 14,013,472.77 = 7,043,000 + 7,006,736.39 = 14,049,736.38 人。 EMA は最新値に重み 0.5 を置くので、 窓平均（14,044,666.67 人）より最新の 14,086,000 人に近い。

🎯 このコードでやること：東京都の総人口を 1 年度ずつ流し、 窓の合計だけを持ち歩く足し引き更新と EMA を自前で計算して、 pandas の rolling・ewm と一致するかを確かめる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

from collections import deque
import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
tokyo = (df[df['Prefecture'] == '東京都']
         .sort_values('SSDSE-B-2026')            # CSV は新しい年度が先なので昇順に並べ直す
         .set_index('SSDSE-B-2026')['A1101'])     # 総人口（人）

W = 3
win, s = deque(), 0.0            # 窓の中身と、その合計だけを持ち歩く
ema, alpha = None, 2 / (W + 1)   # alpha = 0.5
for year, x in tokyo.items():
    win.append(x); s += x
    if len(win) > W:
        s -= win.popleft()       # 最古の 1 件を引く → O(1) 更新
    ema = x if ema is None else alpha * x + (1 - alpha) * ema
    if year >= 2021:
        print(f'{year}: x={x:,}  窓平均={s / len(win):,.2f}  EMA={ema:,.2f}')

# pandas の rolling / ewm と一致するか
print('rolling(3) 2023 =', f"{tokyo.rolling(W).mean()[2023]:,.2f}")
print('ewm(0.5)   2023 =', f"{tokyo.ewm(alpha=alpha, adjust=False).mean()[2023]:,.2f}")

💬 Step 1〜3 の窓平均 14,021,531.33・14,031,864.67・14,044,666.67 人と、 Step 4 の EMA 14,049,736.38 人が手計算と一致し、 pandas の rolling(3)・ewm(alpha=0.5, adjust=False) とも同じ値になった。 自前の更新は窓の中身 3 件と合計 1 つしか持たないが、 全件を足し直す rolling と同じ結果を返す。

✅ 理解度チェック — 実データの数値で解く

1. 問：上の表で、 2021 年度に W = 2 の窓平均はいくらか。
   答：(14,047,594 + 14,010,000) ÷ 2 = 14,028,797 人。 2020 年度の W = 2 平均 (14,007,000 + 14,047,594) ÷ 2 = 14,027,297 人より 1,500 人大きく、 生値が 37,594 人減った年でも窓平均は「増加」を示す。
2. 問：10 秒ごとに 1 回、 誤報率 1% の閾値判定をする画面を 20 分見続けると、 正常時でも 1 回以上誤報する確率はいくらか。
   答：判定は 120 回なので 1 − 0.99¹²⁰ = 0.701、 約 70%。 3σ 基準（誤報率 0.27%）でも 1 − 0.9973¹²⁰ = 0.277 になる。
3. 問：5 Hz で届く 1 点 20 byte のデータを 1 時間分そのまま保持すると何 KB か。
   答：5 × 3,600 = 18,000 点、 18,000 × 20 = 360,000 byte ÷ 1,024 = 351.6 KB。 上の Step 2（10 Hz で 703.1 KB）のちょうど半分になる。
4. 問：大きさ k = 10 のリザーバで 500 件目が届いたとき、 その 500 件目がリザーバに入る確率は。
   答：k/t = 10/500 = 0.02（2%）。 それまでの 499 件も最終的に同じ 10/500 の確率で残る。

🐍 Python 実装

1
2
3
4
5
6
7
8
9

# Streamlit でリアルタイム風の表示（streamlit run app.py で起動する）
import streamlit as st, pandas as pd, time

ph = st.empty()
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])  # 2 行目の日本語ラベルを飛ばす
for i in range(10):
    snapshot = df.sample(5)   # 1 秒ごとに 5 行を無作為に選び直す（seed なしなので毎回変わる）
    ph.dataframe(snapshot)
    time.sleep(1)

▶ 実行 を押せばこのページの中でそのまま動きます（ライブラリもデータも同梱済みで、 準備は要りません）。 手元の Python に移して動かすときは pip install matplotlib numpy pandas が必要です。 読んでいるデータは data/raw/SSDSE-B-2026.csv。 日本語を含むので encoding='cp932' の指定を落とさないでください。

🐍 Python 実装 — リアルタイム可視化

公的統計（SSDSE-B-2026）を題材に、 最小限の Python コードで リアルタイム可視化 を動作させます。 まずはこのまま実行してみてください。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# リアルタイム可視化 を SSDSE-B-2026 で実行する最小コード
import pandas as pd
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df[df['SSDSE-B-2026'] == 2023]  # 2023 年のみ抽出
print(df.shape)  # (47, 112)
print(df[['Prefecture','A1101','A1303','L3221']].head())

# Plotly Dash 風の最小コード（教育用）
import pandas as pd
import matplotlib.pyplot as plt
from matplotlib.animation import FuncAnimation
fig, ax = plt.subplots(figsize=(10,5))
def update(frame):
    ax.clear()
    subset = df.head(frame+1)
    ax.bar(subset['Prefecture'], subset['A1101'])
    ax.set_xticklabels(subset['Prefecture'], rotation=90)
# anim = FuncAnimation(fig, update, frames=len(df), interval=200)
print('FuncAnimation で 200ms ごとに 47 県を順次描画する設計')

💬 前半では 2023 年の 47 行 × 112 列を読み込めていることを、北海道から秋田県までの 5 行で確かめている。FuncAnimation の行はコメントアウトされているので、実際に出力されたのは最後の説明文だけで、アニメーションは描かれていない。47 フレームを 200 ms 間隔で回すと 1 周 9.4 秒になり、動かすにはこの行を有効にして Jupyter なら HTML(anim.to_jshtml()) で表示する。

上のコードで動かない場合は、 ①必要なパッケージがインストール済みか（pip install pandas scikit-learn scipy statsmodels matplotlib）、 ②データファイルが data/raw/SSDSE-B-2026.csv に存在するか、 ③encoding='cp932' になっているかを確認してください。

🐍 EMA + sliding window でノイズを潰す

🎯 このコードでやること: 北海道の消費支出（L3221、 二人以上の世帯・月平均）を 2012〜2023 年度の時系列として描き、 生データ・3 年移動平均 (SMA)・EMA (α=0.4) を重ねて比較する（完全失業率は SSDSE-B-2026 に収録されていないため消費支出で代える）。

📥 入力: SSDSE-B-2026 の L3221 列（消費支出、 円）の北海道 12 年度分

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import pandas as pd, numpy as np
import matplotlib.pyplot as plt

# 英字の項目コードを使うので skiprows=[1] で読む。
# なお E0301（完全失業率）は SSDSE-B-2026 には収録されていないため、
# 実在する L3221（消費支出）を平滑の題材にする。
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.dropna(subset=['L3221']).sort_values(['Prefecture','SSDSE-B-2026'])
pref = '北海道'
sub = df[df['Prefecture']==pref].copy()

# 単純移動平均 (window=3)
sub['SMA3'] = sub['L3221'].rolling(3, min_periods=1).mean()
# EMA (alpha=0.4)
alpha = 0.4
ema = []
prev = sub['L3221'].iloc[0]
for v in sub['L3221']:
    prev = alpha*v + (1-alpha)*prev
    ema.append(prev)
sub['EMA'] = ema

plt.figure(figsize=(10,4))
plt.plot(sub['SSDSE-B-2026'], sub['L3221'], 'o-', label='raw', alpha=0.5)
plt.plot(sub['SSDSE-B-2026'], sub['SMA3'], 's-', label='SMA(W=3)')
plt.plot(sub['SSDSE-B-2026'], sub['EMA'], '^-', label='EMA(α=0.4)')
plt.legend(); plt.title(f'{pref}: 消費支出の平滑')
plt.xlabel('SSDSE-B-2026'); plt.ylabel('消費支出 (円)')
plt.tight_layout(); plt.savefig('rtv_ema.png')
print(sub[['SSDSE-B-2026','L3221','SMA3','EMA']].to_string(index=False))

📤 実行例:

💬 2021 年度に生データが 301,683 円から 268,396 円へ 3.3 万円落ち込むと、EMA は 293,176 → 283,264 円と約 1 万円だけ下がり、SMA3 は 288,254 円にとどまる。2023 年度の反発（296,888 円）でも EMA は 287,387 円まで戻すのに、SMA3 は 2021 年度の落ち込みを窓に含むため 281,007 円と低いまま。EMA は新値への追随が早く (α=0.4 で半減期≈1.4 年)、 SMA は窓の長さだけ遅れる。 リアルタイム可視化では「最新値を即座に反映したい × でも変動を抑えたい」のトレードオフで α を選ぶ。

🐍 Plotly Dash で Web ダッシュボード

🎯 このコードでやること: Dash の dcc.Interval で 1 秒ごとに再描画する Web ダッシュボードの最小例。 SSDSE データを擬似ストリームとして年度ごとに描画。

📥 入力: SSDSE-B-2026 (前処理済 df)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

import pandas as pd
from dash import Dash, dcc, html, Output, Input
import plotly.graph_objects as go

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.dropna(subset=['A1101'])
years = sorted(df['SSDSE-B-2026'].unique())

app = Dash(__name__)
app.layout = html.Div([
    html.H2('SSDSE 人口 リアルタイム可視化 (擬似)'),
    dcc.Graph(id='line'),
    dcc.Interval(id='tick', interval=1000, n_intervals=0),
])

@app.callback(Output('line','figure'), Input('tick','n_intervals'))
def update(n):
    idx = n % len(years)
    cur = years[idx]
    sub = df[df['SSDSE-B-2026']<=cur]
    fig = go.Figure()
    for p in df['Prefecture'].unique()[:5]:
        s = sub[sub['Prefecture']==p]
        fig.add_trace(go.Scatter(x=s['SSDSE-B-2026'], y=s['A1101'], name=p, mode='lines+markers'))
    fig.update_layout(title=f'年度 {cur}', xaxis_title='SSDSE-B-2026', yaxis_title='人口')
    return fig

if __name__ == '__main__':
    app.run(debug=True, port=8050)

📤 実行例（イメージ・未実測。dash 未導入のため、ブラウザで http://localhost:8050 を開いたときの想定）:

💬 dcc.Interval で 1 秒ごとに callback が走り、 グラフが再描画される。 本物のストリームに繋ぐ場合は n_intervals を起点に Kafka/Redis から最新値を取りに行く。 SSDSE のような static データの「擬似ストリーム」として動作確認できる。

🐍 Reservoir Sampling — メモリ膨張を防ぐ

🎯 このコードでやること: 全 SSDSE データを「無限ストリーム」と見立て、 reservoir sampling でサイズ 100 のサンプルだけを保持しながら統計を計算。

📥 入力: SSDSE-B-2026 を 1 行ずつストリームで読む想定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import pandas as pd
import random

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.dropna(subset=['A1101']).reset_index(drop=True)

K = 100  # reservoir size
random.seed(0)
reservoir = []
for t, row in df.iterrows():
    if t < K:
        reservoir.append(row['A1101'])
    else:
        j = random.randint(0, t)
        if j < K:
            reservoir[j] = row['A1101']

import numpy as np
print(f'全体 N = {len(df)}')
print(f'reservoir size = {len(reservoir)}')
print(f'全体 平均 = {df["A1101"].mean():.2f}')
print(f'reservoir 平均 = {np.mean(reservoir):.2f}')
print(f'全体 中央値 = {df["A1101"].median():.2f}')
print(f'reservoir 中央値 = {np.median(reservoir):.2f}')

📤 実行例:

💬 保持しているのは 100 値だけだが、 中央値は 1,619,000 人と全体の 1,620,000 人にほぼ一致する。 一方で平均は 2,499,171 人と全体の 2,690,688 人より約 7% 低く、 東京都（約 1,400 万人）のような少数の大きな値が 100 件に何回入ったかで平均は大きく動く。 seed=0 で固定しているので値は毎回同じだが、 seed を変えると平均の方が揺れやすい。 ストリームが何百万・何億行になっても、 reservoir は K 件しか持たない → スケーラブル。 ヒストグラム描画用のサンプル維持に有効。

🐍 Streamlit による超簡単リアルタイム可視化

🎯 このコードでやること: Streamlit の st.empty() プレースホルダで毎秒書き換える方式。 Dash より少ないコード行数で「動くチャート」を実現。

📥 入力: SSDSE-B-2026 (前処理済 df)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

import pandas as pd
import streamlit as st
import time
import matplotlib.pyplot as plt

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
df = df.dropna(subset=['A1101']).sort_values(['Prefecture','SSDSE-B-2026'])
years = sorted(df['SSDSE-B-2026'].unique())
prefs = df['Prefecture'].unique()[:5]

st.title('SSDSE リアルタイム人口推移')
chart_slot = st.empty()
table_slot = st.empty()

for cur in years:
    sub = df[df['SSDSE-B-2026']<=cur]
    fig, ax = plt.subplots(figsize=(10, 4))
    for p in prefs:
        s = sub[sub['Prefecture']==p]
        ax.plot(s['SSDSE-B-2026'], s['A1101'], label=p)
    ax.legend(); ax.set_title(f'年度: {cur}')
    chart_slot.pyplot(fig)
    table_slot.dataframe(sub[sub['SSDSE-B-2026']==cur][['Prefecture','A1101']].head(5))
    time.sleep(0.5)
    plt.close(fig)

st.success('再生完了')

📤 実行例 (ターミナルで streamlit run app.py):

💬 Streamlit は「Python スクリプトを上から下に流す」モデル。 リアクティブ性は弱いが、 教育用途・社内ツールでは圧倒的に作りやすい。 Dash はコンポーネント駆動でスケールしやすく、 Streamlit はプロトタイプに最適 — 使い分け。

🐍 Bokeh で本格的なストリーミング描画

🎯 このコードでやること: Bokeh server の ColumnDataSource.stream で差分追加のみ送信、 全データ再送せずに滑らかなストリーミング描画を実現。

📥 入力: SSDSE-B-2026 (前処理済 df, 北海道だけ抽出)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import pandas as pd
from bokeh.io import curdoc
from bokeh.models import ColumnDataSource
from bokeh.plotting import figure

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
sub = df[df['Prefecture']=='北海道'].dropna(subset=['A1101']).sort_values('SSDSE-B-2026').reset_index(drop=True)

source = ColumnDataSource(dict(x=[], y=[]))
p = figure(title='北海道 人口推移 (streaming)', x_axis_label='SSDSE-B-2026', y_axis_label='人口')
p.line('x', 'y', source=source, line_width=3)
p.circle('x', 'y', source=source, size=8, color='red')

idx = [0]
def update():
    if idx[0] >= len(sub):
        return
    row = sub.iloc[idx[0]]
    source.stream(dict(x=[row['SSDSE-B-2026']], y=[row['A1101']]), rollover=20)
    idx[0] += 1

curdoc().add_root(p)
curdoc().add_periodic_callback(update, 500)  # 500ms ごと

📤 実行例 (bokeh serve --show app.py):

💬 Bokeh の stream は「差分のみ追加」方式で、 全データ再送がない → ネットワークと CPU が軽い。 rollover で sliding window もコード 1 つで実現できる。 本番ストリーミング可視化の事実上の標準。

🔬 数式を言葉で読み解く — stream の効率性

$$ \text{転送量}_{\text{stream}} = O(\text{差分点数}) \quad \text{vs} \quad \text{転送量}_{\text{full redraw}} = O(\text{全点数}) $$

• 差分転送: 1 点追加なら 1 点だけ送る → 描画 1 万点でも常に O(1)
• 全再描画: 1 万点になったら 1 万点を毎フレーム送る → 帯域圧迫、 ブラウザ重い
• rollover: 上限点数を設定、 古い点を自動削除 → 一定メモリで無限ストリーム対応

🐍 Python で「リアルタイムフレーム」を実データから生成する

このコードでやること：SSDSE-B-2026 の都道府県データを使い、リアルタイム可視化の「1 フレーム」に相当する散布図・ヒストグラム・箱ひげ図を、実データから生成する手順を確認する。ストリーミング処理の前段として、各フレームがどう作られるかを再現する。

📥 入力データ（SSDSE-B-2026 抜粋・最新年スナップショット）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

import pandas as pd
import matplotlib.pyplot as plt

# SSDSE-B-2026 を読み込み（最新年度 2023 のスナップショット）
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
latest = df[df['SSDSE-B-2026'] == df['SSDSE-B-2026'].max()]
print(f'スナップショット: {latest["SSDSE-B-2026"].iloc[0]} 年度, {len(latest)} 都道府県')

# フレーム 1: 散布図（総人口 × 65歳以上人口）
fig, ax = plt.subplots(figsize=(6,4))
ax.scatter(latest['A1101'], latest['A1303'])
ax.set_xlabel('総人口（人）'); ax.set_ylabel('65歳以上人口（人）')
ax.set_title('リアルタイムフレーム例: 散布図')
plt.savefig('rtv_frame_scatter.png', dpi=110, bbox_inches='tight')
print('rtv_frame_scatter.png 生成完了（散布図フレーム）')

# フレーム 2: ヒストグラム（人口分布）
fig, ax = plt.subplots(figsize=(6,4))
ax.hist(latest['A1101'], bins=15)
ax.set_xlabel('総人口（人）'); ax.set_ylabel('都道府県数')
ax.set_title('リアルタイムフレーム例: ヒストグラム')
plt.savefig('rtv_frame_hist.png', dpi=110, bbox_inches='tight')
print('rtv_frame_hist.png 生成完了（ヒストグラムフレーム）')

# フレーム 3: 箱ひげ図（地方ブロック別）
groups = {'北海道':['北海道'], '東北':['青森県','岩手県','宮城県','秋田県','山形県','福島県'],
          '関東':['茨城県','栃木県','群馬県','埼玉県','千葉県','東京都','神奈川県']}
data = [latest[latest['Prefecture'].isin(v)]['A1101'].values for v in groups.values()]
fig, ax = plt.subplots(figsize=(6,4))
ax.boxplot(data, tick_labels=list(groups.keys()))
ax.set_ylabel('総人口（人）')
ax.set_title('リアルタイムフレーム例: 箱ひげ図')
plt.savefig('rtv_frame_box.png', dpi=110, bbox_inches='tight')
print('rtv_frame_box.png 生成完了（箱ひげ図フレーム）')
for k, v in zip(groups, data):
    print(f'  {k}: {len(v)} 都道府県, 中央値 {pd.Series(v).median():,.0f} 人')

📤 実行すると次の出力が得られる：

💬 最新年度 2023 の 47 都道府県だけを 1 フレームとして切り出し、 散布図・ヒストグラム・箱ひげ図の 3 枚を作業フォルダに書き出した（上方の「視覚補助 1〜3」と同じ種類の図）。 箱ひげ図の北海道ブロックは 1 道だけなので箱にならず、 東北 6 県の中央値 117 万人に対して関東 7 都県は 626 万人と 5 倍以上の開きがある。本番ダッシュボードでは このコードを 30 秒間隔で実行し、画像を差し替えることでリアルタイム可視化が成立する。Plotly/Bokeh/Streamlit などの WebSocket 対応ライブラリを使えば、画像差し替えではなくブラウザ側で部分更新できるため、よりスムーズな更新体験が得られる。

🎮 触って理解する — 架空センサーストリームのミニ監視ダッシュボード

静的な図と違い、 リアルタイム可視化は「データが流れ込み、 やがて画面から流れ去る」ことが本質です。 下のミニダッシュボードは、 架空のセンサー値ストリーム（乱数によるシミュレーションで、 実在のデータではありません）を生成して流し続けます。 「▶ 開始」を押して、 更新間隔・ウィンドウ幅・平滑化・スパイク注入を切り替えながら、 リアルタイム監視の基本要素を一通り体感してください。 グラフ上をクリック（タッチ）またはドラッグするとアラート閾値（赤い破線）を上下に動かせます。

👀 観察ポイント — 4 つの実験

• (a) ウィンドウ幅と傾向把握：ウィンドウを 10 点まで狭めると「今」の変動は克明に見えるが、 上昇・下降のトレンドは判別不能になる。 200 点まで広げると傾向は見えるが、 直近の急変が相対的に小さく潰れる。 「詳細用の短い窓」と「傾向用の長い窓」を併用するのが実務の定石。
• (b) 更新頻度と可読性のトレードオフ：更新間隔を 100ms にすると線が激しく暴れて目で追えなくなる。 2000ms にすると落ち着いて読めるが、 スパイクへの気づきが最大 2 秒遅れる。 「人間の判断速度」に合わせた間隔選びを体感してほしい。
• (c) 平滑化の功罪：移動平均 ON でノイズが消えてトレンドが読みやすくなる一方、 スパイクを注入すると平滑線の山は低く・遅れて現れる。 平滑化は可読性を買う代わりに検知感度と即時性を売る取引である。
• (d) 閾値アラートの設計：閾値（赤破線）をドラッグして通常変動のすぐ上に置くと誤報が連発し（アラート疲労）、 高くしすぎるとスパイクを見逃す。 「⚡ スパイク注入」を何度か押して、 検知できる位置と誤報しない位置の狭い妥協点を探ってみよう。

🎨 直感の深化 — バッチ可視化と何が違うのか

バッチ（静的）可視化では、 手元に全データが揃ってから最適な軸・ビン・要約を選べる。 リアルタイム可視化では、 データは 1 点ずつ到着し、 ウィンドウの左端から流れ去って二度と画面に戻らない。 つまり「あとで見返す」ことを前提にできず、 (1) 描画時点で意味が完結する図、 (2) 保持しない過去を要約統計（移動平均・EMA・カウンタ）に畳み込む仕組み、 の 2 つが必須になる。 上のウィジェットで「閾値超過回数」カウンタだけが流れ去った過去を記憶している点に注目してほしい。 これが本文で述べた「O(1) メモリの逐次集計」の最小例である。 折れ線という図法そのものの読み方は 折れ線グラフ を、 時間方向の構造（トレンド・季節性）の扱いは 時系列データ を参照。

⚠️ 落とし穴の体感 — このウィジェットで再現できる 3 つの事故

• 更新過多で読めない：間隔 100ms ＋ ウィンドウ 200 点は、 本文の落とし穴「チラつき」「認知過負荷」の再現実験になる。 更新を速くしても意思決定は速くならない。
• ウィンドウ幅の選択ミス：短すぎる窓は「ノイズを異常と誤認」、 長すぎる窓は「構造変化への気づきの遅れ」を生む。 窓幅は表示の都合ではなく業務の判断周期から逆算する。
• スパイク見逃し：平滑化 ON のままスパイクを注入すると、 生データでは明白な異常が平滑線ではほぼ消えることがある。 実務では「表示は平滑線、 アラート判定は生値」と役割を分けるのが安全。 外れ値の統計的な扱いは 外れ値 を参照。

🚀 発展 — 本物のストリームにつなぐには

このウィジェットは「乱数生成 → 配列 push → canvas 再描画」をブラウザ内で完結させた玩具だが、 本番構成でも各部品は 1 対 1 に対応する。 乱数生成器は センサデータ や 行動ログ などのデータソースに、 配列バッファは Kafka などのメッセージ基盤と時系列 DB に、 setInterval は WebSocket/SSE のプッシュ配信に置き換わる（ストリーム処理基盤の個別ページは未整備のため、 本ページ「🗺 アーキテクチャ全体図」の表を参照）。 ダッシュボード全体の画面設計・KPI 階層化は BI ツール、 閾値の統計的な決め方（3σ・分位点・曜日別ベースライン）とアラート運用は モデルモニタリング が隣接領域。 操作 UI（ブラシ・ズーム・ツールチップ）で過去を掘る方向の拡張は インタラクティブ可視化、 「動いていても誤解させない」誠実な見せ方の原則は データ可視化 で扱っている。

⚠️ よくある落とし穴

この用語を使うときに初学者が踏みやすい失敗パターン。 1 度経験してしまえば次から避けられますが、 先に知っておくに越したことはありません。

⚠️ よくある落とし穴 — リアルタイム可視化

リアルタイム可視化 を使うときに初学者が踏みやすい失敗パターン。 1 度経験してしまえば次から避けられますが、 先に知っておくに越したことはありません。

⚠️ リアルタイム可視化の落とし穴 7 つ

1. レイテンシ過信: 「リアルタイム」と謳っても WebSocket 経由で 200-500ms 遅延する。 SLA を明示しよう。
2. メモリリーク: 全データを描画リストに append し続けると OOM。 sliding window or reservoir で必ず上限を。
3. チラツキ (flicker): 毎フレーム完全再描画すると目が疲れる。 差分更新 (Plotly extendTraces) を使う。
4. 古いデータの誤解: 「1 時間前の値」と「最新値」を同じ太さで描くと、 古い情報を最新と誤認させる。 透明度で減衰を。
5. UI の認知過負荷: 動くチャートが画面に 10 個あると注意散漫。 重要 KPI 上位 3 つに絞り、 他は静的サマリへ。
6. 同時接続スケーリング: Dash 単体は同期処理。 1000 ユーザ同時接続なら Redis pub/sub + Gunicorn ワーカで前段を分ける。
7. 欠損データの可視化: ストリームが途切れたとき「線が直線で延長」されるとミスリーディング。 null は線を切る (mode='lines+markers' で対応)。

⚠️ リアルタイム可視化フレームの 12 大落とし穴

リアルタイム可視化は「動くから良い」のではなく、「正しく動くから良い」。次の 12 個の落とし穴は実務で頻発する代表例である。

1. 軸スケール自動化の罠：毎フレーム軸範囲が変わると、データが変化していなくても点群が動いて見え、利用者は錯覚する。原則固定。
2. 過更新による認知過負荷：1 秒ごとに更新しても人間は読めない。30 秒〜1 分が体感的に適切。
3. 更新タイミング不一致：複数図がバラバラに更新されると「いつのデータを比較しているか」が分からなくなる。同期必須。
4. 外れ値による全体歪み：1 個のスパイクで全体の軸が伸び、他の構造が潰れる。外れ値は別レイヤで明示。
5. 過去履歴喪失：リアルタイム性に集中するあまり過去フレームが残らず、事後分析ができない。録画必須。
6. 遅延データの混入：ストリームに 30 秒遅れのレコードが混じると「現在」がぶれる。タイムスタンプベースで処理時刻を管理。
7. サンプル数不足の箱ひげ：群あたり 5 件未満の状態で箱を描くと、四分位が安定せず誤判断を招く。最低 30 件確保。
8. 固定ビンの不整合：データの値域が突然変わったときに固定ビンの外に値が落ち、見えないバグになる。最大値モニタが必要。
9. 配色の不統一：図ごとに同じセグメントに違う色が割り当てられ、認知負荷が爆増する。グローバルパレットで統制。
10. アラート未連動：図が異常を示しても誰にも通知が飛ばず、見落とされる。閾値とアラートをセットで設計。
11. UI フリーズ：データ量が増えるとブラウザ側でレンダリングが詰まる。サンプリングや LTTB 等の間引きが必要。
12. セキュリティ無視：センシティブなリアルタイム指標が誰でも見られる状態になっている。アクセス管理は必須。

⚠️ 窓幅を広げると「減少」が画面に出ない — 2021 年度の人口で確かめる

🎯 このコードでやること：47 都道府県の総人口を年度の昇順に並べ、 生値（W = 1）と W 年移動平均の前年差が正になる県の数を 2020・2021 年度で数える。 窓幅によって「増加」と表示される県がどれだけ変わるかを見る。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
pop = (df.pivot(index='SSDSE-B-2026', columns='Prefecture', values='A1101')
         .sort_index())                          # 行 = 年度（昇順）, 列 = 47 都道府県

raw = pop.diff()                                 # 生値の前年差
for W in [1, 2, 3, 5]:
    sm = pop.rolling(W).mean().diff()            # W 年移動平均の前年差
    n_up_2020 = int((sm.loc[2020] > 0).sum())
    n_up_2021 = int((sm.loc[2021] > 0).sum())
    print(f'W={W}: 前年より「増加」と表示される県数  2020 年度 {n_up_2020:2d}  2021 年度 {n_up_2021:2d}')

print('東京都 生値の前年差 2021 =', f"{raw.loc[2021, '東京都']:+,.0f}")
for W in [2, 3, 5]:
    print(f'東京都 W={W} 平均の前年差 2021 =', f"{pop.rolling(W).mean().diff().loc[2021, '東京都']:+,.0f}")
print('2021 年度に生値で増えた県:', list(raw.columns[raw.loc[2021] > 0]))
print('W=5 で 2021 年度も「増加」:', list(raw.columns[pop.rolling(5).mean().diff().loc[2021] > 0]))

💬 生値で 2021 年度に前年より増えたのは沖縄県だけ（1 県）なのに、 W = 3 の窓平均では 5 県、 W = 5 では東京都・神奈川県・愛知県など 7 県が「増加」と表示される。 東京都は生値で −37,594 人でも、 W = 3 の窓平均の前年差は +41,000 人、 W = 5 では +72,800 人になる。 窓平均の画面だけを見ていると、 人口が減り始めた年を「増加」と読み違える。 平滑値と並べて生値の差分も表示するのが安全である。

📝 まとめ：3 枚のスナップショットが「リアルタイム」を構成する

リアルタイム可視化は「動く魔法の図」ではない。実体は 静止画フレームの連続である。だから、まず静止画 1 枚を完璧に作れることが前提となり、その上に「同期」「履歴」「アラート」「アクセス管理」などの運用要件が積み重なる。本ページでは散布図・ヒストグラム・箱ひげ図という 3 枚の代表静止画を題材に、それぞれが何を映し、リアルタイム文脈でなぜ重要かを掘り下げてきた。

• 散布図は 2 変量の相関構造を瞬時に伝える。軸固定・透明度・外れ値処理の設計が肝。
• ヒストグラムは 1 変量の分布形を伝える。ビン幅固定、二峰性検知が現場の主目的。
• 箱ひげ図は 群間比較を伝える。窓幅選択とサンプル数確保が品質を決める。
• 3 枚をセットで並べれば「相関・分布・群差」を網羅し、運用担当者が視線を動かすだけで異常検知できる。

この 3 枚構成を SSDSE-B-2026 のような実データで一度通しで作っておけば、後で本番ストリーミング環境（Kafka・Kinesis・WebSocket 等）に移植する際の設計品質が大きく向上する。リアルタイム可視化を学ぶ最短ルートは、まず静止画を上達させること、これが本ページの中核メッセージである。

🌐 関連手法・派生

この用語の周辺にある、 セットで覚えておきたい関連手法を整理しました。 状況によって使い分けが必要なので、 「強みと弱み」を 1 行で言えるようにしておくと、 場面に応じた選択が可能になります。

🌐 主要ライブラリ比較表

用途・スケール・学習コストに応じた選択指針。

🔗 関連用語（前提・並列・発展）

リアルタイム可視化 と直接つながる前後関係。 「前提」=先に知っておくと理解が早い／「並列」=同じ問題に別の角度／「発展」=応用・拡張版。 学習計画の参考にどうぞ。

• 🔗 散布図
• 🔗 ヒストグラム
• 🔗 ヒートマップ
• 🔗 ダッシュボード (BI ツール)
• 🔗 API
• 🔗 ストリーミング (行動ログ収集)
• 🔗 1 変量可視化
• 🔗 2 変量可視化

📚 関連グループ教材

リアルタイム可視化は「可視化」と「データ基盤」の 2 つの教材群にまたがる。 可視化の側では、 1 枚のフレームを正しく作るための 折れ線グラフ・ヒストグラム・箱ひげ図 と、 操作で過去を掘る インタラクティブ可視化、 画面設計の BI ツール が土台になる。 データ基盤の側では、 流れてくるデータ源の センサデータ・行動ログ と、 閾値とアラートを扱う モデルモニタリング が続きの教材にあたる。 このページの「窓平均が減少を隠す」「見続けると誤報が増える」の背景は、 時系列データ と 多重検定 の教材で詳しく扱っている。

📚 関連用語と歴史

歴史: NORAD (1958), Bloomberg ターミナル (1981), Yahoo! Finance リアルタイムチャート (1996), D3.js (2011), Grafana (2014), Plotly Dash (2017)、 Apache Echarts (2018) など、 「ストリーミング × 可視化」は金融・運用監視を出発点に IoT・スポーツ・SNS へ広がった。

🔗 さらに重要な関連用語

• 前提: 折れ線グラフ / 棒グラフ / ヒストグラム
• 並列: インタラクティブ可視化 / ダッシュボード / BI ツール
• 発展: ストリーミング処理 / IoT / 異常検知

🖼 視覚補助 1：リアルタイム可視化を「静止画」に分解して見る — 散布図・ヒストグラム・箱ひげ

リアルタイム可視化は「時間とともに更新される図」だが、その本質は各時刻における静止画（スナップショット）の連続である。したがって、リアルタイム可視化を理解するには、まず「ある瞬間の図がどう作られるか」を徹底的に理解する必要がある。ここでは SSDSE-B-2026 の都道府県データを使い、3 種類の代表的な静止図（散布図・ヒストグラム・箱ひげ図）を題材に、リアルタイム可視化のフレームがどのような「絵」の連続で構成されるのかを丁寧に解きほぐす。これらの図がそれぞれリアルタイムストリームのどの段階で価値を発揮するか、現場の意思決定とどう結びつくかも併せて確認していこう。

1-1. 散布図フレーム：相関の瞬間値を見る

下図は、ある時刻 t における総人口と 65 歳以上人口の散布図である。リアルタイムダッシュボードが「30 秒に 1 回」更新される場合、ユーザーはこの種の静止画を 30 秒に 1 枚ずつ受け取ることになる。重要なのは、1 枚 1 枚の図が単独で意味を持つようにデザインされていることだ。軸ラベル・単位・凡例・タイトルが揃っていなければ、たとえ秒単位で更新されても利用者は読み取れない。

この散布図は SSDSE-B-2026 の 2023 年度（最新フレーム、青）の 47 県を描き、2012 年度の位置（前フレーム、薄い灰）を線で結んで残したものである。軸範囲は両フレームで固定しているので、点がそろって上へ動いた（65 歳以上人口は 47 県すべてで増え、合計 3,079 万人 → 3,623 万人）ことがそのまま読める。相関は r = 0.996 → 0.991 とほとんど変わらない。1 枚の静止画だが、リアルタイム可視化の現場ではこれが「毎フレーム再生成される」と考えると本質が見える。たとえば EC サイトのリアルタイムダッシュボードでは、横軸を「ユーザー滞在時間」、縦軸を「セッション内購入額」とした散布図を 1 分ごとに再描画する。各点が直近 1 分間のセッションを表し、点群の傾きが急になれば「滞在時間と購入額の相関が強まった＝今のキャンペーンは効いている」と読める。逆に点が散らばっていく方向に動けば「相関が崩れている＝顧客行動が分散している」と判断できる。リアルタイム性が活きるのは、この相関構造の変化を意思決定者がその場で観察できるからだ。

1-2. 散布図フレームの設計指針

リアルタイム散布図を設計するときには、次の 5 つの観点を必ず点検する。

特に「軸範囲」の設計はリアルタイム可視化で最大のハマりどころである。auto-scale にすると、外れ値が 1 つ入っただけで全体のスケールが伸び縮みし、利用者の目には「全体が動いた」ように映るが、実際は 1 点だけが特異値で他は変化していない、という錯覚が頻発する。だから多くの本番ダッシュボードは「軸範囲は固定」「外れ値は別レイヤで明示」「全体構造は変えない」の三原則を守っている。

🖼 視覚補助 2：分布の瞬間スナップショット — ヒストグラムで「今の形」を捉える

リアルタイム可視化のもう一つの主役は「分布の形」を見せる図である。散布図が 2 変量関係を見るのに対して、ヒストグラムは 1 変量がどんな値域にどれだけ集中しているかを時系列で追う。たとえば SaaS のレスポンスタイム、IoT センサーの温度、コールセンターの通話時間など、ストリーミングで生まれ続けるデータは「平均」だけでは正体が掴めず、分布の形そのものを見なければ判断できないことが多い。

上のヒストグラムは SSDSE-B-2026 の 2023 年度における 47 都道府県の総人口の分布（塗り）に、2012 年度の分布を同じ固定ビン（50 万人刻み）の輪郭線で重ねたものである。横軸が総人口、縦軸が度数（都道府県数）。中央値 155 万人に対して平均は 265 万人、歪度 2.22 と明らかに右に長い裾を持つ分布で、これは「東京・大阪・神奈川のような大都市が極端に大きく、他は小さい」というロングテール構造を示している。リアルタイム可視化でこの種の図を見せ続ければ、「今この瞬間、利用者の RT は二峰性に分裂し始めた」「センサー温度の分布が右にシフトしている」といった、平均値では掴めない分布の変化を即座に検知できる。

2-1. ビン幅の選択がリアルタイム性を決める

ヒストグラムをリアルタイムで使う際の最大の論点は「ビン幅」だ。ビン幅が広すぎれば変化を見落とし、狭すぎればノイズで形が安定しない。実務でよく使われる規則は次の 3 つ。

• Sturges の公式：k = ⌈log₂(n) + 1⌉。データ数 n が一定なら一意に決まり、リアルタイム表示で「形が落ち着く」効果がある。
• Freedman-Diaconis：h = 2·IQR/n^1/3。外れ値に強く、SaaS のレスポンスタイムなど分布が歪むストリームに向く。
• 固定ビン：可視化対象の物理的意味（例: 0〜100ms を 10ms 刻み）に合わせて固定。リアルタイム可視化では これが最も安定。

リアルタイム可視化では「フレームごとに最適ビン幅を再計算する」のは原則 NG だ。なぜなら、ビン幅が変われば 1 ビンあたりの度数が変わり、見た目の山が一気に動いてしまう。利用者は「データが変わった」のか「ビン幅が変わっただけ」なのか区別できない。だから本番ダッシュボードでは ビン幅は事前に固定し、データの方を流す のが鉄則である。

2-2. 二峰性の検知という現場ニーズ

ヒストグラムを使う最大の動機は「二峰性（バイモーダル）の検知」だ。たとえばオンラインサービスのレスポンスタイム分布が突然、低速グループと高速グループの 2 山に分かれたら、それは「裏でキャッシュミスが頻発している」「特定リージョンだけ遅い」など、平均値では絶対に見えない問題のサインである。リアルタイム可視化でヒストグラムを見続けることは、分布の構造変化を察知する早期警戒装置 として機能する。

🖼 視覚補助 3：群間比較のスナップショット — 箱ひげ図でセグメントを並べる

リアルタイム可視化で 3 番目に重要なのが「群間比較」である。1 つのストリームの平均や分布を追うだけでは「全体としてどう動いたか」しか見えない。実務では「リージョンごと」「顧客セグメントごと」「サーバーごと」に分けて、複数群を並べて見たい状況が圧倒的に多い。そのときの代表選手が箱ひげ図である。

上図は SSDSE-B-2026 の 2023 年度の総人口を 7 地方別に並べた箱ひげ図である（点は各県）。関東は中央値 626 万人・四分位範囲 592 万人と箱が大きく上に伸び、東京・神奈川などの大都市の影響で群全体が高い水準にある。一方、四国（中央値 81 万人・四分位範囲 33 万人）や九州・沖縄（137 万人・51 万人）は箱が小さく、群内のばらつきも限定的だ。ただし北海道（北海道・東北）や福岡県（九州・沖縄）のように、小さな箱から 1 県だけ飛び出す群もある。リアルタイム可視化でこの図を「群ごとに毎分更新」すれば、特定の群だけが突然外れ値を出した、特定の群だけ箱が広がった、といった群レベルの異常を一目で検知できる。

3-1. 箱ひげ図がリアルタイム可視化で強い理由

なぜ箱ひげ図がリアルタイム可視化で愛されるかというと、1 枚の絵に「中央値・ばらつき・外れ値」の 3 情報が同時に詰まるからである。これらは別々に折れ線で出すこともできるが、群が 10〜30 あるダッシュボードでは折れ線が密集して読めない。箱ひげ図なら横並びに 30 群並べても、各群の状態が瞬時に比較できる。

また、箱ひげ図は外れ値の検知にも強い。リアルタイム可視化で平均値だけ追っていると外れ値の影響を平準化してしまうが、箱ひげ図ならヒゲの外に飛ぶ点として明確に表現される。これは IoT・センサー監視・サーバー監視のリアルタイム運用で特に重要で、たとえば「ある工場の温度センサーだけ箱から飛び出した」と気づければ、その瞬間に保全チームを派遣できる。

3-2. ストリームでの群定義の難しさ

ストリーミング環境で箱ひげ図を実装する際の難点は「群の定義」と「窓幅」だ。リアルタイムでは「直近 1 分間のレスポンスタイムを群ごとに比較」のようにスライディングウィンドウで集計する必要がある。窓幅が短いと群内サンプル数が足りず箱が安定しない。窓幅が長いと「今」の異常検知が遅れる。実務では「リアルタイム監視用は 1 分窓、トレンド分析用は 1 時間窓」のように複数窓を併用するのが定石である。

🔁 3 つの図を「リアルタイムフレーム連鎖」として組み合わせる

ここまでで散布図・ヒストグラム・箱ひげ図の 3 種を見てきたが、本番のリアルタイム可視化システムでは これらが同一画面に並んで毎フレーム更新される ことが多い。なぜなら、3 つは相互補完の関係にあるからだ。散布図は「2 変量関係」、ヒストグラムは「1 変量の分布」、箱ひげ図は「群間比較」を担当する。1 つだけでは盲点が出るが、3 つ揃えば「相関構造・分布形・群差」がほぼ網羅される。

4-1. 典型的なダッシュボード構成例

本番リアルタイム可視化の典型的な「3 枚構成」は次のようになる。

• 左：散布図 — 直近 1 分間のユーザー滞在時間 × 購入額。点の色で来訪チャネルを区別。
• 中央：ヒストグラム — 直近 1 分間のレスポンスタイム分布。固定ビン 10ms 刻み。
• 右：箱ひげ図 — リージョン別 P50/P90/P99 を箱ひげで並列表示。

これを 30 秒ごとに更新すれば、「滞在時間と購入額の相関」「ユーザー体験の分布の歪み」「リージョン間の性能差」が同時に視認できる。1 つの図だけだと「気づきが偏る」が、3 種類が並んでいれば、運用担当者は 自分の関心領域に合わせて視線を動かすだけで異常検知ができる。

4-2. 3 枚構成のためのチェックリスト

3 枚構成を運用品質に持っていくためのチェックリストを以下にまとめる。リアルタイム可視化を導入する際には、必ず全項目を点検したい。

🗺 概念マップ — リアルタイム可視化のアーキテクチャ全体図

本番システムでは、 ライブラリ単体ではなくスタック全体を意識した設計が必要。

🔬 数式を言葉で読み解く — 処理パイプラインのレイテンシ加算

$$ L_{\text{total}} = L_{\text{source}} + L_{\text{transport}} + L_{\text{process}} + L_{\text{render}} $$

• 各 L: 各層で生じる遅延 (ms)
• 合計: ユーザが感じる総レイテンシ。 100ms 以下を狙うなら各層 25ms 以下に割り振る
• ボトルネック: 通常 transport (Kafka 50ms+) と render (300ms+ for D3) が大きい
• 最適化: WebSocket 直結、 server-side rendering、 differential update が定石

🔗 隣接手法への橋渡し

「リアルタイム可視化」は単独で完結する手法ではなく、 隣接領域と連携することで真価を発揮する。

• 上流: ストリーミングデータ・センサデータ・WebSocket / APIでデータが連続入力される
• 並列: ダッシュボード・BI ツールと比較し、 更新頻度が秒単位ならリアルタイム
• 下流: アラート・異常検知と連動して即時アクションへ

SSDSE 系の静的な公的統計だけでなく、 流れてくる時系列を Plotly Dash や Streamlit で即時描画 → 閾値判定 → アラートまで一気通貫させると価値が出る。

🌳 手法選択フロー

「リアルタイム可視化」を実際の課題に当てはめるとき、 状況別に何を選ぶかを 3 段階で判定する。

1. 更新頻度は? 秒単位 → リアルタイム (WebSocket/SSE)、 分・時単位 → ポーリング / 定期バッチ
2. 視認性 vs 詳細性? 視認 → 大きな KPI 数値 + 色、 詳細 → 表 + ドリルダウン
3. 履歴は必要か? Yes → 時系列グラフを横スクロール、 No → 現在値だけ表示

SSDSE-B-2026 は年次データなのでリアルタイムは不要。 リアルタイム化が意味を持つのは PoS 売上・気象センサ・SNS 投稿数など、 秒～分単位で意思決定したいデータ。

🔍 解説を深める — 「見続けること」の統計学

本ページはここまで、 レイテンシ・ウィンドウ集計・ライブラリ・運用設計を扱ってきた。 この追補では視点を変え、 「画面を監視し続ける」という行為そのものが持つ統計的性質を掘り下げる。 平滑化が真の変化を隠す現象と、 逐次監視が偽アラートを必ず生む現象は、 どちらも実装ではなく確率の問題であり、 どんなに高速な描画基盤を使っても消えない。

🎨 直感 — 平滑化は「誤報保険」と引き換えに検知を遅らせる

ページ上部の 🎮 ウィジェットで「移動平均 (W=5)」を ON にすると線が滑らかになるが、 スパイク注入への反応も鈍る。 これはデモ上の演出ではなく、 実データでも同じことが起きる。 SSDSE-B-2026 の東京都 A1101（総人口）2012–2023 年を「1 年 = 1 イベント」の擬似ストリームとして流し、 生値・W=3 スライディング平均・EMA（α=0.5、 W=3 相当）を並べてみる。

生値の前年差は 2021 年に観測期間 12 年で初めて負（−37,594 人）となり、 COVID 期の東京都の人口減少をその年のうちに示す。 ところが W=3 平均は 13,980,531 → 14,021,531 → 14,031,865 と、 EMA も 13,967,891 → 13,988,946 → 14,013,473 と一貫して増加し続け、 この転換を一度も「減少」として表示しない。 平滑化はノイズ由来の誤報を減らす保険だが、 保険料として「真の変化の検知遅れ（ときには完全な隠蔽）」を支払っている。 リアルタイムダッシュボードでは「生値の差分」と「平滑値」を両方表示するのが正解で、 どちらか一方に絞るのは情報の破棄である。

⚠️ 落とし穴（重要） — ずっと見ている画面は、 いつか必ず偽アラートを出す

閾値超過アラートは「1 回の判定」としては妥当でも、 リアルタイム可視化では同じ判定を何百回も繰り返す。 これは検定の多重性の問題と同型で、 1 回あたりの誤報率を $\alpha$、 判定回数を $N$ とすると、 少なくとも 1 回誤報する確率は次式で膨張する。

• $\alpha = 1\%$ で 60 回判定（5 秒更新 × 5 分）→ $1-0.99^{60} = 45.3\%$
• $\alpha = 1\%$ で 720 回判定（5 秒更新 × 1 時間）→ $1-0.99^{720} = 99.9\%$。 ほぼ確実に鳴る
• 3σ 基準（$\alpha = 0.27\%$）に厳しくしても、 720 回判定で $85.7\%$

つまり「データが完全に正常でも、 1 時間監視すれば 3σ アラートは高確率で 1 回は誤発火する」。 これが本文で触れたアラート疲労の数理的な正体である。 対策は閾値を下げることではなく判定の構造を変えること：（1）連続 k 回超過で初めて発報する持続性ルール（単発ノイズの誤報率は $\alpha^k$ に急減）、（2）超過量を累積する CUSUM や平滑値に管理限界を引く EWMA 管理図の発想を借りる、（3）「1 画面 = 1 時間に何回誤報してよいか」という時間あたり誤報予算から逆算して $\alpha$ を決める。 🎮 ウィジェットで閾値線をドラッグし、 正常運転のまま放置したときの「閾値超過回数」の増え方を見ると、 この式を体感できる。

🚀 発展 — Welford 法：O(1) メモリで「全履歴の分散」を持ち歩く

本文の EMA は「忘却しながら」平均を追う道具だった。 一方、 管理限界（μ ± 3σ）を引くには忘却しない平均と分散が要る。 全データを保持せずにこれを更新するのが Welford のオンラインアルゴリズムで、 1 件到着するたびに次の 3 行を実行するだけでよい。

実データで検証：東京都 A1101 の 12 年分（2012–2023）を 1 件ずつ Welford 更新で流すと、 平均 13,745,405.42 人・不偏標準偏差 314,571.94 人となり、 全データ一括計算（numpy）と完全に一致する。 素朴な「二乗和 − 平均の二乗」方式は桁の大きい値（千万人オーダー）で桁落ちを起こしやすいが、 Welford 法は数値的にも安定している。 EMA（忘却あり・トレンド追従）と Welford（忘却なし・ベースライン推定）を併走させ、 「Welford のベースライン ± 3σ を管理限界、 EMA を現在値」として比較するのが、 ストリーム異常検知の最小構成である。 さらに先へ進むなら、 分布自体が時間とともに変わるコンセプトドリフト下でのベースライン再学習が次のテーマになる。

🔗 関連ページ

• 多重検定 — 逐次監視の誤報膨張は多重比較問題そのもの。 補正の考え方の出発点
• 時系列データ — ストリームは「終わりの決まっていない時系列」。 自己相関・トレンドの基礎
• データドリフト — Welford で推定したベースラインが「ずれていく」現象への対処
• 外れ値 — 閾値設計・3σ 基準の前提と限界
• センサデータ — リアルタイム可視化の代表的な上流データ源
• BI ツール — 秒単位でない「準リアルタイム」ダッシュボードとの使い分け
• 管理図（CUSUM・EWMA チャート）— 品質管理由来の逐次検知手法（本用語集に単独ページなし。 発展学習は SQC の教科書を参照）