1．「入口を絞る」という発想――GitHub

　GitHubは、生成AIを使って生成したコードやそのプルリクエストの増加そのものを公式に「問題」と定義しているわけではない。しかし、スパム的なプルリクエストや低品質な投稿が増加する傾向を踏まえて、メンテナーの対応負荷が高まっている。

　この状況に対し、OSSプロジェクトの一部では「すべてをレビューで頑張る」のではなく、そもそも“入ってくる量”を制御する運用に踏み切っている。例えば、プルリクエストの作成権限を既存のコラボレーターや承認済みユーザーに限定することで、匿名や大量の投稿を物理的に抑制する手法がある。

　Code Ownersの設定や必須レビューの指定によって、「誰がレビュー責任を持つのか」を明確にし、レビュー対象を機械的に振り分ける取り組みもある。GitHubのワークフロー自動化サービス「GitHub Actions」でactionlintやフォーマットチェックを必須化することで、最低限の品質基準を満たさないプルリクエストは、ユーザーの目に触れる前にふるい落とすことも可能だ。

　GitHub本体は、プルリクエストの分類や優先度付けを支援するトリアージ機能の改善を進めている。メンテナーが「今、どのプルリクエストを見るべきか」を判断しやすくするためだ。

　これを情シスの文脈に置き換えると、「誰でも成果物を持ち込める状態」を前提にしないという考え方に近い。受領時のルール、チェックリストの作成、最低限の自動検証の実施など、成果物の提出前に“入口”を設けることで、情シスの判断負荷を下げる発想だ。

2．「誰が責任を持つのか」を明示する――Vouch

　2026年2月、HashiCorp共同創業者でエンジニアのMitchell Hashimoto氏は、OSSにおける信頼管理をテーマにしたツール「Vouch」を公開した。

　Vouchは、「誰でも自由にプルリクエストできる」というOSSの前提が、生成AIの普及によって揺らぎつつあるという問題意識から生まれた。AIによって大量のコードや説明文を容易に生成できるようになった結果、“善意のコントリビューター”と“責任を持たない大量投稿”を区別することは困難になりつつある。Vouchは、この曖昧さに対し、信頼を暗黙の了解ではなく、明示的に管理する仕組みを持ち込む発想だ。

　具体的には、リポジトリ内に「VOUCHED.txt」と呼ばれるテキストファイルを配置している。信頼済みのコントリビューターを列挙するホワイトリストのようなものだ。この情報をGitHub Actionsと連携させることで、Vouchされていないアカウントからのプルリクエストに対して警告を表示したり、自動的にクローズしたりといった運用が可能になる。

　Vouchには、“信頼の連鎖”を意味する「Web of Trust」という構想もある。これは、あるプロジェクトで信頼されたコントリビューターが、別のプロジェクトでも一定の信用を持って活動できるようにする考え方だ。実際に、コマンドラインインタフェースを通じてコマンドを実行する「ターミナルエミュレータ」（ターミナル）でHashimoto氏が開発した「Ghostty」では、試験的な導入が始まっている。

　この考え方は、情シスにとっても示唆的だ。コードの品質以前に、「誰が責任を持つ成果物なのか」を可視化するためだ。生成AIを使って生成したコードを排除するかどうかという話ではなく、成果物に関する説明責任の所在を明確にする話だ。

3．AI slopを“兆候”として捉えるツール群

　生成AIを使って生成したコード特有の傾向を自動で検知しようとするツールもある。

　その一例が「SlopCannon」だ。GitHubの機能拡張ツール「GitHub Apps」として公開されるもので、プルリクエスト内のコードや説明文を解析し、

• 無難過ぎるキーワードを含む命名
• 文脈と噛み合わないコメント
• それらしいが具体性のない説明文

といった特徴に着目してプルリクエストをスコアリングする。

　コントリビューターの過去の活動履歴やプルリクエストの実績を参照し、「ヒューリスティック（経験に基づいて正解に近い解を導き出すこと）の観点から「信頼度」を評価する「PR Slop Stopper」もある。一定の基準を下回る場合には、レビュー前に警告を出すなど、メンテナーの判断を補助する役割を担う。

　重要なのは、これらのツールが「特定のコードを自動で排除する」ことを目的としていない点だ。狙いは、情シスが本当に注意を払うべき成果物に集中できる状態を作ることにある。

　ただし、これらのツールはPoC（概念実証）の段階にあり、人間のレビューを完全に置き換えるものではないと明示されている。

情シスにとっての本質的な論点

　紹介したツールの論点は、「生成AIを使っているかどうか」ではなく、「その成果物の責任を、誰がどこまで持つか」だ。

　OSSの世界で進む試みは、そのまま情シスの現場にも転用できる。レビューで疲弊する前に、設計で問題を解決する。それが、低品質なコードや成果物の提出を当たり前にしないための現実的な防波堤になる。