情シス部門が“質の低い生成AI成果物”を受領しない仕組みを作る OSSに学ぶ対策は：生成AI時代の「AIスロップ」対策
生成AIの普及で低品質なコード「AIスロップ」が増加している。OSSで進むGitHubやVouchの対策を手がかりに、情シスが成果物受領時に責任と品質を担保する方法を探る。
「とりあえず動くコード」は、今や誰でも生成できる時代になった。生成AI（AI：人工知能）の普及により、専門的なスキルがなくても、それらしく見えるコードや設計説明を短時間で用意できるようになりつつある。この結果、見た目は整っているが、品質や責任の所在が曖昧な成果物が大量に流通する現象が起きている。こうした低品質なAI生成コンテンツの氾濫は「AI slop」と呼ばれる。
この問題は、オープンソースソフトウェア（OSS）の世界だけの話ではない。SIerやベンダー、業務委託先、社内の開発チームからコードを受け取る側である情報システム部門（以下、情シス）にとっても、無視できない現実になりつつある。本稿は、OSSコミュニティで実際に試行されている対策を手がかりに、情シスがコードを受領する際の「防波堤」になり得る考え方とツールを紹介する。
低品質な成果物を受け入れないためには
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の世界で進む試みは、そのまま情シスの現場にも転用できる。レビューで疲弊する前に、設計で問題を解決する。それが、低品質なコードや成果物の提出を当たり前にしないための現実的な防波堤になる。
Copyright © ITmedia, Inc. All Rights Reserved.