ハクソク

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

Debian、AI生成の貢献について決定を下さず

50日前原文(lwn.net)

概要

  • DebianコミュニティでAI（特にLLM）生成の貢献物受け入れに関する議論が発生
  • 明確な結論や決定なく、議論は一時的に収束
  • 技術定義、倫理、法的問題など多様な論点が浮上
  • AI利用の透明性や責任、オンボーディング問題が指摘
  • プロジェクトとしての統一見解や方針策定は未達

DebianにおけるAI生成物の受け入れ議論

  • 2024年2月、Lucas NussbaumがAI支援による貢献物の受け入れに関する**General Resolution（GR）**草案を提示
  • 条件付きで「AI支援（LLM生成含む）貢献物」を許容する提案
    • ツール由来部分の明示的開示
    • 「[AI-Generated]」等のラベル付与
    • 提出者が技術的妥当性・セキュリティ・ライセンス遵守等に責任を持つこと
    • 非公開情報や機密情報でのAI利用禁止
  • しかし、正式なGR提出や決定には至らず、議論は一時的に収束

用語定義と技術的線引きの重要性

  • 「AI」という用語の曖昧さが議論を複雑化
    • Russ Allbery：具体的な技術（LLM等）で議論すべきと主張
    • Sean Whitton：LLM利用の用途（コードレビュー、プロトタイプ生成、本番コード生成等）ごとに区別を提案
    • Andrea Pappacoda：漠然とした「AI」ではなく、明確な線引きが必要との意見
  • Nussbaumは技術の細分化よりも「自動化ツールの利用」という観点で問題を捉えるべきと主張

オンボーディングとAI活用の影響

  • Simon Richter：AIエージェントが新規貢献者の役割を奪い、知識伝承やコミュニティ参加の機会を損なう「オンボーディング問題」を指摘
  • Nussbaum：AI利用が難易度の高いタスクへのアクセスを広げ、新規貢献者が減る懸念は少ないと反論
  • Ted Ts'o：AI利用者の排除は自己矛盾であり、貢献意欲を妨げるリスクを指摘

倫理・法的・品質面での懸念

  • Matthew Vernon：生成AI開発企業の倫理問題（著作権無視、環境負荷、偽セキュリティ報告等）を重視し、Debianとして明確な反対姿勢を求める
  • 著作権・ライセンス問題も議論対象
    • Jonathan Dowland：法的状況が明確になるまで一部貢献物の受け入れ禁止を提案
    • Thorsten Glaser：LLM生成物を含むプロジェクトの非フリー移動を主張（賛同は少数）
  • コード品質については、人間もAIも良し悪しが混在するため、AI生成物のみを問題視するのは不適切との意見（Russ Allbery, Bdale Garbee）

将来への課題と未解決事項

  • LLM出力の非決定性やモデルの更新頻度による再現性の問題
  • 「修正のためのpreferred form」として「プロンプト等の入力情報」が適切かという疑問
  • Debian開発者間でAI生成物の定義すら統一できておらず、方針策定や投票には時期尚早との認識が大勢

今後の展望と課題

  • 技術的定義の明確化：LLMやAIの範囲、用途ごとのガイドライン策定の必要性
  • 倫理・法的観点の整理：著作権、ライセンス、環境・社会的影響への対応
  • コミュニティ形成との両立：AI活用と新規貢献者の育成のバランス
  • 透明性と説明責任：AI支援貢献物の開示・責任範囲の明確化
  • 長期的な影響評価：AI技術進化に伴うプロジェクト運営の柔軟性確保

Debianは、AI時代におけるオープンソースコミュニティの在り方を模索し続けている状況。

Hackerたちの意見

AIが生成した貢献やコンテンツについての質問なんだけど、長い目で見たときに、AIの進化が進む中で、人間とAIの生成物をどうやって確実に見分けられるのかな？今は簡単だけど、3〜10年後にはAIがかなり進化するだろうし。MP3の音質みたいなもので、完璧ではないけど（ロスレス音源の方がいい）、大多数のユーザーには「十分良い」って感じなんだよね。ある時点で、AIが生成したコンテンツやPRが、人間が「人間」として受け入れるのに十分なクオリティになると思う。そうなった時、どんなに良いチェックやバランスがあっても、どうなるんだろう？
└
あなたの予測って、むしろ良いことじゃない？今は人間の方が優れているから人々は人間を好むけど、AIが同じくらい良くなったら、もっと良いPRが増えるってことじゃない？
└
その通り。AIの貢献は個人の延長として見られるべきだよね。むしろ、アカウントは人間に属するべきで、ただのボットアカウントじゃないってことを求めるべきだと思う。基本的には、その人自身の評判がかかってるはずだから。
└
ニッチな商品やサービスが、速くて安いものと比較されるのと同じだね。ニッチなものは、統計的な平均に反して、意図を持って作られているから、通常はもっと時間と労力がかかる。マクドナルドは客観的に見れば「まあまあ」なハンバーガーを作るけど、みんなもっと特別で丁寧に作られたハンバーガーを求めてニッチな店に行くんだよね。人間が意図を持ってAIを使うことができないわけじゃないけど、そうなるとAIは別のツールになって、自律的なコード生成エージェントじゃなくなる。
└
じゃあ、メンテナー自身が好きなLLMに機能を実装させたり問題を修正させたりできるなら、どうしてPRを受け入れるの？
└
> AIが生成した貢献やコンテンツについての質問なんだけど、長い目で見たときに、AIの進化が進む中で、人間とAIの生成物をどうやって確実に見分けられるのかな？その貢献者が本当にパッチの著者で、そのコードに対して著作権を主張する会社で働いていないって確実に言える？いや、でも「それはできない」っていうポリシーを持つのは多分良いアイデアだし、明らかな違反には目を光らせておくべきだよね。ここでも同じ話だよ。何もしなければ問題を招くし、何かをすればすべての事例を止めることはできないけど、問題が大きくなったときには強い立場にいることができる。もちろん、次の質問は、人間のクオリティに匹敵するかそれを超えるAI生成コードが本当に問題なのかってことだけど、今は学問的な話だね。オープンソースプロジェクトに届くAIの提出物はほとんどが低品質だから。もし改善されても、いくつかのプロジェクトは法的（著作権）やイデオロギー的な理由で問題を抱えるかもしれないし、それは彼らの権利だよ。
└
> でも3〜10年後にはAIがかなり進化するだろうって、クリスタルボールかタイムマシンでも持ってるの？
└
もちろん、わかるよね。誰かが突然、どこからともなく山のようなコードを提出して、すべての問題を解決すると主張したら、その作者がAIを使ったと推測するのは合理的だよ。そうなると、その作者が問題の範囲を理解するために必要な時間や詳細を取らなかった可能性を示唆するのも同じくらい合理的だよ。これが議論の基盤なんだ。AIを使うかどうかは関係ないけど、何をしているかを理解しているかどうかは重要だよね。
└
その橋は渡るときに燃やそう。今のペースだと2027年がどうなるかもわからない。今日がこんなに混乱してるのに、2035年のことを心配しても意味ないよ。
└
よくわからないけど、AIが人間の貢献と区別がつきにくいって考えるのは、ちょっと飛躍だと思う。AIはトークンレベルで予測をするからね。この便利さと力は驚くべきものだけど、そのトークン予測には根本的な限界がある。人間が「駆動」したコードとAIが生成したコードの違いは、デザインにあることが多い。冗長で漏れの多い抽象化、明確な価値を提供しない小さな抽象が多すぎる、もっと小さくて的確な変更で目標を達成できるのに大規模なリファクタリングをする、などが、私の経験ではAI生成コードの特徴だと思う。これらは、トークン予測を超えた次の世代の飛躍がない限り、なくならないと思う。ちなみに、「人間が『書いた』」のではなく「人間が『駆動』した」と言ったのは、ちょっと意図的だよ。今の状態のAIでも、革命的な生産性向上の開発者支援ツールになると思う（ある程度はもうそうなってる）。デバッガーやリンターのような他の開発ツールと似てるけど、もっと広い用途と影響があると思う。もし人間がAIを使ってPRを作成したら、それは心配するべきことなのかな？レビューや関連プロセスのチェックを通過できる貢献なら、AIがどれだけ使われたかは関係ある？個人的には、答えは「ノー」だよ。でも、人間がAIを使うことと、AI生成の貢献が人間として通用することには大きな違いがあると思う。前者は増えていくと思うけど、後者はAI研究や技術の次の世代の飛躍がない限り、実現するのは難しいと思う（少なくとも私の意見では）。--- 余談だけど、コード生成にAIを過剰に使うことは、今私が直面している問題だよ。バイブコーディングに頼りすぎている貢献者が、コードレビューやメンテナンスに余計な負担をかけてる。メンテナンスはもともと長期的なコストがかかるものなのに、今はそれが急激に痛手になってる。
└
このシステムは、責任が提出者にあるからこそ機能してるんだよね。
すごく理にかなった立場だね。PRをレビューして受け入れるのは信頼の問題だと思う。提出者がPRを正確で役立つものにするためにできる限りのことをしたと信じるわけだから。今は、ただLLMに頼むのが「できる限りのこと」だと思う人もいるかもしれないけど、AIを使うこと自体が問題なんじゃなくて、使うことに対して意識を持って責任を持つことが大事なんだよね。
└
重要なのは、一般的には悪意のある行動をする人は少ないと考えがちだけど、XZ攻撃のように、FOSSにも高度な持続的脅威が現実として存在することを考慮しなきゃいけないよね。いくつかの一見無関係な貢献者が実は一人のアクターで、バックドアを作っているシビル攻撃を想像できる。今は、多くの貢献者がLLMを使える一方で、受け取るプロジェクトはLLMを使ってそれを効果的にレビューできていないという不均衡がある。LLMが生成したコンテンツは、しばしば（定義上）LLMにとって受け入れられるものに見える。これが重要な問題だよね。もしPRを客観的に効果的に評価できる手段があれば、この問題は解決するはず。これって新しいクラスの問題があるのかな？PRを判断するのは、作るより難しいのかな？今はそう思える。
└
> PRをレビューして受け入れるのは信頼の問題だと思うけど、それは逆だと思う。すべてのコードは、他の方法で証明されるまで、専念する敵からの慎重に考えられたトロイの木馬だと思ってレビューされるべきだよ。
└
これが全ての鍵だよ。PRのレビューは、エラーをキャッチできる堅固なプロセスである必要がある。人間でもAIでもね。
└
信頼の問題として捉えるのが正しいと思う。
私の意見だけど、ほぼ一生コーディングしてきたけど、数年前に手首にかなりの怪我をしてしまったんだ。それ以来、タイピングに対する耐性がほとんどなくなって、フルタイムの仕事が不可能になってしまった。LLMやAIオートコンプリート、エージェントベースの開発ワークフローの登場で、信頼性の高い高品質なコードを提供する能力が復活したし、（言ってもいいけど）むしろ良くなったと思う。個人的には「幻覚」が好きで、それがプロンプトや基本的な指示を微調整するのに役立っている。例えば、あれは本当に受け入れるべき正しい解決策/提案なのか？エゴの戦いなしでペアプログラミングしているみたいだよ。問題を分析する時は、良い面と悪い面の両方を見なきゃいけないと思う。みんなAIの多くの悪い面を議論していて、それが会話の中心になりがちだけど、たぶんそれは良いことだよね。でも逆に、私はアクセシビリティの観点からAIを強く支持している。私は（ほぼ）正確に目指している出力を知っていて、それを執拗にコントロールしているけど、指先ではなくAIと私の声が主導しているんだ。「良いことが悪いことを上回るか？」という視点から見るのは間違っていると思う。関連性はあるけど、功利主義的な議論はしばしば直感に反する結果をもたらして、解決しようとしている問題を増幅させてしまうことがある。これらのツールを私たちのエコシステムに包括的に受け入れ、統合する方がずっといいと思う。「AI禁止！」って言うのは（それが何を意味するかが明確でも）あまり効果がないと思う。世界を良くしようとしない人にはね。
└
> 逆に、私はアクセシビリティの観点からAIを強く支持している。私は（ほぼ）正確に目指している出力を知っていて、それを執拗にコントロールしているけど、指先ではなくAIと私の声が主導しているんだ。これが私が過去数ヶ月で最も得られた技術だよ。難しい高レベルの問題を与えて、その後に巨大な変更セットをレビューして解決しようとはしない。私は、もともと実装するつもりだった技術的解決策を与えて、それに基づいて生成されたコードを得るようにしている。そうすることで、レビュー疲れが大幅に減るんだ。期待しているものがわかっているから、レビューは主にその逸脱に焦点を当てることができる。
└
>「個人的には、"幻覚"が大好きで、プロンプトや基本的な指示を微調整するのに役立ってる。意図を強化するのもね。」これ、AIパワーユーザーの皮肉みたいに聞こえる。なんでLLMが適当なことを言うのが好きなの？もっとプロンプトを書けるから？それなら、そんなことしない方が良くない？「渋滞にハマるのが好きだ、だって運転時間が長くなるから！」って言ってるようなもんだよ。ごめん、その一文がすごく気になった。
└
私も似たような状況だよ：RSIがあって、スマートオートコンプリートスタイルのAIは神のような存在。あなたとは違って、エージェントモードの複雑なAIは、私のやってること（ハードリアルタイムのC++やRust）にはあまり役立ってないから避けてる。プログラミングの楽しさが奪われちゃうしね。（旅の過程が目的地より大事だよ。）アクセシビリティの観点は本当に重要だ。理解していない貢献をする人を止める方法が必要だし、著者であることを保証できない人もね（ライセンスの問題はまだ曖昧だし、アメリカの最高裁の言ったことはEUでは関係ない）。これは難しいけど。
└
似たような話だけど、そこまで極端じゃない。時々、同じようなエルゴノミクスの問題が出てくる。プログラミングにはあまり影響しないけど（考える時間の方が多いし）、メールやドキュメントは厳しい（プログラミングよりもコンピュータの使用が多い）。私のシンプルな解決策：Whisperを使ってテキストを文字起こしして、その出力をLLMに渡して整理してもらう（カスタムプロンプト）。素晴らしいよ。Dragonみたいなものよりずっといい。今は、AndroidのGoogleのデフォルトのメカニズムで文字起こしするのにイライラしてる - すごく不正確！でも、Whisper + LLMを使ってメモを取ったり、メールを口述したりする能力は貴重だね。IPをLLMに入れることを許可しない会社には働きたくない。似たように、私は紙にたくさんメモを取るけど、それをタイプするのは面倒で痛い。メモを声に出して読んで、上記のシステムで文字起こしするようにした。まだ痛いけど。最近、Geminiが私のメモを読むのが得意だと気づいた。だから、今はメモを写真に変えてGeminiに送ってる。すべての経費を分類してる。スーパーのレシートも、アイテムをカテゴリーにハイライトしてる。これを財務ソフトに入力するのがどれだけ面倒か想像できるよね。Geminiにレシートの写真を見せて、カテゴリーを分類して合計してもらうのを試してみるつもり。これらはそれぞれすごく面白いアプリケーションだけど、健康も改善してると気づくと…明らかに勝ちだね。
└
コードにサインして、自分の専門知識と評判をかけるなら、AIはただの高度なオートコンプリートツールになって、それに対して「AI禁止」のルールは適用されないべきだよ。使うのは全然問題ない、仕事ができるならね。
└
>「私は、これらのツールを私たちのエコシステムに統合して、全体的に受け入れる方がずっといいと思う。人々に『AI禁止！』って言うのは（それが何を意味するかが非常に明確でも）あまり意味がない。世界を良くしようとしない人たちに対してはね。これは論争を解決しない。なぜなら、あなたが合理的な人だと仮定して、他のAIを使う人もあなたと同じように合理的で、正しくAIを使えると考えているから。私たちが聞く噂は、レビューできる以上のプルリクエストが溢れているプロジェクトに関するもので、プルリクエストは明らかに質が低く、貢献者の動機は自己中心的だ。つまり、PRは自分のGithubプロフィールのためにクレジットを得るために提出されている。この場合、プルリクエストはあなたの仕事に対する誠意を持って開かれているわけではない。一般的に、AIの提出に対する良いポリシーは、まず「誠意」の問題を主に扱う必要がある。そして、プロジェクトがどれだけバイブコーディングに対して寛容かを説明する必要がある。」
└
アクセシビリティは、この議論であまり取り上げられない視点だけど、強いポイントだよね。
└
具体的なことは置いておいて、怪我のことを聞いて残念に思うし、対策を見つけられてよかった。高品質な音声転写が私の健康にとって大きな意味を持つかもしれないと思う（今のように、あんなにタイプするのは良くないよね）。
└
ちなみに、毎年できるだけアクセシビリティに焦点を当てたトークをカロライナコードカンファレンスでやるようにしてるよ。今、スピーカーの募集が始まってるから、もし自分のストーリーについて何か提出したいなら、ぜひどうぞ。
└
プロジェクトに関しては、ライセンスの問題もあるんだ。AIが生成したコードの著作権は誰も持ってないから、ライセンスを付けることができないんだよね。
メンテイナーの時間の無駄遣いやオンボーディング、著作権についての懸念は、政策的な観点から私にとって非常に興味深い。だけど、AIの貢献の質に関する議論が奇妙だと感じる。質は常に変更を提出する人の責任であるべきだよ。誰かが善意で行動しているなら、その人がLLMを使ったかどうかは大きな問題ではないはず。もし悪いコードを提出したら、AIを使ったことは正当な言い訳にはならない。AI使用を制限するポリシーは、良い貢献者を傷つける一方で、悪い貢献者はその制限を無視するかもしれない。とはいえ、著作権の懸念のような質以外の理由での制限は、まだ意味があるかもしれない。
└
変更を提出する人の責任だと思う。でも、AIのおかげで人々がその責任を逃れやすくなってるのが問題だよね。
└
>「もし彼らが悪いコードを提出したら…」根本的な問題は、これを評価するのにかなりの労力がかかることだよ。LLMが生成したコードは見た目が良いからね。静的型付けの言語は、実装する内容を本当に理解していないと実装が難しいと言われてる。動的型付けの言語は、理解が不十分でも実装しやすいんだ。LLMは、何も理解せずに実装できるようにすることで、これをさらに進化させてる。
└
本当に変わらないのは責任だよ。パッチを提出したら、それを自分のものとして持つべき。理解して、デザインの選択を擁護できて、必要ならメンテナンスもできるべきだよ。
Slobianにフォークして、クランカーたちが自分たちでプルリクエストを作成、承認、マージできるようにしよう。インストールベースを見て、人々が何を好むかを確認してみて。
LLM生成コードに対する品質の議論は、私にはいつも弱いように思える。メンテナーはすでにパッチをレビューしているから、悪いコードを提出する人間がいるからね。レビュー過程がフィルターになってるんだ。
これ、Hacktoberfestの状況を思い出させる。メンテナーが低品質なPRに溺れてたやつ。これが、もっとひどくて常に続く感じになるかもしれないね。
誰かリスクだと言った？もし裁判所が、クローズドモデルの製品を使うユーザーがトレーニングデータの所有者に合理的な料金を支払わなきゃならないって決定したらどうなる？
問題の議論はここから始まるよ：「https://lists.debian.org/debian-vote/2026/02/msg00000.html」
[遅延]