Blog Dice

My First Impressions of MeshCore Off-Grid Messaging

Michael Lynch

MeshCoreのオフグリッドメッセージングを試した第一印象

新しく買った暗号化対応の無線機をいじっていると、妻が「それは何に使うの？」と聞いてきました。

「想像してみてよ」と私は言いました。「スマホでメッセージを打って君に送ると、その瞬間に君のスマホに表示されるんだ！」

妻はまったく感動しませんでした。

「停電で電話回線が止まっても……いや、社会が崩壊しても使えるんだよ」それでも反応はなしです。

「もしお互いの電波が届かなくても、近所の人たちの無線機が作るメッシュネットワークを中継して届けられるんだ。しかもメッセージはエンドツーエンドで暗号化されるから、誰にも読まれないよ！」そこまで言ったところで、妻は部屋を出ていきました。

妻には素晴らしいところがたくさんありますが、正直に言って「暗号化されたオフグリッドメッセージングへの情熱」はその中に含まれていません。

もちろん、私が妻に熱く語っていた技術こそMeshCoreでした。

tl;dr ― 結論は？

結論だけ先に知りたい方は、まとめをご覧ください。

MeshCoreとは？

MeshCoreは安価な長距離無線（LoRa）で動くソフトウェアです。LoRa無線は見通しが良ければ数マイル先まで届きます。アマチュア無線と違って、米国ではLoRaの周波数帯を使うのに免許は不要なので、誰でも無線機を買ってすぐにおしゃべりを始められます。

MeshCoreは単に無線でメッセージを送るだけではありません。名前に含まれる「mesh（網の目）」は、ユーザー同士がメッシュネットワークを作ることに由来します。たとえばAliceが友人のCharlieにメッセージを送りたいけれど、Charlieが自分の電波の届かない場所にいる場合、近くにいる別のユーザーBobを経由してメッセージを中継し、BobがCharlieへ転送することができます。

AliceがBobとは通信できるがCharlieとは直接届かない場合、BobのMeshCore無線機にメッセージを中継させてCharlieに届けることができます。

オフグリッド通信に託す夢

私は終末に備えるガチなプレッパーというわけではありませんが、長期の停電や食料不足、干ばつといった現実的な災害シナリオには備えています。

MeshCoreの話を聞いたとき、近所の友人にデバイスを渡しておけば緊急時に連絡が取れるかもしれないと思いました。もし互いの電波が届かなくても、近所の何人かを巻き込めば、停電や電話網の障害に強いメッセージングネットワークを作れるのではないかと考えたのです。

なぜMeshtasticではないのか

MeshCoreは、Meshtasticという技術によって広まったアイデアを、より新しく実装したものです。

私がMeshtasticを初めて知ったのは、Tyler Cipriani氏の2022年のブログ投稿でした。面白いアイデアだと思いましたが、Tyler氏の結論は「当時のMeshtasticはバグが多く、一般層に普及するには難しすぎる」というものでした。

私はMeshCoreにもMeshtasticにも特に肩入れしているわけではなく、どちらも触ったことはありませんでした。Mastodonでフォローしている人たちがMeshCoreで盛り上がっていたので、試してみようと思ったのです。MeshCore対応デバイスの多くはMeshtasticにも対応しているので、片方を試してからもう片方を試すのも簡単です。

MeshtasticとMeshCoreの違いについて私の理解は限られていますが、把握している限りでは、MeshCoreの最大の違いは帯域の節約にあります。Meshtasticは近距離に多くのユーザーが集まるとスケーリングの問題が起きるようです。MeshtasticのプロトコルはMeshCoreよりおしゃべりで、無駄な通信が電波を埋めてメッセージの到達を妨げるという不満をよく見かけます。MeshCoreはネットワーク上の無駄話を最小限にすることで、この問題を解決しようとしています。

私は無線の素人です

ここで断っておきますが、私は無線の専門家ではありません。

LoRaコミュニティの多くの人は、アマチュア無線など無線全般に詳しい愛好家のようです。

私はある程度技術に詳しいソフトウェア開発者ですが、無線通信については何も知りません。もし無線の伝播について私の理解が間違っていたら、それが理由です。

Heltec v3：最安で始めるMeshCore

MeshCoreのファームウェアは数十種類のデバイスで動きますが、公式サイトでは特に3機種が推奨されています。その中で一番安いのがHeltec v3です。私は27ドルで2台購入しました。

27ドルのHeltec v3は、私が見つけた中で最も安いMeshCore対応デバイスでした。

Heltec v3をUSB-Cでパソコンにつなぎ、MeshCoreウェブフラッシャーを使って最新のファームウェアを書き込みました。デバイスは「Heltec v3」、モードは「Companion Bluetooth」、バージョンは「v1.9.0」を選び、新規インストールなので「Erase device」をクリックしました。

次に、MeshCoreウェブアプリを使ってHeltecとスマホをBluetoothでペアリングしました。

MeshCoreウェブアプリで迷子になる

さて、スマホとMeshCoreデバイスのペアリングはできました。で、次はどうすればいいのでしょう？

アプリは初期設定についてほとんど案内してくれません。

「Map」をクリックして、近くに他のMeshCoreユーザーがいないか見てみました。

表示されたのはニュージーランドの地図でした。私は米国在住なので少し驚きました。地図をあちこち見てみても、どこにもMeshCoreのアクティビティは見当たらず、この地図が何のためのものなのかさっぱり分かりません。

ニュージーランドの地図を見て思い出しました。国によってLoRaで使う周波数が違うということです。アプリがデフォルトでニュージーランドの位置を表示するなら、送信周波数もニュージーランド向けになっているはずです。

設定画面を開くと「Radio Settings」という項目があり、ドロップダウンかと思ってクリックしてみると、数値を入力する欄でした。よく見ると目立たない「Choose Preset」というボタンがあり、そこには「コミュニティ推奨」の国別プリセットが並んでいます。意味は全く分かりませんでしたが、コミュニティに逆らう理由もないので「USA/Canada (Recommended)」を選びました。

設定でデバイス名も変えられることに気づいたので、これは便利そうだと思いました。

予想通り、私の周りに他のMeshCoreユーザーはいないようでした。だからこそ2台目のHeltecを買ったのです。

古いスマホともう1台のHeltec v3で同じ手順を繰り返しましたが、互いに認識しません。よくよく考えると、2台目の周波数を米国用に設定し忘れていたことに気づきました。こういうところでも、MeshCoreアプリが初期設定をもっと丁寧に案内してくれればと思います。

ようやく2台が互いを認識しました！どちらもパブリックチャンネルにメッセージを投稿できます。

ようやくデバイス同士がパブリックチャンネルで会話できるようになりました。

ダイレクトメッセージを試す

友人とMeshCoreでやり取りするなら、会話のすべてをパブリックチャンネルで垂れ流したくはありません。そこでダイレクトメッセージを試すことにしました。

パブリックチャンネルで相手の名前をクリックしてDMを送れるのだろうと思っていましたが、できませんでした。名前をクリックしても何も起きません。「Participants」ビューはありますが、そこにある選択肢はブロックだけで、DMを送ることはできません。

これは奇妙な設計だと思いました。パブリックチャンネルに投稿しているユーザーになぜ直接話しかけられないのでしょう。

最終的に「Advert」する必要があると分かりました。選択肢は「Zero Hop」「Flood Routed」「To Clipboard」の3つです。どれも意味は分かりませんが、「Flood」はなんだか乱暴そうで、「Zero Hop」はエレガントに聞こえたので、「Zero Hop」を選びました。

よし！デバイス2がデバイス1を認識しました。ではデバイス2からデバイス1に挨拶してみましょう。

おっと、何が問題でしょう？デバイス2からも「Advert」する必要があるのかもしれません。

やってみると、ほら！メッセージが届くようになりました。

これはイライラするユーザー体験です。両方からAdvertが必要なら、なぜ中途半端なハンドシェイクの状態でメッセージ送信を許可するのでしょう。

「Advert」とは自分のデバイスの公開鍵を告知することだと推測していますが、なぜそれを事前に明示的にやらなければならないのか分かりません。パブリックチャンネルに投稿したときや、誰かにDMを送ろうとしたときに、自動でやってくれればいいのにと思います。

ともかく、パブリックチャンネルでもDMでも、自分自身と会話できるようになりました。先に進みましょう！

さらにMeshCore対応デバイスを追加購入

Heltec v3基板はMeshCoreを試すには良い方法でしたが、実際の利用シーンでは実用的ではありません。独自の電源が必要で、ペアリングするスマホも必要です。USB-Cケーブルでスマホから給電しようとしましたが、Heltec基板は起動しませんでした。本当の緊急時には、故障の要因が多すぎます。

MeshCoreの公式サイトでは他に2つの対応デバイスが推奨されていたので、それらを注文しました。Seeed SenseCAP T-1000e（40ドル）とLilygo T-Deck+（100ドル）です。

MeshCoreの実験を続けるため、Seeed SenseCAP T-1000e（左）とLilygo T-Deck+（右）を購入しました。

SenseCAP T-1000eを試す

T-1000eはHeltec v3から明らかに進化していました。バッテリーもアンテナも内蔵された一体型で、よりシンプルで頑丈に感じます。軽いのも良いところです。バックパックに入れても存在を忘れるほどです。

むき出しの基板であるHeltec v3と比べると、T-1000eはずっとユーザーフレンドリーな製品に感じられます。

残念なことに、T-1000eは専用のUSBケーブルを使うので、手持ちの標準的なUSBケーブルでは充電も書き込みもできません。

Seeed T-1000eは充電と書き込みに専用のUSBケーブルを使います。

Heltecではウェブフラッシャーを使いましたが、T-1000eはソースから直接書き込んでみることにしました。

git clone https://github.com/meshcore-dev/MeshCore.git

# Latest firmware version at the time I tested.
FIRMWARE_VERSION='companion-v1.9.0'
git checkout $FIRMWARE_VERSION

私はNixを使っているのですが、リポジトリにdefault.nixが用意されているので、direnvで依存関係が自動的にインストールされました。T-1000eへのファームウェア書き込みは次のように行いました。

# Specify the device settings, from variants/t1000-e/platformio.ini.
DEVICE_SETTINGS='t1000e_companion_radio_ble'
pio run \
  --environment $DEVICE_SETTINGS \
  --target upload \
  --upload-port /dev/ttyACM0

その後はT-1000eをスマホとペアリングしましたが、使い勝手はHeltecとほぼ同じでした。唯一の違いは、T-1000eには画面がないため、Bluetoothのペアリングパスワードがデフォルトで123456になっていることです。ということは、Bluetoothが届く範囲にいる誰でも簡単に私のT-1000eを乗っ取り、メッセージをすべて読めてしまうということでしょうか。

また、T-1000eは電源を切ることができないように見えるのも、電波を発するデバイスとしては好ましくありません。メーカーは数日間放置してバッテリーが切れるのを待つようにユーザーに案内しています。

追記：MeshCoreコントリビューターのFrieder Schrempf氏がコミット07e7e2dでこの問題を修正しました。MeshCoreファームウェアv1.11.0に含まれており、T-1000e上部のボタンを長押しすることで電源を切れるようになりました。

Lilygo T-Deckを試す

次はLilygo T-Deckを試す番です。

これはMeshCoreの中でも、最初から一番楽しみにしていた部分でした。

T-1000eのようなデバイスをあまり技術に詳しくない友人に渡しても、実際の緊急時にはうまくいかないことが多すぎると思いました。「あれ、MeshCoreアプリ入れてないの？」「スマホとのペアリングで困ってるの？」「スマホのバッテリー切れちゃったの？」といった具合です。

T-Deckは2000年代のBlackBerryのような見た目でした。スマホとのペアリングもアプリのインストールも不要なオールインワンデバイスなので、驚くほどシンプルに使えそうに見えました。たくさん買って友人に配ろうと思っていました。社会が崩壊して街が混乱に陥っても、まるで2005年のように「終末ハッカー向けBlackBerry」でおしゃべりできるだろうと。

これはBlackBerryではない

T-Deckの電源を入れた途端、期待は打ち砕かれました。これは全くBlackBerryではありませんでした。

参考までに、こちらが2003年当時のBlackBerryです。

2003年当時のBlackBerryスマートフォン

T-Deckのソフトウェアの話をする前に、ハードウェア自体が大きくてかさばります。22年前に作ったハードウェア製品の品質にすら追いつけないのでしょうか。

使い始めから、T-Deckは扱いづらさの連続でした。UIの操作は中央にある小さくて頼りないサムホイールをクリックして行うのですが、気まぐれでスクロールの半分は無視されます。

良い知らせは、タッチスクリーンがあることです。しかしタップの半分は反応しません。

UI要素を「クリック」する方法は3通りあります。トラックボールをクリックするか、「Enter」キーを押すか、画面をタップするかです。特定のUI要素がどれを期待しているのかは、3つすべて試してみなければ分かりません！

余談：Lilygo T-Deck+をDFUモードにして書き込む方法

T-Deck+を再書き込みする方法の説明を探すのにも苦労しました。Jeff Geerling氏の長い動画を見つけましたが、彼は書き込み手順を見つけるのにどれだけ時間がかかったか不満を述べているだけで、結局どうやったのかは説明してくれませんでした！

私の場合、次の手順でうまくいきました。

  1. T-DeckからUSB-Cを抜きます。
  2. T-Deckの電源を切ります。
  3. USB-CでT-Deckをパソコンにつなぎます。
  4. 中央のサムホイールを押し込んだままにします。
  5. デバイスの電源を入れます。

ややこしいことに、デバイスがDFUモードに入ったという表示は一切出ません。画面が表示されないことが、ある意味目印なのでしょう。私の環境では、dmesgのログに接続を示す出力も確認できました。

T-Deckでメッセージを送る

T-Deckの操作方法を何とか把握してメッセージを試してみましたが、体験は依然として不可解なままでした。たとえば、これは何の画面だと思いますか。

この画面は何をするものでしょう？

「パブリックチャンネルでチャット」と答えたなら、あなたは私より勘が良いです。私には何の画面か全く分かりませんでした。チャットメッセージが表示されていても、かろうじてチャットUIに見える程度です。

ああ、これはチャットUIでした。

他にも混乱するUXにはたくさん遭遇しましたが、ここですべて語るのはあまりに退屈なので割愛します。

悲しい結論として、これは緊急時に頼れるデバイスではないと感じました。UXには落とし穴や行き止まりが多すぎて、多くの人がつまずき、私との連絡が取れなくなってしまうでしょう。

屋外でMeshCoreを試す

T-Deckにはがっかりさせられましたが、別のデバイスでMeshCoreを使いたいという希望はまだ捨てていませんでした。

机の上で数センチ離して試すのではなく、現実の世界でこれらのデバイスがどう動くか確かめる必要がありました。

T-1000eからHeltecへ、約1マイル離れて

まず、友人の家までT-1000eを持っていきました。自宅から約1マイル（約1.6km）離れた場所です。そこから自宅の書斎にあるHeltecにメッセージを送ってみましたが、送信は失敗しました。どうやらこの距離では2台が互いをまったく認識できなかったようです。

まあ、仕方ないでしょう。私は郊外の住宅街に住んでいて、自宅と友人宅の間には家や木、車がたくさんありますから。

T-1000eからHeltecへ、数ブロック離れて

次に、車で自宅から離れるときにT-1000eを持っていき、書斎のHeltec v3へメッセージを送ってみました。

1ブロック離れた地点：メッセージは成功しました。

3ブロック離れた地点：まだ届きます。

5ブロック離れた地点：失敗しました。

そしてその日、家に帰るまで自宅のデバイスには二度と届きませんでした。

T-DeckからT-1000eへ、数ブロック離れて

もしかして問題はHeltec側でしょうか？ずっとHeltecを自宅に残して試していましたが、Heltec v3は特にアンテナが弱いと読んだことがあります。

今度はT-1000eを自宅に残し、T-Deckを持ち出して試してみました。

約5ブロック離れたところからはT-1000eに正常にメッセージを送れましたが、それ以上離れるとすべて失敗しました。

リピーターは必要か？

MeshCoreエコシステムの中でまだ触れていなかったのが、リピーターの存在です。

SenseCAP Solar P1-Pro、ソーラー給電のMeshCoreリピーター

MeshCoreのリピーターはWi-Fiの中継器のようなものです。MeshCoreのメッセージを受信して再送信し、到達範囲を広げます。

リピーターこそがMeshCoreの「メッシュ」を作り出しています。リピーター同士がメッセージを送り合い、あなたのメッセージをより遠くまで運んでくれるのです。

技術的に面白いリピーターも登場しています。ソーラー給電で内蔵バッテリーを備え、独立して動作し、数日間日照がなくても持ちこたえます。

問題は、リピーターがどれほどの違いを生むのか分からなかったことです。強力なアンテナを持つリピーターならメッセージをよく飛ばせるでしょうが、それで私の問題は解決するのでしょうか。T-Deckから6ブロック先のT-1000eにすら届かないのに、どうやってリピーターに届くというのでしょう。

この時点でMeshCoreへの熱意は冷めてしまい、どれだけ改善するか分からないのに、さらに100ドルを費やして送信機を自宅に取り付ける気にはなれませんでした。

MeshCoreのソースコードを読んでみる

MeshCoreのファームウェアはオープンソースなので、T-Deckのユーザー体験を改善できることがないか見てみることにしました。

ソースコードを見て最初に驚いたのは、自動テストが一切なかったことです。私は簡単なユニットテストを書きましたが、MeshCoreチームからは2か月近く何の反応もありません。

ざっと眺めた感じでは、コードベースは多少ごちゃっとしていますが、ひどいというほどではありません。C++で書かれており、ほとんどのクラスは非privateな関数やフィールドが20以上あるなど公開範囲が広いのですが、これは組み込み系のプロジェクトではよく見かけることです。

もう一つの気になる点は、私のユニットテストが呼び出しているtoHex関数です。これは生のバイト列を16進文字列にエンコードするものです。

// Create a test input.
uint8_t input[] = {0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF};
char output[HEX_BUFFER_SIZE(input)];

// Call the function we're testing.
Utils::toHex(output, input, sizeof(input));

// Verify that toHex encoded our bytes correctly.
EXPECT_STREQ("0123456789ABCDEF", output);

MeshCoreのtoHex実装は、暗号とは何の関係もないにもかかわらず、2つの暗号ライブラリのヘッダーに依存しています。各コンポーネントにユニットテストを書いていれば避けられたはずの、不要な結合の典型です。

もう一つ些細な不満は、コードのスタイル規約が統一されていないことです。誰かが提案した、リポジトリに既にあるリポジトリに既にある.clang-formatファイルを使うという案について、メンテナーはissueをクローズしました。「自分のIDEがコミット時に不要な変更を加えないようにしてください」という指示とともにです。

なぜでしょう。2025年にもなって、なぜ中括弧の位置をローカルなスタイルに合わせることまで考えなければならないのでしょう。フォーマッターを設定すれば、そんな些細なスタイルのことを考えずに済むのにと思います。

えっ、MeshCoreはオープンソースじゃないの？

私はもともとT-DeckのUIを理解しようとMeshCoreのソースを掘り始めましたが、そのコードが見つかりませんでした。MeshCoreのAndroidアプリやウェブアプリのソースも見つかりません。

そして気づきました。すべてクローズドソースだったのです。公式のMeshCoreクライアント実装はすべてクローズドソースでプロプライエタリでした。

MeshCore FAQを読んで、重要なコンポーネントがクローズドソースであることに気づきました。

なんだって！？オープンソースだと宣伝していたじゃないか！どうして騙したんだ？

そこでMeshCoreのウェブサイトに戻ってみると、どこにも「オープンソース」とは書かれていないことに気づきました。

MeshCoreがオープンソースだと宣伝していたというのは、私の思い込みだったようです。

あまりにオープンソースっぽいものなので、勝手にそう思い込んでいました。しかし、MeshCoreの重要な部分がプロプライエタリだと知って、ひどくがっかりしました。

オープンソースのクライアントがなければ、MeshCoreは私には合いません。

追記（2026-01-13）：現在は非公式のオープンソースクライアントが存在します。

私はオープンソース原理主義者ではなく、ソフトウェアがプロプライエタリであること自体は構わないと思っています。しかし、オフグリッド通信の肝は分散化と技術的な自由にあるので、クローズドソースのソリューションには賛同できません。

MeshCoreエコシステムの一部は確かにオープンソースで寛容なライセンスで提供されていますが、肝心のT-Deckファームウェア、ウェブアプリ、モバイルアプリはすべてクローズドソースでプロプライエタリです。Heltec v3やT-1000eに書き込んだファームウェアはオープンソースですが、それらの無線機を使うために利用したモバイルアプリやAndroidアプリ（クライアント）はクローズドソースでした。私の見る限り、開発用開発用CLI以外にオープンソースのMeshCoreクライアントは存在しません。

製品オープンソース？無料で使える？
MeshCore無線ファームウェアはいはい
MeshCoreプロトコルはいはい
ウェブ版MeshCoreファームウェアフラッシャーはいはい
公式Android / iOS MeshCoreアプリいいえはい、ただし一部機能は有料
公式MeshCoreウェブアプリいいえはい、ただし一部機能は有料
T-Deck MeshCoreファームウェアいいえはい、ただし一部機能は有料

まとめ

最後に

MeshCoreというアイデア自体は今でも大好きですが、まだ緊急時の連絡手段として実用的とは感じられません。ソフトウェアが使いづらすぎますし、5ブロック（約0.3マイル）以上先にはメッセージを届けられたことがありません。

MeshCoreを再検討する気持ちはありますが、オープンソースのクライアントと使い勝手の改善を待ちたいと思います。

MeshCoreの良かったところ

  • 大企業のインフラに頼らずにテキストメッセージを送れるのは、とにかくクールです。
  • 災害への備えが好きな私の心をくすぐるコンセプトです。
  • MeshCoreは多種多様な低価格デバイスで動作し、その多くはMeshtasticでも使えます。
  • 熱心で活発なコミュニティが存在します。

MeshCoreの残念だったところ

  • 公式のMeshCoreクライアントがすべてクローズドソースでプロプライエタリであること。
  • ユーザー体験が脆すぎて、特にMeshCore初心者と連絡を取り合うような緊急時に頼れないこと。
  • ほとんどのハードウェアがスマホとBluetoothでペアリングすることを前提としており、故障の要因や複雑さが増していること。
  • 公式のスタンドアロン端末がT-Deck+しかなく、しかも使いづらくてイライラさせられること。
  • 文章で書かれたスタートガイドが存在しないこと。
    • FAQはありますが、整理されておらず細かな情報が雑多に並んでいるだけです。
    • 優れた非公式の入門動画はありますが、私はテキストのドキュメントを好みます。

原文は Michael Lynch により に公開されました。

この記事は「muse-spark-1.2-contributor」を使用して翻訳されました。