シリーズ注記：これはManThink LoRaWAN技術深掘りシリーズの第10部です。これまでに物理層パラメータ、SF/BW/CRのトレードオフ、Class A/B/C、SX1301/1302/1303の系譜、ゲートウェイホストとしてのESP32-S3、TDOA/RSSI測位、そして3つのバックホールプロトコル（Basic Station / UDP / MQTT）を扱ってきました。本記事は、最も頻繁に尋ねられ、最も頻繁に誤って答えられるエンジニアリング上の問いに立ち返ります： 1台のゲートウェイで何台のエンドデバイスを収容できるのか？

変わり続ける数字

「御社のゲートウェイは何台のデバイスを処理できますか？」

これはあらゆるLoRaWANソリューション会議で最初に尋ねられる質問であり、あらゆる調達担当者の表計算で最初に埋められるセルです。答えはどの製品データシートにも載っていません。なぜなら、実展開における同じゲートウェイが対応できるのは 700台のデバイス であったり、 20,000であったりするからです。ハードウェアは変わっていません。変わったのは展開条件だけです。

これはベンダーの誇張ではありません。SX1302ゲートウェイは、特定の前提条件の下では確かに数万台のセンサーを収容できます。ただ、その前提条件が明示されることはほとんどありません。だからこそ、同じハードウェアが正直に2桁の範囲にわたる展開を支えるのです。違いはゲートウェイではありません。主に カバレッジです。

本記事はゲートウェイ容量を解き明かします。ハードウェアが与えるもの、ALOHAプロトコルが奪うもの、現場で実際に調整できるノブ、そして最後にすぐ使える推定式と3ステップの判断フローです。

1。ハードウェアが与えるもの

1.1 SX1302コンセントレータ：8チャネル × 16復調器

現代のLoRaWANゲートウェイは、ほぼ例外なくSemtech SX1302コンセントレータを中心に構築されています。容量について語るには、まずこのチップの内部を見る必要があります。

Semtech公式SX1302データシートより：

• 8 × 125 kHzの周波数チャネル：8個の同時受信センター
• 16個のLoRa復調器、2つのグループに分かれます：
• 8が対応 SF5–SF12 （長距離・低レート層）
• 8が対応 SF5–SF10 （短距離・高レート層）
• 1 125 / 250 / 500 kHzの高帯域幅LoRa復調器
• 1 (G)FSK復調器 （レガシー互換）
• 最大 65個の設定可能な論理チャネル

感度 -141 dBm SX1250 RFフロントエンドを備えています。消費電力は前世代のSX1301と比べておよそ一桁低くなっています。

重要な洞察：8個の周波数チャネルと16個の復調器は 共有されており、1対1で結びついているわけではありません。同じ周波数チャネルでもSFが異なれば、異なる復調器で並列に復調できます。周波数チャネルもSFも異なる場合も、もちろん同様です。

しかし 16は大きな数ではありません。17番目のパケットが到着すると、それは黙って破棄されます。キューイングも再送要求もありません。SX1302の同時処理の上限はまさにここで終わります。

まさにここでSX1303がもう一線を引きます。その Fine Timestamp 機能を有効にすると、同時処理の上限が16から8に下がります。本シリーズの第8部を参照してください。

1.2 「復調器の飽和」が実際にどう見えるか

実際の展開では、ゲートウェイ容量が復調器で制限されることはほとんどありません。制限するのは エアタイムです。

これを直感的に理解するため、13バイトのペイロード、BW=125 kHz、CR=4/5の実測エアタイムを示します。これらはSemtechの内部RF物理モデルを用いたSemtech公式LoRa計算機による実際の数値です：

SF12の1台のデバイスは、SF7の25台のデバイスと同じだけのネットワークリソースを消費します。ペイロードは同一です。違いは、どれだけ遠くにあるか、あるいはリンクがどれだけ悪いかだけです。

これが、LoRaWANエンジニアリングにおいて真の容量指標がデバイス数ではなく SF分布である理由であり、カバレッジが良ければ容量が無償で増える理由です。ハードウェアをアップグレードしたからではなく、フリートに占めるSF7/SF8の割合が増えたからです。

2。ALOHA：あらゆる推定の出発点

2.1 LoRaWANアップリンクはALOHAチャネルである

LoRaWANデバイスは送るべきものがあるときに話します。スケジューリングもチャネル予約もなく、ほとんどの地域ではlisten-before-talkもありません。このためアップリンクチャネルは 本質的にALOHAチャネルです。

ALOHAには不快な性質があります： スループットは提供トラフィックとともにある点まで上昇し、その後下降する。横ばいになるのではなく、下降します。ピークを過ぎると、より多くの送信がより少ない受信成功を生みます。衝突がパケットを破壊し、デバイスが再試行し、再試行がさらなる衝突を生むからです。

ピークは約 18%のチャネル利用率で発生します。この数値を超えると、ネットワークは「正常動作」から一気に「デバイス故障のように見える」状態へと移行します。

LoRaWANは容量限界で緩やかに劣化することはありません。動作しているかと思えば、突然崩壊します。この崩壊モードは監視ダッシュボード上では「ゲートウェイ満杯」ではなく「ランダムなデバイスドロップアウト」として現れます。だからこそ、多くのフィールドエンジニアがボトルネックを見つけられないのです。

2.2 キャプチャ効果：6 dBが1パケットを救う

ALOHAは完全に絶望的ではありません。LoRaには キャプチャ効果があります。同じチャネルと同じSFで2つのパケットが衝突したとき、 強い方のパケット（もう一方より約6 dB上）は依然としてデコード可能です。

つまり、デバイスがパスロス勾配に沿って分散している適切に計画されたネットワークは、教科書的なモデルを上回る性能を発揮します。また、これが 優れたカバレッジ計画が無料の容量増加に等しい 理由でもあります。キャプチャ効果が機能するには、デバイスが勾配に沿って分散している必要があります。

しかしキャプチャ効果は 曲線の形状を変えることはなく、わずかに右へ押し出すだけです。

2.3 SFコスト曲線

上記の数値を「1時間あたりのチャネル予算」（EU868、8チャネル）に換算します：

Hourly channel budget = 8 channels × 3600 seconds = 28,800 channel-seconds/hour
ALOHA usable budget   = 28,800 × 18% ≈ 5,200 channel-seconds/hour

それを各デバイスが1時間あたりに消費するエアタイムで割ると、理論上の容量が算出されます。ThinkLinkナレッジベースでは、13バイトのペイロード、8チャネルのゲートウェイ、1時間ごとのアップリンク間隔を前提として、以下の公式推定値を示しています：

注：これは 理論上の上限であり、衝突ゼロ、再送ゼロ、ダウンリンクゼロを前提としています。 実際の展開容量は通常、理論値の30～50%です 。だからこそ、パンフレットにある「チャネルあたり数十万台」という主張が現場で実現されることはほとんどないのです。

3. 容量を実際に左右する変数

3.1 アップリンク／ダウンリンクの非対称性

LoRaWANで最も直感に反する設計上の選択は、その アップリンク／ダウンリンクの非対称性です：

• アップリンク：8の周波数チャネル＋16の並列復調器 — 設計上、多車線の高速道路
• ダウンリンク：通常 わずか1つの送信チャネル — 一車線の田舎道

つまり「ダウンリンクの輻輳」はLoRaWANのスケーリングにおける最大の隠れたリスクであり、小規模な展開ではほとんど現れません。1,000台のデバイスを超えると、ダウンリンクがボトルネックになり始めます。Join Accept、ACK、MACコマンド — すべてのダウンリンクトラフィックがこの単一の送信チャネルを通過しなければなりません。

3.2 SF分布：見落とされがちな中核指標

多くのチームはLoRaWANの負荷を「デバイス数」で評価します。これは間違いです。 正しい指標はSFで重み付けした総エアタイムです。

例：あるサイトに1,000台のデバイスがあり、そのうち200台がSF12に固定されています。それらの等価負荷はおよそ200 × 25 = 5,000 SF7台分のデバイスに相当します。このサイトは「1,000台のデバイス」というスプレッドシート上では「緑」に見えますが、ネットワーク層ではすでに「赤」です。

ネットワークがALOHA閾値にどれだけ近いかを知りたい場合、最も直接的な方法は、ネットワークサーバーのバックエンドで 過去24時間のSF分布ヒストグラム を見ることです。10%を超えるSF12のシェアは黄色信号であり、20%を超えるとカバレッジ最適化を行う時期です。

3.3 ペイロードサイズ：2つ目の見落とされがちな変数

13バイトのペイロードと50バイトのペイロードはSF12においてそれぞれ1155 msと2468 msかかります — 50バイトのパケットは2倍のエアタイムを消費します。

多くのチームは、タイムスタンプ、デバイスID、センサー値、バッテリー電圧、信号強度、ファームウェアバージョン、CRCなど、すべてを最初からワイヤに詰め込んでしまいます。 ペイロードの削減はスケーリングの最も安価な方法です — 50 バイトから 13 バイトに削減すると、同じ SF でエアタイムが半分になり、容量が倍増するのと同等です。

4. 実際に調整できる6つの容量ノブ

これらのノブはコストの低い順から高い順に並んでいます。 新しいハードウェアに投資する前に、必ず最初のいくつかを調整してください。

ノブ1｜ADR（Adaptive Data Rate）を有効にする

ADRはLoRaWANに組み込まれたレート適応メカニズムです。 ADRを無効にすることは容量を半分にすることと同じです — すべてのデバイスがデフォルトでSF12になり、SF7の25倍のエアタイムを消費します。

ADRを有効にすると、NSはリンクバジェットに基づいて各デバイスのSFを調整します。時間の経過とともに、SF7/SF8のシェアは大幅に上昇するはずです。

落とし穴：サーバー側のADRは 配信が遅延する 可能性があり、ダウンリンク負荷が高い状況ではデバイスがSF12に固定されたままになることがあります。 ローカルADR は、デバイスがローカルのRSSI/SNRに基づいて自己調整できるため、より信頼性が高いです。ManThink独自のEdgeBus（EB）ランタイムには、ローカルADRが標準で搭載されています。

ノブ2｜Confirmedアップリンクを控えめに使う

ConfirmedアップリンクはすべてダウンリンクACKを必要とします。ダウンリンクは一車線です。

重要でないデータ（温度、湿度、バッテリー電圧、定期的なハートビート）をConfirmedから Unconfirmedに移し、信頼性をアプリケーション層（リトライ、重複排除、集約）に引き上げます。これにより ダウンリンクトラフィックが大幅に削減され 、ダウンリンクのボトルネックを緩和する最も安価な方法となります。

ノブ3｜Joinのタイミングをずらす

「電源投入と同時に参加」は典型的なアンチパターンです。5,000 台のデバイスが大規模障害の後に 一斉に電源投入される 状況を想像してください。全デバイスが同じ秒に Join Request を送信し、下り方向の Join Accept チャネルが輻輳します。

正しい方法: - オンデマンド参加: N 回連続で上りリンクが失敗した後にのみ参加をトリガーする UTC ベースのランダム遅延: 各デバイスが pseudo_random_delay = (DevAddr & 0xFF) × 100 ms を用いて試行を分散させる

ManThink EdgeBus の参加保護はまさにこれを実現しています。組み込みのランダム遅延と参加リトライにより、大規模な電源復旧後の「参加アバランチ」を回避します。

ノブ 4 | カバレッジとゲートウェイ密度を適切に計画する

直感に反するものの繰り返し検証されている経験則:

過密 (同一エリア内の 3+ 台のゲートウェイがすべて同じパケットを受信) はハードウェアを浪費しますが、受信成功率の向上と引き換えになります。過疎はデバイスを高い SF に追いやり、ネットワークを崩壊させます。

ノブ 5 | ペイロードを削減・圧縮する

• アプリケーション層では必要なフィールドのみを送信し、冗長な ID やタイムスタンプを削除する
• 大きなデータブロックには差分圧縮を使用する (差分のみを送信)
• 複数の小さな測定値を 1 つの定期パケットに統合する
• バイナリは ASCII に勝る: "23.5" として int16 2 バイトを直接節約する

ノブ 6 | 「すべてをアップロード」ではなくエッジコンピューティングを使う

アラーム判定、しきい値フィルタリング、データ集約をゲートウェイまたはエンドデバイスに移す。 例外とサマリのみを送信する — これが LoRaWAN をスケールさせる真のキラー機能です。

ManThink EdgeBus (EB) はまさにこのために設計されています。低消費電力 MCU (Cortex-M0 で十分) 上でイベント駆動型のエッジコンピューティングロジックを実行し、「ほとんどの時間は上りリンクなし」を常態とします。これにより容量指標は「1 秒あたりのパケット数」から「1 日あたりの異常数」へと引き上げられます — まったく異なるスケールです。

5. すぐに使える推定式

5.1 3 ステップの推定フロー

ステップ 1 | デバイスごとの 1 時間あたりのエアタイムを計算する

T_airtime = packet_time(SF, payload_size)  // Use the Semtech LoRa calculator
T_device_hourly = (3600 / send_interval_sec) × T_airtime

ステップ 2 | ゲートウェイの 1 時間あたりのチャネル予算を計算する

B_gateway_hourly = 8 × 3600 × 0.18 = 5,184 channel-seconds/hour

ステップ 3 | 理論容量を計算し、50% の余裕を残す

N_max = B_gateway_hourly / T_device_hourly
N_recommended = N_max × 0.5

5.2 計算例

スマート農業の導入: - 1,000 台の土壌水分センサー - 10 分ごとに上りリンク - 8 バイトのペイロード (水分 + 温度) - ADR 有効時、推定 SF 分布: 60% SF7 / 25% SF8 / 15% SF9

実測エアタイム (8 バイト、BW125、CR4/5、Semtech 計算機): - SF7 ≈ 41 ms - SF8 ≈ 77 ms - SF9 ≈ 164 ms

加重平均エアタイム:

T_avg = 0.6 × 41 + 0.25 × 77 + 0.15 × 164 ≈ 69 ms

デバイスごとの 1 時間あたりの消費量:

T_device = (3600 / 600) × 0.069 = 0.414 channel-seconds/hour

理論上の単一ゲートウェイ容量:

N_max = 5,184 / 0.414 ≈ 12,500 devices

50% の余裕を残した推奨導入上限:

N_recommended ≈ 6,200 devices

1,000 台のデバイスはこの予算内で余裕があります。8 チャネルの SX1302 ゲートウェイ 1 台で十分すぎるほどです。

対比: カバレッジが悪く、すべてのデバイスが SF12 に留まる場合:

T_device = 6 × 1.155 ≈ 6.93 channel-seconds/hour
N_max = 5,184 / 6.93 ≈ 748 devices
N_recommended ≈ 374 devices

同じ 1,000 台のデバイスでも、カバレッジが悪いと 単一ゲートウェイでは負荷を支えられず、直ちに 2 台目のゲートウェイ (またはアンテナ配置の最適化) が必要になります。

6. ManThink GD6 / GDO51 による実践的な容量

6.1 GD6 オープンソースゲートウェイ

ManThink GD6 (ESP32-S3 + SX1302) は中小規模の導入向けに位置付けられています。典型的な用途:

• 1 棟の建物 (3–8 フロア) + 1–2 km² の屋外を単一ゲートウェイでカバー
• 推奨デバイス規模: 500–3,000 台/ゲートウェイ (ADR あり)
• ペイロードは 8–20 バイトに制限
• ローカル ADR + Unconfirmed + 参加保護を有効化

6.2 GDO518 商用ゲートウェイ

ManThink GDO518 商用屋外ゲートウェイ (SX1302、 16 周波数ポイント + 32 同時パケット復調): - 推奨デバイス規模: 5,000–20,000 台/ゲートウェイ - 大規模な都市規模の導入 (スマートシティ、スマート農業、資産追跡) に適しています - Docker 対応でゲートウェイ上で EB エッジコンピューティングを実行可能 - 外部 SIM スロット + デバッグシリアルポート — 保守のためにケースを開ける必要がありません

実際の事例: 中国江蘇省のスマート農業導入 — GDO518 ゲートウェイ 1 台で 8,000 台の土壌センサーを収容 (15 分間隔の上りリンク、6 バイトのペイロード、ADR 有効)、12 か月間安定稼働。

7. よくある 5 つの誤解

誤解 1: SX1303 は容量が大きい

誤りです。SX1303 は SX1302 とピン互換で復調器の数も同じですが、 Fine Timestamp を有効にすると同時接続の上限が 16 から 8 に低下します。SX1303 の真の価値は 測位精度にあり、スループットではありません。

誤解 2: 「接続デバイス数」は「収容デバイス数」を意味する

多くのベンダーは「この NS は XX0,000 台のデバイスを接続した」と宣伝していますが、それは単なる登録数です。 同時オンライン容量ではない。実際の容量はSFで重み付けされた同時負荷である。

誤解 3：スケールアップするには、ゲートウェイを増やせばよい

誤り。ほとんどのLoRaWANネットワークは、ADRの有効化、ペイロードの削減、ジョインの時間分散という三つのことだけで3～5倍にスケールアップできる。 ゲートウェイの追加購入は最初の手段ではなく最後の手段である。

誤解 4：デバイスが増えるほどClass Cが必要になる

誤り。Class Cは受信機を常時オンに保つため、その消費電流はClass Aのスリープ状態の1,000倍以上である。 大規模展開ではClass Aが主力である — 下り帯域は本質的に狭く、Class Aの「上り送信後のみRXウィンドウ」という仕組みは、まさにこの制約に適合している。

誤解 5：すべてのデバイスはConfirmed上り送信を使うべきだ

誤り。温度、湿度、バッテリー電圧、定期的なハートビート — これら 再送可能なデータ項目 にはUnconfirmedを使う。アラームや制御コマンドにはConfirmedを使う。下り帯域は希少な資源であり — 配信保証を必要としないデータに浪費してはならない。

8．持ち帰り用チェックリスト

次回LoRaWAN展開容量を見積もる際は、このリストをたどってほしい：

• [ ] Semtech LoRa計算ツールを使い、 対象SFとペイロードサイズでのエアタイムを測定する
• [ ] SFで重み付けした平均エアタイムを見積もり、 SF7やSF12をそのまま使わない
• [ ] ALOHAの18%しきい値＋50%のマージンを適用し、推奨デバイス数を求める
• [ ] ADR＋ローカルADRを有効化する（EBには標準搭載）
• [ ] 重要データはConfirmed、それ以外はUnconfirmed
• [ ] ジョインにはUTCのランダム遅延またはオンデマンドトリガーを使う
• [ ] ペイロードは小さく保つ。ASCIIよりバイナリが有利
• [ ] エッジで集約とフィルタリングを行い、上り送信を削減する
• [ ] 単一ゲートウェイの容量が厳しい場合は、 まずカバレッジを最適化し、その後でゲートウェイの追加を検討する

9．おわりに

冒頭のスプレッドシートのセルに戻ろう： SX1302ゲートウェイは何台のデバイスを扱えるのか？

単一の数値が求められるなら：典型的な範囲は ゲートウェイあたり1,000～10,000台である。しかしその数値自体には意味がない — SF分布、ペイロードサイズ、上り頻度、上り/下り比、ジョイン戦略、カバレッジ品質に依存するからだ。

容量は設計された結果であり、購入するパラメータではない。購入するハードウェアは容量曲線の出発点にすぎず、SF分布、ペイロード管理、カバレッジ計画 — これらのソフトウェア層の判断が、同じハードウェアで700台を扱えるか20,000台を扱えるかを決める。

大規模LoRaWAN展開では、 唯一信頼できるスケーリング順序は：

ADR → ペイロード削減 → ジョインの時間分散 → エッジコンピューティング → カバレッジ最適化 → ゲートウェイ追加

この六つのステップを踏めば、ほとんどのプロジェクトは二台目のゲートウェイを必要としない。

参考文献

• Semtech公式LoRa Modem Calculator：https://lora-developers.semtech.com/resources/tools/calculators/lorawan-airs-time-and-duty-cycle-calculator/
• LoRa Alliance, RP002-1.0.4 LoRaWAN Regional Parameters （2020）
• LoRa Alliance, LoRaWAN L2 1.0.4 Specification （2020）
• Semtech, SX1302 Datasheet — Corecell Gateway Baseband Processor
• ThinkLink公式ナレッジベース：「Decoding LoRaWAN Gateway Capacity」「LoRaWAN Gateway Capacity Analysis」「How Big Is a LoRa Gateway's Capacity」
• 「How Many Devices Can One LoRaWAN Gateway Really Handle?」 — lorawan-consulting.com（2024）
• Semtech, LoRa Corecell Reference Design — SX1302CFD490GW1 / SX1302CFD915W1-H
• ManThink公式ドキュメント：GD61x Configuration Guide / EdgeBus SDK

シリーズ索引

• 第1回：ManThink、GD6オープンソースLoRaWANゲートウェイを発表
• 第2回：GD6ハードウェア設計分析：ESP32-S3＋SX1302の選定ロジックとエンジニアリングトレードオフ
• 第3回：GD6入門：コードのクローンからカスタムゲートウェイファームウェアまで
• 第4回：GD6実践展開：5分でThinkLink / ChirpStack / TTNに接続
• 第5回：GD6の応用シナリオと選定：スマートビルからマルチリージョン全球展開まで
• 第6回：LoRaWANデバイスのジョイン手順解説：OTAA vs ABP、その選び方
• 第7回：LoRaWAN ADRメカニズム：データレートを制御するのは誰か
• 第8回：LoRaWANリージョナルパラメータ：CN470とEU868でチャネル数が異なる理由
• 第9回：LoRa物理層パラメータ：SF、BW、CRが通信距離とレートに与える影響
• 第10回（本記事）：LoRaWANネットワーク容量推定：SX1302ゲートウェイは実際に何台のデバイスを扱えるのか？

著者：ManThink技術チーム レビュアー：EdgeBus / GW Tool Group ドキュメントバージョン：v1.0 · 2026-09-09 ライセンス：CC BY-SA 4.0（再公開時は著者とリンクを保持してください）