AI で書き直した Postgres「pgrust」の信頼性をどう見極めるか

AI で Postgres を Rust に書き直した pgrust は、テストの過程で Postgres 本体のバグを見つけたと報告されています。その一方で、分析のベンチマーク ClickBench からは「cheating」として外されました。この 2 つの出来事を並べて、AI で作られたソフトをどこで見極めればよいかを考えます。情報は 2026 年 10 月 25 日時点のものです。

この記事の要点

• pgrust は Postgres 18.3 を AI で Rust に書き直したもので、回帰テスト 46,066 件すべてに通ると作者は主張しています。ただ README 自身が「not production ready」としています。
• Dan Luu によると、テストは Postgres へのバグ報告 5 件につながりました（1 件は Postgres 側でバグと見なされず、残りも受理は未確認）。一方 ClickBench では、43 本のクエリ専用の経路と結果のキャッシュを理由に削除されました。答え自体は正しく、問題とされたのは「何を測っていたか」です。
• AI で作られたソフトは、既存のテストに通るかより、元の実装との突き合わせや、入力を少し変えたときの動きで見るのがよいと私は考えています。

pgrust とは

pgrust は Michael Malis 氏が進めている、Postgres 18.3 を Rust で書き直すプロジェクトです。2026 年 4 月のブログによると、作者はコードのほとんどを自分では読まず、ガードレールと可視性で開発を管理していて、始めて 2 週間で 25 万行に達しました。6 月 25 日のブログでは、回帰テストにすべて通ったと発表しています。

README と docs には、ClickBench で ClickHouse より 18.5% 速いという強い主張も載っています（docs では v0.2 の結果）。一方で README は、バグが多いと認めています。既存の拡張は動かず、ライセンスは AGPL-3.0 です。

2 つの出来事を図にしました。

Postgres へのバグ報告につながったテスト

Dan Luu は 2026 年 10 月の記事で、pgrust のテストが Postgres 本体へのバグ報告 5 件につながったことを、信頼の根拠に挙げています。答え合わせの途中で、模範解答のほうの誤りを指摘したようなものなんです。認められたかは次の表のとおりです。

報告の内容	扱い
SP-GiST の数値のバグ	受理されたかは未確認
JSONPath のフォーマットキャッシュのバグ	受理されたかは未確認
pgcrypto のバグ	受理されたかは未確認
辞書ローダーのメモリ安全性のバグ	Postgres 側ではバグと見なされていない（Dan Luu の脚注）
money 型のオーバーフロー	受理されたかは未確認

README にも、関数 1000 個を Kani という形式検証のツールで調べ、Postgres との差異 12 件のうち 4 件は Postgres 側のバグだったとあります。これが Dan Luu の 5 件と重なるかは、どちらにも書かれていません。

ただ、これはテストの網が細かい証拠で、pgrust 自身が正しいことの証明ではありません。README も「テストスイートに通ったからコードが正しいとは限らない」と書いています。

ClickBench から削除された理由

ClickBench は、43 本の分析クエリの速さを比べるベンチマークです。PR #2165 は、2 つのルール違反で pgrust を削除しました。結果のキャッシュは無効にする決まりなのに効いていたことと、クエリに合わせた調整は無しと申告しながら、43 本専用の経路があったことです。

PR の指摘を試験に例えると、出題される 43 問の解き方だけを覚え、一度解いた問題は前の答案を写していた状態です。PR の作者が停止してキャッシュを捨ててから測り直すと、2 回目から急に速くなりました。

クエリ	1 回目	2 回目	3 回目
Q20	10.8 s	11 ms	5 ms
Q17	1.65 s	4 ms	15 ms
Q33	2.38 s	213 ms	108 ms

PR の作者は、2 回目からの速さは結果のキャッシュによるもので、メモリに載った状態での実際の速さは数百 ms、同じ機材の ClickHouse と同じくらいだとしています。また列指向のテーブルでクエリを少し変えると、一部が「not served」のエラーで拒否されました。近いクエリ 67 件のうち 20 件が通らず、SELECT MIN(URL) FROM hits; のような素直なクエリも含まれていたそうです。式や関数を少し変えた類題を出すと、3 割ほどは解けなかったわけです。

ただし、43 本の答え自体は ClickHouse と照合して正しかったと、同じ PR に書かれています。PR の結論は、測っていたのはデータベースではなく「答えを引くための表」だった、というものでした。

AI で作られたソフトを見極める観点

Dan Luu は、悪意ある不正という非難は誤りに見えるとしつつ、プレビュー版をベンチマークに出したのは早すぎたと Malis 氏が認めた、と書いています。PR と Dan Luu のどちらも、キャッシュと専用の経路があったこと自体は否定していません。分かれているのは、それを不正と見るか準備不足と見るかです。

片方の出来事だけを見ると、本物だとも slop（AI で量産された低品質なもの）だとも言えてしまいます。ほかの AI 製ソフトで私が確かめたい観点は、次のとおりです。

観点	pgrust の場合
作者は本番での利用をどう見ているか	「not production ready」と明記
元の実装と結果を突き合わせているか	Kani などで差異を探している（自己申告）
入力を少し変えても動くか	列指向テーブルでは、変えたクエリの一部がエラー（PR の測定）
設定の開示が版をまたいで続いているか	キャッシュの設定の記述が消えたと PR が指摘
「正しいか」と「何を測ったか」を分けているか	答えは正しいが、測っていたのは答えの表だと PR が指摘

3 つめは、PR の作者がやったことそのものです。合否の基準がはっきりしたベンチマークでも、基準を満たすだけの実装が出てくれば、基準の外から確かめないと気付けないんですよね。

使いどころと注意点

2026 年 10 月時点の pgrust は、本番のデータベースというより、AI で大きなソフトを書き直すとどこまでできるかを知る教材として見るのがよさそうです。インストールの要らない WASM 版のデモが https://pgrust.com にあり、Docker でも動かせます（amd64 と arm64）。

docker run -d --name pgrust -e POSTGRES_PASSWORD=secret -p 5432:5432 malisper/pgrust:v0.2
psql -h localhost -p 5432 -U postgres

この手順は v0.2 のもので、PR #2165 が調べた v0.4-preview とは版が違います。試すなら捨ててよいデータで、自分のクエリを流してみるところから始めるのが安全です。

ここまでの評価の多くは特定の人の見立てで、Dan Luu は Malis 氏を個人的に知っていることも根拠にしています。PR の測定も PR の作者によるもので、pgrust 側の反論は読めていません。「ClickHouse より 18.5% 速い」という数字も、ClickBench の上ではもう確かめられないので、人に紹介するときは引かないほうがよいと思います。

もっと知りたい人へ

Dan Luu の記事のほかの論点

Dan Luu の記事の中心は、AI 製の書き換えの大半が slop でも作り手には関係がなく、テストとベンチマークをきちんとやれば、以前は大きすぎたソフトも使える品質で作れる、という主張です。モデルが賢くなるほど、モデルが検証できる範囲と実装できる範囲の差が開き、いちばん難しいのは検証だ、とも書いています。本人は記事を短時間で書いたこと、ベンチマークが厳密ではないことを注記しています。末尾には、合否基準のない課題は AI が試行と修正を繰り返す進め方に向かないとする、Yossi Kreinin の反論も載っています。

PR #2165 が示した細かい証拠

バイナリには q00.rs のようなクエリごとのソースのパスが埋め込まれ、ベンチマークの SQL はコンパイル時に include_str! で取り込まれていたそうです。v0.3 の clickbench.ron は「43 クエリ全部の手書き物理プラン」と説明され、一部のクエリはスキャンせず統計から答える MetadataAnswer でした。Q20 は定数を変えても 1 回目 283 ms、2 回目 4 ms で、再起動しても 1 回目 11.2 s、2 回目 3 ms でした。キャッシュの設定をオフにしても、LIKE を使うクエリの再実行は 3〜4 ms で返ったとしています。測定は 96 コアの Graviton で、エントリ自身のスクリプトと設定を使っています。

版の食い違いと削除の日付

PR が調べたのは v0.4-preview のバイナリで、そのバイナリ自身は pgrust 0.3-beta と名乗っていたそうです。README と docs は v0.2 の内容です。削除の日付は PR の本文に無く、Zenn の記事は 9 月 22 日としていますが、私は確かめていません。

作者の本番での見立てと Mac での動かし方

Dan Luu が記事で引用した 9 月 17 日の Discord での発言によると、Malis 氏は本番の主データベースとしては今は勧めないとしつつ、障害への耐性が高いある企業向けに本番導入を準備しているそうです。Apple Silicon の Mac には単体のバイナリもあります。自前の initdb と psql を持たないので、先に Homebrew で PostgreSQL 18 を入れてから、README の手順（v0.2 のもの）で起動します。README には Windows 向けの記載が見当たらず、日本語の照合順序やロケールへの対応も書かれていません。