なぜCSPは自社チップを設計するのか
kichikawa@3dicrl.com――AWS Annapurna Labsの講演から読み解く“ハードから始める最適化”
2025年10月21日に台湾で開催された IMPACT 2025 の基調講演（Plenary Speech）に、元Intel ATTDトップで現在はAWS Annapurna Labsに所属する Dr. Babak Sabi（ババック・サビ）氏 が登壇した。本稿では、その講演内容をレポートする。
クラウド事業者（CSP）が自社で半導体を設計する動きは、単なる流行ではない。AWSはAnnapurna Labsを2015年に買収して以降、Nitro（仮想化・ネットワーク・セキュリティ）／Graviton（CPU）／Trainium・Inferentia（学習・推論）という三層の自社チップを継続投入してきた。講演では、その狙いが次の4点に整理されていた（“Why build our own chips?”）。
- Specialization（特化）
クラウドの実ワークロードに合わせ、必要機能を狙い撃ちで実装する。一般汎用品では拾いきれないレイテンシやI/Oのボトルネックを、設計段階から潰し込める。 - Speed（スピード）
要件定義から実装・検証まで社内で回すことで、サービス要件の変化に素早く追随できる。世代更新のテンポ（おおよそ1〜1.5年）もこれに支えられている。 - Innovation（継続的改良）
自社運用で得た知見（実トラフィック、障害傾向、TCOなど）を次世代設計へ直接フィードバックし、ベンチマーク値より実ワークロード性能を優先して磨き込む。実際、Gravitonの世代比較では、マイクロベンチの伸びを実アプリが上回る事例が示された。 - Security（ハードウェア実装）
セキュリティをハードウェアの層に組み込む設計方針が明言された。基盤の信頼性を“下から”支えるために、チップレベルの機能として実装する、というスタンスである。
Babak氏が繰り返し強調したのは、「ベンチマークスコアではなく、実際のクラウド環境での性能を基準に設計する」という考え方だ。
AWSのチップ開発チームは、CassandraやNGINX、MySQLといった実際にAWS上で動くサービスの挙動を直接測定し、それを設計改善の指標にしている。
この“実運用データに基づく最適化”によって、Gravitonシリーズでは世代を重ねるごとに、利用者が体感できる性能と効率が着実に向上している。
さらに、生成AI時代の現実――モデル・データ・計算量の指数的拡大（AI Scaling Law）――に対し、AWSは二正面作戦を敷く。
- Scale Up：2.5D/3D実装、HBM、UCIe、必要に応じてCPO（光）を取り込み、1ノードあたりの密度と帯域を極限まで引き上げる。熱・電力は最大の制約で、マイクロチャネルやウェハーレベル冷却、TIM改良、裏面給電（BSPDN）などでボトルネックを崩す。
- Scale Out：多数のサーバやデータセンターを連結し、配線・コネクタ・ラック設計を見直して物理展開の効率を上げる（面積削減、展開時間短縮、コネクタ削減といった効果が示された）。
パッケージ面では、大型化（〜240mmクラス）とともに、基板・インターポーザ双方のパネルプロセス化が鍵になる。従来のウェハー制約を超えてスループットとコストを下げ、巨大な計算・メモリ・I/Oを一体で収める“器”を現実の製造で支えるためだ。ここでも、「特定の技術や構造に依存せず、目的に応じて最適な方式を選べる柔軟な実装（fungible interposer／assembly options）」という考え方が示された。
要点をまとめれば、CSPが自社チップを設計する理由はサービス品質と効率の源泉を自ら握るためである。クラウドの最適化はソフトだけでは完結しない。ハードウェア（さらに言えばパッケージ）から同時に設計し、実ワークロードに照準を合わせて改良を積み重ねる――この“下からの最適化”こそが、AI時代のクラウド競争力を左右する、講演はそう語っていた。
