テストコードが新しい堀(Moat)になる時代

Cloudflareが1週間でVite基盤のNext.js互換ランタイムを作った。どうやって? Vercelが数年かけて積み上げたNext.jsのドキュメントとテストスイートをAIに放り込んだ。

コードをコピーしたのではない。仕様(Spec)を学習したのだ。そしてその仕様はテストコードの中にあった。

成功の逆説

プロジェクトが大きくなるほど、後方互換性と巨大なコードベースという荷物を背負う。Theseusの船のように部品を入れ替えながらも名前を保たなければならない。

一方、競合はクリーンな状態から始まる。API仕様とテストだけを持ってきて核心価値だけを抽出した、より軽くてモダンなバージョンを作る。レガシー負担がゼロだ。

これがAI時代のオープンソースの根本問題だ。

SQLiteの先見性

SQLiteはコードは完全公開だ。ところがテストは非公開だ。ソースコードの590倍にあたる9,200万行のテストスイートがある。

100%分岐カバレッジ。数百万のテストケース。10億を超えるミューテーションテスト。これがSQLiteがオープンソースでありながら商業的防御力を持つ理由だ。

誰かがSQLiteをフォークしてもっと速いバージョンを作ることはできる。しかしSQLiteが30年間発見したすべてのコーナーケースの保証はできない。飛行機のブラックボックスがSQLiteを使う理由だ。

テストは仕様だ

過去にはコード自体が価値だった。どう動くか知りたければコードを読まなければならず、だからコードを隠した。

今は違う。動作がどうあるべきかを定義したテストの方が高価な資産だ。コードはAIが書き直す。テストが定義した振る舞いを満たしさえすればいい。

結局「ソフトウェア契約(Contract)」がコードより高くなった。そしてその契約を最も精密に表現する形式がテストだ。

じゃあオープンソースは終わりか

いや。ただ戦略が変わるだろう。

これから商業的オープンソース企業はこんな質問を受けることになる。コードは公開してもいい、でもテストも公開するのか?

私の予想ではSQLiteパターンが標準になりそうだ。コードは公開、テストは非公開。「うちの製品を使いたいならコードを読め。うちの製品をパクりたいならテストは自分で書け。」

ソロ開発者にも意味がある

7個のプロジェクトを同時に回すソロ開発者ならもっと切実だ。AIで初速は狂ったように速くなったが、テストなしで積み上げたコードはリファクタリング地獄になる。

機能一つ触るたびに他のところが壊れるのが怖くて手が出せない。そうしているうちに結局そのプロジェクトは死ぬ。

一方、テストがちゃんとあるプロジェクトはAIに思う存分リファクタリングさせられる。テストが通る限り、AIはコードを書き直していいという許可を得たも同然だ。

何がいいテストか

E2Eテストが核心だ。単体テストは実装に縛られていてリファクタリングすると壊れる。AIが書き直したコードを検証するには狭すぎる。

本当の資産になるのは「この入力にこの出力が出るべき」を仕様化する統合/E2Eテストだ。ユーザーシナリオ単位で書かれたテストだけが実装変更にも生き残る。

もう一つ。AIはコード生成は得意だが、意味のあるテストシナリオを書くにはまだ人間のドメイン知識が必要だ。エッジケースは人間が見つける。AIはそれをコードに移すだけだ。

結論

コードを公開しても安全だった時代は終わった。今、本当に守るべきものは動作仕様、つまりテストコードだ。

オープンソース企業ならSQLiteパターンを検討する時だ。ソロ開発者ならテストから書く習慣をつける時だ。会社ならADRとテスト資産のセキュリティ等級を再評価する時だ。

AIがコードを簡単に複製できるほど、テストの価値は上がる。