タイムラインを眺めていると、「ジークアスか Claude Code の話題しかないんじゃないか」という評判の高さを目にし、数日前から自腹で Claude Code の Max プランに申し込んで使ってみている。
使う前は「100ドルは高いな…」という印象だったけれど、数日間試してみた感想はむしろ「これ、安いかもしれない…」というもの。基本的にネガティブ思考の私でさえ、そう感じるほどなのだから世間の評判も当然だと思う。
何を作ってみたか
今回は Claude Code を活用して、次のプログラムが生成できるか挑戦した。
-
プログラムそのものではなく、tree-sitter 用の文法ファイルを自動生成する
-
その文法のベースにはドキュメントではなく、SQLite の文法定義ファイルを使う
入力も出力も機械的に処理できるケースであれば、要求仕様は明確だし、評価もしやすい。もしうまくいくのであれば、「Vibe Coding」による実用的なライブラリ開発がグッと現実味を帯びるはずだ。既存の tree-sitter-sql はサポート範囲が狭く、実用には物足りないという課題もある。
実際、SQL 文法はデータベースのバージョンアップに伴って変化するし、多種多様で一貫性がない。人間が都度メンテナンスしていくのは現実的ではなく、むしろ、こうした作業こそ AI に任せるべきだろう。
で、実際に作ってみたのがこれ。
git clone した後に npm run web-ui を実行するとブラウザ上で動作を試すこともできる（これ自体は tree-sitter-wasm の組み込み機能）。
なかなかに驚愕の出来じゃないですか。ちなみに、これを作るにあたりコーディングはまったくせず、やったのはおおむね次のようなディレクションのみ。
- SQLiteの文法定義ファイルとのすべての相違点を洗い出してレビューして
- テストを実行して修正して
実際、使う前と使った後でLLM支援型プログラミング（いわゆる Vibe Coding）に対する認識はかなり変わった。もしかすると、非プログラマから見たら「そうかプログラマ/プログラミングが不要になるのか」と思われるのかもしれないが、実際に使ってみると「プログラミングという概念が変わった」という方が感覚に近い。
作ってみてわかったこと
まず誤解を受けそうなので言っておくと、ディレクションを1回しただけで現在のリポジトリが出来上がったわけではない。指示内容は概ね決定論的な内容で正解はひとつとはないものの明確であるから、1回で処理できても良さそうなものだが、毎回いくつかのトピックのみがTODOとして提示され解決されていくので、少しずつしか進まない。最終的に SQLite文法が完全にカバーされるには数時間程度かけて十数回は同じ指示を出さなければならなかった。
また、「実施しました！」と自信満々に回答してくるものの、２番目の「テストを実行して修正して」と確認するとあちこち自動テストに失敗し長い修正の旅が始まってしまう（まぁ、これはディレクション自体に修正したら必ずテストすること、という文言を入れればよいのかもしない）。
感覚としては「やればできるが抜けが多い若手」に指示を出し続ける感じに近い。相手がLLMだからできる話で人間相手なら完全にパワハラ。
今までも GitHub Copilot などあったが「知識豊富だが的外れ」な感じがあり、指示をしてもまったく答えにたどり着かなかったのが、最新の Claude Code では抜けはあるものの確実に進捗するというのが大きい。
指示文にコーディング的な要素はまったくないが、どこまでやればOKなのかはプログラマにゆだねられているわけで、設計者としての能力はむしろ今まで以上に問われている。
「プログラマ不要」という人が明らかに見落としているのは、単にディレクションとは言ってもそこには専門的な知識が必要だということだ。各DBでのSQL構文の違い、構文解析という概念、tree-sitter というライブラリの存在をそもそも知らない人には的確な指示ができない。そして、そういった大枠のアーキテクチャの設計方針は人間が決めるしかない。
そしてもうひとつ、今回は１から開発したから良いものの、既存のプログラムの修正となるとだいぶ話は変わってくるはずだ。既存で動いている機能のどの仕様を維持してどの仕様は壊していいのか、LLMには必ずしも決められない。いちいち人間側に承認しろと依頼してくるだろう。自分が開発に関わっていないシステムのコード・レビューがいかに難しいか。
一方で、LLMの生成物を下敷き扱いに格下げすれば、これほどに優秀な下敷きはないとも言える。LLMが作ったサンプルを横目に人間が開発すれば、生産性がはるかに向上するのは明らかだろう。そういう意味で、プログラマ不要の時代というよりは、少数のプログラマが今まで以上に多くの仕事を抱えることになりそうではある。
[2025/06/06 追記]
Oracle や MySQL で良く知られている文法のうち矛盾のないものは扱えるようにして、と Claude に依頼して以降、テストに失敗し試行錯誤する時間が明らかに長くなっていたのだけど、大文字キーワードにしか対応できないという問題に気付き、修正を依頼したあたりから本格的に雲行きが怪しくなってきた。
まず、どんなに指示しても最初に発見したキーワード数カ所にしか対応してくれない。いわゆる横展開ができない。変更箇所は多かったが一括置換できる内容だったため、直接修正した。
さらに別の問題が原因となってエラーが発生しているのに、直前の IgnoreCase 対応のコードが原因と勘違いして元に戻そうとする。それは違うよ、と訂正しても他の方法が思いつかないのか同じ修正を繰り返すことしかできない。結局、こちらで調べて reserved に一部のキーワードを移動させることにした。
人間でも同じような人はいるような気がするけれど、一度壁にぶち当たるとにっちもさっちもいかなくなってしまう。プログラマが完全に不要になるまでの道のりはまだ遠そうである。
