新しい暗号化無線機をいじっている僕を見て、妻が何に使うものなのかと聞いてきた。

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

彼女はまったく感心しなかった。

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

「もしお互いが無線の届く範囲にいなくても、近所の人たちの無線機が作るメッシュネットワークを経由してメッセージを届けられるんだ。でも心配しないで！無線機はメッセージをエンドツーエンドで暗号化するから、他の誰にも内容は読まれないよ」こう言い終える頃には、彼女は部屋を出ていた。

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

もちろん、僕が妻に熱弁していた技術というのがMeshCoreだ。

TL;DR ― 結論を先に言うと

先に結論を読みたい方はまとめをご覧ください。

MeshCoreとは？

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

MeshCoreは単に無線でメッセージを送るだけではない。名前に含まれる「mesh（メッシュ）」は、MeshCoreユーザーがメッシュネットワークを形成することに由来する。例えばAliceが友人のCharlieにメッセージを送りたいが、Charlieが自分の無線の届く範囲外にいる場合、近くにいる別のMeshCoreユーザーであるBobを経由してメッセージを中継し、Bobが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だ。僕は1台27ドルで2台購入した。

Heltec v3をUSB-Cポートでパソコンに接続し、MeshCore web flasherを使って最新ファームウェアを書き込んだ。デバイスに「Heltec v3」、モードに「Companion Bluetooth」、バージョンに「v1.9.0」を選択した。新規インストールだったので「Erase device」をクリックした。

次に、MeshCore web appを使ってHeltecとスマホをBluetoothでペアリングした。

MeshCoreウェブアプリで手探りする

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

アプリは導入ガイドという点ではあまり役に立たない。

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

表示されたのはニュージーランドの地図だった。僕は米国在住なので、ちょっと驚いた。地図をいろいろ動かしてみても、どこにもMeshCoreのアクティビティは見当たらず、この地図が何のためにあるのかわからなかった。

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

設定画面を開くと「Radio Settings」という項目があり、ドロップダウンを期待してクリックしたが、数値を入力する形式だった。そして控えめに置かれた「Choose Preset」ボタンに気づいた。そこには「コミュニティが推奨する」各国用のプリセットが並んでいた。どれが何を意味するのかさっぱりわからなかったが、コミュニティに逆らう理由もない。「USA/Canada (Recommended)」を選んだ。

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

自分の届く範囲には他のMeshCoreユーザーがいないようだったが、これは想定内だった。だから2台目のHeltecを買ったのだ。

古いスマホと2台目のHeltec v3でも同じ手順を繰り返したが、お互いを認識できなかった。やがて、2台目のデバイスを米国の周波数に設定し忘れていたことに気づいた。MeshCoreアプリが初期導入をもっと真剣に考えてほしいと思う理由がまた一つ増えた。

よし、ようやくお互いが見えるようになった！どちらもパブリックチャンネルにメッセージを投稿できる。

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

友人とMeshCoreで連絡を取り合うなら、会話のすべてをパブリックチャンネルで放送したくはない。そこでダイレクトメッセージを試すことにした。

パブリックチャンネルの連絡先を表示してダイレクトメッセージを送る手段があると思っていたが、できなかった。名前をクリックしても何も起きない。「Participants」ビューもあるが、できるのはブロックだけで、ダイレクトメッセージを送る選択肢はない。

奇妙な設計選択に思える。MeshCoreユーザーがパブリックチャンネルに投稿しているのに、なぜ直接話しかけられないのか。

やがて「Advert」しなければならないことがわかった。選択肢は「Zero Hop」「Flood Routed」「To Clipboard」の3つだ。どれが何を意味するのかわからないが、「flood」はなんだか乱暴に聞こえるし、「Zero Hop」はエレガントに聞こえるので、「Zero Hop」を実行してみた。

やった！デバイス2がデバイス1を認識した。デバイス2からデバイス1に挨拶してみよう。

おっと、何が問題だろう？デバイス2からも「Advert」する必要があるのかもしれない？

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

これはイライラするユーザー体験だ。両端からadvertが必要なら、なぜMeshCoreは握手が半分しか終わっていない状態でメッセージ送信を許したのか。

「Advert」は自分のデバイスの公開鍵を告知することだと推測しているが、なぜそれを事前に明示的にやらなければならないのかわからない。パブリックチャンネルに投稿したり、誰かにダイレクトメッセージを送ろうとしたときに、MeshCoreが暗黙的にやってくれればいいのに。

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

さらにMeshCoreデバイスを注文する

Heltec v3ボードはMeshCoreを試すには良かったが、実際の利用シーンでは実用的ではない。独自の電源とペアリングするスマホが必要だ。USB-C to USB-Cケーブルでスマホから給電しようとしたが、Heltecボードは起動しなかった。実際の緊急時には、これでは障害点が多すぎる。

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

SenseCAP T-1000eを試す

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

厄介なことに、T-1000eは専用のUSBケーブルを使うため、手持ちの一般的な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だ。

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にしか見えない程度だ。

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

悲しい結論として、これは緊急時に頼れるデバイスではない。UXには落とし穴や行き止まりが多すぎて、多くの人がつまずき、僕との連絡を妨げるだろう。

MeshCoreをフィールドでテストする

T-Deckには心を折られたが、別のデバイスでMeshCoreを使えることにはまだ希望を持っていた。

机の上で数センチ離して使うのではなく、現実の世界でこれらのデバイスがどう動くのかを見る必要があった。

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

まず、T-1000eを約1マイル離れた友人の家に持っていき、自宅の書斎にある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エコシステムのもう一つの要素がリピーターだ。

MeshCoreリピーターはWi-Fiエクステンダーのようなものだ。MeshCoreのメッセージを受信して再送信し、到達範囲を広げる。

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

技術的にクールなリピーターもいくつか存在する。ソーラー給電で内蔵バッテリーを備えており、独立して動作し、数日間日照がなくても持ちこたえる。

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

この時点ですでにMeshCoreへの熱意は冷めており、どれだけ改善されるかわからないのに、さらに100ドルを払って送信デバイスを自宅に取り付ける気にはなれなかった。

MeshCoreのソースコードを覗いてみる

MeshCoreのファームウェアはオープンソースなので、T-Deckのユーザー体験を改善するために何かできないかと中を覗いてみた。

ソースコードを見てまず驚いたのは、自動テストが一切ないことだった。簡単なユニットテストを書いてみたが、MeshCoreチームからは誰も返信がなく、約2ヶ月が経っている。

ざっと眺めた感じでは、コードベースは散らかっているが、とんでもなくひどいというほどではない。C++で書かれており、ほとんどのクラスは20以上の非privateな関数やフィールドを持つ広いインターフェースを持っているが、これは組み込みソフトウェアのプロジェクトではよく見かけることだ。

もう一つのコードの異臭は、僕のユニットテストが呼び出す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ファイルを使うことを、メンテナーが「コミット時に自分のIDEが不要な変更をしないようにするだけでいい」というガイダンスとともにクローズした。

なぜだ？2025年にもなって、なぜローカルスタイルに合わせて中括弧の位置を考えなければならないのか？フォーマッターを設定して、そんな退屈なスタイルのことを考えずに済むようにしてほしい。

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

もともとT-DeckのUIを理解するためにMeshCoreのソースを掘り下げ始めたのだが、そのコードが見つからなかった。MeshCoreのAndroidアプリやウェブアプリのソースも見つからない。

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

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

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

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

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

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

僕はオープンソース至上主義者ではなく、ソフトウェアがプロプライエタリであること自体は構わないと思っている。ただ、オフグリッド通信の要点は分散化と技術的な自由にあるので、クローズドソースのソリューションには賛同できない。

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

まとめ

最後に

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

MeshCoreを再訪する可能性はあるが、オープンソースのクライアントと使いやすさの改善を待ちたい。

MeshCoreの気に入った点

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

MeshCoreの気に入らなかった点

• 公式のMeshCoreクライアントがすべてクローズドソースでプロプライエタリである。
  • 追記（2026-01-13）：現在は非公式のオープンソースクライアントが存在する
• ユーザー体験が脆すぎて緊急時に頼ることができない。特にMeshCore初心者と連絡を取ろうとする場合にはなおさらだ。
• ほとんどのハードウェアはスマホとBluetoothでペアリングすることを前提としており、障害点や複雑さが大幅に増える。
• 唯一の公式スタンドアロンデバイスはT-Deck+だが、混乱してイライラさせられる使い勝手だった。
• 文章による入門ガイドが存在しない。
  • FAQはあるが、整理されていない細切れの情報の寄せ集めだ。
  • 優れた非公式の入門動画はあるが、僕はテキストのドキュメントの方が好みだ。