もくじ
- 第1章：また人流ツール？——現場が嫌がる「運用が増えるだけ」問題から始める
- 第2章：スマホ＝人（約）が崩れる瞬間：MACランダム化とOS省電力の壁
- 第3章：入口で勝負する：在館推定は「入数−出数」から逆算すると腹落ちする
- 第4章：Wi-Fi/BLEゲートの基本設計：外→内の時系列で“方向”を決める
- 第5章：指向性アンテナと 5GHz/2.4GHz の使い分け：検知範囲は“狭くする”ほど精度が上がる
- 第6章：安価カウンタ3兄弟（IR/ToF/mmWave）：何がどこまで正確で、どこで外れるか
- 第7章：コスト比較の現実：既設Wi-Fi流用 vs ゲート新設 vs センサー追加（台数で逆転する）
- 第8章：災害時に意味がある構成：建物内に閉じない外部集計・LTEバックアップ・短期ローカル保持
- 第9章：PoCの進め方：1入口で誤差を可視化し、補正係数を作って横展開する
- 第10章：帰結：完璧を狙わず「意思決定に足る数値」を安定運用するための選定基準
【注意】 本記事は一般的な情報提供を目的としており、施設の構造・動線・既設設備・法令/ガイドライン・プライバシー要件によって最適解は変わります。実案件の設計や意思決定（機器選定・配置・外部サーバ構成・運用設計）で悩んだ場合は、株式会社情報工学研究所のような専門事業者に相談することをおすすめします。
第1章：また人流ツール？——現場が嫌がる「運用が増えるだけ」問題から始める
「人流を見える化しよう」「BCPのために在館者を把握しよう」——言っていることは正しい。でも現場のエンジニアとしては、まずこう思いがちです。
「また新しい箱が増えるの？ 監視対象が増えるの？ 障害対応も増えるの？ しかも“正確に”なんて言われたら、責任だけ重くならない？」
このモヤモヤは自然です。ショッピングセンターのように不特定多数が出入りする環境では、名簿や事前配布QRの前提が置けません。現行の現実解は、多くの場合「スマホ≒人（概算）」で統計的に寄せていくことになります。ところが、Wi-Fi/BLEは“人”ではなく“端末”を見ているだけなので、ここにズレ（ノイズ）が乗ります。
BCPで本当に欲しいのは「個人の特定」ではなく「意思決定に足る状況把握」
BCPの文脈で求められるのは、個人追跡ではなく「今、館内にどれくらい居るか」「どの出入口から流入が多いか」「避難誘導や救助の優先度をどう付けるか」といった状況判断です。ここで重要なのは“完璧な真値”よりも、一定の誤差幅を理解した上で、ブレずに使える指標を作ることです。
例えば災害時、現場は「今どれくらい残っている可能性があるか」を素早く把握し、消防・警備・テナント責任者との連携を回さなければいけません。ここで数値が毎分上下に暴れると、議論が過熱し、社内調整・対人対応が消耗戦になります。まずはノイズカットし、場を整える——そういう“運用のための数値”が必要です。
「建物内サーバに閉じない」設計が、閉じ込め・崩落リスクへのダメージコントロールになる
もう一点、BCPとして現実的なのが「計測・集計・閲覧が建物内に閉じない」ことです。停電、回線断、設備損壊が同時に起こり得る状況では、建物内にしかデータがない構成は脆い。だからこそ、入口ゲートや集計ノードは“薄く”し、外部サーバへ必要最小限の集計値を送れるようにしておく。これは単なるクラウド志向ではなく、閉じ込め時の救助・対外連携の観点で、被害最小化に直結します。
本記事では、ショッピングセンターの前提（事前配布なし、スマホ≒人、災害時は外部で把握）を置いた上で、Wi-Fi/BLEでできる限り精度を寄せる考え方と、入口ゲート（機器＋配置＋運用）をどう組むと腹落ちするかを、エンジニア目線で整理します。
第2章：スマホ＝人（約）が崩れる瞬間：MACランダム化とOS省電力の壁
Wi-Fi/BLEで人流を“端末ベース”に見るとき、まず押さえるべきは「端末は、こちらの都合で喋ってくれない」という事実です。ここを理解しないままPoCを始めると、数週間後に必ずこうなります。
「あれ？ 休日のピークなのに端末数が減ってる。装置が壊れた？ いやログは生きてる…」
Wi-Fi：見えているのは「接続」か「探査」かで世界が変わる
Wi-Fiで端末を数える方法は大きく分けて2系統あります。ひとつはAPへの接続情報（認証・関連付け）を使う方法。もうひとつは、端末が周囲のSSIDを探すために出す信号（いわゆる探査・プローブ）や周辺フレームを受信して推定する方法です。
前者（接続ベース）は、無料Wi-Fiを提供していて接続率が高いと強い一方、接続しない端末は見えません。後者（探査ベース）は、接続していなくても見える可能性がある一方、端末側のプライバシー機構に強く影響されます。
ここで効いてくるのがMACアドレスのランダム化です。端末は追跡されにくくするため、観測できる識別子を変えたり、探査の出し方を変えたりします。つまり、同じ人が同じ場所にいても、こちらからは「別の端末が増えた」「急に消えた」に見えることがあります。これが“端末カウントの揺れ”の正体です。
BLE：検知率は上がるが、距離は粗く、バックグラウンド挙動に癖がある
BLEは「入口近接」の判定に向くことが多いのですが、距離を正確に測るものではありません。RSSI（受信強度）で距離を推定しても、遮蔽物、人の密集、金属・ガラス反射で簡単にズレます。さらにOSの省電力やプライバシー設計によって、バックグラウンドでの広告（アドバタイズ）やスキャンが抑制されることがあり、ピーク時ほど取りこぼしが出ることもあります。
要するに、Wi-FiもBLEも「人流を測る万能センサー」ではなく、端末観測という不完全な信号を、統計と設計で“使える指標”に変換する技術です。
「個体追跡」を捨てると、設計が一気に現実的になる
不特定多数の出入りを前提にすると、個体を長期に追いかける設計は、精度面でもプライバシー面でも難易度が跳ね上がります。ここで方針転換して、「個体追跡ではなく、入口の短時間の挙動から“入った/出た”を推定し、集計だけ残す」という設計にすると、実装と説明責任が一気に整います。
例えば、入口の外側→内側の順に観測されたら“入館らしい”、内側→外側なら“退館らしい”という時系列ルールに寄せる。識別子は長期保存しない。保管するのは1分単位の入数・出数・推定在館だけ。こうすると、技術選定の議論が「どの情報を、どれだけ残すか」という健全な方向に落ち着きます。
次章では、この「入口で勝負する」考え方を、在館推定の数式に落として腹落ちさせます。ここが腑に落ちると、Wi-Fi/BLEゲートの設計要件が自然に決まります。
第3章：入口で勝負する：在館推定は「入数−出数」から逆算すると腹落ちする
人流の話が難しく感じるのは、「どこまで正確にしたいのか」が曖昧なまま、いきなり機器選定に飛ぶからです。プログラマー的に一度、モデルを単純化しましょう。
在館推定は、基本的に次の更新式で表せます。
「推定在館数（今） ＝ 推定在館数（前） ＋ 推定入数 − 推定出数」
当たり前の式ですが、重要なのはここに“推定”が混ざる点です。入数・出数の推定が少しでも偏ると、その誤差が積み上がっていきます。つまり、在館推定は「入口カウントの品質」に全てが乗ります。
誤差設計：一番怖いのは「平均的に外れる」こと
Wi-Fi/BLEは取りこぼしや重複が起こります。ただし、それ自体は致命傷ではありません。致命的なのは、ある条件で“偏って”外れることです。たとえば、ピーク時だけ取りこぼしが増える、雨の日だけ検知が落ちる、店舗イベントのときだけ端末比率が変わる——こうした偏りは、在館推定を一方向にずらし、意思決定を誤らせます。
そこで設計の狙いは、「誤差をゼロにする」ではなく、誤差の性質を制御して、運用で説明できる形にすることになります。言い換えると、炎上/クレーム対応を避けるために、数値の“揺れ方”を制御する、という発想です。
入口を「計測しやすい形」に寄せると、同じセンサーでも精度が上がる
入口カウントは、センサー性能よりも「人の通り方」で決まる場面が多いです。ここがエンジニア的に面白いところで、アルゴリズムより先に“入出のI/O”を整える方が効く。
例えば、入口幅が広いままだと、並列通過・すれ違い・立ち止まりが増え、Wi-Fi/BLEの短時間時系列判定が崩れやすくなります。逆に、導線ポールや什器でレーン化すると、外→内の順序が明瞭になり、同じ受信機でも方向推定が安定します。つまり、ゲートの役割は「測る装置」だけでなく「測りやすい状態を作る装置」でもあります。
「基準入口」を決めると、システム構成がシンプルになる
ショッピングセンターは入口が複数あります。すべてを同じ精度でやろうとすると、コストが跳ねます。ここで現場が納得しやすい戦略は、まず“基準入口”を決めることです。
基準入口：メイン入口（最も通過が多い）。ここを最も安定させる。
補助入口：サブ入口・連絡口・従業員口。ここはコストを抑えつつ、偏りが出ない設計にする。
在館推定が崩れる典型は「メイン入口の偏り」なので、まずそこにリソースを集中し、他入口は“歯止め”として最低限の整合を取る。これが、投資対効果の良いダメージコントロールになります。
次章以降では、この入口モデルを前提に、Wi-Fi/BLEゲートの具体設計（外側/内側ユニット、指向性、5GHz/2.4GHzの使い分け、外部サーバ送信）へ落としていきます。
第4章：Wi-Fi/BLEゲートの基本設計：外→内の時系列で“方向”を決める
入口で勝負する、と決めた瞬間に設計が楽になります。なぜなら「館内全域で測位する」ではなく、「ゲートを通過したっぽいイベント」を作ればよいからです。ここでの核心は、距離を正確に当てることではなく、外→内／内→外という順序（時系列）で方向を確定することです。
現場の心の会話で言うと、こうです。
「位置をセンチメートル単位で当てろって言われたら詰む。でも“順番”ならログ設計で勝てる」
ゲートの最小構成：外側ユニット＋内側ユニット
入口の外側と内側に、同じ役割の受信ユニットを置きます。どちらもWi-FiとBLEを“受信”し、一定時間ウィンドウ（例：数十秒）で観測された端末らしき信号をスコア化します。ポイントは「同一端末の厳密一致」を捨て、短時間だけ“同一っぽさ”を組み立てることです。
例えば、外側ユニットで観測された信号の特徴（受信強度の変化、出現間隔、2.4/5GHzの同時性、BLE広告の周期的出現など）が、直後に内側ユニットでも観測されたら「入館イベント」とする。逆順なら「退館イベント」とする。こうした時系列判定は、測位よりも現実に強いです。
「同一っぽさ」を作るときに見る“特徴量”の例
MACアドレスやBLEアドレスが変わる可能性がある以上、識別子一本槍は危険です。そこで、短時間の観測から次のような特徴量の組を使い、重複カウントや取りこぼしを減らします。
RSSIの推移：外側で強→内側で強、という“移動らしさ”があるか
観測タイミング：外側観測から内側観測までの遅延が、人の歩行速度として妥当か
同時観測：Wi-Fi 5GHzと2.4GHz、またはWi-FiとBLEの両方で近い時間に出現するか
バースト性：端末が一定時間だけ“喋る”パターン（省電力の癖）を踏まえてスコア化する
ここで大事なのは、個体追跡ではなく「入口の集計」を安定させることです。識別子を長期保存しない設計（例えば数十秒〜数分で破棄）にしておけば、プライバシー面の議論も沈静化しやすく、運用説明もしやすくなります。
ゲート設計の論点を表で整理する
| 論点 | Wi-Fiで起きやすいこと | BLEで起きやすいこと | ゲート設計での対策 |
|---|---|---|---|
| 取りこぼし | 接続しない端末は見えにくい／探査が減ると急に減る | 広告やスキャンが間引かれると出現頻度が落ちる | 両方を受信して冗長化／短時間ウィンドウで“出現したら拾う” |
| 重複 | 識別子が変わると別端末に見えることがある | ランダムアドレス等で継続性が崩れる場合がある | 識別子依存を弱め、時系列＋RSSI推移＋同時観測でスコア化 |
| 方向判定 | 電波が広がると外/内が混ざる | 反射や人体遮蔽で強度が揺れる | 指向性と設置距離で外/内を分離し、外→内の順序で確定 |
| 説明責任 | 「人ではなく端末」問題が残る | 同左（端末ベース） | “個体追跡しない・集計のみ”を前提に、誤差幅と利用目的を明確化 |
建物内に閉じない：外部サーバへ“集計だけ”を送る
BCPの観点で効くのは、データを外へ出すことです。ただし生データ（パケット）を外へ出すと、通信量・管理・リスクが膨らみます。現実的な落としどころは、ゲート側では次のような集計だけを作ることです。
1分ごとの 推定入数・推定出数・推定在館
入口ごとの 信頼度スコア（その分の観測が薄かった/濃かったの目安）
障害監視用の 死活・温度・ストレージ残量（運用の歯止め）
通信は有線が理想ですが、災害時や回線断を考えるとLTE/5Gバックアップが効きます。こうしておくと、閉じ込めや設備損壊の局面でも「外部の関係者が状況を把握できる」状態を作れます。これがBCPとしての堤防になります。
次章では、方向判定の成否を大きく左右する「指向性」と「5GHz/2.4GHzの使い分け」を掘ります。ここは設置の工夫で結果が変わる、コスパの良いポイントです。
第5章：指向性アンテナと 5GHz/2.4GHz の使い分け：検知範囲は“狭くする”ほど精度が上がる
人流計測でありがちな失敗は、「とにかく拾えるだけ拾おう」と受信感度を上げすぎて、入口の外と内が混ざることです。結果として、方向判定が不安定になり、入数と出数が行ったり来たりして、現場の温度が上がります。
ここでのキーワードはノイズカットです。検知範囲は広ければ良いのではなく、「入口の外側」「入口の内側」という二つの領域を分けるために、むしろ狭くした方が精度が上がります。
なぜ5GHzが効きやすいのか（一般論）
一般に、5GHzは2.4GHzに比べて減衰が大きく、壁・人混みの影響を受けやすい傾向があります。これは“通信”では弱点になり得ますが、“外/内を分けたい”入口ゲートではメリットになります。つまり、外側ユニットが館内まで拾いにくく、内側ユニットが屋外まで拾いにくい、という分離が起きやすい。
ただし、環境（ガラス面・吹き抜け・金属什器・天井高）で反射や回り込みは起こります。そこで、5GHzは主チャネル、2.4GHzは補助、といった二段構えが実務的です。
指向性アンテナ：入口に“向けて”拾い、横へは拾わない
ゲートの目的は「入口の通過」です。ならばアンテナも入口を向いているべきです。指向性アンテナ（パッチ等）で、受信方向を入口の通路に絞ると、次の効果が出ます。
入口の外/内の混ざりが減り、方向判定が安定する
関係ないゾーン（テナント前・ベンチ付近）の端末を拾いにくくなり、重複が減る
“拾えなかった”ときの原因が切り分けしやすい（設置角度・遮蔽物の問題に落ちる）
現場の感覚で言うと、「センサーの性能を上げる前に、I/Oを整える」発想です。ソフトウェアの入力品質を上げるのと同じで、ハードでも入口の入力を整えると、アルゴリズムが効きます。
外側/内側の設置距離：短すぎても長すぎてもダメ
外側と内側を近づけすぎると、同じ端末を両方が同時に拾って混ざります。離しすぎると、人が途中で立ち止まったり、端末が省電力で沈黙したりして、時系列が途切れます。理想は「歩行で自然に通過する距離」の中に収めることです。
ただしショッピングセンターでは、ベビーカー・台車・行列・立ち止まりが常に起きます。だからこそ、距離は固定値で決め打ちせず、入口の導線設計（レーン化）とセットで考える必要があります。入口が広いなら、1レーンに無理やり1セットで対応せず、レーン分割して複数セットにした方が、結果として安定し、運用が楽になります。
ゲート機器の構成を“役割”で分ける
実装が泥沼化するのは、ゲートユニットに全部を詰め込むときです。おすすめは役割分割です。例えば次のように考えると、障害時のダメージコントロールが効きます。
| 要素 | 役割 | 故障時の影響 | 歯止め |
|---|---|---|---|
| 外側/内側受信 | Wi-Fi/BLE観測・短時間スコア化 | その入口の推定精度が落ちる | 冗長化（Wi-Fi+BLE）／信頼度スコアを出して“怪しい”を見える化 |
| 集計・バッファ | 1分集計、短期ローカル保持 | 通信断時にデータが飛ぶ | リングバッファ（短期）／復旧時に再送 |
| 外部送信 | TLSで外部サーバへ集計送信 | 外部から状況が見えない | LTE/5Gバックアップ／死活監視 |
こうしておくと、「まず入口の分離（指向性・周波数）」「次に時系列判定」「最後に外部送信」という順で、段階的に詰められます。議論が過熱しにくく、関係者の合意形成も進めやすい構成です。
次章では、Wi-Fi/BLEだけで頑張る場合と、IR/ToF/mmWaveのような人数カウンタを“最小限”足して、推定の堤防を築く場合の違いを整理します。ここはコストの話に直結します。
第6章：安価カウンタ3兄弟（IR/ToF/mmWave）：何がどこまで正確で、どこで外れるか
「Wi-Fi/BLEだけでやり切りたい」気持ちは分かります。配線や工事を増やしたくないし、機器管理も増やしたくない。でも現場目線で言うと、入口カウントの“基準”がないまま推定に全振りすると、あとで説明が苦しくなりがちです。
ここで効くのが、個人特定をしない人数カウンタを“最小限”足す設計です。Wi-Fi/BLEは傾向、カウンタは入口の基準。両者を組み合わせることで、推定の穴埋めができます。
3方式の特徴を、実務の観点で整理する
| 方式 | 得意 | 苦手 | 設置のコツ |
|---|---|---|---|
| 赤外線（IR）双方向ビーム | 入口が狭い/レーン化されている場合の入退館方向 | 並列通過、密集、立ち止まり、台車・ベビーカーの混入 | レーンを1人幅に寄せる／ビーム高さと角度を調整／“逆流”を減らす |
| 上向きToF（天井設置） | 入口カウント、密集時の分離（設計次第で強い） | 天井工事・設置位置の制約、死角（看板・梁） | 入口直上に置く／死角を作らない／広い入口はレーン分割して台数で解決 |
| ミリ波レーダー（mmWave） | 暗所でも動きやすい、プライバシー配慮のゾーン把握 | 遮蔽物や反射で特性が変わる、入口“線”よりゾーン“面”向き | 壁・柱の影響を避ける／ゾーン設計とセットで配置／入口単体に過期待しない |
「安価」かどうかは、既設Wi-Fiの強さと入口数で逆転する
コスト比較で見落とされがちなのは、Wi-Fi/BLEが“安い”のは既設環境をうまく使える場合に限られる、という点です。既設Wi-Fiが十分にあり、ログ取得や解析基盤もすでにあるなら、追加コストは小さくできます。一方、入口のために新規で受信ゲートを置き、電源や回線、保守を揃えると、入口数が増えるほど積み上がります。
逆に、IRやToFは「入口を計測する」という目的に直結する分、入口数が少ない段階では費用対効果が出やすいことがあります。ここは“どちらが常に安い”ではなく、入口数と既設設備で最適解が変わります。
精度以上の効果が出るのは「入口の形を整えた」とき
センサーを高級にする前に、入口の通り方を整える方が効くケースが多いです。たとえば、IRが苦手な並列通過も、導線ポールでレーン化すれば沈静化します。ToFも、入口直上で死角を潰すだけで精度が上がることがあります。
ここがBCP設計の面白いところで、装置だけではなく、施設運用（導線、案内、警備動線）を含めて“測れる状態”を作ると、同じ機器でも結果が変わります。技術だけでなく、現場の社内調整・対人の設計が、数値の安定につながります。
Wi-Fi/BLEと人数カウンタの“役割分担”が腹落ちポイント
整理すると、こうです。
人数カウンタ：入口の入数/出数を“基準値”として作る（在館推定の堤防）
Wi-Fi/BLE：端末比率・混雑傾向・滞在の偏りを見て、基準値の解釈を補助する（ノイズカットの材料）
この役割分担ができると、「Wi-Fi/BLEで完璧に人数を当てる」という無理筋から降りられます。結果として、PoCも運用もブレーキが効き、継続的に改善できる構造になります。
次章では、ここまでの設計論を「費用の組み立て方」に落とし、既設流用・ゲート新設・カウンタ併用が、入口数でどう逆転するかを、現場で説明できる形にします。
第7章：コスト比較の現実：既設Wi-Fi流用 vs ゲート新設 vs センサー追加（台数で逆転する）
人流・流入の話がこじれやすい理由のひとつが、「精度」と「費用」と「責任」が同時に議論されるからです。しかも、ショッピングセンターは入口が複数あり、テナント都合で動線も変わります。ここで重要なのは、結論を“機器の値段”で決めないことです。
現場の心の会話はこうなりがちです。
「安いって言われたから採用したのに、運用コストで燃えるやつだ…」
まずコストを分解する：CAPEXとOPEXと“人件費”
入口計測の費用は、ざっくり次の3つに分かれます。
CAPEX（初期費）：機器、取付金具、配線（PoE等）、小型UPS、設置工事
OPEX（運用費）：回線（LTE/5G含む）、クラウド/サーバ、監視、保守交換、定期点検
人件費（見落とされがち）：障害一次対応、現地確認、ログ解析、再校正、関係者への説明資料
Wi-Fi/BLEは「既設を流用できるならCAPEXが小さい」一方、運用の中で“端末比率の変化”や“入口混雑の偏り”が出たときに、説明と再調整の負荷が乗ることがあります。逆にIR/ToF/mmWaveのような人数カウンタは「入口の基準値」を作りやすい分、説明コスト（社内調整・対人）が沈静化しやすいことがあります。
比較は「入口数」「既設設備」「要求する使い方」で逆転する
代表的な3パターンを、判断軸ごとに整理します。
| パターン | 初期費 | 運用費 | 精度の安定性 | 向く状況 |
|---|---|---|---|---|
| 既設Wi-Fi流用（＋分析） | 小〜中（流用度合い次第） | 中（分析基盤・監視） | △〜○（端末側要因に影響） | 「混雑傾向」「滞在傾向」が主目的、既設が強い |
| Wi-Fi/BLEゲート新設 | 中（入口数で比例） | 中〜大（回線・保守） | △（設置で改善するが限界あり） | 既設が弱い、入口方向イベントを作りたい |
| 人数カウンタ併用（IR/ToF/mmWave） | 中（入口数・方式で変動） | 小〜中（方式により月額あり） | ○〜◎（入口基準が作れる） | 在館推定を“意思決定に足る値”として使いたい |
費用見積りのテンプレ：入口単位で積み上げる
現場で説明しやすいのは、「入口1か所あたりのユニット費×入口数＋共通費」です。共通費には、外部サーバ・監視・ダッシュボード・運用手順書・教育が入ります。入口の方式が違っても、ここは共通です。
さらに、BCPの観点では「通信断でも最低限の集計が外に出る」構成が重要なので、入口ごとの回線バックアップ（または館内共通のバックアップ回線）も見込む必要があります。ここを削ると、災害時に“見えない”という最悪の穴が残ります。
“安く見える案”が高くつく典型パターン
経験的に、次のパターンは炎上/クレーム対応に発展しやすいです。
精度要件が曖昧：最初は「だいたい」で始めたのに、途中から「正確に」に変わる
入口が広いのに1セットで無理：並列通過で方向判定が崩れ、数値が揺れる
外部への出力が弱い：災害時に見えず、BCPの目的を満たせない
これを避けるには、PoCで「誤差幅」と「使い方（判断にどう使うか）」を先に決め、そこに合う構成へ段階的に寄せるのが現実的です。次章では、BCPとして意味がある“外部で把握できる”構成を、もう一段具体にします。
第8章：災害時に意味がある構成：建物内に閉じない外部集計・LTEバックアップ・短期ローカル保持
BCPの目的を「平時の可視化」だけにすると、設計が軽くなりすぎます。ショッピングセンターのBCPで重いのは、停電・通信断・設備損壊・人的対応の逼迫が同時に起きることです。ここで必要なのは、見栄えの良いダッシュボードより、状況把握が途切れない堤防です。
現場の心の会話で言うと、こうです。
「災害時にダッシュボードが落ちたら、結局“見えないまま”意思決定するしかない。それだけは避けたい」
原則1：ゲートは“薄く”、外部サーバに“集計だけ”を出す
入口ゲートで生パケットや生ログを溜めると、容量・セキュリティ・運用が重くなります。BCPで本当に必要なのは「何人くらい残っている可能性があるか」「どの入口から流入/流出が起きているか」という集計です。だから、ゲートは薄く、次のような粒度に落とします。
入口ごとの1分集計（入数/出数/推定在館）
信頼度スコア（観測が薄い/濃い、異常値の有無）
死活・電源状態（AC/UPS）、温度、ストレージ残量
これなら通信量は小さく、外部へ出し続けやすい。災害時でも、最低限の状況把握が残ります。ここがダメージコントロールの基本です。
原則2：通信は“二系統”が現実的（有線＋LTE/5G）
ショッピングセンターの回線は、館内回線・テナント回線・監視回線などが混在し、災害時には輻輳や断線も起きます。ここで、入口ゲート（または集計ノード）が有線のみだと、回線断＝即ブラックアウトになります。
そこで、通信は二系統を推奨します。
第一系統：有線（可能ならPoEで電源も統一）
第二系統：LTE/5G（バックアップ、または最低限の集計送信用）
この二系統があるだけで、災害時の「見えない」を大きく減らせます。BCPとして“外部の関係者が見える”状態を維持できるのは、実務上の価値が大きいです。
原則3：短期ローカル保持（リングバッファ）で“漏れ止め”する
通信が完全に途切れる瞬間はどうしてもあります。そこで、ゲート側に短期のローカル保持（例：数時間〜数日）を持たせ、回線復旧後に再送できるようにします。ここで重要なのは、保持するのは“集計”だけにし、個体追跡につながる情報を長期に残さないことです。
これにより、運用上は「通信断の間の数字が欠けた」という穴が埋まり、あとから状況の説明がしやすくなります。結果として、議論が過熱しにくく、場を整えやすい。
外部サーバ側の要件：落ちないより“復旧が速い”を優先する
外部サーバは冗長化が前提ですが、BCPで効くのは「完全無停止」よりも「復旧が速く、復旧後にデータが追いつく」設計です。入口ゲートがリングバッファを持っていれば、外部側の短期停止は吸収できます。
外部側は、次のような現実的な構成が取りやすいです。
受信API（TLS、認証）＋メッセージキュー（再送・順序吸収）
時系列DB（1分集計の保存）＋簡易ダッシュボード
災害モード表示（最新時刻、入口ごとの信頼度、推定在館）
この構成なら、災害時の最優先である「今どうなっているか」に集中できます。装飾は後で良い。まず“見える”ことに全振りします。
次章では、ここまでの設計を、PoC（現地検証）でどう固めるかを具体手順に落とします。PoCのやり方次第で、全体の温度が下がる（＝腹落ちする）か、上がる（＝揉める）かが決まります。
第9章：PoCの進め方：1入口で誤差を可視化し、補正係数を作って横展開する
PoCで一番やってはいけないのは、「とりあえず入れてみて、数字が出たからOK」としてしまうことです。人流の数字は、それっぽく見えます。でも、偏りがあるとBCPの判断を誤らせます。PoCの目的は、デモではなく誤差の性質を掴み、運用で使える形に沈静化することです。
現場の心の会話で言うと、こうです。
「数字が出るのは当たり前。問題は“その数字がいつ嘘をつくか”だよね」
ステップ1：基準入口を1つ決める（メイン入口推奨）
まず入口を1つに絞ります。理由は簡単で、入口が増えると要因が増えて原因が追えなくなるからです。メイン入口は通過が多い分、データが早く溜まり、偏りも見つけやすい。ここを基準入口として詰めるのが近道です。
ステップ2：比較対象（グラウンドトゥルース）を用意する
Wi-Fi/BLEの推定だけを見ても、正しいか分かりません。そこでPoCでは、短期間でもよいので“比較対象”を置きます。ここでの比較対象は、個人特定ではなく、入口の通過数です。
警備員の手カウント（短時間・ピーク帯だけでもよい）
IR/ToF/mmWaveなど人数カウンタの暫定設置（レンタルや簡易固定でもよい）
この比較対象があるだけで、議論が「感想」から「差分」に変わります。社内調整が楽になります。
ステップ3：評価指標を決める（“誤差ゼロ”ではなく“用途に足る”）
BCP用途で現実的なのは、次のような評価です。
方向の整合：入数と出数が明らかに逆転しない（逆転する条件が説明できる）
ピーク帯の偏り：混雑時に過小/過大が一方向に寄りすぎない
復旧性：通信断後に集計が追いつく（穴が残らない）
信頼度の見える化：怪しい時間帯を“怪しい”と言える（ノイズカットの前提）
ここを決めずに「正確さ」だけを追うと、無限に改善が必要になり、運用が増えていきます。評価軸は最初にブレーキをかけるためのものです。
ステップ4：補正係数を作る（端末比率の変動を“織り込む”）
ショッピングセンターでは、来館者の端末比率は一定ではありません。曜日、天候、イベント、年齢層、観光シーズンで変わります。だから、固定係数で永久に当てに行くのは危険です。
PoCでは、比較対象とWi-Fi/BLE推定の差分から、時間帯・曜日などの粒度で補正の当たりを付けます。重要なのは、補正を“魔法”にしないことです。補正は、数式ではなく運用に落とします。
補正は「曜日×時間帯」など限定されたルールにする（複雑化すると保守不能）
補正の根拠を、比較対象データで説明できるようにする
信頼度が低い時間帯は、推定在館の“幅”として表示する（断定しない）
こうすると、誤差がゼロでなくても、意思決定に使える“整った数字”になります。議論が過熱しにくくなり、BCP運用の温度を下げられます。
ステップ5：横展開は“入口の型”を揃えてから
PoCが終わったら、いきなり全入口に広げたくなります。でも、入口の形が違うと同じ設定は効きません。横展開の前にやるべきは、入口ごとの「型」を作ることです。
入口幅、レーン化の有無、立ち止まりポイント、回り込みの有無
外側/内側ユニットの設置距離、指向性の向き、5GHz/2.4GHzの使い分け
通信（有線/LTE）の取り回し、UPSの有無、保守動線
この“入口の型”を揃えると、設定・監視・保守が標準化でき、運用が増えにくい。結果として、現場が納得しやすい仕組みになります。
次章では、ここまでの議論をまとめて「完璧を狙わず、意思決定に足る数値を安定運用する」という帰結に落とします。そして最後に、個別案件では一般論の限界があること、だからこそ株式会社情報工学研究所のような専門家に相談すべき理由を、自然な流れで整理します。
第10章：帰結：完璧を狙わず「意思決定に足る数値」を安定運用するための選定基準
ここまでの話を、あえて乱暴に一言でまとめるとこうです。
ショッピングセンターの流入・人流把握は、「人を正確に数える」プロジェクトではなく、不完全な信号を、運用で使える指標に“整える”プロジェクトです。
「完璧に当てる」方向に舵を切ると、端末側のプライバシー機構や省電力挙動、入口の混雑・立ち止まり・反射環境など、コントロールできない要因が増えます。すると、現場の説明負荷が増え、議論が過熱し、最後は「使われないダッシュボード」が残りがちです。
選定基準は「精度」だけでなく「誤差の説明可能性」と「災害時の見え方」
BCPの観点で本当に効くのは、次の3点です。
誤差が偏らない：多少ズレても、特定条件で一方向に外れ続けない（偏りが起きる条件を把握できる）
信頼度が出せる：怪しい時間帯を「怪しい」と言える（ノイズカットの前提が作れる）
外部で見える：建物内に閉じず、通信断でも集計の漏れ止め（短期保持）と再送ができる
この3点を満たすと、「正確かどうか」だけの不毛な衝突から降りられます。現場は「今は信頼度が低い」「だから幅で見る」「次にここを改善する」と言えるようになり、場が整います。
最終的な機器選定を“意思決定表”に落とす
実務では、入口数・既設設備・求める使い方（BCPの判断に使うのか、平時の傾向把握が主なのか）で最適解が変わります。そこで、説明しやすい形に落とすための対応表を置きます。
| 要求 | 優先する構成 | 理由 | 注意点 |
|---|---|---|---|
| 平時の混雑傾向を見たい（概況） | 既設Wi-Fiログ活用＋補助でBLE | 追加工事を抑えつつ傾向を掴みやすい | 端末比率の変動を前提にし、断定値にしない |
| 入口の入/出方向を安定させたい | Wi-Fi/BLE外側・内側ゲート（指向性＋5GHz主） | 外→内の時系列で方向を作れる | 入口のレーン化（通り方）をセットで設計する |
| BCPで在館推定を意思決定に使いたい | 人数カウンタ（IR/ToF/mmWave）＋Wi-Fi/BLE補助 | 入口の基準値が作れ、説明が沈静化しやすい | 広い入口は台数で割り切る（1台で無理をしない） |
| 災害時に外部で状況把握したい | 外部サーバ集計＋LTE/5Gバックアップ＋短期ローカル保持 | 建物内に閉じない＝閉じ込め時のダメージコントロール | 生データ外送を避け、集計のみ＋信頼度で運用する |
プライバシーと説明責任は「設計で先にブレーキをかける」
不特定多数の人流を扱う場合、個人追跡の誤解が生まれると、導入が止まります。ここで効くのは、設計時点で「残すデータ」を最小化し、運用資料として言語化することです。
個体追跡を目的にしない（長期IDを作らない）
ゲート側で短時間スコア化して破棄し、外部へは1分集計のみ送る
信頼度スコアを併記し、「確度が低い時間帯」を断定しない
こうしておけば、技術的にも説明的にも歯止めが効きます。「何をするか」だけでなく「何をしないか」を決めるのが、BCP向けの機器選定では重要です。
一般論の限界：入口と施設運用が違えば、同じ機器でも結果が変わる
最後に強調したいのは、ここまでの話はあくまで一般論だということです。入口の形状（幅、吹き抜け、ガラス面、金属什器）、人の通り方（並列、立ち止まり、行列）、既設Wi-Fiの配置、外部回線の取り回し、警備・テナントの運用——これらが変わると、同じ機器でも“効き方”が変わります。
つまり、機器選定は「カタログ比較」で完結しません。PoCで誤差の性質を掴み、補正と運用の型を作り、災害時に外部で見える構成まで落とす必要があります。ここは社内調整・対人も含めて設計する領域で、現場だけで抱えると消耗戦になりやすい。
もし、具体的な案件として「入口が多い」「既設設備が複雑」「BCPとして外部把握が必須」「プライバシー説明が必要」といった条件が重なるなら、株式会社情報工学研究所のような専門家と一緒に、要件整理→PoC→運用設計まで一本の線で組み立てる方が、結果的に被害最小化（コスト・工数・炎上リスクの抑え込み）につながります。
次の一歩としては、「入口数」「既設Wi-Fiの有無」「BCPで何を判断したいか（在館推定が必要か）」「外部で見たい範囲」を整理するだけで十分です。その情報があれば、過不足ない機器構成と、現場が回る運用の型を一緒に設計できます。
付録：現在のプログラム言語各種で実装する場合の注意点（ゲート／外部サーバ／ダッシュボード）
ここからは、同じ構成を作るとしても「どの言語でどこを作るか」でハマりやすい点を整理します。重要なのは、言語の優劣ではなく、役割（ゲート・集計・外部API・可視化・運用）に合った選択をすることです。
Python：PoCと分析に強いが、ゲート常駐と低レイヤは設計が必要
強み：PoCのスピード、時系列分析、補正係数の検討、運用スクリプト化が速い。
注意点：Wi-Fiパケット/低レイヤ扱いはOS権限やドライバ依存が大きい。常駐プロセスにするなら、再起動・監視・ログローテ・例外時の自動復旧（漏れ止め）が必須。
向く場所：分析基盤、集計処理、PoC用の入口評価ツール、バッチ再送。
JavaScript / TypeScript（Node.js）：外部APIとダッシュボードに強いが、長期運用は監視前提
強み：Webダッシュボード、API、通知、可視化の開発が速い。TypeScriptで型を入れると保守性が上がる。
注意点：依存パッケージ更新が多く、セキュリティパッチ追従が運用コストになる。常駐運用はプロセスマネージャ（監視・自動再起動）とセットで考える。
向く場所：外部受信API、管理画面、通知、集計表示（災害モード画面など）。
Go：外部API・集計・常駐に向くが、可視化は別レイヤが必要になりがち
強み：単体バイナリで配布しやすく、常駐サービスとして安定させやすい。並行処理やI/Oで堅い。
注意点：UIや細かな可視化は別途Webフロントが要ることが多い。PoCの“試行錯誤”速度はPythonに比べて落ちる場面がある。
向く場所：外部受信API、メッセージキュー連携、集計サービス、ゲートの送信エージェント。
Java / Kotlin（サーバサイド）：堅牢だが、PoCの小回りより標準化向き
強み：大規模運用、監視、ログ、権限管理など“企業運用の型”に乗せやすい。
注意点：PoCでの速度や、現地での小改修は工数が増えやすい。最初から重く作ると導入が遅れる。
向く場所：外部サーバ基盤（受信・認証・権限・監査）、長期運用の中核。
C# / .NET：業務系統合に強いが、現地ゲートのハード連携は環境依存に注意
強み：既存の業務基盤（AD、社内認証、管理ツール）との統合がしやすい。Windows運用の現場では導入が早いことがある。
注意点：ゲート機器がLinux系や組込みの場合、周辺の運用設計が分かれる。マルチOS前提なら設計段階で役割分割が必要。
向く場所：管理コンソール、既存業務システム連携、レポート生成。
C / C++：ゲートの低レイヤや組込みに強いが、保守性と安全設計が最重要
強み：無線モジュール、ドライバ、センサー連携、低消費電力の常駐処理など“入口機器”の中核に向く。
注意点：メモリ安全性や例外時の挙動が品質に直結する。災害時に落ちると“見えない”ので、ウォッチドッグ、ログ、自己診断、フェイルセーフ（最小機能で動く）を設計で入れる必要がある。
向く場所：ゲート機器、センサー処理、短期リングバッファ、送信エージェントの基盤。
Rust：安全性と堅牢性で魅力だが、周辺ライブラリと開発体制を確認
強み：メモリ安全性を軸に、常駐系の安定性を上げやすい。ゲートの漏れ止め設計に相性が良い。
注意点：無線・ハード連携や特定センサーの周辺ライブラリ状況、チームの習熟度で速度が変わる。導入初期は学習コストが出ることがある。
向く場所：ゲート常駐、送信エージェント、集計処理のコア。
PHP：管理画面や既存Web連携に使われがちだが、リアルタイム・常駐は工夫が必要
強み：既存CMSや管理画面との連携で導入が速いことがある。
注意点：リアルタイム集計や常駐処理を前提にすると設計の工夫（ジョブ、キュー、別プロセス）が必要。入口ゲートのリアルタイム制御には向きにくい。
向く場所：既存Web基盤への表示・レポート、限定的な管理機能。
共通の落とし穴：セキュリティと運用の“穴”が、BCPでは一番痛い
言語に関係なく、BCP用途でやってはいけないのは「動いたからOK」で止めることです。災害時ほど、運用の穴が露呈します。最低限、次を設計に含める必要があります。
認証と暗号化：外部送信はTLS、鍵管理、失効、ローテーションの運用を用意する。
監視と自動復旧：死活、遅延、欠損、再送、ストレージ枯渇を検知して自動で立て直す。
データ最小化：個体追跡に寄せない。外部へ出すのは集計と信頼度に限定する。
現地保守動線：交換手順、予備機、UPS、配線、警備との役割分担を文書化する。
ここまで含めて初めて、「災害時に意味がある人流把握」になります。一般論としてのベストプラクティスは示せますが、実際は施設ごとの入口・動線・既設設備・運用体制で最適解が変わります。
だからこそ、具体的な案件・契約・システム構成で悩んだ段階では、株式会社情報工学研究所のような専門家に相談し、要件とリスクの優先順位を整理した上で、PoCと運用設計まで一体で進めることをおすすめします。結果的に、無駄な改修や炎上対応の抑え込みにつながり、現場の負担を下げられます。
