作るソフトウェアにもっと野心を持てばいい

今年に入ってから、pgrustの Michael Malis が、自分がやった面白いことをいろいろ見せてくれて、こう言っている。

ソフトウェアを作るときは、もっと野心的であるべきだ¹

pgrust のようなプロジェクトに懐疑的な声が多いのも無理はない。低品質な AI 生成プロジェクトが世に溢れているからだ。Malis を知らず、中身も見ていなければ、pgrust もまた、絶対に動かない vibeslop の一つだと決めつけていただろう。しかし私は Malis をよく知っているので、中身を見なくても彼の仕事は信頼できる。少し調べれば分かることだが、pgrust のテストはかなり徹底していて、Postgres 本体の本物のバグまで見つかっている。たとえば正しい SP-GiST 操作が失敗しうる数値バグ、JSONPath が誤った結果を返しうるフォーマットキャッシュのバグ、後続の操作が失敗しうる pgcrypto のバグ、辞書ローダーにおける複数のメモリ安全性バグ²、money のオーバーフローバグなどだ。

だからといって pgrust にバグがないわけではない³が、相当な量のテストが行われていることは確かだ。pgrust 自体が成功しなくても、挑戦しただけで Postgres は着実に良くなる。pgrust の主な売りは実は性能で、本当に面白い仕事はそこにある。pgrust が失敗しても、彼らが示した最適化の一部が Postgres や Clickhouse などに取り込まれる可能性はある。ただし、見つけた Postgres のバグが修正されるのに比べれば、明らかに遠回りだ。

とはいえ、ニュースアグリゲータで pgrust が話題になるたび、ほとんどの人が vibeslop のゴミだと切り捨てるのは理解できる。こうした書き直しプロジェクトのほとんどはスロップだからだ。Malis を知らなければ私も同じ判断をしただろう。すべてのプロジェクトを調べる時間など誰にもない。Malis を知っていたから、私は中身を見る手間を省いて彼を信じた（上のバグを見つけたのは、この記事の例として使う前に pgrust の様子を確認しようと思ったからにすぎない）。

ソフトウェアを使う側から見ると、どこを見ても作者が高速だと主張している遅いソフトウェアばかりだ。作者はろくでもないベンチマークをありがたがって見せている。たとえば昨日見かけた複数の例のひとつがこれで、動かない低品質なソフトウェアはもちろん、かつてないほどよく見かける。

だが、ソフトウェアを作る側からすれば、そうしたプロジェクトのほとんどが vibeslop であることや、他の連中が大量のクソを山ほど積み上げて金だと称していることは関係ない。pgrust のようなもの、あるいは以前なら実現が難しすぎた他のプロジェクトを作れる。テストとベンチマークをきちんとやれば、実際に使える程度の品質にはなる。

自分が書くなら「作るソフトウェアはもっと野心的でいい」とは言うが、「べきだ」とは言わない。ただ、Malis がこれを言うときはいつも気軽に雑談している最中だったので、実際の投稿でも同じことを言うかもしれない。ここでの should と can の違いを深読みしないでほしい。興味深いのは、能力がここまで進歩して、ずっと多くのことができるようになったという点だ。

ひとつの例を挙げると、OpenAI が SOTA モデルに Cerebras を使うつもりだと聞いたときのことだ。5.3-Codex-Spark のような高速だが低品質なモデルではなく、という話だった。そこで、SOTA モデルを 10 倍から 100 倍速く使ったら自分のマシンの時間はどこに消えるかを考えてみた。すでにときどきボトルネックになっていて、モデルが速くなれば悪化するだけのものはこうだった。

1. Ripgrep
2. Rust のコンパイル
3. システムコールとファイルシステムのオーバーヘッド

「自分なら動く」レベルのプロジェクトでも、これらはすべて本気で改善できる。今はまとまった時間がほとんどないが、それでも気になるワークロードなら何であれ他の汎用正規表現ライブラリより速くなるよう調整できる正規表現エンジンと、その正規表現エンジンのネイティブコードコンパイラを使い、自分の codex の ripgrep ワークロードで速い ripgrep のフォーク（もちろんテキストインデックスのほうが優れた解だ。だがテキストインデックスにはすでに取り組んだことがあるし、これは最適なことを目指さない「遊び」のプロジェクトだった）、それに自分のプロジェクトのビルドを速くする Rust を作った（コールドビルドでは大幅、ウォームではそこそこ。Rust コンパイラのフロントエンドのフォークを避けたいという制約がある）。システムコールとファイルシステムのオーバーヘッドについては、開発環境を Mac から Linux に移すだけで大きく改善した。もちろんこれも大幅に速くできる話で、エージェントが小さなファイルシステム操作を大量に叩くときは特にそうだ（標準の OS ファイルシステムインターフェースは現代のディスク性能を想定して設計されていないので、マシンがファイルシステム操作を待っているのは珍しくない）。現代のディスクなら、*nix のファイルシステム API を使う理由はない。直接 I/O を使って通常のファイルシステム操作を置き換える開発ツールチェーンを書くのは、以前なら無茶な話だった。今なら完全に現実的だ。

正規表現も文字列マッチングアルゴリズムもコンパイラもインタプリタも知らない私のような人間なら、この一連のプロジェクトは「自分用には動く」品質に達するまでに 1 年以上かかっていたはずだ。実際には一桁時間の数時間で済んだ。どれかを「使える製品やオープンソースプロジェクト」の水準まで引き上げようと思えば、はるかに手間がかかる。それでも、この工程がこれだけ短縮されるのはかなりのものだ。

Malis が「作るソフトウェアにもっと野心的であるべきだ」と言うときの意図は、今では簡単にできるこうしたことを、人はそもそも思いつきもしない、ということだと私は読んでいる。何週間ものあいだ、Twitter にログインするたびに、Rust のコンパイルが遅くて開発速度を制限している、という愚痴を見かけた（私が見た時点では、これは実際には正しくなかったと思う。5.6 Sol と 6 Astra が Cerebras で使えるようになる前の話で、時間が実際にどこで消費されているかを計測すれば、当時 Rust のコンパイル時間はそれほどボトルネックではなかった）。Rust のコンパイルが遅いのは確かだ。なら Rust のインタプリタを書けばいいし、コンパイル自体を高速化してもいい。こうした問題は毎日のように愚痴られているのを目にするが、今なら大した時間も労力もかけずに解決できる。私が見る限り、これらの問題が問題であり続けるのは、人が暗黙のうちにエージェント以前のコストモデルを持ち歩いているからだ。10 年前、コンパイラが遅いからといって新しいコンパイラを実装するような人間は、インディーゲームを作りたいからといって新しい 3D ゲームエンジンを書き始めるような人間、つまり何も出荷したことのないタイプの人間だった。私の知る生産性の高いプログラマの大半は、今ならこういうことを実装するのは実際に妥当なのに、いまだにこういう行為に拒否感を持っている⁴。

以前触れた別のプロジェクトに、マッチタイムコントロールで超人級の強さを持つこの Azul AIがある。GPT-5.1/5.2 を使ってこれを作ったとき、AI の知識がゼロの状態から超人級のものを作るのに約 5 時間、当時最強と思われる AI になるのに約 20 時間かかった。Board Game Arena で不正に使われていたあの AI よりも人間相手に強いところまで行ったわけだ。最近 Gabriel Cangussu が私の AI を圧倒する AI を作ったが、私の見る限り、彼がそれに費やした時間は私よりずっと短い。彼と話して分かった重要な違いの一つは、Fable 5.1 と Opus 5.5 がボードゲーム AI についてはるかに深く理解していることだ。GPT-5.1/5.2 を使っていた頃は、提案のほぼすべてが的外れで、まともな形にするにはかなり誘導する必要があった。GPT にコードベースや論文を読ませて、論文の手法を実装させようとしても失敗する。私が論文を読んで手法の名前を指定すれば、やったと言いはするものの、たいていはその手法らしく見えるだけで実際にはその手法になっていないものを出してきて、何度か修正を入れるまで直らなかった。モデルが正しいことをできる状態からそこまで遠いと、その分野のバックグラウンドがない場合は、モデルが正しくやったかを確認するのがかなり面倒になる。何をすべきかをある程度学んで、主張どおりにやったかを検証できるようにならなければならないからだ。

あのプロジェクトをやったとき、私は友人たちに、モデルが今いる状態が長く続くとは思えないと言った。近いうちに論文を読んで技術を実装できるほど優れたモデルが出てくるはずだし、流用できるコードベースや論文を選び出せるようにもなるはずだ、と。Fable 5 を少しいじった自分の経験と、Fable 5.1 と Opus 5.5 を試した Cangussu の経験からすると、それは起きたようだ。ボードゲーム AI について何も知らない私のような人間には、時間の大幅な節約になる（今は少しは知っているが、本物の AI 研究者には及ばない）⁵。

ボードゲーム AI のような特定の領域については、「だから何だ、ボードゲーム AI なんてどうでもいい」と言うこともできる。だが、この能力の向上はかなり多くの領域で当てはまると感じている。一例として、GPT-5.6 Sol に zstd を実装させ、medium と xhigh で検証・テスト手法の簡易評価をやった。記事にまとめる時間はまだないが、あの記事を公開したとき、GPT-6 Astra でも同じ評価をやり直した。6 Astra が優秀すぎて、モデルが進歩しすぎたせいで別の評価を探さなければならなかった。zstd では、6 Astra は全条件で登録済みテストを 99% 以上の確率で通す。TDD を使うような性能を大きく損なう条件でも同じだ（ちなみにコストも安く、zstd の実装に約 1 ドルしかかからない）。結局、5.6 Sol には効果的にこなせなかった IMAP RFC と、多くの異なる形式を読み書きする必要があるぶん実装の規模が大きい Pandoc を使うことにした⁶。

ちなみに、新しいモデルを使ったら全部うまくいった、ソフトウェアは解決済みだ、といった話をよく聞くが、私はまったくそうは思わない。新しいモデルが一発でこなせることは確かにかなり増えた。ほぼそのまま動く。だがそれは、モデルがまだ苦戦するような、より野心的な作業に私が取り組むようになるというだけのことだ⁷。以前より生産性が上がり、速く働けるようになったが、自分がやっていることに関しては、モデルが賢くなるほど「そのまま動く」状態から遠ざかっている。モデルが大した手助けなしに効果的に検証できる範囲と、モデルが実装できる範囲の差が広がり続けているからだ⁸。ここまで長々と、しかも下手に言い換えてきたが、要はこうだ。もっと野心的なソフトウェアを作るべきだ。

コメント・修正・議論をくれた Laurence Tratt、Yossi Kreinin、Alex Kolovsky、Michael Malis に感謝する。

最近の投稿にはこの注記を付けているが、この記事にも当てはまる。投稿の本数を増やすために、1 本を 30 分で書き上げ、ほとんど見直さないようにしている。当然、裏付けの弱い記事になる。いつもの書き方なら、記事で触れたすべてのプロジェクトについて網羅的なベンチマークを取っていたはずだ。今回は好奇心を満たす程度の簡単な比較だけをして、厳密なベンチマークなしで記事にしている。この記事には、やりたいのにやっていないことが 20 も 30 もある。

Rust インタプリタの記事すら書いていない。5 年前なら、コールドコンパイルで 50 倍、ウォーム／キャッシュ済みビルドで 2 倍の高速化を実現する Rust インタプリタ（Rust コンパイラ自体の変更まで許すなら、さらに多くのことが可能だ）を組み上げたら、それは非常に面白い話で、記事にしたかったはずだ。しかし、ほとんど推敲せず書き散らす今のモードでは、これは記事にするほど面白くない。少し前なら非常に面白いとされたようなことが、あまりにも簡単にできてしまうからだ。

付録：作るソフトウェアの野心はもっと低くていい

Yossi Kreinin のコメントを（もちろん許可を得て）引用する：

これを公開するなら、回答を公開する。ほとんどの人は、AI で作るソフトウェアへの野心をもっと低くしないと、悲惨な失敗を経験することになる、という内容だ。問題の多くは「エージェントループ」に向いているとは言いにくい。合否の基準が明確でないからだ。基準があっても、ほとんどの人は巨大なブラックボックスをうまく扱えない。制約は課せても、中身は理解できない［この集合には自分も含まれる］。マイクロサービスに少し似ていると思う。必要としていて、しかも使いこなせる人もいるが、ほとんどの人にとっては必要性は低く、まともに使いこなせない。もちろん、これだけの野心を持つべきで、実際に持てる人たちを少し羨ましく思う。野心を持つなとは_まったく_言わないが、その野心を加減することが、今の状況に対処する上で大部分を占めると思う。「ソフトウェアが遅い理由はない」についても同じことを思う。多くの場合、AI で何かの処理を高速化すると、ごちゃごちゃしたコードが増える。それはテストしたユースケースに過剰適合していて、性能面で本来気にすべきあらゆるユースケースに一般化しないし、今後の変更にも耐えられない。何をしているか分かっていて、システムをどう分割すべきか、どの部分あるいは部分の組み合わせに最適化を全力で投じるのが妥当か、どうベンチマークを取るのが正しいか、といったことが分かっているなら話は別だ。だがたとえば、「ソフトウェアが遅い理由はない」と思っているマネージャーがいて、AI を使ってソフトウェアのあちこちを高速化しろと人に押し付けてくるなら……逃げろ。

全体として、ここでの状況はAI が生産性を 100 倍、1000 倍にすると語られることについて、私がなぜ好まないかを論じたやり取りと少し似ていると感じている。1000000 倍を軽く超えるような、非常に大きな倍率で高速化されるものもある。逆に、現時点ではまったく高速化されないものもある。5 年前とまったく同じやり方を AI でやるだけなら、アムダールの法則のせいで高速化はたいしたことにならない。ただ、一般には何を高速化するかを選べるし、生産的なことを探すとき、それは多くの場合、以前はコストが高すぎて手が出なかったことに思える。

それに、大半の人はやらないだろうが、ある種の自己検査性を備えた仕組みを組めることはよくある。Guards of Atlantis 2 の実装に関するこの議論がその例だ。AI プロジェクトとしては最悪の選択である。公式ルールが曖昧で矛盾だらけの英文の寄せ集めだからだ（おそらく、人間が最も高い頻度で誤プレイしているゲームで、ルールは混乱を招くほどで、デザイナー自身が自分のルールの意味を何度も変えているにもかかわらず、ルールは完全に明快で、書かれているとおりに読めば遊べると言い続けている）。素朴なやり方で動くルール一式を作ろうとしても、AI はほとんど役に立たない（きれいな仕様があれば実装を速めることはできる）。だがこの件では、ゲームルールの矛盾した説明どうしのあいだに、お粗末ながら整合性チェックの仕組みを組むことができ、かなり正確なルール一式に近づいた（別の人がずっと多くの人手と、より非系統的なアプローチでやったのと同程度には近い）。それで十分、他人の実装と比較して動くルール一式を得られた。このやり方は、より手作業の多いアプローチよりトークン代がかなりかかった。それでも「わずか」月 200 ドルの OpenAI サブスクリプションで GPT-5.1/5.2 を使った 1〜2 か月分であり、私が腰を据えてゲームのきれいな仕様、つまり実際に整合していて正しいルールのコピーを書くのにかかる時間的コストより安い。

多くの問題はこの種のクラスに属している気がする。少なくとも部分的に自己検証できる仕組みを用意しておけば、人間が少しの時間をかけるだけで済む。これはソフトウェアテスト全般の状況にも似ている。(コーディングエージェントが登場する前から)ファジングとプロパティベーステストは非常に効果的だと感じていた。ほとんどの領域で、この種のテストはうまくいかないという理由を何かしら聞かされたが、そう言われた領域すべてで実際に試してみると、どれも問題なく機能した。適用には少し手間がかかるものの、使えないわけではなく、自分の知る限りでは従来のユニットテストを書くより効率的で効果的だ。

Yossi のコメントの趣旨のひとつは、誰もこういうことをやっていない、という点にある。以前よりずっと多くのバグを目にするようになった今、たとえば先日、大手 AI ラボの Web チャットを開いたら、1 分足らずで二桁個のバグに遭遇したことを考えると、Yossi が間違っているとは言いにくい。とはいえ、この点についても最初の意見は変わらない。他の人がろくに動かない粗悪品を大量に量産しているからといって、自分も同じことをする必要はない。

付録:「ランダム」な例をいくつか

本文で挙げた、自分がやったことの例は、本来なら決してやらなかったようなツール類だ。こうした例は他にもたくさんある。自分専用の「自分では動く」程度のツールを作るのはあまりに簡単だからだ。生産的と言える範囲を超えて突き進むことも可能だとは思う。たとえば、Steve Yegge は Gas Town について、どれほど生産的だったかを大量に書いていたが、次のエージェントフレームワークを作る段階になると、Gas Town でうまく作れたのは Gas Town 以外に何もなかったと述べている。Ralph Loops もしばらく流行ったが、自分が比較してみたときには、当時やっていた素朴な方法（通常のループにコンテキストを組み合わせ、1 ターンが終わったという完全に恣意的なタイミングで機械的にクリアするのではなく、適宜コンテキストをクリアする）より劣っているように見えた。そんなわけで、影響がかなり直接的なものに留めるようにしている。これが効果的だった明白な理由に加えて、モデルとハーネスの能力が時間とともに劇的に変化するため、どんなツールを作るのが妥当かはすぐに変わってしまう。特定のツールに時間を大量に費やしても、せいぜい最適とは言えず、3 か月後には時代遅れになっている可能性も十分にある。それでは意味がない。

私が個人的に使っているツールの多くは、AI ラボがすぐに陳腐化させるという前提で作っている。かなりくだらない例を挙げると、GPT-5.6 Sol のリリース以降ずっと役に立っているツールがあって、これはメモリリークを見つけると codex を再起動する。OpenAI がいずれこれを修正すれば、このツールは無価値になる。もう少しマシな例なら、エージェントに作らせた Rust インタプリタだ。トークン予算の都合で、高性能なインタプリタなら本来やるべきことの多くが手つかずになっている。

たとえば、このインタプリタは Rust のフロントエンドコンパイラ自体には手を入れていない。更新を追いかけやすくするためだ。Rust のフロントエンドに変更を加えれば性能はずっと良くなるが、Rust コンパイラの互換フォークを保守するトークン予算がない。ただ、OpenAI にとっては問題にならないはずだ。OpenAI は Cerebras へのアクセス権を得るために 100 億ドル以上を費やし、同時に Anthropic にはアクセスさせないようにしている。

面白いことに、コーディングでは多くのタスクで、実際に彼らの SOTA モデルを使って Anthropic のものと比べても、Rust のコンパイルなどに時間を取られるせいで、実測の高速化はそれほど大きくない。100 億ドル以上を投じる気だったことを考えれば、AI ラボの外では現実的に誰もできないほど関連ツールの高速化をうまくやるようになるのは道理だ。だからこれにあまり労力をかける意味はない（短期的にコーディング以外のタスクが OpenAI の将来の売上を完全に支配すると見込むなら、これは的外れかもしれない。それでも、彼らがトークンに払う額と私が払う額を比べれば、私がラボの外でできることなのだから、彼らがこうしたものを高速化するのは筋が通るように思える。彼らの利用データにアクセスできれば、もっと重要なボトルネックが山ほどあってこれを優先する意味はない、といった反論はあるかもしれない。それでも、Cerebras を使ったコーディングエージェントの上位 100 のボトルネックに入らないとしても、どこかの時点で彼らにとって筋の通ることのように思える）。

「野心的」とは言えないかもしれないが、何が可能かを示すものとして、自分で作ったゲームがある。作りたいと思いながらも、実際に作ったところで一般のプレイヤーが楽しめるとは思えない、それでも自分が遊んでみたいゲームだ。たとえば、90 年代に David Gerrold のStar Wolfシリーズを読んで以来、本に書かれているような戦闘、いわば潜水艦戦のような戦闘を実装したゲームを遊びたいと思ってきた。少なくともリアルなウォーゲームの中では、このジャンルは極めてニッチだ。海戦を面白いと思う人はほとんどおらず、潜水艦戦は海戦ゲームの中でも特に退屈なサブジャンルなので、儲かるゲームとして成立する代物ではない。だがゲームの実装はあまりに簡単なので、エージェントに作らせて 1〜2 時間遊んだ。1〜2 時間遊ぶためだけに 10〜20 時間かけてゲームを実装することは決してなかっただろうが、5 分なら払う。ScoutやGuards of Atlantis 2と同じルールのゲームを実装したことについても以前触れた。仲間と直接集まれないときに遊ぶ手段が欲しいからといって、これらのゲームを手作業で実装する時間を取ることは決してなかったが、LLM にざっと書き出させるのは構わない。もちろん、もっと多くの人に遊んでもらえるゲームを作りたい人にとっても、コーディングエージェントのおかげで今ゲームのルネサンスが起きている。プログラミングスキルとそれを活かす時間がゲーム制作のボトルネックでなくなった今、面白く独創的なゲームがこれほど多く作られているのは驚くべきことだ。

データ分析も生産性の倍率が非常に高くなり得る分野で、これまでなら決してやらなかったさまざまなことができる。最近の投稿でも何度か書いたが、こうしたプロジェクトは多すぎて、1 本 30 分で書き上げるような勢いで書いても、とても記事にしきれない。

社内の使い捨てツールについて聞いて回ると、面白い事例がたくさん出てくる。たとえば、1〜2 か月前に Peter Geoghegan が話していたのがこれだ:

Fable に頼んで、自分の細かい好みどおりにコードを整形する Neovim の Lua 関数を書いてもらった。自分でメンテしたくないものであり、本質的に Rube Goldberg 的な仕掛けでもある。理屈の上では clang-format にパッチを当てれば同じ結果を筋の通った方法で得られるのだが、要件が細かすぎて、そのやり方では満足いくものにはならないと思う。我々は pgindent というツールを使っている。bsd_indent のフォークだ。clang-format でも同じ整形ルールに近いことはできるが、それでは足りない。pgindent どおりに整形・インデントされていないコードをコミットすると CI が落ちて、すぐ直せと言われる。できれば避けたい。実際のところ、clang-format 風の小気味よい整形を手に入れつつ、インデントのずれを指摘するメールも来ないようにするには、アーキテクチャが完全にぐちゃぐちゃになる。筋の通ったやり方を開発する時間もかけたくないが、それはまた別の話だ。この関数のおかげで、Neovim からコードのブロックを clang-format の LSP 連携と同じ感覚で楽に整形できる。もちろん unreasonable なまでに細かいことをやっているのは承知しているが、LLM のおかげでツールにここまでこだわれるようになった。この関数は複数パスで動く。最初に clang-format/clangd で整形し、そのあと別のパスで pgindent にかける。両方必要なのは、pgindent が取りこぼすケースの一部を clang-format が正しく処理するからだ。厄介なのは、ブロックビジュアルモードで選択した行の範囲内だけを整形したい点にある（自分のパッチで追加していないコードに clang-format をかけたくない）。これは pgindent の設計と衝突する。pgindent は C ファイル全体しか整形できない。一時的に作ったファイル全体のバッファのうち、どの部分を自分の作業バッファに戻すべきかを見極めるのは簡単ではない。最初に選択した行範囲は、影響を受ける C の AST 要素にそのまま対応するわけではない。そこでこの関数は tree-sitter を使って、インデント済みの一時的な C コードのうち、戻すべき部分を正確に切り出す。選択範囲が同じコードブロックにまたがるケースでは、ルールをちょうどいい具合に曖昧にする必要がある。エッジケースは山ほどある。さらに厄介なのは、pgindent が型を識別するために objdump で生成した typedef ファイルに依存していることだ。このファイルがないと整形結果がおかしくなる。整形関数はそのファイル用に clangd から追加の typedef を動的に生成するので、typedef ファイルが古くなる心配はない（整形ツールを走らせる数秒前に新しい struct を作ったかもしれないし、そのたびに postgres バイナリ全体に対して objdump を走らせるのは遅延が跳ね上がるので避けたい）。どうやら完璧に動いている。レイテンシもまったく問題ない。ただ、仕組みは漠然としか理解していない。Lua すら書けない。それでも、bsd_indent のフォークに変更が入って整形のされ方が多少変わることは時々あるが、おそらく動き続けるだろう。saaspocalypse には懐疑的だ。ただ、LLM が書いている有用なソフトウェアの中には、他の方法では採算がまったく合わなかったであろうものが大量にあるとは思う。

退屈すぎて人間には向かない保守作業。それでも生み出す価値は大きい。そんなソフトウェアが、興味深い小さな一群として存在する。

Malis とはこの記事を書いている途中でもやり取りしていて、彼がやっているいろいろ面白い話を聞いた。詳しく書き起こせばそれだけで一本の記事になるくらいだが、面白かったのは、pgrust の検証について最後に話したとき、コードの一部を検証するのに Kani を使っていると聞いたことだ。その後彼は Lean に乗り換え、Kani では複雑すぎて扱えないものを Lean で検証している。これも別記事の話題になるが、なぜ LLM に駆動された証明で（たとえば ACL2 ではなく）Lean が広く定着したのかは気になる。定理証明器の比較を更新したら Lean はどう見えるのか、あるいはこの言語評価に相当する定理証明器の評価を誰かがやったらどうなるのか、と考えてしまう。

もちろん、AI ラボの例はいくらでも挙げられる。たとえば中規模のチームがAnthropic で 5 か月の間に GitHub の内部代替やその他のツールを構築した例がある。

7 人のチームが Scion と Antique（私たちのコードレビューツールで、これだけで別のブログ記事が軽く一本書ける）を作ったうえ、関連するシステムも半ダースほど構築し、5 か月で完全に移行した。

こうした例は面白いし、そう遠くない未来に業界がどこへ向かうかを示している。ただ、無制限のトークンで何ができるかは、無制限のトークンで作られた他のインフラやツールに依存した話であって、無制限の資金がない今日何が達成できるかはあまり語ってくれない。pgrust のようなプロジェクトや、知り合いが余暇にやっているプロジェクト（おそらく 1%くらいしか触れていない。とにかく数が多い。David Turner が作った「自分では動いている」品質のポッドキャスト用スキッパーは、彼が見つけられたどのツールよりよく動くし、Dennis Snell がここで挙げている余暇プロジェクトなどもある）のほうが、今日何ができるかをよく表している。

Footnotes

1. この記事では「野心的」を、私にとってしっくりくる一貫した意味で使うが、多義的だと指摘する人もいるかもしれない。ここでは一般的な意味で、以前より多くを成し遂げることを指している。以前なら合理的に実現できなかった規模のプロジェクトを作ることと、以前でもできたけれど時間をかける価値がなかった超専門的なツールを作ることには違いがある、と言えるだろう。かなり異なるものではあるが、どちらも同じこと（ソフトウェアを作るのがずっと容易になったこと）から生じていると私は考えているので、この多義的とも言える定義には特に抵抗がない。 ↩

2. Alex Kolovsky は、これはバグとして扱われていないと指摘した。セキュリティの観点からの主張は理解できるし、Postgres についてこの点を判断できるだけの文脈を自分は持っていない。ただ、自分が関わってきたプロジェクトでは、こうした類の問題は潰しておくのが好みだ。コードをこの種の問題からきれいにしておけば、本物のバグはずっと見つけやすくなる。 ↩

3. Malis を信頼している理由のひとつは、彼が典型的な創業者よりもずっと慎重に発言することだ。たとえば、pgrust discord に参加して何が話されているか見に行ったとき、pgrust を本番データベースとして使えるかと尋ねる人に対して、Malis がこう答えていた（1 か月前、2026-09-17 付。エージェントコーディングの世界では永遠に等しい時間だ）。

   今日、主要な本番データベースとして使うことはおすすめしない。現在ある企業の本番デプロイを進めているが、その企業は多くの人より本番データベースの停止に寛容だ。彼らが運用を始めれば、pgrust がどれだけ信頼できるかについて良い実証データが得られるはずだ。

   Malis は、明らかにまったく本番向きではない段階で本番 ready だと主張するような人には見えない。著名なプロジェクトの多くはそうしてきたが、彼は違う。この記事の下書きは公開の 1 週間前に書いたもので、公開する時間がなかった。その後、pgrust の Clickhouse ベンチマークをめぐる騒動があった。調べてみると、不正なカンニングをしたという非難はどうやら事実ではない。pgrust のプレビューをベンチマークに提出するのは時期尚早だったという指摘については、Malis 自身も認めている。ただ、こういう話はプロジェクトにつきまとって離れない類のものだと思う。真実がどうであれ、何年も後に持ち出される。今回の騒動をめぐる議論でもそれは起きているし、Ed Zitron の予測の的中率を調べたときも、Kurzweil のような未来予測者を取り上げたときもそうだったが、実際に何が起きたかを確認する人はほとんどいない。雰囲気で語られた誤った主張は、いつまでも繰り返される。なぜ私が Malis を信頼しているのか、その根拠をすべて示すのは無理だと思う（技術的には可能だが、軽く 2 万語を超える記事になる）。ただ、彼が pgrust について語る様子と、典型的なデータベース創業者が新しい DB プロジェクトを売り込む様子を比べると、私にはまるで違って見える。もちろん MongoDB のような極端な例もある。Kyle Kingsbury がデータ破損に関する人々の体験談は本当だと繰り返し示していたのに、同社は何年も正確性の問題を争っていた。もっとありふれた例を挙げよう。友人がデータベーススタートアップの初期社員として働いていた。その会社のウェブページは、とんでもない QPS を誇っていた。テストしてみると、友人はその主張が桁違いに外れていることを突き止め、ページを修正するよう提案した。創業者は反対した。いずれその性能数値に到達するのだから、主張としては正しいという理屈だった。何年も性能改善を重ねた末、会社はようやく主張を 1 桁下げた。それでも、その数値に届くのは非常に作為的で非現実的なワークロードのときに限られる。性能を売りにする製品を扱う会社にとって、残念ながらこれはよくあることだ。これに対して、Malis が性能について何を言っているかを見ようと pgrust の discord を覗くと、最新のメッセージはこうだった：

   今いちばん助かるのは、0.4-beta のバグとパフォーマンス問題を見つけてもらうことだ。新しいクエリエンジンは一部のワークロードでは非常に速いものの、別のワークロードでは性能が後退し、より複雑なクエリには対応していない。Postgres より遅いもの、エラーになるものを洗い出そうとしている。実行できるクエリの空間が膨大なので、簡単な作業ではない。0.4-beta の一般リリースまでにこれらを直したい。ぱっと思いつくのは、非常に速いクエリでの大きな性能後退だ。新しいクエリエンジンは主に大規模で OLAP 的なワークロードに合わせて最適化したためだ。今は非常に遅いクエリを直す最適化に取り組んでいる。速いクエリで新しいエンジンが前のエンジンより遅くなる根本的な理由はないはずだ。

   彼は pgrust プロジェクトを始める前から成功したスタートアップの創業者兼経営者だったが、多くの創業者が陥るあの思考法にはどうしてもなじめなかったようだ。何でも言えて、しかも自分が言ったことを信じられる、あの思考法だ。ハードルが低いと言う人もいるだろうし、私もそう思う。それでもなお珍しいことだと思うし、だからこそ私は pgrust についての彼の話を裏取りせずに信じた。実際に調べてみても、彼の主張は現実と一致しているように見えた。 ↩

4. 別の見方としては、[Thomas Ptacek によるこの整理]というのがある。

   この 1 年のテクノロジー業界は、100 年分の出来事が一度に起きたように感じられた。業界は、パーソナルコンピュータの登場以来誰も経験したことのない形で不安定になっている。AI がぶつかる限界は、1 か月もすれば崩れる。今日フロンティアモデルでやっていることは、数年後には一瞬で、しかも無料でできるようになる。

   最近の変化の速さを考えれば、ほとんどの人、プログラマーの大多数でさえ、今なにが可能なのかをよく把握していないのは理解できる。プログラマー以外の反応について言うと、Ed Zitron の予測精度に対するこのレビューに多くの人が反論していたのが興味深かった。AI の能力はこの 2 年で上がっていないと考えたからだ。私が話すほとんどの人にとって、AI が 2024 年秋から 2026 年秋にかけて進歩しなかったという考えはまったく不可解だ（プログラミングを例外と考え、他の能力を見たとしても）。ただ、検索結果の上部に出る Google の AI 要約を見ていたり、Microsoft の製品群に組み込まれた Copilot を使っていたりして、能力が向上したことに気づいていない人も大勢いる。どの規模でも、こうした情報の勾配があるようだ。ラボの外で、今日もっとも生産性の高い人たちがモデルで何をしているかをよく知っている人はごくわずかだ。 ↩

5. オンラインでの不正行為が増えるというこのコメントは現実になった。自分が書いた実際のコメントを読み返すと、不正行為が大幅に増えるのは避けられないように思われるとは明示的に書いていなかった。ただ、そこにある記述をつなげ合わせればそう推測できるし、いくつかの Discord などで公の場で発言した記録も残っている。オンラインゲームの界隈は追っていないが、聞いた話では、Azul（モダンボードゲーム向け最大のオンラインプラットフォームである BGA で最も人気のゲーム）では、前シーズンのトップ 10 のうち 3 枠を不正行為者が占め、1 位も含まれていたという。また、以前に別の場所でも書いたが、BGA はほとんどどのレベルにおいても妥当な方針判断ができる体制には見えない。Elo ランキングアルゴリズムの仕組み、ゲームシーズンの構造、談合に対抗する方針、不正行為に対抗する方針などは、素朴に考えつく最も単純な解決策よりも劣っている。だから予想どおり、不正行為に対抗する妥当な方針を持ち合わせていない。最も人気のゲームの上位は不正行為者に占拠されており、これが他のゲームにも広がると考えるのが自然だ。AI による害としてはかなり軽微な部類に入る。ただ、先週見た、作るソフトウェアの野心を膨らませている人々の例が二桁に上るうちの一つにすぎない。これを挙げるのは、一つには簡単に数値化できるからであり、もう一つには、こうなると予測していたので、その後どうなったかを追うのは筋が通っているからだ。 ↩

6. Pandoc は入力フォーマットとして{html, docx, xlsx, pptx, csv, markdown, gfm, commonmark, commonmark_x, markdown_strict, markdown_mmd, markdown_phpextra, markdown_github, rtf, epub, odt, tsv, latex, ipynb, mediawiki, rst, asciidoc, bibtex, biblatex, org, typst, jira, docbook, endnotexml, ris, opml, dokuwiki, textile, man, mdoc, jats, csljson, fb2, pod, vimwiki, djot, creole, tikiwiki, twiki, t2t, haddock, muse, json, xml, native}を、出力フォーマットとして{pdf, html, html4, docx, plain, pptx, markdown, gfm, commonmark, commonmark_x, markdown_strict, markdown_mmd, markdown_phpextra, markdown_github, rtf, epub, epub2, odt, latex, ipynb, mediawiki, rst, asciidoc, asciidoc_legacy, bibtex, biblatex, org, typst, bbcode, bbcode_phpbb, bbcode_steam, bbcode_xenforo, bbcode_fluxbb, bbcode_hubzilla, jira, docbook, docbook4, revealjs, beamer, opml, dokuwiki, textile, man, texinfo, context, jats, jats_publishing, jats_articleauthoring, tei, icml, opendocument, csljson, fb2, ansi, chunkedhtml, djot, xwiki, zimwiki, vimdoc, haddock, markua, muse, ms, slidy, s5, dzslides, slideous, json, xml, native}をサポートしている（native は Pandoc の AST をシリアライズしたもの）。 ↩

7. ちなみに、このことから公開ベンチマークの多くは実用上ほとんど意味を持たない。私や他のプログラマがモデルに期待するのは、人間の誘導を必要とするタスクでモデルがどれだけ優れているかであって、モデルにとって自明なタスクでどれだけ優れているかではないからだ。 ↩

8. これは未来についての主張ではない。近い将来、私が持つソフトウェアスキルのほぼすべて、あるいはすべてが無意味になるかもしれない。しかし、まだそこではない。現時点では、プログラミングスキルのレバレッジはかつてなく高いように見える。今の状況には少し滑稽なところがある。モデルが置き換えつつあるスキルを持っている人のほうが、そのスキルを持たずにモデルを使おうとする人よりはるかに成果を出せるらしいのだ。Max Bittker の指摘が気に入っている。モデルは偽造が非常に得意で、偽物と本物を見分けるのに必要な専門性の水準は、モデルが進歩するにつれて上がり続けている、というものだ。 ↩