AIツール使用による貢献は開示必須

 (github.com/ghostty-org)
5 ポイント 投稿者 GN⁺ 2025-08-22 | 1件のコメント | WhatsAppで共有
  • オープンソースプロジェクト Ghostty のPR議論で、AIツールの使用有無を 明示的に開示すべきだ という意見が提起された
  • 提案者は、AIが依然として 低品質なコード を生成することが多く、特に 未熟な利用者がレビューなしで提出 する場合に問題が大きいと指摘した
  • 開示の目的は、メンテナーがPRの信頼性を評価し、人間の貢献者には教育的なフィードバック を与える一方で、単なるAI生成物には不要な労力を減らすことにある
  • 別の参加者は、PRテンプレート を通じてAI使用有無を含むチェックリストを追加できると提案した
  • 一方で、AIツールが自動的に 特別なbylineを標準化 してGitHubコミットメッセージに記録されるようにすれば、透明性とツールの明示を同時に確保できるというアイデアも示された

AI使用開示の必要性

  • MitchellhはAIツールの使用を好み、自身も活用しているが、現時点では 同等またはより高い品質を保証できていない状況 だと評価
    • 特に レビュー能力が不足した初心者 がAIコードをそのままPRに上げる場合、品質は非常に低い
    • このような状況でメンテナーが不要なレビューやフィードバックに時間を費やすのは 「だます行為」 だと批判
  • そのため、AI使用有無を明示的に開示すれば、メンテナーは どの程度注意深くレビューすべきか判断 できる

PRテンプレート導入の提案

  • Yawaraminは GitHubのPRテンプレート機能 を活用し、AI使用有無を含めようと提案
    • 同時に Developer Certificate of Origin(DCO) のようなチェックリストも含められる
    広告
  • これにより、すべての貢献者が一貫した方法で AI活用の事実を知らせられる

GitHub標準化のアイデア

  • TobiはGitHubレベルで AI専用のbyline標準 を作ることを提案
    • AIツールが使われるたびに .git ステージングファイルに記録され、コミットメッセージに自動追加される
    • GitHubはこれを一覧化し、ツールへのリンクを提供 → メンテナーは出所を確認できる
    • 同時にAIツール側も、現在のように co-authorsをスパムのように乱用しなくて済む
  • この方式は 透明性の確保、ツールの周知、メンテナンス効率 をすべて満たす案として評価されている

関連記事

1件のコメント

 
GN⁺ 2025-08-22
Hacker Newsの意見
  • 「AI」を使う場合でも知的財産権の汚染問題は発生しているのに、私たちはその事実から目を背けている、もし誰かがあらゆるオープンソースプロジェクトのコードを暗記して必要なときにそのまま書けるなら、その人は当然うちの会社では禁止されるべきだ、なのにAIの場合はさまざまな合理化や言い訳を並べてその事実を否定している、実際にはGPLを含む多様なコードを緩くロンダリングしているようなもので、これは知的財産(IP)ベースの企業にとって致命的なリスクをはらんでいる
    • 米国の裁判所はすでに、学習データの利用が変形的(transformation)な用途であると判断している、細部の調整はまだ多いだろうが、結局は元に戻せない変化だ、IP創出が経済的に持続可能な活動であってほしいなら、関連する法体系も変えなければならない
    • この論理に従うなら、StackOverflowやほぼあらゆる分野の教科書も禁止しなければならない、現実にはプログラマーはどうしても他人のコードを見ることになる
    • 実際、金銭的に関係する人以外はAI関連の法的問題を深刻に考えていないと思う、幸い多くの場合この問題は無視されており、法体系も進歩を妨げない範囲でうまく機能している
  • mitchellhの「新規コントリビューターを最後まで支援し、PRがマージされるよう助ける」という部分がとても印象的だった、フィードバックを通じて新人開発者が成長するのは本当に価値のあることだ、しかしもしPR提出者がそのフィードバックをすぐAIに投げて本人は何も学ばないのだとしたら、それは時間の無駄だ
    • これから新人開発者には、AIなしで働く環境そのものがなくなっていくだろう
  • 今日のHNフロントページが現実的な経験ベースの良いコンテンツで埋まっていてとても気分がいい、無駄な恐怖や誇張なしに率直な話が多い、個人のPCではAIアシストを切っており、会社でも本当に必要な場面でのみごく限定的に使っている、AIアシストは小さな単位の作業(atomic work)には非常に強いが、複合的な作業(compound work)にはさっぱりだ、結局のところAIは人間がどう活用するかにかかっており、人間の知能が核心だ
    • 「AIは人間が扱える範囲でしか賢くない」という言葉にますます同意するようになった、同じAIでまったく違う結果が出るのが理解できなかったが、本当にAIは魔法ではないと実感している、チーム内で説明すらできない人たちがAIから価値を引き出せると期待していた自分は naïve だったと思う、むしろAIは平凡なエンジニアと優れたエンジニアの差をさらに広げるだけかもしれない、まだ気持ちは複雑だが、なぜAIを無用だと感じる人がいるのか理解できるようになった
    • Frederik P. Brooksの「No Silver Bullets, Refired」から、ソフトウェア開発は本質的に複雑であり、革命的な解決策をただ待つのではなく段階的な生産性向上を目指すべきだという結論を引用している、この視点は現実的で希望が持てる
    • 「AIは人間が扱える範囲でしか賢くない」という言葉に興味を引かれる、結局「AIで1日でクールなライブラリを作った」という投稿の主役たちは、もともと実力のある開発者だった
    • 自分も共感する、会社ではハッキング週間なのでAIツールを全社的に実験しているが、分析的アプローチ、ガードレール、grounded generation など実運用ではそうしたものが主に良い結果を生む、最近は無駄なチャットボット熱が過ぎ去って、機械学習の本質へパラダイムがリセットされたように感じる
    • 人間が中核となる意思決定を行い、その後でAIが残りをつないでくれるのだと考えている、中核となる意思決定とは何か、点を単純につなぐだけの作業とは何かはドメインごとに異なるが、実際にはコードの大半(80〜90%ほど)は単純な反復・接続作業だ、この境界さえ守れば生産性向上は非常に大きい、逆にAIに中核的な意思決定を任せるともっと大きな損失になる、むしろ捨てて作り直したほうがいい、中核的な意思決定の例としてはデータベース設計、型定義、依存関係、システム/インフラ/画面設計、テスト項目の選定、コード構成などがある、一方でAIがうまくできるのはCRUD、APIハンドラー、単純なデータ構造変換、デプロイスクリプト、テスト実装、UIコンポーネントコード、スタイリング、一時データの整理などだ、やはりAIはリサーチやアイデア探索、代替案の検討などには役立つが、結論と実装は人間が自分で担うべきだ
  • 自分はAIを大好きというわけではないが、単なるツールの一つとして見ている、誰がどうPRを準備したかより結果が良ければ気にしない、ただしPR提出前にメンテナーが何か求めているならそれに合わせるのが礼儀だと思う
    • PRがどこから来たのか、どう作られたのかは重要だ、レビュアーにもミスや限界があるので信頼が重要になる、信頼がなければそもそもレビュー工程に受け入れるべきではない、Linuxカーネルチームが実験を理由にミネソタ大学をブロックしたのも同じ理由だ
    • 文章の核心的な論点、つまり「新規コントリビューターが成長できるよう助けるのが目的だが、相手がAIなら時間の無駄でしかない」という部分にはきちんと答えていないように思う
    • AIなら1日に1,000件のPRも作れる、AIでうまく作られたPRだけを想定しているようだが、現実にはAIでプロジェクトのメンテナーをとてつもなく疲弊させることもできる
    • 米国著作権局によれば、AIが生成した成果物は著作権保護の対象ではない、そのためライセンス目的のためにもAI使用の事実開示が必要だ、これに違反すると作品全体の著作権を失う可能性がある、詳しくは報告書とメインページを参照
    • AIを使っていてその事実を尋ねられたら、常に開示するつもりだ、ただし具体的に聞かれていないなら「慣例的な礼儀として先に」明かすことはしない、大半の人はAI利用を当然視しているか気にもしていないと思うし、むしろ注意を散らす些細な表示だと感じる、dependabotの通知が来ても実際には関心を持たないのと同じだ
  • 「自分のオートコンプリートはどうなるんだ」という質問が何度か出ていたが、単純なタブ補完のようにキーワードや短いフレーズであれば開示不要だと方針文書で明確に例外規定がある、文書(あるいはPR)をきちんと読めと言いたい
  • 今回の方針は追加の文脈説明が入っていて納得できる、以前に見た多くのAI関連ポリシーは理念表明に近かったが、ここでは要求する理由と今後の方向性が示されていて、ずっと現実的だ、こういうやり方がもっと増えてほしい
  • この方針は結局、正直な人ほどAIを使いにくくするのではないかという懸念がある、どうせAIを使ったと言えばPRが注目されにくくなるのだから、みんな隠すようになるのではないかという問いだ
    • そこまで単純ではないと思う、方針を出した本人(mitchellh)もLLMを使っているので、自分が行った作業を十分理解したうえで利便性のためにAIを使ったと説明できるなら、そこまで信頼を失うことはないだろう
    • 懸念が現実になる可能性はある、AIは「だいたい合っているように見えるが実際にはめちゃくちゃ」なコードを大量に生み出すので、もしAIコードへの不信が積み上がるなら、それは人の問題ではなくAIの問題だ、より進化したAIコーディングツールが必要だ
    • 「chat-gptを使った」と明かすとすぐ埋もれ、何も言わずに知識があるふりをすれば褒められる、すでに誰もがAI利用を隠す方向へ向かっている
    • これを問題だと捉えること自体にあまり意味はないと思う
    • 「AIを使うな」と言っているのではなく、使ったなら正直にPRで明かしてほしいという趣旨だ
  • 「ChatGPTでコードベースの理解を手伝ってもらったが、実際のコーディングは自分で行った」のような詳細な開示まで求める理由が気になる
    • こうした説明が残っていれば、レビュアーとしては「コードベース理解」の部分で誤解や思い違いがレビューのポイントになり得ると分かるので、そこに集中できる
    • 自分は開発者ではないが、このようなAIアシスタントのおかげでコード探索の時間が著しく短縮された、個人的にはAIが本当に大きな助けになった
  • PR生成に使った各プロンプトを含めるパターンは良いと思う、LLMは完全に決定論的なツールではないが、どのような段階やプロンプトを経て結果に至ったのかという文脈を残すことに意義がある
    • 現実的には非常に非実用的だ、AIベースのPRを一つ作るだけでも10〜20個のプロンプト、テスト、手動での文脈調整、手動コーディングなど多くの手順が混ざるからだ、むしろ画面録画のほうがましだと思う
    • 自分はvscodeプラグイン(specsytory)とcursorの組み合わせで、すべてのLLMとのやり取りのログをmdで残し、Pull Requestに添えて提出し、コードレビュー時の参考にしている
  • 個人プロジェクトでは、エディタのオートコンプリートを使ったかどうかまで開示するルールにしている
    • 意図の伝え方としては興味深いが、今のAIは従来のオートコンプリートとはまったく違う、オートコンプリートのようにも使えるが、AIにできることははるかに多様で深い、AIを単なる自動補完程度とみなすのは個人的な見方にすぎず、多くの人はそう使っていない
    • タブ補完は方針上、明確に例外として認められている
    • オートコンプリートは大半が文法的なツールにすぎないが、AIはコードの意味や構造までガイドしようとする