「過去を記憶できない者は、それを繰り返す運命にある」。正直あまり好きではない言葉だが、AIをめぐるソフトウェア・プロジェクトの再実装について今起きていることは、この考えがいかに限界を抱えているかを示している。多くの人が、既存のプロジェクトをAIで書き直すことの公正さに抗議している。だが、そうした人々のかなりの部分は、90年代にはすでにこの業界にいた。彼らはリチャード・ストールマンの偉業の最終章（80年代に始まったもの）をリアルタイムで追っていたのだ。彼とその同志たちがGNUプロジェクトのためにUNIXのユーザーランドを再実装していた時代である。今AIによる書き直しに反対しているのと同じ人々が、当時はGNUプロジェクトの活動を喝采していた（私見では正しく――私自身も喝采していた）。

ストールマンは単なるプログラミングの天才ではない。分野を横断する広い視野を持つ人物であり、とりわけ著作権の機微にも精通していた。彼は他のプログラマーたちに、UNIXのユーザーランドを特定のやり方で再実装するよう求めた。オリジナルと比べて、一つひとつのツールをユニークで、ひと目で区別できるものにするやり方だ。より高速に、あるいはより多機能に、あるいはスクリプト可能に。そうした特質は、二つの異なる目的に資するものだった。GNU Hurdをより良いものにすることと、同時に訴訟に対する防御層を築くことである。もし誰かが、GNUの実装はアイデアや振る舞いの模倣（これは合法だ）にとどまらず、「保護される表現」（すなわちソースコードそのまま）をコピーしたのだと主張してきても、追加された機能や意図的に特定の設計方向へ推し進めたことが、裁判官にも理解できる反論材料となる。

彼はまた、実際の実装は見ないようにし、仕様書や、ツールを実際に動かして手作業で確かめた挙動だけを頼りに、その振る舞いそのものを再実装するよう求めた。とはいえ、GNUプロジェクトに携わった人々の多くが、UNIXのソースコードに触れたり、アクセスできる環境にあったと推測するのは妥当だろう。

リーナスがUNIXを再実装してLinuxカーネルを書いたとき、状況はもう少し複雑で、間接層が一つ増えていた。彼はUNIXにはあくまでユーザとして触れていただけで、UNIXのソースコードにはアクセスしていなかったようだ。一方で、彼はMinixのソースコード（マイクロカーネルを用いたUNIXの実装）や、その実装を解説した書籍には徹底的に触れていた。ところが今度は、タネンバウムがMinixを書いたとき、彼自身がUNIXのソースコードに徹底的に触れた上でそうしていたのだ。だからこそ、SCOは（IBM訴訟の際に）Linuxに保護される表現が含まれていると主張するのに苦労した。とはいえ、リーナスがMinixから着想を得たとき、彼はUNIXのコードを知ることで作られたもの（Minix）に精通していただけでなく、（より興味深いことに）Minixのライセンスは制限的で、オープンソースになったのは2000年になってからだった。それでも、このような状況下ですら、タネンバウムが抗議したのは（有名な論争で）アーキテクチャについてであって、著作権侵害についてではなかった。したがって、タネンバウムは、リーナスがMinixに触れていたとしても（そして彼自身もMinixを書く際に同様のプロセスをたどっていたとしても）、書き直しはフェアだと考えていたと合理的に推測できる。

著作権法が本当に言っていること

このすべてを正しい文脈に置くため、著作権の実際の射程にズームインしてみよう。法律が禁じているのは「保護される表現」のコピーである。ソフトウェアの場合、保護される表現とは、同じ構造、変数、関数、特定の処理を実現する正確なメカニズムを備えた、そのままのコードを指す。ただし、既知のアルゴリズムは例外だ（標準的なクイックソートや二分探索は非常によく似た形で実装されても違反にはならない）。問題になるのは、プログラムのビジネスロジックが元の実装とほぼ一行単位で完全に一致する場合だ。そうでなければ、そのコピーは合法であり、元のライセンスに従う必要はない。コードが似たことをしていても、切り貼りされたものでも、機械的に別言語へ翻訳されたものでも、見た目だけ少し違うように体裁を整えられたものでもないことが十分に明らかであればいい（いいか、これはまさに裁判所が見抜こうとする悪意あるごまかしの典型だ）。この記事を読んでいる有能なプログラマーなら誰でも、再実装とは何か、それがどう見えるかを完璧に理解しているはずだ。不可避な類似点は出てくるが、コードがコピーでないことは明らかに分かる。もしこれが法的な前提なら、なぜ人々はクリーンルーム実装にこだわるのか？ 実のところ、それは訴訟になった場合の最適化にすぎない。法廷で勝ちやすくはなるが、あるプログラムのオリジナルのソースコードに触れていたとしても、その接触がアイデアや振る舞いについての知識を得るためにだけ使われたのであれば問題ないのだ。そもそも、私たちは今日LinuxやGNUのユーザーランド、そして同様の道をたどった多くのオープンソースプロジェクトが存在することを喜んでいる。ルールは、その結果に賛成するときも、そうでないときも、同様に適用されなければならないと私は考えている。

AIの登場

つまり、再実装はいつだって可能だった。今変わったのは、それが圧倒的に速く、安くできるようになったという事実だ。以前は、開発者を雇うか、ビジネス上の野心からか、あるいは世界に向けて共有したいという思いから、自分自身で再実装を作り上げるほどの熱意と情熱を持っている必要があった。

今では、コーディングエージェントを立ち上げ、二つのやり方で進めることができる。一つは、実装を仕様に変換し、別の新しいセッションでエージェントに再実装させる方法だ。その際に特定の性質を強制することもできる。たとえば、より速くとか、実装を極めて追いやすく理解しやすいものにするとか（これは他の実装から大きく離れたものに仕上げるうまい手口だ。なにしろ、多くのコードは正反対の目的で設計されているように見えるのだから）、よりモジュール化するとか、元の実装が抱える根本的な制約を解消するとか。そうした指示はすべて、元の設計から大きく逸脱することをはるかに容易にする。LLMをこのように使っても、過去に見たもののコピーを生成することはない。それでも最後に、エージェントを使って違反がないか慎重に検証し、もしあればその箇所を新しいコードに置き換えることができる。

もう一つ、一見すると厳密さには欠けるが、現実世界では非常に有効になりうるアプローチは、ソースコードそのものを渡し、エージェントにまったく新しいやり方で再実装させる方法だ。ソースコードを仕様としても使いつつ、同時に実装を元のコードからできる限り遠ざけるために利用するのである。フロンティアLLMは非常に有能で、何かを利用してあえてコピーを避けることさえでき、異なる実装アプローチを慎重に試すことができる。

もし上記のようなことを試したことがあれば、「非圧縮のコピー」がいかに幻想であるか分かるはずだ。エージェントはソフトウェアを非常に「有機的」なやり方で書いていく。間違いを犯し、後になって初めて明らかになる制約のために設計を何度も変え、小さなものから始めて徐々に機能を追加していく。そして、このすでに混沌としたプロセスの中で、私たちはプロンプトやヒント、要望によってその作業を大きく方向づける。多くの考えは、慰めになると同時に偽りでもある。「非圧縮のコピー」もその一つだ。とはいえ、今や書き直しのプロセスはあまりにも簡単にできてしまい、多くの人がそれに動揺している。ここにはもっと根本的な真実がある。ソフトウェアの本質が変わったのだ。異なるライセンスの下での再実装は、その本質が永遠に変容したことの一例にすぎない。自動プログラミングの現れの一つひとつと戦うのではなく、新しいメンタルモデルを築き、適応する方が良いと私は考えている。

法を超えて

組織化された社会は法が守られてこそ繁栄すると私は信じているが、だからといって存在するからという理由だけで盲目的にルールを受け入れることはせず、自分の倫理に基づいて物事を問い直す。そうすることこそが、個人や社会、そして法自体の進化を可能にするのだ。私たちは自問しなければならない。著作権法は倫理的に正しいのか？ AIが既存のプロセスにもたらす高速化は、そのプロセス自体を根本的に変えてしまうのか？

ソフトウェアが他の多くの人間の分野よりもはるかに速く進化できた理由の一つは、この分野が特許や保護にあまり縛られていないという事実だ（そしてそれ自体、ソフトウェアをめぐる共有の文化があったからこそだろう）。もし著作権法がより厳格だったら、私たちは今日あるものを手にできなかった可能性が高い。個人や企業の利益保護は、人類文化全体の進化よりも重要なのだろうか？ 私はそうは思わない。しかも、著作権法は共通の競技場だ。ルールは誰にとっても同じである。さらに、比較的緩やかなアプローチにもかかわらず、ソフトウェアが依然として最も稼ぎやすい分野の一つであり続けていると言っても大げさではない。再実装が可能であることがビジネス面に悪影響を与えたようには見えない。おそらく逆が真実だ。オープンソースのソフトウェアスタックによってどれだけ多くのビジネスが可能になったかを考えてみてほしい（OSSの大部分がコピーでできているというわけではないが、過去のシステムから多くのアイデアを確実に受け継いでいる）。AIが登場しても、そうした根本的な緊張関係はすべて依然として有効だと私は考えている。再実装は安く作れるようになったが、これが私たち全員にとっての新しい競技場であり、アイデアやエンジニアリング、機能の面で何か新しいものを加えることなく、ただ自動的に物事を再実装するだけでは、長期的にはささやかな価値しか持たないだろう。重要になるのは、何かをどう作るかという具体的なやり方だ。よく設計されているか、使うのが面白いか、サポートされているか、ある程度の新規性があるか、速いか、文書化され役に立つか？ さらに今回は、力の不均衡が正しい方向に傾いている。大企業はこれまで常に、途方もない金額を投じてシステムをコピーし、ユーザーにとって抗いがたい形で（たとえば何年も無料で提供し、後でモデルを切り替えるとか）提供し、自分たちが実際には発明しなかったアイデアの主導者として位置づけることができた。今や、少人数のグループが大企業のソフトウェアシステムに対して同じことができる。多くの人にとって合成的な労働力が安くなった今、アイデアで競争できるのだ。

私たちは巨人の肩の上に立っている

私たち全員が内面化すべき、もう一つの根本的な考えがある。ソフトウェアは、漸進的で継続的なプロセスとして作られ、進化していくものであり、一つひとつの新しいイノベーションは、誰かが私たちの前に発明したものの上に築かれている。私たちは何かを作るとすぐにそれを「所有」していると思い込みがちだが、それは自分が書いた正確なコードに限れば正しい。しかし私たちは、すでになされた仕事やアイデアの上に物を築いているのであり、現在のITの発展が、アイデアや振る舞いは著作権の対象にならないという根本的なパラダイムによるものである以上、再実装がフェアなプロセスであることを受け入れる必要がある。そこに何の新規性もなければ、怠惰な努力だと言えるかもしれない。確かにその可能性はある。しかし、それはフェアであり、誰も何かを侵害しているわけではないのだ。それでも、エコシステムの良き一員でありたいなら、何かを複製する際には、同時にそれを進化させ、何か新しいものを発明するよう努めるべきだ。より少ないメモリフットプリントに特化させるとか、特定の文脈でより有用にするとか、よりバグを少なくするとか――ストールマン流のやり方である。

AIに関して、私たちはほぼ集団的に、ある技術がソフトウェアや人類にとって単独で善か悪かを判断するという誤りを犯している。AIはオープンソースソフトウェアの分野で多くの良いことを解き放つ可能性がある。多くの情熱的な個人がオープンソースを書くのは、日々の仕事が嫌いで、自分が愛するものを作りたいからだったり、経済的利益を超えたより大きな何かの一部になりたいからだったりする。オープンソースソフトウェアの多くは、自由時間に書かれているか、プロジェクトに割り当てられる人数に厳しい制約がある中で書かれているか、あるいはさらに悪いことに、開発費を出している企業によって課された制限的な条件の下で書かれている。コードが日々アイデアよりも重要でなくなりつつある今、オープンソースはAIによって大きく加速されうる。週末に確保した4時間が、適切な人の手にかかれば10倍の成果をもたらすだろう（優れたコーディングや設計が誰にでもできるわけではないのと同じく、AIコーディングも誰にでもできるわけではない）。たとえば、Linuxのデバイスドライバは、プロプライエタリなバイナリを自動的に逆アセンブルすることで実装できるかもしれない。あるいは、かろうじて維持されているだけのライブラリが、より現実的な時間で十分に手の行き届くプロジェクトへと変わるかもしれない。

AI以前、私たちはソフトウェアのコモディティ化を目撃してきた。品質は低下し、金だけにしか目が向かず、ミニマリズムやリソースへの敬意などまったく顧みられない。あるのはほとんど壊れたブロートの山だけだ。ハードウェアの性能が上がればブロートも増え、配慮は減る。すでに事態はかなり悪化していた。AIがそれをさらに悪化させるのは自明でも自動的でもない。そして、他のソフトウェアシステムを再実装する能力は、私たちの分野にいくらかの関心と健全さを取り戻すかもしれない、より大きな絵の一部なのだ。