PS3エミュレータとして世界的に知られるオープンソースプロジェクト「RPCS3」が、プルリクエスト（PR）への自律型AIエージェントの使用を禁止したと発表した。開発チームのメッセージは「learn to code（コードを書け）」——挑発的とも取れるこの一言は、AIが生み出す低品質コード「AIスロップ」への強い拒絶感を表している。オープンソースの現場で何が起きているのかを読み解いてみたい。
何が問題になったのか——「AIスロップ」とは
AIスロップ（AI Slop）とは、AIが生成したものの、コンテキストの理解が浅く、品質・一貫性・設計哲学などの観点でプロジェクトの基準を満たさない低品質なコードを指す俗語だ。
エミュレータ開発は、ゲームハードウェアの動作を正確に再現する高度な低レベルプログラミングを伴う。PS3のCell Broadband Engineアーキテクチャは特に複雑で、汎用的なAI生成コードが通用するほど単純ではない。RPCS3チームが受け取るPRの中に、明らかにAIが生成したと思われる、プロジェクトのアーキテクチャや設計哲学を無視したコードが混入し始めたことが今回の決断の背景にある。
重要なのは、今回の禁止が「AIツールの全否定」ではないという点だ。RPCS3チームが問題視しているのは「開示なしでの使用」——つまり、AIが書いたコードを自分のものとして黙って提出することへの異議申し立てだ。
なぜこれが重要か——OSSの「門番問題」
この動きが注目されるのは、RPCS3という一プロジェクトの問題にとどまらないからだ。
オープンソースプロジェクトは長年、PRレビューを通じてコード品質を保ってきた。しかし自律型AIエージェントがコントリビューターを「自動化」し始めると、メンテナの負担が急増する。量的な問題だけでなく、質の問題もある——ドメイン知識のないAI生成コードはレビュー工数を多く要するため、「スロップのレビューに時間を取られて本質的な開発が進まない」という逆説的な状況が生まれる。
日本のエンタープライズ開発においても、社内ライブラリや共通基盤をオープンソース的に運用しているチームでは、同様の課題が表面化しつつある。
実務への影響——エンジニアが明日から考えるべきこと
1. AI使用の開示をデフォルトに
コードレビュープロセスにAI生成コードの開示を求めるポリシーを検討する時期に来ている。「このロジックはAI補助で生成しました」という開示があれば、レビュアーは適切なチェックポイントに集中でき、チーム全体の品質管理が効率化される。
2. AIコードの「受け取り方」を設計する
外部コントリビューションを受け入れているリポジトリでは、AIエージェントが送信してきたPRを検知・フィルタリングする仕組みの検討が必要になるかもしれない。GitHub ActionsやBot検出、コードパターン分析ツールが現実的な選択肢になる。
3. 「なぜそう書くのか」を説明できる人材を守る
「AIに任せれば書ける」は短期的には生産性を上げるが、プロジェクト固有の設計哲学の理解なしにコードを量産することは、長期的なリスクを積み上げる。AIを活用しながらも「なぜこう書くのか」を説明できる人材の育成が、今後のチーム運営の鍵になる。
筆者の見解
RPCS3の対応は、少なくとも誠実だと思う。高度に専門化されたドメインでは、汎用AIが生成したコードでは到底通用しない領域がある。その現実を「learn to code」という強いメッセージで示すことには、賛否はあれど一定の合理性がある。
ただ、「禁止」という手段が長期的に機能するかについては懐疑的だ。AIを使ったコードと使っていないコードの区別は技術的にますます困難になっており、禁止ルールを確実に執行する手段が限られる以上、いたちごっこになるだろう。
より持続可能なアプローチは、禁止よりも「使い方の基準を設けること」だと考える。「AIで書いたコードであっても、コントリビューター自身がその内容を理解し、説明できること」をコントリビューションの条件とする方が、現実的かつ建設的ではないか。
AIがコードを書く時代において、エンジニアに求められるのは「AIより速くタイプできること」ではない。AIが書いたコードを批判的に評価し、プロジェクトの文脈に適合させ、責任を持って届けられる能力——これが今後のコントリビューターに必要なスキルセットだ。
OSSコミュニティがこの問いに正面から向き合い始めたことは、業界全体にとって健全なシグナルだと受け止めている。
出典: この記事は RPCS3 says “learn to code” as it bans autonomous AI agents from project の内容をもとに、筆者の見解を加えて独自に執筆したものです。