Cannot Execute Binary File: Exec Format Error を修正する方法

重要: まずは安全な環境（テスト用のVMまたはコンテナ）で操作を行ってください。本番システムでの変更は事前にバックアップとロールバック計画を用意してください。

トラブルシューティング: 実行形式エラーの概観

概要

「Cannot Execute Binary File: Exec Format Error」は、Linux系システムでバイナリを実行しようとした際に出る一般的なエラーです。意味としては「そのファイルはこのシステム上で実行できない」ということです。原因は多岐にわたりますが、共通しているのは「実行しようとしているバイナリが実行環境と合っていない」点です。

この文書では、原因の切り分け手順、よくある修復法、特殊ケース（32ビットバイナリを64ビットで動かす等）、運用時の注意点およびチェックリストや受け入れ基準を含む実践的なプレイブックを提供します。

このエラーは何を意味するか

バイナリ実行エラーの画面表示

一言で言うと、実行しようとしたファイルが現在のカーネル／CPUアーキテクチャ／ユーザー権限／実行インタープリタ／ライブラリ依存などのいずれかに合致していない、あるいはファイル自体が破損している、という状態です。

短い定義（ワンライナー）: 実行ファイルが実行環境と互換性がないか、実行に必要な条件が満たされていないために起きるエラー。

主な原因（チェックリスト）

アーキテクチャ不一致（例: ARMバイナリをx86_64で実行しようとした）
バイナリの破損（ダウンロード中の不整合、転送エラー）
実行権限がない（chmod の問題）
実行形式（ELF/PE/Mach-O）またはインタープリタが異なる
シェルや環境変数の誤設定（例えば shebang が間違っている）
必要な互換レイヤやライブラリが不足している

基本の診断手順（推奨順）

ファイルの種類を確認する: file コマンド
実行権限を確認する: ls -l と chmod の利用
チェックサムで破損を確認する: md5sum / sha256sum
ランタイムや依存関係を確認する: ldd（ELF向け）、readelf、objdump
実行環境（アーキテクチャ）を確認する: uname -m、arch
ログやシェルのエラーメッセージを確認する

以下では各ステップの具体的なコマンドと対処法を詳述します。

修正 1: バイナリの互換性を確認する

まずはバイナリが現在のCPUアーキテクチャとOSに対応しているか確認します。バイナリ自身にどのアーキテクチャ向けかの情報が含まれているため、これを見れば互換性の有無が分かります。

コマンド例:

file

出力例（例示）:

ELF 64-bit LSB executable, x86-64, ... → x86_64 向け
ELF 32-bit LSB executable, Intel 80386, ... → 32ビット向け
Mach-O、PE32 など違う実行形式が出る場合、その形式に対応する環境が必要です。

対処:

アーキテクチャが不一致なら、対応するバイナリをダウンロードするか、ターゲット環境（VM/コンテナ）を用意する。
クロス実行が必要な場合は QEMU や互換レイヤの導入を検討する（後述）。

修正 2: ファイル整合性の確認

ダウンロード中や転送中にバイナリが破損していると、正常に実行できません。提供元がチェックサムを出している場合は必ず照合してください。

チェック例:

md5sum my_executable
sha256sum my_executable

チェックサムが公開値と一致すればファイルは大丈夫です。
一致しない場合は、ファイルを再ダウンロードするか、提供元に問い合わせてください。

注意: 一部の配布は署名（GPG）付きで提供されます。信頼性を高めるためには署名検証も併せて行ってください。

修正 3: アーキテクチャの不一致に対処する

32ビットと64ビット、あるいは x86 と ARM 間ではバイナリの互換性がありません。対処法は主に次のいずれかです。

適切なアーキテクチャ向けバイナリを取得する
実行環境をアーキテクチャに合わせる（例: ARMホストで ARM バイナリを使う）
エミュレーションを使う（QEMU）
必要ならソースから再ビルドする（可能な場合）

例: 64ビットOS上で32ビットバイナリを動かすには、Linux のマルチアーキ機能で i386 を有効にし、32-bit ランタイムライブラリをインストールします（Debian/Ubuntu 系の一般的な流れ）。

# 例: Ubuntu/Debian の場合
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libc6:i386

（ディストリビューションやバージョンにより手順やパッケージ名は異なります。ローカルのパッケージ管理ドキュメントを参照してください。）

修正 4: 実行権限の確認と付与

ファイルの実行権限がないと「実行できない」エラーが出ます。まずは権限を確認して、必要なら付与します。

確認:

ls -l my_executable

付与:

chmod +x my_executable
./my_executable

権限が不足している場合、sudo を使うか適切な所有者に権限を与えてください。ただし、外部から入手したバイナリを無条件で実行するのはセキュリティ上のリスクがあります。

注意: 不明な提供元のバイナリを root 権限で実行する前に、必ずソースの信頼性を検証してください。

修正 5: 実行形式（インタープリタ）や互換レイヤの確認

スクリプトの先頭にある shebang（例: #!/usr/bin/env python3）や、ELF のプログラムインタープリタ（interpreter）が存在しない場合も実行されません。ELF バイナリなら readelf -l で INTERP を確認できます。

readelf -l my_executable | grep INTERP -A1

INTERP に記載されたランタイムが存在しない場合は、そのランタイムをインストールしてください。
Windows の PE 形式や macOS の Mach-O 形式は Linux では動きません。対応する環境を用意するか、互換ツールを使う必要があります（Wine など）。

修正 6: 32ビットバイナリを 64ビットシステムで動かす特殊ケース

前述の通り、32ビット向けの依存ライブラリが必要になります。Debian/Ubuntu 系では多くの場合マルチアーキ対応で解決できます。Red Hat / CentOS 系では glibc.i686 など 32-bit 共存パッケージを追加します。

例（一般的なアプローチ）:

32-bit ランタイムライブラリをインストール
必要なら ia32-libs（古い名）ではなく各ディストリの現在の方式に従う
あるいは chroot / コンテナで 32-bit ユーザーランドを用意する

追加の診断コマンド（デバッグ用）

strace ./my_executable — システムコールレベルで何が失敗しているかを追跡する
ldd my_executable — 依存する共有ライブラリが解決できているか確認（ELF のみ）
objdump -x my_executable — 詳細なバイナリ情報

これらを使うと「何が見つからないのか」「どの段階で落ちているのか」が明確になります。

よくある誤解と反例（いつこれで直らないか）

単に chmod +x をしても、アーキテクチャ不一致や破損したファイルは直らない。
file が示すアーキテクチャが正しいのであれば、まずチェックサムと依存関係を疑うべき。
スクリプトの shebang が誤っている場合、バイナリの問題ではなくインタープリタの問題である。

ベストプラクティス（運用上）

配布バイナリには対応プラットフォーム（アーキテクチャ、OS、必要ライブラリ）を明示する。
チェックサム（SHA256など）と署名（GPG）を併記する。
テスト用のVM/コンテナで手順を検証してから本番に適用する。
依存関係はドキュメント化し、パッケージ管理下で配布する。

互換性マトリクス（簡易）

バイナリ形式	ホスト OS	成功するか	対応策
ELF x86-64	Linux x86-64	はい	そのまま実行可能
ELF x86-32	Linux x86-64	条件付き	32-bit ランタイムを追加
ELF ARM	Linux x86-64	いいえ	QEMU エミュレータか ARM ホスト
PE (Windows exe)	Linux	いいえ	Wine など互換レイヤ
Mach-O	Linux	いいえ	macOS 環境が必要

トラブルシュート用プレイブック（SOP）

手順（単純化したプレイブック）:

file my_executable を実行して形式とアーキテクチャを確認する。
uname -m でホストのアーキテクチャを確認する。
md5sum/sha256sum で整合性を確認する。
ls -l で権限を確認し、chmod +x を試す。
ldd/readelf/strace を使って不足リソースやエラー箇所を特定する。
必要に応じて再ダウンロード、互換レイヤ導入、あるいは別アーキテクチャでの実行を検討する。
変更後はテストケースを回し、ロールバック手順を記録する。

ロールバックの簡単なルール:

バイナリを上書きする前に元ファイルを保存する（例: mv my_executable my_executable.bak）。
パッケージ管理を使ったインストールであれば、アンインストールと再インストールで戻せる状態を保つ。

役割別チェックリスト

開発者:
- 対応アーキテクチャを明記する。
- ビルドアーティファクトにチェックサムと署名を付与する。
- ソースからの再ビルド手順を用意する。
運用（SRE/DevOps）:
- 配布バイナリの署名検証を自動化する。
- 32/64-bit 共存が必要な場合のランタイム管理をドキュメント化する。
- 本番での実行前にステージングで確認する。
セキュリティ担当:
- 外部配布バイナリの実行権限付与は最小権限で行う方針を維持する。
- 不明なバイナリの実行はサンドボックス化（コンテナ/VM）で行う。

受け入れ基準（確認すべきポイント）

バイナリが正しいアーキテクチャ向けであり、file の出力が期待通りであること。
チェックサムが公式値と一致していること。
実行に必要なライブラリやインタープリタがすべて解決されていること（ldd に not found がない）。
実行権限が付与され、かつ最小権限の原則に従っていること。
テストケースが成功していること（基本的なヘルスチェックが通る）。

テストケース（受け入れテスト例）

正しいアーキテクチャのバイナリを実行して期待する基本出力を得られる。
32-bit / 64-bit の混在環境で、必要な32-bitライブラリを導入して起動できる。
実行権限を外した状態でエラーが出ることを確認し、権限付与で直ることを確認する。
破損したバイナリではチェックサム不一致を検出し、再ダウンロードで修復することを確認する。

セキュリティと運用上の注意点

不明なバイナリを安易に root で実行しない。
可能な限りパッケージ管理されたバイナリを使い、署名とチェックサムを必須にする。
サンドボックス（コンテナ、VM）やアクセス制御でリスクを限定する。

ローカル（日本）でのよくある落とし穴

Debian/Ubuntu 系で古いチュートリアルにある ia32-libs は非推奨になっている場合があります。現在はマルチアーキ対応で dpkg --add-architecture i386 といった手順を使うのが一般的です。
Red Hat 系では yum install glibc.i686 や glibc-devel.i686 のようなパッケージが必要になることがありますが、ディストリやバージョン差に注意してください。
日本語ドキュメントやパッケージ名の翻訳差で検索時に情報が散らばることがあるので公式ドキュメント（英語を含む）も参照してください。

まとめ

エラーの多くは「アーキテクチャ不一致」「破損」「権限不足」「実行インタープリタの欠如」など単純な理由に起因します。
file / md5sum / sha256sum / ldd / readelf / strace を順に使って原因を切り分けると迅速に解決できます。
本番環境では署名やチェックサムの検証、サンドボックス化、パッケージ管理を徹底してください。

質問や具体的なファイル名・エラーメッセージがあれば、実際の出力を提示いただければさらに詳しい診断手順をお伝えします。

参考記事・関連リンク:

Hannah Montana Linux: What is It? Better than other Distro? by J. Shanmugam
How to List Groups in Linux? by K. Masoun
How to Install and Use iTunes on Ubuntu? by Shruti Gupta

Cannot Execute Binary File: Exec Format Error の原因と対処

概要