世界を動かす技術を、日本語で。

ウィルスの復讐

2026年2月5日原文(jmoiron.net)

概要

  • Niklaus Wirth による「A Plea for Lean Software」と Wirth's Law の紹介
  • ソフトウェアの 複雑化と遅延、ハードウェア進化の関係性
  • クラウドコンピューティング による新たなトレードオフ
  • ORMの使い方LLM活用 におけるコスト意識の重要性
  • 効率性と利便性の バランス、現代ソフトウェア開発の課題

Wirthの法則とソフトウェアの膨張

  • Niklaus Wirth のエッセイ「A Plea for Lean Software」で提唱された Wirth's Law ソフトウェアがハードウェアの進化以上の速さで遅くなっている現象
  • 1970年代のテキストエディタやOSは 数KB で動作 現代の同等ソフトは 数MB を必要とする現状
  • 機能追加(ウィンドウ、カット&ペースト、アイコン等)による 利便性向上 その一方で ランタイムコスト やパフォーマンス低下
  • 技術的観点だけでなく 社会的価値 も評価対象とすべきという指摘
  • Wirth の思想が後の開発者や筆者自身の設計思想にも影響

入力遅延と複雑性のトレードオフ

  • Dan Luu による2017年の入力遅延調査 Apple 2e(1983年)が最も低遅延という結果
  • 入力処理パイプラインの 複雑化 による遅延増加 柔軟性を得る代償としての レイテンシーコスト
  • 現代の低遅延システムは 複雑性の追加 で問題を解決 単純化ではなく、より高度な仕組みの導入による対応

クラウドコンピューティングの時代

  • 1995年当時、インターネット企業の インフラ要件 はシンプル 利用者数も少なく、 高可用性 も未要求
  • 2010年には利用者が 20億人 に増加 システム規模や 可用性要件 が飛躍的に拡大
  • データセンター運用 の複雑化、初期投資・運用負担の増大
  • クラウドサービス (AWS等)の登場により 柔軟なリソース利用・コスト最適化が可能に
  • クラウド導入で パイプラインの複雑性 は増すが、 アクセシビリティやリスク低減という明確な価値

ORM利用と「悪いWirthトレードオフ」

  • Djangoアプリ開発時の経験 ORMの 自動外部キー読込 によるパフォーマンス劣化
  • テンプレート内での 多重ループDB負荷増大 を招く
  • 全体最適化が難しい複雑なテンプレート構造
  • キャッシュレイヤー 追加による問題解決 複雑性を増やしてパフォーマンスを確保
  • 安易な利便性追求が 予想外のコスト を生む例

LLM時代の新たなコスト認識

  • LLMの登場で 非エンジニア層 もプログラミング的体験が可能に
  • LLMの利用は 計算資源消費 が非常に大きい 単純計算ですら 従来のPCの何万倍ものリソース を消費
  • ORM同様、 コスト意識の欠如 が無駄な消費を招くリスク
  • LLMに直接タスクを依頼するのではなく スクリプト生成 に活用し、効率的な自動化を図る手法が主流
  • LLMによるタスク実行は 信頼性や再現性 に課題 決定論的なプログラム構築の重要性

LLM利用の失敗例と教訓

  • LLMでレシピデータ変換を依頼したが 低速かつ不正確 な結果、手作業以下の効率
  • エンジニアがLLMを評価する際は スクリプト生成 等の補助的用途が中心
  • LLMを繰り返し使うタスクでの コスト爆発 例 Twitterの事例:リマインダー用エージェントがAPIを大量呼び出し 一晩で 約20ドル の無駄な課金発生

現代ソフトウェア開発における本質的課題

  • ソフトウェアの 複雑性増加利便性向上 のトレードオフ
  • 技術的効率だけでなく 社会的価値 の評価視点
  • 新技術導入時の コスト意識設計判断 の重要性
  • Wirth's Law の現代的再解釈と、 効率・利便性・持続可能性のバランス

このように、Wirthの法則は今なお現代のソフトウェア開発において重要な示唆を与えている。ソフトウェアの肥大化や複雑化は避けられないが、利便性・アクセシビリティ・社会的価値を理解しつつ、コストと効率のバランスを意識した設計判断が不可欠である。

Hackerたちの意見

著者は、アクセスしやすくするためにソフトウェアのレイヤーが多く関与していると言っているけど、私の経験では、ほとんどの場合はアプリ開発者が怠けているだけだと思う。例えば、Claude CodeがReactを使ってターミナルで何を描画するかを決める事例があって、それが遅延を引き起こしているんだ。開発者たちは、60 FPSを達成するのに「たった」16.7ミリ秒しかないと嘆いている。ターミナルでね。ターミナルはそれ以上のことができるはずなのに。Primeagenが示した例[0]では、ターミナルの変更が多いアプリケーションでも、何も比較せずに新しい変更を表示するだけで、かなり速く動くってことがわかるよ! [0] https://youtu.be/LvW1HTSLPEk

そうだね、これの多くは制度やインフラの慣性、抽象化の負債、第二次以上の無知、専門性の狭まりに起因していると思う。今これを作っている人たちは、Reactなどを使いこなせるレベルには達しているけど、彼らの焦点は機械学習にあるべきだよね。ターミナルの処理を低レベルで超高速にできる人たちは、今は引退して島に住んでいるか、亡くなっているか、こういう会社が求める他の専門性を持っていない。ユーザーは、アプリが10倍速くビルドされるなら、ターミナルでの16.7ミリ秒なんて気にしないから、そのトレードオフは明らかだよ。

もっとグラフィックスプログラマーがアプリ開発に飛び込んでくれたらいいのに。16.7ミリ秒は彼らにとっては大きな時間だし、60フレーム毎秒なんて目標としては低すぎる。144じゃなきゃダメだね。

これ、1980年代の技術みたいだね。逆に、動画の中の人がリモート接続で帯域制限のある環境でアプリを動かしてたら、diffingの方がパフォーマンス良かったかも。俺は職場に1GbpsのGoogleファイバーがあるけど、VPNの帯域が時々数百kbpsに落ちることもあるし、もっとひどい時もある。

記事の高レベルなポイントはよくわからないけど、プログラマーとしてAIエージェントを使って正確で効率的なプログラムを書く方がいいっていう観察には同意するよ。エージェントにその作業をさせるのが理想だけど、エージェントにやらせたいことがプログラムとして表現しやすいわけじゃない。でも、コンピュータが得意なことはわかってるよね。もし正しい結果に賭けなきゃいけないなら、AIモデルに5000の数字を「頭の中で」ソートさせるのと、ソートするプログラムを書いてそれを実行させるの、どっちがいいと思う?これは明らかだと思うけど、最近はプロの人たちがAIモデルを変なところに挿入して、GenAIを取り入れてるって言ってるのをよく見るよ。

面白い記事だったし、LLMの修正や執筆の痕跡が全くないものを読むのは新鮮だった。LLMにアプローチするための複数のモードがあるという有益な洞察が含まれていて、それが使用する際の結果の大きな差を説明するのに役立つ。余談だけど、この記事は「2月2日」って日付がついてるけど、フッターには「2025」って書いてある。これは古い生成されたフッターで、2026年のことを指してるのかな?

実際の制約は、人々が結果を待つことにどれだけの時間をかけるかだよね。結果が本当に良いと期待されるなら、人々は長い時間待つだろう。だから、エンジニアはものが動き始めたらすぐに次の機能に移るんだ。人々は、少しでも速くできる可能性があっても、あまり気にしないから、遅すぎなければそれでいいんだよ。技術的に可能かどうかは関係ない。実際、動きすぎるコンピュータは怪しまれるかもしれないし、結果を出すのに時間がかかるのは一種の作業証明だよ。

技術的に可能かどうかは関係ない。実際、動きすぎるコンピュータは怪しまれるかもしれないし、結果を出すのに時間がかかるのは一種の作業証明だ。最近、複雑なリクエストの後にLLMが数秒でテキストを吐き出すと、この先入観にハマってしまうことがあったよ。

人々は単に気にしていないと思うけど、それは正しくないと思う。特に一般の人にとってはね。5秒かかることが、50ミリ秒でできるはずなのに、その痛みは微妙で、無視されたり、気づかれなかったりするんだ。100個のことを連続でやっているときに、5秒かかる代わりに50ミリ秒でできることがあるって知らなければ、その痛みについて文句を言うべきだとも思わないよね。

LLMは、効果的に使い方を学べばとてもクールで強力なツールだよ。でも、ほとんどの人はそうじゃなくて、リソースやトークンを最大限に使いながら満足のいかない結果を出す使い方をしていると思う。その原因は、大きなモデルを持っている会社が実際にはトークン販売ビジネスをしていて、自社のモデルを万能の問題解決者や生活改善者としてマーケティングしているからだよ。

1980年代後半に8MBのRAMで何ができたか見てみてよ: https://infinitemac.org/1989/NeXTStep%201.0 上のリンクをクリックすれば、ブラウザでNeXTStepを実行できるよ。数週間前にはFrameMakerも動かせたんだ。1980年代後半のFrameMakerには驚かされたよ。今のMicrosoft Wordは、1980年代後半のFrameMakerには全然敵わない! 編集: FrameMakerの起動方法はこうだよ: FinderでNextDeveloper > Demos > FrameMaker.appに行って、デモ文書を開いてデモ文書のページを見てみて。驚く準備をしておいて。1989年には64MBのRAMでそれができたの??この37年間で業界は後退してるよ。Microsoft Wordは、ここ数十年競争がないせいで停滞してる。

これが今撮ったFrameMakerのスクリーンショットだよ: https://imgur.com/a/CG8kZk8 1980年代後半に可能だった素晴らしいページレイアウトを見てみて。今のWordはこれができる?

Hacker Newsで議論の続きを見る