「MシリーズのMacでビルドしたイメージをサーバに持っていったら起動しない」「CIでは通るのに本番だけ落ちる」「node_modules をコピーしたら壊れた」——そしてログに出るのはたった一行、exec format error。

このエラーは情報量が極端に少ないので慌いますが、原因はほぼ4つに限られます。本記事では3行のコマンドで原因を特定する手順と、ケース別の直し方、そしてよく混同される別のエラーとの見分け方までを整理します。

このメッセージは、Linuxカーネルが返す ENOEXEC というエラー番号の表示です。意味はシンプルで、

「実行しようとしたファイルを、実行可能な形式として認識できなかった」

ということです。ファイルが存在しないわけでも、権限がないわけでもありません。ファイルはそこにあって実行権もあるのに、中身がカーネルの知っている形式ではない、という状態です。

Dockerでは次のような形で現れます。

exec /app/server: exec format error

古めのDockerだとこういう表示になることもあります。

standard_init_linux.go:228: exec user process caused: exec format error

推測で直し始める前に、実行環境とバイナリのアーキテクチャを並べて見ます。これでほぼ決着します。

# ① 今動いている環境のアーキ
uname -m
# x86_64  → Intel/AMD 64bit
# aarch64 → ARM 64bit

# ② 問題のバイナリ/スクリプトの正体
file ./server
# ELF 64-bit LSB executable, x86-64 ...      → x64 用
# ELF 64-bit LSB executable, ARM aarch64 ... → arm64 用

# ③ Docker イメージのアーキ
docker image inspect myapp:latest --format '{{.Os}}/{{.Architecture}}'
# linux/amd64 または linux/arm64

①と②（もしくは③）が食い違っていたら、原因はアーキ不一致で確定です。

flowchart TB
    A["exec format error"] --> B{"file の出力は<br>ELF バイナリか"}
    B -->|"ELF だが<br>uname -m と違う"| C["アーキ不一致<br>ケース 1〜3"]
    B -->|"ASCII text など<br>スクリプト"| D["shebang 欠落<br>ケース 4"]
    C --> E{"どこで混ざったか"}
    E -->|"docker image inspect が違う"| F["ケース 1<br>イメージのアーキ違い"]
    E -->|"node_modules / venv をコピーした"| G["ケース 2<br>ネイティブモジュール"]
    E -->|"CI だけで発生"| H["ケース 3<br>runner のアーキ"]

最も多いパターンです。Apple SiliconのMac（arm64）でビルドしたイメージを、x64のサーバやEC2に持っていって起動しない、というやつです。

docker run --platform linux/amd64 myapp:latest

ただしこれはQEMUによるエミュレーションなので大幅に遅くなります。開発中の応急処置と割り切り、本番には使わないでください。

エミュレータが入っていないLinuxホストでは、先にbinfmtを入れる必要があります。

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

本番のアーキに合わせてビルドするのが正解です。buildx を使います。

# 両アーキ向けにビルドしてレジストリにpush
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myrepo/myapp:latest \
  --push .

こうしておけば、pullする側のアーキに合ったイメージが自動で選ばれます。x64サーバにしかデプロイしないのであれば、--platform linux/amd64 だけでビルドしても構いません。

これが一番気づきにくいパターンです。イメージのアーキは正しいのに、中身のネイティブモジュールだけが違うアーキという状態です。

原因はほぼこれです。

# Dockerfile
COPY . .        # ← ホストの node_modules ごとコピーされている

Mac（arm64）で npm install してできた node_modules には、arm64用にビルドされたバイナリ（esbuild、sharp、rollup、node-gyp経由の.nodeファイルなど）が入っています。これをx64のイメージに持ち込むと壊れます。

# ホスト側の残骸を消して入れ直す
rm -rf node_modules package-lock.json
npm install

# ネイティブモジュールだけ再ビルドするなら
npm rebuild

根本対策はホストの node_modules をイメージに入れないことです。

# .dockerignore
node_modules
npm-debug.log
.venv
__pycache__
*.pyc
.git

コンテナ内で npm ci を走らせれば、そのアーキに合ったバイナリが入ります。

「ローカルでは動くのにCIで落ちる」「CIでは通るのに本番で落ちる」ケースです。

GitHub Actionsでは、runnerのラベルでアーキが決まります。

なおarm64のホストrunnerは、パブリックリポジトリ向けが2025年8月にGA、プライベートリポジトリ向けも2026年1月に利用可能になっています。選択肢が増えた分、意図せず混在させてしまう事故も増えています。

本番がx64なのにMacでしか確認していない、という状態を避けるには、CIで本番と同じアーキをビルドします。

# .github/workflows/build.yml
jobs:
  build:
    runs-on: ubuntu-latest      # x64
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - name: Build for production arch
        run: |
          docker buildx build --platform linux/amd64 -t myapp:ci --load .

ここが見落とされがちです。アーキテクチャが完全に一致していても exec format error は出ます。

シェルスクリプトの1行目にshebang（#!/bin/bash など）がない場合、カーネルは「このファイルを何で実行すればいいのか」が判断できず、ENOEXECを返します。

# 1行目を確認する
head -1 entrypoint.sh

# なければ追加する
#!/bin/bash

Dockerで ENTRYPOINT ["/app/entrypoint.sh"] のようにexec形式で書いていると、シェルを介さずに直接execveされるため、この問題が顔を出します。

「Windowsで編集したスクリプトが動かない」とき、改行コード（CRLF）を疑うのは正しいのですが、CRLFは exec format error にはなりません。ここを混同すると切り分けを間違えます。

つまり bad interpreter と出ているならアーキを疑う必要はありません。CRLFならこう直します。

# 確認（CRLF なら \r\n と出る）
file entrypoint.sh

# 変換
dos2unix entrypoint.sh
# dos2unix がなければ
sed -i 's/\r$//' entrypoint.sh

一度直しても、仕組みがなけれまた同じことが起きます。最低限この3つを入れておくと安全です。

① .dockerignore を必ず置く

ケース2の根絶です。リポジトリ作成時のテンプレートに入れてしまいましょう。

② Dockerfileでベースイメージのアーキを意識する

クロスビルドするなら、buildxが渡す変数を使えます。

FROM --platform=$BUILDPLATFORM node:22 AS builder
ARG TARGETPLATFORM
ARG BUILDPLATFORM
RUN echo "building on $BUILDPLATFORM for $TARGETPLATFORM"

③ CIで本番と同じアーキをビルドする

ローカルのMacでしか確認しない運用をやめ、CIを「本番アーキでの検証の場」にします。

• exec format error の正体は ENOEXEC。「ファイルを実行形式として認識できない」という意味で、ファイルの有無や権限の問題ではない
• 切り分けは3行。uname -m / file / docker image inspect を並べて見ればほぼ決着する
• ケース1（イメージのアーキ違い）は docker buildx build --platform で根本対応する。--platform での実行は遅いので応急処置に留める
• ケース2（node_modules / .venv の持ち込み）が最も気づきにくい。.dockerignore で除外してコンテナ内で入れ直す
• ケース4の shebang欠落はアーキと無関係。head -1 で即座に確認できる
• CRLFはこのエラーではなく bad interpreter になる。メッセージで見分けられる

エラーメッセージが短いだけで、原因の範囲は狭いエラーです。まず3行切り分けを回してから手を動かしてください。

動くようにはなりますが、QEMUによるエミュレーションなので大幅に遅くなります。ビルドに数倍の時間がかかることもあります。開発中に一時的に使うのは良いですが、本番はターゲットアーキでネイティブにビルドしてください。

Docker Desktopには、x86エミュレーションにRosettaを使うオプションがあります。QEMU単体よりは速くなりますが、それでもネイティブには及びません。Rosettaの仕組みはRosetta 2とは？で解説しています。

ケース2を疑ってください。 イメージ自体のアーキが合っていても、中の node_modules や .venv が別アーキだと同じエラーになります。コンテナに入って file node_modules/**/*.node や file .venv/**/*.so を見ると一発でわかります。

どちらもbinfmt_miscにエミュレータを登録するもので目的は同じです。Docker環境では tonistiigi/binfmt が手軽で、buildxのドキュメントでもこちらが案内されています。Docker Desktopを使っている場合は既定で有効なため、通常はどちらも不要です。

📄ARM64とx64の違い・確認方法を解説｜Windows/Mac/Linux対応【2026年版】

📄Rosetta 2とは？Apple SiliconでIntelアプリを動かす仕組みと終了時期｜確認・有効化方法【2026年最新】

📄Dockerとは何か？その概要と利点を解説

📄WSLが重い・メモリを食う問題を.wslconfigで直す完全ガイド【2026年版】

• ARM64とx64の違い・確認方法を解説
• Rosetta 2とは？Apple SiliconでIntelアプリを動かす仕組み
• Dockerとは何か？その概要と利点を解説