あなたの雰囲気に合わないスラップPRは歓迎されません

2025年10月28日原文(samsaffron.com)

概要

AIコーディングツール の普及により、オープンソースプロジェクトの メンテナー負担 が急増
プロトタイプ と 本番レビュー用PR の明確な区別が必要
プロトタイプは アイデア検証 に有用だが、直接PRとして送るべきではない
AI生成コード のレビューコストが高く、適切なラベリングと運用ルールが不可欠
人間による最終責任 と コードへのオーナーシップ の重要性

AIコーディングツールによる新たな課題

GitHub Copilot、Cursor、Codex、Claudeなどの AIアシスタント によるコード生成の爆発的増加
コード生成コストの低下 と レビューコストの高さ によるバランスの崩壊
不完全なPRがメンテナーの 貴重なリソース消費 の原因
Discourseをはじめとする多くのプロジェクトで この傾向が加速
すべてのOSSエンジニアが 同じ課題に直面 する時代の到来

プロトタイプと本番レビュー用PRの二分法

プロトタイプ ：アイデアのデモ用、品質保証・テスト・セキュリティ未確認
本番レビュー用PR ：ガイドライン遵守、テスト済み、責任を持てるコード
適切な ラベリングとルール の欠如がOSSエコシステムに悪影響
AI生成のプロトタイプPRがメンテナーの モチベーション低下 を招く
数分で生成 されたコードに対し、 数時間〜数日 かけてレビューが必要な現実

プロトタイプの運用と共有方法

プロトタイプは ブランチ で共有、PR（ドラフト含む）は送らない運用推奨
短い動画 や ブランチへのリンク、面白いコードの引用をIssueやフォーラムで共有
AIツールでのアイデア探索であることを明示
他の誰かがプロトタイプを 本番PRへ昇華 する可能性も
Jules、Codex cloud、Cursor Cloud、Lovable、v0など 多様なAIエージェント で誰でもプロトタイピングが可能

プロトタイピング導入時の社内合意形成

いつプロトタイプを使うべきか、 チームで議論と合意形成 が必要
デザイナーやPMの 受け止め方の違い、人間の創造性への影響、ラベリング基準などの検討
社内での 態度分断や不満 を防ぐための明確なルール作り

プロトタイプの価値と役割

アイデア検証・コードベース探索 の効率化
視覚的コミュニケーション 手段として有用
プレイアブルなプロトタイプは 仕様漏れの洗い出し に有効
テスト実施による 事前課題発見
LLM生成の奇抜なコードが 新たな発想のきっかけ になることも

メンテナーのサバイバルガイド

大規模PRの初期レビューをタイムボックス し、AI生成かどうかの見極めを優先
プロトタイプPR対応の エチケット整備
貢献ガイドラインへの誘導や フォーラムでの議論推奨
「vibe coded」な未レビューPRは遠慮なくクローズ してOK

本番レビュー用PRの基準

全コードの内容を確認し、責任を持てる状態 で提出
プロジェクトの ガイドライン・テスト・構造基準 を満たすこと
AIアシストの有無は問わず、 最終的に自分が保証できるコード であること
プロトタイプから本番PRへの ギャップは非常に大きい （例：Andrej Karpathyの指摘）
Veracode調査によると 生成コードの55%しか安全でない という現実

AIは「異星人知能」として捉えるべき理由

LLMを「優秀なインターン」等の 人間的比喩は不適切
良い部分と悪い部分が極端に混在 する異質な知能
異星人知能として受け入れることで、 エンジニアリングプロセスの複雑さ に対応

異星人知能の強みを活かすプロトタイピング

dv（Discourse用コンテナオーケストレーター）を AIエージェント中心で開発
複数のプロトタイプ環境を 簡単に構築しアイデア検証
dvのようなツールは プロトタイピングの工場 として機能

AI貢献・プロトタイプ禁止の是非

各プロジェクトの ルール遵守 が大前提（例：Cloud hypervisorはAI生成コード禁止）
「AI禁止」は 非生産的かつ実質的に強制困難
AI生成と人間生成の区別がつかない 場合も多い
健全なアプローチは 明確な期待値設定とラベリング
PRは 自分のブランドとして責任を持てるもの のみ提出

なぜラベリングとオーナーシップが重要か

人間によるコードレビュー がソフトウェア開発のボトルネック化
他人の時間と自分のブランド を守る意識が不可欠
プロトタイプは 学びや発見の宝庫 だが、PR提出時は 必ず責任を持つ こと
最終的な承認とオーナーシップ の重要性

まとめ AI時代のOSS貢献は、 プロトタイプと本番レビュー用PRの明確な区別 と 責任あるラベリング が不可欠。 AIによる爆発的なコード生成の恩恵と課題を理解し、 メンテナー・貢献者双方のリソースを守る運用 が求められる。 自分のブランドを守る意識 と プロジェクトガイドラインの遵守 が、今後ますます重要となる。

Hackerたちの意見

オープンソースプロジェクトには、レビュー用に提出されたコードがプロジェクトのコードフォーマットや規約に従うべきだと明記されたガイドラインが必要じゃないかな？

└

コーディングスタンダードの話を聞くたびにいつも思うことなんだけど、基準があるだけじゃなくて、それをツールで強制するべきだよね。とはいえ、個人は自分のコードを自由に扱うべきだと思う。小規模プロジェクトでそれを実現するためのインフラを整えるのはちょっと難しいけど、AIのPRは小規模プロジェクトにはあまり大きな問題じゃないと思う。

└

完璧な世界では、人々はPRやイシューを開く前に貢献ガイドラインを読んで理解するだろうけど、残念ながら…

└

まるで誰もガイドラインを読まないみたいだね。確かに、違反したときに指摘するためにはあった方がいいけど、基本的に人は貢献する前に読むことはないよね。

└

LLMのコーディングエージェントは、リンターを書くのがかなり得意だと思う。

└

コードのフォーマットや規約が問題じゃないんだよ。問題は、テストもせずに、考えもせず、PRに対するオーナーシップを持たずに変更を加えること。中には、AIを魔法使いみたいに使って、何かを実行して「オープンソースの貢献」を得ようとする人もいる。彼らは、適切な注意を払うことの重要性を理解して、メンテナの負担を減らさないといけない。メンテナが本当に必要になる前にレビューしないようにするためにね。新しい貢献者を楽にすることも大事だけど、これは素晴らしい議論だと思う。

└

提出されたコードはプロジェクトのコードフォーマットや規約に従わなければならない…それは表面的な話に過ぎない。問題は、LLM（大規模言語モデル）が単独の人間なら絶対にしないようなミスをすることだ。コーディングの規約は、コードレビューの焦点になるべきではなく、通常はツールによって強制されるべきだと思う。例えば、他の人のコードを読むとき、その人の思考プロセスに合わせて調整することができる。数行の（非自明な）コードを読んだ後には、その人がどんな「プログラミングキャラクター」なのか、どんな問題が予想されるのかが無意識にわかる。LLMが生成したコードは、まるで千の脳に同時に合わせようとしているようなもので、コードは千人が書いて公開したものの寄せ集めだからだ。コードを通じてその人の思考プロセスを読むことはもうできない。なぜなら、まとまりのある思考プロセスが存在しないからだ。個人的には、信頼できる貢献者でない限り、数十行の小さな変更以上のPRをオープンソースプロジェクトにマージするのは非常にためらう。例えば、受け入れるPRについては、バイブコードかどうかはあまり気にしない。受け入れるPRの複雑さが非常に低いから、違いはあまり重要ではないはずだ。

他に感じてる人いる？LLMコーディングのハイプカーブがピークに達しつつある気がする。価値があるって認識はあるけど、ソフトウェアエンジニアを全部置き換えるっていう興奮状態は過ぎてる感じ。

└

私もそう感じる—成熟に近づいている気がする。ここにいるサフランさんが言っているように、「プロトタイピングのためにAIを使いまくって、PRの代わりにデモやブランチ、ビデオとしてコミュニケーションを取るべき」って。人やプロジェクトが「その雑なものを出すな」っていう純粋な態度から、よりニュアンスのある、価値あるものを統合しながら怠けたものを除外する方法を自信を持って表現する方向に動いている感じがする。

└

gpt5がリリースされて、OpenAIのベールが剥がれたときにそうなったと思う。悪いモデルではないけど、オルトマン氏の言葉の価値がはっきりしたね。

└

人々が「AIバブルが弾ける」と言うとき、これを指しているんだ。AIは役に立ち続けることは明らかだけど、「特異点が近い」というハイプは衰えてきているし、永続的な指数的改善に基づく企業評価は現実的じゃない。さらに悪いことに、各世代での限界的な改善は、ますます高いリソースを必要とするようになってきていて、AIがどれだけ優れていても、経済的に運用できる範囲に制限がかかっている。

└

うーん、MSがOpenAIにサーバーの無料使用を許可して、OpenAIがそれを100億ドルの投資と呼ぶ。で、トークンを使い切って、MSが100億ドルの収益を上げるってことかな。そう思うよ。

Hacker Newsで議論の続きを見る

ハクソク