IBMは2026年8月24日、ArmのAArch64とIBMのz/Architecture（Z アーキテクチャ）を各コアでネイティブ実行できるプロセッサ設計をHot Chips 2026で発表した。Arm専用コアを別に載せる構成ではなく、11基すべてを二つの命令セットに対応させる。従来、IBM Z上のLinuxはs390x向けであり、広く流通するArm64バイナリをそのまま扱うプロセッサではなかった。今回の設計は、メインフレームの高い可用性や暗号化機能を保ちながら、クラウドネイティブやAIソフトウェアの選択肢を増やそうとする試みである。
ただし、IBMが公表したのは将来のIBM ZとLinuxONEに向けた開発中の設計だ。製品名も発売時期も明かしておらず、同社は仕様や計画が変更、撤回される可能性を明記している。
2nm・11コアより大きい、二重ISAへの転換
新プロセッサは2nm技術ノードで設計され、11基の高性能コアを5.7GHz超で動かす計画だ。オンチップには取引中の不正検知を想定したAI推論アクセラレーターと、I/Oを高速化するデータ処理ユニット（DPU）も置く。IBMは大容量キャッシュ構成を採るとしているが、公式発表では容量を示していない。
現行IBM z17の中核を担うTelum IIと比べると、違いは次のようになる。
| 項目 | Telum II | 新デュアルISA設計 |
|---|---|---|
| 技術ノード | Samsung 5nm | 2nm、製造委託先は未公表 |
| 高性能コア | 8基 | 11基 |
| 公表動作周波数 | 5.5GHz（ベース） | 5.7GHz超 |
| CPU命令セット | z/Architecture | z/ArchitectureとAArch64 |
| I/O高速化 | オンチップDPU | オンチップDPU |
| AI処理 | オンチップAIアクセラレーター | AI推論アクセラレーター |
コア数と周波数は増えるものの、IBMはアプリケーション性能や消費電力をまだ公表していない。製造ノードの呼称も、その数字に反比例して性能が上がるという意味ではない。AIアクセラレーターとDPUはTelum IIにもあるため、世代を分ける最大の変更はAArch64を同じコアへ組み込んだ点にある。
同じコアへAArch64をどう組み込んだのか
Hot Chipsで示された技術資料によると、IBMはAArch64 v9.3をハードウェアで実装し、ベクトル演算を拡張するSVEを含む2,792命令に対応させた。二つの命令セットをソフトウェアで逐次変換するエミュレーションとは異なり、コアがAArch64の命令を直接解釈して実行する。
とはいえ、コア内部を二重に作ったわけではない。分岐予測器はTelum IIの設計を引き継ぎ、整数演算やロード／ストアの主要なデータ経路も両ISAで共有する。AArch64対応で最もシリコンを増やしたのは命令デコーダーだった。SVEと半精度浮動小数点数FP16向けの回路を加え、アドレス変換では既存のTLBを使いながら、AArch64用のページテーブルをたどる機構を新設した。
この設計では、命令を読み取る入口でAArch64とz/Architectureの違いを吸収し、後段の演算器やキャッシュをできるだけ共用する。足し算やメモリー読み出しといった処理は、命令の表現が違っても同じ回路へ流せるからだ。二種類の完成したコアを並べるよりシリコンを有効に使える可能性はある。ただし、IBMはデュアルISA対応に要した面積や電力を示しておらず、効率が優れるとの結論はまだ出せない。
Arm側の実行環境はKVMによる仮想化を使い、コアはナノ秒単位でISAモードを切り替えると説明されている。「同時実行」とは、単一のプログラムがAArch64命令とz命令を混ぜて走ることを指さない。ArmネイティブLinuxの仮想マシンと、z/OSやIBM Z向けLinuxの環境を同じシステム内で共存させるという意味である。どの単位でコア資源を分けるのかなど、仮想化構成の詳細はまだ公開されていない。
Armを選ぶ理由、2,200万人超の開発者
IBMとArmは、Armのソフトウェアエコシステムに世界で2,200万人超の開発者がいると説明する。ここでの数字は開発者数であり、そのすべてのソフトウェアがIBM Zで動くという保証ではない。それでも、クラウドやAI向けのソフトウェアがArm64を主要な配布先にするなか、IBMが一つずつs390xへ移植するよりも、AArch64をハードウェアへ迎え入れる方が対象を広げやすい。
メインフレーム利用企業にとっては、Arm64向けの分析ツールやAI基盤を、取引データから離れた別サーバーへ送らずに実行できる可能性が生まれる。IBMが既存のキャッシュや暗号化、障害検出の仕組みを両ISAで共有しようとしているのも、そのためだ。データ移動とシステム分離を減らせれば運用は簡素になるが、実際の効果は対応ソフトと性能測定が揃ってから判断する必要がある。
同じ筐体に入ることと、データ交換が不要になることも同義ではない。z/OSの取引処理とArm仮想マシンが、どのメモリーを共有し、どの通信経路で結ばれるのかは公表されていない。IBMのAI推論アクセラレーターも取引中の不正検知を主な例としており、Arm向けAIソフトが自動的にその回路を使えるとは限らない。ハードウェアの近さを実務上の利点へ変えるには、OSとミドルウェア側の連携が要る。
2026年4月に両社が協業を発表した時点では、取り組みは仮想化技術の拡張、Arm環境を企業の可用性・セキュリティー要件へ合わせる作業、共通技術層によるエコシステム拡大という三つの方向に分かれていた。4カ月後の今回、IBMはプロセッサ仕様まで具体化した。開発の中心は、構想から実装へ一段進んだことにある。
ネイティブ対応と製品互換性は別の問題
AArch64をネイティブ実行できても、既存のArmソフトウェアが無条件で製品サポートされるわけではない。ゲストOSとドライバーを整え、ハイパーバイザーや管理ツールを検証する必要がある。ミドルウェアのライセンスと、IBM Zの可用性要件を満たす認証も残る。
コンテナイメージにArm64版があっても、内部で呼び出すネイティブ拡張や周辺機器のドライバーが対応しなければ動かない。逆に、JavaなどCPU差を吸収する実行環境でも、その下のライブラリーまで確認が必要だ。また、今回加わるのはAArch64であり、x86専用バイナリを直接実行する機能は発表されていない。クラウド向けソフト全般がそのままIBM Zへ移るわけではない。
IBMが発表と同時に、独立系ソフトウェアベンダーやオープンソース開発者へ関心登録を呼びかけたことは、準備状況をよく表している。登録者には将来のテスト、検証、プレビューに関する情報を提供する予定だが、参加は保証されない。ハードウェアはArmの入口を作った。実際に通れる道へ仕上げる作業はこれからである。
製品化を見極める材料は、対応するArmゲストOSと認証済みアプリの一覧、z環境と同居させた際の性能・消費電力、障害分離の仕様である。提供地域とライセンス条件も欠かせない。これらが揃えば、企業はArm向けソフトを重要データの近くで動かす利点と、移行・運用にかかる費用を比較できる。IBMが次に公開するソフトウェア対応表が、デュアルISAを技術展示から実用基盤へ変えられるかを決める。