ハクソク

世界を動かす技術を、日本語で。

バイブコーディングがオープンソースを殺す

2026年1月26日原文(arxiv.org)

概要

  • Generative AI によるソフトウェア開発手法「vibe coding」の登場
  • OSSエコシステムへの 均衡効果 の分析
  • OSS利用のコスト削減と 生産性向上 の一方で、ユーザー関与の低下
  • OSSの 維持・発展 に必要な報酬体系の再設計
  • 現状のOSSモデルでは 福祉減少 のリスク

Generative AIによるvibe codingとOSSエコシステムへの影響

  • Generative AI がOSSの選択・組み合わせによるソフトウェア自動構築を実現
  • ユーザーが ドキュメント読解・バグ報告・メンテナとの交流 を省略
  • OSSが スケーラブルな入力資源 として活用される構造
  • OSSプロジェクトへの 新規参入や品質 の異質性を考慮したモデル構築
  • OSSの利用方法として 直接利用 と vibe coding経由 の2択

vibe codingの経済的インパクト

  • vibe codingで 既存コードの利用コストが低下 し、 生産性が向上
  • 一方、ユーザー関与が 減少 し、 メンテナ報酬 の機会が減少
  • OSSが 直接的なユーザー関与 のみで収益化される場合
    • vibe coding普及で 新規参入減少・共有減少
    • OSSの 可用性・品質低下
    • 生産性上昇にも関わらず 社会的福祉が減少

OSS持続のための課題と提言

  • vibe coding普及 下でOSSを現状規模で維持するには
    • 報酬体系の抜本的見直し が不可欠
  • OSSメンテナへの 新たな収益モデル の必要性
  • OSSエコシステムの 持続可能性確保 への課題提示

Hackerたちの意見

オープンソースのJava NLPロケーションライブラリを改善するためにClaudeのコードを使おうとしてるんだけど、コードの最適化や小さな問題の修正以外はうまくいかない。抽象的な高レベルの問題には苦戦してる。例えば、今は曖昧さの衝突に関する問題があって、入力が「California」の場合、出力が「California, Missouri」になる。Californiaは州だけど、Missouriの中にも同じ名前の市があるんだよね。https://github.com/tomaytotomato/location4j/issues/44 何度もClaudeにこの曖昧さを解決してくれって頼んだけど、いろんな優先順位付けの戦略を提案された。でも、その結果、ライブラリの他の機能が壊れちゃった。結局、AIの手助けを最小限にしてライブラリをゼロから再設計してる。なんでかっていうと、数年前にAIの助けなしでプロジェクトを始めたから。問題を解決するために設計したけど、その問題や微妙なプログラミングの決定がLLMには尊重されてないみたい。LLMはストーリーなんて気にしないし、コードの現在の状態だけを気にしてるんだよね。

└

プロジェクトは頭の中で始まったし、たくさんの欠陥やニュアンスがあって、LLMがそれを尊重するのに苦労してると思う。プロジェクト、それともあなたの頭の中？これが多くのLLMコーダーが直面することだと思う。彼らは言葉にするのが難しい、または時間と労力がかかる多くの内在的な知識を持っている。「説明できないけど、このコードはおかしい」みたいな感じ。

└

デザインドキュメントを書かせて、それをレビューするのがいい結果を得られると思うよ。レビューは君とボットの両方ができるしね。

└

LLMはストーリーには興味がなく、コードの現在の状態だけを気にしている。バックストーリーについて教えなきゃいけない。どこかに書いて入力しない限り、LLMはそれを知らないんだ。

└

それは苦労している それは苦労していない、あなたが苦労しているんだ。これはあなたが使っているツールで、あなたが言った通りに動いているだけ。ツールを使うには時間がかかるけど、それは全然問題ない。ツールを責めるのは逆効果だよ。コードがよくドキュメント化されていて、高レベルでインラインコメントもあれば、指示が明確なら、きちんと理解するはず。もし間違いを犯したら、どこでコミュニケーションが崩れたのかを見つけて、もっと明確かつ一貫して伝える方法を考えるのはあなたの責任だよ。

└

成功するLLM支援のコーディングの大事なポイントは、コードをただ吐き出すのではなく、しっかりとした土台を作ることだよ。ドキュメント、ドキュメント、ドキュメント：アーキテクチャやベストプラクティス、好み（コードに関することや、LLMとの関わり方、期待する動作について）をしっかり記録しておくことが重要。時間はかかるけど、これが半分成功するための唯一の方法だからね。LLMの開発者にとっての最大の力は、コードを書くことよりも、理解を助けたり、機能間の関連をつなげたりすることなんだ。プロジェクトに導入して「Xをやって、Yをやって」と言うだけでは、必要な土台がないとすぐに混乱してしまうよ。確かに、時々タスクを完了することはあるけど、複雑さが増して、あなたもLLMもそこから抜け出すのが難しくなる。AIに否定的な人たちは、LLMに優しいプロジェクトを作るために必要な膨大な作業を面倒に思って、失敗してツールのせいにしちゃうんだ。土台を作った後も、特に大事なプロジェクト（アイデアを素早く検証するためのプロトタイプじゃないもの）では、逐一コードを追いかけて、同じミスを繰り返さないように土台やドキュメントを更新し続けることが大切だよ。そして、土台作りにはメインの依存関係のソースコードも含める必要がある。私は主要な依存関係のためにgitサブツリーを使った_vendorディレクトリを持ってる。LLMは依存関係のコードやテストをチェックして、何が間違っているのかをもっと早く理解できるんだ。最後に、LLMは特定のパターン、例えばTDDと相性がいいから、「Xを実装して」ではなく「Xを実装したいけど、その前にテストと進捗を追跡する方法を設定しよう」と言った方がいいよ。仮想マシン用のインスペクターを作ったり、e2eテストや他のテストを設定したり、単にログをファイルに逐一出力したりする方法はいろいろある。ケースバイケースでアプローチは変わるけど、LLMにコードを作成してもらうための実際の助けを得るには、良いコンテキストと良いセットアップ（テスト、ビジネス要件の計画を書かせたり、実装の計画を立てたり）を持って、進むにつれてこれらの側面を追いかけて改善していくことが重要だよ。

└

モデルのトレーニングみたいだね。AIを使ったプログラミングは、テストとトレーニングの分割をしっかり意識してやってきたよ。エージェントが見えないホールドアウトを用意して、それに対して測定することが大事だね。（そして、エージェントがズルしないように） https://softwaredoug.com/blog/2026/01/17/ai-coding-needs-tes...

└

Claudeが全てのコミット履歴を読んだら、プロジェクトの方向性や一般的な進め方に合った選択ができるようになるんじゃない？

新しい大きな波の役立つオープンソースソフトウェアが出てくると思う。でも、開発モデルが同じままでいるとは思わないでね。やっといくつかのプロジェクトを復活させることができたし、もっとたくさん出てくるよ。驚くべきことの一つは、フォークから価値のあるものを簡単にマージできることだった。新しいOSSは、あなたが生み出せるコードの量ではなく、ソフトウェアのアイデア、ソフトウェアがどうあるべきか、どう振る舞うべきか、役に立つために何をするべきかから推進される。今はデザインがコーディングよりも重要なんだ。

└

新しいgitが必要だね。（今のgitを基に作れるかも） > フォークから価値のあるものを簡単にマージできることは本当に素晴らしいと思う。無駄な努力を減らせるしね。でも、それは存在するものを知っていて、どこにあるかを把握している場合に限る。

└

GitHubリポジトリに .claude が含まれているソフトウェアは信用できない。

└

本当の問題は、新しい波のバイブコードソフトウェアがどれだけペットプロジェクトからコミュニティ維持プロジェクトに成長できるかだね。バイブコーディングは、同じことのために10個の異なるバイブコードパッケージができたり、週末に作って放置されたりすることで、オープンソースソフトウェアの断片化や放棄を悪化させるかもしれない気がする。

Hacker Newsで議論の続きを見る