80KBのタスクマネージャー動画に、開発者たちが呻いた理由

「初代タスクマネージャーは80KBだった」という元Microsoftエンジニアの動画に、千件を超えるコメントが押し寄せている。懐古ではない。何かが長く喉につかえていた人たちが、一斉に漏らした呻きだ。

80KBのタスクマネージャー動画に、開発者たちが呻いた理由

「初代タスクマネージャーは80KBだった」という元Microsoftエンジニアの動画に、千件を超えるコメントが押し寄せている。懐古ではない。何かが長く喉につかえていた人たちが、一斉に漏らした呻きだ。


80KBという数字が呼び起こしたもの

現在のWindowsタスクマネージャーは約4MB。デイヴ・プラマー氏が1990年代に書いた初代版は、その50分の1ほどにあたる80KB程度だったという。本人のYouTubeチャンネル「Dave's Garage」で語られたこの事実自体は、とくに目新しい話ではない。

ところが動画のコメント欄には、半日で千件を超える反応が積み上がった。そのほとんどは、単なる懐かしさでも、Microsoftへの当てこすりだけでもない。長く喉につかえていたものが、一度に押し出されたような文章が並んでいる。

面白いのは80KBという数字そのものではない。その数字を合図に、世界中のエンジニアが同じ方向を向いて呻いたという事実のほうだ。

Windowsタスクマネージャー:サイズの肥大化
初代版(1990年代) プラマー氏が開発
約 80 KB
現行版(2026年) Windows 11
約 4 MB(約50倍)

「家賃を払わない同居人」という比喩

プラマー氏は動画のなかで、現代的なユーティリティ開発を痛烈な比喩で切り捨てた。

すべての依存関係は、あなたの食べ物を食い荒らし、家賃を一切払わない同居人のようなものだ

フレームワークから始めて、快適さのための層と将来対応のための層を何枚も積み上げ、画面に数字をいくつか出すのに何百MBのメモリと壮大な演説を要求するようになる。その過程で、自分が何を抱え込んでいるかを開発者は見失っていく——これがプラマー氏の診断だ。

対する初代タスクマネージャーの設計思想は、すべてが逆側に振られている。頻出する文字列はグローバルに一度だけ読み込む。ドック解除のように稀にしか呼ばれない機能は、呼ばれた瞬間に初めてロードする。プロセスツリーはプログラムごとに問い合わせず、カーネルにプロセステーブル全体を一度だけ要求する。バッファが足りなければ拡張して再試行するという地味な一段も必ず入れる。

補足:通常のアプリは起動時に「別インスタンスが走っていないか」を確認し、あればそちらを前面に出して自分は終了する。プラマー氏の初代タスクマネージャーはもう一段深い。既存インスタンスにプライベートメッセージを投げて応答を待ち、無反応であれば「そいつも固まっている」と判断して新しく立ち上がる。OSが限界に追い込まれた瞬間に呼ばれる道具としての自覚が、この設計に滲んでいる。

同じ動作をさせる書き方はいつも複数ある。そのうち最も軽くなる道を本能で選びにいくこと。それが当時の設計者にとっては、空気のようなものだった。

初代タスクマネージャーの「軽さ」を支えた設計
テクニック 狙い
文字列のグローバル化 頻出する文字列を起動時に一度だけ読み込み、以後は再取得しない
稀な機能の遅延ロード ドック解除など稀にしか呼ばれない処理は、呼ばれた瞬間に初めて読み込む
プロセステーブル一括取得 カーネルにプロセス情報全体を一度だけ要求し、個別の問い合わせを回避する
バッファ拡張+再試行 バッファが足りなければ自動で拡張し、もう一度要求して確実に取り切る

コメント欄に溜まっていた何か

面白いのは、この動画に集まった反応の温度である。上位コメントの多くは、Microsoftへの嫌味でも、プラマー氏への称賛でもない。もっと個人的で、もっと疲れている。

あるコメントは「これはコーディングの授業ではない、人生の授業だ」と書く。別のコメントは「すべてのコード行は存在理由を示さなければならず、無駄な重みは許されない——この考え方が好きだ」と続く。「現代のWindowsがいまもこの哲学を守っていたら」と願う書き込みも目立つ。衛星飛行制御ソフトを書いているという人物は「100MHz、2コアの石で、割り込みハンドラは100kHz周期で回る。だから1命令まで数える」と自分の現場を紹介していた。そういう現場は今も確かに存在している。ただ、市販OSやアプリの世界からは、その感覚がほとんど蒸発してしまっただけだ。

皮肉の混じった声もある。「次のWindowsが出る頃には、タスクマネージャーは3つの異なるAIがプロフェッショナルにバイブコーディングしてくれているから、絶対いいものになるぞ」——これは2026年の空気をひとことで射抜いている。褒めているのか呪っているのか、書いた本人にも分かっていないのかもしれない。

コードの節約は、ハードウェアの節約ではなく、考え方の節約だ——コメント欄を通読すると、声の向きはそこに集まっている。

共通しているのは、「豊かになった器を、なぜこうも無造作に使い捨てるのか」という、もっと根本的な問いかけだ。機能の細部や製品の出来ではなく、ソフトウェアの作り方そのものに、視線が向かっている。

プラマー氏自身が拒否しているフレーム

ただ、ここで一つだけ念を押しておきたい。プラマー氏は「90年代のハードウェアに戻りたい」などとは一言も言っていない。むしろ逆だ。

動画のなかで彼は、あの時代のメモリ不足には独特の「におい」があったとまで言っている。画面の再描画を一つ間違えれば、隣の部屋の同僚の苦しげな声が聞こえてきた——そんな環境に戻りたいわけがない、と彼ははっきり線を引いている。

彼が取り戻したがっているのは、苦しみではなく「本能」のほうだ。作業をまとめて行う本能。正しいものをキャッシュする本能。見えない仕事を省く本能。再描画前に差分を取る本能。カーネルに百回ではなく一回だけ問う本能。そして便利さがユーザーに請求書を回してきたときには、その便利さのほうを疑う本能。

プラマー氏が取り戻したい6つの「本能」
本能 具体的な振る舞い
まとめる 処理を一つずつ細切れに行わず、可能な限りまとめて一度に片づける
キャッシュする 何でも保存するのではなく、再利用する価値のあるものだけを記憶しておく
省く 画面に出ない仕事、ユーザーが気づかない処理をためらわず切り落とす
差分を取る 再描画の前に何が変わったかを見極め、変わっていない部分には触れない
一度だけ問う カーネルに百回問い合わせず、必要な情報を一度の要求で集約して受け取る
便利さを疑う ユーザーに請求書を回すタイプの「便利さ」には、ひとまず警戒心を向ける

この区別は地味に大事だ。「昔は良かった」という単純な懐古と、「当時あった感覚は、ハードウェアが豊かになっても捨てる必要はなかったのではないか」という問いは、並べて書けば似ているが、中身は別物である。コメント欄が呼応していたのは、たぶん後者のほうだ。


「節度」という言葉が持つ、別の意味

DDR5メモリの価格が高止まりし、8GBのビデオメモリでは足りないと嘆かれる2026年に、この動画が広く共有されていることは、偶然のはずがない。

ハードウェアは潤沢になった。しかしその潤沢さを前提にソフトウェアは膨張し、膨張したソフトウェアがまた新しいハードウェアを要求する。この循環のどこかで、ユーザーが受け取る請求書が一段ずつ厚くなっていく。プラマー氏が「同居人」と呼んだものは、気がつけば家の半分を占拠しかけている。

節度という言葉は、禁欲とは違う。必要なだけ取り、不必要な分は取らない、ただそれだけの判断の積み重ねでしかない。初代タスクマネージャーの80KBは、その積み重ねの化石である。化石が今になって注目を集めるとき、生きている世界のほうに何かが起きている。

答えを持っているのは、プラマー氏ではなく、これを読んでいる開発者のほうだ。明日書く一行に、家賃を払わせる気はあるか。


参照元

関連記事

Read more

Linux 7.0、Zen 3の誤検知エラーを土壇場で抑制

Linux 7.0、Zen 3の誤検知エラーを土壇場で抑制

Linux 7.0安定版のリリースが予定される当日、AMD Zen 3のユーザーを長らく悩ませてきた誤検知のハードウェアエラーを黙らせるパッチが、土壇場で送り込まれた。原因はハードウェアではなかった。 リリース当日の駆け込みパッチ Linux 7.0安定版のリリース当日、AMDのマシンチェック例外(MCE)ドライバに対する修正パッチが、ギリギリのタイミングでLinus Torvaldsへ送られた。送り主はx86メンテナのIngo Molnar。件名は素っ気なく、「Zen3クライアントで発生する誤ったハードウェアエラーをフィルタする」とだけ書かれていた。 変更行数はたった8行、対象ファイルは arch/x86/kernel/cpu/mce/amd.c の一か所のみ。リリース直前にカーネルへ入れるにしては、あまりに慎ましい修正だ。だが、この8行の裏には、Ryzen 5000シリーズのユーザーが抱え続けてきた不安があった。 Linux 7.0 直前パッチの概要 送信者Ingo Molnar(x86メンテナ) 宛先Linus Torvalds 件名x86/mc