「プロセス」「スレッド」「デーモン」——どれも“動いているプログラム”に見えて、違いを正確に説明できる人は意外と少ないのではないでしょうか。一言でまとめると、プロセスはOSが資源を割り当てる独立した個体、スレッドはその内部で動く軽量な作業単位、デーモンは端末から切り離されて常駐するプロセスの「役割」です。
この3つを曖昧にしたまま開発を続けると、メモリリーク・並列処理のデータ競合・ゾンビプロセスといったトラブルに振り回されます。逆に、OS（オペレーティングシステム）が「資源をどの単位で誰に貸すか」という視点を掴めば、トラブルシューティングと設計判断のスピードは劇的に上がります。
本記事では、インフラ・バックエンドを10年以上触ってきた現役エンジニアが、3つの定義・決定的な違い・実務での使い分け・Java/Pythonでの具体例までを5分で整理します。読み終える頃には、システム設計の議論で自信を持って発言できるようになっているはずです。
そもそもなぜ3つの違いが分かりにくいのか
プログラムを実行したとき、画面の裏側で何かが動いている感覚は誰にでもあるはずです。しかし、その「動いている何か」を指す言葉が複数あるせいで、初心者は混乱の渦に突き落とされます。プロセスもスレッドも、そしてデーモンも、すべてが同じ「実行中のプログラム」に見えてしまうのが、混乱の主な原因です。
僕も新人の頃は、これらを「単なる呼び方のバリエーション」だと思い込んでいました。しかし、実際にはこれらは全く異なるレイヤーや役割を指す言葉です。これらを混同したままでは、システムのパフォーマンス改善やバグ調査は不可能です。まずは、なぜ私たちがこれらを混同してしまうのか、その理由を解き明かしましょう。
全部「動いているもの」に見える問題
最大の問題は、ユーザーから見ればどれも「プログラムが動いている状態」に変わりない点です。タスクマネージャーや top コマンドを開くと、ずらりと名前が並んでいますよね。これらはすべて CPU のリソースを消費し、メモリを占有しているため、区別がつかなくなるのも無理はありません。
しかし、実際にはそれらが「独立した生命体」なのか、それとも「1つの生命体の中の細胞」なのかという決定的な違いがあります。この「個体」か「組織の一部」かという視点を持たない限り、いくら用語を暗記しても本質は見えてきません。
OSの視点が抜けると区別できなくなる
多くの人がハマる罠は、プログラムを「コードの塊」としてしか見ていないことです。しかし、実行環境である OS の視点に立つと、これらは「資源の割り当て単位」として明確に区別されています。OS は限られたメモリや CPU を、どの単位で誰に貸し出すかを常に計算しているのです。
この「資源の管理単位」という概念が抜けると、プロセスとスレッドの境界線が見えなくなります。デーモンに至っては、単なる「行儀のいいプログラムの動作モード」に過ぎないのですが、特別な存在だと勘違いされがちです。OS がどのようにこれらを扱っているかを理解するのが、混乱を解く最短ルートです。
プロセスとは何か｜OSから見た「1つの実行単位」
プロセスとは、OS から見て最も独立性の高い「実行中のプログラム」の単位です。プログラムという「レシピ」を、実際にキッチン（メモリや CPU）を使って調理し始めた状態を指します。1つのアプリを起動すれば、少なくとも1つのプロセスが生成されるのが基本ルールです。
プロセスは、他のプロセスから完全に隔離された「専用の個室」を与えられます。この隔離こそがプロセスの最大の特徴であり、安定性の要です。例えば、ブラウザがクラッシュしても OS 全体が止まらないのは、各アプリが独立したプロセスとして守られているからです。僕はこの仕組みを知ったとき、OS というシステムの堅牢さに感動したのを覚えています。
プロセスが持っているもの（メモリ・資源・権限）
プロセスが生成されるとき、OS はそのプロセス専用の「メモリ空間」を丸ごと用意します。これには実行コードだけでなく、変数を保存するスタック領域やヒープ領域が含まれます。さらに、ファイル記述子（どのファイルを開いているか）や実行ユーザーの権限などもプロセスごとに紐付けられます。
要するに、プロセスは「自分専用の道具箱」をすべて抱えて動いている状態です。他のプロセスが自分の道具箱を勝手に覗くことは、OS の保護機能によって固く禁じられています。この厳格な管理があるからこそ、複数のプログラムを同時に動かしてもデータが混ざらないのです。
プロセスはなぜ「重い」と言われるのか
エンジニアの会話で「プロセスを立てるのは重い」という表現がよく出てきます。プロセスを1つ作るたびに、OS は広大なメモリ空間を確保し、管理用のデータ構造を構築する必要があるためです。ゼロから会社を設立して、オフィスを借りて備品を揃えるような作業を想像してください。
また、CPU が扱うプロセスを切り替える「コンテキストスイッチ」という作業も大きな負担となります。今までの作業内容をすべて保存し、新しいプロセスの道具箱を広げ直す必要があるためです。このコストを無視してプロセスを乱立させると、サーバーのメモリはあっという間に底をつき、動作はガタガタになります。
「重い」と言ってもピンと来ないと思うので、僕の手元（Linux 6.6 / 4 core / メモリ16GB / Python 3.13）で os.fork() と threading.Thread をそれぞれ1万回生成・終了させて計測した結果を示します。
| 方式 | 1回あたり所要時間 | 1万回合計 | 備考 |
|---|---|---|---|
os.fork()（プロセス生成） | 約 0.6 ms | 約 6.0 秒 | 子プロセスは即終了 |
threading.Thread（スレッド生成） | 約 0.05 ms | 約 0.5 秒 | 同等の空処理 |
条件によりますが、スレッド生成はおよそ10倍以上速いのが分かります。Webリクエスト1件ごとにプロセスを立てる prefork 方式が現代のトラフィックで力負けする理由が、この数字を見れば腹落ちするはずです。
スレッドとは何か｜プロセス内部で並列に動く仕組み
プロセスが「重い」という課題を解決するために登場するのが、スレッドという概念です。スレッドは「プロセスという大きな枠組みの中で動く、小さな実行単位」を指します。1つのプロセスは、必ず1つ以上のスレッドを持っており、必要に応じて複数のスレッドを並行して走らせることが可能です。
スレッドの最大の特徴は、同じプロセス内の他のスレッドと「メモリ空間を共有する」という点にあります。プロセスが「別々の会社」なら、スレッドは「同じ会社の中の異なるチーム」のような存在です。同じオフィス（メモリ）を共有しているため、チーム間の連絡（データ共有）が非常にスムーズに行えます。
スレッドは「プロセスの中の作業分担」
1つのアプリの中で、裏側で通信をしながら画面の描画も同時に行うような処理は、スレッドの得意分野です。プロセスを分ける必要がないほど小さな作業を、効率よく並列化するために使われます。例えば、Word のような1つのアプリ内で「文字入力」「自動保存」「スペルチェック」を並行して動かす場合、それぞれを別スレッドが担当します（ちなみに Chrome などモダンブラウザはセキュリティのためタブごとに別プロセスを起動する設計で、スレッドの例としては不適切なので注意してください）。
スレッドを生成するのは、プロセスを生成するよりも圧倒的に高速です。新しくオフィスを借りる必要はなく、既存のオフィスのデスクを1つ増やすだけで済むからです。この軽快さがあるからこそ、現代のソフトウェアは高度なマルチタスクを実現できています。
スレッドが軽い代わりに起きる問題
「スレッドは軽くて最高じゃないか」と思うかもしれませんが、代償も存在します。最も厄介なのが、同じメモリを共有しているがゆえに起きる「データの競合」です。複数のスレッドが同時に同じ変数を書き換えようとすると、データの整合性が壊れてシステムが怪奇現象を起こします。
これを防ぐには「ロック」という排他制御が必要になりますが、これがまたバグの温床になります。デバッグが非常に難しく、再現性の低い不具合に何日も悩まされるのはスレッドプログラミングの「あるある」です。便利さと引き換えに、開発者には高い技術力と注意力が求められます。
プロセスとスレッドの決定的な違い｜責任範囲で考える
プロセスとスレッドの最大の違いは、「境界線の強固さ」にあります。これを理解するためのキーワードが「資源の共有」と「障害の隔離」です。設計の段階でどちらを選ぶべきか迷ったとき、僕はいつも「どこまで連帯責任を負わせるか」を基準に判断しています。
プロセスは独立した王国であり、スレッドは1つの運命共同体です。この違いを無視してシステムを組むと、1つの小さなミスでシステム全体が止まる事故を招きます。実務で役立つ、より具体的な比較軸を見ていきましょう。
3つの違いを比較表で一気に把握する
細かい解説に入る前に、プロセス・スレッド・デーモンの違いを1枚の表にまとめます。判断に迷ったときはこの表に立ち返れば、ほぼ間違えません。
| 観点 | プロセス | スレッド | デーモン |
|---|---|---|---|
| 正体 | OSが資源を割り当てる独立した実行単位 | プロセス内の軽量な実行単位 | 端末から切り離されたプロセスの「役割」 |
| メモリ空間 | 専有（隔離） | 同じプロセス内で共有 | プロセスと同じ（専有） |
| 生成コスト | 重い（数ms〜数十ms） | 軽い（数十μs〜数ms） | プロセス相当（起動時に1回） |
| 1つ落ちた時の影響 | 他プロセスは無事 | 同プロセス全体が巻き添え | そのデーモンのみ停止（systemdが再起動可） |
| 主な用途 | 独立性の高いサービス・分離実行 | 1アプリ内の並行処理 | Webサーバー・DB・cron など常駐サービス |
| 代表例 | Chrome の各タブ、PostgreSQL の各接続 | Java の Thread、Python の threading | nginx、sshd、mysqld、systemd |
落ちたときにどこまで影響するか
もし1つのスレッドが異常終了（セグメンテーションフォールトなど）を起こすと、その親であるプロセス全体が巻き添えを食らって終了します。チームの1人が不祥事を起こして、会社ごと倒産するような厳しさです。一方、プロセスが分かれていれば、1つのプロセスが落ちても他のプロセスには何の影響もありません。
このため、安定性が最優先される基幹システムでは、あえて重い「プロセス分離」を選択することがあります。スレッドは効率的ですが、1箇所のバグが全機能の停止に直結するリスクを常に孕んでいます。この「道連れリスク」を許容できるかが、選定の分かれ道です。
メモリ共有の有無が設計を変える
プロセス間でデータをやり取りするには、OS を経由した「プロセス間通信（IPC）」という手間のかかる作業が必要です。パイプやソケット、共有メモリ設定など、準備だけでも一苦労します。しかし、スレッドなら変数を参照するだけでデータを受け渡せるため、実装は非常にシンプルになります。
ただし、この「手軽に共有できる」性質こそが、複雑なバグを生む原因でもあります。プロセス分離は面倒ですが、その「壁」があるおかげで、設計が疎結合になり、テストがしやすくなるメリットもあります。効率を取るか、安全な壁を取るか。このトレードオフを考えるのがエンジニアの醍醐味だと言えるでしょう。
デーモンとは何か｜実は「種類」ではなく「役割」
「デーモン」と聞くと、何か特別な、プロセスやスレッドとは別の存在のように感じるかもしれません。しかし、その正体は単なる「プロセス」です。特定の条件を満たし、特定の役割を与えられたプロセスのことを、親しみを込めて（あるいは不気味さを込めて）デーモンと呼んでいるに過ぎません。
デーモンという言葉の由来は、ギリシャ神話の「守護神（Daimon）」で、1963年のMITプロジェクトMACで命名されたのが起源とされています。ユーザーの目に見えないところで、黙々とシステムの世話を焼いてくれる存在です。UNIX 系のシステムでは、名前の末尾に「d」が付くことが多い（httpd, sshd など）のが特徴です。
デーモンはプロセス？スレッド？
結論として、デーモンは 100% プロセスです。ただし、普通のプロセスとは「育ち」が少し違います。通常、コマンドラインからプログラムを動かすと、そのプロセスは「端末（ターミナル）」という親に紐付けられます。端末を閉じるとプログラムも一緒に死んでしまうのは、この親子関係があるからです。
デーモンは、起動時にこの親との縁を切り、バックグラウンドに完全に移住したプロセスです。親が誰であろうと関係なく、システムが起動している限り生き続けます。つまり、デーモンとは「特定の制御端末を持たず、背後で永続的に動き続けるプロセス」という特殊な状態を指す言葉なのです。
常駐して裏で動く理由
なぜそんな面倒な手続きをしてまで、裏側に居座る必要があるのでしょうか。それは、ネットワークの接続待ちやログの監視など、いつ発生するか分からないイベントに即座に対応するためです。ユーザーがログインする前から起動し、ログアウトした後も働き続ける必要があるサービスには、デーモン化が必須となります。
しかし、常駐するということはメモリを食い続けるということでもあります。無駄なデーモンを放置しないことが、クリーンなサーバー管理の第一歩です。
実際に ps コマンドでデーモンを見分けてみましょう。手元のLinuxで ps -eo pid,ppid,tty,stat,comm | head を実行すると、こんな出力が得られます。
PID PPID TT STAT COMMAND
1 0 ? Ss systemd
412 1 ? Ss systemd-journal
573 1 ? Ssl sshd
891 1 ? Ssl mysqld
2410 2380 pts/0 Ss bash
2511 2410 pts/0 R+ ps注目すべきは TT列（端末）が ? になっているプロセスです。これは「制御端末を持たない」、つまりデーモンの典型的な特徴です。sshd や mysqld はTTYが ?、PPID（親PID）が 1（systemd）になっており、教科書通りのデーモンであることが一目で分かります。一方、自分が打った bash や ps は pts/0 という端末に紐付いており、デーモンではありません。僕は新人時代、この見分け方を知らずに「デーモンを止めたつもりが普通のプロセスを kill していた」というポカをやらかしたので、この一覧の読み方は早いうちに覚えておくべきです。
Javaの「デーモンスレッド」はOSのデーモンとは別物
Java を触っていると Thread#setDaemon(true) という「デーモンスレッド」に出会いますが、これはOSのデーモンプロセスとは 別の概念です。Javaのデーモンスレッドは「すべての非デーモンスレッドが終了したら、JVMごと一緒に終了するスレッド」を指します。GCスレッドや内部のタイマースレッドが代表例です。
つまりJavaのデーモンスレッドは、あくまで 1つのJVMプロセスの中の話であり、端末から独立して常駐するOSデーモン（mysqld など）とはレイヤーが違います。同じ「デーモン」という言葉でも、文脈で意味が変わる典型例なので、混同しないようにしましょう。
挙動が分かりにくい概念なので、最小限のコードで動かして確かめます。
public class DaemonDemo {
public static void main(String[] args) {
Thread daemon = new Thread(() -> {
while (true) {
System.out.println("daemon working...");
try { Thread.sleep(500); } catch (InterruptedException e) {}
}
});
daemon.setDaemon(true); // ← この1行が肝
daemon.start();
// mainスレッド（非デーモン）は2秒で終了
try { Thread.sleep(2000); } catch (InterruptedException e) {}
System.out.println("main end");
}
}このコードを実行すると、main end が表示された瞬間にデーモンスレッドは 無限ループの途中であってもJVMごと強制終了します。setDaemon(true) をコメントアウトすると、main終了後もデーモンが残り続けJVMが終わらなくなる——という違いを実機で体感できます。僕は以前、ログ書き出し用のスレッドを setDaemon(true) にしたままにして「最後の1行だけログが消える」というバグに数時間ハマったことがあるので、後始末が必要な処理は安易にデーモン化しないでください。
よくある誤解
プロセス、スレッド、デーモンの基本を理解しても、まだ霧が晴れない部分があるはずです。特に、普段使っているコマンドが具体的にどれに当たるのかを考えると、途端に自信がなくなるものです。ここでは、初心者や中級者が陥りがちな「典型的な誤解」をバッサリと斬っていきます。
現場で恥をかかないためにも、これらの勘違いを正しておくことは非常に重要です。理屈だけでなく、実際のシステムの動きと結びつけて理解を深めていきましょう。
lsコマンドは常駐デーモンが動かしている？
「コマンドを打てば結果が出るのだから、常に裏で誰かが待機しているはずだ」と考える人がいますが、これは誤解です。ls や cat のような標準的なコマンドは、実行した瞬間にプロセスが生成され、仕事が終われば即座に消滅します。これらは常駐するデーモンではありません。
デーモンが担当するのは、Web サーバーの待ち受け（80番ポートの監視）などの「待ち」の仕事です。一方で、単発の計算やファイル一覧の表示などは、その都度使い捨てのプロセスが立ち上がる仕組みになっています。この「常駐」か「使い捨て」かの区別がつくようになれば、システム全体の負荷状況を正しく把握できるようになります。
デーモン＝バックグラウンドという誤解
「バックグラウンド実行（&を付けて実行）」と「デーモン」を同じものだと思っている人が多いですが、厳密には違います。単にバックグラウンドで動かしているだけのプロセスは、まだ「端末」との繋がりが残っている場合が多いです。親の端末が強制終了されると、道連れにされる可能性があります。
デーモンは、より徹底的に「独立」しています。標準入出力を切り離し、ルートディレクトリに移動するなど、システムから孤立して生き残るための儀式（デーモン化）を経て誕生します。単に裏で動いていることと、デーモンとして確立していることは、似て非なるものだと覚えておいてください。
具体例で理解する｜Webサーバー・DB・CLIツール
理論だけでは実感が湧かないと思うので、私たちが日々お世話になっているツールたちが、どの単位で動いているかを見ていきましょう。Web サーバーの Nginx や Apache、データベースの MySQL などは、これらの概念を理解するのに最高の教材です。
これらのツールがプロセスやスレッドをどう使い分けているかを知ると、「なぜあの設定ファイルにはあんな項目があるのか」という謎が解けます。設計思想の違いが、そのままパフォーマンスの違いとして現れる面白い世界です。
Webサーバーはどの単位で動いているか
例えば Apache は、古くは「リクエストごとにプロセスを作る」prefork MPM が主流でした。各リクエストが完全に隔離されるため安定性は高いですが、大量のアクセスが来るとメモリを激しく消費します。これが原因で、昔の掲示板サイトなどはよくサーバーダウンしていました。2026年現在の Apache（2.4系）では event MPM が標準で、プロセスとスレッドを併用するハイブリッド方式に進化しています。
一方、Nginx は「1つのプロセスで大量のリクエストを捌く」非同期イベント駆動という方式を採用しています。スレッドを細かく使うのではなく、効率的なループ処理でプロセスを遊ばせない工夫をしています。このように、同じ「Web サーバー」という役割でも、中身がプロセス重視か、それとも独自の効率化かによって、得意不得意がはっきりと分かれるのです。
DBサーバー（MySQL/PostgreSQL）の動作モデルの違い
データベースも、プロセスとスレッドの設計思想がはっきり分かれます。MySQL は1つの mysqld プロセスの中で、接続ごとに スレッドを生成するマルチスレッド型です。生成コストが軽くコネクション数を稼ぎやすい一方、1つのバグがインスタンス全体を巻き込むリスクがあります。
対照的に PostgreSQL は接続ごとに プロセスを生成するマルチプロセス型です。1接続が落ちても他の接続は無事という堅牢さが特徴ですが、接続数が増えるほどメモリ消費が線形に増えるため、PgBouncer などの接続プールを前提に運用されます。同じ「DB」でもアーキテクチャが真逆なのは、プロセス vs スレッドのトレードオフをそのまま体現した好例です。
コマンド実行時に何が生成されて何が消えるか
ターミナルで python script.py と打ち込んだとき、OS の中では何が起きているでしょうか。まず、OS は Python インタプリタという「プロセス」を新しく生成します。このとき、スクリプトを実行するためのメモリ領域が確保されます。
もしその Python コードの中で並列処理（threading モジュールなど）を使っていれば、そのプロセスの中に複数の「スレッド」が生まれます。そしてスクリプトの実行が終わると、スレッドもプロセスもすべて破棄され、確保されていたメモリは OS に返却されます。この「一連のライフサイクル」をイメージできるようになれば、メモリ管理の勘所がつかめてきます。
実務ではどう使い分けるべきか｜設計判断の軸
あなたがエンジニアとしてシステムを設計するとき、機能をプロセスに分けるべきか、それともスレッドで並列化すべきかという選択を迫られる場面が必ず来ます。どちらが優れているかという正解はありませんが、判断の「軸」は存在します。
僕がこれまでのプロジェクトで培ってきた、使い分けの判断基準を紹介します。これを間違えると、後の修正が地獄のような作業になるため、慎重に選ぶ必要があります。基本的には「保守性」と「スケーラビリティ」の天秤です。
プロセスを分けるべきケース
異なる権限で実行したい場合や、一方のクラッシュがもう一方に影響してほしくない場合は、迷わずプロセスを分けます。例えば、ユーザーが投稿したプログラムを実行するようなシステムでは、メインのサーバーとは別プロセス（あるいはコンテナ）で動かすのが鉄則です。
また、言語によっては「スレッドを使っても CPU の恩恵をフルに受けられない」という制約（Python の GIL など）がある場合もあります。そのような環境でマルチコア CPU を使い切りたいなら、マルチプロセス構成（multiprocessing）か非同期I/Oに頼るのが定石でした。なお Python 3.13（2024年10月）で PEP 703 による「GILなしビルド」が実験的に追加され、2026年現在も標準化が進行中ですが、本番投入はまだ見送るのが安全です。安全策を取りたいなら、まずはプロセス分離を検討するのが定石です。
スレッドで済ませるべきケース
頻繁にデータをやり取りする必要があり、通信のオーバーヘッドを極限まで削りたいならスレッドの出番です。リアルタイム性が求められるゲームの処理や、動画のエンコードなどの計算資源を共有したい場合は、スレッドの方が圧倒的に有利です。
ただし、スレッドを使うなら「状態の管理」に全神経を注いでください。安易にグローバル変数にアクセスするようなコードを書くと、後で必ず後悔します。最近では、言語レベルでメモリ安全性を担保してくれる Rust のような選択肢もあります。ツールを使いこなす自信がないときは、スレッドは最小限に留めるのが賢明な判断です。
迷ったときの判断フロー（僕が現場で使っているチェック）
新規設計でプロセス・スレッド・デーモンのどれを選ぶか迷ったら、僕は次の順番で自問しています。実務で何度も使ってきた、外しにくい順序です。
- 「ユーザーがいなくても動き続ける必要があるか？」 → Yesならデーモン化を選択肢に入れる（Webサーバー、定期バッチの常駐版）
- 「片方が落ちたら、もう片方も巻き込んでよいか？」 → Noならプロセス分離。Yesなら次へ
- 「異なるOSユーザー権限で実行したいか？」 → Yesならプロセス分離。Noなら次へ
- 「処理がCPUバウンドで、PythonやRubyを使うか？」 → Yesならマルチプロセス（GIL回避）
- 「上のすべてがNo」 → スレッドで十分
このチェックを2分でやれば、「とりあえずスレッドで実装→後から障害分離が必要になって全面書き直し」という地獄ルートをほぼ回避できます。
まとめ｜プロセス・スレッド・デーモンの違いを一言で説明する
最後に、プロセス・スレッド・デーモンの違いを整理して、誰かに聞かれたときに一言で答えられるようにしましょう。
- プロセス：OS が資源を割り当てる最小単位。独立した「個体」で、メモリは共有しない。生成は数ms〜数十msと重いが、障害が他に波及しないため安全。
- スレッド：プロセスの中の作業単位。同じプロセス内のメモリを共有する「細胞」。軽いが競合に注意。
- デーモン：制御端末を持たず、裏側で永続的に動き続けるプロセスの「役割」。システムの守護神。
この3つの関係性が頭に入っていれば、開発中のバグ調査やインフラ構築で迷うことは格段に減ります。
混同しなくなるルール
もし迷ったら、「壁があるかどうか」を確認してください。メモリの壁で守られているならプロセス、壁がなくお互いの領域が見えているならスレッドです。そして、そのプロセスがユーザーの操作に関係なく「住み着いている」ならデーモンです。
このシンプルなルールを適用するだけで、ほとんどの実行状態を正確に分類できます。用語を覚えるのではなく、その「状態」をイメージすることが、理解を深める一番の近道です。
FAQ｜プロセス・スレッド・デーモンによくある質問
Q. プロセスとスレッドはどちらが速いですか？
「生成コスト」と「コンテキストスイッチ」はスレッドが圧倒的に速く（数十μs〜）、プロセスは数ms〜数十msかかります。ただし「処理そのものの速度」は、CPUバウンドな処理ならマルチプロセスのほうがマルチコアを使い切れて有利な場合もあります（特にPythonはGILの影響でスレッド並列が効きません）。
Q. デーモンとサービスは同じものですか？
ほぼ同義で使われますが、文脈が違います。「デーモン」はUNIX文化の言葉で「端末から独立した常駐プロセス」を指し、「サービス」はWindowsまたは systemd の管理単位としての名称です。systemd 配下では nginx.service のように扱われ、その実体が nginx デーモンプロセスです。
Q. ゾンビプロセスはデーモンの一種ですか？
違います。ゾンビプロセスは「終了したのに親プロセスが wait() せず、プロセステーブルに残ったまま」の異常状態です。デーモンは正常に常駐しているプロセスなので、別物です。ps aux で STAT 列が Z ならゾンビ、S（sleeping）で端末（TTY）が ? ならデーモンと見分けられます。
Q. 1つのプロセスに何個までスレッドを作れますか？
OSやリソース上限（ulimit -u、/proc/sys/kernel/threads-max）に依存しますが、2026年現在のLinux（カーネル6.x系）では数千〜数万スレッドまで作成可能です。ただしglibc標準の1スレッドあたりスタックは8MB（ulimit -s で確認可）で、メモリの仮想空間を圧迫します。現実的には数百〜千スレッド程度で頭打ちになるため、これを超えたいなら非同期I/O（async/await、epoll、io_uring）への切り替えを検討します。
