RFC 406i — AIが生成したゴミのような貢献を拒否する（RAGS）標準プロトコル

 (406.fail)
10 ポイント 投稿者 GN⁺ 2026-03-08 | 1件のコメント | WhatsAppで共有
  • オープンソースのリポジトリやコミュニティなどで、AIが生成した低品質な貢献を自動拒否するための標準プロトコルを、ユーモラスなRFC形式で定義した文書
  • プロジェクトのメンテナーが当該URIを貼り付けるだけで、**「AIスロップ（slop）検知」**の拒否シグナルを伝える標準化された手段として機能
  • AI生成の貢献物に典型的な特徴の一覧を挙げ、保守リソースの浪費と未検証出力の危険性を率直に指摘
  • LLMベースの提出物がテストを通過し文法的に正しくても、論理やアーキテクチャの理解がなければ根本的に無価値だという立場を明確にする
  • RFC形式を借りた風刺文書だが、オープンソース生態系におけるAI自動化貢献の乱用に対するメンテナーたちの実際の疲弊を反映

Abstract - この文書の目的

  • ソースコードリポジトリ、イシュートラッカー、脆弱性報告ポータル、コミュニティフォーラムに提出される低労力・AI生成の貢献物の処理および廃棄の標準プロトコル
  • 公開オープンソースプロジェクトと社内企業システムの両方に適用

1. Introduction - なぜこのページに案内されたのか

  • あなたの貢献物が自動または手動のAIスロップ検知システムを作動させたため、このページに案内された
  • 具体的には、メンテナーまたはシニアエンジニアが提出物を見て「深遠で実存的なため息」をついた後、即座に接続を終了し、このURIを貼り付けた
  • この文書で使われる"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL"というキーワードは、**「私たちがこの提出物をどれほど読みたくないか」**の尺度として解釈すること

2. Diagnostic Analysis - あなたの提出物から検出された特徴

  • 提出された資料の語彙および構造分析の結果、あなたのプロンプトエンジニアリングは誤っており、その結果あなたは自らを恥じるべきだという結論に至った
  • 確率論的オウムにPR・脆弱性公開・Issueコメント・フォーラム投稿を代筆させた結果、それは私たち全員に嘘をついた
  • 次の特徴が圧倒的に明白な形で検出された:
    • 過度に丁寧でロボット的な文体の使用
    • 高い確信をもって提示されたまったく存在しないAPIの混入
    • 実際の問題をひとつも解決しない肥大化したボイラープレートコード
    • PR説明で"delve"を大真面目に使用
    • docstring、コメント、またはセキュリティレポートの中に"Certainly! Here is the revised output:"のようなLLM出力の残骸がそのまま残っている
    • 単純なタイプミス修正に600語のコミットメッセージまたは巨大な理論エッセイを添付
    • utils.helpersのような存在しない幻覚ライブラリをimport
    • 軽微なバグ報告に"In conclusion, this robust and scalable solution..."で始まる締めの段落を追加
    • カフェインと睡眠不足で動く人間のプログラマには到底達成できない奇妙で無菌的な変数名・関数名
    • 実際のシステムアーキテクチャや脅威モデルの理解なしに、regexや幻覚的概念に全面依存
    • "fix this"または"find a bug"というプロンプトに対し、無関係な大規模コンテキストブロックを盲目的に貼り付けた痕跡
    • コミット履歴でコンパイラに謝罪している
  • 自動化ゴミの基本定理に従い、あなたが読んでいないのだから、私たちも読まない

3. The Asymmetry of Effort - 労力の非対称性

  • プロジェクトのメンテナー、セキュリティトリアージチーム、コミュニティモデレーターは、無給のボランティアであれ疲れ切った社内同僚であれ、厳しいリソース制約の下で運営されている
  • あなたの提出物のトランザクション記録を確認すると:
    • a. 第一印象では賢そうに見えたか? - たぶん
    • b. 検証済みで再現可能な問題を実際に解決したか? - いいえ
    • c. 人間のレビュアーの有限な時間を浪費しようとしたか? - はい
  • プロジェクトトラッカー・フォーラム・リポジトリは、GitHubの草埋め、根拠のないバグバウンティ集め、スプリント速度の人為的な水増し、あるいは企業KPI指標への悪意ある準拠のために、未検証のコピペ出力を捨てるゴミ箱ではない
  • あなたの同僚は無料のLLM検証サービスではない

4. Resolution Protocol - 回復手順

  • 書き込み権限の回復と同僚の信頼を取り戻すため、以下の手順を順番に実行しなければならない:
    • 1. 当該提出物を生成したローカルブランチ、テキストファイル、または幻覚的な脆弱性スクリプトにrm -rfを実行
    • 2. 生体脳のハードリブートを実施
    • 3. 実際のコードベース、プロジェクト文書、または脅威モデルを読み、自分の作業状態と論理を手作業で検証
    • 4. 検証可能な意識を獲得し、人間の指で直接タイプする準備が整うまで戻ってこないこと

5. Security Considerations

  • 状態: 拒否済み
  • 診断: トレンチコートの中に隠れた雑に書かれたPythonスクリプトで稼働中
  • 措置: 接続終了

6. Punitive Actions - 懲罰措置およびアカウント降格

  • AI生成スロップ提出の結果として、あなたのアカウントは自動的に**Trough of Sorrow™（悲しみの飼い葉桶）**へ移され、保護観察期間中は以下の制限が適用される場合がある:
    • リポジトリ権限がWRITEからWISHFUL_THINKINGへ強制的にダウングレード
    • 今後のすべてのPRは、シアンリボンが永久に切れたドットマトリクスプリンタに接続された14.4kボーのダイヤルアップモデム経由でルーティング
    • git push -fを入力するとrm -rf /を実行し、悲しいトロンボーン音を再生するようgit aliasを再マッピング
    • IDEのデフォルトフォントが7pt Comic Sansに永久固定
  • システム管理者への連絡は不可 - 管理者は現在、個人Slackチャンネルであなたを笑っている

7. FAQ

  • "いったい何を言っているんだ?": 要するに、機械があなたの提出物を書き、機械が今その提出物を拒否している。あなたはこのやり取りにおいて完全に不要な**肉ベースの仲介者（meat-based middleman）**にすぎない
  • "コードはコンパイルできます / 報告は詳細です / 文法は正しいです": 整った脅迫状でもそれは可能。文法と構文は貢献の最低基準であって上限ではない。あなたの論理は依然として幻覚的な熱病の夢（hallucinated fever dream）だ
  • "AIは技術の未来です": この提出物が未来を代表するのなら、こちらは喜んで農耕社会への移行を加速させる
  • "役に立とうとしました": あなたの「助け」は今や、丁寧な挨拶で包んだローカルDoS攻撃に近い。本当に役に立ちたいなら、生成エネルギーを自分で所有し保守しているリポジトリに向けること
  • "AIが書いた証拠はありません": 人間の無能さは物理法則と怠惰によって制限される。あなたの提出物は、ギガワット級の電力を燃やすサーバーファームだけが生み出せるレベルの自信満々で文法的に完璧な狂気に達している
  • "CI/CDが通り、テストはグリーンです": あなたの生成モデルがTrue == Trueだけを主張するようテストスイートを書き換えてくれたからだ
  • "誤りを指摘してくれれば学びます": 不可。メンテナーはあなたのLLMデバッグループのためのリバースプロキシではない。フィードバックが必要なら、この事態を作ったそのチャットウィンドウにスタックトレースを貼り直すこと
  • "GitHubの草が必要です": 緑のホワイトボードマーカーを買って、モニターに直接描くことを勧める。私たちの時間をはるかに消費せず、それでいて将来の雇用主から同程度の職業的敬意を得られる
  • "オープンソースメンテナーの役割は歓迎的なコミュニティを作ることではないのですか": 役割はソフトウェアを保守することだ。「歓迎」は、実際に思考を提供する意識ある存在に適用されるのであって、Issueトラッカーで確率論的な反芻を行う自律ボットネットには適用されない
  • "このメッセージは不快です": 良い反応だ。LLMに合わせて共感的な謝罪文を生成させるとよい。現在、同情の在庫は切れており、感情サポートSLAは99年だ
  • "管理者にこの敵意を報告します": すでに予測済みで、あなたの好みのLLMが生成した800語の辞職届をHRに送付してある。"delve"が6回使われ、管理者の「相乗的パラダイム」を称賛する内容だ
  • "Code of Conduct違反です": CoCは人間の貢献者を保護する。分析によれば、あなたは現在OpenAI APIキーを包んだ薄い肉の殻として動作している。権利は恥を感じられる炭素ベース存在に留保される
  • "異議申し立てはできますか": できる。すべての異議申し立ては/dev/nullへ直接ルーティングされる。あなたが自分の提出物に払ったのとまったく同じ注意水準で監視中だ
  • "謝罪して正す方法はありますか": ある。元のPRを厚手の紙に印刷し、鋭い紙の鶴に折って丁重に食べること。そこでようやく癒やしが始まる

Appendix A - エスカレーション経路

  • RFC 406iの反復違反時には、リポジトリ・プロジェクト・ツールその他のアクセス権を全面取り消し
  • MACアドレスのブラックリスト登録
  • メールアドレスを攻撃的に複雑なregexチュートリアル日刊ダイジェストへ強制購読登録
  • よい一日を。

Appendix B - 標準化された拒否マクロ

メンテナーおよびレビュアーが即座にコピー＆ペーストできる標準拒否文:

  • PR / MR:
    • PR closed. あなたのdiffは、コンテキストウィンドウを失った予測テキストのマトリクスのように読める。私たちが求めているのは、自動化された当てずっぽうゲームではなく、手作業による炭素ベースのテストと実際の論理的一貫性だ。参照: https://406.fail
    • PR closed. Your diff reads like a predictive text matrix that lost its context window. We require manual, carbon-based testing and actual logical continuity, not automated guessing games. See: https://406.fail
  • Issue / バグレポート:
    • Issue closed. この報告のtemperatureパラメータは高すぎる。私たちが必要としているのは、検証可能なバグを説明できない整然とした生成エッセイではなく、意識あるユーザーによる生の再現可能なスタックトレースだ。参照: https://406.fail
    • Issue closed. The temperature parameter on this report is set too high. We require raw, reproducible stack traces from a sentient user, not a neatly formatted generative essay that fails to describe a verifiable bug. Protocol at: https://406.fail
  • セキュリティ / バグバウンティ:
    • Report rejected. 基本的なリンター警告をLLMに投入して破滅的な脅威シナリオを生成することは、有効な脆弱性開示には当たらない。私たちは計算コストの高い合成パニックに対して報奨金を支払わない。参照: https://406.fail
    • Report rejected. Feeding basic linter warnings into an LLM to generate a catastrophic threat narrative does not constitute a valid vulnerability disclosure. We do not pay bounties for computationally expensive, synthetic panic. Refer to: https://406.fail
  • メーリングリスト / ディスカッションフォーラム:
    • Thread locked. このコミュニティは、あなたの未整合なプロンプト実験のための強化学習サンドボックスではない。自分自身の認知負荷を使って質問を書けるようになってから戻ってくること。参照: https://406.fail
    • Thread locked. This community is not a reinforcement learning sandbox for your unaligned prompt experiments. Please return when you can author a question using your own cognitive load. Diagnostics: https://406.fail

関連記事

1件のコメント

 
GN⁺ 2026-03-08
Hacker Newsのコメント

  • 本当に役に立ちたいなら、自分で実際に所有し、メンテナンスしているリポジトリにそのエネルギーを注ぐべきだと思う
    みんなもこういう習慣を身につけるべきだ。フォークを公開するのは簡単になったが、自分で実際に使っていないコードを他人が使ってくれると期待すべきではない
    GitHubで1日にいくつのプロジェクトにPRを送っているかの統計を見ると、99%は1件、1%は2件、0.1%は3件だ。5件以上PRを送るアカウントはほぼすべてボットかスクリプトだった。未登録のボットにはレート制限をかけるべきだ

    • こういう状況なら、私のフォークが元のリポジトリの上に定期的にrebaseされる恒久パッチモードのような機能があるといい。たとえば1行だけの修正でも自動で最新化されるようなもの

  • 私は GhosttyのAIポリシー のほうが好みだ
    「AIの助けなしに変更点が何をするのか、そしてシステム全体にどんな影響を与えるのかを説明できないなら、このプロジェクトに貢献するな」という一文が特に気に入っている

    • いいアイデアではあるが、どう実施するかが問題だ。AIに説明させて、それを自分の言葉で書き直せば実質的に回避できてしまう

  • オープンソースへの貢献が一種の通過儀礼になってしまったのが問題だと思う
    本当の貢献よりも「貢献したという事実」が重要になると、こういう浅いPRが生まれる。以前は脆弱性報告も似たようなものだった — 「nullを入れるとNullPointerExceptionが出ます」程度の報告だ
    開発速度のような誤った指標を重視するのも問題だ。前の会社でAIで高速開発していると自慢していた同僚のPRを見たら、テストが全部失敗していた。結局はAI支援のゲーミフィケーションなんだ

    • 私も最近、AIで書かれた応募書類をたくさん受け取る。その中にはGitHubでの貢献を強調するものもある。たぶんこういうPRが実際に通ることもあるのだろう。プロジェクトのスター数を採用指標にする文化が、こうしたスパムを助長している
    • 「数学をものすごく速くできる」→「じゃあ137*243は？」→「132,498」→「違うよ」→「でも速かったでしょ」みたいな感じだ

  • これはただ面白半分で書かれたブログ記事だ。AIで低品質なPRを送る人たちは、そもそもこういう文章を読まない
    私のやり方は単純だ:

    1. PRを閉じる
    2. あまりに不誠実ならユーザーをブロックする
      最近では、文字列定義で ‘’ の代わりに '' を使ってCI全体を壊したPRもあった。即ブロックした
    • PRを閉じるとき、このページのリンクをコメントに添えるのがよさそうだ

  • バグなら、修正が確認できる赤い行(diff)があるべきだし、機能なら少なくとも受け入れ基準が必要だ
    ドキュメントなら、読んで理解できれば十分だ。役に立つための基準はかなり低い

  • 「オープンソースのメンテナは歓迎的なコミュニティを作るべきでは？」という問いに対して、それは義務ではない
    メンテナはプロジェクトの所有者であり、親切である必要もない。気に入らないならフォークするか去ればいい

    • こういう主張は実際のところ感情的な操作に近いと思う。「私たちの時間を感情的に浪費させるな、なぜLLMが生成したPRが役に立たないのか理解しろ」と言うほうがいい。こちらもLLMの使い方は知っているし、その後に必要となる実際の作業量がどれほど大きいかも分かっている

  • 本当に痛快だ。こういう記事がいい加減なPR投稿者を恥じ入らせるために広く使われてほしい。FAQの率直で無礼なくらいの口調が、むしろ爽快だ

    • でもそういう人たちは恥を感じない。電話詐欺師に怒るのと同じで、ただ切ってまた次を試すだけだ

  • 会社であった話だ。AIで小さな機能要望を解決するコードを作ったが、コードベースをよく知らなかったので正確さに自信が持てなかった
    1分のプロンプト、5分の整理、30分のレビューで2日分のエンジニアリング時間を節約できるかもしれなかったが、結局は信頼の問題だった
    いろいろ意見を聞いた結果、単に機能要望だけを上げて、diffは含めないことにした。
    興味深いことにAI推進派は「AIをもっと使って自信を高めろ」と助言したが、むしろ修正を重ねるうちにコードがこんがらがって、完全に信頼を失った

    • もしLLMが作ったコードを本当に使いたいなら、すべての変更を理解し、それを自分で要約して機能要望に添えるのがよい
      私もLLMが作ったPRを何度も受け取ったが、会話が成立せず、既存のパターンを無視したコードだったので結局捨てるしかなかった。
      人間なら、自分の視点で問題を説明してほしい。それがずっと役に立つ
    • あなたは優れたエンジニアリング感覚を持っている。業界にこういう人がもっと増えてほしい
    • 「2日分のエンジニアリング時間の節約」というのが理解できない。コードベースを知っている人が同じようにAIを使うこともできるはずだ。なぜAIの出力を他人に検証させようとするのか分からない。こちらだってLLMは使える
      関連記事: Promptingについての文章
    • 私も似たようなやり方をしている。Claudeが作ったコードを完全には理解できないときは、「この部分はなぜこうしたの？」「エッジケースはどう処理されるの？」のような質問を投げて、修正せず説明だけしろと頼む。こうすると結果を自分のものにできる
    • そのライブラリを実際に使っているなら、ステージング環境でテストしてからレビューを提出するとよい

  • 最後の plonk という表現がすごくよかった
    Plonk(Usenet) 参照

    • BOFH Task Forceなら、そのくらい当然できると思っていた

  • 「rm -rfでローカルブランチやたわごとスクリプトを消せ」という一文があまりに面白い
    「有機脳をハードリブートしろ」という表現も完璧だ

    • 実際、LLMはすでにそういうPR投稿者たちの**脳を rm -rf**してしまったように見える