プロフィール写真

中央大学 国際情報学部 教授

飯尾 淳

博士(工学)。NPO法人オープンソースソフトウェア協会(OSSAJ)理事。1970年、岐阜市生まれ。1994年に東京大学大学院工学系研究科計数工学専攻の修士課程を修了し、同年、三菱総合研究所に入社。情報技術研究センター主席研究員などを経て、2013年に中央大学へ。2019年より現職。

curlは低品質なAI製バグ報告の急増を理由にバグバウンティを一時停止し、ゲームエンジンのGodotは「slopなPRは自動的に却下する」と明言——AIが書いた低品質なコードやバグ報告が大量に送られてくる「AI SLOP問題」によって、ここ1〜2年でOSS開発の世界に変化が起きています 1

OSSは本来、さまざまな人の手で支えられてきた開発のかたちです。そこにAIが加わったことは、OSSという開発のあり方にとって何を意味するのか。そして、この課題はどう解かれるべきなのでしょうか。

四半世紀にわたってOSSの世界に関わってきた、中央大学教授でオープンソースソフトウェア協会(OSSAJ)理事の飯尾淳さんに取材してみると、「AI SLOPは、OSSコミュニティーにおける組織マネジメントの問題」であり、「AIは、AI SLOPという新しい課題を引き起こしている一方で、10年来の課題解決に役立つかもしれない」という答え。

OSSコミュニティーのあり方とそれが抱える課題、そしてAIがもたらす功と罪とは何なのか。同氏にお話を伺いました。

AI SLOP問題の根本原因はAIか人間か、それとも?

――低品質なパッチなどが送られてくることでOSS開発者を困らせるAI SLOP。この根本的な原因はなんだと思いますか?

飯尾:AIを使うことで、PRやパッチを出すのが簡単になりましたよね。しかし、私自身も開発のためにAIを使うなかで、「なかなか本質的な提案をしてくれない」「一見それらしいコードを書くけれども、なんとなく動いているように見えるだけのことが多い」と感じています。そこはAIを使ううえでの懸念点のひとつだと考えています。

ただ、AI SLOPの根本的な原因は、そこではないのではないかと思います。

――というのは?

飯尾:OSSに対して、低品質なパッチが送られてくる。こういったことはAI以前から起こっていました。もちろんその対処には相応の手間がかかりますが、特に問題視されるような感じではなかったかと。「初心者がおかしなことをしていても邪険に扱うのではなく、ちゃんと向き合って育てていきましょう」という考え方をするのがOSSの文化だと思います。

しかし、ここにはAI以前は「このような出来事があまり多くなくて、十分対処できた」という側面もあると思います。

思うに、AI SLOPの厄介さはDoS攻撃に近いのではないでしょうか。1つ2つなら個別に対応できても、大量に来られるとどうしようもなくなる。AIの出力の「質」というより、AIがもたらす「量」の問題かと思います。

――では、「AIを使う人間が悪い」という捉え方でしょうか?

飯尾:そのような一面的な見方も、適切ではないと思います。

AI SLOPを起こす人の動機はいろいろ考えられます。「勢いがあり注目されているプロジェクトで少し目立ちたい」という程度の、悪意があるとまでは言えない人もいるでしょう。あるいは、「本当に善意から支援したいと思ったのだけれども、スキルがないのでAIに頼って結果として低品質なものを送ってしまう」という人もいるはずです。

大前提として、コントリビューションが多いこと自体は決して悪いことではないし、AI SLOPは工夫すれば十分対処可能な課題だというのが、私の考えです。そのうえで、「AI SLOPが問題化してしまう根本的な原因」は、OSSコミュニティーにおける組織のあり方や、組織マネジメントにあると捉えています。

OSSコミュニティーという「開かれた開発組織」の弱点

――そもそもOSSコミュニティーには、どのような特徴があるのでしょうか?

飯尾:まず、OSSの成り立ちからお話します。2

2000年以前のソフトウェア業界では、「ソースコードは秘匿するもの」という考え方が一般的でした。コンパイル後のバイナリーは販売するけれども、ソースコード自体は知的財産として外には出さない。リバースエンジニアリングも禁止する。以前はそれが常識だったんです。

OSSはそれをひっくり返して、ソースコードをみんなでシェアして発展させた。今ではこちらのほうが一般的で、ソースコード以外のところで付加価値を付けるビジネスモデルも広まりました。

私がOSSに関わりはじめたのも2000年前後で、初めて公開したのは2万行ほどのCの動画処理ライブラリでした。Linux、NetBSD、FreeBSDの3つに対応していたのですが、あるとき「Solarisに移植しました」という人が現れ、「公開していると、こんな良いことがあるんだな」と感じた覚えがあります。

OSS開発はこんなふうに誰でも参加できるのが特徴で、いろいろな人がPRやパッチを送って貢献できます。このコミュニティーの原理原則から考えれば、コントリビューションが増えること自体は良いことで、開発には自発的にどんどん参加するのが望ましいはずです。

しかし、OSSコミュニティーでは、ボランティア的に開発に関わっている人がほとんどで、割くことができる労力に限りがあります。そんな中で、AI SLOPのような出来事に直面すると「もう勘弁してくれ」という気持ちになるのも、もっともだと思います。

こういったときに、何かしらの手が打てれば問題ないのです。「閾値を定めて、合致しないPRは自動的に排除する」や「”誰でも開発に参加できる”ではなく、会員制に近いかたちで運営する」など、方法はいろいろ考えられるでしょう。

――手が打てれば問題ない。しかし、それが難しい事情があるのでしょうか?

飯尾:例えば、Linuxのような大規模コミュニティーならば、AI SLOPのような問題が起こっても、何らかの判断やルールを下すことで対処できると思います。大企業から開発者が送り込まれていて、リーナス・トーバルズをトップとする意思決定の仕組みが長年にわたって培われているはずですから。

――実際、Linuxカーネルでは2025年に、AI支援での開発についての公式ガイドラインが整備されましたね 3 。成熟したコミュニティーであれば、自分たちでルールを更新していける。

飯尾:しかしそういった、組織として成熟していくためのノウハウがわかる”教科書”のようなものが、残念ながらOSSコミュニティーには乏しい、というのが難点です。

企業にはあるのです。創業者数人のスタートアップ企業から大企業に成長していくまでの間には、組織内でさまざまな問題が発生しますが、その時々で参照できる”組織マネジメントの標準的な教科書”のようなものが。

――開かれたコミュニティーを形成するOSSの世界には、“組織マネジメントの教科書”がない。このような開発のあり方を守るために必要なことはなんでしょうか?

飯尾:「ソフトウェアの裏側には必ず人がいる」という意識ではないでしょうか。OSS開発も、最終的には人と人とのコミュニケーションなので、誠実さが大切です。

それから、AIはツールであるという意識。AIはコードを書いてくれますし、私も「チャッピーくん」と呼んだりしますが、人間ではありません。そこは履き違えずに、向き合うべき相手と向き合う必要があると思います。

それでも、AIはOSSにとって悪いものではない

――AIと、OSSの開発体制。ここまでのお話だと相性が悪いようにも聞こえますが、飯尾先生はどう捉えていますか?

飯尾:いや、私はむしろ「AIはOSSにおける10年来の課題を解決してくれるかもしれない存在」として前向きに捉えています。

――それはどんな課題でしょうか?

飯尾:若者の参加が少ないことです。OSSは、インフラ周りやサーバーサイドと親和性が高いのですが、そういった領域は面白みが玄人好みでどうしても地味なんですよね。私が関わるOSSAJ(オープンソースソフトウェア協会)の人たちを見ても、年齢層がかなり高いですね。

2010年あたりでしょうか、JavaScriptのユーザーが増えたころに、Web系のテックイベントに行ったら700〜800人くらい若い人が集まっていて、「活況でうらやましいな」と思ったものです。

――OSS開発は今や当たり前。しかし世代交代が進んでいない、と。

飯尾:しかし、AIのおかげでOSSに貢献するハードルは確実に下がっています。下がっているからこそ、AI SLOPのような問題が出てきた、とも言えるかもしれません。

AIの進化を良い機会と捉えてどんどんコントリビュートしてほしい、企業もOSSにフリーライドするのではなく、開発に貢献してほしい、と思っています。

でも、無理に背伸びする必要はありません。よく分からないけれどAIが書いてくれたからそのまま送りつける、というようなことをしてしまうとAI SLOPになりますから。

コントリビューションの対象は、コードだけではありません。バグレポートを送る、ドキュメントを改善するなど、自分のスキルの範囲内でできることをすればいいのです。

取材・執筆:川島 昌樹
編集:川島 昌樹、田村 今人


  1. AI SLOPをめぐる主な出来事——curlは低品質なAI製バグ報告の急増を理由に、2026年1月末でHackerOne上のバグバウンティをいったん終了した(確認に至る報告の割合が15%超から5%未満に低下したという。なお同年3月に運用を見直して再開)。ゲームエンジンのGodotは「slop PRは自動的に却下する」と方針を明示し、ターミナルエミュレーターのGhostty(Mitchell Hashimoto氏)はドライブバイのAI製PRを問答無用でクローズ、tldrawは外部からのPRを自動クローズに切り替えた。Pythonのプロジェクト共同体Jazzbandは2026年3月、AI生成スパムの量に耐えきれず解散。GitHub自身も2026年2月、プルリクエストを無効化できる“キルスイッチ”機能で対応している。
  2. 背景として、ストールマンらによるフリーソフトウェア(FS)運動とその考え方が大きな影響を与えているが、本稿では割愛する。
  3. Linuxカーネルコミュニティーは2025年以降、AIの利用自体は禁じないスタンスを取りつつ、AI/ツール生成物への対応を段階的に進めている。公式ドキュメント「AI Coding Assistants」を整備してAIの関与を Assisted-by タグで開示させ(DCOを認証する Signed-off-by は人間のみが付与)、2026年春には「Kernel Guidelines for Tool-Generated Content」を正式化して、変更履歴での開示・メンテナーの裁量・投稿者の全責任を定めた。いずれも数か月の議論を経たもので、最終的な責任は人間が負うという原則は一貫している。出典: AI Coding AssistantsKernel Guidelines for Tool-Generated Content