ハクソク

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

低労力のAI生成プルリクエストを処理し廃棄するための標準プロトコル

2026年3月6日原文(406.fail)

概要

  • AI生成の低品質な投稿 を自動検出・排除するための標準プロトコルの解説
  • 人間によるレビュー負荷 とリソースの非対称性を強調
  • 機械的・虚偽的な投稿例 とその判定基準を列挙
  • 再投稿・改善のための具体的な手順 を提示
  • FAQや懲罰的措置、定型文 も併記し、ユーモラスかつ厳格に対応

AI生成スロップ拒否プロトコル（RFC 406i）概要

  • AIによる低労力投稿 （スロップ）の排除を目的とした標準プロトコル
  • 対象範囲 ：オープンソース、社内リポジトリ、イシュートラッカー、脆弱性報告、フォーラム等
  • 自動・手動の検出 により、人間レビュワーへの負担軽減を図る
  • 投稿が拒否された場合、本プロトコルURIが送付される流れ

1. はじめに

  • あなたの投稿 がAIスロップ防御機構により検出・拒否された経緯
  • MUST/SHOULD等のRFC用語 は、どれだけレビューしたくないかの度合いとして解釈
  • 人間レビュワーの深いため息 と即時拒否の実態

2. 診断分析

  • 投稿内容の構造・文体分析 によるAI生成の判断
  • 典型的な特徴 ：
    • 過剰に丁寧かつ機械的な表現
    • 存在しないAPIやライブラリの記述
    • 問題解決に寄与しない冗長なボイラープレート
    • 「delve」など不自然な単語の使用
    • 「Certainly! Here is the revised output:」等のAI特有のフレーズ残存
    • 小さな修正に対して過剰な理論展開
    • utils.helpers等、架空のライブラリ導入
    • 「In conclusion, this robust and scalable solution...」で始まる不要なまとめ
    • 完璧すぎる命名や設計、現実離れした構造
    • システム理解不足・正規表現頼みの修正
    • 「fix this」等の雑なプロンプトの貼り付け
    • コミット履歴でコンパイラに謝罪
  • 根本定理 ：「読んでいない投稿は、こちらも読まない」方針

3. 労力の非対称性

  • プロジェクト管理者やレビュワーのリソース制約
  • 投稿の実態 ：
    • 一見賢そうでも本質的解決なし
    • 人間レビュワーの時間浪費を目的
  • GitHub等のトラッカー・フォーラムはAI出力のゴミ箱ではない
  • 他者を無料のLLM検証サービスにしてはならない

4. 解決プロトコル

  • 再投稿・信頼回復のための手順 ：
    • 問題のブランチ・ファイル・スクリプトをrm -rfで完全削除
    • 自身の脳をハードリブート
    • 実際のコード・ドキュメント・脅威モデルの精読と手動検証
    • 人間として自力で内容を理解し、指を動かせる状態 になってから再投稿

5. セキュリティ考慮事項

  • ステータス：REJECTED（拒否）
  • 診断：あなたはトレンチコートを着た不完全なPythonスクリプト
  • アクション：接続終了

6. 懲罰措置・アカウント制限

  • Trough of Sorrow™（悲しみの谷）へ自動移行
  • 制限例 ：
    • リポジトリアクセス権がWRITEからWISHFUL_THINKINGへ降格
    • PRが14.4kモデム経由でドットマトリクスプリンタに出力（シアン切れ）
    • gitエイリアスが改変、git push -fでrm -rf /と悲しいトロンボーン音
    • IDEフォントが7pt Comic Sansに固定
    • シスアドへの問い合わせ禁止（シスアドはSlackで爆笑中）

7. FAQ（よくある質問）

  • Q:「何これ？意味わからん」
    • A: 機械があなたの投稿を作り、機械が拒否した。あなたは不要な仲介者
  • Q:「コードはコンパイル通る／詳細に書いた／文法正しい」
    • A: 人質要求書も文法は正しい。論理が空想レベル
  • Q:「AIは未来！」
    • A: もしこれが未来なら、農業社会へ戻る方がマシ
  • Q:「助けたかっただけ」
    • A: 今の「助け」はDoS攻撃に近い。自分のリポジトリで発揮を推奨
  • Q:「AI投稿と断定できる根拠は？」
    • A: 人間の無能さには物理法則と惰性の限界がある。今回のはAI特有の暴走
  • Q:「CI/CD通った！」
    • A: テストもAIがTrue==Trueしか検証していない。感心しない
  • Q:「具体的な指摘とフィードバックがほしい」
    • A: ここはLLMデバッグのリバースプロキシではない。出力元のチャットに貼り付けて
  • Q:「GitHubのグリーンスクエアが欲しい」
    • A: モニターに緑のマーカーで直接描く方が早いし効果も同じ
  • Q:「オープンソースは歓迎すべきでは？」
    • A: 歓迎は思考する人間に限る。自動化されたスパムは対象外
  • Q:「このメッセージは攻撃的」
    • A: LLMに謝罪文生成を依頼して。共感SLAは99年
  • Q:「マネージャーにエスカレーションする」
    • A: 既にLLMで800語の辞表を生成し、HRに送付済み
  • Q:「Code of Conduct違反では？」
    • A: Code of Conductは人間のため。今あなたはAPIキーを持つ肉のラッパー
  • Q:「再審査できる？」
    • A: /dev/nullに送って。あなたが自分の投稿を読んだのと同じレベルで監視
  • Q:「どう謝罪すればいい？」
    • A: PRを厚紙に印刷し折り鶴にして食べて。そこからが癒しの始まり

付録A：エスカレーションパス

  • 繰り返し違反時の措置 ：
    • リポジトリ・プロジェクト・ツール等のアクセス権剥奪
    • MACアドレスのブラックリスト化
    • メールを高度な正規表現チュートリアルのデイリー配信に登録

付録B：標準拒否マクロ

  • PR/MR用 ：「PRをクローズ。内容が予測テキストの羅列。手動テストと論理的整合性が必要」
  • イシュー/バグ報告用 ：「Issueをクローズ。温度パラメータが高すぎる。再現性あるスタックトレースを要求」
  • セキュリティ/バグバウンティ用 ：「レポート却下。LLMで生成した脅威説明は無効。報奨金対象外」
  • メーリングリスト/フォーラム用 ：「スレッドロック。ここはあなたのプロンプト実験場ではない」
  • サポート・雑談 ：「#406 @ Libera.Chatで日次グループセッション開催」

Hackerたちの意見

バグなら、修正されたことを確認するために赤いラインが必要だよね。機能の追加なら、少なくとも受け入れ基準が欲しい。ドキュメントに関しては、ちゃんと追えるならあんまり気にしないかな。助けに関しては、俺のハードルはめっちゃ低いよ。

すごいね。これがたくさん使われて、手間なしの時間の無駄遣いを恥じるようになればいいな。FAQはぶっきらぼうで、適切に失礼で、めっちゃ好き。

└

そう願ってるのは同じだけど、誰かが恥知らずに雑なPRを出しても、彼らの努力が失敗しても恥ずかしいとは思わないだろうね。電話詐欺師に冷たくするようなもので、彼らはただ切ってまたやるだけだから。

この文書の中の「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」というキーワードは、あなたの提出物をレビューしたくないという気持ちを正確に表しているんだよね。冗談だとはわかってるけど、「shall」が入ってる文書が多いのが本当に嫌だ。解釈が法的に両方の方向に裁定されることもあるから。もっとあいまいでない言葉を使って、「MUST」か「SHOULD」にデフォルトすべきだよ。

└

多くの法的文書では、「may」を使って「しなければならない」と言うんだよね。だから、法律用語が嫌いなんだ…。

└

そうだね。コンピュータ関連の文書にこれらの言葉が出てきたら、RFC 2119やRFC 6919に従って使われているかも言及すべきだと思う。

└

「Must」は厳密な要件で、柔軟性はない。「Shall」は推奨や義務で、やるべきことだよ。車を運転するにはガソリンを入れなきゃいけない。「Shall」は6000マイルごとにオイル交換をするべきだ。

└

1990年頃、データ通信の標準を作るISO/JTC1の会議に参加したことがあるんだけど、イギリスとアメリカの代表団の間でこの言葉を巡って激しい議論があったのを今でも覚えてるよ。（デンマーク出身なんだけどね）特に「shall」と「should」は英語とアメリカ英語で意味が違ってた。ISOの最初の標準、ISO 1ではISO標準は英語で書かれるべきだとされてたから、俺たちもそうしなきゃいけなかったし、アメリカの代表団も同じだった。スコット・ブラドナーもRFC 2219で、今後のIETFの標準にはアメリカの慣習に従うべきだと言ってたから、「shall」という言葉が英語で強い意味を持つのは確かだと思う。ただ、アメリカの法律用語でもそうかは分からないけど。

「もし本当に役に立ちたいなら、あなた自身が所有して維持しているリポジトリに無限の生成エネルギーを向けてください。これは人間が学ぶべき習慣です。フォークを公開するのは今までになく簡単です。自分のコードを本番環境で使っていないなら、他の誰かが使うことを期待しちゃダメです。GitHubにいる誰かが見てるなら、ユーザーが1日にPRする平均的な異なるプロジェクト数の統計を見てみてください（そのユーザーがメンテナーでない場合）。最近のgharchiveの分析では、99%が1、1%が2、0.1%が3でした。5つ以上のリポジトリにPRを出している人はほんとに少なくて、手動でレビューできるくらいでした。みんなボットやスクリプトなんです。未登録のボットにはレート制限をかけてください。」

最後のプランク、いいね。

└

BOFHタスクフォースからは何も期待してなかったけど、やっぱりその通りだね。

「ローカルブランチやテキストファイル、妄想の脆弱性スクリプトに対して rm -rf を実行しろ。」 > 「自分の肉体脳をハードリブートしろ。マジで脳を rm -rf しろ。」

Hacker Newsで議論の続きを見る