LLVM AIツールポリシー：人間の介入

107日前原文(discourse.llvm.org)

概要

LLVMプロジェクトが提案するAIツール利用ポリシーの要点解説。
貢献者は「人間が内容を理解し説明できる」ことが必須条件。
AI生成物の無検証提出や、メンテナへの負担転嫁を禁止。
透明性確保のためのラベリング指針と違反時の対応策。
著作権や他コミュニティの事例も参照しつつ運用方針を明示。

LLVM AIツール利用ポリシー

LLVMはAIツール利用自体を禁止しないが、「人間が必ず内容を理解し、説明できること」を条件とするポリシー。
貢献者はAI生成コードやテキストを必ず自分で精査・確認し、他のメンバーにレビュー依頼する前に内容を把握する責任。
貢献者自身が著者として全責任を負うことが原則。
自信のない新規貢献者には、小さな貢献から始めて理解を深めることを推奨。
メンテナの負担軽減と、プロジェクト価値向上を最重要視。

具体的な運用例

AIツールで生成したコードやドキュメントは、必ず人間が内容を見直し、正確性を確認した上でPull Request（PR）等で提出。
大規模・複雑なPRや、メリットが薄い貢献は「extractive」とラベル付けし、再検討を促す運用。
AIツール利用時の透明性確保として、PR説明文やコミットメッセージ等で「Assisted-by:」のような記載を推奨。
自動エージェントやbotによる無人投稿は禁止。人間が介在しない自動レビューコメントも不可。
オプトイン型の人間介在ツールは許可。

extractive contribution（搾取的貢献）への対応

メンテナがextractiveと判断した場合、定型文で修正要求し、ラベル付与後は追加対応を控える。
貢献者が改善しない場合、該当スペースのモデレーションチームにエスカレーションし、会話ロック等で対応。
extractive度合いの判断基準は、プロジェクト維持に携わるメンテナの裁量。

著作権への配慮

AIツール利用時も著作権責任は貢献者に帰属。ライセンス違反や第三者著作物の無断利用は禁止。
違反が判明した場合、他の違反貢献物と同様に削除対象。

参考事例・他コミュニティの動向

Fedora、Rust、Python、QEMU等、他OSSコミュニティのAI/LLM利用ポリシーや議論を参考に策定。
コミュニティの持続的成長と新規貢献者の育成を両立する運用方針。

ポリシーのまとめ

AIツール利用の自由と人間による責任ある貢献の両立を目指すLLVMの方針。
メンテナの時間と労力を守るため、「価値ある貢献」の原則を徹底。
透明性・説明責任・コミュニティ維持を重視した実践的ガイドライン。

Hackerたちの意見

コードを書く人が一晩で急増したね。レビューをする人の数は一定だけど、リストラの影響でちょっと減った。

└

それに、質も悪化したね。

こういうことをわざわざ説明しなきゃいけないのが悲しい。人々が理解できないことでメンテナンス担当者を嫌がらせするほど愚かだとは思えないよ。

└

先を見越して考えられる人は、「AIがすべての仕事を完璧にこなして、ただ私の神の導きが必要だ」って罠にハマらないくらい賢いよ。

└

プログラマーじゃないなら無理だよね！

└

仕事でよくあることなんだけど、俺はハードウェアチームと一緒に働いてるプログラマーで、今は大きな変更を彼らが提案してきて、俺はそれに合わせてやっていかなきゃいけない状況。管理者はこれをすごく好んでるみたい。

└

これは「AIがソフトウェア開発者を置き換える」っていうハイプの一部だと思う。多くの初心者や志望する開発者がこれをそのまま信じて、AIに問題を指示して、生成されたものを管理者に提出するんだよね。

└

コンピュータのアルゴリズムに自分の考えを丸投げする人は、あんまり頭良くないよね。

うちの会社では「自分の仕事に責任を持て」って言ってる。実際には、AIがやったって言い訳にはならないよ。AIを使ったとしても、自分がやった仕事には責任を持たなきゃいけない。AIを使えとも使うなとも言わないけど、実際にはあんまりAIを使ってる人はいないね。

└

一番賢くて理にかなった反応だね。AI使用の指標が全開発者に導入される日が来るのが怖いよ。

└

> うちの会社では「自分の仕事に責任を持て」って言ってる。それが最低限のことじゃないの？ AIが存在する前から、プログラミングに関わっていなくても、最低限それはやらなきゃいけなかったよ。トースターを使って、会社のガイドラインがサンドイッチを20秒焼くことを推奨していても、訓練通りにやった結果が炭になったら、お客さんに出せないよ。結局、サンドイッチを作るのは自分なんだから、正しく作る責任がある。だらしない仕事の言い訳にAIを使うのは許されるべきじゃないね。

└

でも「AIがやった」って言い訳は通用するの？もし、なぜそのコードがそのように作られたのか説明できないなら、AIに代わりにやらせてもいいよね？

└

企業がこれに対処するのと、オープンソースコミュニティが対処するのとの違いは、企業は従業員を解雇できるってことだよね。オープンソースの寄付はコストがほとんどかからないし、色んな人から来るから、管理者は「AIがやった」って言い訳を使う千人目の人に反応しなくて済むように、特定のポリシーを作ることになるんだ。

└

彼らが「自分の仕事に責任を持つ」って言っても、俺には何の役にも立たないんだけど。それでコードを探る時間が節約できるわけじゃないし、ただ注意するための台本ができるだけ。注意したくないんだよ。善意で渡されたコードをレビューしたいだけ。昔、同じファイル内で「FooBar」構造体と「BarFoo」構造体を宣言して、両方とも同じフィールド名/型で、相互変換のためのボイラープレートまであったコードをレビューしなきゃいけなかったことがあったんだ。この分割には全く意味がなくて、多分エージェントにコンパイルするまで繰り返すように指示して、その結果を実際に読まずに出荷しただけなんだろうな。「自分の仕事に責任を持て」って叫んでも、どうしてこんな風にコードが書かれたのか理解するのに失った時間は戻ってこないし、ただの嫌な奴になっちゃうだけだよ。

└

>「AIを使えとも使うなとも言わないし、実際に人々はあまりAIを使っていないようだね。これがどれだけ価値があるかは別として。」この部分はちょっと混乱するな。AIツールのために企業契約を提供してるの？それとも、従業員が会社のデータを使って個人アカウントを使うのを許可してるの？今の時点で、どの会社も何らかの形でこれを管理しなきゃいけないみたいだね。

└

履歴書を磨きたいだけの人が、自分の作ったゴミに対する質問やフィードバックをAIにフィードバックすることがあるよ。それが何度も行き来して、レビュー側がコードの作者が何も分かってないってことを学ぶまで続く。LLMは「自分の仕事の後ろに立っている」と簡単に見せかけることができるからね。会社は、何も分かってない人を解雇することができるし、少なくともその努力に対して何らかの対策を取ることができる。公共のプロジェクトでは、こういう人たちが千切りにされることもある。最近のバグバウンティサイトで見かける自動化された「CVE」レポートがその最たる例だね。

└

これ、言うまでもないことじゃない？どこかの時点で誰かがコードをレビューしなきゃいけないし、その時にPRの送信者として人間の名前が見えるでしょ。その人が仕事が悪いって思ったら、PRに名前がある人がその責任を持つのは完全に明白じゃない？もし「でもこれはAI生成だよ」って返事が来たら、「関係ない」と返してレビューを戻すのが正当だと思う。で、LLVMポリシーにあることも自然に出てくるはずだよね？もし誰かがレビュー用にコードを送ってきて、自分で読んでない感じがしたら、「これをレビューしないし、あなたが自分で読んだって約束しない限り、他のPRもレビューしないよ」って言うつもり。こういうことを明示的な方針として確立する必要があるっていうのはちょっと気になるな。（悪いアイデアでは全然ないけど、そういう必要があったのが心配。）

タイトルは「LLVM AIツールポリシー：人間が関与する」に変更すべきだね。今のは「プログラマーじゃない貢献者がコードを提供する必要はない」っていう返信からのもので、元の投稿を代表するものじゃない。HNのガイドラインには、誤解を招くかリンクベイトでない限り、元のタイトルを使うようにって書いてあるし、編集しないでって。

└

それに、新しい貢献者に対してかなり敵対的に見えるのも良くないね。この記事の意図とは全然違うし。

└

はっきり言うけど、コードを読めないのに友達に書いてもらって提出するのは、実際に提出するべきじゃないよ。そういう人は扱うのが一番面倒だから。状況を理解していない人がループに入ってきて、無理に進めようとするのは、役に立たないだけじゃなくて、逆に害になるからね。

└

なんでタイトルが修正されてないのか知りたいな。

└

元のリンクはこのスレッドのコメントにあったんだけど、それを引用したんだ。今はメインスレッドに変更されてる。

└

同意。元のタイトル（「プログラマーじゃない貢献者がコードを提供する必要はない」）は、非常に冷静で理にかなった政策変更を風刺しているように見えるね。

開発者として、コードを書くことだけが仕事じゃないよね。ちゃんと動くか確認するのも大事だよ。別のチームでこのやり方を見たことがあるけど、LLMだけじゃなくて、問題を理解せずにバグ修正をする開発者もいたりするんだよね。

└

公開するLLM生成コードには、もう一つの責任があるよ：著作権を侵害しちゃダメだ。

彼らの著作権条項は、LLMの使用に関する俺の悩みを反映してる。俺は、公開するLLM生成コードが著作権を侵害していないことを確認する責任がある。でも、ネガティブを証明するのはほぼ不可能なんだ。実際に経験したことがあって、Claudeが難しい問題に対してほぼ完璧な解決策を出してくれたんだけど、それが10行で、俺が見たことのある何千行もかかるものをやってのけたんだ。その後、著作権のある資料にほぼ同じ解決策を見つけたことがある。

└

著作権はクリエイティブな作品のためのものだから、もしそれが本当に最良の方法なら、AIが誰かのアイデアをコピーしても安全だと思うよ。著作権を使って特許のように有用な技術へのアクセスを制限することはできないからね。

└

> ただし、否定を証明すること、つまりコードが著作権で保護されていないことを証明するのはほぼ不可能だ。そんなのナンセンス、自分でコードを書いたなら簡単だよ。著作権は自分にあるからね。もし誰かのLLMにコードを吐き出させたなら、それについては全く分からないよね。だから、その吐き出したものには貢献できない。

└

著作権侵害で誰かが痛い目にあったことってある？ゲーム会社が前の雇用主からコードを盗むのはすごく明らかだけど、企業ソフトウェアではそんなの見たことないな。

タイトルは絶対に変えるべきだと思う。「レビュー中に自分の仕事について質問に答えられることを求める」ってのは全然合理的だよ。今のタイトル「プログラマーじゃない貢献者にコードを提供してもらう必要はない」ってのは、まったく別の話だし。

└

それって本当にそう？ハンガリー語が話せなくて、ハンガリー人の友達にテキストを書いてもらって、それをハンガリーの詩のコレクションに提出する場合、そのテキストについて質問に答えるのが正しい人だと思う？内容は分かっても、質や他の作品との関連性を判断することはできないよね。友達を信じるしかない。でも、それでいいけど、他の人を巻き込まないでほしい。個人的には、これをやろうとするのはすごく失礼だと思うし、もしやったら、他の人の時間を無駄にして恥をかくことになるよ。

ローンオフィサーとして、この方針は好きだな。クレジットリスクを計算するためにたくさんのモデルを使うけど、モデルに契約にサインさせることはない。アルゴリズムは裁判に行けないし、破産した家族に謝ることもできない。「人間が関与する」ってのは、コードの質だけじゃなくて、責任の問題でもある。もし生産が壊れたら、どの人間がその評判をかけてマージしたのかを正確に知る必要がある。責任はまだ自動化できない唯一のものだからね。

└

このアカウント、投稿履歴を見る限りLLMのゴミみたいだね。「日本から」と始まる投稿が毎回あるのは何なんだ？HNで隠れたチャットボットとやり取りしたくないよ。この責任についてのコメントの皮肉もイライラする。

これ、特に貢献が引き起こす実際の問題に焦点を当ててるところが好き。AIツール自体じゃなくてね。「抽出的貢献」っていう言葉も特に気に入ってる。これが問題をうまく捉えていて、LLMが登場する前からあった非AIのケースもカバーしてる。レビューに優しい貢献をするのは一つのスキルで、大きな違いを生むよね。

100%同意する。プログラマーは、自分が提出したPRのコードに責任を持つべきだよ。AIを使ったかどうかに関わらず、GoogleやStackExchangeを使ったかどうかに関わらずね。責任は自分にある。ただ、別の状況もあるよね。もし働いている会社がLLMを使ってコーディングすることを求めているなら、「ああ、AIがやったことだ」と言うのは100%正当化できると思う。会社がその使用を強制しているからね。もし会社が手を抜くことを強制しなければ、もっと良いものができたはずだよ。

ハクソク