前回の記事では、「AI Slop」を受けて主要 OSS がコントリビュート方針を書き換えた事例を、全面禁止・Human-in-the-Loop・構造的閉鎖という三つの政策類型で整理しました。あの記事はあくまで「ポリシー文書がどう変わったか」に軸足を置いていました。
本記事はその続編として、もう一段踏み込んだ事例、つまりポリシー文書ではなく PR の入口そのものを閉じた、あるいは構造的に絞った 2026 年の著名事例を扱います。2026 年 6 月 5 日、独立系ブラウザエンジンの Ladybird が公開プルリクエストの受付を完全に停止したことは、この流れの象徴的な到達点でした。同年 1 月から春にかけては、tldraw・Ghostty・openai/codex・Jazzband が相次いで外部コントリビュートの経路を閉じています。
そして 2026 年 2 月、GitHub 自身が PR 受付を無効化・制限する機能を実装したことで、「PR を歓迎するのがデフォルト」という GitHub 時代の前提そのものが、プラットフォームのレベルから揺らぎ始めました。本記事では、これらの入口閉鎖を一次資料に当たりながら停止の形態で類型化し、最後に OSS に依存する立場、運営する立場の双方から実務的な示唆を整理します。
「ポリシー文書」から「入口の閉鎖」へ
前回扱った curl のバグバウンティ廃止や Ghostty の AI ポリシーは、いずれも「文書で態度を表明する」段階の話でした。文書は good actors には効きますが、Slop を投げ込む側はそもそも読みません。2026 年に入って各プロジェクトが踏み込んだのは、文書ではなくリポジトリのアクセス制御そのものを変える段階です。
この変化を駆動しているのは、前回も整理した「生成コストとレビューコストの非対称性」です。コードを書くコストはほぼゼロまで下がりましたが、レビューするコストは有限な人間の認知資源に縛られたまま変わりません。GitHub のオープンソースプログラム担当ディレクター Ashley Wolf 氏は 2026 年 2 月のブログ “Welcome to the Eternal September of open source” で、この状況を「作成コストは下がったが、レビューコストは下がっていない（The cost to create has dropped but the cost to review has not）」と端的にまとめています。
そして、ここに 2024 年の xz utils バックドア事件（CVE-2024-3094）以降の供給網セキュリティへの懸念が重なります。AI Slop は「レビュー帯域を物量で枯らす」問題ですが、xz 事件は「信頼を獲得してから悪用する」問題です。2026 年の入口閉鎖は、この二つの脅威が合流した結果として読むのが正確です。
停止・制限の四類型
2026 年に確認できた AI 起因の「外部 PR の停止・制限」は、停止の形態で見ると大きく四つに分類できます。前回の政策類型（全面禁止・Human-in-the-Loop・構造的閉鎖）が「文書上の態度」の分類だったのに対し、こちらは「実際に何を閉じたか」の分類です。
flowchart LR
A[外部 PR の停止・制限]
A --> B[完全閉鎖]
A --> C[招待・推薦制]
A --> D[自動クローズ]
A --> E[報奨・組織モデルの撤収]
B --> B1[Ladybird]
C --> C1[openai/codex]
C --> C2[Ghostty — Vouch]
D --> D1[tldraw]
E --> E1[curl — バウンティ廃止]
E --> E2[Jazzband — 組織解散]
- 完全閉鎖: 公開 PR の経路をすべて閉じ、コード変更をメンテナーのみに限定する。Ladybird が典型。
- 招待・推薦制: unsolicited な外部 PR を止め、招待されたコントリビューターや vouch を受けたコントリビューターのみを通す。openai/codex と Ghostty。
- 自動クローズ: PR の作成自体は許すが、外部からの PR を bot で自動的に閉じる。tldraw。
- 報奨・組織モデルの撤収: 個別リポジトリの入口ではなく、報奨制度や共同維持の組織モデルそのものを畳む。curl のバグバウンティ廃止、Jazzband の解散。
以下、それぞれの事例を見ていきます。
Ladybird — 公開 PR の完全停止
Ladybird は Blink・WebKit・Gecko のいずれにも依存しない完全独立のブラウザエンジンで、SerenityOS から 2024 年 6 月にスピンアウトしました。GitHub スター 6 万超、フォーク 3,000 超、コントリビューター 1,200 人超という規模で、非営利団体 Ladybird Browser Initiative が運営しています。GitHub 共同創業者の Chris Wanstrath 氏が自己資金 100 万ドルを投じ、Shopify や Cloudflare の支援も受けています。
創設者の Andreas Kling 氏は 2026 年 6 月 5 日、ブログ記事 “Changing How We Develop Ladybird” で「もう公開プルリクエストを受け付けない。今後 Ladybird のコードベースへの変更はメンテナーのみが行う」（原文: “We will no longer accept public pull requests. From now on, code changes to the Ladybird codebase will only be introduced by project maintainers.”）と宣言しました。アルファ版リリースを前に「より厳密な開発プロセス、より明確なセキュリティモデル、コードに責任を持つより小さな集団」（原文: “a tighter development process, a clearer security model, and a smaller set of people responsible for the code that enters the browser”）が必要だ、という理由です。
最も引用された一節は、前回も触れた「労力＝善意の代理指標」という前提の崩壊を正面から述べたものです。「大きなパッチはかつて大きな労力を意味し、その労力は善意の合理的な代理指標だった。その前提はもはや成り立たない」（原文: “A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.”）。さらに Kling 氏は供給網セキュリティへの懸念を明示しました。「ブラウザはインターネット全体からの信頼できない入力をユーザーのマシン上で実行する。巧妙に隠された脆弱性が一つあれば攻撃者には十分だ。私たちはすでに、メンテナーの信頼を獲得してそれを悪用する、忍耐強く資金力のあるキャンペーンを目にしてきた」（原文: “A browser runs untrusted input from the entire internet on the user’s machine, and one well-disguised vulnerability is all an attacker needs. We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it.”）。これは明らかに xz utils 型の攻撃を念頭に置いた言明です。
停止の形態は徹底しています。既存の公開 PR もすべてクローズし、「issue、コメント、メール、フォークを通じた影のコントリビュート経路も作らない」（原文: “We do not want to create a shadow contribution system through issues, comments, email, or forks.”）と明言しました。一方で、バグ報告、テストケース、ウェブサイトテスト、標準化議論、セキュリティ報告、技術的フィードバックは引き続き歓迎する、としています。ライセンスは BSD-2-Clause のままで、コードはオープンソースを維持します。つまり「コードのマージ権限だけを絞り、コントリビュートの他経路は残した」構造です。
反応は割れました。批判派は「外部からのコードのコントリビュートを一切受けないプロジェクトは本当にオープンソースか」「メンテナーへの権限集中は単一障害点になる」と問題提起し、擁護派は SQLite の開発モデル（バグ報告は受けるがコードのコントリビュートは厳格に管理する）を先例として挙げました。Ladybird の事例は、「オープンソース＝誰でもコードを送れる」という素朴な等式が、2026 年にはもはや自明ではなくなったことを示す決定的なケースです。
openai/codex — unsolicited PR の停止と collaborators-only
openai/codex は Apache-2.0 ライセンスのコーディングエージェント CLI で、約 9.1 万スター、1.35 万フォークという巨大リポジトリです。2026 年 1 月 27 日の Updating Codex Contribution Guidelines #9956 で、従来の外部 PR 中心モデルを招待制に切り替えました。
文言は明快です。「We no longer accept unsolicited pull requests（求めていない PR はもう受け付けない）」。理由は、AI ツールでコード生成が安く速くなった一方で、レビュー・修正・統合の人間コストは依然として高く、さらに外部投稿はアーキテクチャ文脈や近未来のロードマップを共有していないため、結果としてメンテナーのボトルネックになっている、というものです。メンテナーの etraut-openai 氏は、外部 PR が「force multiplier ではなく bottleneck になった」と明言しました。
その後 docs/contributing.md で制度が文章化され、「明示的に招待されていない PR は……レビューせずクローズする（will be closed without review）」と踏み込みました。単なる「まず issue を立ててほしい」ではなく、招待のない PR はレビューすらしない、という強い停止です。技術的にもこれは裏付けられており、PR 一覧画面には「新規 PR の作成は制限されている」と表示され、GitHub API のリポジトリメタデータには pull_request_creation_policy: "collaborators_only" が返ります。後述する GitHub のプラットフォーム機能を、正式なガバナンス機構として使い始めた格好です。
興味深いのはコミュニティの反応で、全面的な反発というより投稿様式の変更として現れました。複数の issue で外部開発者が「contribution policy が招待制なので、PR ではなく enhancement request として出す」と明記し、ローカルや fork 上の reference implementation を添えるケースが見られます。コード差分の直接提出から、分析・提案・再現情報の提出へと、コントリビュートの重心が移ったわけです。
tldraw — 外部 PR の自動クローズと「AI の自己ループ」
tldraw は React ベースの無限キャンバス SDK です。前回も触れたとおり、創業者の Steve Ruiz 氏が 2026 年 1 月 15 日の Issue #7695 で外部コントリビューターからの PR を自動クローズする方針を打ち出し、1 月 17 日のブログ “Stay away from my trash!” で詳述しました。
続編である本記事で改めて強調したいのは、tldraw が指摘した「AI の自己ループ（AI-to-AI looping）」という構造です。Ruiz 氏は Claude Code 用の /issue コマンドで軽微なアノマリーを低コストに issue 化していました。その issue 群を外部コントリビューターが各自のコーディングエージェントに食わせ、中身を理解しないまま diff を生成して PR を返してきます。結果として「メンテナーが深く吟味していない不完全な issue」に対し「コントリビューター自身も整合性を説明できないコード」が自動送信される、不毛な自動化サイクルが完成しました。提出された PR は構文も CI も通るのに、アーキテクチャや長期的なデザインパターンを完全に無視し、PR テンプレートや CLA も放置されがちでした。
なお tldraw は厳密には OSI 準拠のオープンソースではなく、production 利用にライセンスキーを要する「ソースアベイラブル」（tldraw license）です。それでも GitHub 上で公開され、コミュニティから PR を受けていたプロジェクトとして、入口閉鎖の代表例に数えられます。停止の形態は「外部 PR の自動クローズ」で、issue やバグ報告は引き続き歓迎、「GitHub がより良い管理ツールを提供するまでの一時的ポリシー」と位置づけられました。その「より良いツール」を GitHub が 2 月に実装したのは、後述のとおりです。
Ghostty — Vouch という Web of Trust
Ghostty は HashiCorp 共同創業者の Mitchell Hashimoto 氏が Zig で開発する GPU アクセラレートなターミナルエミュレータです。前回は AI ポリシーの段階的な強化（2025 年 8 月の開示義務、2026 年 1 月の AI_POLICY.md、2 月の Vouch Request 制）を扱いました。
続編で深掘りしたいのは、その Vouch を支える仕組みそのものです。Hashimoto 氏は、信頼された既存メンバーから明示的に「保証（vouch）」されない限り外部ユーザーが PR を出せない、という Web of Trust ツール Vouch を自ら開発し、Ghostty に統合しました。特徴的なのは、信頼リストをデータベースや外部 API ではなく、リポジトリ内の単一テキストファイル（Trustdown 形式）で管理し、POSIX ツールや GitHub Actions でパースする設計です。2026 年 6 月時点で、Ghostty の本番運用を筆頭に複数のリポジトリがこの Vouch を導入し始めていると報告されています。
Hashimoto 氏が一貫して述べているのは、これが「反 AI ではなく反バカ（anti-idiot, not anti-AI）」のスタンスだという点です。Ghostty 自身もメンテナーの多くが日常的に AI を使っており、問題は AI を使うことではなく、理解も検証もしていないコードを他人にレビューさせる行為にある、という整理です。Vouch は、その「検証していないコードを投げ込む匿名の流入」を、人間の信頼関係によってゲートする試みだと言えます。
curl と Jazzband — 報奨制度の廃止と組織の解散
前回詳しく扱った二件も、入口閉鎖の文脈で簡潔に位置づけておきます。
curl は 2026 年 1 月 26 日、Daniel Stenberg 氏のブログ “The end of the curl bug-bounty” で、2019 年から続いたバグバウンティの廃止を発表しました（制度は 2026 年 1 月 31 日をもって正式に終了）。これは PR 受付の停止ではなく報奨制度の廃止ですが、AI が捏造する偽の脆弱性報告で有効率が 5% 未満まで崩れた結果として、金銭インセンティブという「入口の誘引」を断った点で、本記事の文脈と地続きです。報告経路は GitHub Private Vulnerability Reporting に限定されました。
Jazzband は 2026 年 3 月 14 日、“Sunsetting Jazzband” で組織そのものの終了を発表しました。84 の Python プロジェクトを共同維持してきた「共有プッシュアクセス」モデルが、AI 生成スパムの氾濫する世界では成立しなくなった、という説明です。これは個別リポジトリの入口を閉じたのではなく、共同維持の組織モデルそのものを畳んだ最も重い事例でした。
Node.js — 19,000 行の AI 生成 PR が呼んだ議論
入口を閉じた事例ではありませんが、2026 年の論点を象徴するケースとして Node.js の一件は外せません。
2026 年 1 月、Node.js コアの TSC（Technical Steering Committee）メンバーで Fastify 作者の Matteo Collina 氏が、約 19,000 行（PR 自身の内訳ではコード約 9,200 行、テスト約 11,200 行、ドキュメント約 1,300 行で総計 2 万行超）の仮想ファイルシステム機能を実装した PR #61478 を提出しました。「大量の Claude Code トークンを使ったが、全コードは自分でレビューした」と開示したうえでの投稿です。これに対し、かつて io.js を立ち上げた当事者でもあった Fedor Indutny 氏が、LLM 生成 PR の受理を禁止する嘆願を立ち上げ、TSC 投票を要求しました。
争点はコードの品質そのものよりも、DCO（Developer Certificate of Origin）の順守、巨大 diff のレビュー可能性、そして有料ツールが事実上の「課金障壁」になる公平性でした。この一件は、「人間がレビューしたと開示された大規模 AI 生成 PR」を、信頼ベースのコミュニティがどう扱うべきかという、入口閉鎖の一歩手前の論点を鮮明にしました。コードレビューが「設計思想の相互理解」から「単なる構文検査と動作確認」へ退化したとき、マージされたコードはコンテキストを欠いた技術負債になる、という懸念です。
GitHub — プラットフォームとしての対応
メンテナーの離脱と悲鳴を受けて、GitHub も 2026 年 2 月、プラットフォームとしての対応に踏み切りました。前回は機能の存在に簡単に触れましたが、続編では仕様を具体的に押さえておきます。
2026 年 2 月 13 日、GitHub は リポジトリ設定の変更を公式にリリースしました。
- PR 機能の完全無効化: Settings から PR 機能をオフにできる。有効にすると「Pull requests」タブ自体が消え、新規 PR を開くことも既存 PR を閲覧することもできなくなる。ミラーや読み取り専用コードベース向け。
- コラボレーター限定の PR 制限: PR タブは維持しつつ、write 権限を持つコラボレーターのみに PR 作成を限定する。未承認の外部ユーザーの PR だけをブロックできる。
これらは Settings > General > Features から変更でき、設定はリポジトリのメタデータにも反映されます。先述の openai/codex が pull_request_creation_policy: "collaborators_only" を返していたのは、まさにこの機能によるものです。
この機能はコミュニティで激しい議論を呼びました。一部は「アンチ OSS 的で、参入障壁を作って排他的な文化を助長する。AI 生成 PR だけを識別してブロックする中間層を作るべきだ」と批判しました。一方、多くのメンテナーは「開発者は自分のコードを無償で共有しているが、他人のコードレビューを強制される義理はない」と防衛手段の正当性を主張しました。議論の中で生まれた「サッカースタジアムとブブゼラ」の比喩は秀逸です。観客（コントリビューター）が無料の拡声器（生成 AI）を一斉に吹き鳴らした結果、選手（メンテナー）が試合を続けられなくなったなら、スタジアム（GitHub）は持ち込み（PR）を制限せざるを得ない、というものです。
学術的整理 — “Beyond Banning AI” の三類型
個別事例と並行して、学術的な整理も進んでいます。2026 年 3 月の論文 “Beyond Banning AI: A First Look at GenAI Governance in Open Source Software Communities” は、著名な 67 の OSS プロジェクトのガバナンス対応を分析し、三つの方向性に分類しました。前回の記事の三類型とほぼ対応するもので、外部からの裏付けとして有用です。
- 禁止主義的アプローチ（Prohibitionist / zero-tolerance）: AI 生成コードを知的財産上の不確実性や「汚染コード（tainted code）」とみなし、入口で関門を閉じる。QEMU や NetBSD が代表。
- 境界・責任重視型（Boundary-and-accountability）: AI 利用を許容しつつ、開示・検証・全責任の引き受けを課す。Linux カーネル・CloudNativePG・Aurelia など。
- 品質第一・ツール不可知論的（Quality-first / tool-agnostic）: 生成手段の取締りは非現実的とし、既存の品質基準と CI、手動レビューの再強化で対応する。Oh My Zsh や curl が代表。
論文が提起する本質的な課題は、AI 生成コードが残す「情報の消失壁（wall of missing information）」です。一瞬で 19,000 行を生成するとき（Node.js の例）、「なぜこの設計にしたか」「どのトレードオフを検討したか」というコンテキストが残りません。さらに、AI 生成コードが Web に公開され次世代モデルの学習データになる「モデル崩壊（model collapse）」の懸念も指摘されています。設計思考なきコード生成は、長期的にソフトウェアの品質を下げる負の螺旋を内包している、という整理です。
まとめ
前回は「自社で OSS を運営する側」の政策設計を整理しました。続編となる本記事の事例群からは、運営側だけでなく OSS に依存する側の観点も含めて、次の三点が実務的な示唆になります。
- 閉じ方の「強度」を読む
- 同じ AI 起因の閉鎖でも、停止の形態によって依存先としての意味は変わる。
- Ladybird の完全閉鎖は、実質的にメンテナーへの集権。
- codex・Ghostty の招待・推薦制は、関係を作ればコントリビュートを続けられる。
- tldraw の自動クローズは、GitHub のツール待ちの一時措置。
- 共通点は、いずれも issue・バグ報告・セキュリティ報告などコード以外の経路を残し、「コードのマージ権限だけを絞った」こと。
- 依存ライブラリがどの強度で閉じたかを見て、fork するか、関係を作ってコントリビュートを続けるか、待つかを判断する。
- ライセンスを fork 戦略の前提として読む
- Apache-2.0 や BSD のパーミッシブなライセンスは、上流が閉じても fork による継承の法的余地を残す（Ladybird は BSD-2-Clause、codex は Apache-2.0 を維持）。
- tldraw のようなソースアベイラブルなライセンスでは、PR 停止とライセンス制約が重なって逃げ道が狭まる。
- 重要な依存先については、ライセンスとガバナンスをセットで評価項目に加える。
- 供給網セキュリティと AI Slop を同じテーブルで扱う
- Ladybird が信頼の悪用という供給網攻撃に言及したように、2026 年の入口閉鎖は「レビュー帯域の枯渇」と「信頼の悪用」という二つの脅威の合流点にある。
- 自社が依存する OSS の bus factor、資金状況、コントリビューター受け入れポリシーを評価し、必要ならスポンサーシップで支援する。
- 自社開発者が AI 生成コードを上流に「丸投げ」しないよう、社内ポリシーで歯止めをかける。
- 依存先のメンテナーを守ることが、結局は自社の供給網を守ることになる。
前回の結びで書いたとおり、OSS のオープンなコントリビュートというモデルは死んでいません。しかし 2026 年は、「PR を歓迎するのがデフォルト」という GitHub 時代の素朴な前提が、プラットフォームのレベルから崩れ始めた年でした。価値の源泉は「コードを書くこと」から「正しい問題を設定すること」、そして「明示的な信頼を構築すること」へと、はっきり移っています。Ghostty の Vouch が示す Web of Trust への回帰は、その最も具体的な現れだと言えるでしょう。
以上、2026 年に OSS が外部 PR 受付を停止・制限した著名事例について、前回の続編として現場からお送りしました。