Googleが、自社のデータセンターを支える心臓部、CPUのアーキテクチャをx86からArmベースへ全面的に移行させる壮大なプロジェクトを進行させていることが、同社が公開した技術論文によって明らかになった。自社開発のArmベースCPU「Axion」を核に、YouTubeやGmailを含む10万以上の社内アプリケーションを書き換えるこの取り組みは、AIエージェント「CogniPort」によって支援されているという。
なぜGoogleはArmへ移行するのか？ 「Axion」が示す圧倒的なコスト効率
この大規模な移行の根幹にある動機は、極めて明快だ。それは「圧倒的な経済合理性」である。
Googleによれば、自社設計のArmベースCPU「Axion」を搭載したサーバーは、同等のx86ベースのサーバーインスタンスと比較して、最大65%優れた価格性能比を実現し、エネルギー効率は最大60%向上するという。 この数字は、世界中に巨大なデータセンター網を張り巡らせ、天文学的な量の電力を消費するGoogleにとって、無視できないインパクトを持つ。
この驚異的な効率性は、Axionの設計思想と製造技術に支えられている。AxionはArm社の「Neoverse V2」プラットフォームを基盤としており、業界の報道によれば、半導体製造の世界的リーダーであるTSMCの最先端3nmプロセスで製造されているという。 これは、現行の商用半導体技術の頂点に位置するものであり、Googleがこの移行にいかに本気であるかを示している。
データセンターにおけるサーバーの総所有コスト（TCO）は、単純なプロセッサの購入費用だけではない。消費電力、冷却コスト、設置スペースなど、運用にかかる費用が大部分を占める。エネルギー効率が60%向上すれば、電力コストとそれに伴う冷却コストを劇的に削減できる。また、価格性能比が65%向上するということは、同じ投資額でより多くの計算処理能力を、あるいは同じ処理能力をより低いコストで手に入れられることを意味する。
まさに「倉庫規模」でコンピューティングを実践するGoogleにとって、この効率化は年間数十億ドル規模のコスト削減に繋がる可能性を秘めているのだ。
10万アプリ、数十億行コードの巨大移行プロジェクト「マルチアーキ」
コスト効率という明確な目標を掲げたGoogleだが、その実現への道は平坦ではない。同社のソフトウェアエコシステムは、10万を超えるアプリケーションと、数十億行に及ぶコードで構成されている。 その全てを一社のコードベースで管理する「monorepo」と呼ばれる巨大リポジトリ上で、これらの資産をx86アーキテクチャからArmアーキテクチャへと対応させる必要があった。
Googleが目指したのは、単なる「置き換え」ではない。「アーキテクチャ中立性」の実現である。 これは、x86とArm、双方のアーキテクチャのサーバーがデータセンター内に混在し、ワークロード（計算処理のタスク）をその時々の状況に応じて最適なサーバーに動的に割り当てられる状態を指す。
この柔軟性を実現するのが、Kubernetesの原型としても知られるGoogleのクラスター管理システム「Borg」だ。BorgがCPUアーキテクチャを意識することなく、空いているリソースに効率的にタスクを詰め込むことができれば、データセンター全体のサーバー利用率が最大化される。しかし、そのためには、ほとんどのアプリケーションがx86とArmの両方で動作するバイナリ（実行ファイル）を持つ必要がある。これが「マルチアーキ」プロジェクトの核心だ。
既に、Googleの主力サービスであるYouTube、Gmail、BigQueryといった身近なアプリケーションを含む、30,000以上のパッケージがArmへの対応を完了している。 しかし、Googleによると、全計算処理能力の約60%は上位50のアプリケーションで占められているものの、残りの膨大な数の「ロングテール」のアプリケーションを移行させることが、Borgによる効率的なスケジューリング、ひいてはサーバー利用率の向上に不可欠なのだという。
移行の現実は「地味で退屈な作業」の連続だった
命令セットアーキテクチャ（ISA）の移行と聞くと、多くの技術者はCPUの細かな仕様の違いに起因する難解な問題を想像するだろう。浮動小数点演算の微妙な誤差（floating point drift）、メモリ操作の順序に関する問題（concurrency）、CPU固有の命令（intrinsics）の書き換えなどだ。
Googleのチームも当初は、これらの技術的課題に多くの時間を費やすと想定していた。しかし、現実はまったく異なっていた。同社のエンジニアリングフェロー、Parthasarathy Ranganathan氏はブログでこう語る。
「当初、F1、Spanner、Bigtableといったトップクラスのジョブを移行した際、想定していた問題は確かに存在しましたが、予想していたほど多くはありませんでした。現代のコンパイラやサニタイザーのようなツールが、驚きのほとんどを取り除いてくれていたのです。」
彼らが実際に最も多くの時間を費やしたのは、以下のような、より地味な作業だった。
- テストの修正: 既存のx86サーバーの挙動に過度に最適化（overfit）されていたテストコードが、Arm環境で失敗するケースの修正。
- ビルド・リリースシステムの更新: 特に古くから稼働している高トラフィックなサービスにおいて、複雑化したビルド設定やリリース手順をArmに対応させる作業。
- 本番環境での設定問題の解決: 開発環境では問題なくとも、本番環境特有の設定下で発生する問題への対処。
あるエンジニアは、「誰もが全く異なるツールチェインに固執し、すべてが壊れると思い込んでいた。しかし、難しさの大半は設定ファイルとか、そういう退屈なものだった」と振り返っている。 この事実は、ISA移行における課題が、かつての低レベルなコード変換から、現代的なソフトウェア開発におけるビルド、テスト、デプロイといったパイプラインの整備へとシフトしていることを示唆している。
人海戦術からAI支援へ。自動化ツール「CogniPort」の威力
数万に及ぶ「ロングテール」のアプリケーション移行を、開発者への個別依頼といった人海戦術で進めるのは非現実的だ。そこでGoogleは、自動化を徹底的に推し進めた。
既存の自動化ツール群がまず活躍した。「Rosie」は、設定ファイルの変更のような定型的な修正を数千のファイルにわたって一括で適用し、コードレビュープロセスを自動で進める。 「Sanitizers」や「Fuzzers」といったツールは、x86では顕在化しにくいメモリ関連のバグや競合状態を事前に検出し、アーキテクチャ間の挙動の違いによる問題を未然に防ぐ。 そして「CHAMP」は、Arm対応したアプリケーションを本番環境へ自動で展開し、問題（クラッシュや性能低下）が発生した場合には自動で切り戻す役割を担う。
しかし、これらのツールはあくまで決められた処理を実行するだけだ。予期せぬビルドエラーやテストの失敗には対応できない。このギャップを埋めるために開発されたのが、AIエージェント「CogniPort」である。
CogniPortは、ビルドやテストのプロセスでエラーが発生すると自動的に介入し、問題の解決を試みる。その内部は、3つのネストしたエージェント（LLMを活用した自律的なプログラム）で構成されている。
- オーケストレーター・エージェント: 全体を指揮し、ビルドやテストの状況に応じて他のエージェントを呼び出す。
- ビルドフィクサー・エージェント: ビルドエラーが発生した際に、ソースコードやビルドファイルを修正してビルドが成功するまで試行を繰り返す。
- テストフィクサー・エージェント: テストが失敗した際に、テストコードや関連コードを修正し、テストが成功するまで試行を繰り返す。
Googleは、過去に人間が手動で行った修正コミットを245件選び、それを元に戻した上でCogniPortに解決させるというベンチマークテストを実施した。その結果、CogniPortは全体の約30%の問題を自律的に修正することに成功したという。 特に、テストコードの修正、プラットフォーム固有の条件分岐の追加、データ表現の修正といったタスクで高い効果を発揮した。
成功率30%は完璧ではないが、人間が介在することなく、膨大な数のアプリケーションの問題を自動で解決できる可能性を示した点は画期的だ。Googleは、残る70,000のアプリケーション移行にこのCogniPortを本格投入していく計画である。
38,156件のコミットが語る、ISA移行の「新常識」
この移行プロジェクトの実態は、Googleが公開した4万件近いコードコミットの分析結果から、より鮮明に浮かび上がる。LLMを用いて38,156件のコミットを16のカテゴリに分類したところ、驚くべき事実が判明した。
- コミット数の84%はビルド・設定ファイルの変更: 最も多くのコミット（32,204件）は、ビルドファイルの修正やCI/CD（継続的インテグレーション/デプロイメント）の設定変更といったカテゴリに分類された。
- コード自体の修正はごく僅か: 一方で、CPU固有命令の書き換えやデータ型の修正といった、純粋なコードの適応・修正に関連するコミットは、全体のわずか1%程度に過ぎなかった。
このデータは、「ISA移行の主戦場は、もはやコード変換そのものではない」という新常識を裏付けている。現代のソフトウェア開発において、コードのロジックそのものよりも、それをビルドし、テストし、本番環境へ展開するための一連の「仕組み」を新しい環境に適応させることの方が、遥かに膨大な作業量を要求されるのだ。
また、移行のタイムラインを分析すると、プロジェクトのダイナミズムが見て取れる。
- 初期段階: 移行を支えるツール開発やテスト環境の適応に関するコミットが中心。
- 中期段階: 共有ライブラリのコード修正など、影響範囲の広いコード適応が増加。
- 最終段階: ほとんどのコミットが個別のアプリケーションの設定ファイル変更となり、コミット数が爆発的に増加。
これは、まずインフラを整え、基盤となる問題を解決し、最後に個別のアプリケーションをスケールさせていくという、極めて計画的な大規模プロジェクトの典型的な進行パターンを示している。
x86の時代の終焉か？ Googleの選択が業界に与える衝撃
Googleのこの動きは、単なる一企業の社内プロジェクトに留まらない。コンピューティング業界全体、特にサーバーCPU市場を支配してきたx86アーキテクチャの未来に、大きな疑問符を投げかけるものだ。
長年、IntelとAMDが供給するx86プロセッサは、データセンターの絶対的な標準だった。しかし、省電力性能に優れたArmアーキテクチャがスマートフォン市場を席巻し、その性能をサーバークラスにまで高めてきたことで、状況は変わりつつある。Amazon Web Services（AWS）が自社製ArmベースCPU「Graviton」で成功を収めたことは、記憶に新しい。GoogleがAxionでそれに続くことは、クラウド業界全体で「脱x86」の動きが加速していることを明確に示している。
この巨大な移行が完了した時、Googleが購入するx86プロセッサの数は大幅に減少する可能性がある。 世界最大のサーバー購入者の一つであるGoogleのこの決断は、IntelやAMDにとって大きな打撃となり、サーバーCPU市場の勢力図を塗り替える可能性がある。
我々が日々利用するGoogleのサービスは、見えないところで絶えず進化している。その裏側では今、AIの助けを借りながら、データセンターの基盤そのものを入れ替えるという、静かだが巨大な革命が進行しているのだ。この革命の成否は、間違いなく未来のインターネットの姿を形作ることになるだろう。
Sources