Jellyfin LLM/「AI」開発方針

概要

Jellyfinプロジェクトは、 コード品質 と 透明性 を重視。 LLM（大規模言語モデル）利用増加により、 貢献ポリシー を明確化。直接的なコミュニケーションでの LLM出力禁止。コード貢献には 責任と説明能力 を要求。違反時には 削除・拒否・BAN 等の厳格な対応方針。

JellyfinにおけるLLM利用ポリシー

Jellyfinプロジェクトは コードの可読性・簡潔さ・シンプルさ を最重視。
過去の複雑で壊れやすいコードベースの反省から、 手動による品質管理 を徹底。
LLM（例: Claude Code, ChatGPT）の導入が増加、 利便性とリスクの両面 で議論。
公式プロジェクトおよびコミュニティ全体に 統一ルール を適用。

一般ガイドライン

LLM生成出力の 直接投稿は禁止。
- 対象: issue、コメント、機能要望、プルリクエスト本文やコメント、フォーラム・チャット投稿
投稿内容は 自分自身の言葉・説明 で記述。
違反時は 該当投稿の削除・クローズ を実施。
英語で意図を伝えにくい場合の LLM翻訳補助は例外的に許可。
- その旨を明示し、可能なら 原文も併記。

コード貢献におけるLLM利用

「雰囲気コーディング」は却下、コミット内容に 責任を持つこと が原則。
PRは 対象範囲を明確に限定、関係ない箇所への影響があれば却下。
大規模なPRは小分けに分割 し、履歴とレビューのしやすさを確保。
フォーマット・品質基準を厳守。
- 無意味なコメント、スパゲッティコード、不要な空白行等は LLM出力と見なして却下。
- LLMメタファイル（例: .claude設定ファイル）やエディタ生成の非コードファイルは コミット禁止。
変更点を 自分の言葉で説明可能であること。
- PR本文やコミットメッセージで 背景・理由を明確に記述。
- LLMの説明文をそのまま貼り付けるのは不可。
動作確認・テスト必須、ビルド・実行が正常でなければ却下。
レビュー指摘への対応能力 が必須。
- 何がどう変わったか理解していない場合や、指摘をLLMに丸投げするだけでは 不合格。
機能追加・リファクタリングには深い理解が必須。
- 理解不足が明らかな場合は却下。
PRは 複数の独立したコミット で構成、適宜squash対応。
大規模変更は 事前協議・レビュー・テスト 等の既存方針も遵守。
最終判断はレビュアーの裁量。
- 適切にレビューできないPR（複雑すぎる・巨大すぎる等）は 分割提出を要求。
LLMの自動生成コードをそのままコミットするのは厳禁。
- 努力のない安易な貢献は 受け入れ不可。
LLMは 補助ツールとして利用可能 だが、 唯一のソースにしないこと。

サードパーティ・プロジェクトの扱い

主にLLMで開発したプロジェクトは明示的に表記。
- 利用者が受け入れるか否かを判断。
ドキュメントやフォーマット等でLLMを補助的に使った場合も 開示推奨。
ライセンス遵守・貢献者の正当なクレジット付与 を厳守。
- Git履歴の改ざんや第三者コードの無断コミットは BAN対象。
- コード盗用や不正な帰属は 一切容認しないゼロトレランス方針。

コミュニティでの対応

LLM生成ツール等を理由に 通報・排除運動をしないこと。
- 利用可否は 各利用者の自由意思。
モデレーターは LLM検証のための調査を行わない。
- 明らかな違反のみ対応、 疑わしいだけなら無視・スルー。
ライセンス違反等はLLM利用の有無に関わらず厳格対応。

まとめ

Jellyfinは品質と透明性を最重要視。
LLM利用には 責任・説明能力・テスト・開示 が必須。
安易な丸投げ・雰囲気コーディングは認めず。
ライセンスとクレジット遵守、違反には厳格対処。
コミュニティ全体で健全な開発環境維持を目指す方針。

Hackerたちの意見

LLMの出力を直接的なコミュニケーションに使うのは禁止されてる。もっと見たいな。LLMのヘビーユーザーだけど、自分のコミュニケーションは100%自分で書いてる。LLMが書いたものを送らないでほしい。LLMの出力を読みたいなら、LLMに聞くから。

└

そうそう、メールを短くするためにLLMを使ってる。長文を書くのは得意だけど、短くて簡潔なメールが必要なときにすごく助かる。でも、結局は全部自分で書いてるよ。

└

LLMのコードも同じだね。LLMが書いたコードをレビューしたくない。自分はテキストやコミュニケーションを書くためにLLMを使ってるけど、それが仕事で嫌な部分だから。

└

LLMを使って英語のコミュニケーションを翻訳したり修正したりするための特例があるのは嬉しい。LLMはオープンソース開発を本当にグローバルにしてくれる素晴らしいアクセシビリティツールだよ。翻訳や文法の修正はLLMが得意なことだからね！でも、それは翻訳であって、「この変更のためのプルリクエストメッセージを生成して」っていうのとは違うよね。

└

関連リンク: https://noslopgrenade.com

└

うん、LLMに聞くこともできるけど、何を聞くべきか分かってる？ mechanicのジョークみたいに、車を一回レンチで叩いただけで100ドル請求するってやつ。

└

Redditでよく見かける光景だよ。誰かがコードを書いて、それをLLMのマーケティング文でサブレディットにスパムするんだ。ほんと、手抜きで質も低いし。

└

完全に同意だな。LLMにたくさんのコードを書かせてるけど、自分の文章は自分で書いてる。なんか変な「二つの心を持つ」状態だよね。自分の文章は自分のものであるべきなのに、コードはそうじゃなくていいの？唯一の説明は、どこかでコードは重要なものじゃないってこと。ユーザーはコードがどう見えるかなんて気にしない、ただ製品が動くことが大事なんだ。一方で、文章は直接自分の思いを伝えるためのものだから、AIにその仕事を任せると何かが失われる気がする。テッド・チャンの素晴らしい話『事実の真実、感情の真実』のこの引用をよく思い出す。

「彼が書く練習をするうちに、ジジンギはモズビーが言っていたことを理解するようになった。書くことは単に誰かの言葉を記録する方法ではなく、自分が言う前に何を言うかを決める手助けになることができる。そして、言葉は単に話すためのものではなく、考えるためのものでもある。書き留めることで、思考を手の中のレンガのように把握し、異なる配置に押し込むことができる。書くことは、ただ話しているだけでは見えない形で自分の思考を見つめ直すことを可能にし、それを見たことで改善し、強化し、より詳細にすることができる。」でも、LLMにコードを書かせるのはいいけど、文章はダメというのは明らかに矛盾があるよね。この引用が自分のコードにも当てはまるんじゃないかって思う。文章とコードの間に本当に違いがあるのか、それとも単にコーディング部分を自動化するのが便利だから認めているだけなのか、決めかねている。

└

同僚の中にはコパイロットを使ってる人がたくさんいるけど、ほんとバカみたいだよ。ハイテンションな企業のドローンスタイル、何にでも絵文字を使うし、箇条書きだらけ。正直、彼らが伝えようとしているメッセージの価値を下げちゃってると思う。これを見ると、すぐに「はぁ？」って感じになる。

└

この件については、ライナスの意見に賛成だな。どうやってそれを強制するつもりなの？俺がこれをLLMで生成したわけじゃないってどうやってわかるの？

完全に合法に見えるし、新しい貢献者がAIが生成したものを学んで理解する手助けになることを願ってる。

いつかLLMやAIのコード貢献のための「PEP-8」みたいなドキュメントが必要になると思う。プロジェクトごとに再利用可能で採用可能な「エージェントポリシー」みたいなやつを作って、コードベースに触れる前に読んでおくべきだと思う。プロジェクトのポリシーによっては、自分の貢献が受け入れられないかもしれないって警告するような。GPLやBSD、MITみたいに、そういうのがあってもいいと思う。特にプロジェクトのニーズや希望を尊重する人たちにとってはね。サンなLLMコードやバイブ感のあるコードには確かに余地があるけど、自分の変更を検証したり、全てのテストを実行したり、出力やその影響を理解するために少し手間をかけないといけない。開発者にPRを押し付けて受け入れてもらえるのを期待するだけじゃダメだよ。オープンソースのPRは、リグレッションを引き起こさないような戦略的なコードの塊であることが多いけど、LLMはそれを知っているわけじゃないし、気にもしてない。バイブ感でコードを書く人はプロジェクトの期待を知らないかもしれない。行動規範の代わりに、プロジェクトの期待をカバーする「コードの期待」みたいなドキュメントが必要だと思う。

└

どんなエージェントも、コードベースに触れる前に読むべきで、ユーザーに彼らの貢献が受け入れられないかもしれないと警告するべきだって言ってるの？ FOSSコードを書くための特定のエージェントのことを話してるの？そうじゃなければ、なんで全てのエージェントにこんな風に行動させたいのか分からないよ。いつも言ってるけど、貢献者がコードベースと貢献プロセスを理解するのは彼らの責任だから、貢献しようとする前に理解しておくべきなんだよね。もし理解してなかったら、反発を受けたり、貢献が削除されたりするかもしれない。それはほぼ予想されることで、結局「助けよう」としてるのに何も分かってないなら、スパムみたいなもんだからね。誰かが貢献する前にこれを理解していることは、FOSSがプロジェクトでのコラボレーションについてどう機能するかを理解する一部なんだ。一部のプロジェクトは非常に厳しいガイドラインを持っているし、他のプロジェクトはかなり緩いから、貢献者に何を期待しているのかを見極めるのは自分次第だよ。

発展途上国の多くの人たちが、地球上のあらゆるオープンソースプロジェクトにLLMのコミットをスパムしてると思うし、プロジェクトやプログラミング言語を理解してない人も多いから、このポリシーにはあまり注意を払わないんじゃないかな。自動化で「貢献」をプロジェクトにバンバン送り込んで、履歴書やポートフォリオに一つでも入れられればいいっていう数字ゲームになってる。

└

ポリシーは何かを防ぐためにあるんじゃなくて、PRスレッドをロックする時に指さすサインを持つためにあるんだよね。

LLM/"AI"、「AI」を引用符付きで好きだな。

└

「AI」を引用符で囲むのはちょっと矛盾してると思うけど、使うことを許可するのはどうなんだろう。これは知的だよ。

このポリシーがいつ導入されたのかは分からないけど、最近Jellyfinが結構大きなアップデートをして、たくさんのバグやパフォーマンスの問題が出てきたんだ。彼らの問題トラッカーを見てると、LLM生成のPRが溢れてて、明らかにLLM生成のPRコメントや説明、返信も多い。LLM生成のPRは、2〜8個の異なる問題が一つのPRにごちゃ混ぜになってることが多いから、これを整理するのは本当にイライラするよね。実際に問題を修正する時間を奪われてる感じがする。

└

最近、バグを報告する時はこのアプローチを取ってるんだ：1. 問題の完全に人間が書いた説明と、追加できる情報を全部盛り込む 2. バグに添付する形で（PRじゃなくて）、AIの適当な修正を明記して、症状が消えるっていうメモを付ける。こんな形式のバグ報告を受けたことがあって、結構役立ったと思った。AIの修正はクソだったけど、そのパッチでバグが消えたっていうのは有用なシグナルだったよ。

└

誰でもPRを出せるモデルは今、危険にさらされてるかもね。メンテナが無限に入ってくる適当なものをレビューすることを期待されるのは無理だよ。オープンソースのプロジェクトがコミュニティの貢献を許可するのを諦める未来が見えるかも。もしくは、プロジェクトに対して一定以上の興味を示した信頼できるメンバーだけが貢献できるようになるかもね。

└

こういう考えはしばらく前からあったけど、特にクライアントに関しては、まさにこれがきっかけだったんだ。純粋に「雰囲気でコードされた」パフォーマンス改善のPRが大量にあって、ほんとに処理するのが大変だった。

つまり、あなたが提出するコード（自動PRを通じて提出されるものも含めて）に対して責任があるってことだよ。どんなに素晴らしいツールを使っても関係ない。とはいえ、具体的に指摘するのは理解できる。彼らの書き方が好きだな。関連リンク:

最近、Wikimediaのwikitech-lのディスカッションリストで話し合いがあったんだけど、参加者の一人が言ったコメントが印象に残った。

「人々があなたがLLMを使っているとわかるなら、それは使い方が間違っていると思う。」その人は続けてこう言った。「提出するパッチは完全に理解していることが期待されている。LLMを使って助けてもらう分には誰も文句を言わないし、気づきもしないだろうけど、仕組みを理解せずにLLMが作ったパッチを盲目的に提出したら、すぐに人々はイライラするだろう。」

これは新しいことじゃないってわかってるけど、「私たちと話すときは、人間の言葉を使わなきゃダメ、コピー＆ペーストのLLM出力はダメ」っていうポリシーが必要だなんて、ほんとに信じられないよ。「自分がコミットするコードを理解していなきゃダメ」ってのもね。若い頃は、時代の変化にオープンマインドで、頑固にならないと思ってたけど、誰かがChatGPTで返事をしてくる「会話」に入ると、もう完全に頑固者になっちゃう。

└

彼らはすぐに自分たちで分かれるよ。ChatGPTを使ってる人たちは、同じような人たちと話して楽しむだろうし、うまくいくと思う。

└

LLMの出力を堂々と使うのは、最初からターゲットオーディエンスに対するリスペクトがないよね。もしあなたの文章の文脈や内容を理解するために必要なメンタルキャピタルを使うことが期待されるなら、少なくとも実際にそれを執筆する際には同じことをしていることを期待するよ。

└

ランダムな人の顔にカメラを突っ込むのが失礼だと一般的に見なされているのと同じように、これが受け入れられるようになればいいなと思う。そういうことをする悪い奴は必死で、そう見られるだけだしね。俺はLLMにテキストをコピー＆ペーストすることはできるけど、その出力をくれたり、出力を自分の作品だと偽ったりするのはやめてほしい。

JellyfinのLLMガイダンスに書かれているこのポリシーの意図は理解できるし、大体同意もする。貢献者やメンテイナーの時間を守るために、低労力で未検証の「見た目が信頼できそうな」LLM出力が問題やPR、サポートチャンネルに投げ込まれるのを防ごうとしているんだよね。ただ、「LLMが書いたテキストは絶対に投稿しない」っていう一律のルールは正しい境界線だとは思わない。なぜなら、2つの全く異なる行動を混同してしまうから。1つは、未レビューのLLM出力を実際の調査や理解のように投稿すること（これは悪いことで、確かにこれは抑制すべきだと思う）、もう1つは、人間が作業をして結果を検証し、LLMをツールとして使って明確で構造的な要約を作成すること（これは良いことで、しばしば有益）。人間もLLMも、理解して物事を進めるためには文脈が必要だよ。特にバグ調査に関しては、ワークフローの一部としてLLMを使うのがますます最適になってきている。ログを推理したり、再現手順を考えたり、考えられる根本原因を探ったり、その調査結果を簡潔にまとめたアップデートを作成したりするんだ。今朝、オープンソースの「AIフレンドリー」なプロジェクトに取り組んで、まさにこれをやった。報告者がLLMを使って問題を提出したんじゃないかと思うけど、俺は人間としてそれを読んで、LLMを使って調査した。俺が投稿したコメントは簡潔で技術的で、次の人が作業を続けるための有用な文脈を加えている。最も重要なのは、俺がそれを正確だと思っていること。わざわざそのコメントをもっと人間らしく聞こえるように書き直すために、誰かの時間を無駄にする価値があるのか？だから、Jellyfinの目標には賛成だよ（AIスパムなし、検証できないコンテンツなし、メンテイナーへの余分な負担なし）。ただ、「LLMの関与」が正しい線引きだとは思わない。正しい線引きは、責任と検証だよ。

ハクソク