🧵 Jacquard — 「AIが書き、人間がレビューする」前提で設計されたプログラミング言語が現れた

AIがコードを書く割合が増えるほど、人間の仕事はレビューに寄っていく。なのに、我々がレビューしている言語は全部「人間が書く」前提で設計されたものだ。この非対称、言われてみれば確かに変じゃないか。

Show HNに出てきたJacquardは、ここを正面から突いた実験だ。「AI-written, human-reviewed」——AIが書き、人間がレビューする前提のプログラミング言語。作者はJoshua Winters、OCaml(83.8%)+Cランタイム製でC言語へAOTコンパイルする。v0.1 RC・87 starsの研究プロトタイプで、作者自身が「本番言語ではない」と明言している。数字より思想を見るタイプのプロジェクトです。

「何に触れるか」をシグネチャが白状する

レビューで一番怖いのは、見た目は無害な関数の奥に隠れた副作用だ。ログ出力のふりをして外部にリクエストを飛ばす、設定読み込みのついでにファイルを書く。LLM生成コードを疑いながら読むとき、結局全行を追うはめになる。

Jacquardは副作用(effects)を関数の型シグネチャに強制表示する。

// この関数はネットワークに触る、と型が宣言している
fetch_title : (text) ->{net} text

{net} の部分がeffect row。ネットワーク・ファイル・乱数など、環境に触れる操作はすべてここに現れ、書かずに使うと型チェッカーが弾く。つまりレビュアーは、シグネチャを見るだけで「このコードが触れる範囲」を確定できる。1行ずつ読んで副作用を探す作業が、原理的に不要になる。

さらに実行時はcapabilityベースで、--allow で明示した権限のハンドラしかインストールされない。Denoの --allow-net に似ているが、プロセス単位ではなく関数の型のレベルで追跡される分だけ粒度が細かい。

テストの同一性はハッシュで決める

もうひとつ面白いのが、プログラムの同一性を構造ハッシュで扱う点だ。コメント・整形・変数名を消した正規形でハッシュを取るので、AIがリファクタと称して変数名を変えただけならテストは再実行されず、意味が変わったときだけ再検証が走る。「AIの出力が毎回微妙に違う」問題を、差分の意味論で吸収する発想だ。

algebraic effectsのハンドラは多重再開(multi-shot)に対応していて、同じコードを本物のネットワーク・偽のスクリプト・過去の記録と差し替えて走らせられる。effectをすり替えてテストする、が言語機能として最初からある。

「それはツールの仕事では?」への答え

当然の反論がある。レビューしやすさが欲しいならlinterと型チェッカーとサンドボックスを重ねればよくて、言語を新造する必要があるのか?

半分は正しいと思う。既存エコシステムを捨てるコストは巨大で、Jacquardが実用になる未来は率直に言って狭い。ただ、ツールによる検査はopt-inで、書き手(AI)が回避できる。言語仕様による強制は回避できない。「LLMの出力を信頼せず、構造で封じる」という設計原則を言語まで下ろすとどうなるかの思考実験として、これはかなり誠実な実装だ。effectsの理論自体はEffやKokaで枯れているので、奇抜な理論に賭けているわけでもない。

Jacquard(ジャカード織機)は、パンチカードで織りのパターンを機械に指示した装置——プログラミングの遠い祖先だ。人間が織り方を全部手で決めていた時代から、パターンを与えて機械に織らせる時代への転換点の名前を、AIに書かせて人間が検品する言語に付ける。この命名のセンスだけで、READMEを最後まで読む価値はあった。本番採用は当分ないとして、「レビューのために言語ができること」のリストは、ここから他の言語に輸入されていく気がする。