Bitchat削除命令 — 政府はコードの流通を止められるのか
Bitchat削除命令 — 政府はコードの流通を止められるのか
ネットワークを使わないアプリをネットワーク遮断で止められないなら、国家はコードの流通経路を狙う。その戦略は有効なのか、それとも単なるストライサンド効果の引き金なのか。
導入
2026年7月24日、インドの有力紙The Hinduは、インド政府がGitHubに対しBluetoothベースのチャットアプリBitchatのリポジトリ削除を命じたと報じた。この事実は、Bitchatの開発を主導してきたJack Dorsey — Twitter共同創業者でBlock CEO — が公表したことで明らかになった。政府命令書が挙げた削除理由はこうだ。「このアプリはネットワーク制限中でも通信を可能にし、反国家勢力、テロ組織、組織犯罪集団、サイバー犯罪者が合法的傍受を回避し、法的に課された制限にもかかわらず通信を継続する実質的リスクを生む」。
この文章はそれ自体が分析対象である。命令書が問題視しているのはBitchatの脆弱性や違法コンテンツではなく、政府が統制できない通信手段が存在するという事実そのものだからだ。Hacker Newsでこのニュースは541ポイント、438コメントを集めて終日トップページに留まり、同じ週のGitHubトレンドでは permissionlesstech/bitchat リポジトリが1日2,300以上のスターを獲得して1位に立った。削除命令が最高の宣伝になったわけである。
この事件は「政府対ビッグテック」という見慣れた構図ではなく、より根本的な問いを投げかける。インターネットインフラを迂回するよう設計されたソフトウェアを、国家は何によって止められるのか。
遮断すべきネットワークが存在しないという問題
Bitchatの技術構造を見れば、インド政府がなぜGitHubという迂回路を選んだのかが理解できる。Bitchatは2025年夏にDorseyの週末プロジェクトとして始まったアプリで、インターネット接続なしにBluetooth Low Energy(BLE)のメッシュネットワークだけでメッセージを届ける。サーバーがなく、アカウントがなく、電話番号もメールアドレスも要求しない。メッセージは近くの端末をリレーノードとしてホップ単位で伝播する。
この構造は国家の伝統的な遮断手段の大半を無力化する。通信キャリアに遮断を命じることはできない — キャリア網を使わないからだ。DNSブロックもIPブロックも意味がない — 接続すべきサーバーがないからだ。アカウント凍結も不可能だ — アカウントがないからだ。残るのは二つ。アプリストアからアプリを下ろさせること、そしてソースコードの流通自体を止めること。インド政府のGitHub削除命令は後者である。
文脈も重要だ。HNスレッドで複数のコメンターが指摘した背景 — 要旨をまとめると — は、現在インドのラダック地方で気候活動家Sonam Wangchukが率いる大規模な非暴力デモが進行中で、政府がデモの拡散を防ぐため地域のインターネット遮断を繰り返してきた、というものだ。インターネット遮断下でも動作するメッシュチャットアプリは、この統制体系の穴になる。あるコメンターは、インドの通信統制が2008年のムンバイ同時多発テロ以降強化されてきた歴史を指摘した — 実行犯が衛星電話で攻撃を調整したため、以降インドは大半の衛星通信機器を禁止し、今でも乗り継ぎ旅行者が預け荷物にGarmin inReachのような衛星メッセンジャーを入れていて拘束される事例が報告されているという (HNコメント要旨)。
つまり今回の命令は突発的な行動ではなく、「すべての通信は傍受可能であるべきだ」というインド通信政策の一貫した延長線上にある。1990年代後半、通信業界のカンファレンスでインド政府代表がVoIPへの対応を問われ、真顔で「許可しない」と答えたという逸話がHNスレッドで語り草になったのも同じ文脈だ (HNコメント要旨)。VoIPも、衛星電話も、エンドツーエンド暗号化メッセンジャーも、毎回「許可しない」から始まった。変わったのは相手である。衛星電話はハードウェアだから税関で押収できる。WhatsAppのような中央集権型メッセンジャーは事業者に圧力をかけられる。BitchatはGitHubで git clone 一発で複製されるオープンソースコードであり、事業者もサーバーもない。
技術的に補足すると、Bitchatのメッセージはエンドツーエンドで暗号化されたままストア・アンド・フォワード方式で伝播する。受信者が範囲外にいれば中間ノードが暗号文を保管して再転送し、中間ノードは自分が運ぶメッセージの内容を読めない。傍受ポイントを作るにはプロトコル自体を変える必要があるが、プロトコルは公開されたコードだ。結局、政府が介入できるのはコードが人に届く経路だけ、という結論になる。
GitHubというチョークポイント、そしてその限界
インド政府の選択は逆説的に正確な判断だった。分散型通信アプリのアキレス腱は通信レイヤーではなく流通レイヤーである。どれほどサーバーレスなアプリでも、ユーザーがアプリを入手する経路 — アプリストア、そして開発が行われるコードホスティング — は中央集権化されている。Apple App StoreとGoogle Playは各国政府の要請で地域別にアプリを下ろした前例が多く、GitHubも国別の法的要請に応じてリポジトリを地域ブロックしてきた透明性レポートを出している。国家にとってGitHubは数少ない有効なチョークポイントだ。
しかし今回の事例は、そのチョークポイントの有効期限が切れつつあることを示している。削除命令が報じられてから1日で起きたことを時系列で見よう。第一に、HNスレッドが炎上してリポジトリのリンクが数十万人に露出し、リポジトリは報道時点でも削除されずに生きていた。第二に、リポジトリがGitHubトレンド日間1位に立った — 本稿執筆時点で1日2,346スター。第三に、7月25日にBitchatプロジェクトはP2PコードホスティングプロトコルRadicleにミラーを公開した。RadicleはGitリポジトリを中央サーバーなしにノード間複製で流通させるシステムで、こうなると「削除を命じる対象」そのものが消滅する。
Radicleへの移行は技術的にも興味深い。Radicleではリポジトリが自己認証(self-certifying)識別子を持ち、ノード同士が関心のあるリポジトリをシードし合う。BitTorrentがファイル流通で果たした役割をGitコラボレーション全般に拡張した構造だ。Bitchat — それ自体がインフラなしの通信を志向するプロジェクト — が自らの流通経路までインフラなしの形に移したのは、プロジェクトの哲学と生存戦略が一致した稀有な事例である。
これは教科書的なストライサンド効果だ。あるHNコメンターの指摘は痛烈である — 要旨を写せば、デモ以前のBitchatのインド国内実ユーザーは微々たるもので、政府が無視していれば誰も知らなかったアプリを、政府自らが全国ニュースにしてしまった、というものだ。検閲耐性を設計目標とするソフトウェアにとって、検閲の試みは最高のプロダクト検証でありマーケティングである。
ただし楽観ばかりもしていられない。スター数と実利用は別物だ。BLEメッシュはノード密度が確保された都市部のデモ現場では機能するが、ノードが疎らな地域ではメッセージが届かない。そしてコードが生き残ることと、一般ユーザーがアプリをインストールできることも別問題だ。AppleがインドのApp Storeからアプリを下ろせば、サイドローディングが塞がれたiPhoneユーザーにとってGitHubのソースコードは事実上無意味である。流通レイヤーの検閲耐性はプラットフォームの開放性に従属する — これは同じ週にHNを賑わせたAndroidのオンデバイスADB制限の議論ともつながる問題だ。
GitHubの対応方式も注目に値する。GitHubは政府の法的要請に対し全面削除ではなく当該国内での地域ブロック(geo-blocking)で対応し、その内訳を github/gov-takedowns リポジトリで公開してきた。インドのユーザーには見えないが、他の世界には見えるという折衷案だ。しかしこの折衷は双方を満足させない。政府にとってはVPN一つで突破される遮断であり、開発者にとってはプラットフォームが国家単位の検閲執行者になる前例である。折衷の寿命が尽きるにつれ、双方が次の手段を探すことになる。
コード流通の次の局面
この事件が示唆するところを三つのレイヤーに分けて見よう。
政府側のシナリオ。 インドの試みが失敗に見えても、各国政府がコードホスティングプラットフォームに圧力をかける頻度は増えるだろう。英国のOnline Safety Act、EUのCSAMスキャン論議、そして各国の「合法的傍受」要求は、いずれもエンドツーエンド暗号化・分散型通信と正面衝突する軌道にある。GitHubのようなプラットフォームは国別ブロックという折衷で対応してきたが、折衷が通じない事例が積み重なれば「コード自体を違法化」する立法の試みが出てくる可能性がある。1990年代米国の暗号輸出規制 — PGPのソースコードを書籍として印刷して輸出したことが憲法修正第1条の論争になった — の再演だ。
開発者側のシナリオ。 検閲リスクのあるプロジェクトの流通多角化が標準プラクティスになるだろう。BitchatのRadicle移行は象徴的だ。Git自体が分散VCSであるにもかかわらず、我々はこの15年間GitHubという単一ハブに開発フローを集中させてきた。フォークとクローンは検閲に強いが、Issue・PR・リリースといったコラボレーションのメタデータはプラットフォームに閉じ込められている。Radicle系のP2Pフォージがそのメタデータまで複製可能にすれば、「リポジトリ削除命令」という概念自体が時代錯誤になる。
ユーザー側の現実。 それでもボトルネックは結局端末である。メッシュネットワーキングアプリの実効性はインストールベースの密度に比例するが、インストール経路は二大アプリストアが握っている。政府が学習すれば次の標的はコードホスティングではなくアプリストアになるだろうし、その戦線ではプラットフォーム事業者の抵抗インセンティブははるかに弱い。検閲耐性通信の未来は暗号学ではなく、端末開放性の規制 — EU DMAのサイドローディング義務化のような — にかかっているという逆説が成立する。
結論
「政府はコードの流通を止められるのか」というリード質問に戻ろう。答えは条件付きだ。単一プラットフォームに閉じたコードなら止められる。しかしBitchatの事例が示すように、削除命令が公になった瞬間、コードは注目とともに複製されてプラットフォームの外に溢れ出す。国家が勝てる相手はコードではなく流通チャネルであり、流通チャネルの分散化が進むほど、残るチョークポイントはアプリストアと端末だけになる。
あるHNコメンターの言葉がこの事件の要約として適切だ — 要旨を写せば、国家の安全が市民間の私的メッセージをすべて遮断できる能力に依存しているなら、その政府はすでに市民に安全を提供するという本来の目標に失敗している、というものだ。傍受不可能な通信手段の存在を国家の脅威と規定した瞬間、すべての暗号化ソフトウェアとその開発者が潜在的な被告になる。次の削除命令がどのリポジトリに届くのか、そしてそのとき我々のコードはどこに何個の複製として存在するのか — オープンソースに関わる全員が自分事として問うべき質問である。
出典: