i2y

読まなくていいコード AI のエージェントにコードを書かせるようになってから、奇妙なことが起きている。コードを書く時間は減ったのに、コードを読む時間が増えたのだ。 これは印象の話ではない。Faros AI が 2 万 2,000 人の開発者のデータを調べた 2026 年 4 月の報告では、AI をよく使う時期には、開発者 1 人あたりのタスクの処理量が 33.7% 増えた一方で、プルリクエストがレビューにかかっている時間の中央値は 441.5% 増えた1。ハーバード大学の Chen と Stratton が 718 社を調べた論文では、コーディングエージェントを入れたあとに追加されたコードは約 30% 増えたが、解決された課題の数は統計的に意味のあるほどには増えず、プルリクエストがマージされるまでの時間は 49% 延びた2。 書く作業を機械に渡せば、全体は速くなるはずだった。なぜそうならないのか。 私の考えでは、理由は単純だ。コードを書くことには、これまで二つの仕事が含まれていた。一つはコードを作ることで、もう一つは、そのコードが何をするのかを誰かが理解することだ。人が自分でコードを書いていた頃は、二つ目の仕事は一つ目をすれば自然に済んでいた。書いた人は、書きながら理解していたからだ。 エージェントに書かせると、一つ目の仕事だけが機械に移り、二つ目の仕事は人に残る。そして、人が理解を得る方法としては、読むことしか残っていない。Joel Spolsky が 2000 年に書いたように、コードは書くより読むほうが難しい3。理解をいちばん安く得られる方法を手放し、いちばん高くつく方法だけが残ったのだから、全体が速くならないのは当然だ。 レビューの時間が延びるのは、レビューする人がそこでこの理解を作っているからだ。Alami らが 2026 年 9 月に公開した事例研究で、ある技術者は「結果を一行ずつ見なければならない。責任を負うのは自分だから」と話している4。人は、理解していないものに責任を負えない。だから、エージェントがどれだけ速く書いても、誰かがそれを読んで理解するまで、仕事は終わらない。 では、読むことはなぜこれほど高くつくのか。コードが長いからだけではない。読む人が考えている単位と、コードが書かれている単位が違うからだ。 PdM やエンジニアが業務について考えるとき、頭にあるのは業務の概念だ。運賃表、本則に優先するただし書き、負になってはいけない残高、担当者だけができる承認といったものだ。エージェントが返してくるのは、関数、条件分岐、型、例外の処理、ログで書かれたものだ。運賃表はいくつかの if 文になってほかの処理のあいだに置かれ、ただし書きが優先することは、分岐を書く順序でしか表されない。読む人は、この分岐が表のどの行にあたるのか、表の行がすべてあるのか、二つの条件が同時に成り立つときにどちらが勝つのかを、自分で組み立て直さなければならない。 セマンティックギャップ：人の考える単位と、エージェントが書くコードの単位 計算機科学では、異なる表現の体系のあいだにある意味の違いをセマンティックギャップと呼ぶ。汎用言語はどの業務にも使えるように作られているので、運賃表もただし書きも知らない。だから、汎用言語で書く限り、誰が書いてもこの違いは残る。人が書いていた頃もこの違いはあったが、書く速さが人の速さだったので、読む人も追いつけた。今の問題は、この違いが残ったまま、書く速さだけが人の読める速さを大きく超えたことだ。 実は、同じことは前にも一度起きている。 コンパイラが広まる前、プログラマは機械の命令を自分で書き、自分で読んでいた。高級言語が広まると、機械の命令はコンパイラが書くようになった。それ以来、コンパイラが出力したアセンブリを一行ずつレビューする人はほとんどいない。レビューするのはソースコードで、機械の命令ではない。 なぜそれで済むのか。理由は二つある。一つは、コンパイラが決定的だからだ。同じソースからは同じ命令が出るので、ソースを理解すれば、命令がすることも決まる。もう一つは、ソースが人の考える単位に近いからだ。プログラマは変数や関数で考えるので、変数や関数で書かれたものなら読める。理解を作る場所が、機械の命令からソースコードに移ったのだ。 ここから、エージェントが書くコードへの答えも出てくると私は思う。読む速さを上げるのではなく、読む場所をもう一段上に移せばよい。人が考える単位、つまり業務の概念の単位で書かれたものを人が読み、そこから下はコンパイラのように決定的に生成する。 この考え方自体は新しくない。Paul Graham は 1993 年に、Lisp ではプログラムを言語に合わせて書くだけでなく、言語のほうもプログラムに合わせて作っていくと書いた5。言語を問題のほうへ近づけるという考えは、プログラマのあいだでは古くからある。新しいのは、それが業務の側で、しかもコードを書かない人のために必要になったことだ。 私はこの考えにもとづいて、ritsu という言語の集まりを作っている6。9 つの言語があり、rulec は表と条件で決まる規則を、dandori は途中で止まっても続きから再開すべき手順を、chobo はお金の勘定を、sekisho は誰が何をしてよいかを書く。どの言語も、書く単位は業務の単位だ。会員が 3,900 円以上買えば送料を無料にするただし書きは、rulec ではこう書く。 clause 無料(free) -> 送料 # 出典: 第3条第2項ただし書 when 注文金額 >=3900円 and 会員 true then 0円 overrides 通常 規程を読んだ人なら、プログラムを書いたことがなくても、これが規程のどこにあたるかを指させる。ただし書きが本則に優先することは、分岐の順序ではなく overrides 通常 の一行に書かれている。 大事なのは、このファイルを書くのも人ではないことだ。書くのはエージェントで、人は規程などの資料を渡し、資料から決まらないことを聞かれたら答え、できあがった規則と、規則の中身を表と文章で説明するページを読んで承認する。説明のページも規則から生成される。エージェントが書いた規則は検査にかけられ、表の抜けや重なりがあれば、どの入力で何が起きるかを添えた診断が返る。検査を通った規則から、ritsu がコンパイラのように決定的に、12 の言語のコードとテストを生成する。 ritsu を使うとき：人が読むのは業務の単位の規則まで 読む場所を移すと、いくつかのことが同時に変わる。 いちばん大きいのは、生成されたコードを読まなくてよくなることだ。理由は、コンパイラの出力を読まないのと同じだ。規則は人が業務を考える単位で書かれていて、コードはそこから決定的に作られる。だから、人が理解して承認した規則と違うことをするコードは出てこない。人が理解していないコードが生まれないので、人はシステムがなぜその答えを返すのかを業務の言葉で説明でき、その結果に責任を負える。先の技術者が一行ずつ見なければならなかったのは責任を負うためだったが、責任を負うために必要な理解は、規則を読むことで得られる。 その結果、読む量が大きく減る。会員の無料を含む送料の規則は 36 行で、そこから生成されたのは 60 のファイル、合わせて 25,128 行だった7。無料になる金額を 3,900 円から 5,000 円に上げると、生成コードでは 29 のファイルで 266 行が変わる。rulec diff で二つの版を比べると、答えが変わるのは入力の組合せ 1,316 通りのうち 188 通りで、それが会員の 3,900 円から 4,999 円の注文に限られることがわかる。PdM が承認するのはこの内容で、コードの差分ではない。 エージェントの側でも、書いて読む量が変わる。エージェントが書くのは規則の 895 文字で、生成にはモデルのトークンを使わない。公平に言えば、Python の関数を一つ書くだけなら手で書くほうが短いだろう。差が出るのは、テストと、言語の数と、説明の文章と、直す回数を数えたときだ。それらは生成されるか、検査の診断が一度で直し方を示すので、エージェントはコードを動かしてログを読む繰り返しをしなくてよい。 生成が決定的であることも効いてくる。同じ規則から二度生成すると、60 のファイルすべてが一致した。エージェントに同じことを二度頼むと違うコードが返ってくることがあるが、規則から生成するなら、一度理解した規則のコードは毎回同じになる。人の理解が、版をまたいで持ち越される。 最後に、規則は動かす前に確かめられる。rulec の検査は、表の抜けと重なりについて入力のすべての組合せを調べる。運賃表の行を一つ消すと、青森県の 80 サイズのような当てはまらない入力の例を示して止まり、ただし書きの優先を書き忘れると、両方に当てはまる注文金額 3,900 円の会員の例を示して止まる。検査を通らない規則からは何も生成されないので、人は抜けを探す必要がなく、規則が業務として正しいかだけを考えればよい。 ここで、当然の疑問が出てくるだろう。業務のための専用の言語、いわゆる DSL は何十年も前からある。それが広く使われてこなかったのはなぜか。そして、なぜ今ならうまくいくと言えるのか。 私は、DSL の費用のほとんどは書く側にあったと思う。新しい言語を使うには、誰かがその書き方を覚えなければならない。文法を覚え、エラーの意味を覚え、道具をそろえる。チームにその言語を書ける人が一人しかいなければ、その人がいなくなったときに困る。だから多くのチームは、多少読みにくくても、誰もが書ける汎用言語を選んできた。 エージェントは、この費用をほとんどなくした。エージェントは言語の説明と例を渡されればその言語で書けるし、検査の診断を読んで直せる。ritsu の検査が診断を JSON でも返すのは、それを読むのが人ではなくエージェントだからだ。書くのが人からエージェントに変わったので、めずらしい言語を選ぶ費用が下がった。一方で、読む側の利点は前と同じように残っている。人にとって読みやすいのは、今も業務の単位で書かれたものだ。 つまり、DSL の損得の計算が変わったのだ。書く費用は下がり、読む利点は残った。それどころか、エージェントが大量に書くようになったことで、読む利点は前より大きくなった。人が書いていた頃には割に合わなかった選択が、エージェントが書くようになって割に合うようになった。 もちろん、これで全部が解決するわけではない。生成コードを読まなくてよいと言えるのは、生成器が正しいと信頼できるからだ。コンパイラの出力を読まずに済むのも、コンパイラを信頼しているからで、事情は同じだ。rulec test が、生成した各言語のコードを同じテストの組で走らせるのは、この信頼を規則ごとに確かめるためだ8。また、検査が確かめるのは規則に抜けや矛盾がないことまでで、規則が業務として正しいかどうかは確かめない。それを判断するのは、規則と説明のページを読む人だ。人が読む量は減るが、読むことそのものがなくなるわけではない。 もう一つは範囲の問題だ。今の ritsu の言語で書けるのは、規則、手順、勘定、日付、権限のような業務の一部で、規則の関数を呼ぶ画面や API のようなつなぎのコードは、今のところエージェントが汎用言語で書き、人がレビューしている。ただし、これは今の ritsu の範囲がそうだというだけだ。この記事を note に書いたあとにも、つなぎのコードのうち計算して決めるだけの部分が、九つ目の言語の kaname で書けるようになった9。画面や API も、ritsu の外にある小さな言語や、これから ritsu に加わる言語で書けるようになるかもしれない。私は、システム全体がこうした小さな言語の集まりで書かれ、人がシステムのどの部分も業務の単位で読めるようになる未来を想像している。 エージェントが書く速さは、これからも上がるだろう。人が読む速さを上げてそれに追いつこうとしても、うまくいかない。高級言語が出てきたとき、プログラマは機械の命令を速く読む方法を探したのではなく、機械の命令を読まなくてよい方法を見つけた。同じことを、もう一段上でやればよい。 人が読むべきなのは、コードではなく、コードが実現すべきものだ。それを人が理解できる単位で書き、そこから先をコンパイラに任せれば、人が理解していないコードは生まれない。そして人は、自分たちのシステムがなぜその答えを返すのかを説明でき、その説明に責任を負える。 ritsu は Homebrew で brew install i2y/tap/ritsu とすれば入れられる。入れずに、ブラウザで規則を書いて検査を試せるページもある10。 この記事は、少し前に note のマガジン「小さな言語の時代」に書いたものを、ritsu 0.35.0 で数字を取り直して転載した。 note.com 脚注 Faros AI, "The AI Engineering Report 2026: The Acceleration Whiplash"。2026 年 4 月 12 日に公開された要約の数字による。4,000 を超えるチームの 2 年分の記録をもとに、同じ組織の中で AI の利用が最も少ない時期と最も多い時期を比べている。 faros.ai ↩︎ Fiona Chen and James Stratton, "Artificial Intelligence in the Firm: Bottlenecks in Software Production"（2026 年 8 月 4 日版）。2021 年 1 月から 2026 年 3 月までの 72 万 5,938 人の作業の記録を調べている。査読をまだ経ていない job-market paper で、数字は ComplexDiscovery の紹介記事（2026 年 10 月 13 日）による。 complexdiscovery.com ↩︎ Joel Spolsky, "Things You Should Never Do, Part I"（2000 年 4 月 6 日）。原文は "It's harder to read code than to write it." joelonsoftware.com ↩︎ Adam Alami, Elda Paja, Abhishek Tiwari, "The Psychological Costs of Artificial Intelligence Adoption in Software Engineering"（arXiv、2026 年 9 月 3 日）。21 人への聞き取りにもとづく質的な研究で、発言は英語の原文から訳した。 arxiv.org ↩︎ Paul Graham, "Programming Bottom-Up"（1993 年）。原文は "In Lisp, you don't just write your program down toward the language, you also build the language up toward your program." paulgraham.com ↩︎ ritsu。 i2y/ritsu ↩︎ この記事の数字はすべて ritsu 0.35.0 で実際に走らせて数えた。生成されたファイルには、テスト、MCP サーバ、ほかのサービスから呼ぶためのコードも含まれる。送料を計算する本体だけでも、Python は 224 行、Go は 520 行ある。 ↩︎ この記事を書いた環境では、12 言語のうち処理系が入っていた 10 言語で走らせ、答えを確かめる 29 件と受け付けない入力 14 件がすべて一致した。Swift と Wasm は、その環境にたまたま処理系が入っていなかったので走らせていない。 ↩︎ kaname については note の記事「つなぎのコードは、誰が確かめるのか」に書いた。 note.com 。ドキュメントは i2y.github.io ↩︎ ritsu のプレイグラウンド。 i2y.github.io ↩︎