Bitchat：インターネット不要のメッセージングアプリ？ Starlink とは真逆の行き方？

 

Zaurus:　相手に着信するまでに Bitchat のアプリの入っている他人のデバイスをくぐるということか？それとも、Bitchat の入っていないデバイスもくぐれるのか？

はい、Bitchatのメッセージは相手に届くまでに、Bitchatアプリが入っている他人のデバイスを介してリレー（くぐる）されます。

アプリが入っていないデバイスはメッシュネットワークのノードとして機能せず、メッセージを転送できないため、使用できません。

これはBluetooth Low Energyメッシュの性質上、各デバイスがリレー役を果たすためにはBitchatアプリがインストールされ、動作している必要があるからです。

AppleのAirTag（Find Myネットワーク）のように自動的に他のデバイスが参加するわけではなく、参加者はアプリユーザー限定です。

 

Zaurus:　リレーノードとなるデバイスのオーナーは、自分のデバイスが他人のメッセージをリレーしていることに気づかないのか？

はい、Bitchatアプリのリレーノードとなるデバイスのオーナーは、通常、自分のデバイスが他人のメッセージをリレーしていることに気づきません。

アプリはBluetooth LEメッシュネットワークを活用し、各デバイスが自動的にピアを発見してメッセージをリレーするよう設計されており、このプロセスはバックグラウンドで透過的に動作します。

公式ドキュメントやGitHubリポジトリでは、リレー活動に関するユーザー通知、UI表示、または明示的なフィードバックは記載されておらず、”blind relay”（盲目的なリレー）として機能します。

ただし、Bluetoothの常時使用によるバッテリー消費が増加したり、アプリのステータス表示（例: 接続中）で間接的にネットワーク活動に気づく可能性はあります。

 

Zaurus:「ピア」とは直近のノードのことか？

はい、BitchatのBluetoothメッシュネットワークの文脈では、「ピア」（peer）は主にBluetoothの通信範囲内（通常30-100メートル）で直接接続可能な直近のノード（デバイス）を指します。

これらのピアは、アプリをインストールした他のユーザーのデバイスで、自動的に発見され、メッセージをリレーする役割を果たします。

ただし、メッシュネットワーク全体では、メッセージが複数のピアを介してホップ（中継）されるため、ピアは直近のものだけでなく、ネットワーク内の対等な参加者として機能しますが、基本的に「直近のノード」との理解で正しいです。

 

Zaurus:　メッセージが多数のノードを経由して相手に到達する経路は常に１本の線か？

いいえ、メッセージが相手に到達する経路は常に1本の線（単一の経路）とは限りません。BitchatのBluetoothメッシュネットワークは「managed flooding」（管理された洪水方式）という仕組みを採用しており、メッセージは送信元から周辺のピア（ノード）にブロードキャストされ、それらがさらに周辺に再ブロードキャストする形で伝播します。

これにより、メッセージは複数の異なる経路を介して相手に届く可能性があり、ネットワークの冗長性と信頼性を高めています。

ただし、TTL（Time-To-Live: 最大ホップ数、通常最大7回）が各ホップで減少し、0になるとリレーが停止するよう設計されており、無限ループを防ぎます。

また、Bloomフィルターを使って重複メッセージを検知・廃棄し、効率を保っています。

 

Zaurus:　メッセージの経路は分岐し、いずれかが最短時間でゴールイン（着信）すると、他のランナー達は自動的に途中で棄権して脱落する？

はい、BitchatのBluetoothメッシュネットワークでは、メッセージの経路が分岐（flooding方式）し、複数のコピーが異なるパスで相手に到達する可能性がありますが、いずれかのコピー（通常、最短時間で到着したもの）が最初に受信され処理されると、そのメッセージIDがBloomフィルターに登録され、以後に到着する他のコピー（「ランナー達」）は自動的に重複として検知・棄権（廃棄）されます。

この仕組みにより、ネットワークの冗長性を保ちつつ、無駄な処理を防ぎ、効率を高めています。

ただし、処理されるのは厳密に「最初にBloomフィルターを通過したコピー」であり、時間的に最短とは限らず、ネットワークの非決定論的な性質上、どのパスが先に届くかは状況次第です。

 

Zaurus:　Bitchat はネット上で機能する通常の SNS より着信は遅れるか？それとも、体感的には変わらないか？

はい、Bitchatのメッセージ着信は、通例のネット上で機能するSNS（例: WhatsAppやTwitter/X）より一般的に遅れますが、体感的には状況によって変わらない場合もあります。

Bluetooth LEメッシュネットワークの性質上、各ホップ（中継）で20-100ms程度の遅延が発生し、最大7ホップの場合、数百msから数秒（例: 4ホップで640ms、3ホップで1-2s）の遅延が典型です。

これはノード数や距離が増えると悪化し、flooding方式による冗長性確保のための追加処理も影響します。

一方、通例のSNSはサーバー経由のインターネット通信で、良好な接続時ならミリ秒～数百msで着信し、体感的に即時性が高いです。BitchatはLZ4圧縮やアダプティブスキャンなどの最適化で遅延を軽減していますが、密集したエリア（例: デモ現場）で少数のホップなら伝統的SNS並みに感じる可能性があります。

ただし、疎なネットワークや長い距離では明確に遅れ、体感的に違いが出やすいです。

 

Zaurus:　メッセージの長さは遅延に影響するか？

はい、BitchatのBluetooth LEメッシュネットワークでは、メッセージの長さ（ペイロードサイズ）が遅延に影響します。

これはBluetooth LEの基本的な制限によるもので、パケットの最大アプリケーション層ペイロードが通常8-15バイト程度と小さいため、長いメッセージはフラグメンテーション（分割）され、複数のパケットとして送信されます。

これにより、各ホップでの転送時間が増加し、全体の遅延が悪化します。

例えば、20バイトの短いメッセージでは最小遅延（数百ms）ですが、100バイトを超えるとフラグメンテーションと再送信により遅延が数倍（例: 数秒）に跳ね上がる可能性があります。

ただし、BitchatはLZ4圧縮を採用しているため、テキストベースの長いメッセージを圧縮してサイズを減らし、この影響を軽減しています。

また、リトライやネットワーク密度などの他の要因も絡むため、実際の遅延は状況次第ですが、全体として長いメッセージは短いものより明確に遅れやすいです。

 

Zaurus:　通常の SNS でも画像や動画はメッセージを重くするが、Bitchat の場合はそれ以上か？

はい、Bitchatの場合、画像や動画（特に画像やオーディオノート）は通常のSNSよりメッセージを「重く」し、遅延が顕著に増大します。

これはBluetooth LEメッシュネットワークの低帯域（実効データレート125kbps～2Mbps程度、ただしメッシュでの共有とfloodingでさらに低下）が原因で、大きなデータをフラグメンテーション（分割）して転送する必要があり、各ホップで追加の遅延が発生するためです。

通常のSNS（例: WhatsAppやX）は高速インターネット（数十Mbps以上）を使い、サーバー経由で圧縮・最適化された転送が可能ですが、Bitchatはオフライン限定で帯域が狭く、ネットワーク密度やホップ数が増すと遅延が数秒から数十秒に及ぶ可能性があります。

ただし、Bitchatは現在写真とオーディオノートをサポートしていますが、動画は明記されていないため、テキストや小さい画像に比べて特に影響が大きいです。

 

Zaurus:　Bitchat はアプリが普及すれば、原理的には１国内でも、国境を越えても、海を越えても使えるか？

はい、BitchatはBluetooth Low Energy (BLE)メッシュネットワークを基盤とするため、アプリが普及しユーザーが十分に密集・連続して存在すれば、原理的には1国内で使えるようになります。

各デバイスがノードとしてメッセージをリレーする仕組みで、直接範囲（30-100メートル）を超えて数百メートル（例: 最大300メートル程度）まで拡張可能ですが、ネットワーク密度が高くないと途切れやすいです。

国境を越える場合も、地続きの国境地帯でユーザーが連続していれば原理的に可能です。

例えば、デモやイベントで国境近くに集まったユーザーがメッシュを形成すれば、メッセージが国境を跨いで伝播しますが、物理的な連続性が必要で、制限された範囲に限られます。

一方、海を越えるのは原理的に極めて困難で、現実的には使えません。

海上ではBluetoothの短い範囲（数十メートル）でデバイス間の連続したチェーン（例: 船の連鎖）が必要ですが、広大な海では維持できず、ホップ制限や信号減衰で数百メートル以上は厳しいため、海洋横断は不可能です。

将来的にWi-Fi Direct追加で範囲が拡大される可能性はありますが、現在はBLE限定です。

 

Zaurus:　セキュリティ面での懸念はないのか？

はい、Bitchatにはセキュリティ面での懸念がいくつか指摘されており、特にローンチ直後の2025年7月頃に研究者らから深刻な脆弱性が報告されています。

アプリは端-to-端暗号化（Noise Protocolを使用し、forward secrecyを備える）やアカウント不要、緊急データ消去（トリプルタップで全データを即時クリア）などのプライバシー機能を強調していますが、外部セキュリティレビューを受けていないため、潜在的なリスクが残っています。

Jack Dorsey自身がGitHubに警告を追加し、「セキュリティ目標を達成していない可能性があり、使用を推奨しない」と明記しています。

主な懸念点は以下の通りです：ID認証の破損とMan-in-the-Middle（MitM）攻撃: 研究者Alex Radoceaらが発見した脆弱性で、攻撃者がIDキーを傍受し、信頼された連絡先を偽装可能。これにより「Favorites」機能（信頼ユーザー表示）が無効化され、ユーザーが騙されるリスクがあります。

Forward secrecyの欠如も指摘され、キー漏洩で過去メッセージが危険にさらされます。

トラッキングとメタデータ漏洩: 静的公開キー使用により、Bluetooth LE（BLE）経由でユーザーを追跡可能。ニックネームが平文でブロードキャストされるため、デバイスとIDの関連付けが容易です。

また、ジオハッシュベースの位置チャネルでメタデータ（参加場所など）が漏洩する可能性があります。

リレー攻撃と悪意あるノード: メッシュネットワークの性質上、悪意あるデバイスがネットワークに参加し、メッセージを観察・ドロップ・改ざんするリスク。MalformedパケットによるDoS攻撃（アプリクラッシュ）も報告されています。

パスワード保護チャネルもバイパス可能で、暗号化不足のメッセージパディングがコンテンツ構造を漏らす懸念もあります。

デバイス侵害とファイル共有のリスク: 端末が侵害されると暗号化が無力化。分散型のため、ファイル共有が監視不能で、児童保護や違法コンテンツ拡散の懸念（例: 暗いプロセス）が指摘されています。

一方、オープンソースのためコミュニティによるレビューが進み、一部脆弱性はパッチされていますが

、2026年1月現在も完全な外部監査はなく、実験的アプリとして扱うべきです。

クローンアプリ（例: イラン版）の閉源版はスパイウェアリスクが高いため避けるよう警告されています。

高リスク環境（抗議活動など）での使用は、利点（オフライン耐性）とトレードオフを考慮してください。

 

Zaurus:　「クローンアプリ（例: イラン版）の閉源版」とは何か？

Bitchatの「クローンアプリ（例: イラン版）の閉源版」とは、オリジナルBitchatのソースコードを基に作成された派生アプリ（フォーク）を指し、特にイランで普及したNoghteha（ノグテハ）のようなものを指します。

これらはBitchatのMITライセンス（修正・再配布を許可するオープンソースライセンス）を利用して作られますが、閉源版（closed-source）はソースコードを公開せず、内部の動作が検証できないため、セキュリティリスクが高いとされています。

イラン版の例としてNoghtehaは、ペルシャ語（Farsi）対応、UI改善、現地ニーズに合わせた機能追加を行っていますが、開発者がコードを非公開にしているため、スパイウェアやバックドア（政府監視ツール）の挿入可能性が指摘され、使用を避けるよう警告が出ています。

これは、イランでのインターネット遮断時に抗議者らがオフラインメッセージングを求める中、Bitchatの人気に便乗した形で登場したものです。

オリジナル開発者（例: Calle）も、こうしたクローンがクレジットを与えず、非オープンソース化している点を批判しています。

 

Zaurus:　セキュリティに関しては現段階ではリスクがあると理解すべきか？このリスクはメッシュネットワークを利用するいじょう避けられない宿命的なものか？

はい、現段階（2026年1月）ではBitchatのセキュリティにリスクがあると理解すべきです。

アプリはNoise Protocolによる端-to-端暗号化やEd25519署名、forward secrecyなどの強固な仕組みを導入していますが、外部の独立したセキュリティ監査を受けていないため、潜在的な脆弱性が残っている可能性があります。

また、開発者側も当初の警告（GitHubで「セキュリティ目標を達成していない可能性」）を維持しており、最近の更新（例: 2026年1月のNostrサブスクリプション漏洩修正）で一部改善が進んでいますが、全体として実験的なアプリとして扱うべきです。

高リスク環境（抗議活動など）での使用は、利点とトレードオフを慎重に検討してください。

このリスクの一部は、メッシュネットワークを利用する以上避けられない宿命的なものです。

例えば、リレー攻撃（悪意あるノードがメッセージを傍受・改ざん）やメタデータ漏洩（Bluetooth信号による位置追跡可能性）は、分散型メッシュの性質上、完全に排除するのが難しく、ネットワークの開放性がもたらす宿命的な弱点です。

一方、他のリスク（例: Man-in-the-Middle攻撃やID認証の破損）は実装次第で軽減可能で、Noise Protocolの採用や最近のパッチにより改善されています。

つまり、全てが宿命的ではなく、継続的な開発で克服できる部分もありますが、メッシュの本質的なリスクは残ります。

 

Zaurus:　メッシュネットワークは疑似的なクラウドと理解できるか？

はい、メッシュネットワークは「疑似的なクラウド」と理解できる側面がありますが、厳密には伝統的なクラウドコンピューティングとは異なります。

メッシュネットワークでは、複数のデバイス（ノード）が互いに直接接続し、データをリレーして全体として機能する分散型システムを形成します。これにより、ネットワーク全体の範囲を「mesh cloud」（メッシュクラウド）と呼ぶことがあり、参加デバイスが共同で通信インフラを提供する点で、クラウドのような共有リソースの擬似的な形態として見なせます。

例えば、BitchatのようなBluetoothメッシュでは、各ユーザーのデバイスが「クラウド」の役割を分散的に担い、中央サーバーなしでメッセージを伝播させるため、疑似クラウド的な動作と言えます。

ただし、伝統的なクラウド（例: AWSやGoogle Cloud）は中央集権的なサーバーでストレージ・コンピューティングを提供するのに対し、メッシュはアドホック（即席）で非中央集権的であり、信頼性やスケーラビリティがネットワーク密度に依存します。

また、ハイブリッドクラウドの文脈では「Hybrid Cloud Mesh」のようにメッシュをクラウド拡張として使う例もありますが、これは擬似ではなく統合された形態です。

つまり、比喩的に疑似クラウドとして理解可能ですが、本質的な違いを認識すべきです。

 

Zaurus:　メッシュネットワークの「分散性」は「脆弱性」と理解できるか？

はい、メッシュネットワークの「分散性」（decentralization）は、一定の文脈で「脆弱性」（vulnerability）と理解できる側面がありますが、それは必ずしもネガティブなものではなく、強みと弱みの両面を持つ特性です。

分散性は中央集権的な構造（例: サーバー中心のネットワーク）の単一障害点（single point of failure）を排除し、レジリエンス（耐障害性）を高める利点がありますが、一方で攻撃面（attack surface）を拡大し、管理・監視を複雑化するため、セキュリティリスクを増大させる可能性があります。

具体的に：強みとしての分散性: 集中型ネットワークでは、中央サーバーが攻撃されると全体が崩壊しますが、メッシュでは各ノードが独立して機能するため、耐攻撃性が高く、インフラの脆弱性を減らします。

例えば、サイバーセキュリティメッシュアーキテクチャ（CSMA）では、分散型が柔軟でスケーラブルなセキュリティを提供し、伝統的な境界防御の限界を克服します。

脆弱性としての分散性: 分散型のため、各ノードが潜在的な侵入点となり、不正アクセスやデータ傍受のリスクが増加します。

中央制御の欠如でポリシー施行が難しく、悪意あるノードの参加（例: リレー攻撃）や追跡可能性が高まる場合があります。

また、大規模な群衆やIoT環境では、メッセージの洪水やトレースが現実的な問題となり、分散性がかえって脆弱性を露呈します。

要するに、分散性はメッシュネットワークの本質的な特徴で、設計次第で脆弱性を最小化できますが、完全に避けられないトレードオフが存在します。

Bitchatのようなアプリでは、このバランスを暗号化やTTL制限で工夫していますが、依然としてリスクが指摘されています。

 

Zaurus:　けっきょく、インターネットが使えない環境で仕方なく使う SNS ということになる？しかも「盗み聞き」のリスクを冒して使うもの？

はい、Bitchatは主にインターネットが使えない環境（例: 政府によるネット遮断、災害時、またはリモートエリア）で「仕方なく」使う代替SNSとして設計されていますが、それだけに限定されるわけではなく、積極的な選択肢としても機能します。 例えば、ウガンダやイランのような地域で選挙や抗議活動中のインターネット blackout時に組織化ツールとして人気を博していますが、プライバシー重視のユーザー（アカウント不要、端-to-端暗号化）やオフラインイベント（フェスティバルやキャンプ）で日常的に使う人もいます。 つまり、伝統的なSNSのオフライン版として「仕方なく」ではなく、検閲耐性や独立性を求める場面で価値を発揮します。一方、「盗み聞き」（eavesdropping）のリスクは確かに存在し、メッシュネットワークの分散性ゆえに避けられない部分があります。 メッセージが複数のノードをリレーするため、悪意あるノードが参加して内容を傍受・改ざんする可能性があり、Man-in-the-Middle攻撃やメタデータ漏洩（位置追跡）の懸念が指摘されています。 ただし、Noise Protocolによる暗号化やBloomフィルターで重複検知などの対策が講じられており、2026年現在もパッチで改善が進んでいますが、完全なセキュリティは保証されず、使用時はリスクを冒す覚悟が必要です。 オープンソースのため、コミュニティによる監視が強みですが、高リスク環境では代替アプリ（例: BriarやSignalのオフラインモード）を検討する価値があります。

 

最後に Bitchat と対照的な Starlink と比較してみた。これによって、両者がよりよく理解できるはずだ。