この記事の要点

AppImage (.appimage / .AppImage) は Linux 向けの ポータブル実行ファイル形式 1 ファイルで完結、インストール不要・root 権限不要、chmod +x してダブルクリックで起動 内部構造は ELF ランナー + SquashFS（圧縮ファイルシステム） の連結 中身は AppDir 構造（AppRun、*.desktop、usr/bin/、usr/lib/ 等）で、.app バンドルに近い思想 依存は同梱、ディストリ間の互換性問題を回避。Snap / Flatpak と並ぶ「ユニバーサルパッケージ」3 大形式の 1 つ --appimage-extract で中身展開、appimagetool でビルド。更新は zsync による差分更新、署名は GPG

概要

AppImage は 2004 年頃に "klik" として始まり、後に "AppImage" へ改名された配布形式である。Linux におけるソフトウェア配布の長年の難題「ディストリビューションごとに DEB と RPM を別々にメンテする」「依存ライブラリのバージョンが合わない」を、必要な依存をすべて自前で抱え込む 1 ファイルにするという方向で解決しようとするアプローチである。

同じく Linux 向けポータブル配布として Snap（Canonical）と Flatpak（freedesktop.org）があるが、AppImage はランタイム・サンドボックス・常駐デーモン・ストアを必要としない点で最も軽量である。Krita、Inkscape、OBS Studio、Blender、Audacity といった主要 OSS が AppImage 版を公式公開している。

内部構造

AppImage ファイルを file app.AppImage で確認すると、先頭が ELF 実行ファイルであることがわかる。これは「ランナー（type-2 runtime）」と呼ばれる小さな実行コードで、後続に SquashFS イメージが連結されている。

• ELF ランナー — FUSE 経由で SquashFS をマウントし、AppRun を起動する
• SquashFS イメージ — 高圧縮かつランダムアクセス可能な読み取り専用ファイルシステム。unsquashfs で展開可能

SquashFS を展開すると、AppDirと呼ばれる構造が現れる。

MyApp.AppDir/
├── AppRun                  # 起動スクリプト or バイナリ
├── myapp.desktop           # メニュー統合用 .desktop ファイル
├── myapp.png               # アイコン
├── .DirIcon                # アイコンへのシンボリックリンク
└── usr/
    ├── bin/myapp
    ├── lib/libfoo.so.1
    └── share/...

SquashFS の圧縮アルゴリズムは gzip / xz / zstd から選べる。xz は圧縮率重視、zstd は起動速度重視。デスクトップアプリでは zstd が好まれる傾向。

主な用途

• OSS デスクトップアプリの配布 — Krita、Inkscape、OBS、Audacity、KeePassXC、AppImageHub の数千件
• 商用ソフトの Linux 版 — Bitwig Studio、Reaper（実験的）など、ディストリ依存を避けたい場合
• 古い OS への新バージョン投入 — 古い CentOS / Ubuntu LTS で最新 GIMP を動かす、といったユースケース
• USB スティック持ち運び — chmod 済みの AppImage を入れておけば、別の Linux マシンで即起動できる
• CI 成果物 — タグ付きビルドを GitHub Releases に上げる際の標準形式の一つ

関連形式との比較

• vs DEB / RPM — DEB/RPM はシステムに統合される正攻法のインストール、AppImage はインストール不要のポータブル配布。役割が逆。AppImage はディストリを問わない代わりに、システム全体での依存共有はできない。
• vs Snap / Flatpak — Snap/Flatpak はランタイム + サンドボックス + 自動更新の総合パッケージシステム。AppImage はサンドボックスなし（必要なら Firejail などを別途併用）、自動更新は appimageupdate を別途使う。
• vs .app バンドル — 思想は近い（必要なものをぜんぶ抱える）。違いは、.app はディレクトリだが、AppImage は単一ファイル（SquashFS をマウントしている）。
• vs EXE — EXE は OS に大量に依存しがちだが、AppImage は逆に「依存を抱え込んで OS に頼らない」設計。ポータブル EXE と思想は近い。

コマンド・ツール

• chmod +x MyApp.AppImage — 実行可能ビットの付与（必須）
• ./MyApp.AppImage — 直接起動
• ./MyApp.AppImage --appimage-extract — AppDir を squashfs-root/ へ展開
• ./MyApp.AppImage --appimage-mount — 一時マウント（FUSE 不可環境のデバッグ用）
• ./MyApp.AppImage --appimage-version — バージョン情報
• ./MyApp.AppImage --appimage-signature — GPG 署名表示
• ./MyApp.AppImage --appimage-updateinformation — zsync 更新情報の表示
• appimagetool — AppDir から AppImage を生成
• linuxdeploy — 依存ライブラリの自動収集と AppDir 構築
• AppImageUpdate — zsync ベースのデルタ更新ツール
• appimaged — デスクトップに AppImage を自動統合するデーモン（任意）

注意点

• FUSE が必要。多くのディストリで標準だが、コンテナ内・最小構成サーバでは fuse パッケージのインストールが必要なことがある。代替として --appimage-extract 後の直接実行も可能。
• サンドボックスはデフォルトで無い。APK や Flatpak のような権限分離は提供されない。信頼できる配布元から取得すること。Firejail などで隔離するのが定石。
• desktop 統合は手動。.desktop ファイルを ~/.local/share/applications/ へ置かないと、アプリメニューに出ない。appimaged や AppImageLauncher を使うと自動化される。
• 署名検証は習慣化する。配布元の GPG 公開鍵を別経路で取得して、--appimage-signature で検証する。
• glibc バージョンは AppImage 内で同梱できないため、ビルドホストは「サポートしたい最古ディストリ」と同等以下にする必要がある。これを誤ると古い OS で起動しない。
• ファイルサイズが大きい。依存をすべて抱えるため、同等の DEB よりも数倍大きくなる。

関連リンク

• 実行ファイル・パッケージ（親カテゴリ）
• ファイル拡張子とは（概論）
• DEB（.deb） / RPM（.rpm）（システムへ統合する正攻法）
• app（.app）（macOS の「依存を抱え込むバンドル」）
• EXE（.exe）（Windows のポータブル EXE と発想が近い）
• アーカイブ・圧縮形式（SquashFS は xz/zstd を内部で利用）