curl の作者 Daniel Stenberg 氏が 2026 年 1 月に HackerOne 上のバグバウンティを終了し、Mitchell Hashimoto 氏が同月、ターミナルエミュレータ Ghostty で「ドライブバイの AI 生成 PR は問答無用でクローズする」と宣言しました。tldraw の Steve Ruiz 氏は外部からの PR をすべて自動クローズに切り替え、Jazzband は 84 プロジェクトの共同維持組織そのものを畳む決断を下しています。

引き金になったのは、生成 AI が大量に生み出す「AI Slop（AI スロップ）」と呼ばれる、もっともらしいが検証されていない PR、issue、脆弱性報告です。コーディングエージェントによって「秒で生成し、数時間かけて反証する」非対称なレビュー経済が成立し、これまで OSS を支えてきた「オープンな貢献（open contribution）」というモデルが根底から揺らいでいます。

本記事では、2024 年末から 2026 年春にかけて公開された一次資料（メンテナーのブログ、リポジトリのコミット、AI ポリシー文書、メーリングリストの議論）に当たりながら、主要 OSS プロジェクトが採った方針転換を整理します。最終的には、自社で OSS を運営する場合に参照できる三つの政策類型（全面禁止、Human-in-the-Loop、構造的閉鎖）として整理します。

AI Slop と「維持管理コストの非対称性」

「AI Slop」という言葉は、Simon Willison 氏らが 2024 年から使い始めたもので、生成 AI が作り出す低品質なコンテンツを指します。OSS の文脈では、AI に書かせたままで投稿者自身が検証していない PR、AI が幻覚（ハルシネーション）で作り上げた API を引用するバグ報告、AI が「もっともらしく見せる」ためにテストやドキュメントを付けてくる脆弱性レポート、などが該当します。

Python Software Foundation の Security Developer-in-Residence である Seth Larson 氏は、2024 年 12 月のブログ記事 “New era of slop security reports for open source” で、CPython、pip、urllib3、Requests のトリアージ現場から見えた問題を最初に体系化しました。

問題の本質は、貢献の生成コストとレビューコストの「非対称性」にあります。

指標	従来のエコシステム	AI 主導のエコシステム	ガバナンスへの影響
生成コスト	数時間〜数日	数秒〜プロンプト 1 回	自然な品質フィルターの消失
レビューコスト	中程度（文脈依存）	極めて高い（敵対的検証が必要）	メンテナーの疲弊
表面的な正しさ	価値と相関	価値と無相関	「綺麗に見えるコード」への不信
投稿の意図	具体的なニーズに基づく	不透明（実績稼ぎや自動化）	不要な機能要求の急増

LangChain のコントリビューションガイドはこの状況を 「大量の自動投稿は私たちの人間の労力に対する DoS 攻撃である」 と表現しています。

curl の Stenberg 氏は “Death by a thousand slops” で、メンテナーは「機械の中の砂を減らす（reduce the amount of sand in the machine）」必要があり、ノイズの出どころが人間か AI かに関わらず「最終的な影響は同じ（the net effect is the same）」だと指摘しています。AI Slop はメンテナー個人を物量で削り取り、最終的にはプロジェクトの存続そのものを脅かすところまで到達しています。

三つの政策類型

2024 年末から 2026 年春にかけて公開された各プロジェクトのポリシーは、大きく三つの類型に分類できます。

flowchart LR
    A[AI Slop 対策]
    A --> B[全面禁止派]
    A --> C[Human-in-the-Loop 派]
    A --> D[構造的閉鎖派]

    B --> B1[NetBSD]
    B --> B2[Gentoo]
    B --> B3[QEMU]
    B --> B4[Zig / GIMP]
    B --> B5[Cloud Hypervisor]

    C --> C1[Linux Kernel]
    C --> C2[LLVM]
    C --> C3[Fedora]
    C --> C4[WordPress]
    C --> C5[Django security.txt]
    C --> C6[MicroPython]
    C --> C7[Mastodon]
    C --> C8[EFF]

    D --> D1[curl — バウンティ廃止]
    D --> D2[Ghostty — vouch 制]
    D --> D3[tldraw — 外部 PR 自動クローズ]
    D --> D4[Jazzband — 解散]
    D --> D5[GitHub — PR 制御機能]

• 全面禁止派: DCO（Developer Certificate of Origin）やライセンス互換性を根拠に、AI 生成物そのものをコミットしないことを宣言する流派。NetBSD、Gentoo、QEMU、Zig、GIMP などが該当します。
• Human-in-the-Loop 派: AI 利用を全面禁止せず、「人間が責任を取る」「AI 利用を開示する」「Good First Issues では使わない」といった条件を付ける流派。Linux カーネル、LLVM、Fedora、WordPress、Mastodon、EFF などが採用しています。
• 構造的閉鎖派: ポリシー文書ではなく、PR 受付や報告経路そのものを閉じてしまう流派。curl のバグバウンティ廃止、Ghostty の vouch 制、tldraw の外部 PR 自動クローズ、Jazzband の解散などが該当します。

以下、それぞれの代表的な事例を見ていきます。

curl — バグバウンティ廃止と「シグナル対ノイズ比」の崩壊

curl は世界中で数十億台規模のインストールベースを持つデータ転送ライブラリで、2019 年から HackerOne 上でバグバウンティを運営してきました。Stenberg 氏が 2026 年 1 月 26 日のブログ記事 “The end of the curl bug-bounty” で公開したデータによれば、6 年間で 87 件の脆弱性を確定し、累計 10 万ドル以上を支払っています。

問題は 2025 年に入って急速に悪化しました。Stenberg 氏が 2024 年 10 月時点で集計したスタッツでは、受け取った報告のおよそ 6 件に 1 件（約 15%）が有効な脆弱性として認定されていました。しかし 2025 年は AI を使って「脆弱性を捏造する」報告が急増し、有効率は 5% 未満まで落ち込みます。2026 年に入ってもこの傾向は続き、月初に届いた報告のうち AI 由来でないと判断できるものはほぼ皆無、というところまで signal-to-noise 比が崩れました。

AI が生成する「10 年以上前に削除された関数のバッファオーバーフロー」や、存在しない curl_mfprintf の format string 脆弱性、誰も実装していない HTTP/3 のストリーム依存サイクルといった、専門用語で武装した架空の報告を一件ずつ精査して反証する作業は、少人数で運営される OSS プロジェクトにとって致命的でした。

2026 年 2 月 1 日、Stenberg 氏は FOSDEM 2026 のクロージングキーノート “Open Source Security in spite of AI” で、満員の Janson ホールに向けてバウンティ廃止と新方針を発表しました。新しい BUG-BOUNTY.md は「報奨金は提供しない」と明言し、.well-known/security.txt は「くだらない報告で時間を浪費させた者は BAN し、公の場で晒し上げる」と踏み込みました。報告経路は GitHub Private Vulnerability Reporting のみに限定されました。

興味深いのは、2026 年 4 月の追跡記事 “High-Quality Chaos” で、報酬を廃止したのちに HackerOne に戻し、アカウント評価ベースで運用した結果、Slop の流入が沈静化したと報告されている点です。一方で Stenberg 氏は、別の機会には専門家が AI を「使いこなした」例として、Joshua Rogers 氏が ZeroPath と協働して 100 件以上の実バグを発掘した事例（Stenberg 氏の 2025 年 10 月のまとめ記事 “A new breed of analyzers”）を高く評価しており、「AI そのもの」ではなく「未検証の出力を投げ込む人間」が問題であることを繰り返し強調しています。

Ghostty — vouch 制と公開糾弾リスト

Ghostty は HashiCorp の共同創業者 Mitchell Hashimoto 氏が開発する Zig 製のターミナルエミュレータです。Hashimoto 氏自身が AI を積極的に使う立場にもかかわらず、Ghostty のポリシーは AI Slop に対して最も攻撃的な部類に入ります。

転機は三段階に分かれています。

1. 2025 年 8 月 19 日: PR #8289 で「AI tooling must be disclosed for contributions」という開示義務が公式化されました。提案文で Hashimoto 氏は、現状では AI がしばしば slop を生み、経験の浅い投稿者が十分にレビューしないままコードを送ってくることが問題だと説明しています。
2. 2026 年 1 月 22 日: 独立した AI_POLICY.md が追加されました。コミットメッセージでは、agentic programming の台頭で従来存在していた「労力による自然な逆圧」が消え、低品質貢献の件数がおおよそ 10 倍ないしそれ以上に増えたことが説明されています。accepted issue に紐づかない AI 生成 PR の即時クローズ、AI 生成メディアの禁止、低品質投稿者の将来貢献停止までが明文化されました。
3. 2026 年 2 月 15 日: CONTRIBUTING.md と discussion テンプレートが更新され、初回貢献者向けの Vouch Request 制 が導入されました。初回貢献者はまず Vouch Request discussion を「自分の言葉で、AI に書かせずに」開く必要があり、承認されない限り PR は自動的にクローズされます。違反者は Public Denouncement List（公開糾弾リスト）に載り、Ghostty への将来のすべての投稿が bot で閉じられる仕組みです。

Hashimoto 氏の立場は AI_POLICY.md に集約されています。AI を使うこと自体ではなく、自分が理解も検証もしていないコードを他人にレビューさせる行為が、メンテナーに対する無礼でありリソースの略奪である、という整理です。

さらに 2026 年 4 月、Hashimoto 氏は “Ghostty Is Leaving GitHub” を発表し、Ghostty を GitHub から完全に撤退させると宣言しました。本人が公にしている理由は GitHub Actions の障害をはじめとするインフラの不安定さで、この投稿自体は AI モデレーションには触れていません。一方、それ以前の AI_POLICY.md 関連の議論では、メンテナーが AI のノイズをふるい落とすためのプラットフォーム機能が GitHub に乏しいことを繰り返し問題視していました。Hashimoto 氏は別途、コントリビューターが既存のメンテナーから vouch を受けることを必須にする web-of-trust ツール Vouch も実験しています。

tldraw — 「自分のゴミに近寄るな」

tldraw は React ベースのホワイトボード SDK で、創業者 Steve Ruiz 氏が 2026 年 1 月 15 日、Issue #7695 で外部からのプルリクエストをすべて自動クローズに切り替えると発表しました。2 日後の 1 月 17 日には、Ruiz 氏自身が理由を “Stay away from my trash!” で詳述しています。

Ruiz 氏が観察したのは、彼自身が Claude Code の /issue コマンドで自動生成して GitHub に投稿していた粗い issue ドラフト（＝ゴミ）が、外部のコントリビューターによって AI に再入力され、「もっともらしいが見当外れの PR（＝毒）」として返ってくるループです。彼はこれを「AI slop all the way down（どこまで降りても AI スロップ）」と呼びました。

Ruiz 氏が投げかけた問いは、価値の源泉そのものを揺さぶります。「コードを書くことが最も簡単なプロセスになったのであれば、なぜ他人にそれを書いてもらう必要があるのか？」。Issue #7695 には数百件のポジティブなリアクションが集まり、コミュニティの支持は概ね方針側に傾きました。

tldraw の特徴は、Ghostty のような詳細ポリシーではなく、入口そのものを一時的に狭めた点にあります。Issue / バグ報告 / Discussions は引き続き歓迎しつつ、PR レビューに割く真剣な注意を保護するために、コードの寄贈という形での貢献を選別する仕組みです。

Linux カーネル — DCO は人間にしか署名できない

Linux カーネル は 2026 年、長期にわたる LKML での議論を経て、“Coding assistants and Linux kernel development” というポリシーを正式に採択しました。背景としては、開示なしの LLM 生成パッチがリグレッションを起こす事例が複数報告されたことや、Co-developed-by: / Generated-by: のような明示的なトレーラーを使って AI の関与を可視化すべきだ、というメーリングリスト上の議論の積み重ねがあります。

最終的なポリシーの骨子は以下です。

• AI の利用は許容する。
• AI エージェントは Signed-off-by: を付けてはならない。DCO は人間にのみ署名可能だからである。
• AI を使った場合は Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] というトレーラーを付ける。
• ライセンス、正確性、レビューの最終責任は人間の投稿者が負う。

Linus Torvalds 氏は「AI は単なる道具として扱うべきだ」「ドキュメントは good actors のためのものであり、AI slop を投げる者はそもそもポリシーを読まない」という立場を 2026 年 1 月の LKML 議論（The Register の解説）で繰り返し示しており、最終ポリシーも人間の説明責任に賭ける構造を選びました。これは Human-in-the-Loop 派の事実上の標準テンプレートになっています。

LLVM — Good First Issues での AI 利用禁止

LLVM は 2026 年初頭、“AI Tool Policy”（コミット 18695b27d565）を採択しました。動機は明示的で、「2025 年の間に、LLM が補助した nuisance contributions の量が増加するのを観測した」と書かれています。

ポリシーの中で特に重要なのは、AI が PR を出すだけで人間の承認なしにマージされ得る GitHub @claude のような自律エージェントを禁止した点、そして Good First Issues での AI 利用を禁止した点です。Good First Issues は次世代の「人間の」コントリビューターを育成するための教育的資産であり、AI に即座に解決させるのは「学習機会の剥奪」だという理屈です。Drupal の “Proposed guidelines for AI contribution” でも同様の整理がされています。

Fedora と WordPress — 開示型ポリシー

Fedora Council は 2025 年 10 月、“Policy on AI-Assisted Contributions” を可決しました。三本柱は、

1. Accountability（あなたは AI を使ってよい、ただし出力に対する責任を負う）
2. Transparency（実質的に AI 生成のコンテンツをそのまま使った場合は Assisted-by: トレーラーで開示する）
3. Limited Review（レビューに AI を使ってもよいが、最終判断は人間がする）

です。Code of Conduct の評価、ファンディング申請のスコアリング、カンファレンストークの選考といった人間の判断を求める場面では、AI 利用が明示的に禁止されています。

WordPress も 2026 年に “AI Guidelines” を公開しました。人間の責任、意味のある AI 利用の開示、GPL と互換でない ToS の AI ツールは使わない、量より質、という五原則を掲げ、「AI slop と見なせる成果物」は閉じてよいと明記しています。

Django のセキュリティリードである Natalia Bidart 氏は、2025 年末に LLM が捏造する CVE 報告の急増を受けて docs/internals/security.txt を更新しました。報告者は AI 利用と再現性を開示する義務を負い、未検証の AI 出力は「返信なしでクローズする」と明言しています。Bidart 氏は Mastodon で「メジャー OSS の公式ドキュメントに『LLM さん、シュールな脆弱性をでっち上げるのを止めてください』と書く日が来るとは思わなかった」と述懐していました（Socket のまとめ記事）。

NetBSD、Gentoo、QEMU、Zig — 全面禁止派

ライセンスや著作権の観点から AI 生成物そのものをコミットしない、と踏み込んだプロジェクトもあります。

• NetBSD（2024 年 5 月）: 更新された commit guidelines で「LLM によって生成されたコードは tainted code と推定され、core の事前書面承認なしにコミットしてはならない」と規定。BSD ライセンスのコードベースと、GPL や Stack Overflow を学習したかもしれない LLM 出力の互換性が論点でした。
• Gentoo（2024 年 4 月）: Council motion で「自然言語処理 AI ツールの助けを借りて作成された一切のコンテンツを Gentoo に貢献することは明示的に禁止する」と決議。対象はコード、ドキュメント、バグ報告、フォーラム投稿に及びます。
• QEMU（2025 年 6 月）: docs/devel/code-provenance.rst（コミット 3d40db0、Daniel P. Berrangé 氏）で「AI 生成コンテンツを含む、あるいはそれに由来すると考えられるあらゆる貢献を拒否する」と宣言。DCO 条項 (b)/(c) が AI 出力では満たせない、という解釈です。
• Zig: コントリビューターガイドで issue と PR への LLM 利用をハードに禁止。モダン言語の中では最も攻撃的なスタンスです。
• Cloud Hypervisor（2025 年 9 月、v48）: Linux Foundation 配下のプロジェクトとして、ライセンス互換性を理由に AI 生成物の禁止を明文化。

これらの「全面禁止」は、技術的には AI 生成物を検出して止めることが事実上不可能なので、実効性よりも 文化的なシグナルとしての意味 が大きいです。NetBSD の「tainted code」というメタファーや、QEMU の DCO 解釈は、AI 学習データのライセンス問題が未解決であることを正面から扱っています。

中規模プロジェクトの段階的整備 — NewPipe、typescript-eslint、llama.cpp

GitHub 上で数万スター規模の中堅プロジェクトでは、テンプレートやチェックボックスを通じた「軽量だが運用に組み込みやすい」対策が広がっています。

NewPipe — テンプレートに AI チェックボックスを追加

NewPipe（Android クライアント、約 3.8 万スター）は 2025 年 12 月 16 日、コミット 097c643 で CONTRIBUTING.md と issue / feature request / PR テンプレートをまとめて更新しました。コミットメッセージには「The amount of AI generated PRs is increasing while their quality often remains poor」と書かれています。

新方針は全面禁止ではなく、工程別の許容ラインを引きました。新機能や大きなコード変更での AI 依存は原則禁止、小さなバグ修正は根本原因を理解した上でなら限定的に許容、ドキュメント生成は可だが厳格な人間レビューを要求、そして issue / PR テンプレ本文を AI で書くことは明示的に禁止、という設計です。バグ報告とフィーチャーリクエストのテンプレートには「この内容は AI 生成ではない」というチェックボックスが追加されました。

typescript-eslint — Maintainer Bandwidth を守るポリシー

typescript-eslint（約 1.6 万スター）は 2026 年 1 月 20 日、新規に AI_Contribution_Policy.mdx を追加しました。冒頭の動機は端的で、「AI-assisted coding tools の台頭で大量の低品質貢献を生成しやすくなり、それを善意で読み、レビューし、やり取りすることが従来型の貢献よりはるかに maintainer bandwidth を奪う」と書かれています。

ポリシーは「AI を使った貢献を全面禁止することはできないし、しない」と明記したうえで、

• AI 生成コードは厳密にレビューすること
• 自分が AI なしで理解、修正、レビュー応答できる範囲でのみ AI を使うこと
• issue / PR テンプレートを無視しないこと
• PR description、issue 本文、コメントなどの非コード本文では AI 生成文を避けること

を求めています。中でも「PR 説明文に AI 生成文を貼られても、コード差分の言い換えに終始しがちで maintainer に価値を追加しない」「我々で LLM を呼んだほうがよほど時間の使い方として優れている」という指摘は、AI 補助の使い分けを示すうえで示唆的です。

llama.cpp — 短期間に 6 回の段階的強化

llama.cpp（約 10.9 万スター）は単発の方針変更ではなく、2025 年 11 月から 2026 年春にかけて CONTRIBUTING.md を段階的に強化した事例として典型的です。

• 2025-11-30: update guidelines for AI-generated code
• 2025-12-29: tighten AI usage policy
• 2026-01-13: ban AI-generated PR descriptions
• 2026-02-11: ban AI for issues and discussions
• 2026-03-09: limit open PRs for new contributors to 1
• 2026-03-21: explicit about banning accounts that violates policy

現行ポリシーは「主に AI 生成の PR は受け入れない」「AI を使った場合は利用方法を明示し、すべてのコードを説明できるよう人間が包括的にレビューする」と明記し、PR description、GitHub Discussions、bug report、feature request、対人応答といった非コード本文への AI 利用も厳禁としました。違反 PR は理由説明なしにクローズ可能、という運用ルールもあわせて整備されています。

llama.cpp の事例の教訓は、AI Slop 対策では 「一度ルールを書けば終わり」ではなく、現場で見つけた抜け穴を継続的に塞ぐ必要がある ことです。新規貢献者の同時オープン PR を 1 に絞った 3 月の変更は、AI Slop が triage キューを詰まらせる側面への直接の対処でした。

Jazzband の終焉 — 共同維持モデルが成り立たなくなった

Jazzband は 10 年以上にわたって django-debug-toolbar、pip-tools、prettytable、sorl-thumbnail など 84 の Python プロジェクトを共同維持してきた組織です。月間ダウンロードはおよそ 1.5 億、メンバーは 56 カ国にまたがる 3,135 人、GitHub スター総数は 9.3 万を超えていました。

その Jazzband が 2026 年 3 月 14 日、“Sunsetting Jazzband” で組織の終了を発表しました。創設者で PSF Chair の Jannis Leidel 氏は、終了の引き金として GitHub の「slopocalypse」を名指ししています。Jazzband は「最悪のケースが『誰かが間違った PR をマージしてしまうこと』である世界」のために設計されていたが、AI 生成スパムが氾濫する世界では、共同 push 権限を持つメンバーシップ・モデル自体が成立しなくなった、という説明でした。

新規申し込みは即時停止、プロジェクトリードへの連絡は PyCon US 2026 前に完了させ、GitHub 組織は 2026 年末で閉じる予定です。Simon Willison 氏が引用ポストで拡散し、ニュースは OSS コミュニティ全体に波及しました。

GitHub — ようやく整ったメンテナー向けコントロール

メンテナーの離脱と悲鳴を受けて、GitHub も 2026 年 2 月、OSPO ディレクター Ashley Wolf 氏のブログ “Welcome to the Eternal September of open source” を通じて「オープン・バイ・デフォルト」から「防御的ガバナンス」へのシフトを公に認めました。

実装された機能は次のとおりです。

• 特定リポジトリで PR 機能を完全に無効化するオプション
• 「コラボレーターのみ PR 作成可能」とする制限
• contribution guidelines を issue / PR 入力時にピン留め表示
• 一時的なインタラクション制限
• クローズされた PR をアーカイブして公衆の目から隠す機能、UI からの PR 完全削除（GitHub Community discussion #185387、#187038）

「criteria-based gating」（linked issue や Vouch を要求する）や、GitHub Models ベースの AI トリアージワークフロー（gh-aw）も検討されています。一方、The Register や devclass.com は、Microsoft が Copilot 普及の最大の受益者である立場と、ここで AI を原因として名指ししない姿勢のギャップを批判しています。

OpenSSF などのコミュニティ標準の動き

個別プロジェクトの対応と並行して、標準化の議論も進んでいます。

• OpenSSF Vulnerability Disclosures WG の Issue #178: 「AI-SLOP: Develop best current practises for Open Source maintainers」というタイトルでベストプラクティス文書とテンプレートの整備を進めている。
• chaoss/wg-ai-alignment と melissawm/open-source-ai-contribution-policies: 63 件以上の AI 貢献ポリシーをカタログ化（2026 年初頭時点で 14 件がハード禁止、約 33% が開示義務付き、12 件は未決）。
• Linux Foundation のジェネレーティブ AI ガイダンス: ライセンス互換性中心の整理。

Apache Software Foundation は 2023 年時点で著作権確認と Generated-by: タグでの開示を求める permissive な方針を公開しており、Apache Airflow は PMC メンバーの Jarek Potiuk 氏が issue 流入量の倍増を Scale AI の Outlier プラットフォーム経由の組織的投稿に紐づけた（The New Stack の解説）ことを受け、個別の anti-slop ツールで補強しています。Hono の作者 Yusuke Wada 氏が Zenn に書いた “OSSにおけるAI Slop問題の何が問題なのか？” は、日本のエコシステムでも同種の議論が立ち上がっていることを示しています。

自社プロジェクトに当てはめるための整理

CTO として自社で OSS を運営している、あるいは自社の派生プロジェクトで AI 貢献の扱いに迷っている、という立場から事例を見直すと、次の観点で類型を選ぶのが現実的です。

観点	選択肢	適している状況
ライセンス整合性	全面禁止（NetBSD / QEMU 型）	コードベースが GPL 系で、AI 学習データの互換性が問題になる場合
バウンティハンティング耐性	バウンティ廃止、PVR 化（curl 型）	セキュリティ報告経路に金銭インセンティブがある場合
中規模メンテナーチーム	Human-in-the-Loop + 開示（Linux / LLVM / Fedora 型）	AI のプロダクティビティを活かしつつ責任は人間に置きたい場合
単独またはミニチームの維持	入口閉鎖（Ghostty / tldraw 型）	レビュー帯域が逼迫し、メンテナーの burnout が起きている場合
テンプレート整備からの段階導入	NewPipe / typescript-eslint / llama.cpp 型	まだ Slop の物量は深刻ではないが、予防的に運用ガードを入れたい場合

実装するうえでの推奨は以下です。

1. CONTRIBUTING に短い AI ポリシーを追加する: typescript-eslint のように「AI 利用自体は禁じないが、AI なしで説明できること」「テンプレを壊さないこと」「説明文を自分の言葉で書くこと」を明記するだけでも、低コストでノイズを減らせます。
2. issue / PR テンプレートに self-declaration を入れる: NewPipe の「この内容は AI 生成ではない」というチェックボックスは、強制力は弱くても triage 時の判断材料になります。
3. 本文系の AI 利用も明示的に扱う: コードよりも PR description、issue 本文、Discussions のノイズの方が triage を妨げます。llama.cpp が 2 月にここを禁止したのは、運用上の漏れを発見した結果でした。
4. 限界が見えてきたら入口を閉じる: Ghostty の vouch 制や tldraw の外部 PR 自動クローズは強い手段ですが、メンテナーが「will to live」を失う前に取れる現実的な選択肢です。
5. 執行可能性を伴わせる: Ghostty の denouncement system、llama.cpp の BAN 明示、tldraw の auto-close、NewPipe の template checkbox はいずれも、「お願い」で終わらないために具体的な enforcement を伴っています。

最後に、政策設計の上位レベルで踏まえておくべき視点として、Stenberg 氏の整理がよく効きます。AI そのものは脅威でも救世主でもなく、「専門家が使いこなした AI（ZeroPath による curl の 100 件超の実バグ発掘）」と「未検証の出力を投げ込むだけの行為」を区別できるかどうかが、ガバナンスの分岐点です。OSS のオープンな貢献というモデルは死んでいません。しかし、AI が「コードを書く」コストをほぼゼロまで押し下げたいま、価値の源泉は 「設計意図の理解、長期的なメンテナンスへのコミットメント、特定ユースケースでの深い文脈の提供」 という、AI には代替できない部分に移っています。コントリビュート方針の書き換えは、その価値再定義に組織として向き合うための具体的な手段だと言えます。

以上、OSS のコントリビュートポリシーが AI Slop でどう変わったのか、現場からお送りしました。