ハクソク

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

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

46日前原文(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 しろ。」
└
LLMはすでにそのPRの投稿者の脳をrm -rfしてしまったよ…
最近、仕事で悩んでたことがあったんだ。ちょっとしたTODOや機能リクエストを解決する変更を作ったんだけど、それを完全にAIで作ったんだ。読んでみたら、全てが理解できたし、テストも削除されてなかったし、新しいテストも追加されてたけど、コードベースを十分に理解してないから、その変更の正しさを評価できる自信がなかった。ちゃんとしたエンジニアリングをしたいし、適当なものは作りたくないけど、1分のプロンプト、5分の整理、30分のレビューで、2日分のエンジニアリング時間を節約できるかもしれない。それは何かの価値があるはず。いくつかの進め方が見えたんだ： - やめて、代わりに機能リクエストを出して、diffをオプションのインスピレーションとして含める。 - 出すけど、AIから来たもので、動くかわからないから、レビュアーに特に注意してもらうように頼む。 - それとも普通に出す、テストやリンターを通ってるから、著者や出所に関係なくレビューは同じであるべきだ。これをいくつかのチャットグループに投稿したら、いろんな意見が出てきた。メンテナーの好みによってアプローチが変わる意見もあったし、(1)に対する強い意見、(2)に対する弱い好み、(3)を支持する人もいた。面白いことに、AI支持の人たちはほぼ全員、もっとAIを使って自信をつけるべきだと言ってた。「どうやってテストするか、どうやって確認するか」とかを聞いて、自信を高めるべきだって。これは面白いアイデアだと思って、もっと自信を得る方法を探るためにさらに1時間くらいプロンプトを考えたんだけど、その間にAIが「改善」するためにたくさんのことを「修正」して、結局その変更に対する自信を完全に失っちゃった。必要なこととそうでないことが明確にあったから、それを分けるのは最初からやり直すよりもずっと大変だと思った。だから、選択肢1にして、diffは含めなかった。
└
ライブラリ使ってる？使ってるなら、パッチを当てた状態で本番かステージングでテストしてからレビューを提出してね。
└
> でも、コードベースを十分に理解してないから、その変更の正しさを評価できる自信がなかった。良いエンジニアリングのアプローチは、変更が正しいかどうかを確認することだよ。AIにもっとプロンプトを与えても意味ないから、コードで遊んでみたり、壊そうとしたり、自分でテストを書いてみて。
└
他のことはともかく、君は良いエンジニアリングの直感を持ってるし、業界にもっと君みたいな人が増えてほしいな。
└
> 面白いことに、AI推進派の人たちはほぼ全員が強気になって、もっとAIを使って自信をつけるべきだと言ったんだ。どうやってテストするか、どうやって確認するかを聞いて、自信を高めるべきだって。レビューのやり方を変えるんじゃなくてね。これはいい提案だと思うし、普段俺もそうしてる。もし職場でClaudeが何かを生成して、それを完全には理解できていない場合、実験的にテストして期待通りに動くなら、「なんでこれを入れたの？これは何のための構造なの？このエッジケースにはどう対処するの？」って聞いて、具体的に何も変更しないように言うんだ。そうすることで、その出力を「人間のスピード」で処理して、自分のものにできる。
└
全く公平に言うと、「なんとか動いてるけど、問題を解決してるだけで、コードベース全体にはあまり良くない」PRも人間のやることだよね。問題はAIがそれを大量に生成することで、正直言ってほとんどの人は、最初の段落に書かれているような努力を全くせず、読んですらいないものを盲目的に押し出してるってこと。> 面白いことに、AI推進派の人たちはほぼ全員が強気になって、もっとAIを使って自信をつけるべきだと言ったんだ。まあ、コードベースの把握には悪くないけど、最も生産的に使えたのは「ターボグレップ」として既存のコードベースを見回して、物事を理解することだった。
└
もしLLMが生成した変更が、実装したい機能のコードベースにあった場合、そしてその機能の実装をできるだけ早く進めたいけど、メンテナーを尊重し疎外しないようにしたいなら、次のことをやるといいよ: 1. すべての変更を確認して、何が変わったのか、どう問題を解決するのかを理解する。2. その理解をもとに、手書きでその機能を実装するために何ができるか（そしてその理由）を高レベルでまとめる。3. 通常の機能リクエストを書いて、その要約を付け加える（付録として）。最近、いくつかのLLM生成のPRと部分的にLLM生成の問題の説明を受け取ったことがあって、どちらも少し時間の無駄だった。PRで最悪なのは、変更を見ながら提出者と良い信頼関係で、簡潔で迅速な「なぜ」の議論ができないこと。あと、PRが大規模な既存のパターンに気づかず、全く新しいものを書いてしまうと、メンタルオーバーヘッドを減らすために従いたいパターンを無視しなきゃいけなくなるから、捨てざるを得ない。問題や機能リクエストについては、提出者が自分に役立つと思った「調査」があったけど、少し誤解を招く結果になったし、同時に人々がその内容を書くのに同じくらいの努力をかけることを望んでいることに気づいた。ただ、今はその努力の一部がLLMとのやり取りに使われている。だから、彼らには人間の視点から問題を説明することに集中してほしいと頼んだんだ。もし彼らが余分な時間とエネルギーを持っているなら、それをもっとそちらに注いでほしい。もし職場で起こったら、当然俺はこれを処理するために給料をもらってるけど、俺のリクエストを無視する人からの提出は優先順位を下げざるを得ない。
└
> コードベースを十分に理解しているとは思えなかったから、変更の正しさを評価するのは難しかった。 > 良いエンジニアリングをしたいし、雑なものは作りたくない。でも、1分のプロンプト、5分の整理、30分のレビューで、2日分のエンジニアリング時間を節約できるかもしれない。 "2日分のエンジニアリング時間"ってどこから来るのか、よくわからない。コードベースを知っている人が「1分のプロンプト、5分の整理、30分のレビュー」をして、変更が意味を持つかどうかを理解できない理由は何なの？もっと一般的な質問だけど、なんでこんなに多くのスロップポスターが、自分だけがgenAIツールにアクセスできるかのように振る舞うの？信じて、私もこの手のものにはアクセスできるから、LLMのスロップを読みたいなら、自分でプロンプトを出せばいいだけ。わざわざ送ってもらう必要はないよ。関連リンク: https://claytonwramsey.com/blog/prompt/ (hnのディスカッション: https://news.ycombinator.com/item?id=43888803 )
ちょっと聞いてもいい？なんで人々はそもそもこれをやってるの？エージェントにコードをレビューさせてプルリクエストを作らせる動機は何なの？
└
俺の予想だけど、履歴書に載せて、仕事を得るための助けになると期待してるんじゃないかな。
└
TFAからの引用: 「...githubで緑の四角を稼ぐために厳密に設計された出力、根拠のないバグバウンティを生み出し、スプリントの速度を人工的に膨らませ、企業のKPIメトリクスに悪意を持って従う。」
この方針が好きだな: https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.m... > 「自分の変更が何をしているのか、AIツールなしで大きなシステムとどう関わっているのか説明できないなら、このプロジェクトに貢献しないでください。」追記: この引用を追加したよ。
これはただの面白いブログ記事だね。AIを使って低労力のPRを提出する人たちは、これを読むことはないだろう。私がやってることをやってみて: 1. PRをクローズ 2. PRが極端に低労力ならユーザーをブロック 最後に受け取ったPRは、文字列を定義するのに '' の代わりに ‘’ を使ってた。CIが全部失敗した。即座に牢屋行き。