「過去を記憶しない者は、それを繰り返す運命にある」。私はこの言葉があまり好きではありませんでした。そして今、AIによって既存のソフトウェアプロジェクトが再実装されている状況は、この考え方の限界をあらわにしています。多くの人が、AIを使って既存のプロジェクトを書き直すことの公正さに抗議しています。しかし、そのような人たちの少なからぬ割合は、90年代にはすでにこの業界にいました。80年代に始まったリチャード・ストールマン（Richard Stallman）とその追随者たちによる偉業の最終章、すなわちGNUプロジェクトのためにUNIXのユーザーランドを再実装していく過程を、彼らは見てきたのです。今AIによる書き直しに反対しているのと同じ人たちが、当時はGNUプロジェクトの活動を称賛していました（私から見れば正しいことですし、私自身も称賛していました）。

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

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

Linuxカーネルを書いてUNIXを再実装したリーナス（Linus）の場合、状況はもう少し複雑で、間に一層の間接性が挟まっていました。彼はUNIXにはユーザーとして触れただけで、UNIXのソースコード自体にはアクセスしていなかったようです。一方で、Minixのソースコード（マイクロカーネルを用いたUNIXの実装です）や、その実装を解説した書籍には深く触れていました。ところが今度は、タネンバウム（Tanenbaum）が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がそれをさらに悪化させることは、自明でも自動的でもありません。そして、他のソフトウェアシステムを再実装する能力は、私たちの分野にいくらかの関心と健全さを取り戻すかもしれない、より大きな絵の一部なのです。