6月24日、PostHogが「I wrote a 70x faster SQL parser while barely looking at the code」と題した記事を公開した。AIエージェントを活用し、既存のSQLパーサを本番環境で平均454倍高速化した手法を詳述している。
「AIに任せた」ではなく「AIが間違う前提で設計した」
コードの大半はClaude Opus 4.7（Anthropicの最上位モデル）が書いた。しかし著者が強調するのは「AIにお願いして書いてもらった」話ではない。AIが頻繁に間違いを犯すことを前提に、自動検証・自動修正のループを設計したという点だ。いわゆる「バイブコーディング」（指示を出して結果を待つだけの受け身なAI活用）とは一線を画す。
成果物のスペックをまとめると：
- Rust製パーサ 16,000行（Claude Opus 4.7が生成）
- ツーリングコード 5,000行
- 本番クエリでの平均高速化率 454倍（ラップトップのマイクロベンチマークで約70倍）
- 開発期間：2026年5月
なぜPostHogにSQLパーサが必要か
PostHogは製品分析・セッションリプレイ・A/Bテストなどを統合したオープンソースのプロダクト分析プラットフォームだ。ユーザーはHogQLと呼ばれるSQL方言でデータに直接アクセスでき、入力されたSQLはClickHouse用SQLにトランスパイル（変換）される。その前段で、パーサがSQLをAST（抽象構文木）に変換する必要がある。アクセス制御やクエリ最適化はすべてこのASTに依存するため、パーサの性能と正確性は直接プロダクトの品質に影響する。
従来はANTLR（Another Tool for Language Recognition）というパーサジェネレータを利用し、C++コードを自動生成していた。ANTLRは文法を.g4ファイルで宣言的に記述するだけで動作するが、内部でATN（オートマトン理論に基づくグラフ構造）を解釈実行する仕組みのため、手書きの再帰下降パーサには原理的にスループットで負ける。
手書きパーサを書けばより速くなることはわかっていた。問題はメンテナンスコストだ。SQLの文法は広大で、エッジケースも無数にある。人間が手で書いて維持するのは現実的ではない。しかしAIがあれば話は別だ、と著者は判断した。
ループの設計が鍵だった
単純に「Rustでパーサを書け」とClaudeに指示しても機能しなかった。Claudeは頻繁にコードを誤り、自信をなくし、途中で作業を止めようとしたという。著者が解決策として組んだのは以下の自律ループだ。
① 差分の自動発見
Hypothesis（Pythonのプロパティベーステストライブラリ）を使い、新旧パーサが異なるASTを返すSQLクエリを自動探索する。既存のC++パーサ（ANTLR製）が「正解のオラクル」として機能する。
② 文法ファイルからSQLジェネレータを自動生成
ANTLRの.g4文法ファイルをパースし、文法に沿ったランダムSQLを生成するツールをClaudeとともに作成した。このツール自体もAIが生成したものだ。
③ カバレッジ誘導型テスト
コードカバレッジのフィードバックをもとに、未実行のコードパスを重点的にたたくSQLを生成する。
④ 失敗ケースの自動縮小
ShrinkRayを使い、発見した失敗クエリを最小再現ケースに自動圧縮する。
⑤ エッジケース専門のバックグラウンドエージェント
「エッジケースを徹底的に考え続けろ」という指示だけを持ったClaudeエージェントを常時走らせる。著者によればこれが「最も効果的な失敗ケース生成源の一つ」だったという。
これらを束ねた自律ループの流れはこうなる：
失敗ケースを収集 → 最小化 → 回帰テストに追加 → 文法ファイルとC++ソースを読んで修正方針を決定 → Claudeが修正を実装・要約を人間に報告 → 回帰スイートが全通過するまでループ
ひとつ重要な落とし穴として、Claudeがコンテキストウィンドウを使い切って会話が圧縮（コンパクション）された後、文法ファイルの内容を「忘れる」問題があった。対策はシンプルで、「コードを修正する直前に毎回、文法ファイルと参照C++ソースをコンテキストに読み込む」というプロンプト指示を追加することで解決した。
本番投入と結果
新パーサはまず「シャドーモード」（既存パーサと並走して差分をログに記録するだけ）で稼働させ、数百万クエリで差分がゼロであることを確認した後、数時間で本番切り替えを行った。
ベンチマーク結果は著者自身が「数字がほぼ現実に見えない」と述べるほどの改善だ。ラップトップ上のマイクロベンチマークで約70倍、本番環境の実クエリでは平均454倍という数字が出た。本番クエリはキャッシュに乗らない長大なSQLが多く、そこでANTLRのグラフ走査コストが顕著に出るため、差がより大きくなったと著者は分析している。タイトルが「70倍」を名乗るのは控えめな表現であり、実態はさらに上回る結果だった。
生成されたパーサの技術的な構成は「手書き相当の予測型再帰下降パーサ、Prattパーサによる式解析コア、LL(2)先読みカーソルと局所的な投機的バックトラッキングの組み合わせ」だ。これらは全行、Claude Opus 4.7が出力した。
パーサジェネレータの役割が変わる
著者はこの経験から、ANTLRのようなツールの役割が変わる可能性を指摘している。文法を宣言的に記述するジェネレータは「高速なパーサを生成するツール」ではなく、「LLMが正しさを検証するためのオラクルを提供するツール」として機能する、という新しい使い方だ。
PBT（プロパティベーステスト）とファジングで差分を自動発見しながらLLMが実装を修正していく、このパターンは今後「AIと人間の協業でパーサを作る標準的なアプローチ」になる可能性を持っている。「AIが書いたコードを人間がレビューする」ではなく、「テストが正しさを担保し、AIがひたすら修正を回す」という設計の転換は、パーサに限らず多くの領域に応用できるはずだ。
詳細はI wrote a 70x faster SQL parser while barely looking at the codeを参照していただきたい。
