AI支援コードをOSSに送る前のポリシー確認

AI 支援コードを upstream に送る前に行うこと

現在、オープンソースプロジェクトでは AI 支援コードに関するポリシーが公開されていますが、その内容はプロジェクトごとに異なります。基本的な手順は単純です。パッチを書く前にポリシーを確認し、送信時には正確に開示します。両方に共通する原則があります。レビューで説明できない行は、決して提出しないでください。

正しいパッチでも、プロジェクトが生成コードを禁止している場合や、コードの出所を隠していた場合はクローズされます。その影響はあなたの名前に残ります。後からその不開示に気付いたメンテナーが、あなたのこれまでの貢献を信頼する理由を失うためです。まず、ポリシーで使われる用語を説明します。LLM（large language model）は、コーディングエージェントの基盤となるモデルです。GitHub の PR（pull request）は GitLab の MR（merge request）に相当し、以下の内容はどちらにも適用されます。DCO（developer certificate of origin）は、コミットメッセージ末尾に付ける sign-off 行です。そして、この DCO が議論全体の中心になります。

AI コードに関するオープンソースポリシーの現在地

プロジェクトの方針は、4 つの区分に分かれています。以下の例にはすべて日付があります。これらの文書は変化するためです。

禁止。 Gentoo の council は 2024 年 4 月 14 日、「Natural Language Processing artificial intelligence tools の支援を受けて作成されたコンテンツを Gentoo に貢献することは明確に禁止する」と決議しました。NetBSD の commit guidelines は、LLM の出力を「汚染されたコード」と呼び、「core による事前の書面承認なしに commit してはならない」と定めています。QEMU の code provenance document は 2026 年 8 月時点でも、「AI generated content を含む、またはそこから派生したと考えられる貢献は DECLINE する」としています。

分析のみ。 多くの禁止方針は、見出しから受ける印象より限定的です。QEMU の文書は、この方針が「API やアルゴリズムの調査、static analysis、debugging など、AI の他の用途には適用されない。ただし、その出力を貢献内容に含めないことが条件」と説明しています。agent を使ってコードを読むことはできます。agent が作成したものをリリースすることはできません。この区別が、制限の厳しいプロジェクトの多くで実際に運用されている境界です。しかし、この点を見落とす人が多くいます。

開示が必要。 Fedora の council は 2025 年 10 月、AI-assisted contributions に関するポリシーを承認しました。このポリシーはツールの使用を認め、その責任を個人に負わせます。contributor が著作者であり、貢献全体について全面的に責任を負います。また、重要な部分がツールによって変更なしに作成された場合は、その事実を開示する必要があります。Linux kernel では 2025 年 12 月、process documentation に coding assistants のページが追加されました。そこには使用したツールを記録する trailer と、sign-off できる人に関する厳格なルールがあります。

文書化されていない。 これは現在も一般的なケースです。2026 年 5 月の preprint は、人気のある GitHub repositories 1,000 件を調査し、AI ポリシーを文書化していたものは 118 件だったと報告しました。沈黙は許可を意味しません。patch を作成する前に、issue tracker で 1 文の質問をしてください。そうすれば、その回答が後から示せる公開記録になります。

メンテナーがこのルールを定めた理由

第 1 の理由はレビュー負荷です。計算は一方向に進みます。エージェントは、もっともらしい 400 行のマージリクエストを 1 分で作成します。そのリクエストを適切にレビューするには、メンテナーの半日が必要です。しかも、メンテナーの多くはボランティアです。投稿のコストはほぼゼロになりました。一方、レビューのコストはまったく下がっていません。

curl は、この曲線の極端な側を示しています。Daniel Stenberg は 2025 年半ば、プロジェクトのバグ報奨金制度に届くセキュリティ報告のおよそ 5 分の 1 が、本人の呼ぶ AI slop だったと報告しました。これらは、実在する関数と実在するコードパスを挙げ、もっともらしい攻撃を説明しているものの、中身がありませんでした。プロジェクトは、この流入への資金提供を続けるのではなく、2026 年初頭に報奨金制度を終了しました。これらはパッチではなく報告でしたが、メンテナーが疲れた状態であなたの PR を開くことになる仕組みは同じです。

GNOME Calendar は、この問題をラベルとして明文化しました。2026 年 6 月、プロジェクトは「コード生成における人工的な『知能』への大規模または全面的な依存」が見られるマージリクエストに対して、「Probabilistically Automated」というラベルを導入しました。そして、その症状を正確に次のように説明しました。「通常、適切なテストがなく、コードの正しさではなく理論上の意図した動作に基づいてパッチを仕上げている」。最後の文は 2 回読んでください。コードは動作するように見えます。しかし、実際に動作するかを誰も確認していません。

第 2 の理由はプロベナンス、つまりコードがどこから来たのか、どのライセンスに基づくのかという問題です。QEMU はこの対立を明確に述べています。サインオフによって、あなたが提供する「コンテンツの著作権およびライセンスの状態を完全に理解している」ことを表明します。しかし、モデルの出力に関する著作権の状態は確定していません。Gentoo の評議会も、品質と倫理に加えて同じ理由を挙げました。その法的解釈に同意する必要はありません。ただし、それを判断するのはあなたではなく、メンテナーであることを認識する必要があります。

プロジェクトの AI ポリシーを確認するにはどうすればよいですか？

次の場所を、この順番で確認します。

• リポジトリのルートにある CONTRIBUTING.md、次に .github/CONTRIBUTING.md、その隣にある DCO ファイル。
• 開発者向けドキュメント。QEMU のルールは docs/devel/code-provenance.rst にあります。kernel のルールは Documentation/process/coding-assistants.rst にあります。
• プロジェクトの Web サイトまたは wiki。Gentoo のポリシーは council の wiki ページにあり、NetBSD のポリシーはコミットガイドラインにあります。
• issue tracker とメーリングリストのアーカイブ。ポリシーは通常、リポジトリに記載される数か月前から、これらの場所に存在します。

checkout 内から、次の grep で大部分を確認できます。

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

次に、プロジェクト自身の履歴を確認します。コミット済みの慣例は、それを要約した説明より優先されるためです。

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

trailer の値の横に表示される件数から、そのプロジェクトが実際に使用している形式が分かります。結果が空の場合、その形式ではここで誰も開示していないということです。これも情報になります。プロジェクトが GitHub 上にあり、このワークフローに慣れていない場合は、GitHub で pull request と fork がどのように機能するかで、このセクションが前提とする仕組みを確認できます。

コミットのトレーラーに記載し、コメントには書かない

トレーラーは、コミットメッセージの最後の段落に置く Key: value 行です。Git はすでに Signed-off-by: と Co-authored-by: でこの形式を使用しており、ツールも解析できるため、コードとともにツリーへ確実に引き継がれる開示方法です。

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

カーネルでは、この形式を Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] として文書化しています。行の制限も明記されています。「AI エージェントは Signed-off-by タグを追加してはなりません。Developer Certificate of Origin (DCO) を法的に証明できるのは人間だけです」。エージェントの名前は Assisted-by に記載します。あなたの名前は Signed-off-by に記載します。ツールに後者を書き込ませないでください。また、誰にも属さない Co-authored-by アドレスを生成させないでください。

名前の形式はプロジェクトごとに異なるため、自分で作らず、ローカルの形式をそのまま使用してください。2026 年 5 月に QEMU のメーリングリストへ投稿されたパッチでは、機械的な変更、テスト、ドキュメント、20 行以下のバグ修正について、プロジェクトの禁止方針を緩和する案が示され、AI-used-for: tests, docs のようなトレーラーで記録されていました。2026 年 8 月時点では、これはメーリングリスト上の提案にすぎず、コミット済みの文書では生成コンテンツを引き続き認めていません。あるプロジェクトは、2023 年から 2026 年の間に方針を 2 回変更しました。次の変更はあなたを待ってくれないため、一覧よりも手順が重要です。

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer には Git 2.32 以降が必要です。2 番目のコマンドは、値をそのまま出力するはずです。空行が表示される場合、git がトレーラーを解析できていません。ほとんどの場合、メッセージ末尾のトレーラーブロック内に空行または通常の文章があります。すでに作成した一連のコミットには、git rebase --signoff origin/main で全コミットに sign-off を追加できます。git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt はメッセージファイルを編集します。

計画しておくべき失敗パターンが 2 つあります。squash merge ではコミットメッセージが書き換えられるため、squash を行うプロジェクトでは、メンテナーが確認する PR の説明にも開示を繰り返してください。また、レビューコメントは記録になりません。コメントは編集でき、git の履歴には残らないためです。

正確さは両方向に作用します。自分で手入力したコミットに Assisted-by を付けるのはノイズであり、本当に必要な開示の価値を下げます。エージェントが作成したコミットからこれを外すことは、関係を終わらせる行為です。

Signed-off-by は実際に何を証明するのか

DCO は、developercertificate.org（https://developercertificate.org/）で公開されている version 1.1 の短い文書です。kernel、QEMU など、多くのプロジェクトで使用されています。Signed-off-by: Your Name <you@example.com> を追加することは、その内容を証明することを意味します。何を証明するのかを確認してください。多くの人は内容を読まずに署名しています。

第 (a) 項は、貢献内容が「全体または一部を自分が作成したものであり、ファイルに示された open source license の下で提出する権利を持っている」ことを示します。第 (b) 項は、以前の open source code を基にした成果物を対象とします。変更を加えたうえで、その成果物を渡す権利を持っていることが条件です。第 (c) 項は、同じ内容を証明した人から渡された code を対象とします。第 (d) 項は、貢献内容と sign-off に含まれる個人情報が公開され、無期限に保持されることを理解していると示します。

ここで、含まれていない内容に注意してください。DCO は、すべての文字を自分で入力したとは述べていません。この license の下で code を提出する権利を持っていると述べています。そのため、生成された code はこの条件にうまく当てはまりません。問題は著作者が誰かではなく、出所を説明できるかどうかです。sign-off を必須とするプロジェクトの多くは実名も必須とするため、pseudonym ではチェックに失敗します。git commit -s の行を追加してください。この行は git config から user.name と user.email を読み取ります。DCO bot が PR を失敗させ、不足している行のある commit を示した場合は、git rebase --signoff origin/main を実行して branch に force push すれば修正できます。

コミットへの署名はサインオフと同じではありません

git commit -s はテキスト行を追加します。git commit -S は、GPG または SSH key を使用してコミットオブジェクトに暗号学的な署名を付けます。両者が示す内容は異なります。署名は、このコミットがその key の保持者によるものであり、その後変更されていないことを証明します。ただし、コミット内のコードの出所については何も示しません。そのため、出所を開示していない生成コードを大量に含む署名済みコミットは、署名されていてもポリシー違反です。サインオフは出所に関する表明です。署名は本人性に関する表明です。両方を求めるプロジェクトでは、両方の提出を求めます。

レビューで説明できないコードは提出しない

確認方法は簡単です。これは誠実さを問う話ではありません。各行について、何のためにあり、なくすと何が壊れるのかを説明してください。どちらか一方でも答えられないなら、そのパッチはまだ準備できていません。レビューコメントが届き、その回答のためにさらに生成を繰り返すことになるからです。レビュアーには分かります。その時点で、貢献者はコストになります。境界条件、空の入力、失敗経路、2 番目の呼び出し元についても、同じ質問をしてください。

実際に動かしてください。ビルドし、プロジェクトのテストスイートを実行し、修正したと主張するバグの再現手順を書いてください。kernel のドキュメントには、率直な代替案が明記されています。「修正をビルドまたはテストできなかった場合、あるいは再現手順を作成できなかった場合は、そのことを明示してください。maintainer は現在、検証されていない報告とテストされていない修正の分析に多くの時間を費やしています」。I could not test this on real hardware と書いても、あなたに損失はありません。テストしたかのように示すことは、プロジェクトに損害を与えます。

レビューコメントには、自分の言葉で、自分の時間を使って回答してください。コメントの 30 秒後に届き、内容を 5 段落で言い換えただけの返信を見れば、maintainer には何が起きたかが正確に分かります。diff も小さく保ってください。完全に理解している 40 行の変更は、監督しただけの 400 行のリファクタリングより、プロジェクトにとって価値があります。agent が要求した以上の変更を繰り返し返してくる場合は、動作する最小限の変更に抑える skillを使うと、行単位で説明できる規模にパッチを抑えられます。

リポジトリにエージェントの指示を置く

エージェントに与える指示はツールチェーンの一部です。そのため、コードと同じように扱います。通常は AGENTS.md というリポジトリルートのファイルに、ビルドコマンド、テストコマンド、コミットメッセージの形式、署名要件、プロジェクトですでに文書化されているスタイル規則を記載します。このファイルはバージョン管理とレビューの対象になり、今日も明日も同じ内容を参照できます。記憶を頼りに毎回入力し直した指示では、セッションごとに異なるパッチが生成されます。その場合、却下されたパッチがどのセッションで生成されたのか分かりません。エージェントと人間の両方が読める AGENTS.md の書き方では、このファイル自体について説明しています。

他人のリポジトリを扱う場合は注意が必要です。保守していないプロジェクトへの最初の貢献として、エージェントの指示ファイルを追加する PR を作成しないでください。外部からプロジェクトのツール設定方針を決めようとしているように受け取られます。また、保守担当者がすでに対応に疲れている問題と、あなたのアカウントが結び付けられるきっかけにもなります。誰かに求められるまでは、フォーク内にファイルを置いてください。

同じ理由で、エージェントを実行する場所も重要です。管理下のサンドボックス内でエージェントにプロジェクトのビルドとテストを実行させれば、実際に検証したパッチを得られます。これは、支援を受けたことを開示する場合と、推測を開示する場合の違いになります。自分の VPS でコーディングエージェントを実行する方法では、その構成を説明しています。Claude Code、Cursor、Codex、Copilot の実用上の違いでは、日々の運用で各ツールがどのように異なるかを説明しています。

ポリシーが変更された場合の手順

1. 何かを書く前に、明記されたポリシーを確認します。リポジトリ、開発者向けドキュメント、Webサイト、トラッカーを調べます。
2. ポリシーがない場合は、issue で1文にまとめて質問し、回答を保存します。
3. プロジェクトで指定されている形式で開示し、commit trailer にも記載します。プロジェクトが squash を行う場合は、PR本文にも同じ内容を記載します。
4. その署名がコードを提出する権利を表明するものだと理解したうえで、実名で sign off します。
5. 自分のパッチを、他人が書いたものとしてレビューします。実際に他人が書いたものだからです。

このページで扱う各プロジェクトは、あなたが読む頃には移行を終えているでしょう。5つの手順は変わりません。

FAQ

AI コーディングエージェントを使用したことを開示する必要がありますか？

プロジェクトを確認してください。回答はプロジェクトごとに定められているためです。Fedora では、変更を加えずにツールから得た内容が貢献の重要な部分を占める場合、開示が必要です。Linux kernel では Assisted-by trailer が求められます。2026 年 8 月時点で、Gentoo と QEMU はそのような貢献を一切受け付けていません。明文化されていない場合でも、commit trailer で開示してください。後から知った maintainer は、ツールの使用ではなく未開示に反応します。その反応は、あなたがこれまで送った他の内容にも及びます。

AI が生成したコードを禁止しているオープンソースプロジェクトはどれですか？

2026 年 8 月時点の状況では、2024 年 4 月以降の Gentoo、LLM の出力を汚染されたコードとして扱い、core の承認を必要とする NetBSD、生成コンテンツに由来する貢献を受け付けない QEMU、さらに Loupe や Calendar など複数の GNOME アプリケーションがあります。この一覧は古くなるため、各プロジェクト自身の文書を確認してください。多くのプロジェクトに共通する例外にも注意してください。API の調査、静的解析の実行、デバッグの補助に model を使用することは、通常は問題ありません。出力を patch に含めないことが条件です。

Signed-off-by と署名付き commit の違いは何ですか？

Signed-off-by は git commit -s が追加するプレーンテキストの行です。これは developer certificate of origin を証明するもので、プロジェクトの license に基づいてこのコードを提出する権利があることを示します。git commit -S で作成する署名付き commit は、GPG または SSH key による commit object の暗号署名です。commit がその key に由来し、変更されていないことを証明します。origin と identity は別の主張です。そのため、署名付き commit でも AI policy に違反する可能性があります。

commit message ではなく pull request の説明に開示内容を書けますか？

commit message に書いてください。commit message は git history に残り、後から repository を clone する人にも code とともに伝わる記録だからです。pull request の説明は後から編集でき、hosting platform 上に保存されます。プロジェクトが squash merge を行う場合は、PR body にも追加してください。squash によって commit message が書き換えられ、trailer が失われる可能性があるためです。

AI 生成であることを理由に pull request が閉じられました。どうすればよいですか？

thread 上で policy に反論しないでください。close した人だけで rule を決めたわけではなく、thread は rule を変更する場所でもないためです。policy の本文を読み、自分が条件を満たせるか判断してください。プロジェクトが generated patch を禁止している場合でも、reproducer を含み patch を含まない明確な bug report なら歓迎されます。その方が有用な貢献になることも多くあります。code を再提出する場合は、行ごとに説明できる小さな変更にしてください。