ハクソク

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

ソフトウェアが遅くなる理由はもうない

2026年8月22日原文(danluu.com)

概要

  • LLMやAI技術により、かつて専門家しかできなかった最適化作業が誰でも手軽に可能に
  • 最適化コストの劇的な低下により、以前は割に合わなかった小規模な最適化も実施しやすく
  • ワークロード特化型の動的カスタムソフトウェアが主流になる兆し
  • 実験的な最適化や複雑なソフトウェア構築も、短時間かつ低コストで実現可能
  • AIによる最適化がもたらすリスクと新たな機会

LLMと最適化コストの劇的低下

  • LLM（大規模言語モデル） の普及で、これまで高度な専門知識が必要だった 性能最適化作業 が大幅に簡略化
  • 以前は 数人日〜数週間 かかっていた最適化も、今や 数分〜数時間 でAIに指示するだけで実現可能
  • JITコンパイラ のような高度な技術も、AIを活用すれば一般開発者でも導入できる時代
  • パフォーマンス改善 が容易になったことで、従来はコスト面で見送られていた細かな最適化も積極的に試せる環境
  • これにより、 大規模案件や収益性の高いプロジェクト だけでなく、 小規模な用途 にも最適化技術が普及

ワークロード特化型ソフトウェアの時代

  • Marc Brooker のコメントにもある通り、 特定のワークロードに最適化されたダイナミックなカスタムソフトウェア の普及が加速
  • 例として、 regexエンジンFRE の最適化実験では、AIエージェントがベンチマークに合わせて自動で最適化を繰り返し、短期間で成果を出すことが可能
  • AOTコンパイル やスレッド並列処理など、本来は手間のかかる技術もAI活用で短時間実装
  • 実験的な最適化 も、AIに任せて簡単に試行錯誤できるため、従来よりも多くのパターンを検証可能
  • BitFunnel のような検索インデックスやJIT複数実装も、今や週末プロジェクト感覚で構築可能

最適化の実践例とインパクト

  • Azul AI の開発事例では、LLMの支援により世界最強クラスのAIを短期間・低コストで構築
    • マルチスレッド化や複数アーキテクチャ対応もAIエージェントが自動で実装
    • デバッグやリプレイ機能の追加も、AIループで迅速に対応
  • パフォーマンスエンジニア の手動作業では数日〜数週間かかる作業も、AIで数十分〜数時間に短縮
  • パフォーマンス面接課題 でも、AIが人間エンジニアを上回る最適化を短時間で実現
  • 最適化の試行コスト が激減したことで、成功するか不明な実験的手法も気軽に試せるように変化

ワークロード特化最適化の必然性

  • Marc Brooker や Michael Malis （pgrust開発者）が指摘するように、今後は 用途特化型ソフトウェア が主流になる流れ
  • AIによる自動最適化が進むことで、従来の「汎用ソフトウェア」から「ニーズごとに最適化された動的ソフトウェア」へのシフトが進行
  • これにより、 パフォーマンスの最適化 と メンテナンス性・リスク の新しいバランスが求められる時代へ

まとめ AIとLLMの進化により、最適化作業のコストと難易度が劇的に低下。これまで専門家だけが可能だった高度な最適化が、誰でも短時間で実現可能となり、ワークロード特化型のソフトウェアが今後の主流となる見通し。試行錯誤や実験的な最適化も容易になり、ソフトウェア開発のパラダイムが大きく変わりつつある現状。

Hackerたちの意見

遅さの一番の原因の一つは、ウェブリクエストを待つことなんだよね。多くのソフトウェアがオンラインだったり、同じスタックで作られているから、使っている間ずっとブロックされたり待機状態になっちゃう。アメリカ以外にいる人は、特にこれを感じるよね。オンラインの多くがアメリカにホスティングされてるから、ちょっとしたやり取りでも300msかかると、すぐに積もっちゃう。もしあなたのソフトウェアがUIコントロールに待機ダイアログやローディングホイールを持っているなら、それはデフォルトでブロックされる前提で作ってるってこと。ウェブベースのものを作っているとしても、それが本当に必要なのか、違う方法で作って常にUIがブロックされないようにできるのか、自問自答してみて。

└

この二つの制約を同時に満たすソフトウェアを作るのはそんなに難しくないよ。* すごく反応が良く感じること * ネットワークリクエストがエンドツーエンドで最大500msかかること

└

MLを使って、どこをクリックするか予測して、重要な状態を変えないボタンが予測された時にページを事前にキャッシュすることはできないの？それとも、難しいMLを飛ばして、頻繁にクリックされるボタンを事前にキャッシュするための基本的なルールを使って、マルコフ連鎖を利用するのはどう？

└

新しいノートパソコンを買ったんだけど、RTX 5090搭載なんだ。GLコンテキストを開くのに半秒以上かかる。最適化できることがたくさんあって、ウェブからはかなり離れてる。

└

エージェントと一緒に動く必要があるソフトウェアで、インターネットなしでも動くものを試してるんだ（アクセスが限られた建設プロジェクトを扱ってるからね）。インターネットがダウンするとエージェントのアクセスはなくなるけど、状態は維持できるんだ…CRDTと仮想ファイルシステムを使ってるよ。おもちゃみたいなハーネスのバージョンがあるから、興味があったらフィードバックもらえると嬉しいな。https://ourhearth.ai

└

自分の経験では、レイテンシの主な原因はping時間ではなく、サーバーがリクエストを処理するのにかかる時間なんだ。

これを要約すると： > プログラムの空間Sにおける実行可能な最適化目的を持つ確率的探索プロセスは、目的を維持または改善できるだけだ。 これはスーパ最適化だね。80年代から知られてることだよ（Massalin、STOKEはもっと最近のもの: https://github.com/StanfordPL/stoke）。唯一の新しさは、提案者が今はLM（言語モデル）でずっと良くなったってこと。さらに、エージェントによって書かれたソフトウェアが遅い理由はたくさんある。 - LMはデータやハードウェア指向の設計が得意じゃないから、もしあなたが非常によく理解されたプログラムを移植する以上の新しい作業をするなら、悪いアロケーションの決定を追跡するのに何時間もかかることになる（TigerBeetleがエージェントを使わない理由を参照）。これがしばしば根本的な問題の原因なんだ。 - 本格的なパフォーマンスを得るために必要なノブは、LMが得意な言語ではほとんど手が届かない。Rustですら、デフォルトの言語が強制しない規律が必要だよ。下のレベルに落ちると、消費コンテキストとこれらのレバーへのアクセスを交換することになる。レバーも「ソフト」だから、スキルやツールをたくさん書いて、規律を強制しようとすることになる。エージェントからパフォーマンスの良いコードを（早く）得るには、パフォーマンスの良いコードを書く方法を知っている必要があるし、そのための情報をエージェントに提供する方法も知っておく必要がある。これを知っている開発者は2026年には99%いないよ。確かに、エージェントはこれを教えてくれるかもしれないけど、いわゆる「知ってる人にはわかる」ってやつだね。経験としては、私は数百億トークンをZigに投入して、最高のエージェントと一緒にこれを試す時間と余裕がある。もし規律を学び始めたいなら、matkladのブログやTigerBeetleのブログをおすすめするよ。それに、ハードウェア指向の設計もね。

└

本格的なパフォーマンスを得るために必要なノブは、LMが得意な言語ではほとんど手が届かない。Rustですら、デフォルトの言語が強制しない規律が必要だよ。下のレベルに落ちると、消費コンテキストとこれらのレバーへのアクセスを交換することになる。レバーも「ソフト」だから、スキルやツールをたくさん書いて、規律を強制しようとすることになる。 それは全然私の経験とは違うな。最新のLLMは、アセンブリ最適化されたサブルーチンを作成して、私が夢にも思わなかった100種類のバリエーションをベンチマークするのができるよ。

└

iykyk ある話なんだけど、友達がいて、彼も俺と同じくCRDTや共同編集に興味があるんだ。彼はChatGPTにCRDTを書いてもらったんだよね。それから、良いCRDTの実装を全部集めて、ChatGPTにベンチマークと最適化を頼んだんだ。既存の手動で最適化されたCRDTからトリックやテクニックを使って。これをやったことで、すごいパフォーマンス向上があったんだよ。面白いよね！彼は明確な目的関数を持っていたから、ChatGPTも他のプロジェクトを参考にして最適化のアイデアを得られたんだと思う。彼は自慢げに、自分のコードが俺のダイヤモンドタイプライブラリを上回ったって言ってた。俺は、ネイティブ実装と比較してるのか、-OzのWebAssemblyビルドをWASM VMで動かしてるのか聞いたんだ。後者だった。ちゃんとテストしたら、彼のCRDTはダイヤモンドタイプよりもかなり遅かったんだ。俺の知る限り、ChatGPTはまだ追いついてないみたい。俺もFableを使ってみたんだけど、ソースコードを参照しても、Fableはダイヤモンドタイプで何をしたのか、なぜそうしたのかを理解できてなかった。(... もしかして、やったことをドキュメントにまとめるべきかな！) でも、彼のテクニック自体はしっかりしてると思う。俺も試してみたんだ。Fableにカスタムバイナリシリアライズ形式とパーサーを書かせて、最適化させた。さらに、既存のライブラリを明示的に参照しながら最適化したら、他のコードを参考にすることで大きな違いが出た。今ではそのライブラリとほぼ同じくらいの速さになったよ。（でも、まだそれより速くはない。）俺の結論はこれだ：LLMはコードを読むのがめちゃくちゃ得意だと思う。うまくガイドすれば、プロファイリングやベンチマークも得意。でも、新しい最適化を考えるのはあまり得意じゃないみたい。明らかに遅いプログラム（例えば、Claudeが書いたスロープ）には、ベンチマークと最適化を頼むことで大きなスピードアップが得られることが多い。でも、Zigコンパイラみたいに複雑で既に最適化されたコードベースだと、Claudeは新しい改善方法を自分で見つけるのがあまり得意じゃないみたい。これは、95%の遅いソフトウェアにとっては朗報だけど、すでに速いコードを書いている5%の俺たちにとっては悪いニュースだね。

└

プログラムの空間Sに対する実行可能な最適化目的を持つ確率的探索プロセスは、目的を維持または改善することができる。これが成り立たない理由は次の通り： (1) ベンチマークは実際の使用と一致しないことが多く、多くの最適化がベンチマークを改善しても、測定されていないケースを悪化させることがある（CPUキャッシュの挙動が驚くべきものであることを考えてみて）。 (2) ソフトウェアのパフォーマンス最適化では、多くのソースからのノイズが大きく、測定された変化が実際に改善であることを保証するのが難しい。

コンピュータを使い始めて40年になるけど、全然速くなってないよ。1989年に作った原子力発電所のコンピュータシステムは、選択した画面を1秒で表示しなきゃいけなかった。今使ってるアプリでそれができるのはないと思う。

└

すべてはインセンティブだよ。パフォーマンスを重視する人たちがいるウェブプロジェクトに関わったことがあるけど、その目標から始めればサブ秒の速度を出すのは簡単だよ。逆に、クライアントサイドに1MBのマッピングライブラリを追加して静的な地図を描画するようなプロジェクトにも関わったことがあるけど、その時は私の反対意見を無視された。そういうウェブサイトは遅かったね。

Hacker Newsで議論の続きを見る