Librepods が解いた AirPods の非公開プロトコルと、壊れる前提の運用設計

Librepods は AirPods の非公開プロトコルを Linux と Android に開く

結論から書くと、Librepods は Apple が公開していない AirPods の通信プロトコル（Apple Accessory Protocol、AAP）を解析し、ノイズキャンセル切替・バッテリ表示・耳検出といった機能を Linux と Android で動かす OSS です。2026 年 6 月時点で GitHub の star は 28,000 を超え、Hacker News でも 243 点を集めました。

純正の体験は、iPhone か Mac の設定アプリの中で完結します。ケースを開けば残量が出て、ステムの長押しでノイズキャンセルが切り替わる。あれが「ただ動く」のは、AirPods と Apple デバイスのあいだで非公開のプロトコルが走っているからです。Librepods はそのプロトコルを外から読み解き、Apple ではない OS に同じ操作を持ち込みます。

ライセンスは GPL-3.0。Linux 側は Rust、Android 側は Kotlin で書かれています。README には Apple とは無関係だと明記されていて、これは商標やリバースエンジニアリングの線引きを意識した、よくある防御線です。

どこまで動いて、どこから先は動かないか

先に期待値を下げておくと、Librepods で動くのは「設定アプリでできる範囲」が中心で、Apple のクラウドやハードウェア固有機能には踏み込めません。

動く機能は、リスニングモード（オフ / ノイズキャンセル / 外部音取り込み / アダプティブ）の切替、耳検出による自動再生・停止、バッテリ残量表示、デバイス名の変更あたり。Android では加えてヘッドジェスチャやヒアリングエイドのカスタマイズも入ります。会話感知（Conversational Awareness、話し始めると音量を自動で下げる機能）は Linux / Android の両方で動きます。

機能	Linux	Android
リスニングモード切替	✅	✅
耳検出	✅	✅
バッテリ表示	✅	✅
デバイス名変更	✅	✅
ヘッドジェスチャ	❌	✅
会話感知	✅	✅

逆に動かないものもはっきりしています。Find My による位置追跡、空間オーディオのヘッドトラッキング、心拍計測、そして高品質な双方向オーディオ。このあたりは Apple のサーバ側処理や独自の音声経路に依存していて、プロトコルを読めても再現できません。機能の半分はイヤホンのハードに載っているのに、残り半分はエコシステムの外に出た瞬間に消える、と言い換えてもいいでしょう。

仕組み — AAP を L2CAP の上で話す

仕組みの核心は、AAP を L2CAP（Bluetooth のロジカルチャネル層）の上でやり取りし、短いバイト列でコマンドを送り合うことにあります。難しい暗号化があるわけではなく、フォーマットを知っているかどうかの勝負です。

例えばリスニングモードの切替は、opcode 0x0D を使った 11 バイトのパケット 1 本で済みます。ドキュメント化されている形はこうです。

04 00 04 00 09 00 0D [mode] 00 00 00

04 00 04 00 がヘッダ、09 00 が制御コマンド（control command）の opcode、0D がリスニングモード設定を指します。[mode] のところに 01（オフ）、02（ノイズキャンセル）、03（外部音取り込み）、04（アダプティブ）を入れる。ノイズキャンセルにしたければ、実際に飛ぶのは次の一本です。

04 00 04 00 09 00 0D 02 00 00 00

耳検出のトグルは opcode 0x0A、バッテリ報告は 0x0004 と、機能ごとに opcode が割り当たっています。AAP の opcode 表は 0x0001 から 0x0053 あたりまで並んでいて、解析の成果がそのまま辞書になっている。余談ですが、こういう生のバイト列を眺めていると、暗号化されていないプロトコルが今どきまだ身近にあることに少し驚きます。Wireshark でキャプチャを開いて 1 バイトずつ意味を当てていく作業は、地味ですが確実に前に進む種類の楽しさがあります。

もう一段踏み込むと、VendorID を bluetooth:004C:0000:0000 に偽装して Apple デバイスのふりをすることで、本来は制限されている機能が開くという話もあります。ただし Android でこれをやるには root か Xposed が要る。つまり OS の根を触る前提になり、安定性のリスクと引き換えになります。

reverse-engineered な相棒を運用するということ

ここからが運用の話です。Librepods のような reverse-engineered companion は「いつ壊れてもおかしくない」前提で付き合うべきで、壊れたときに自分の作業が止まらない構成にしておくのが鍵になります。

壊れる引き金は、たいていベンダ側のファーム更新です。Apple が AirPods のファームを更新し、パケットのフォーマットや opcode の意味が変われば、解析済みの辞書はその日からずれる。公式ドキュメントが無い以上、変更の予告も互換性の保証もありません。動いていたものが、ある朝とつぜん無反応になります。

だから私は、本番のワークフローを Librepods に依存させません。会議に出る日のノイズキャンセルや、聞き逃せない通話の自動停止を、リバースエンジニアリングされたツールに預けるのは怖い。手元の Ubuntu ノートで AirPods Pro を使うとき、Librepods は「あれば快適な拡張」であって、「無いと困る土台」にはしない。これは過去にサードパーティの非公式ツールがアップデートで一晩にして死ぬのを何度か見てきたからで、特別に悲観的なわけではありません。

運用として現実的なのは、効いているファームと Librepods のバージョンを記録しておくこと、更新は様子を見てから当てること、壊れたら純正環境（iPhone / Mac）に一時的に戻せる導線を残しておくこと。この三つを守るだけで、壊れた日のダメージはかなり下がります。動かないときにだけ存在に気づく、という意味では、こういうツールは縁の下の配管に近いものです。

プロトコル解析が露わにする相互運用性とロックイン

最後に、技術より少し広い話を一つ。Librepods が面白いのは機能そのものより、ノイズキャンセルという機能はイヤホンの中に既にあるのに、それを開けるかどうかが OS で決まっている、という構造を可視化したことです。

ハードウェアには能力がある。けれどその能力へのスイッチは、ベンダのエコシステムの内側に置かれている。Librepods はそのスイッチを外から押す方法を見つけた、とも言えます。これは相互運用性（interoperability、異なる製品同士が連携できること）の主張であると同時に、ベンダロックインの輪郭をくっきりさせる行為でもあります。

私はこの手の「公式に外れた相互運用」を、善悪というより設計の観察対象として見ています。同じ姿勢で以前 重複を恐れず、間違った抽象から逃げる でも書きましたが、運用者の仕事は「正しさ」を一意に決めることではなく、壊れたときに戻せる余地を残しておくことです。Librepods を使うかどうかも、最後はそこに落ちます。便利さを取りに行くなら、壊れる前提と復帰経路をセットで持つ。それだけの話です。