Arduino Nesso N1で始めるLoRa開発：アイデアと技適の注意点

Arduino Nesso N1のLoRaサンプルコードを開くと、初期値はこうなっている。周波数868.0MHz、拡散率SF12、送信出力22dBm。ヨーロッパ向けの設定だ。このまま日本国内でビルドして電波を出せば、周波数帯も出力も国内の制度から外れる。

Nesso N1はArduinoとM5Stackの共同開発品で、スイッチサイエンス価格8,800円（税込）。ESP32-C6にLoRa（SX1262）、Wi-Fi 6、Bluetooth LE 5.3、Thread、Zigbee、赤外線送信を載せ、さらに1.14インチのタッチ画面と6軸IMUと250mAhのバッテリーまで内蔵している。この1台があれば、PCから切り離した状態で電波の実験ができる。LoRa開発の入門機として、これほど条件の揃ったハードはなかなかない。

ただし前述のとおり、最初にやるべきは配線でもライブラリ選定でもなく設定値の書き換えだ。本記事では、Nesso N1で組めるLoRa開発アイデアを具体的に並べたうえで、日本国内で電波を出す前に必ず押さえておくべき技適・ARIB STD-T108・LoRaWANまわりの注意点を整理する。

Arduino Nesso N1とは何か：スペックとハードウェア上の癖

2025年11月12日発売。ARDUINO-TPX00227という型番で、技適は取得済み（技適マークは箱に記載されているので、購入時に箱を捨てないこと）。

注目したいのはBQ27220フューエルゲージと8pin HAT（M5StickC互換）の2つだ。前者があるおかげで「1パケット送るのに何mAh使ったか」を機体単独で実測できる。後者のおかげで、手元のM5StickC用HAT資産をそのまま挿せる。

実装でつまずきやすいポイント

開発にはRadioLib（7.3.0以降）を使う。ピン配置は以下のとおり。

MOSI 21 / MISO 22 / SCK 20 / CS 23 / IRQ(DIO1) 15 / BUSY 19

ここで2つ、初見では気づきにくい癖がある。

1. SPIバスをLCDとSX1262で共有している。CSを分けることで競合を回避する設計になっている。
2. LoRaの初期化にI/Oエキスパンダ経由の制御が必要。LNAイネーブルやアンテナスイッチ、リセットがGPIO直結ではないため、そこを叩かずにSPIだけ繋いでも無線は動かない。「配線は合っているのに応答しない」で止まる典型パターンがここにある。

そして最重要：公式サンプルの初期値は日本向けではない

M5Stack側の公式ドキュメントに載っているSX1262の初期化パラメータは、周波数868.0MHz、帯域幅125.0kHz、SF12、符号化率4/5、同期ワード0x34、送信出力22dBm、プリアンブル20、TCXO基準電圧3.0V——という並びだ。

868MHzはEU向けの割り当てで日本の帯域とは異なり、22dBmは約158mW。国内920MHz帯の特定小電力無線局の枠を大きく超える。サンプルは「動作を確認するための例」であって「日本で使うための設定」ではない。ここを書き換えるところからNesso N1のLoRa開発は始まる。

Nesso N1で組むLoRa開発アイデア7選

以下、1台または2台で成立するものを優先して並べる。ゲートウェイもネットワークサーバーも要らない構成が中心だ。

1. 手のひらサイズのLoRaリンクアナライザ

タッチ画面・IMU・電池・フューエルゲージが全部載っているという特徴を、最も素直に活かせるのがこれだ。現地で単体完結する電波調査ツールを作る。

• 2台でペアを組み、歩きながらRSSI／SNRを連続計測して画面にリアルタイム描画する
• IMUの加速度から歩数を推定し、GPSなしで「距離 vs RSSI」カーブを描く
• SF7〜SF9を自動スイープし、同一経路で各SFの到達限界を比較する
• BQ27220から電流を読んで「1パケットあたりの消費mAh」を実測する
• 結果をWi-Fi経由でInfluxDBへ投げ、Grafanaでヒートマップ化する

追加ハードウェアはゼロ。しかも後述する技適の出力制約があるからこそ、「厳しい条件でどこまで届くか」という実測データそのものに希少価値が生まれる。市街地での低出力LoRaの到達データは、国内にほとんど蓄積がない。

2. マルチプロトコル・ブリッジ

Nesso N1がLoRa／Wi-Fi 6／BLE／Thread 1.4／Zigbee 3.0／赤外線を1台で持つことは、「プロトコル変換ノード」として異常に便利であることを意味する。

• LoRa → Wi-Fi → MQTT ブリッジ。外付けモジュールなしで成立する定番構成
• Zigbeeの既存センサー群を集約してLoRaで遠方へ中継する。ESP32-C6は802.15.4系のスタックを持つので、Matterデバイスとして振る舞わせる道もある
• 赤外線送信をアクチュエータ化する。Wi-Fiが届かない離れの部屋のエアコンを、LoRa経由で制御する「遠隔赤外線リモコン」が1台で組める

エージェントから見れば、1デバイスが複数プロトコルの翻訳層になる。これはアイデア7の自己記述カタログ構想と相性がいい。

3. Meshtastic JPノードとして実用化する

技適を取得していてMeshtasticが動くデバイスは、国内では非常に少ない。 Nesso N1はその数少ない候補の一つだ。

ただし現時点で、Nesso N1向けのビルドはMeshtasticの公式配布ファームウェアに含まれていない。GitHubのmeshtastic/firmwareにボード対応のIssue（#8744）が立ち、stephensb/nesso-n1-meshtastic-firmwareのような非公式のビルド用リポジトリが公開されている段階だ。したがって手順は次のようになる。

1. PlatformIOで該当ブランチを自分でビルドする
2. Nesso N1へ書き込む
3. スマートフォンからBLEで接続し、RegionをJPに設定する

手間はかかるが、裏を返せば国内での検証結果そのものに価値がある領域ということでもある。動作確認が取れれば上流へのフィードバックやPRという形の貢献も現実的だ。さらにMeshtasticのMQTTブリッジを使えば、メッシュ網 → MQTT → 自宅のエージェントという経路が、LoRaWANゲートウェイを買わずに成立する。

4. ホームラボの「第二経路」死活監視

サーバーやNASのハートビートを、インターネット回線とは独立したLoRa経路で送出する。回線障害が起きたときに「ルーターが落ちたのか、サーバーが落ちたのか」を切り分けられるようになる。

Tailscaleやトンネルサービスによる論理的な冗長化に対する、物理層の冗長化という位置づけだ。送るのは1日数回、ノード生存フラグと温度と電圧だけでいい。後述するデューティ制約から見ても十分に軽く、受信側に置いたNesso N1が異常時だけ通知を上げる構成にできる。

5. 帯域極小環境を「圧縮の実験場」にする

LoRa物理層のペイロード上限は255バイトだが、実運用では拡散率に応じてもっと小さく制限される。感覚を掴むための数字を挙げると、SF12・BW125kHz・プリアンブル8で12バイトの送信に約1.15秒かかる（サンプル既定のプリアンブル20なら約1.55秒）。この極端に狭い帯域は、要約・圧縮アルゴリズムの実験場として理想的だ。

• 既存のBM25＋キーワード抽出によるコンテキスト圧縮の仕組みを、「LoRaパケットに収まるまで要約する」用途に転用する
• エッジ側（Raspberry Piやローカルの小型モデル）で要約してから送信し、クラウド往復をゼロにする
• 評価指標は「数十〜200バイトに詰めたとき、情報量がどこまで保たれるか」

制約が厳しいほどアルゴリズムの差が出る。生成AI検索における「要約の質」の測定と、ほぼ同じ問題設定を物理レイヤの制約下でやることになる。

6. 帯域予算を持つエージェント

アイデア5をもう一段厳しくすると、いちばん新しい問題設定になる。

後述するLDC方式なら、送信は1時間あたり合計36秒まで。SF9／BW125kHz／CR4:5／プリアンブル8の条件でペイロード20バイトなら、1パケットのTime on Airは約185ms。36秒を割ると1時間に約190パケットが上限になる。ペイロードを200バイト近くまで膨らませると1パケット約1秒となり、35パケット程度まで落ちる。つまり「1日に送れる情報量」に硬い上限があり、しかもペイロード設計がその上限を直接動かす。

すると「何を送るか」の優先度付けが、そのまま設計問題になる。エージェントに「今日の36秒を何に使うか」を決めさせる——これは、LLMのトークン予算やAPIのレートリミットを管理する仕組みと構造的に同型の問題だ。疑似トークン経済を、電波のデューティ経済に置き換える。既存のポリシー管理の発想がそのまま転用できる。

7. LoRaノードの自己記述カタログ

Webサイトのエージェント可読性（llms.txtやAPIカタログの整備状況）を評価する、という発想がある。これをIoTデバイスに適用したらどうなるか。

各LoRaノードが自分のメタデータ——センサー種別、単位、更新頻度、信頼度、ペイロードデコーダ定義——を機械可読な形で宣言する。ゲートウェイ側でそれを集約してdevice-catalog.jsonとして公開し、エージェントがMCP経由で「今この家にどんなセンサーがあって何が取れるか」を自己発見できるようにする。

CayenneLPPやLoRaWANのDevice Profileを土台にできるので、ゼロから規格を作る話ではない。マルチプロトコル・ブリッジ（アイデア2）と組み合わせると、Nesso N1が「翻訳層かつ自己記述するノード」として機能する。

注意点1：技適の認証条件は「チップの性能」とは別物

ここからが本題の後半、電波を出す前に必ず押さえるべき話だ。

Nesso N1は技適を取得している。しかし技適を取っていることと、チップの最大性能をそのまま使えることは、まったく別である。

SX1262というICの実力は+22dBm（約158mW）ある。だが国内の技術情報では、Nesso N1の認証条件における空中線電力が、一般的な920MHz帯特定小電力の20mW（13dBm）枠ではなく、3mW（4dBm程度）まで絞られているという指摘がある。もしこれが正確なら、一般的な特小機の1/6以下ということになり、長距離リンクの設計は成り立たない。

この数値は運用設計を根本から左右するため、実際に電波を出す前に、総務省の「技術基準適合証明等を受けた機器の検索」で認証内容——周波数範囲・空中線電力・アンテナ利得の条件——を自分の目で確認しておきたい。認証条件を超えた設定での運用はできない。

低出力制約をネガティブに捉えない

とはいえ、これを欠点として受け取る必要はない。屋内や敷地内なら低出力でも十分に届く。そして低出力だからこそ、「どこまで届くか」の実測に意味が生まれる。リンクバジェットの感覚は、余裕のある条件よりも厳しい条件のほうが早く身につく。アイデア1のリンクアナライザが面白くなるのは、まさにこの制約があるからだ。

長距離が必要になった時点で、13dBm枠の機材（後述）を追加すればいい。

EIRPという落とし穴

もう一つ、見落としやすい論点がある。国内の920MHz帯は本体の送信電力だけでなく、アンテナ利得を含めた実効的な放射電力（EIRP）で管理される。つまり「届かないからアンテナを大きくする」という直感的な対処が、そのまま条件逸脱になり得る。

参考までに、M5StackのUnit LoRa-E220-JP（M5Stack用LoRaユニット JPバージョン、6,710円）はアンテナとセットで認証を取得しており、別のアンテナに交換すると認証が無効になると明記されている。アンテナは自由に付け替えられる部品ではない、という前提を持っておきたい。

注意点2：ARIB STD-T108が課す「時間の予算」

920MHz帯の特定小電力無線局は、「免許不要で使える便利な帯域」というだけの存在ではない。ARIB STD-T108という標準規格に沿った、送信時間制限とキャリアセンス要件の下にある。

キャリアセンス（送信前に空きチャネルを確認する処理）を省略したいなら、デューティ比を1%以下、つまり1時間あたりの送信時間を合計36秒以下に抑える必要がある。センサーの定期送信ならLDC方式が最も素直だが、その代わりに1日に送れる情報量に硬い上限が生まれる。

設計時に最初に決めるべきは、SFでも通信間隔でもなく「どの方式で運用するか」だ。ここが決まらないと、パラメータの妥当性を判断する基準がない。そしてこの制約こそが、アイデア6「帯域予算を持つエージェント」の出発点になっている。

国内P2P運用のパラメータ目安

注意点3：「LoRa」と「LoRaWAN」は別物

機材選定でいちばん大きな事故が起きるのがここだ。「LoRa」という語は、実務上まったく別の2つを指す。片方はSemtechが持つ変調方式そのもの、もう片方はその上に載るネットワーク規格だ。

Nesso N1が標準で扱えるのはプライベートLoRa（P2P）のほうだ。RadioLibでSX1262を直接叩く構成なので、LoRaWANとして動かすにはAS923に対応したプロトコルスタックを別途載せる必要がある。「ChirpStackに繋ぐつもりで買ったのにプロトコルが噛み合わない」という事故は、ここの取り違えから起きる。

LoRaWANへ進むときの選択肢

本格的にLoRaWANをやるなら、Nesso N1とは別の機材を用意するのが素直だ。

ES920LR3搭載キット（M5ATOM用LoRa無線キット、スイッチサイエンス価格6,820円）は、EASELのモジュールでSTM32WLE5JC（RFとMCUが1チップ）を採用し、技適を取得している。920.6〜928.0MHz、13dBm以下、受信感度-140dBm、消費電流はTx 29mA / Rx 5.7mA / Sleep 1.3µA。見通し条件で約10kmの到達実績が報告されている。決定的なのは、ファームウェアの書き換えでプライベートLoRaとLoRaWAN（v1.0.4準拠）を選択できる点だ。

もう一つの候補がM5StackのUnit LoRaWAN-AS923（SKU: U184-AS923）。RAK3172系のSTM32WLE5モジュールを載せ、LoRaWAN 1.0.3、周波数はAS923（923〜925MHz）。AS923は日本が属するリージョンなので帯域としては噛み合う（ただし国内のAS923-1実運用は920.6〜923.4MHzが中心）。ただし公式ドキュメントにはモジュール側の認証情報へのリンクはあるものの、ユニット本体の技適についての明記がない。国内で電波を出す前提で選ぶなら、購入前に販売店へ確認したい。

ネットワークサーバー側は、オープンソースのChirpStack v4を自前で立てられる。Rust製の単一バイナリで、v4.10.1からはPostgreSQLに加えてSQLiteをデータベースとして選択できる（ただしバックエンドはコンパイル時に決める必要があり、既定はPostgreSQLのまま）。Raspberry Pi単体で完結させたい構成には効いてくる変更だ。リージョン設定はas923（AS923-1相当。as923_2〜as923_4も用意されている）を使う。

海外バンド品には手を出さない

Unit LoRaWAN-EU868 / -US915 / -CN470 のように、製品名の末尾はそのままリージョンを表している。868がEU868、915がUS915、470が中国のCN470だ。いずれも日本の割り当てとは異なり、国内でそのまま電波を出すことはできない。AS923版と同じRAK3172系の現行品もあるので、型番の末尾を見落とさないようにしたい。

より注意が必要なのは、Meshtastic対応をうたう新しめの製品だ。仕様表に「868〜923MHz」「最大+22dBm」と書かれているものはEU/US市場を前提とした表記であり、そのままでは国内の枠を超える。出力を下げたとしても、そのモデルに技適がなければ国内での電波発射はできない。日本版SKUと技適番号の有無は、購入前に必ず確認したい。

これから進める順序と、残った確認事項

Nesso N1を起点にする場合、現実的な進め方はこうなる。

Phase 0から1までで「センサーデータが自宅に集まる」状態には到達する。ここまではNesso N1が2台あれば足りる。

一方で、この計画はまだいくつかの未確認事項の上に乗っている。正直に列挙しておく。

• Nesso N1の技適証明書を総務省のデータベースで検索し、空中線電力とアンテナ利得の条件を一次資料で裏取りする。本稿で触れた3mW（4dBm）という数値は国内の技術情報に基づくもので、公的DBでの確認はこれからだ
• Nesso N1でLoRaWANが使えるか（AS923スタックを自前実装する必要があるのか、RadioLibベースのLoRaWAN層で足りるのか）
• 低出力条件での実到達距離（屋内・市街地・見通し）の実測。国内のデータがほとんど存在しない
• MeshtasticのNesso N1対応の本家マージ状況と、JP regionの出力設定が認証条件と整合するか
• ES920LR3のLoRaWANファームウェアとChirpStack v4の実接続事例（情報が薄い）

3番目——低出力での実到達距離の実測——は、単なる下調べではなくそれ自体がコンテンツ資産になる性質のものだ。Nesso N1にはそのための道具が最初から全部載っている。

よくある質問

Arduino Nesso N1は日本で使えるのか

技適を取得しており、技適マークは製品の箱に記載されている。ただし、認証条件として定められた周波数範囲・空中線電力・アンテナ利得の範囲内で使う必要がある。特に空中線電力については、一般的な920MHz帯特定小電力の20mW（13dBm）枠より小さい3mW（4dBm程度）まで絞られているという指摘が国内の技術情報にあるため、電波を出す前に総務省の「技術基準適合証明等を受けた機器の検索」で認証内容を確認することを勧める。

公式サンプルコードをそのまま日本で使えないのはなぜか

Nesso N1のLoRaサンプルは初期値が周波数868.0MHz、拡散率SF12、送信出力22dBmになっている。868MHzはヨーロッパ向けの割り当てで日本の帯域とは異なり、22dBmは約158mWで国内920MHz帯の特定小電力無線局の枠を大きく超える。国内で動かすには、周波数を920MHz帯へ、出力をその機体の認証条件内へ書き換える必要がある。

Nesso N1でLoRaWANはできるのか

標準で使えるのはプライベートLoRa（P2P）で、RadioLibからSX1262を直接制御する形になる。LoRaWANとして動かすにはAS923に対応したプロトコルスタックを別途載せる必要があり、実現可能かどうかは検証待ちの段階だ。確実にLoRaWANをやりたい場合は、ファームウェア書き換えでLoRaWAN v1.0.4に対応できるES920LR3搭載キット（6,820円、技適取得済み）を別途用意するのが現実的である。

ARIB STD-T108の「1時間36秒」とは何を意味するのか

1台の機器が1時間に電波を出せる合計時間の上限が36秒だ、という意味である。920MHz帯でキャリアセンス（送信前の空きチャネル確認）を省略してLDC方式で運用する場合、デューティ比を1%以下、すなわち1時間あたりの送信時間の合計を36秒以下に抑える必要がある。これは実質的に「1日に送れる情報量の上限」として働くため、何を送り何を送らないかという優先度付けが設計上の中心的な課題になる。

Nesso N1でMeshtasticを動かすには何が必要か

現時点でNesso N1向けのビルドはMeshtasticの公式配布ファームウェアに含まれていないため、自分でビルドする必要がある。GitHubのmeshtastic/firmwareにボード対応のIssue（#8744）が立っており、非公式のビルド用リポジトリも公開されている。PlatformIOでビルドして書き込んだあと、スマートフォンからBLEで接続してRegionをJPに設定する、という手順になる。

まとめ

Arduino Nesso N1は、8,800円という価格に対してLoRa開発に必要なものが不自然なほど揃っている。画面があるからPCに繋がずデバッグでき、電池があるから外に持ち出せ、IMUとフューエルゲージがあるから「距離」と「電力」を機体単独で測れる。アイデア1のリンクアナライザが追加ハードウェアなしで成立するのは、この構成のおかげだ。

一方で、LoRa開発の最初の関門は技術的な難易度ではなく制度の理解にある。技適の認証条件はチップの性能とは別物であり、ARIB STD-T108は「1時間に何秒送れるか」という時間の予算を課し、プライベートLoRaとLoRaWANは別のものだ。この3つを最初に押さえておけば、機材選定でも設定値でも大きく外すことはない。

そして制約は、避けるべき障害というより設計の出発点として扱ったほうが面白い。1時間に36秒しか送れないという上限は「何を送るべきか」という問いを強制し、狭いペイロードは圧縮アルゴリズムの差を可視化し、低出力という条件はリンクバジェットの感覚を最短で叩き込んでくれる。電波の予算をどう使うかを考え始めた時点で、LoRa開発はもう始まっている。

参考

参考ソース

• Nesso N1 | Arduino Documentation
• Arduino Nesso N1 — スイッチサイエンス
• Arduino Nesso N1 LoRa 通信 | M5Stack Docs
• Arduino Nesso N1 プログラムのコンパイルと書き込み | M5Stack Docs
• Arduino Nesso N1の使い方：LoRa無線通信編 | ロジカラブログ
• Arduino Nesso N1 で Meshtastic を試す - Qiita
• [Board]: Arduino Nesso N1 · Issue #8744 · meshtastic/firmware
• Unit LoRaE220-JP 公式ドキュメント | M5Stack Docs
• M5Stack用LoRaユニット JPバージョン — スイッチサイエンス
• Unit LoRaWAN-AS923 | M5Stack Docs
• 920MHz帯LoRa/FSKモジュール ES920LR3 | EASEL
• M5ATOM用LoRa無線キット (ES920LR3) — スイッチサイエンス
• [release] ChirpStack v4.10 — ChirpStack Forum
• 「920MHz帯の壁」崩壊の音 - Qiita
• 920MHz帯小電力無線システムの技術的条件（情報通信審議会資料） - 総務省
• 日本でMeshtasticを使うための入門 | LoPRA Lab

関連記事

• LoRaWANで構築する自宅IoTネットワーク：長距離・低消費電力で広がるコミュニティ無線インフラの全貌
• エッジAIハードウェア革命2026：NPUの進化とジェネレーティブAIの民主化
• Sample More, Reflect Less: Self-Refine and Reflexion Lose to Repeated Sampling at Equal Token Cost, from 1.5B to 7B