「小さな」オープンソースの運命

(nolanlawson.com)

4 ポイント投稿者 GN⁺ 2025-11-17 | 4件のコメント | WhatsAppで共有

JavaScriptの小規模ユーティリティライブラリは、LLMのコード生成能力によって徐々に不要になりつつある
例として blob-util は10年前の npm パッケージで、Blob処理ツール集だが、いまやAIがその場で類似コードを生成できる
こうした変化は依存関係の削減と迅速な開発を可能にする一方、学習と理解の機会の喪失をもたらす
Node.js とブラウザの組み込み機能拡張に続き、LLM が小規模ライブラリの終焉を加速させている
今後のオープンソースの価値は、創造的・大規模・専門的な領域で持続する可能性がある

小規模オープンソースの衰退とLLMの影響

10年前に作った blob-util は、JavaScript の Blob オブジェクトを文字列や ArrayBuffer に変換するシンプルなユーティリティ集で、週500万回以上ダウンロードされている
- 作者は、PouchDB のユーザーが Blob 処理に混乱しているのを見てこれを作成した
現在、開発者の約80%がAIを業務に活用しており、その結果、単純なユーティリティはLLMで代替可能になっている
- 例として Claude は、Blob を ArrayBuffer に変換する TypeScript 関数をその場で生成する
Claude の出力は blob-util と似ているが、より冗長で型検証が過剰であり、エラー処理は改善されている
作者は、この変化が依存関係の削減とコードの堅牢性向上として見えるかもしれないと述べている

学習中心のオープンソースが持つ価値の喪失

blob-util の README にはKirbyのキャラクターを使ったチュートリアルが含まれており、単なる機能提供を超えてJavaScript学習を助ける目的があった
LLM中心の開発環境では、即時の回答が理解や教育より優先されるようになり、このような学習型オープンソースの必要性は薄れている
ドキュメント自動化のための llms.txt のような試みは、ドキュメントの意味そのものを再定義することになる

オープンソースの新しい方向性

作者は今でもオープンソースを続けているが、小規模で低価値なライブラリの時代は終わったと考えている
- Node.js とブラウザの組み込み機能（node:glob, structuredClone など）の拡張ですでに減少傾向にあった
- LLM がその流れを決定的に加速させた
教育的な役割を果たしていたライブラリ（例: Underscore.js）も必要性が薄れている
- 単純な配列グループ化のような機能は、いまや標準 API で解決できる

価値が残るオープンソースの条件

LLMが簡単には生成できない大規模・創造的・専門的なプロジェクトに価値が集中する
- 例として fuite プロジェクトやメモリリーク検知の研究は、LLMが再現しにくい創造的な作業だ
今後のオープンソースの意味は、新しいアイデアと人間的な創造性にある
- 例として Dominic Gannaway が開発したRipple.jsフレームワークに言及し、人間の実験精神を強調している

結論

LLMは一部のオープンソースを時代遅れにしたが、それでも新しい形のオープンソース創作の機会は存在する
人間の開発者の創造性と実験精神が、AI時代のオープンソース生態系の持続性の中核要素として示されている

4件のコメント

savvykang 2025-11-20

left-pad のような奇妙なエコシステムの慣行さえ防げるなら、問題ないと思います

shakespeares 2025-11-19

努力に対する満足度がますます低い時代になるにつれて、小さなユーティリティは、保守にかかる手間に見合う価値がないと判断され、顧みられなくなっていくように思います。

GN⁺ 2025-11-17

Hacker Newsのコメント

最近では開発者の約80%がAIを業務に活用している
blob-util のようなユーティリティは、今や大半をLLMでその場で生成できる
ただし、このやり方は諸刃の剣でもある。検証されていないコードは保守負担を残し、エッジケースで失敗することもある
そのためJavaエコシステムでは、Apache Commonsのような信頼できる標準ユーティリティ集が定着した
- 古いユーティリティライブラリは、すでにさまざまな環境で検証されており安定している
  一方でLLM生成コードは、見た目には筋が通っていても奇妙なバグが潜んでいる可能性が高い
AIがコードやチュートリアルを大量生成することで、品質低下とスパム化が加速する時代に入った
個人ブログや小規模ライブラリを作る動機は薄れている
- 実際、Webはかなり前から低品質なチュートリアルスパムであふれていた
  LLMが作った記事も同程度なので、むしろフィルタリングしやすくなったと感じる
  自分は devcontainer の中でコードを実行して、チュートリアルに本当の価値があるかを試す。動けば見る価値があり、動かなければ捨てる
- 今日YouTubeで特定の話題を探していたら、AI生成動画ばかり延々と出てきて驚いた
- 「低品質スパムの時代が来る」という話は、すでに現実になっている
- あるWeb開発者は「これで10倍速くなったのだから、人類に悪いはずがない」と冗談を言っていた
- 別の人は冗談まじりにアセンブリコードを投げて、「これを説明できないなら本物の開発者ではない」と皮肉っていた
JSのマイクロ依存地獄は悪夢だった
いまその時代が終わりつつあり、開発者が再びコーディングを学ぶ時代に戻ってほしい
- jQueryやlodashのように、小さなユーティリティ集を1つのパッケージにまとめた形が最も良い結果を生んだ
- ただし、「もうすべて終わった」という見方には疑問もある。むしろAI生成コードの洪水でもっと悪化するかもしれない
- LLMコードが増えると、同じ機能を持つ関数が複数バージョンに分散し、バグ修正もそれぞれ個別にやることになる
- LLMを使ったからといって、人々がより学ぶようになるわけではない。問題が起きればLLMにリファクタリングを任せるだけだからだ
- 「いまやvibe coderの時代だ」と短く付け加える人もいた
「二分木を反転する問題」は本当に存在するのか、という疑問が出た
- これはHomebrew創設者がGoogleの面接で失敗した問題を指しているようだ
- おそらく著者の単純な言い間違いで、仮にやるとしても比較演算子を逆にする無意味な練習にすぎない
「小さくて価値の低いライブラリの時代は終わった」という主張に共感する声もある
Go言語にはそもそも依存性地獄がなかったので、npmの問題は文化的要因によるものだという
今はユーティリティよりも、実際に動く製品を作るほうが価値もあり楽しい
- Goの格言にあるように、「少しのコピーは少しの依存よりまし」という哲学がある (Go Proverbs)
- Goのどんな機能がこうした依存問題を防いだのか気になる、という質問も出ていた
自分はマイクロ依存性そのものに意味がないと思う
それなら関数一覧をMarkdownに書いて、コピーして使ってもらうほうがよい
Cのヘッダファイルベースの小型ライブラリというやり方のほうが実用的だ
- 「それなら、なぜそうしたヘッダライブラリを標準Cライブラリに入れないのか」という冗談まじりの反応もあった
- ただし、「コピペ方式だとセキュリティアップデートはどうするのか」という現実的な反論も出た
「これからどんな形のオープンソースに意味があるのか」という問いも出ている
公開したコードが結局AI学習データとして吸収されてしまうからだ
そのため、完全なFOSSではなくsource-availableモデルが代案になり得るという見方もある
- 「より多くの人が使えるなら、それこそがオープンソースの利点ではないか」と反論する人もいる
  著者は、貢献の意味は単なる名前の表記より大きいと強調している
- ただし、「source-availableでも結局学習には使われる」と懐疑的な意見もある
- 「世界に無料で知識を与える義務はない」として、相互性のない共有を拒むべきだという主張も出た
- 「非自由なコードを配布するのは非倫理的だ」として、自由ソフトウェアの原則を守るべきだという意見もあった
- ある人は「もうオープンソースに興味を失った」として、すべてのプロジェクトを非公開に切り替えたと明かした
自分は、オープンソースは消えるどころか、むしろさらに強くなると信じている
本当に創造的な開発者たちがAIを活用して、企業には作れない革新を生み出すはずだ
オープンソースは今でも本物の価値を検証する場であり、AIによって限界を超えながら学ぶ空間でもある
- 真のイノベーションはオープンソースから生まれるだろう
  ただし政府や大企業はローカルAIシステムを規制しようとし、やがて「市民が使えるAI」の境界線が引かれるだろうと予測している
- 一方で、オープンソースプロジェクトはすでにAI生成コードの投稿に悩まされている
  レビューや方針議論に無駄な時間が増え、とくにコンパイラのような複雑な分野ではAIはまったく役に立たない
ある人は、「パッケージとして追加されなくても、コードを公開する行為そのものには今なお価値がある」と強調している
- 自分も小さなコード片を見つけたらコピーして、自分の標準に合わせて修正する。科学における共有の精神と同じだと感じる
  LLMが代わりにコードを書いてくれれば学習負担は減り、より深いテーマに集中できる
- Copyleftライセンスのほうが良いと思う。企業が勝手に持っていけないようにし、その代わり直接人を雇わせることになる
- 実行しなくても他人のコードを読んで学べることには大きな価値がある。問題解決そのものが贈り物だと思う
- ただしオープンソースは結局時間と労働の投資でもある
  たとえば14年間 rubygems.org を維持した末に、企業化した構造に失望して離れたと語る人もいた
「AIでコードを書くことも結局依存性の一形態だ」という指摘もあった
検証せずに貼り付けるのは、外部ライブラリを追加するのと変わらない
- ただしLLM生成コードは、必要に合わせて狭く設計できるため、不要な機能が減って効率的になり得る
- また、サプライチェーン攻撃や頻繁なアップデート負担がない点は利点だ
- その一方で、ライブラリは時間とともに自動的にモダン化されるが、LLMのコード片はそうではないという欠点がある
- 結局のところ問題は道具ではなく、検証せずにコピペする習慣だ。無責任な開発者はどんな道具を使っても同じ結果になる

haytsir 2025-11-18

2024年初めに小さなプロジェクトを作りながら
claude 3.5 に pure javascript で使える store state モジュールを作ってほしいと頼んだのですが
簡潔でありながらマイグレーションの状況にまで対応できるコードを書いてくれて、驚いた記憶があります。

小規模なライブラリほど、似たようなことを考える人たちが公開したコードが多いでしょうし、AI がそれを定型化された構造にしやすいと考えれば、当然の現象だと思います。

copyparty のように、誰でも思いつけるけれど、個人が長く維持するのは難しい。
そうしたプロジェクトを最後まで押し進めて生まれる、きれいに磨き上げられたプロジェクトを、これからは見づらくなるかもしれないという点は残念ではあります。