Claude CodeがSQLite内のSPARQLエンジンを12時間で構築、依頼したWillison氏はコードを読んでいない

Simon Willison氏はスマートフォンから誤字まじりのプロンプトを1つ送っただけだった。Claude Code for webはそこから12時間以上かけて、SQLiteにクエリ言語SPARQL 1.1を追加するRust製の拡張を作り上げた。技術的には見事な成果だが、エージェントによる開発で人間の監督がどこで途切れるのかもはっきり示している。

誤字入りのプロンプト1つから11個のRustクレートが生まれた

Willison氏は10月16日、自身のブログでこの実験を紹介した。主な目的はClaude Code for webのUltracodeモードを試すことだった。このモードではClaudeがJavaScriptを生成し、多数のサブエージェントを束ねて動かす。ドキュメントではこれをdynamic workflowsと呼んでいる。依頼の内容はおおよそ「SPARQLを実装し、行を直接読むので高速に動くSQLite拡張をRustで書いて」というものだった。元のプロンプトにあった「delete」という語は、本人によれば電話での打ち間違いだという。

エージェントは12時間以上作業を続けた。その後Willison氏が送った追加のプロンプトは1つだけで、各フォルダへのREADME、チュートリアル、サンプルデータを作るスクリプトを求めた。こうして生まれたsparqliteは、11個のRustクレートと約240 kBのチュートリアルで構成される。リポジトリには、文章もコードもすべて言語モデルが書いたと明記されている。

READMEによると、sparqliteはRDFデータを通常のSQLiteテーブルに格納し、クエリを1本のSQL文に変換するのではなく独自のエンジンで評価する。オプションでB木のページをファイルから直接読み取ることもできる。ソーシャルネットワークの160万トリプルと製品データの100万トリプルを使った計測では、結果件数を数える場合、幾何平均でSQL変換方式の3.5倍、pyoxigraphの10.6倍速い。結果をすべて返す場合はそれぞれ2.8倍と6.6倍だ。

コードを読む代わりに、振る舞いを確かめるテストが担う

Willison氏自身、このコードを現実的にレビューすることはできず、ドキュメントを読み通すだけでも大きな手間になると書いている。思いつきで作り、理解に時間を割くつもりもないSPARQL実装にどれほどの価値があるのか、と自問している。

エージェントはこの問いに、手持ちの唯一の方法で答えた。レビューの代わりに証拠を示したのだ。READMEによれば、該当するW3Cテスト639件中636件に合格している（99.5 %）。残る3件の失敗は、土台にしているパーサーspargebraに起因するという。さらに1,000件を超えるRustのテスト、50件のpytestテスト、仕様をそのまま書き写した意図的に素朴な実装と約770万回比較する差分ファジングも用意された。

開発チームにとって、これは役に立つ型だ。エージェントが書いたコードでは、検証の対象が一行一行から確認可能な振る舞いへと移る。標準テストスイート、独立した参照モデル、既存ライブラリとの比較である。W3Cが既にテストスイートを公開しているSPARQLは、この種の実験に向いている。ただし、社内の業務システムの大半にはそうしたものがない。

テストもベンチマークも参照モデルも、同じエージェントが書いた

ここが弱点だ。参照実装、テストランナー、ベンチマークはいずれも同じエージェントが作った。READMEはランナーを独立した評価器と突き合わせ、ミューテーションテストでも検証したと述べるが、それもモデル自身による自己申告にすぎない。速度の数値は4 vCPUのクラウドマシン1台で測ったもので、まだ誰も再現していない。

もう一つの問題は保守だ。SQLiteの内部ファイル形式を直接読む拡張は、データベース本体の変更に左右されやすい。READMEは、リーダーが確信を持てない場合、たとえばWALモードのデータベースでは通常のカーソルに戻ることで対処するとしている。sparqliteを導入する人は、依頼した本人すら理解していないコードを引き継ぐことになる。実際、Willison氏はこれを完成したツール群ではなく、research用のリポジトリに置いている。

価値を決めるのは、実際にSPARQLを使う人たち

最初の注目点は、RDFやセマンティックウェブのコミュニティがsparqliteを試し、その計測がREADMEの数値を裏付けるかどうかだ。ベンチマークを第三者が一度再現するほうが、同じエージェントによるテストをさらに1,000件積むより重い。

次の注目点は責任の所在である。今やエージェントはデータベースエンジン一式を一晩で納品できる。問われるのは、半年後に誰かがバグを見つけたとき、そのコードに誰が名前を出して責任を負うのかだ。

Lilithの判定

Willison氏は誤字まじりのプロンプトでデータベースエンジンを注文し、翌朝には11個のクレートと約4分の1メガバイトのチュートリアル、そして動作を保証する770万回の比較結果を手にした。分厚いマニュアル付きの機械は手に入ったが、ボンネットの中身を知る整備士はどこにもいない。