インストールしないと動かないのはなぜ？ ソフトウェアが OS に組み込まれる仕組みを図解で理解する

PC やスマホを使っていると、こんなクセモノに何度もぶつかるはずです。

• Slack や VS Code は インストールしないと使えない のに、Gmail や Google ドキュメントは URL を開くだけで動く ─ この差は何？
• 世の中には pip（Python）／npm（Node.js）／brew（Mac）／apt（Linux）／winget（Windows）など、インストールでよく見るコマンドがいくつもある ─ あれらは何をしている？
• アプリをインストールするときに 管理者パスワード を求められるのはなぜ？
• Mac の .app はフォルダにドラッグ＆ドロップするだけなのに、Windows の .exe インストーラはダイアログを延々と進めるのはなぜ？

「インストール」という同じ一語にいろんな手触りが混ざっているせいで、なかなかひと言では説明しづらい現象です。ですが、根っこを辿ると すべては同じ理由 にたどり着きます。

ソフトウェアが動くには、OS（Windows・macOS・Linux などの基盤ソフト）に「これからこういうアプリが住みます」と挨拶し、握手してもらう必要がある からです。

「インストール」は、その握手の儀式に名前を付けたものに過ぎません。本記事では、

• 実行ファイル（.exe / .app / .deb など）の中身は何なのか
• なぜプログラム単体では動けず OS の手を借りる必要があるのか
• 「インストール」というブラックボックスが裏で具体的に何をしているのか
• Web アプリ／ポータブル版／コンテナのように「インストール不要」が成立する世界はなぜ可能なのか

を、専門知識ゼロからでも追えるように図解で順を追って解いていきます。

1. プログラムの正体 ─ 実行ファイルは「OS と CPU への指示書」

そもそも、ダウンロードしたあの .exe や .app や .deb は、いったい何が入った “袋” なのでしょうか？ ここを押さえると、なぜ単体では動かないのかが自然と見えてきます。

1-1. 実行ファイルはただのバイト列、ただし「意味のある並び」

実行ファイルは中身を見ると、ただの 0 と 1 の長い列（バイナリ）です。テキストエディタで開いてもほとんど読めません。けれども、その並びには厳密なルールがあって、OS が読み取れば「ここから先がプログラムの本体」「ここはデータ置き場」「ここは外部ライブラリの一覧」 といった具合に意味が立ち上がります。

この「OS が読み解ける形式」のことを、業界では 実行ファイルフォーマット と呼びます。代表的なものは OS ごとに 3 つに分かれていて、すべての PC がこの 3 つのどれかを使っています。

つまり、Windows 用に作られた .exe を Mac でダブルクリックしても動かないのは、OS が読める “指示書のフォーマット” が違うから です。日本語の手紙をフランス人に送っても文字は読めるけど内容は伝わらない、というのに近い状況です。

1-2. 実行ファイルが含む 4 つの主要パート

3 大フォーマットは細部こそ違えど、構造はおおむね共通です。中身を 4 つの部屋に分けて見ると分かりやすくなります。

┌─────────────────────────────────────┐
│ ヘッダ                              │ ← 「これは ELF v1.0」「64bit用」など、OS が最初に読む案内板
├─────────────────────────────────────┤
│ コード（.text）                     │ ← CPU が実行する命令の本体
├─────────────────────────────────────┤
│ データ（.data / .rodata）           │ ← 文字列・定数・初期値などのリソース
├─────────────────────────────────────┤
│ シンボル／リンク情報                │ ← どの外部ライブラリのどの関数を呼ぶかの一覧
└─────────────────────────────────────┘

• ヘッダ は表紙のようなもの。OS は最初にここを読んで「このファイルは自分が動かせる種類か？」を判断します。
• コード が CPU 向けの命令そのもの。add（足す）、mov（移す）、jmp（飛ぶ）などの命令が並んでいます。
• データ はプログラムが扱う材料。表示する文字列、初期値の数字、画像リソースなど。
• シンボル／リンク情報 は「足りない部品の発注書」のような部分。「ここで printf を呼びたいので、外から繋いでね」と OS とローダーに伝える役割。

ここまで来るとピンと来ませんか？ 実行ファイルは 完成品ではなく、”組み立て指示書 + 材料 + 発注書” がセットになった袋 なのです。これだけでは動かず、OS が「指示書を読んで CPU に流し、足りない部品（共有ライブラリ）を繋ぐ」ところまでやってくれて初めて動き出します。

2. プログラムは独りでは動かない ─ OS との会話

§1 で見たとおり、実行ファイルは “発注書” を含んでいます。発注先はどこかというと、OS とその標準ライブラリ です。アプリは画面に文字を出すのも、ファイルを読むのも、ネットに繋ぐのも、すべて自前ではやれず必ず OS にお願いしています。

2-1. アプリ → 標準ライブラリ → カーネル → ハードウェア の 4 層

PC の中で起きていることをざっくり 4 層に積むと、こうなります。

┌─────────────────────────────┐   ← あなたが起動した Slack や VS Code
│   アプリケーション           │
├─────────────────────────────┤
│   標準ライブラリ             │   ← C 標準ライブラリ、.NET、libc、Foundation など
│   （言語ランタイム）         │      アプリと OS をつなぐ翻訳層
├─────────────────────────────┤
│   OS カーネル                │   ← Windows カーネル、Linux カーネル、Darwin など
│                              │      画面・ファイル・ネット・メモリの大元締め
├─────────────────────────────┤
│   ハードウェア               │   ← CPU、メモリ、SSD、GPU、ネットワークカード
└─────────────────────────────┘

アプリが「画面に “Hello” と表示したい」と思ったら、いきなりモニターに信号を送るわけではありません。次の順でバケツリレーが起きます。

1. アプリが printf("Hello") のような関数を呼ぶ
2. 標準ライブラリ（C 言語なら libc、.NET なら BCL）が「画面出力」用の OS への依頼書を作る
3. OS カーネルにその依頼書を渡す（これを システムコール（アプリから OS への業務依頼書） と呼びます）
4. カーネルがディスプレイドライバ経由で ハードウェア に信号を送り、画面に文字が出る

つまり、アプリは “OS にお願いする” という前提で書かれている のです。実行ファイルが OS の手を借りずに動くことは原理的にできません。これが、「特定の OS 用にインストールする」という発想が必要になる根本理由です。

2-2. システムコールという「OS への注文票」

システムコール（OS に「これやって」と頼むための専用窓口）は、たとえば次のような頼み事が代表例です。

どれも “自分でやれない・やってはいけないこと” を OS に代わりにやってもらう仕組みです。逆に言えば、OS の助けがなければアプリは画面 1 文字すら出せません。

3. 【中核】 “install” というブラックボックスの中身

ここまでで「アプリは OS の手を借りないと動けない」ことが見えました。だとすれば、インストールという儀式は OS とアプリの仲を取り持つ準備作業の総称 だと考えるのが自然です。実際、世の中のほぼ全てのインストーラ（.msi、.pkg、.dmg、.deb、.rpm、Mac の .app ドラッグ、Microsoft Store のボタン押下など）は、内部で次の 6 フェーズを順に踏んでいます。

3-1. インストールが裏でやっている 6 フェーズ

各フェーズは数百ミリ秒〜数十秒で進み、合計が「インストールの待ち時間」になります。

1. 1署名検証ダウンロードしたファイルが “ちゃんとした作者から来た本物” か確認（印鑑チェックのようなもの）。Win なら Authenticode、Mac なら Gatekeeper、Linux のパッケージなら GPG 署名。
2. 2展開圧縮された 1 つの袋（インストーラ）を、本体・部品・設定・ドキュメントなどに分解する。ここまでは “材料の取り出し”。
3. 3配置展開したファイルを OS が決めた所定の場所に置く。Win は C:\Program Files\、Mac は /Applications/、Linux は /usr/lib/ や /usr/bin/。
4. 4登録OS の “アプリ名簿” に名前を載せる。Win ならレジストリ（OS が設定をまとめて記録している巨大なメモ帳）に書き込み、Mac は plist、Linux は .desktop ファイル。
5. 5統合スタートメニュー／Launchpad／アプリメニューにアイコンを追加し、対応するファイル拡張子（.txt や .psd など）と関連付ける。
6. 6後処理起動時に必要な常駐サービスの登録、初回起動用のキャッシュ生成、PATH への追加、ショートカットの作成、最後に一時ファイルの掃除。

覚え方：「検証 → 展開 → 配置 → 登録 → 統合 → 後処理」。ダウンロードしてから「使える状態」になるまで、必ずこの 6 ステップを通ります。

3-2. Before / After ─ ファイルシステムが目に見えて変化する

「6 フェーズ」がピンと来にくければ、インストール前と後でディスクがどう変化するか を並べて見ると一発で実感できます。

~/Downloads/
└── SuperApp-1.2.3.exe   ← 1 つの袋

C:\Program Files\SuperApp\
├── SuperApp.exe                ← 本体
├── core.dll, render.dll, ...   ← 部品（共有ライブラリ）
└── resources\                  ← 画像・翻訳ファイル

C:\Users\me\AppData\Roaming\SuperApp\
└── settings.json               ← ユーザー設定

レジストリ HKLM\Software\SuperApp
├── InstallPath = "C:\Program Files\SuperApp"
└── Version = "1.2.3"

スタートメニュー → SuperApp（ショートカット）

ご覧のとおり、インストールは “1 個の .exe を所定の場所に分解配置 + OS に教える” という作業の集合体です。「ダブルクリックで動かない」のではなく、本当はダブルクリック後の数秒〜数分で OS に対する大量のセットアップが行われていた、と考えるのが正確です。

4. 依存ライブラリ ─ なぜ単体 EXE で完結しないのか

「アプリ 1 個なのに、なぜ何百個もファイルが入るの？」という疑問の答えがこの章です。鍵は 共有ライブラリ（複数のアプリで使い回す “部品箱”） という仕組みにあります。

4-1. 共有ライブラリとは

たとえば「画像を JPEG として保存する」処理は、Photoshop も VS Code の拡張も Slack も使いそうな機能です。これを各アプリが自前で持つと、

• ディスクが部品の重複でムダに膨らむ
• セキュリティ修正のとき、全アプリを更新しないといけない

という困りごとが起きます。そこで OS は 共通部品をひとつのファイルにまとめ、複数のアプリから “貸し出す” 仕組みを用意しています。これが共有ライブラリです（拡張子はそれぞれ Win=.dll、Mac=.dylib、Linux=.so）。

                 ┌──────────────────────────┐
                 │  あなたのアプリ（本体）  │
                 └──────────────────────────┘
                       │   │   │
        ┌──────────────┘   │   └──────────────┐
        ▼                  ▼                  ▼
   libjpeg.dll        libssl.dll         libcurl.dll
   （JPEG 部品箱）   （暗号通信部品箱） （HTTP 部品箱）
        │                  │                  │
        └──────────────────┴──────────────────┘
                           ▼
                ┌──────────────────────┐
                │   OS API（カーネル） │
                └──────────────────────┘

アプリ自身は数 MB でも、上のように何枚もの “部品箱” に依存していて、インストール時にはそれらも一緒にディスクへ配置されます。これが「アプリ 1 個なのにインストールフォルダが数百 MB になる」現象の正体です。

4-2. DLL 地獄 ─ 部品の取り合いで起きる事故

共有ライブラリは便利ですが、バージョンが噛み合わないと壊滅的にハマる という歴史的な落とし穴があります。これを DLL 地獄（同じ部品を別バージョンで取り合ってアプリ同士が壊し合う事故） と呼びます。

   アプリA  ─→ libfoo v1.0 を要求
   アプリB  ─→ libfoo v2.0 を要求
                    │
                    ▼
        OS には 1 個しか libfoo を置けない
        →  どちらかが必ず動かなくなる

現代の OS は、

• Windows：WinSxS（Side-by-Side）や Microsoft.UI.Xaml のように、バージョンごとに別ファイル名で共存 させる
• macOS：各 .app の中に必要な .dylib を 同梱（バンドル） することを推奨
• Linux：パッケージマネージャ（後述）が 依存関係の整合性を解決

といった工夫で DLL 地獄を緩和しています。それでも、古いソフトを引っ張り出すと MSVCR100.dll が見つかりません といったエラーで起動しないのは、まさにこの問題の名残です。

5. OS統合 ─ ファイル関連付け・メニュー登録・自動起動

§3 のフェーズ 4〜5（登録・統合）では、アプリの存在を OS に 正式に名乗らせる 作業が走ります。具体的に「OS のどこに何が書き込まれるのか」を OS 別に並べてみると、Win / Mac / Linux の違いが一望できます。

5-1. 何が登録されるのか OS 別比較

「アプリの “外見” は同じでも、各 OS で どのメモ帳に書き込まれるか が全部違う」ことに気づけば、Windows でうまく動いていたソフトを Mac に引っ越すと別物のように振る舞う理由が腑に落ちます。

5-2. なぜ “ただ実行ファイルを置く” だけでは不十分なのか

たとえばあなたが notepad.exe のような実行ファイルを Downloads に置いたまま使い続けても、「単体としては」起動できます。しかし以下のような体験は得られません。

• スタートメニューから素早く起動する
• .txt をダブルクリックすると自動的にそのアプリで開く
• アンインストール画面で 1 クリックで消せる
• 自動更新が走る
• PC 再起動後も同じアイコンで残る

これらは すべて OS 統合の成果物 です。インストールが「ファイルを置く + OS に登録する」の合わせ技になっているのは、こうした体験を提供するためなのです。

6. 権限とセキュリティ ─ なぜ管理者パスワードを聞かれる

「インストールするとき毎回パスワードを聞かれて面倒…」という体験は誰にもありますが、これは OS の安全装置が働いている証拠 です。理屈を一度知ると、聞かれる意味も納得できるようになります。

6-1. システム領域とユーザー領域

OS の中は、書き込みに 管理者権限が要る場所 と 要らない場所 に分かれています。

┌─────────────────────── 管理者権限が必要 ───────────────────────┐
│  Windows: C:\Program Files\, C:\Windows\, HKLM\レジストリ      │
│  macOS  : /Applications/, /Library/, /usr/local/             │
│  Linux  : /usr/, /etc/, /opt/                                │
└────────────────────────────────────────────────────────────────┘
┌─────────────────────── ユーザー権限で OK ─────────────────────┐
│  Windows: %USERPROFILE%\AppData, HKCU\レジストリ              │
│  macOS  : ~/Library/, ~/Applications/                         │
│  Linux  : ~/.local/, ~/.config/                              │
└────────────────────────────────────────────────────────────────┘

§3 のフェーズ 3（配置）で、アプリを システム領域 に置くタイプのインストーラは、この瞬間に OS から「本当にやっていいですか？」と聞かれます。これが、

• Windows の UAC ダイアログ（”このアプリがデバイスに変更を加えることを許可しますか？”）
• macOS のパスワード入力プロンプト
• Linux の sudo パスワード要求

の正体です。逆に、Mac の .app をユーザーフォルダ（~/Applications/）にドラッグするだけならパスワードは不要、というのも同じ理屈で説明できます。

6-2. 署名検証 ─ 印鑑チェックという仕組み

権限の確認に加えて、「そもそもこのインストーラはちゃんとした作者から来たのか？」を OS は事前にチェックしています。これを 署名検証（インストーラが “ちゃんとした作者から来た本物” であることを確かめる印鑑チェック） と呼び、各 OS でこんな仕組みが動いています。

「身元不明の開発元のアプリです」「このアプリは確認できないため開けません」という警告は、すべてこの署名検証の結果を伝えているメッセージです。検証に通らないからといって即マルウェアとは限りません（個人開発者は署名取得が高価で省略しがち）が、検証に通らないものは原則として実行しない が安全側の判断です。

7. 「インストール不要」が成立する世界

ここまでで「インストールとは OS との握手」だと見てきました。だとすれば、握手の手間を別の方法で肩代わりすれば インストールが不要になるはず ─ そして実際、現代では複数のやり方が主流になっています。それぞれの仕組みと、なぜ “インストール不要” が成立するのかを軽く押さえましょう。

7-1. 4 つのアプローチ比較

7-2. それぞれが「インストール不要」を成立させる仕組み

各方式について、初学者向けの言い換え付きでひとことずつ確認します。

• Web アプリ：アプリの本体は 遠くのサーバー にあり、あなたの PC では動きません。動いているのは “ブラウザ” だけ。ブラウザ自身が一度 OS と握手済み なので、その上に乗っているアプリは追加の握手が要りません（飲食店のテーブルを借りるイメージ）。
• ポータブル版（アプリ本体を 1 つの USB に詰めたような形）：必要な部品を全部抱え込み、レジストリや plist にも触らない作りにしてあるので、解凍するだけで動く。代償としてサイズが大きく、OS 統合（メニュー登録・ファイル関連付け）は得られません。
• コンテナ（アプリと必要な部品をまとめて密閉した “持ち運べる小部屋” のようなもの）：アプリだけでなく、それが動くために必要な OS の一部（ライブラリや設定など）まで丸ごと小部屋に詰め、ホスト OS とは隔離して動かします。握手は小部屋の中で完結する ので、外（あなたの PC 本体）にはほぼ何も書き込まれません。クラウド時代に「動作環境ごと配る」という考え方が広まったのは、まさにこの手軽さのおかげです。
• パッケージマネージャ（手作業の代わりに “install” の決まり文句を OS 側で代行してくれる仕組み）：見た目はインストール不要ですが、実際は §3 の 6 フェーズを コマンド 1 行で自動的に走らせている だけです。むしろインストールの “上手な自動化” だと考えると正確です。brew install nginx の数十秒の間に、検証・展開・配置・登録が裏で全部進んでいます。

ここまで来ると、「インストールが必要かどうか」は OS と握手する仕事を誰が肩代わりしているか の違いに過ぎないことが見えてきます。Web アプリならブラウザが、コンテナならコンテナエンジンが、パッケージマネージャなら自動化スクリプトが、それぞれ握手を代行しているわけです。

8. 実際に観察する ─ 何が変わったかを覗くコマンド

理屈が分かったところで、自分の PC でも「インストールでファイルが本当に増えているか」を覗いてみましょう。OS ごとに 1〜2 行のコマンドで簡単に確認できます。

8-1. インストール済みアプリ／パッケージの一覧

まずは “今、自分の PC に何が入っているのか” を OS 別に出してみます。

# Windows (PowerShell)
Get-Package | Select-Object Name, Version | Sort-Object Name

# macOS (Homebrew で入れたもの)
brew list --versions

# Linux (Debian / Ubuntu)
dpkg -l | head -20

8-2. 特定のアプリが置いたファイルを覗く

ある 1 個のアプリがインストール時にどんなファイルを撒いたかを、パッケージ単位で全部見ることもできます。

# Linux (Debian / Ubuntu) ─ git が置いたファイルを全部見る
dpkg -L git | head -20

# macOS ─ 公式 .pkg で入れたものの説明
pkgutil --pkg-info com.apple.pkg.CLTools_Executables

# Windows ─ レジストリの Uninstall 項で一覧表示
Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*' | Select-Object DisplayName, DisplayVersion

実行すると、/usr/bin/git、/usr/share/man/man1/git.1.gz、/etc/bash_completion.d/git など、1 個のアプリが OS 内のあちこちに分散配置されている 様子が一望できます。「ダウンロードした 1 個のファイルが、こんなに広く OS の中に染み出していた」と分かれば、インストールという行為の重みが体感として残るはずです。

まとめ ─ 4 行エッセンス

長い記事でしたが、エッセンスはたった 4 行に圧縮できます。

• アプリは独りでは動けない。OS とハードウェアを借りて初めて動く ─ だから OS と握手する仕組みが必須
• インストールはその握手を実行する儀式 ─ 検証・展開・配置・登録・統合・後処理の 6 フェーズで構成
• 管理者パスワードは “システム領域に書いていい？” という確認、署名検証は “本物の作者か？” という確認
• Web／ポータブル／コンテナ／パッケージマネージャは握手の “代行者” ─ “インストール不要” もどこかで誰かが握手している

これさえ覚えておけば、.exe でも .app でも .deb でも docker run でも、目の前で起きていることを同じ枠組みで読み解けるようになります。

ネットワーク側の土台は前回のIPアドレスとは？で扱いました。今回の “OS とアプリの握手” と合わせると、PC でデータが届いてアプリが動く一連の景色がほぼ揃います。さらに掘り下げたい方は、SQLの数値型を正しく選ぶ技術 のように “プログラム内部でデータをどう持つか” の側に進むと、地続きで学びが広がります。

FAQ

Q1. ポータブル版とインストール版は何が違いますか？

A. 中身（実行ファイル本体）はほぼ同じで、違うのは OS 統合の有無 だけです。インストール版は §3 の 6 フェーズすべてを実行して OS と “深く握手” するので、スタートメニューやファイル関連付け、自動更新が効きます。ポータブル版はフェーズ 1〜2（検証・展開）と 3 の一部（フォルダ配置）だけで止め、OS の名簿には載らない選択をしている、と考えると分かりやすいです。

Q2. アンインストールすれば本当に全部消えますか？

A. ほとんどは消えますが、設定とユーザーデータは残ることが多い です。Windows は C:\Users\<you>\AppData\ 配下の設定ファイル、Mac は ~/Library/Application Support/<App>/、Linux は ~/.config/<app>/ を、アンインストーラはわざと残すのが一般的です（再インストール時に設定が引き継がれる利点があるため）。完全に消したいなら、これらのフォルダを手動で削除するか、AppCleaner（Mac）や Bulk Crap Uninstaller（Win）のようなツールを併用してください。

Q3. Mac の .app はなぜドラッグ＆ドロップだけで動くのですか？

A. .app は実は 「ファイル」ではなく “中身が一式詰まったフォルダ”（バンドルと呼ばれる）です。本体・部品（.dylib）・リソース・Info.plist をすべて中に抱え込んでいるので、外側のレジストリ的な書き換えがほとんど不要で、フォルダを /Applications/ に置くだけで OS が認識できます。Apple が「アプリ＝バンドル」という設計思想に統一したからこそ実現できる手軽さです。Windows の .exe も理論上は単独配置で動きますが、設定はレジストリに散らかる慣習があるため、ドラッグだけでは綺麗に整わないのです。

Q4. Docker は「インストール」したことになりますか？

A. 二重構造で考えてください。Docker そのもの（コンテナを動かすエンジン）はあなたの PC に 1 回ネイティブインストールが必要 です。一度入れてしまえば、その上で動く個々のアプリは「コンテナ」という小部屋に閉じ込められて動くため、追加のインストールが PC の OS には書き込まれません。「インストール不要に見えるアプリ」は、Docker エンジンが裏で握手を肩代わりしているおかげで成立しています。

Q5. 管理者権限なしでもインストールできますか？

A. ユーザー領域に閉じる形なら可能 です。Windows なら %LOCALAPPDATA% に置く “ユーザーインストール” 対応のインストーラ（VS Code の “User Installer” 等）、Mac なら ~/Applications/ へのドラッグ、Linux なら ~/.local/bin/ へのコピーや pipx install --user などが該当します。ただし、システム全体に影響する作業（ドライバ追加、サービス常駐、/usr/local/ への配置など）は本質的にシステム領域への書き込みを伴うため、どうしても管理者権限が必要になります。