著者：ManThink Engineering 公開：2026-09-18 シリーズ：LoRaWAN技術読本 · 第14号 · 業界動向
2026において、LoRaWANはビル向け無線技術の事実上のリーディング技術である。LoRa Allianceの2025年末レポート（2026-02公開）は次を確認している： LoRaWANは現在、スマートビルおよびファシリティマネジメント向けのトップ無線技術として首位にある。世界で1億2500万台のデバイスが展開され、年間平均成長率は25%である。
そうした背景の中で、現場で測定されたある結果は、ほとんど矛盾のように読める。
台湾の近代的なオフィスビルでの試験で、エンジニアは1階に単一のLoRaWANゲートウェイを設置し、3つの位置にセンサーを配置した：
ゲートウェイは1台。同じ65メートルの水平距離。2フロアの垂直分離が「安定」を「使用不可」に変えた。
この試験は新しいことを何も発見していない。業界が何年も言い続け、プロジェクトスケジュールが日常的に圧縮してしまうことを、ただ言い直しただけである： 建物内では、LoRaWANカバレッジの単位は平方メートルではない。伝搬ゾーンである。1フロアにつき1ゲートウェイは保守的な設計ではなく、エンジニアリング上の下限である。
本記事では3つの問いに答える：今日LoRaWANが建物内で実際にどこに位置するのか、展開を真に妨げているものは何か、そして実際の建物向けにネットワークをどう設計するか。
全体像を枠づける六つのデータポイント。
| 指標 | 値 | 出典と範囲 |
|---|---|---|
| 世界で展開されている LoRaWAN デバイス | 125 百万台、25% CAGR | LoRa Alliance 2025 年末レポート（2026 年 2 月） |
| エコシステムの規模 | 360 会員（2025 年に 57 社が新規加入）／625 以上の認証済みデバイス | 同上 |
| ビル分野の位置づけ | 現在は 主要な無線技術 スマートビルおよびファシリティマネジメント向け | 同上 |
| ビル市場の成長 | Alliance により LoRaWAN の 最も急成長している分野 | LoRa Alliance プレスリリース、2025-09-16 |
| LPWAN接続全体 | 439 M（2024）→ 約1.8 B（2034） | Transforma Insights |
| 世界のスマートビルディング自動化市場 | 2026年に82 B米ドルを超え、前年比+12.7%。APACが増分需要の38%超を寄与 | 市場調査、2026 |
| 商業ビルにおけるスマートシステムの採用 | 調査対象の所有者／運営者の91%。組織あたりの平均支出は550,000米ドル超 | ASHB調査、2025年12月 |
| 新築商業ビルにおける無線プロトコルの普及率 | 60%超（Zigbee 3.0／Thread／Matter） | 同上 |
市場規模に関する注記：定義は大きく異なる。広範な「スマートビルディングにおけるIoT」の推計は2025年で115.8 B米ドル、2032年までに272.1 B米ドルに達する。狭義の「スマートビルディング向けプロフェッショナルIoTプラットフォーム」は1.41 B米ドル（2025）から5.72 B米ドル（2035）である。常に範囲を明示すべきである。さもなければ同じ市場が800倍も異なって見える。
良い数字だ。しかし、LoRaWANを実際にビル所有者の予算項目に押し上げたのは、他ならぬ三つの進展である。
これは2025～2026年における最大の変化である。かつてビルの効率改修は、所有者が先送りできるコスト削減プロジェクトだった。今では厳格な期限を伴うコンプライアンスプロジェクトとなっている。
欧州：
中国：
GB 55015-2021の「ブレークポイント・レジューム」要件に注意が必要だ。これにより低価格帯センサーの多くが排除される。デバイスはネットワーク障害時にデータをローカル保存し、復旧後にバックフィルしなければならない。そのためファームウェアにローカルストレージ、タイムスタンプ、再送ロジックが求められる。 これは通信要件ではなく、デバイス選定の閾値である。
有線設置の隠れたコストはこれまで過小評価されてきた。業界ベンチマークでは、 有線センサーポイント1点あたりの総負荷コストは概ねEUR 300 — ケーブル、コンジット、ケーブルトレイ、人件費、そして穴あけ後のパッチ処理。3階建てオフィス全体の200ポイントは、ダウンタイムや美観の復元を数える前の時点でEUR 60,000です。
LoRaWANセンサーは通常、1点あたり数分で設置でき、ケーブルや電線管が不要なため、設置総コストを最大60%削減できます。既存の建物、賃貸物件、そして建物の構造に手を加えることが許されない歴史的建造物では、多くの場合これが唯一実行可能な方法です。
625を超えるLoRaWAN認証デバイスが存在する。さらに重要なのは、主要ベンダーが汎用ゲートウェイの転用ではなく「ビル」を独立した製品ラインとして扱うようになったことだ。最も明確な兆候は ネイティブなビルプロトコル統合である。新世代のビルIoTゲートウェイはBACnet/IP、BACnet MS/TP、Modbus TCP/RTU、KNX TP1、M-Bus、LoRaWANを1台に統合し、LoRaWANセンサーデータがミドルウェア層なしで既存BMS内のネイティブBACnetオブジェクトとして現れる。
この点は慢性的に過小評価されている。ビルオートメーション業界はBACnetに数十年分の知見を投資しており、施設チームはグラフィック、アラームロジック、エスカレーションルールといったワークフロー全体をBMS上に構築している。 LoRaWANがBACnetを話せるかどうかが、弱電室に招き入れられるか、ドアの外に置かれるかを決める。
ManThink（門思科技）は、デバイス接続、ネットワーク、データ活用に向けたIoT製品を提供しています。この記事の技術情報とあわせて、以下の製品情報をご覧ください。
ボトルネックを論じる前に、なぜLoRaWANがそもそも採用されるのかを確認する価値がある。
| シナリオの特性 | 有線の問題 | LoRaWANの利点 |
|---|---|---|
| 既存建物の改修 | 追いかけ配管、電線管、美観損傷、使用中スペースの混乱 | ケーブル不要、専門外でも設置可能 |
| 賃貸物件 | 所有権や賃貸条件が恒久的な工事を制限 | 取り外し・移設可能、賃貸条件の変化に対応 |
| メーターがライザー/地下に集中 | 電気工事に不向きな環境、検収が困難 | 電池駆動、メーターボックス横に設置 |
| 時間とともに変化する分散ポイント | ポイント追加のたびに新規配線が必要 | 工事ゼロでセンサー追加 |
| 歴史的保護建造物 | 歴史的躯体の改変が禁止 | 唯一実行可能な選択肢 |
最後の2行を見てほしい。ビルIoTの最も価値ある特性は「ワイヤレス」ではなく、 段階的な進化可能性である。
典型的な実プロジェクトの道筋：漏水検知と機械室監視から始め（リスク主導）、実証後にサブメータリングを追加し（効率主導）、次に空間利用とIAQを追加する（体験主導）。すべての2,000ポイントを最初から指定するビルプロジェクトは存在しない。 「稼働しながら構築する」このケイデンスを支えられるのはワイヤレスだけである。有線の追加はすべて小さな建設プロジェクトだからだ。
すべてのユースケースがLoRaWANに適するわけではない。次の5つは2026年において明確な経済性とともに繰り返し検証されている。
| ユースケース | 典型的な報告間隔 | 遅延要件 | ダウンリンクの必要性 | カバレッジ難易度 | 電池寿命の期待値 |
|---|---|---|---|---|---|
| サブメータリングとエネルギー | 5～15分 | 中（分単位の遅延は許容） | 低 | 高（ライザー、地下） | 主に電源駆動 |
| 室内環境品質（IAQ） | 5～15分 | 中 | 低 | 低（室内） | 4,000 mAhで約5年 |
| 漏水検知 | イベント駆動＋15分ハートビート | 高（分単位の警報） | 低 | 高（機械室、ライザー） | 3～5年 |
| 空間利用と在室状況 | 5～15分 | 中 | 低 | 低 | 3～5年 |
| 設備状態と予知保全 | 15～60分 | 低 | 中（閾値設定） | 中程度（工場フロア、屋上） | 主に主電源駆動 |
三つの明確化：
業界のコンセンサスは15分を開始間隔とし、60分で機能するなら15は使わないというものです。 これは保守主義ではなく、セクション5の容量計算から直接導かれるものです。地域の標準が5分の周期を要求する場合、北京の規則は 収集 頻度を規定しており、必ずしも 報告 頻度ではないことに注意してください。デバイスは5分ごとにサンプリングし、ローカルで集約して15分ごとに報告できます。この区別はコンプライアンスを議論する際に重要です。
「ダウンリンク必要」列はほぼすべて「低」であり、これは同時にLoRaWANの最大の構造的利点であり、最大の構造的リスクでもあります。 利点が存在するのは、ビルモニタリングが主にテレメトリだからです。リスクは、プロジェクトが後から制御要件（バルブの開閉、照明の切り替え、設定値の調整）を追加したときに現れます。ダウンリンクの負荷が突然現れ、ネットワークはダウンリンク予算を考慮して設計されていなかったのです。
一つの具体的な事例が経済性を示しています。ドバイの商業ビルがLoRaWANスマート照明制御を導入し、 25%の照明エネルギー消費削減を一ヶ月以内に達成し、月間約11,000時間の照明稼働時間を節約しました。このような数値が測定可能になれば、投資回収は数ヶ月単位で計算されます。
これはあらゆるビル無線プロジェクトにおける最初の罠であり、最も高くつくものです。
LoRaはサブGHz帯で動作し、2.4 GHz Wi-FiやZigbeeよりもはるかに透過します。「はるかに良い」は「常に」を意味しません。実測値：
| 材料 | 厚さ | 単層減衰 |
|---|---|---|
| 標準レンガ | 89 mm | ~3.5 dB |
| 標準レンガ | 178 mm | ~5 dB |
| 標準レンガ | 267 mm | ~7 dB |
| コンクリート | 102 mm | ~12 dB |
| コンクリート | 203 mm | ~23 dB |
| コンクリート | 305 mm | ~35 dB |
| 鉄筋コンクリート | 89 mm | ~27 dB |
| コンクリート（減衰係数） | — | 8–12 dB/m |
| 金属ダクト＋滞留水 | — | 10 mあたり−25〜−30 dB |
これらの数値をリンクバジェットと並べれば、結論は明白です。
22 dBmの送信電力と−148 dBmの感度（理論限界）では、LoRaは 理論上 3–5枚の標準レンガ壁、または1–2枚のコンクリート壁を透過できます。しかし「理論限界感度」はSNRがほぼゼロでパケットエラー率が極端であることを意味します。エンジニアリング実務ではマージンが必要であり、現実的に使用可能な透過量はおよそその半分です。
そして実際の建物では： 壁を一つだけ越えることはほとんどありません。
三階のオフィスのセンサーと一階の弱電室のゲートウェイの間では、オフィスの間仕切り→廊下→コンクリート床スラブ→別の廊下→遮蔽された機械室の扉を通過するかもしれません。四〜五層の減衰層が容易に60 dBを超えて積み重なり、リンクバジェットを完全に破壊します。
壁やスラブ以外にも、サブGHzに対して特に敵対的な三つの構造があります：
金属製HVACダクト。 金属は天然のRFシールドです。吊り天井上の金属ダクトの列は不規則な反射面と予測不能なデッドゾーンを生み出します。ダクトに隣接する天井裏に設置されたデバイスは、自由空間値の数倍の減衰を経験する可能性があります。
エレベーターシャフト。 鉄筋コンクリートの囲い＋金属製かご＋垂直に連続する構造：遮蔽と反射の組み合わせ。エレベーターシャフトに隣接する部屋は典型的なカバレッジの空白地帯です。
Low-Eガラスカーテンウォール。 省エネビルでは低放射率コーティングガラスが広く使われており、その金属層は通常のガラスよりもはるかにRFを減衰させます。これにより直感に反する結果が生じます： 建物のエネルギー評価が高いほど、屋内無線カバレッジは難しくなります。 エネルギー効率に最適化する建物は、知らず知らずのうちにあなたの信号も最適化して消してしまうのです。
電気室や変電所にも注意してください。これは減衰の問題ではなく周囲ノイズの問題です — 受信機のノイズフロアを上昇させます。
冒頭の測定と他の業界テストを組み合わせると：
| テスト | 構成 | 結果 |
|---|---|---|
| 台湾のオフィス、実測 | 1Fのゲートウェイ、同じフロアの65 mのセンサー | 安定、信頼性の高いテレメトリ |
| 台湾のオフィス、実測 | 1Fのゲートウェイ、2F（1階上）のセンサー | 機能するがマージン減少、障害物に敏感 |
| 台湾のオフィス、実測 | 1Fのゲートウェイ、3F（2階上）のセンサー | 大幅な劣化、顕著な損失、 本番運用不可 |
| Robustel / Voytechビルプロジェクト | 三階建てオフィス、200以上のセンサー | 導入成功 |
| Robustel / Voytech概念実証 | 14フロア間の通信 | 達成可能（PoC条件であり、本番環境での保証ではありません） |
| 屋内単一フロアのリファレンス設計 | ゲートウェイは天井中央、2.5～3 m | 半径30～50 m、<100ノードに適しています |
| 多層階のリファレンス設計 | 各フロアに1台、廊下・共用部の天井 | フロア間の透過を避け、フロアごとに独立管理 |
一見すると、14フロア間の通信と「2階上では使えない」は矛盾しているように見えます。しかし矛盾していません。 PoCと本番環境の違いはマージンです。
PoCでは、ゲートウェイとセンサーの位置を意図的に選び、障害物を避け、最良の経路を取ることができます。本番環境では、センサーの位置は業務要件によって決まります。漏水センサーはライザー内に置かなければならず、IAQセンサーは呼吸高さに置かなければなりません。選択の余地はありません。PoCは何かが 物理的に可能であることを証明します。本番環境ではそれが 最悪の位置で動作する必要があります。
したがって、業界の経験則は次のとおりです。
多層階の建物では、フロアごとにゲートウェイを1台配置する。これは過剰設計ではなく、「最悪の地点でも必ず接続できなければならない」という条件をアーキテクチャに書き込むことである。
非常に高い建物や、極端に厚い鉄筋コンクリートスラブの場合、密度を2～3フロアにつきゲートウェイ1台まで高める必要があるかもしれません。
業界で広く流布している一文は覚えておく価値があります。
「屋上に設置した500ドルのLoRaWANゲートウェイは、地下室に隠した2,000ドルのユニットより優れた性能を発揮します。」
設置に関するガイダンス:
よくあるアンチパターン：電源とイーサネットが既にあるという理由で、すべてのゲートウェイを弱電室に置くことです。 建物プロジェクトでは、設置の容易さとカバレッジ品質がしばしば相反します。 まずカバレッジゾーンを定義し、次に各ゾーン内で電源、バックホール、アクセス許可も満たす位置を見つけてください。
これが、建物プロジェクトが「動作している」状態から「不安定」な状態へ移行する最も隠れた理由です。容量の議論のほとんどはアップリンクのみを数えています。ダウンリンクが先に壁にぶつかります。
LoRaWANゲートウェイは送信中は聞こえません。ダウンリンクを送信した瞬間、アップリンクを受信できません。
したがって、すべてのダウンリンクフレームは 2倍のコストがかかります：
一般的な8アップリンク／1ダウンリンクのゲートウェイアーキテクチャでは、ダウンリンクリソースはすでにアップリンクより一桁希少です。
第一：確認付きアップリンク。 すべての確認付きアップリンクはダウンリンクACKを必要とします。確認付きアップリンクをデフォルトのままにしているチームは、実質的にゲートウェイが受信するすべてのメッセージに対して1回送信するようにしており、これは業界で最もよくある自ら招いた容量問題です。
定期的なセンサーテレメトリでは、 確認付きアップリンクが正当化されることはほとんどありません：温度の読み取り値を1つ失っても、次は15分後に届きます。これをオフにすると、ダウンリンク負荷を一桁削減できます。
第二：ジョインストーム。 すべてのJoin Acceptはダウンリンクです。現場の停電後、すべてのデバイスが同時に再ジョインを試み、各ジョインにはダウンリンクが必要で、ゲートウェイはデューティサイクル制限を守りながら1つずつ送信します。 五分間の停止が一時間の復旧作業になり得る。
解決策はファームウェアにあります。再ジョインのバックオフをランダム化する必要があります。これを後から発見するのではなく、調達文書で指定してください。
第三：MACコマンド、ADR調整、設定プッシュ、ファームウェア更新。 すべてダウンリンクです。FUOTAは極端なケースです。LoRaWANマルチキャストで配信される50～100 KBのファームウェアイメージは、通常 数時間から数日かかります。これらはトラフィックの少ない時間帯にスケジュールしてください。
LoRaWAN容量の台帳の核心は1つのルールです： スプレッディングファクターの段を一段下るごとに、デバイスのエアタイムコストはほぼ倍増します。
| データレート | 感度（参考） | レート（参考） | 相対エアタイムコスト |
|---|---|---|---|
| SF7 | −124 dBm | ~5.4 kbps | 1×（基準） |
| SF12 | −137 dBm | ~0.25 kbps | 8～32× |
15分ごとに報告する20バイトのペイロードの容量（理論上の単一ゲートウェイ上限）：
| データレート | 間隔 | ゲートウェイあたりのデバイス数（理論上の上限） |
|---|---|---|
| SF7 | 15分 | ~18,000 |
| SF9 | 15分 | ~5,400 |
| SF10 | 15 分 | ~2,900 |
| SF12 | 15 分 | ~700 |
| SF9 | 60 分 | ~21,000 |
| SF12 | 60 分 | ~2,900 |
この表は、ビルプロジェクトにおける中心的な緊張関係を説明している。 ビル内で最も信号が悪い場所、すなわちライザー、地下階、機械室は、まさに ADR が SF10–SF12 へと押し下げる場所である。そして SF12 デバイス 1 台は、8–32 台の SF7 デバイスと同じだけのエアタイムを消費する。
したがって、直感に反する結論が導かれる。 ビルネットワークにおける容量のボトルネックは、通常「デバイスが多すぎる」ことではなく、「信号の悪いデバイスの割合が高すぎる」ことである。
言い換えれば—— カバレッジの問題と容量の問題は、同じ問題である。 デバイスを SF7–SF9 まで下げられるよう適切に配置されたゲートウェイは、利用可能な最も効果的な容量拡張手段であり、より多くのチャネルを備えたゲートウェイを購入するよりもはるかに効果的である。
| ノイズフロアの上昇 | 影響 |
|---|---|
| +1 dB | 顕著 |
| +3 dB | 実効到達距離が半減 |
| >6 dB | 深刻な性能影響 |
ビル内では、ノイズフロアは Wi-Fi、BLE、他のサブ GHz デバイス（アクセス制御、ワイヤレスメータリング、インターホン）、および電気機器からの広帯域ノイズによって引き起こされる。別のベンダーの独自仕様の LoRa メータリングネットワークが同じビル内ですでに稼働している場合、あなたのゲートウェイはエアタイムをめぐって恒久的にそれと競合することになる。
これはプロジェクト評価の際に測定すべきである。 15 分間のバックグラウンドノイズスキャンを行えば、後になって何か月も原因不明のパケット損失を調査する事態を防げる。
ヘント大学の研究は、正直な数値を示している。 1,000 台のノードが最大 1% のデューティサイクルで送信する場合、単一ゲートウェイでのパケット損失は 32% に達することがある。
これは LoRaWAN の欠陥ではなく、免許不要スペクトルの物理的現実である。そこから示唆されるのは、 実際の単一ゲートウェイの上限は、計算式から導かれる数値よりかなり低いということである。 余裕（ヘッドルーム）とマルチゲートウェイによるカバレッジは、選択肢ではなく必須である。
よくある誤判断：RF 調査で全 RSSI 値が範囲内に収まっているため、ネットワークは問題ないと見なされる。半年後、ランダムなパケット損失が現れる。
見落とされがちな三つの変数が、それを説明する。
広く引用される「ゲートウェイあたり 500–2,000 ノード」という数値には、非常に具体的な前提が埋め込まれている。すなわち、SF の混合分布、低い報告頻度、最小限のダウンリンクである。
これらの前提を取り除けば、数値は直ちに変わる。より正直な比較は次のとおり。
| デバイスプロファイル（20 バイトのペイロード） | ゲートウェイあたりのデバイス数 |
|---|---|
| SF7、15 分に 1 回 | ~18,000 |
| SF9、15 分に 1 回 | ~5,400 |
| SF12、15 分に 1 回 | ~700 |
| SF9、1 時間に 1 回 | ~21,000 |
| SF12、1 時間に 1 回 | ~2,900 |
同じハードウェアが 700 から 21,000 にまたがる。 「1 台のゲートウェイで何台のデバイスを扱えるか」は、報告間隔と SF 分布を特定するまで答えは出ない。
この誤解は広く蔓延しており、高くつく。
LoRaWAN のアーキテクチャでは、送信を聞き取ったすべてのゲートウェイがそれを転送し、ネットワークサーバーが重複を破棄する。したがって、2 台のゲートウェイが同じエリアをカバーする場合：
容量はゲートウェイの台数ではなく、地理的な分離に比例して拡大する。 2 台のゲートウェイが 2 つのエリアをカバーすれば、容量はほぼ倍になる。2 台のゲートウェイが 1 つのエリアをカバーする場合、主に保険を買うことになる。
唯一の例外はチャネル数である。64 チャネル構成（US915/AU915）では、ゲートウェイは異なるサブバンドで動作でき、デュアルコンセントレータを備えた 16 チャネルゲートウェイは真に 2 つの並列経路を提供する。CN470 や EU868 のような狭帯域はこの論理に従わない。
そしてもう一つ： チャネルを所有することは決してない。 同じビル内の他の LoRaWAN ネットワーク、他の事業者のデバイス、そして免許不要帯のすべての利用者が同じエアタイムを消費する。これは自分の容量計算には決して現れないが、都市部の混雑した地域では相当な割合を占めることがある。
これがビルと他の IoT シナリオを分ける決定的な違いである。
プロジェクトは 15 分のハートビートで 40 台の漏水センサーから始まるかもしれない。2 年後、運用チームは 60 点のサブメータリング、80 台の IAQ センサー、30 台のドアコンタクト、20 台の在室センサーを追加している。 密度は五倍に増加し、ネットワークは40のポイント向けに設計されていました。
当初の設計に余裕が残されていなければ、ある日ネットワークは「管理が難しい」ものになり、「LoRaWAN は信頼性が低い」という評価に結び付けられる。
正しいアプローチは、設計時に三つのことを定義することである。
最初の三つのボトルネックは技術的であり、エンジニアリングで解決できる。四つ目は組織的なもので、より致命的である。
業界データ： 企業の IoT プロジェクトのおよそ 70% はパイロット段階から抜け出せない。 原因はほとんど技術ではない。
次のようなものだ：
PoCは成功した。1棟の建物、10個のセンサー、ダッシュボードに流れるデータ、関係者も感銘を受けた。予算は全額承認：12拠点に500台のデバイス。
6か月後、プロジェクトは停滞している。10個のセンサーを処理できたゲートウェイでは、そのトラフィックを処理できない。パイロット用ハードウェアを販売したベンダーはボリューム価格を提示しない。ITはRaspberry Pi上でプロトタイプしたネットワークアーキテクチャを承認しない。拠点#4の施設チームはアンテナ用の屋上アクセスを拒否する。
これがパイロットの煉獄だ。それはほとんど常に4つの予測可能な失敗から構成される。
ほとんどのPoCは「技術が機能することを証明する」ことを目的とするため、意図的に好条件を選ぶ：単一拠点、協力的な施設管理者、見通し線内のセンサー、ITセキュリティは「一時的なテスト」として通過、スプレッドシートへの手動エクスポート。
これらのいずれも本番には通用しない。
建設的なアプローチは、PoCに本番の問題を露呈させることだ。
PoCが問題を露呈しないなら、それは何もテストしていない。
3つの一般的な形態：
| PoCの実践 | 本番要件 | 移行コスト |
|---|---|---|
| Raspberry Pi上のネットワークサーバー | 冗長性、バックアップ、監視が必要。適切にサイジングされたサーバー（2–4コア、8 GB RAM、SSD）上のChirpStackは数千台のデバイスを確実に処理する | 移行は容易だが、最初から計画する必要がある |
| 単一ゲートウェイ | N+1の冗長性が必要。そのゲートウェイが2 AMにオフラインになると — 電源、Ethernet、またはハードウェア — その背後のすべてのセンサーが暗くなる | 配置計画のやり直しが必要 |
| FUOTAパスなし | ファームウェア更新が必要：バグ修正、セキュリティパッチ、プロトコル変更 | FUOTAがないということは、500台のデバイス → 500回の現場訪問 |
最後のものは致命的だ。選定時にFUOTAサポートを確認し、PoC中に完全な更新フローをテストすること。
| 次元 | PoC段階 | 本番段階 |
|---|---|---|
| 価格設定 | 販売店在庫、クレジットカード | 企業調達が発動；ボリューム価格は自動的に適用されない |
| リードタイム | 数日 | 8–16週間（部品不足時はさらに長い） |
| 認証 | 誰も尋ねない | ITとコンプライアンスが尋ねる：CEマークはあるか？サイバーセキュリティ要件は？サプライチェーンの信頼性は？ |
桁数は計算する価値がある：EUR 80のセンサーは500個でEUR 55に下がるかもしれない — あるいは下がらないかもしれない。500個 × EUR 25の差 = EUR 12,500。その数字はハードウェアプラットフォームにコミットする 前に 交渉されなければならない、後ではなく。
建物プロジェクトに対する業界推奨の3フェーズモデル：
| フェーズ | 範囲 | デバイス | 期間 | 目的 |
|---|---|---|---|---|
| フェーズ1 — 概念実証 | 1フロアまたは1建物ゾーン | 10–20 | 4週間 | RFカバレッジ、ゲートウェイ配置、BMS統合を検証 |
| フェーズ2 — パイロット | 3–5フロアまたは1棟全体 | 50–100 | 8週間 | スケーリング、実際のバッテリー寿命、ダッシュボードの使いやすさ、FMワークフローを検証 |
| フェーズ3 — 完全展開 | 建物全体またはキャンパス | 200–2,000+ | 12–24週間 | 本番ロールアウト、フロアごとに段階的に |
フェーズ2の検証項目に注目：「バッテリー寿命」と「運用ワークフロー」は パイロットでのみテストできる。 PoCではそれらを測定できない。まさにそれがフェーズ2が存在する理由だ — それは「より大きなPoC」ではなく、 異なる種類 のテストである。
| 指標 | 目標 |
|---|---|
| アップリンク成功率 | >98% |
| 限界リンク閾値 | RSSI < −130 dBmは限界と見なす；ゲートウェイを追加するか移設する |
日次監視：デバイスのアップリンク健全性（予想間隔の2倍を超えてアップリンクがない場合はアラート）、ゲートウェイのオンライン状態、バッテリー電圧の傾向。月次：ネットワークKPIとデータ完全性（予想データポイント対受信）。
上記のすべてを、設計文書にそのまま入れられる8つのルールに凝縮した。
ルール1：まずビジネス成果を定義し、次にセンサーリストを定義する。
「どのセンサーを買うべきか」から始めないでください。まず、施設チームが何を 見る、自動化する、または防ぐ必要があるのかを答えることから始めます。
この二つの目標は、まったく異なる報告間隔、レイテンシ要件、屋内配置を意味します。同じ床面積の二つの建物 — 一方は毎時の環境データを必要とし、もう一方はほぼリアルタイムのアラーム状態を必要とする — は、ネットワーク設計において二倍の差が生じ得ます。
ルール 2: ゲートウェイの配置は階数ではなく伝搬ゾーンで計画する。
建物のRFゾーンは、コンクリートコア、スラブ厚、金属ダクトの配管経路、エレベーターシャフトの位置、Low-Eカーテンウォール、技術室の境界によって決まります — 間取り図をそのまま写すことでは決まりません。
800 m²のフロアが二つのコンクリート壁で三つの区画に分かれている場合、ゲートウェイが二台必要になることがあります。3,000 m²のオープンプランオフィスなら一台で足りることがあります。
ルール 3：フロアごとにゲートウェイ1台が基準であり、最終目標ではありません。
これをデフォルト構成として扱います。そのうえで、追加の密度について以下をそれぞれ評価します:
ルール 4: 15分間隔から始め、60分で機能するなら15は使わない。
15分から60分に移行すると容量は四倍になり、建物監視のユースケースの大多数では運用上の違いはまったくありません。
5分の収集要件があるプロジェクトでは、ローカルで5分のサンプリングを行い、15分の集約レポートを使用します。
ルール 5: 確認付きアップリンクをオフにする。
定期的なテレメトリでは、ダウンリンクの増幅効果が信頼性の利点をはるかに上回ります。確認付きアップリンクは「一つ失うと何かが壊れる」というイベントメッセージ用に取っておきます。
ルール 6: アップリンクの送信時刻をランダム化する。
デバイスが毎正時に一斉に報告するのを防ぎます。これにはコストがかからず、多くの人が期待する以上の効果をもたらします。
ルール 7: 重要なゾーンで20–30%のカバレッジオーバーラップを確保する。
すべての場所ではなく、「このメッセージを失うとインシデントになる」ゾーン（漏水、冷蔵・冷凍、機械室）には第二の受信ポイントを設けるべきです。これは 冗長性であり、 容量 ではないことに注意してください — 容量予算に含めてはいけません。
ルール 8: 最小カバレッジではなく、N+1台のゲートウェイを予算計上する。
予算は必要ゲートウェイ数 + 1として提出します。余分な一台はホットスペアであると同時に、将来の密度向上の出発点となります。
ManThinkの屋内ゲートウェイポートフォリオは、すべてのケースに対応する単一製品ではありません。 建物内の設置条件によって区分された四つのラインです。
| 製品 | 位置づけ | 主な違い | 電源と取り付け | 適した建物シナリオ |
|---|---|---|---|---|
| GD61x (GD614 / GD618) | ESP32-S3 オープンソース屋内ゲートウェイ | 選択可能な SX1301 または SX1302 コンセントレータ、Ethernet / Wi-Fi / オプションの 4G、および G 構成には4GモジュールとPoEモジュールが含まれる |
Type-C 5 V / DC 5–24 V / PoE (G); 単一の外部LoRaアンテナ |
オフィス、ビル、キャンパス、機械室、小規模産業サイト; 開発者やインテグレーターの自作向け |
| GDI51 / GDI52 | ThinkLink内蔵の屋内ゲートウェイ | GDI52は産業向けバリアント: アルミ筐体、RS-485を追加、DC 5–24 Vの広入力 | GDI51: PoE / Type-C; GDI52: DINレール取り付け | キャンパス、タワー、ビル; GDI52は弱電室内のDINレールキャビネットに適する |
| GD73 | 高性能屋内マルチチャネルゲートウェイ | SX1302、≥8アップリンクチャネル、8周波数ポイント、16復調器; 感度 −141 dBm (SF12、BW 125 kHz); 送信電力 27 dBm (-1) / 22 dBm (-2); TKL LoRaWANネットワークサーバーとIoTプラットフォームを内蔵 |
PoE / Type-C / DC 5–24 V; DINレール; デュアルゲートウェイ冗長アーキテクチャをサポート | 大規模ビル、キャンパス、産業サイト、スマートプロパティ; エッジコンピューティングとローカルプラットフォームが必要 |
| GDO51 | IP67 屋外ゲートウェイ | 最大16周波数ポイント / 32チャネル | PoE | 屋上、キャンパス外部、建物の外皮を越えてカバレッジを拡張 |
選定ロジックは三つの文に集約されます:
建物の改修では、最も高価な項目はしばしばワイヤレスセンサーではなく、 既存の有線メーターをどうオンライン化するかです。
ManThinkのアプローチでは、DTUを使って有線プロトコルをLoRaWANに変換します:
| 製品 | 電源 | 取り付け | インターフェース | 典型的なシナリオ |
|---|---|---|---|---|
| KC11 | AC 85–270 V | DINレール | RS-485 | 主電源給電の弱電室シナリオ、大規模な既存メーター・計器の後付け改修（100,000台超を導入済み） |
| KC25 | DC 5～24 V | DINレール | RS-485 | EdgeBusとFUOTAをサポート |
| KC21 | バッテリーまたは外部電源 | スタンドアロン | RS-485 | IP65、屋外および過酷な環境 |
統合パスは標準的な三段階のチェーンです。実際の例：
Renke UMxTH4xCN8F0温湿度トランスミッター（RS-485 / Modbus RTU）→ KC11主電源給電DTU（LoRaWAN Class C）→ ThinkLinkプラットフォーム
このパスのエンジニアリング上の価値： 建物内に既にある有線資産を保持し、最後のホップのみを無線に置き換えます。 弱電室内のRS-485台のメーターは撤去も再配線も不要です。DINレールDTUが無線変換を完了します。
| ユースケース | 製品 | 備考 |
|---|---|---|
| 温湿度＋水漏れ | KS52 | ポイント型またはロープ型の漏液検知 |
| 温度（単一点） | KS53 | DS18B20またはプローブなしのバリエーション |
| 水漏れ（スタンドアロン） | KS51 | ポイント型またはロープ型、バッテリーまたは外部電源 |
| 室内空気質 | KS61 | 86ボックス形状、4-in-1または7-in-1（温度 / 湿度 / TVOC / 照度 / CO₂ / PM2.5 / 照明制御、個別に有効化可能） |
| アナログ入力 | KS31 | 4チャンネル 4～20 mA または 0～10 V |
| デジタルステータス | KS32 | ドライ接点デジタル入力 |
KS61の「機能有効化ビット」設計に注目してください。各パラメーター（温度、湿度、TVOC、照度、CO₂、PM2.5、照明制御）はビット設定により個別に有効化または無効化できます。これはコンプライアンスのシナリオに有用です： 北京市の5分間収集要件の対象となるプロジェクトでは、エネルギー指標の計算に参加するパラメーターのみを有効化し、報告負荷を抑えてください。
GD61xは建物全体のソリューションではありません。
その設計境界は明確です。単一の外部LoRaアンテナ、屋内向け、開発者とインテグレーター向けのオープンプラットフォームです。適するのは 自社構築・カスタム オフィス、ビル、キャンパス、機械室、小規模産業サイトにおけるシナリオです。
もし必要なのが：
選定の最初のステップは仕様の比較ではありません。それは 自分でどこまで構築するつもりかを明確に述べることです。
四つの文で記事全体を要約できます：
LoRaWANはすでに建物における主流の選択肢です。 1億2500万台の導入済みデバイス、年間25%の成長、建物向けの主要な無線技術としてLoRa Allianceが確認済み。その原動力は技術的な目新しさではなく、三つの事柄が同時に到来したことです：規制の期限、改修の経済性、エコシステムの成熟。
技術的なボトルネックには単一の根本原因があります：マージンです。 透過損失、拡散因子の上昇、増幅されたエアタイムコスト、上昇するノイズフロア——これらはすべて同じ現象です。建物環境はリンクマージンを消費します。建物の無線設計作業は、根本的にはそれを回復することにほかなりません。
エンジニアリング上の答えは、ゾーニング、報告頻度の低減、確認付きアップリンクの無効化、冗長性の追加です。 いずれもより高価なハードウェアを必要としません。必要なのは設計を正しく行うことです。
本当の崖は技術的ではなく組織的なものです。 プロジェクトの70%はPoCと本番の間で消えます——ITセキュリティレビュー、調達価格、設置許可、運用の責任者によって潰されます。PoCで問題が表面化しなかったなら、それは何もテストしていません。
これで冒頭の数字に戻ります。
1階から3階へ、65メートルが「使用不可」になりました。この結果を繰り返す価値があるのは、悲観的だからではなく、それが 計算可能だからです。建物の無線には屋外カバレッジのような大きな不確実性がありません——壁はそこにあり、スラブの厚さは図面にあり、材料の減衰には実測値があります。つまり 設計時に真剣なゾーニングとマージン計算を行えば、カバレッジ問題の圧倒的大多数を事前に排除できます。
建物がLoRaWANの最良の応用シナリオの一つであるのは、まさにそれが不寛容だからです。建物はエンジニアリングチームにあらゆるパラメーターを適切に計算することを強います。
| 用語 | 定義 |
|---|---|
| LPWAN | Low-Power Wide-Area Network（低消費電力広域ネットワーク）。低消費電力、広カバレッジ、大規模接続密度を特徴とする。ライセンススペクトル（NB-IoT / LTE-M）と非ライセンススペクトル（LoRaWAN / Sigfox）に分かれる |
| LoRaWAN | LoRa物理層上に構築されたオープンなMAC層プロトコルで、LoRa Allianceが維持管理する。スター型トポロジー。ゲートウェイ同士は中継しない |
| SF（拡散因子） | 値はSF6～SF12。SFが高いほど到達距離が長く干渉耐性も向上するが、データレートが低下しエアタイムが増加する |
| ToA（Time on Air） | 単一フレームがチャネルを占有する時間 |
| ADR | Adaptive Data Rate（適応データレート）。ネットワークはリンク品質に基づいてデバイスのSF、送信電力、再送回数を調整する |
| BACS | Building Automation and Control System（ビルオートメーション・制御システム）。EUのEPBDにより大規模非住宅建築物に義務付けられている |
| BMS | Building Management System（ビル管理システム） |
| BACnet | ビルオートメーションにおける支配的なオープン標準プロトコル。BMSエコシステムのデファクトスタンダード |
| KNX | 欧州のビル制御バス標準。KNX TP1 はツイストペア物理層 |
| M-Bus | メーターバス。熱量計、水道メーターなどの計量デバイスに一般的に使用される |
| BACS法令（フランス） | フランスの義務的なビルオートメーション要件。建物エネルギー消費の削減を段階的に導入 |
| EPBD | 建築物のエネルギー性能指令。改正版 (EU) 2024/1275 は 2026-05-29 までの国内法化を要求 |
| FUOTA | ファームウェア無線更新。LoRaWAN 1.1+ および一部の 1.0.4 デバイスでサポート |
| MACコマンド | LoRaWANプロトコル層の管理命令。ダウンリンクで伝送される |
| 確認付きアップリンク | ネットワークACKを必要とするアップリンク。1回ごとにダウンリンクを消費する |
| ノイズフロア | 受信機における周囲ノイズレベル。3 dB の上昇で実効距離が半減する |
| フレネルゾーン | 直接RF経路の周囲の楕円体領域。見通しが確保されていても、この領域に侵入する物体は干渉を引き起こす |
標準および規制
業界データ
技術測定およびエンジニアリング参考文献
ベンダードキュメント
関連記事