ARM VPSとx86 VPSの違いは？互換性を確認する方法

ARM VPS に移行すると何が変わるか

ARM VPS でも、x86 VPS と同じ Linux と Nginx を実行でき、通常はコアあたりの料金も安くなります。移行時のリスクは互換性です。x86-64 向けにコンパイルされたプログラムは arm64 ではまったく実行できません。そのため、スタック内のすべてのソフトウェアに arm64 ビルドが用意されているか、自分で再ビルドできる必要があります。

最新のスタックの多くは、追加作業なしでこの条件を満たします。問題が集中するのは、これまで単一アーキテクチャ向けにしかビルドされていないコンテナイメージと、arm64 用のダウンロード版がないクローズドソースソフトウェアの2つです。以下のコマンドを使えば、インスタンスを契約する前に、自分のスタックがこの2点を満たすか確認できます。必要なサーバーの種類をまだ検討中であれば、まず VPS とは何か、共有ホスティングとどう違うか から始めてください。

arm64、aarch64、amd64: それぞれ何を意味するか

何よりも先に、すべてのインスタンスで次のコマンドを実行します。

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

uname -m は ARM マシンで aarch64 を出力し、Intel または AMD のマシンで x86_64 を出力します。dpkg --print-architecture は、同じ2種類のマシンに対して arm64 と amd64 を出力します。どちらの結果も正しいものです。Linux kernel と Debian packaging system は、同じ命令セットに異なる名前を付けています。そのため、aarch64 と arm64 は一方を、x86_64 と amd64 はもう一方を意味します。Docker は Debian 形式の名前を使用するため、イメージのプラットフォームは linux/arm64 のように表示されます。

arm64 には、/proc/cpuinfo に model name 行がありません。代わりに Features フィールドがあり、ハードウェア暗号化は aes pmull sha1 sha2 のようなフラグとして表示されます。これは ARMv8 Cryptographic Extensions であり、Intel および AMD のプロセッサーにおける AES-NI と同じ役割を果たします。TLS (transport layer security) とディスク暗号化をハードウェアで高速化します。VPS で AES ハードウェアアクセラレーションを確認するでは、両方のアーキテクチャーで確認する方法を説明しています。

コンテナが最初に動かなくなる理由とエラーの内容

すべての Docker イメージマニフェストには、ビルド対象のアーキテクチャが記録されています。amd64 のマニフェストしかないイメージを arm64 ホストに pull しても、pull 自体は成功します。失敗するのは、最初のプロセスを起動した時点です。

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error

exec format error は、ファイルの ELF（executable and linkable format）ヘッダーに、この CPU が実装していないマシン種別が指定されているため、カーネルが実行を拒否したことを示します。設定で修正することはできません。その命令セットは CPU のシリコンに実装されていないためです。

デプロイ前にマニフェストを確認します。

docker buildx imagetools inspect nginx:1.27

出力には、マニフェストリスト内のイメージごとに Platform: 行が 1 つずつ表示されます。例として linux/amd64 や linux/arm64 などがあります。linux/arm64 がない場合、そのタグは ARM VPS 上で起動しません。docker manifest inspect --verbose nginx:1.27 でも同じ情報を確認できます。ただし、Docker のドキュメントでは docker manifest は実験的なコマンドとされており、リリース間で動作が変わる可能性があります。そのため、imagetools を優先してください。

自分でビルドするイメージでは、1 つのコマンドで両方のアーキテクチャ向けにビルドし、マニフェストリストを push します。

docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4 --push .

1 台のホスト上で別のアーキテクチャ向けにビルドするには、カーネルの binfmt_misc ハンドラーに QEMU user mode エミュレーションを登録する必要があります。

docker run --privileged --rm tonistiigi/binfmt --install all

エミュレーションはビルドとテストに使用してください。ネットワークトラフィックを提供する本番運用には使用しないでください。Docker の公式ドキュメントにも、QEMU によるエミュレーションは「ネイティブビルドより大幅に遅くなる場合があり、特にコンパイルや圧縮・解凍などの計算負荷が高い処理で顕著です」と記載されています。そのため、ARM インスタンス上で x86 サービスをエミュレーションすると、移行によって得たコスト削減効果が失われます。ネイティブ構成のホスト設定は、両方のアーキテクチャで同じです。VPS 上で Docker を実行するで説明しており、既存の Compose ファイルも、そこに含まれるすべてのイメージに arm64 マニフェストがあれば、そのまま使用できます。

arm64 で必要なパッケージは利用できますか？

Ubuntu と Debian は、アーカイブのほぼ全体を arm64 向けにビルドしています。そのため、apt install nginx postgresql redis-server は両方のアーキテクチャで同じように動作します。違いが出るのは、サードパーティーのリポジトリです。

ARM インスタンス上で、apt に直接確認します。

apt-cache policy some-vendor-agent
apt-get install -s some-vendor-agent

apt-cache policy が Candidate: (none) を報告する場合、有効なリポジトリのいずれも、このアーキテクチャ向けのそのパッケージのビルドを公開していません。apt-get install -s はインストールをシミュレートするだけで、何も書き込みません。同じ場合は、E: Unable to locate package で終了します。

次に、apt update の出力を読みます。スクロールして通り過ぎないでください。amd64 専用のベンダーリポジトリは、そのことを明示します。

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

リポジトリは設定済みで到達可能ですが、このマシンにインストールできるものは保持していません。ソースエントリ自体も確認してください。[arch=amd64] で固定された行は arm64 ホストではスキップされます。そのため、実際の原因が pin であるにもかかわらず、パッケージが見つからないように見えます。

安全に移行できるワークロードと、事前確認が必要なワークロード

インタープリター型およびバイトコード型のランタイムは、もともと移植性を考慮して設計されています。PHP、Python、Ruby、Node.js には、主要なディストリビューションの arm64 パッケージが用意されています。Go と Rust は、ターゲットを1つ指定するだけで arm64 向けにクロスコンパイルできます。LEMP スタック、Node API、Nginx の背後で動作する Go バイナリ、Postgres データベースは、arm64 でも一般的な構成です。

ジャストインタイム（JIT）コンパイラは、プログラムの実行中にマシンコードを生成するため、対象アーキテクチャー向けのコードジェネレーターが必要です。現在のバージョンには、その対応が備わっています。OpenJDK、.NET、Node.js 内部の V8 エンジン、PyPy は、いずれも Linux 上の arm64 をサポートしています。実際のリスクは、古いバージョンを固定して使う場合です。数年前のランタイムリリースをインストールするデプロイスクリプトは、動作すると決めつけず、そのリリースのノートで aarch64 のサポート状況を確認してください。

手書きの x86 アセンブリや SSE、AVX の intrinsic を含むライブラリは、判断が難しいケースです。多くは NEON（NEON は ARM のベクトル命令セット）の実装、または通常の C によるフォールバックも備えているため、コンパイルして実行できます。性能は x86 ビルドより向上する場合も、低下する場合もあります。記事の内容から予測せず、実際のインスタンス上で測定してください。

クローズドソースのソフトウェアが、本当の制約になります。ベンダーの監視エージェント、ライセンスが必要なデータベースドライバー、商用コントロールパネル、アンチウイルスデーモンは、コンパイル済みバイナリとして提供されます。ベンダーが arm64 ビルドを公開していなければ、対処方法はありません。ホスティング分野では、cPanel と WHM が最も明確な例です。システム要件には x86_64 と記載され、ARM は含まれていません。そのため、コントロールパネルサーバーは x86 のまま運用します（2026年8月に確認。ベンダー公式の要件ページでも再確認してください）。これだけが移行を妨げているなら、VPS で運用する価値のある cPanel の代替製品から始めて、各製品のアーキテクチャーサポートを同じ方法で確認してください。

カーネルとページサイズ: ARM インスタンスで依然として異なる点

x86-64 サーバーは、ほぼ相互に置き換えられます。ARM サーバーはより均一性が低く、その違いはアプリケーションより下の層にあります。

本番環境に影響するのはページサイズです。ほとんどの arm64 カーネルは x86-64 と同じ 4 KiB ページを使用します。一部は 64 KiB を使用します。Red Hat Enterprise Linux 8 for aarch64 は、デフォルトで 64 KiB ページのカーネルを提供していました。RHEL 9 ではデフォルトが 4 KiB に戻りましたが、より大きなサイズを必要とするワークロード向けに別の kernel-64k パッケージが用意されています。64 KiB のページサイズでは、細かいマッピングを多数持つプロセスのメモリ使用量の下限が上がります。カーネルが割り当てられる最小単位が 16 倍になるためです。インスタンス上で getconf PAGESIZE を実行し、推測せずに値を確認してください。アプリケーションに影響するカーネルの判断は、ページサイズだけではありません。プロバイダーが提供するバージョンによって、処理をコアへ割り当てる方法も決まります。また、Linux 7.2 で追加されたキャッシュを考慮するスケジューリングは arm64 と x86-64 の両方に適用されます。

ほかにも、知っておくべき小さな違いがあります。arm64 にはオペレーティングシステムの CPU マイクロコードパッケージがないため、ファームウェアの更新は apt ではなくプロバイダーから提供されます。ARM サーバーは UEFI (unified extensible firmware interface) で起動し、ACPI (advanced configuration and power interface) によってハードウェアを記述します。一部の x86 機能には ARM に対応する機能がありません。AMD SEV メモリ暗号化や Intel GVT-g mediated GPUs などが該当します。

ARM サーバープラットフォームは成熟したのでしょうか？

ソフトウェア面では、成熟しています。Debian、Ubuntu、Fedora、RHEL はいずれも第一級の arm64 ビルドを提供しており、Docker Hub の公式イメージも当然のようにマルチアーキテクチャ対応です。

最近の明確な証拠は Proxmox です。2026年8月5日、Proxmox は Proxmox Virtual Environment の arm64 版として初めて公式サポートされるバージョン 9.2 を発表しました。x86-64 版とパッケージリポジトリおよびリリースライフサイクルを共有します。Debian 13.5、Linux 7.0、QEMU 11.0、LXC 7.0、ZFS 2.4 を基盤としており、少数のアーキテクチャ固有項目を除けば、設定とツールは x86-64 版と同じです。

同じ発表に記載された注意事項を確認してください。公式にサポートされる ARM サーバーハードウェアが、依然として非常に限られていることが分かります。Proxmox は初日から NVIDIA Grace と NVIDIA Vera のシステムを検証済みです。これは NVIDIA および Supermicro と共同で Grace Hopper ハードウェアをテストした結果です。その他の UEFI ベースの ARMv8-A および ARMv9-A ハードウェアは、ベストエフォートでサポートされます。Device Tree のみを使用する Raspberry Pi などのシングルボードコンピューターはサポートされません。ゲストは同じアーキテクチャのノードでのみ実行できます。ライブマイグレーションも同じアーキテクチャのノード間でのみ動作します。異なるアーキテクチャを混在させたクラスタは公式にはサポートされません。

2026年8月時点での実情はこれです。ハイパーバイザーのベンダーが、x86-64 と同じライフサイクルで arm64 を提供することは、プラットフォームにとって確かな進歩です。ただし、初日からサポートされるハードウェアは2つの CPU ファミリーに限られます。

コミットする前に実行するチェックリスト

1. 試験用インスタンスで uname -m を実行し、aarch64 と表示されることを確認します。
2. Compose ファイル内のすべてのイメージで docker buildx imagetools inspect を実行し、それぞれに linux/arm64 platform 行が表示されることを確認します。
3. ARM インスタンスで apt update を実行し、表示された Skipping acquire 警告をすべて確認します。
4. 依存しているクローズドソースの各エージェントについてダウンロードページを開き、名前に arm64 または aarch64 と付いたビルドを探します。
5. getconf PAGESIZE を実行し、メモリ容量を決める前に結果を記録します。
6. 比較対象として選んだ ARM プランと x86 プランの両方で、独自のベンチマークを実行します。

この記事で主張していないこと

ARM と x86 の価格性能比を提示するものではありません。コアあたりの価格はプロバイダーやプランによって異なり、他者のハードウェアで測定した数値から自分の環境の結果を予測することはできません。実際に測定してください。VPS のベンチマークに関するガイドでは、再現可能な方法で sysbench と fio を使う手順を説明しています。VPS の実際のコストでは、比較における料金面を扱っています。ストレージは CPU アーキテクチャとは別に判断する要素であり、VPS で NVMe と SATA SSD を比較する方法ではその点を説明しています。両方のプランで同じテストを実行し、可能であれば自分のワークロードを使用してください。最終的には測定結果で判断します。

FAQ

Docker コンテナは ARM VPS で動作しますか？

スタック内のすべてのイメージのマニフェストに linux/arm64 エントリがあれば動作します。各イメージで docker buildx imagetools inspect <image> を実行し、Platform: linux/arm64 行を確認してください。Docker Hub の公式イメージは通常、マルチアーキテクチャに対応しています。一方、小規模なベンダーが提供するイメージや、x86 マシンで自分でビルドしたイメージは、対応していないことがよくあります。独自イメージは docker buildx build --platform linux/amd64,linux/arm64 ... --push で再ビルドすると、1 つのタグで両方のアーキテクチャに対応できます。

ARM サーバーで exec format error は何を意味しますか？

カーネルが、異なるマシン種別を示す ELF ヘッダーを持つバイナリを実行しようとして拒否したという意味です。arm64 ホストでは、ほとんどの場合、x86-64 バイナリまたはコンテナイメージが原因です。Docker はまず、要求されたイメージのプラットフォーム linux/amd64 が検出されたホストプラットフォーム linux/arm64/v8 と一致しないという警告を表示します。正しいアーキテクチャ向けにビルドしてください。設定を変更しても、x86-64 バイナリを ARM 上でネイティブに実行することはできません。

arm64 と aarch64 は同じものですか？

はい。どちらも 64-bit ARM 命令セットを指す名前です。カーネルは uname -m を通じて aarch64 を報告します。一方、Debian と Ubuntu のパッケージング、および Docker のプラットフォーム文字列では arm64 を使用します。反対側にも同じ違いがあり、uname -m は x86_64 を示し、パッケージングでは amd64 と表記します。ダウンロードページに aarch64 ファイルしかない場合、それらは dpkg --print-architecture が arm64 と呼ぶマシン向けの正しいファイルです。

ARM VPS は x86 VPS より高速ですか？

一般的な答えはありません。読んだ単一の比率も、あなたが使うものとは異なるハードウェアで測定された値です。速度は、CPU の具体的なモデル、割り当てられるコア数、プロバイダーがテナント間のリソース競合をどのように処理するか、ワークロードがベクトル命令をどの程度活用するかによって変わります。実際に選ぶ 2 つのプランをベンチマークしてください。可能であれば、自分のワークロードを使い、その数値を比較します。

本番サーバーを arm64 に移行する前に何を確認すべきですか？

次の 4 項目を、この順序で確認します。すべてのコンテナイメージに arm64 マニフェストがあることを確認します。すべてのサードパーティー apt リポジトリが binary-arm64 を公開していることを確認します。すべてのクローズドソースエージェントに aarch64 用のダウンロードがあることを確認します。最後に、対象インスタンスで getconf PAGESIZE を実行します。64 KiB ページのカーネルでは、小さなマッピングを多数持つプロセスのメモリフットプリントが変わるためです。これら 4 項目のいずれかで失敗するものがあれば、そのサーバーは x86 のままにする理由になります。