Claude Codeで25年前のカーネルドライバを近代化！ベテランコードがAIで生まれ変わる
引用元：https://news.ycombinator.com/item?id=45163362
良いケーススタディだね。AI活用のメリットは二つあると思うよ。一つは自分のスキルを大幅に向上させるツールとして使うこと。Claudeは慣れたフレームワークでの定型的な部分で僕の生産性を高めてくれる。もう一つは新しいフレームワークを素早く学ぶためのツールとして使うこと。これも生産性を上げてくれるし、新しい分野を探求できるから、大規模なテック企業で多くの技術スタックやフレームワークがある場合に特に役立つよ。AIの能力を正確に理解するには、急速に変化する技術についていく必要がある。Claude CodeやClaude 4.0に100時間くらい使わないと、その真の能力は分からないんじゃないかな。「非コーダーが適当にコードを生成してトラブルを起こす」ってのはXでの一般的な見方かもしれないけど、時間をかけた専門家が経験するのとは違うんだよね。
これは良い気づきだね。僕はClaude Codeをコードベース変更の主要なアプローチとして、もう何ヶ月も毎日使ってるよ。試行錯誤で確固たるシステムを築いてきて、全体として生産性が大幅に向上したし、大規模な実験にも躊躇しなくなったんだ。特に気に入ってるのは、強力なデータ構造やスキーマ、内部APIを開発したら、Claude Codeに内部ツール用の素晴らしいUIをワンショットで作らせることだね。煩雑な作業やフレームワークの細かいニュアンスを超えて、より高次のレベルで考えられるようになったのは、16年のキャリアでゲームチェンジャーだよ。
これは、僕らの仕事がこれまで本質的に進化してこなかったことの現れじゃないかな。筆者は「ボイラープレート」って言ってるし、君は「泥臭い作業」って言ってる。今やAIがこれらをやってくれるようになったけど、そもそもなんでこんなものが必要なんだろう？なんで最小限のボイラープレートで済む言語やフレームワーク、プログラミング環境がこれまでなかったの？なんで僕らは collectively でボイラープレートや泥臭い作業を減らす新しいツールの開発を重視してこなかったんだろうね？
これこそが明白な誤りだ！僕らは信頼できない確率的なエージェント（AI）を使って、本来なら完全に決定論的で信頼性の高いプログラムで抽象化したり自動化すべきボイラープレートや面倒な作業をやらせているんだ。これは、どう見ても退行的で無駄なソフトウェア開発方法だよ。
ボイラープレートなんていらない、って言うのは、もし家具を木から完璧に一枚で切り出せるようにデザインするなら釘やネジはいらない、って言うのと同じだね。それに対する答えは「まあ、そうだったら最高だよね。でも、実際にどうやってそれを達成するのかは分からないけど」って感じかな。
人間が関わると、大体すべてが確率的になるよね。もっと重要なのはエラー率と結果の正確さだよ。AIの導入は、テストケース、測定、そして最終的な成果への注目を高めることになると思うな。
いや、これは根本的に間違った例えだよ。僕らは確率的なプロセスでコードを生成するわけじゃないからね。
新しいフレームワークだけでなく、新しい言語にも使えるね。僕のチームはRubyを使ってるんだけど、Rubyは読みやすいから構文を学ぶのをスキップして、LLMにコードを書かせられるんだ。すべての決定は僕がして、LLMをガイドするんだけど、Rubyを学ばなくても許容レベルのコードは書けるんだよ。おかげで慣れない環境でもすぐに生産的になれるのは素晴らしいね。[0]許容レベルはチームの他のメンバーが僕のPRをチェックすることで定義されてるんだけどね。
新しいフレームワークへのオンボーディングにツールを使うって話だけど、新しい言語でもって。Rubyは読みやすいからLLMにコードを書かせれば、構文を学ぶ必要はないって？もしRubyが「読みやすい」なら、自分でRubyを書いて習得するのにどれくらい難しいの？チームがRubyを使ってるのに、なんで君はそれを学ぶ必要がないの？「ああ、分かったよ。共通言語を学んで自分で作業を検証する代わりに、他のチームメンバーが君のPRが明らかに失敗しないか確認しないといけないんだね。」チームメンバーが君のPRが許容できるか判断する必要があるって、「悪いこと」じゃない？君が導入してる変更への信頼の欠如を示してる可能性もあるよ。それに、この状況ってチーム全体にとって「すぐに生産的」なの？それとも君だけ？
EDIT:もし君がソフトウェアエンジニアじゃなくて、エンジニアリングチームに望むシステム変更を正式に指定するステークホルダーなら、PRの代わりにRSpecで機能仕様を定義するアプローチを検討してごらん。こうすれば、機能要件をコード化して検証可能にできるし、チームが既存の挙動の文脈で何をすべきかを理解するのを助け、エンジニアリング作業が費やされる前に競合するシステム要件を特定できる。それに、一連の機能回帰テストや実行可能なドキュメントとしても役立つよ。
RSpecの詳細: https://rspec.info/features/6-1/rspec-rails/feature-specs/fe…
俺のチームには、LLMで新しい領域に挑戦したがるやつがいるけど、Claude 4の思考エージェントを使っても、的外れなコードを大量に作っちゃうんだよな。長年のキャリアでパターンマッチングばかりしてきた人にとっては、LLMエージェントがその上でもパターンマッチングするから、経験のない人たちにとっては頭痛の種になる。
LLMエージェントは人間のパターンマッチングよりはるかに速いけど、全体的な精度はいまいちって感じ。
これは大きな誤解だよ！面白くない、魅力的じゃない作業だから苦痛に感じるんだ。家具を作る時、切断、釘打ち、接着は創造行為の周りにある「ボイラープレート」だろ。LLMはただのネイルガンだよ。
後方互換性への執着と、コードを壊さないってことにこだわりすぎだからだろ。Web開発業界がその典型だよ。HTML、JavaScript、CSS、バックエンドとフロントエンドのアーキテクチャなんて、マジで最悪なスタックだ。
俺たちがやることは全部確率的なプロセスだよ。ダーツを100回投げても、毎回同じ場所には当たらないだろ？日々の行動には、たくさんの不確実性や非決定的な挙動があるんだ。
LLMで的外れなコードを大量に作るってのは、結局そいつらが何してるか分かってないってことだろ。手作業でも同じように的外れで意味のないコードを作るだろうけど、もっと遅いだけ。これはパラダイムシフトなんだよ。LLMの未熟な使い手が生み出す大量のクソコードをろ過するには、もっと大きなふるいが必要になる。
著者はClaudeにLinux 2.4から6.8へのドライバ移植を頼んだんだろ。訓練データやウェブ上の情報も十分にあったはず。Claudeが類推できなかった、本当に重要な部分で著者が専門知識を提供したわけだ。「これらのツールを自分のスキルの巨大な増幅器として使う」ってのは良い表現だけど、自分のスキルがほぼゼロなら、いくら増幅しても結果はゼロになるよ。生産性がマイナスになることだってある。
「これらのツールを自分のスキルの巨大な増幅器として使う」ってのを今週実感したよ。AIの入力からめちゃくちゃな繰り返し作業が多い小さなプロジェクトを作ってみて、やっと分かった。その後で、markupやスタイル、JavaScriptなんかを統一する「統合」タスクでは、AIをガイドするだけで魔法みたいにうまくいったんだ。スタートアップだと、しっかりしたコーディング規約がないからパターンマッチングの依頼がしにくいけど、厳格で成熟したコードベースならもっと効果的だろうね。
Claudeみたいなツールが、何やってるか分かってないやつらを炙り出すようになるなら面白いだろうな。
「なぜ最小限のボイラープレート言語やフレームワーク、プログラミング環境がないんだ？」って言うけど、Railsみたいに何十年も前からボイラープレート生成コマンドを持ってるものがあるじゃん。
AIモデルが訓練時に利用可能な全チュートリアルやソースコードから、学習すべきことのリストや効率的なコースを作れるってさ。トークンさえあれば24時間いつでもAIをチューターとして使えるんだって。
まさにそれ。AIに全てを任せるのは、未来永劫同じクソみたいなアーキテクチャで立ち往生する「グラウンドホッグデー」状態に陥るってこと。自動化は柔軟性の真逆を行くからね。だからAIには破滅的な予感がするんだ。
「ボイラープレートは必要だ」って言うのは「釘一本一本にハンマーが必要だ」って言うのと同じだよ。ある程度のボイラープレートはいるけど、基本的には最小限にすべき。ここ10年くらい、残念ながら意図的に増やしてる傾向にあるんだよね。
LLMを使うなら、根本概念やプロジェクトのアーキテクチャを理解してないと苦労するよ。LLMの問題は知識不足か、「2文で全て解決」という過度な期待から来てるんだ。思考をLLMに丸投げは無理。プロセス全体に関わり、知識を持つ必要がある。何が起きているか、何をしたいのか分からなければ、難しいだろうね。
RustやTypeScriptの時代では、コーディング規約は明確で必須だよ。僕のプロジェクトでは全部CIを使って、スタイルや型チェックを含むテストをしてる。AIエージェントはミスしても、テスト失敗を見て自分で修正するんだ。もし1999年のPerlやPHPみたいに適当にコードを書いてたら、大変なことになるよ。
コードレビューなしでmainに直プッシュしろって言ってるの？
全然違うよ。相手がエンジニアじゃないなら、RSpec仕様で要件を定義して、エンジニアチームに任せるのがいいって話。プロダクトマネージャーが開発に口出しするケースを見てきたけど、「何を、どう作るか」の役割分担が明確じゃないと、結局はPRフローも回避策で対応されることが多いんだよね。
どうしてテンプレートやインクルードみたいなものが、コアのウェブスタックの一部じゃないのか、理解できないな。（理想的にはJSなしの宣言型でね。）外部ツールやビルドプロセス、サードパーティフレームワークなんて不要なはずなのに。
知識がある場合、LLMでのコーディングは遅くなるんじゃないかな。コーディングは形式的で、正しい方法は一つ、それ以外は無限のバグだ。言語、型システム、リンターでエラーは減らせるけど、まだエラーの範囲は広い。LLMがエラーフリーのコードを生成する確率はどれくらいなんだろう？僕ら人間は、正しいコードのライブラリを使ってエラーを減らしてきたんだよ。
スタートアップ、特に初期段階では、「リリースすること」だけが必須だ。問題は後でいくらでも修正できる。まず「後」があることを保証しないとね。（だからと言って、全く何もしなくていいわけじゃないけど、テクノロジーよりビジネスに集中すべきだ。）
9ダーツを出したダーツ選手に言ってみろよ…いや、Ronnie O’Sullivanにも言ってみたら？君の言ってることは、やっていることに決定論がないってことだけど、それは全然違うよ。
Haskellを学ぶのって難しすぎるとみんな思ってるからね。
俺は30年以上開発してるベテランだけど、LLMのおかげで知らないRubyを何ヶ月もかけて学ぶ手間が省けたよ。LLM使うとPRの質も上がって、チームメンバーと遜色ないレベルのコードが出せるんだ。最初は懐疑的だったけど、実際かなり使えるってわかったよ。
もっとコメントを表示（1）
LLMは、使い方をわかってる人が使えばマジで生産的だね。完璧じゃないけど、ちゃんとプロンプトすればすっげー使える。特に、古ーいカーネルドライバの移植とか近代化にはもってこい。HNでLLMが使えるかどうかの議論が多いけど、これは使えるってハッキリわかる例だろ。数ヶ月前は無理だったことも、今はできるようになってるし、LLMの可能性はどんどん広がってるよ。
ツールは使えば使うほど、いつ役立つかわかるようになるよね。AIを使うかどうかの判断をコイン投げで決めるような研究はマジでバカげてるし、ツールの使い方を根本的に誤解してるよ。俺は「今日はAIを使うぞ」なんて思わないし、まるごと機能を作らせたりもしない。あくまでバカなアシスタントとして使う感じだね。
俺はLLMにまるごと機能を作らせることがあるよ。以前は無理だと思ってたけど、状況次第ではできるようになってきた。まだまだ「できたらラッキー」って感じだけど、たまに驚くほどちゃんと動くからね。
ちょっと言い間違えたわ。UIデザインはBoltでまるごと作らせるけど、バックエンドは自分で書いてる（Copilotをオートコンプリートとして）。既存のデザインから拡張するの苦手だったから、デザイナーに怒られずに正確な画面を作れるのはマジで神だわ。
LLMが実際のコストより高く設定されたときに、本当に役立つのか心配だね。これらのツールに依存しすぎると、将来的にめちゃくちゃ高くなって使い物にならなくなるんじゃないかって不安があるよ。
俺は月20ドルのClaude CodeプランでCoMapsの開発に使ってるよ。ソフトウェアエンジニアリングの経験は少ないけど、LLMのおかげで普段なら無理なことまでできちゃってる。例えば、CarPlayとiOSの検索実装を比較してバグ直したり、コードベースの強力な検索ツールとして使ったりね。もちろん、みんながLLM使ってコードベース知らなくなったらヤバいけど、本物のエンジニアの未来は明るいぜ！
[1] https://codeberg.org/comaps/comaps
[2] https://codeberg.org/comaps/comaps/pulls/1792
[3] https://codeberg.org/comaps/comaps/pulls?state=all&type=all&…
[4] https://codeberg.org/comaps/comaps/pulls/1782
CoMapsへの貢献、ありがとうね。cartes.appのメイン開発者として、地図の世界で自由な取り組みが進むのは嬉しいよ。近いうちにcartes.appのi18nで連携できるといいな。俺もLLMを開発に使ってるよ、主にMistralだけどね。
Claude Codeの月20ドルプランって、どうやって使ってるの？その20ドル以外にAPI料金も別途払ってるんじゃないの？
20ドルのプランだと限定的に使えるって聞いたよ。
Claude Codeはコード記述を任せたい時に使うんだけど、最近すごくニッチな使い方を発見したんだ。オープンソースプロジェクトで困った時、リポジトリをクローンしてCCに問題を調べてもらったよ。例えば、Helix/ZedでZigコードのパラメータ置換に関する問題があったんだけど、CCがtree-sitter grammarを解析して、修正とテストをしてくれたんだ。俺は5分くらい手直ししただけで、CCが30分くらい頑張ってくれた感じ。リポジトリのフォークやPR作成までやらせたよ。その結果、自分でやろうと思わなかったような、みんなに役立つ変更が実現できたんだ。
LLMは、ちょっとした実験やベンチマークを素早く書くのにも役立つよ。例えば、複数のプロセスが同じ変数にアクセスする時に、キャッシュラインがコア間で移動するのにどれくらい時間がかかるか知りたかった時、詳細なベンチマークアルゴリズムを書いたら、LLMが瞬時にコードを生成してくれたんだ。俺はアルゴリズムを完全に記述しただけで、LLMはそれをコードに変換しただけだけどね。自分で書くより、数分で答えが得られるのは本当に便利だよ。
あとね、LLM（少なくとも無料版）って時々かなりおバカで、明らかなことに気づかないんだ。例えば、テストコードを書かせると、すごく重複したコードを生成して、ヘルパー関数にまとめたり、パラメーター化してテストを結合したりしないんだよね。毎回手動で直さなきゃいけないんだ。たぶん、コードをワンパスで生成するから、戻って問題を修正できないんだろうね。LLM開発者さん、生成したコードをLLM自身でレビュー・編集できるようにすべきだよ！
俺もそういうことよくあるけど、もしLLMに生成したコードをレビューして、重複コードをまとめるように頼んだら、そこそこちゃんとやってくれるよ。
https://github.com/terryyin/lizard は、エージェントが生成したコードで関数が複雑すぎたり長すぎたり、重複が多すぎたりするのを追跡するのに役立っているよ。長期的にどれだけうまく機能するかはまだ見ていく必要があるけど、時々問題を検出してくれているし、スクリプトのビルドステップに組み込んであるから、エージェントもその出力を見ているんだ。
LLM（少なくとも無料版）って時々かなりおバカで、明らかなことに気づかないんだよね。例えば、テストを書かせると、すごく重複したコードを生成して、ヘルパー関数にまとめたり、パラメーター化してテストを結合したりしないんだ。
重複したコードを減らすように、プロンプトで指示してる？
どんなプロンプトでも打てるけど、最初から明らかな間違いをしない方がいいと思うんだ。
”DRYコーディングを使え”。この3語で問題は解決できるよ。もしかしたら、親プロンプトに含めるべきかもね。
＞毎回手動でやらなきゃいけないんだ。＜
そう言えば、LLMはコードを移動して、今後その共通コードを使うようになるよ。
LLMにコードの説明するって、自分で書くより時間かかることあるよね。例えば、ベクターのテストで毎回手動でデータ作らせるより、ヘルパー関数作ってパラメータ化すれば楽なのに、それをLLMに理解させるのが大変って話。
でも、最初から完璧なコードが出てこなくても、そのズレを修正する過程でLLMとのコミュニケーションがスムーズになることもあるんだ。
「テストケースで毎回手作業でベクター作らないで、ヘルパー関数使って」って指示出してみなよ。LLMがどう動くか見て、ちょっとおバカでも、どこがダメか分かれば次どう修正すればいいかスムーズに伝えられるはずだよ。
Claude Codeってマジで「すごい戦力増強」だよな！LLMが出る前から、手が出せなかったプロジェクトにも挑戦できるようになったけど、Claude Codeはさらにそれを加速させた感じ。俺も最近、LangroidのPydantic V1からV2への大幅アップグレードとか、HTMLログやDSLの作成とか、CCのおかげでできたんだ。ドキュメントもかなりCCに手伝ってもらったしね。
[2] https://github.com/langroid/langroid/releases/tag/0.57.0
[3] https://github.com/badlogic/lemmy/tree/main/apps/claude-trac…
https://github.com/langroid/langroid/releases/tag/0.59.0
https://langroid.github.io/langroid/notes/task-termination/
「ドメイン固有のキーワードを使って、できるだけ具体的にプロンプトを書け」って言うけどさ、技術的な知識がないと、どうしても指示が曖昧になっちゃうじゃん？そうするとLLMが勝手に解釈して、意図しないコードを生成してバグの温床になるんだよ。これって「戦力増強」って言われるLLMの、まさに裏の顔だよな。
「タプル用のコンストラクタを持つCクラスが必要」ってプロンプト、俺だったらClaudeが「おいおい、ちょっと待ってくれよ…」って言ってくれることを願うわ（笑）。
前のコメントの「タプル用のコンストラクタを持つCクラス」っていうプロンプト、試しにQwen3-Coderで動かしてみたら、汎用Tuple構造体、Constructor、型安全なSetter／Getterとか、C言語でそれっぽいコードを吐き出したんだよ。モデルの学習データにこういうリクエストがよくあるんだろうね。コードは素朴で遅かったけど、機能は問題なかったよ。
ChatGPTに「指定したフィールドで構造体を作るマクロと、内容をプリントする関数」頼んだら、絶対に動かない再帰マクロを吐き出して失敗したんだよ。LLMってCマクロは特に苦手みたいだね。もしすごいコードアシスタント使えるなら、デストラクタ関数生成も合わせて試してみてほしいな。
「タプル用のコンストラクタを持つCクラス」って言ったら、LLMは最初にC++で書いちゃったんだよ。で、「いやCで」って言ったら、「Cにはクラスとかコンストラクタはないよ。Structと初期化関数を使うんだ」って教えてくれて、ちゃんとCのコードを生成してくれたんだ。
この手の記事を読むとさ、LLMが登場する前の世の中って、やりたい仕事の量に対して、人手が全然足りてなかったんだなってつくづく思うよ。
LLM使ってコード書くと、アイデアからMVPまで一晩で作れちゃうんだよ！GeminiやChatGPTでプロジェクト計画立てて、Claudeに実装させながら俺はTV見てるって感じでさ。LLMがなかったら、もっと急ぎの用事があったから、ニッチなBlu-ray販売店の価格監視ツールみたいな「これ役に立つかも？」ってアイデアなんて、絶対試さなかっただろうね。
LLMを使ってもプロジェクトにかかる時間は変わらないけど、連続した集中がいらなくなるから、精神的な負担がめちゃくちゃ減るんだよね。これって結構すごい利点だと思うんだけど、あまり語られてない気がするな。
まさにこれなんだよな。マジで驚くべきことだよね。今Claudeにアイデアを処理させてる間に、俺このコメント打ってるし。
もっとコメントを表示（2）
課題は作業不足じゃなくて、専門知識を持つ人が少ないことなんだよな。LLMも人間の監督なしじゃ無理だし、その監督できる人が全然足りない。Alan KayとJoe Armstrongの話にもあったけど、形式仕様がないと古いドライバの移植は人間頼りになっちゃうんだよ。LLMはパターンマッチングしかできないからね。¹https://www.youtube.com/watch?v=axBVG_VkrHI
ハードウェアの仕様書って普通あるんだけどさ、まず非公開のことが多いし、あと仕様通りに動かないバグをソフトウェアでごまかすから、その情報が仕様書に反映されないことが多いんだよ。これ、20年以上前から見てる現実なんだよね。
AIが専門家を完全に置き換えなくても、需要が減る可能性はあるんだ。もし今働いている人たちの生産性が上がれば、同じ仕事でも必要な人数は少なくなる。そうすると、他の分野から人が流れてきて、専門家が一人も置き換わらなくても、仕事の量が人より少なくなっちゃうってことも簡単に起こりうるよね。
ボトルネックって、アイデアの実装よりも「売れるアイデア」のほうにある気がするな。人が実際にお金を払ってくれるものって、そんなにたくさんないし。
やらなきゃいけないことは山ほどあったけど、もっと重要なことが絶対的に優先されちゃったんだよね。
需要って無限なんだよな。常に新しいものが欲しいし、もっと早く、小さく/大きく、軽く、安くって、ずっと思ってるから。
懐かしいなぁ！子供の頃、俺の親が持ってた386か486のPCに、Colorado Jumbo 250ってフロッピーテープデバイスが繋がってたんだよ。容量は125MBだったけど、圧縮で250MBって宣伝されてた。Linux ftapeドライバでは使ったことないけどね。親の物置にまだあるかも。今PCにフロッピー端子があるかわからないけど、試してみるのも面白い週末プロジェクトになりそう。クールなプロジェクト、作者に拍手！
子供の頃、俺の486で使ってたテープドライブを思い出そうとしてたんだけど、まさにこれだよ。教えてくれてありがとう！
AIがカーネルハッキングの参入障壁を下げるって疑ってたけど、本当だと嬉しいな。組み込みやARMハードウェアのサポートが広がるし、スマートデバイス用の新しいOSも出てくるかもね。
障壁なんて元々なかったよ。
だって筆者はCとカーネルモジュールに経験があるんでしょ？
新しいOSの夢は甘いね…
Cを知ってる人なら1週間、知らないプログラマーでも2週間でカーネルハックを始められるはず。以前は数ヶ月かかってたから、習熟が桁違いに速くなるのはマジでデカい。
”絶対的にデカい”って、LLMが作るセキュリティホールみたいにね。／s
AIは正しく使えば早く習得できる手助けになるよ。でも残念ながら、ほとんどの人はAIに家全部を作らせたい（全部やらせたい）って思ってて、釘を打つのを手伝ってもらう（補助的に使う）ことは望んでないんだよね。
AIがバグや脆弱性を引き起こすような、質の悪いコードを幻覚するのを恐れてるよ。
”スマートデバイス用の新しい小型OS”って、既存のOSで何か問題でもあるの？
人気のOSやカーネルは肥大化しすぎてて、組み込みサポートも不十分なんだ。
例えばFreeRTOSは64ビットIntelアーキテクチャをサポートしてないし、Androidアプリみたいな感覚で使えるものじゃない。
シンプルで目的特化型なアプリを、あらゆるハードウェアで動かしたいんだよ。
それがもっと簡単になれば、新しい技術や製品が生まれるはずさ。
RTOSはたくさんあるけど、Zephyrが一番洗練されてるね。
FreeRTOSはOSというより”Scheduler”に近いよ。
本当に「クロスプラットフォーム」なOSが欲しいの？
それとも「ESP32のアプリをAndroidで動かしたい」の？
後者なら適切な抽象化レイヤーでできるよ。
AIツールを使った情報だとCoCに反するからって、OpenSourceプロジェクトでバグ修正を提案したらBANされちゃったよ。マジか。ClaudeにRustで全部作り直してもらおうかな。
URL: https://codeberg.org/superseriousbusiness/gotosocial/src/bra…
「AIツールで作った変更は認めない。AIは低賃金労働者や著作権者を無視してるから倫理的にダメだ」っていうCoC、これどう思う？納得できない？それとも倫理とかどうでもいいって感じ？俺はプロジェクトがはっきりした態度をとるの、いいと思うけどね。Dynamiclandの議論も深くて面白かったよ。開発者って倫理意識低い人多くない？
URL: https://dynamicland.org/2024/FAQ/#What_is_Realtalks_relation…
芸術とか文学は置いといて、FOSSソフトでLLMを学習させるのは、ライセンスの精神的にはOKなんじゃない？ただ、FOSSのボランティア労働問題は解決しないし、それはLLMが出てくる前からあった問題だけどね。
「FOSSソフトはライセンスの精神に沿ってる」って、MITとかApacheみたいな緩いライセンスの話でしょ？他のライセンスの精神とは全然違うからね。
FOSSライセンスの「精神」ってのは、80年代のGNUプロジェクトとかFSF、ユーザーの自由を守るってところから来てるんだよ。これは歴史的な事実だから、GNUやFSFを批判する人だって認めるはず。君のコメントはFOSSライセンスの歴史を知らないからじゃない？これを読んでみたら？
URL: https://en.wikipedia.org/wiki/GNU_General_Public_License
コピーレフトライセンスの精神には、あまり合ってないんじゃないかな。
「AIモデルは低賃金労働者やコンテンツ所有者をリスペクトしない。倫理的にダメだ」って言うけど、この倫理って、結局は利益のためでしょ？たとえどんなに些細な動機だとしてもね。
君は「尊重」が「支払い」を意味するって思ってるかもしれないけど、単に「認識」って意味だってあり得るんじゃない？
逆に、もし動機が利益だけなら、それは倫理とは呼べないよね。（それに、非営利の動機がなきゃ、OpenSourceのエコシステム自体、そもそも存在しなかっただろうし！）
