はじめに
Googlebookの全貌が徐々に明らかになっていく中で、「reddit」「9to5google」のコメント欄、「github」のリポジトリでは、主に以下のような開発環境としての実用性に関心が集まっています。
- Debian環境の完全性とカーネルの自由度
Termuxのような環境ではなく、完全なディストリビューションとしてパッケージやシステムコールが制限なく動くのか。 - Docker・コンテナ環境の稼働
ホストを汚さずに開発コンテナやローカルAI環境をスムーズに立ち上げられるのか。 - GUIアプリとハードウェア（GPU）アクセラレーション
VS Codeやグラフィックツールが、ソフトウェア描画のカクつきなしにGPUを活用して滑らかに動作するのか。 - ネットワーク連携と自動ポートフォワーディング
Linux内で立ち上げたWebサーバーへ、ホスト側のブラウザから即座にアクセスできるのか。
これらの議論に加えて、日本のユーザーとしては以下の点が気になります。
- Chrome OS 147（Baguette）で置き去りにされた「ホスト日本語入力（IME）の連携」はどうなるのか？
他には、
- ファイルマネージャーからターミナルへの「ドラッグ＆ドロップ」連携は改善されたか？
現行ChromeOSでは、ローカルの「Linux ファイル」をターミナルへD&D、SFTPマウントしたリモートフォルダ内のファイルをSSH接続したターミナルへD&Dしても、パスが自動展開されない制約がある。新アーキテクチャではこの不便さが解消されているのか。
ですね。もちろん新しくAndroidホスト側に追加されたエージェントの動きについてはワークフローの効率性・利便性に直撃しますので大変気になっていますが(おそらく激アツポイントですが)、書き加えた疑問はChrome OSでやや不便だった部分がどうなるか、という点で記載しました。
発表内容から何が予測されるか、見ていきます。
公式アナウンスと「Ferrochrome」から読み解くアーキテクチャの全貌
公式アナウンスの内容
以下に公式アナウンスを日本語訳したものを添付します。
Googlebookとしての公式発表で述べられているのは上で書かれていることがほぼ全てであり、
- Googlebook OSはAndroidの技術スタックをベースに、Chrome OSのデスクトップ基盤を組み合わせたもの
- セキュリティはChrome OSと同じ多層防御を継承（Google Titanチップ、Verified Boot、オンデバイスマルウェア検出）
- ノートPCカテゴリで初の「Level 5 security-certified hypervisor powered by pKVM」を搭載
- このpKVMが「隔離されたLinux環境（full terminal access）」を動かしており、開発ツールやコード取得、ネットワーク・ポートアクセス、自律エージェント実行が可能
これ以上の詳細なアーキテクチャ図や、Linux VM内部の具体的な実装（virtioデバイスの種類、GPU共有の方式、メモリ管理の詳細など）は、公式からはほとんど出ていません。
カンファレンスで語られた「Ferrochrome」アーキテクチャから推測する仕様
2025年12月13日、東京・虎ノ門ヒルズで開催された「Linux Plumbers Conference 2025（LPC 2025）」において、GoogleでAndroidの仮想化を専門に扱っているエンジニアJeongik Cha氏から以下の発表が行われた。
Title：Ferrochrome: A Linux VM on Android host via Android Virtualization Framework (AVF)
(Ferrochrome：AVFを介したAndroidホスト上でのLinux VM)
この頃Googlebookは当然未発表で、今から思えば基盤技術でした。
ここで発表されたアーキテクチャから仕様を推測していきます。
Ferrochrome出自
Ferrochromeとは2024年頃当初、AVFのためのデモでした。
Googleは Android 13 より、公式の仮想化フレームワークである「AVF (Android Virtualization Framework)」を導入しました。これは、Android OSの隣に安全に隔離された仮想空間（Virtual Machine）を作り出し、高度なセキュリティ処理を行うための仕組みです。そして、この仮想空間をハードウェアレベルで安全に隔離・制御しているハイパーバイザーこそが、公式発表にも登場した「pKVM」です。
この高度なセキュリティ処理という当初の目的からしては以下は必然でした。
- 画面がない：元々暗号鍵の保管や著作権保護（DRM）など裏方の計算専用だったため、画面を
描画する仕組み（ディスプレイ出力）が一切存在しませんでした。 - GPUが使えない: 仮想マシン内からはスマホのGPUアクセラレータにアクセスできず、画面を表示しようとしてもCPUが力づくで計算（ソフトウェアレンダリング）するため、カクカクで実用に耐えませんでした。
- ホストとの壁が厚すぎる: セキュリティが強固すぎる反面、スマホ内のファイルを開いたり、タッチ操作を伝えたり、メモリを柔軟に分け合うことが困難でした。
これに対し2024年頃登場したのがFerrochromeで、Android上でChrome OSをVMとして動かすためのデモでした。Android 15で強化されたAVF（特にグラフィックス対応）を見せるための「面白いデモ」として、Google内部でChrome OSをゲストに選んだものです。
その後、ゲストはより汎用的で自由度の高いフルLinuxディストリビューションであるDebianが選ばれFerrochromeは、Androidホスト上でフル機能のDebian環境を快適に動かすプロジェクトになりました。
つまり、Androidホスト上でpKVMで隔離したフル機能のLinux仮想マシンを動かす、というのはまさに今回公式アナウンスのあったGooglebookのアーキテクチャそのものです。
以下から具体的なFerrochromeアーキテクチャを見ていきます。カンファレンスの内容と発表アブストの内容を使用し、分かりやすく解説資料を生成していますのでそれを使用します。
全体アーキテクチャ
全体アーキテクチャは上記のようになります。pKVMによってLinux環境は隔離されています。この中で動作し、ホストとはvirtio-* デバイス群がインターフェースになり通信を行います。
詳細な注意として、このLinux環境は「non-protected VM」として動作しています。
AVF（Android Virtualization Framework）には、大きく分けて2種類の仮想マシンがあります。
- Protected VM（保護されたVM）
鍵管理や生体認証など、極めて機密性の高い処理を想定したもの。
ホスト（Android）が完全に侵害されても、ゲストのメモリにアクセスできない強い隔離を提供します。しかしこれを普段利用のファイルなどに適用するとガチガチ過ぎて利便性が損なわれる。 - Non-protected VM（非保護VM）
今回のDebian Linux環境（Ferrochrome）が使用しているモードです。
完全な機密隔離よりも、利便性とパフォーマンスを優先しています。
※「非保護」という名前だからといって決してセキュリティガバガバで危険という意味ではありません。（pKVMで隔離されています。）
具体的には：
- GUIアプリケーションを快適に動かすためのGPU加速（gfxstream）
- ファイル共有（virtio-fs）
- 入力デバイス共有
- メモリ・ディスクの動的管理
といった深い統合を実現するために、non-protectedモードが選択されています。
つまり「pKVMで隔離されている」環境でありつつも、
「完全にホストから見えない機密領域」ではなく、「通常の仮想マシンとして隔離されつつ、ホストと柔軟に連携できる環境」
になっているということになります。
GPU描画パイプライン
解説資料を見ると分かる通り、物理GPUを駆動する設計になっています。 設計上はネイティブ並のパフォーマンスが出てもおかしくないアーキテクチャと言えると思います。
図では60fps達成と書いてありますが、カンファレンスでの発表内容では「目標・設計として60FPSを狙える」というニュアンスだと思います。実機で常に60FPSが出ることを保証していたわけではありません。
しかし、Googlebookでは駆動SoCはスマホより強力です。また、カンファレンスから時間も経過していますので、実際に何fps出るかは、実機検証次第です。
入力操作 タッチ・キーボードの低遅延伝達
入力は取り立てて特別な仕組みではないように思いますが、Ferrochromeでは、Androidホストから文字が入力されると、そのイベントが専用の高速通信路「vsock」を通ってLinux内の「Guest Agent」へ届きます。そのGuest AgentがLinuxカーネルの「uinput」機能を使って「今、USBキーボードやマウスが接続されて操作された」とOSに錯覚させることで、あらゆるLinuxアプリで入力操作を実現しています。
ファイル共有 キャッシュなし直接メモリアクセス
Ferrochromeでは、AndroidのストレージをLinux側に共有する際に、virtiofs + DAX（Direct Access）という仕組みを採用しています。
従来のファイル共有では、データをいったんコピーしてから相手に渡す方式が一般的でしたが、DAXではファイルをメモリ上に直接マッピングします。これにより、コピー分の遅延時間がほぼゼロになり、大容量の写真や動画でもネイティブに近い速度でアクセスできます。
これにより「ホスト側の写真をLinuxのGIMPで編集したい」「Linuxで作成したPDFをホストのLINEで送信したい」といった日常的な作業をストレスなく行うことができるようになります。
動的リソース管理 風船技術
Linux領域のメモリ使用は動的に管理され、固定ではありません。また、従来のChrome OSと違う箇所と思いますが、ストレージが固定でなく、使っている分だけ使用になる、というものです。
こうなると容量管理的には良い方向になりますね。しかしこれも実機確認が必要です。
ネットワーク・開発者デバッグ連携
Linux VM内で起動したWebサーバー（例: localhost:8080）は、Androidホストの自動ポートフォワーディングにより、ホスト側のChromeブラウザから何の設定もせず即座にプレビュー・動作確認が可能です。ローカルWeb開発の快適さはそのまま維持されます。
また、「ADB over vsock」は、元のFerrochrome発表がスマートフォンを対象としていたため「画面の小さいスマホ内のLinuxを、PCからUSB接続してデバッグする」という目的で設計された機能です。Googlebookはフルサイズのキーボードと大画面を備えたノートPCであるため、通常は本体のターミナルから直接操作できます。このADB over vsockは、外部PCからの遠隔自動テストや、高度なデバッグを行いたい開発者向けの強力な裏ルートとして機能すると考えられます。
これらの開発連携が製品版でどこまでオープンに開放されているかは、実機が到着し次第、手元のコマンドとブラウザでテストして確かめたいと思います。
浮上している疑問とFerrochromeによる挙動予想
GooglebookがFerrochromeアーキテクチャを採用した場合、実際の挙動はどうなるのか。
冒頭で挙げた疑問や、アーキテクチャを読み解く中で見えてきた技術的論点を表にまとめました。
既存のChromeOSとの違いを踏まえ、「改善されるか否か」の観点から予想を整理しています。
実機検証予告
製品版Googlebookがどうなっているかは、実際にマシンを叩いてみなければ分かりません。
私はLenovo Googlebook 15（15.3インチ 2.8K OLED / Core Ultra 5 / 16GB / 512GB）の発注を済ませており、10月中旬には手元へ届く予定です。機体が到着次第、上の表の項目を実機で検証します。
おわりに
Googlebookは、Androidスマートフォンユーザーにとって、真の快適性と統一感をもたらすために登場した永年待ち望んだ理想の体現を目指すデバイスです。
これまで、Androidスマホユーザーに真にシームレスな体験をもたらすPC環境は正直なところ存在しませんでした。その中で唯一、エコシステムの統一感を持っていたChromeOSが、今回ついにAndroidのシステム基盤へと根底から再構成されました。このアーキテクチャの刷新は、スマホとPCの境界をなくし、日常の快適性や生産性の劇的な向上に直結するものだと確信しています。
なお、今回あえて深く触れなかった「Androidホスト側に組み込まれた自律型AIエージェントの実力と、Linux開発環境との自動連携」、そして「スマホ連携の実際の使い勝手」については、それぞれ単体でも膨大な検証ボリュームになるため、実機到着後に個別のレビュー記事として順次公開する予定です。
まずは10月中旬、実機が到着し次第、上記のチェックリストに沿って最速で実機レポートをお届けします。続報をぜひ楽しみにお待ちください。
コメント