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 カーネルと Debian のパッケージングシステムでは、同じ命令セットに異なる名前を使用しているため、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（トランスポート層セキュリティ）とディスク暗号化をハードウェアで高速化します。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（実行可能リンク形式）ヘッダーに、この 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 ユーザーモードエミュレーションを登録する必要があります。

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

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

必要なパッケージは 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 でも一般的な用途です。

Just In Time（JIT）コンパイラーは、プログラムの実行中にマシンコードを生成するため、対象アーキテクチャー向けのコードジェネレーターが必要です。現在のバージョンにはその機能があります。Linux 上の OpenJDK、.NET、Node.js 内の V8 エンジン、PyPy は、いずれも 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 の aarch64 では、デフォルトで 64 KiB ページのカーネルが提供されていました。RHEL 9 ではデフォルトが 4 KiB に戻り、大きなページサイズを必要とするワークロード向けに別の kernel-64k パッケージが用意されています。64 KiB のページサイズでは、サイズの小さいマッピングを多数持つプロセスのメモリ使用量の下限が高くなります。カーネルが割り当てられる最小単位が 16 倍になるためです。インスタンス上で getconf PAGESIZE を実行し、推測せずに実際の値を確認してください。

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

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 のシステムを検証済みとしました。これは、Grace Hopper ハードウェアについて NVIDIA および Supermicro と共同テストを実施した結果です。その他の 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 プラットフォーム行が表示されることを確認します。
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 命令セットを指す名称です。カーネルは aarch64 を uname -m 経由で報告します。一方、Debian と Ubuntu のパッケージング、および Docker のプラットフォーム文字列では arm64 を使用します。反対側にも同じ違いがあり、uname -m は x86_64 を示し、パッケージングでは amd64 と表記します。ダウンロードページで aarch64 ファイルしか提供されていない場合、それが dpkg --print-architecture で arm64 と呼ばれるマシン用の正しいファイルです。

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

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

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

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