ソースより先に出たAPI — Android 17 QPR1と「オープンソースのAndroid」の時差

APIの表面は公開されたのに、その実装が三か月後に出てくるのなら、そのプラットフォームはなおオープンソースなのか、それとも「後から公開されるソース」を持つプロプライエタリなプラットフォームなのか?

導入

2026年9月16日、GrapheneOSプロジェクトが自らのMastodonアカウントに短い投稿を行った。Android 17 QPR1は、Android Honeycomb(3.x)以来初めて、Android Open Source Project(AOSP)へのリリースなしにアプリ開発者向けの新しいAPIを追加したリリースだという内容である。新APIは現時点でPixel OS専用であり、他のAndroid OEMには提供されていないとした。根拠として、Googleの開発者サイトにあるAPI差分レポート(APIレベル37から37.1への変更)がリンクされていた。

この投稿は9月18日(UTC)、Hacker Newsに「Android 17 is the first since 3.x to add new APIs without releasing to the AOSP」というタイトルで投稿され、1,180ポイントを集めた。日本時間では9月19日の未明にあたる。

タイトルだけを見ると「GoogleがAPIをPixel専用に囲い込んだ」と読める。しかしGrapheneOSのスレッドを最後まで読むと、話の形は異なる。問題は特定のAPIが恒久的にPixel専用だということではない。Androidのリリースのリズムそのものが「Pixelが先、残りは四半期後」へと再編され、その時差の中にAPIとセキュリティパッチまで入り始めたということである。本稿は、その時差がどのようなコストとして誰に降りかかるのかを整理する。

実際に何が変わったのか

まず事実関係を出典ごとに分けておく。

Googleの公式の立場はsource.android.comのサイト更新ページにある。同ページは、2026年からトランク安定開発モデルに合わせ、エコシステムのプラットフォーム安定性を確保するため、AOSPへのソースコード公開をQ2とQ4に行うと記している。ビルドとコントリビュートには android-latest-release マニフェストを使うよう案内しており、このマニフェストは現在 android17-release ブランチを指している。つまり年2回の公開は隠された方針ではなく、公表された方針である。

GrapheneOSの説明は、そこに具体的な帰結を付け加える。ある返信で彼らは、これらのAPIは「標準のAndroid API」であり、2026年12月のAndroid 17 QPR2を通じてAOSPと他のOEMにも提供されると述べた。現在Pixel専用なのは、Android 16以降QPR1とQPR3のリリースがPixel専用になったためであり、今回はその体制下で初めてQPR1またはQPR3にAPIが追加されたケースだという。

API差分レポート自体を開くと規模が見える。追加されたパッケージは android.hardware.hid の一つで、ACCESS_HID パーミッションが新設された。変更されたパッケージには android.hardware.input、android.health.connect.datatypes、android.media、android.os、android.provider、android.telecom、android.widget.photopicker などがある。新しいクラスとしては入力デバイスのカスタマイズ系(CustomizationTrigger、KeyCustomizationTrigger、ButtonCustomizationTrigger、AppCustomizationAction など)、EmbeddedPhotoPickerUiCustomizationParams、MediaStore.DeletedFiles などが見え、Health Connectには AlcoholConsumptionRecord が追加された。レポートの生成日時は2026年6月29日と表示されている。9月15日の正式リリースより二か月半前に、API表面はすでに確定していたと読むことができる。

Hacker Newsでは@jauntywundrkindが、このAPIがHIDである点に注目した(直接の引用ではなく、コメントの要旨の要約)。USB HIDの仕様には充電器やバッテリーの状態、各種センサーなど活用されていない機能が多く、AndroidのHIDサポート拡大は歓迎すべきだが、他者と一緒に作ってほしかったという趣旨である。同じユーザーは別のコメントで、これがPixel向けなのか、Chromebookのために急いで入れたものなのか気になるとも書いている。

要約すればこうなる。APIの数は多くなく、恒久的な独占でもない。しかし「APIドキュメントとSDKは公開、実装のソースは非公開」という期間が公式に生まれた。Honeycomb時代のソース非公開が例外的な事件だったとすれば、今回はそれがカレンダーに書き込まれた定例のスケジュールだという点が違う。

時差のコストは誰が払うのか

カスタムROM:「移植は終わったのに出せない」

GrapheneOSのスレッドで最も具体的なのは、自分たちの作業事情である。彼らは9月15日の正式リリース前にすでにAndroid 17 QPR1へコードを移植していたが、まだ公開の許可がないと書いた。そのため当面は、Pixelのファームウェア、カーネルドライバ、ユーザー空間ドライバ、HALをQPR1からAndroid 17へバックポートする作業をしているという。前へ進む代わりに後ろへ植え替えているわけである。

GPLの問題にも触れている。GrapheneOSは、Googleがまたしても数週間にわたりGPLソースの要求に応じなかったと主張し、9月1日に要求した CD1A.260905.001.A1 のソースを9月16日になってようやく受け取ったと書いた。カーネルのビルドIDが17 QPR1 Beta 9と同じなので、カーネル側はすでに持っていたという但し書きも付いている。この部分はGrapheneOS側の主張であり、Googleの反論は今回確認した資料にはない。

彼らの結論は逆説的である。Pixelはいまや他の多くのデバイスよりはるかにサポートが難しくなり、Pixelの数少ない利点の一つが欠点に変わったという。アップデートとセキュリティ機能ゆえに依然として最適ではあるが、プライバシーとセキュリティの作業に使いたい時間を食いつぶしているとした。一方、協業中のMotorolaのデバイスは公式のファームウェアとドライバのコードが提供されるため、このような問題はないと述べている。「Google純正ハードウェアこそ脱Google OSの最適な基盤」という長年の定式が揺らいでいる兆候である。

LineageOSのような他のAOSPベースのプロジェクトについては、今回の資料に直接の言及はない。ただしGrapheneOSは、Google以外のOEMとAOSPベースのプロジェクトは年次リリースとQPR2リリースを出荷でき、セキュリティのバックポートもあると整理したうえで、数か月の遅延なしにパッチを出すにはセキュリティプレビューへのアクセスが必要であり、自分たちはMotorolaとの協業以前から別のOEMを通じてそれを持っていたと述べた。この文を裏返して読めば、そうしたアクセスを持たないプロジェクトは遅延をそのまま受け入れるしかないということになる。

セキュリティパッチ:本当の争点はAPIではない

Hacker Newsで最も多くの共感を集めた分析は@bri3dのものだった(直接の引用ではなく、コメントの要旨の要約)。構造を整理すると、Googleは半期ごとに「本物」のソース更新をOEMと一般に出し、Pixelにはドキュメントと SDK を含むアップデートを年4回出す。今回、Pixel専用のアップデートに新しいAPIが入った。しかしPixelの市場シェアは小さいため、アプリ開発者がこのAPIに依存する可能性は低く、結果としてPixelが一四半期後に一般のデバイスへ来る機能のベータテスト機になるだけだという見方である。むしろ見出しはより深い問題を埋もれさせていると彼は指摘した。四半期ごとのPixelリリースに月次バックポートにないセキュリティ修正が含まれているなら、Pixelのリリースをパッチ差分解析してエクスプロイトを逆算できるので、非常にまずいということだ。

GrapheneOSのスレッドには実際にその主張がある。2026年9月のPixel Update Bulletinには、Pixel以外のデバイスも使う標準Androidプラットフォームのコンポーネントへの追加パッチがあるが、それは9月のAndroid Security Bulletinにもプレビューパッチにも含まれていないという。他のOEMは12月のQPR2を通じてようやく受け取ることになり、GrapheneOSはコードをリバースエンジニアリングして先に出荷できるとした。あるMastodonユーザーが、AIによる高速なリバースエンジニアリングの時代にセキュリティ修正を出すことは脅威アクターに脆弱性を開示するのと同じではないかと問うと、GrapheneOSはそうだと答え、数か月隠しても大して隠れていないのに、セキュリティプレビューの仕組みは何を達成しようとしているのか疑問だと述べた。

ここが今回の件の核心である。バイナリはすでに無数のPixelに配布されている。攻撃者にとってバイナリの差分は十分な情報だ。ところが防御側、つまり他のOEMとカスタムROMはソースを受け取れず、同じ差分を公式の経路で反映できない。ソース公開を遅らせることは攻撃者にはほとんど障壁にならず、防御者にだけ障壁になるという非対称である。GrapheneOSが、Googleの法務チームはPixelに新機能とセキュリティパッチへの数か月の先行アクセスを与えていることを把握しているのか知りたいと書いたのも、この構造がOEMパートナーとの関係において競争上の問題になりうるという問題提起である。

ただし反論もある。Hacker Newsで@mdwrigh2は、主要なOEMはごく短い遅延で内部のソースにアクセスでき、OEMが中間リリースを出さないのはGoogleがソースを止めているからではなく自ら選んでいるのだと反論した(直接の引用ではなく、コメントの要旨の要約)。これが正しければ「OEMから隠している」という枠組みは誇張であり、実際に排除されているのは契約関係の外にいるAOSPの利用者、すなわちカスタムROM、小規模メーカー、研究者である。今回確認した資料では、どちらが正確かを判定することはできない。ただし、どちらの主張においても共通して損をする集団が「契約のないオープンソース利用者」だという点は一致している。

アプリ開発者:実質的な影響は小さいが、シグナルは大きい

アプリ開発者の立場からすれば、HIDや入力デバイスのカスタマイズAPIが三か月早くPixelだけにあることは、実務上大きな問題ではない。@bri3dの指摘のとおり、Pixelのためだけに機能を作る開発者は少ない。@vkakuは多くの開発者がAndroid 16のAPIレベルでのみ開発するだろうと予想したが(直接の引用ではなく、コメントの要旨の要約)、これは誇張かもしれないが方向としては正しい。ほとんどのアプリはもともと最小SDKを数年前に置いている。

シグナルとしての意味は別である。「APIレベル」はいま、「すべてのAndroidデバイスがいずれ受け取る契約」から「Pixelに先に来る機能リスト」へと性格を変えつつある。Hacker Newsの@soleil-colzaは、「Pixel = AOSPのリファレンス実装」という関係が侵食され始めているようだと短く書いた(直接の引用ではなく、コメントの要旨の要約)。リファレンス実装がソースより先に進めば、リファレンスはもはやソースを参照していない。

展望と示唆

短期的には12月が分岐点である。GrapheneOSの説明どおりなら、Android 17 QPR2とともに今回のAPIとセキュリティ修正がAOSPに公開される。それまでカスタムROMはバックポートとリバースエンジニアリングで持ちこたえることになり、これは人手の少ないプロジェクトほど重い負担となる。Hacker Newsの@charcircuitは、AIエージェントは変更点を突き止めてリバースエンジニアリングするのに役立つが、最終的な結果は変わらないまま、エコシステムに非効率を加えるだけだと書いた(直接の引用ではなく、コメントの要旨の要約)。リバースエンジニアリングが可能であることは被害の最小化であって、正当化ではない。

中期的には「オープンソースのAndroid」の定義が変わる。これまでの契約は「リリースされればソースがついてくる」だった。新しい契約は「年2回、Googleが決めた時点でスナップショットが出る」である。この二つの違いはライセンスの条文には現れない。Apache 2.0のコードは公開された瞬間から依然として自由だ。変わるのは時間軸である。オープンソースの価値のかなりの部分は「いま動いているコードをいま読める」ことから生まれるが、その「いま」が最大で半年まで開きうるようになった。

Hacker Newsの@natterangellは、AndroidがmacOSとDarwinの道をたどっていると見た(直接の引用ではなく、コメントの要旨の要約)。AOSPは無償で基盤に残り続けるが、いずれユーザー体験の中核となる非自由な要素が現れて対等な代替が不可能になり、AOSPはコードベース以上の意味を失ってゆっくり朽ちていくというシナリオである。今回の件をそのシナリオの証拠と断定するのは早い。APIは最終的には公開される。しかし「最終的には公開される」と「同時に公開される」の間の隔たりが方針として固定されたことは、そのシナリオへの道が舗装され始めたことを意味すると読むことはできる。

規制の面では、@jauntywundrkindがEUのデジタル市場法(DMA)がGoogleに一部のAPI、特にAIアシスタント関連APIの相互運用を求めており、大半の期限が2027年8月1日だと言及した(直接の引用ではなく、コメントの要旨の要約)。今回のPixel先行APIがDMAの関心範囲に入るかどうかは、確認した資料からは判断できない。

実務上の示唆は三つにまとめられる。第一に、カスタムROMのユーザーは「Pixelなら安全」という前提を見直すべきである。GrapheneOSでさえ、Pixel以外のデバイスのサポートの方が容易になるだろうと言っている。第二に、セキュリティ担当者はPixel Update Bulletinを「Pixel専用の情報」ではなく「他のAndroidデバイスにまだ届いていない修正のリスト」として読むべきである。第三に、アプリ開発者にとってAPIレベル37.1のような小数点付きのレベルは「Pixel先行レベル」として扱い、機能の分岐はAPIレベルではなく実際の機能の有無で行う方が安全である。

結論

今回の件の表面は、HIDパッケージ一つといくつかのクラスにすぎない。その程度なら1,180ポイントの反応は過剰に見える。しかし人々が反応したのはAPIの量ではなく順序である。APIドキュメントが出て、バイナリがPixelに配布され、ソースは三か月後に出る。この順序はオープンソースプロジェクトの順序ではなく、ソース公開スケジュールを持つプロプライエタリ製品の順序である。

Googleの公式の説明は「プラットフォームの安定性」である。それにも一理はある。しかし安定性のための遅延がセキュリティ修正にまで適用され、その修正がすでに配布されたバイナリから差分として露わになりうるのなら、遅延は安定性ではなく情報の非対称を生む。攻撃者はバイナリを読み、防御者はソースを待つ。

そうであれば、問いはこうなる。Androidが「オープンソース」だと言うとき、われわれはライセンスのことを言っているのか、それともいま自分の手の中で動いているコードを読む権利のことを言っているのか。12月のQPR2公開が予定どおり行われるか、そしてその間にPixel専用のセキュリティ修正がどれだけ積み上がるかが、その答えの最初のデータになるだろう。

(10月14日追記:Hacker Newsに「AOSPのソース公開があまりに遅く、開発者がライブラリを逆アセンブルしてバグを報告している」という投稿が509ポイントで上がった。リンク先のAndroid NDK issue #2260で報告者は、2026年9月のAndroid 17ビルド(CP3A.260905.009)のbionic wcscspn()/wcspbrk() がU+0100以上の文字を誤って一致として扱う回帰を発見した。公開されている android-17.0.0_r1(6月)のソースは正しい実装であったため、出荷されたライブラリを逆アセンブルして原因を追跡したという。Google側のbionic担当者は問題を認めつつ、ソースを見ればよいと言いたいところだが公開リリースが古すぎて該当の変更が入っていない、という趣旨で答えた。ソースと実行コードの時差が実際のデバッグコストとして現れた具体的な事例である。)

出典: