ソフトウェア開発における「野心」の再考：AI 時代のパフォーマンスと品質

はじめに

Michael Malis（pgrust の開発者）から今年初以来、興味深い成果物を見せていただき、「我々が構築するソフトウェアに対し、より野心を持つのべきだ'というメッセージをいただいております。 低品質な AI 生成物が溢れている現状では、pgrust に対する懐疑論が多く見られます。しかし、Malis 氏の人物には信頼があり、実際の調査においては極めて徹底的な検証が行われていることが確認できました。

• Postgres に実在する深刻なバグの発見:
  • 有効な SP-GiST 操作を失敗に陥らせる数値計算の誤り
  • JSONPath から誤った結果を生じさせる形式キャッシュのバグ
  • 後続の操作を失敗に導くpgcrypto のバグ
  • 辞書ローダー内の複数のメモリ安全性に関するバグ
  • 通貨超過（money overflow）のバグ

これらは pgrust が「バグフリー」であるという保証ではありませんが、大規模かつ堅牢な検証活動が行われていることを示しています。この挑戦自体が Postgres を永続的に改良することに繋がっています。

「雰囲気だけで適当に作った（vibeslop）」プロジェクトの現実

pgrust の主要な売りは**「パフォーマンス」**であり、ここにおいて最も興味深い進展が生じています。 しかし、リファクトリング・プロジェクトの多くは「vibe-slop（雰囲気だけで適当に作ったもの）」であるとされがちです。

• 信頼の源泉: Malis 氏のような開発者を知らなければ、同様の仮説を立てていたかもしれませんが、彼らの実力を信じることで詳細な検証を省略できました。
• 間接的だが価値のある貢献: pgrust が不成功に終わっても、実証された最適化手法が Postgres や ClickHouse などのシステムに取り込まれる可能性があります。
• 「べきだ」vs「できる」: 「もっと野心を持って構築すべきだ（should）」と、「技術的に可能か（can）」の違いに固執する必要はありません。技術的キャパシティの進歩こそが重要です。

具体的なスピードアップ事例

OpenAI が最先端モデル（SOTA）を採用したことで、処理速度が 10 倍〜100 倍になり、以下の要素が新たなボトルネックとなりました：

- Ripgrep の実行
- Rust コンパイル
- システムコールおよびファイルシステムのオーバーヘッド

「私の環境で動く（Works for Me）」プロジェクトの加速

以前なら不可能だった規模感を持つものや、任意のワークロードでの高速化が現実的になりました。

• 正規表現エンジン: 他の汎用ライブラリよりも高速なエンジンを実装。Codex ワークロードでも大幅な高速化を実現。
• Rust ツール開発: ビルド時間の短縮（特に冷起動で劇的、温起動でも改善）。
• 環境移行による改善: Mac から Linux へ移行し、システムコールオーバーヘッドを削減。

驚くべき事実: これらを実現するために私がかかったのは単桁の十数時間のみでした（以前は 1 年以上かかっただろうと推測）。 「有用な製品」としての質を高めるにはさらに時間がかかりますが、プロセス自体が劇的に加速しています。

Azul AI と大規模モデルによる実装の進化

Azul AI の事例

将棋やボードゲームにおいて実力者並みの性能を持つ「Azul AI」を開発しました。

• GPT-5.1/5.2 を使用した時:
  • 約 5 時間でゼロからの知識状態で超人的な性能を引っぱり出せるレベルに到達。
  • 当時の最も強力な AI（人間を上回るボードゲームアリーナ用 AI）に達するには約 20 時間必要でした。
• Gabriel Cangussu 氏のプロジェクト:
  • 私よりも遥かに短い時間で同様の AI を構築。
  • Fable 5.1 と Opus 5.5 は、ボードゲーム AI に比べてはるかに深い理解を持つことが判明。

モデルの能力向上と課題

以前の GPT-5.1/5.2 では提案がほぼ間違いで、多大な介入が必要でしたが、最新のモデルではコードベースや論文から技術を適切に実装できるようになりました。

• GPT-6 Astra の検証:
  • 99% 以上の確率でテストケースをパス（TDD の使用など困難な条件も含む）。
  • 実装コストは約 $1 と非常に低コスト。
• IMAP RFC や Pandoc の実装: これらの難しい形式の処理にも成功しています。

「すべてが機能する」という誤解について

新しいモデルを使えば「ソフトウェアの問題は解決した」わけではありません。

• 多くのことがワンショットで成立し、自動動作しますが、より野心のある課題へと移行しているだけです。
• モデルが無手先なし（significant handholding）で検証できる範囲と、実装可能な範囲のギャップが増大しています。
• これこそが、「我々が構築するソフトウェアに対し、より野心を持つのべきだ」というメッセージに通じます。

補遺：より野心を控えるべきだとする意見への反論

Yossi Kreinin 氏は、AI を使ったソフトウェア構築には「野心を控えよ」と警告しました。

「明確な合格/不合格の基準がない…ブラックボックスについて推論に困難を感じるため…」

しかし、大局的には以下のように考えます。

• 加速の可能性: AI は特定のフローを 1,000 倍〜1,000,000 倍加速させることがあります。アムダールの法則が働く場合もありますが、何を選択するかで生産性は劇的に変わります。
• 自己検証メカニズムの導入: 「Guards of Atlantis 2」などのルール曖昧なゲームにおいて、人間が短時間で部分的に自己検証可能なシステムを設定できます（ファッジングと性質ベーステスト）。
• ランダムな最適化は避けるべき: 「ソフトウェアが遅い理由はない」と考え、AI でランダムな部分を高速化しようとするのは危険です。

具体的な「Works for Me」プロジェクトの例

生産的限界を超えて進むことは可能ですが、陳腐化するツールには時間をかけないことが重要です。

• ゲーム開発:
  • 『Star Wolf』シリーズのような戦闘を実装するゲームを数時間で作成。潜水艦戦などニッチなジャンルでもエージェントに任せることで実現可能。
  • Scout や『Guards of Atlantis 2』のルールセットを持つゲームも実装済み。
• データ分析: 生産性倍増により、以前は不可能だった多くのことを達成可能。

Neovim カスタマイズの事例（Peter Geoghegan 氏の記述より）

Fable

を使用して

clang-format

と同様の挙動を実現しつつ、独自の要件を満たしています。

• 機能概要: Neovim から指定されたコードブロックを容易にフォーマット（clang-format パスと pgindent パスの両方を実行）。
• 仕組み: tree-sitter を使って正確な部分集合を区切っており、レイテンシは問題なし。
• 結論: LLM がツールに対して厳格になれることに価値があり、複雑なアーキテクチャ的混乱を避けた解決策が得られています。

結論と展望

LLM は他の方法では不可能なほど非経済的に開発しなければならない多くの有用なソフトウェアを記述しています。 Anthropic の中等規模チームが 5 ヶ月で GitHub の内部代替品を開発した事例は興味深いですが、無制限のトークンを使用した場合のみです。

• 今日の達成可能性を示すのは: pgrust のようなプロジェクトや、人々が余暇で行っているプロジェクト（約 1% を占めるものの一部）の方です。
  • David Turner 氏の「Skipper」など既存のものよりも優れている余暇プロジェクトも多数存在します。
• 今後の疑問: 定理証明器として Lean が ACL2 より選定される理由や、LLM 駆動の検証における Lean の役割について、さらに調査が必要です。

要約: 低品質な生成物が溢れていても、開発者の野心と適切な検証があれば、技術的能力は大きく進歩しており、以前以上に多くのことを成し遂げられます。