AI時代のOSS貢献：メンテナーに負担をかけない4週間プラン

OSSに貢献してみたい人なら誰でも、初心者の方でも、AIをよく使う方でも読めます。コミュニティの進め方を事前に知っている必要はありません。用語にはどれも身近なたとえを添え、gitの実例は印をつけてあるので、まだ必要なければ読み飛ばせます。

数字は公開情報から取っており、末尾に一覧があります。「例」と書いたものは作った例で、実在の人物やプロジェクトには触れていません。この記事は私自身の貢献体験談を書いていません。語れる体験がないからです。gitの実例は、手元の練習用リポジトリで実際に動かしたものです。AIモデルの内部の仕組みは、まだ誰にも完全には分かっていません。以下のたとえは覚えやすくするための補助です。

---

まず要点#

• OSSのメンテナーは、AIが生成した質の低い貢献を多く受け取っています。Linux Foundation Researchの調査（2026年10月20日）では、メンテナーは**プルリクエストの約25%を「AIスロップ」と見積もり、大規模プロジェクトでは31%**でした。
• 具体例として、curlは2026年1月末でバグバウンティを終了しました。主要メンテナーは、本物と確認された脆弱性報告の割合が15%超から5%未満に下がったと書いています。
• 負担をかけない進め方は4週間に収まります。1週目はプロジェクトを読んで使う、2週目は承認済みの小さな作業を選び、先に聞く、3週目はAIなしで説明できる、テストつきの小さな変更を作る、4週目は明確なPRを出し、AI利用を申告し、フィードバックに落ち着いて対応する。
• ルールはプロジェクトごとに違い、変わるのも速いです。申告と理解を条件にAIを認めるところもあれば、禁止するところもあります。この記事ではなく、貢献先のルールを読んでください。
• 実際に動かしたgitの例（Git 2.56.0）では、小さな変更が3つの段階を踏みます。先にテスト、次に修正、そしてフィードバックを受けて直す、です。最初の実行では「NO TESTS RAN」と出ました。実行したテスト数を必ず書き留める理由の1つです。
• 却下はよくあることです。4週間の目的は、何としてもマージされることではなく、次もあなたの作業を読みたいと思ってもらえる振る舞いをすることです。

---

むずかしい言葉をやさしく#

---

この記事を読むと説明できること#

1. なぜOSSのメンテナーが確認されていないAI生成の貢献を嫌がるのか、そしてなぜプロジェクトごとの方針がまったく違いうるのか。
2. 4週間の順序：ルールを読む、先に聞く、1行ずつ理解した小さなテストつきの変更を作る、それからPRを出してAIを申告する。
3. そのためのgitの流れ：自分用のブランチ、テストつきのコミット、プロジェクトが進んだときのrebase、フィードバック後の修正。

---

1. まずイメージ：他人の工房を訪ねる客として#

主人が1人で切り盛りする小さな木工所が、見学者を受け入れているとします。ある客が入ってきて「ここはもっと良くできると思います」と言い、手作りの品を荷車いっぱいに持ち込んで、あちこちの隅に置いていきます。品物は良いかもしれません。でも主人は1つずつ確認し、場所を空け、壊れたら責任を負わなければなりません。別の客は1週間座って眺め、「この椅子を磨かせてもらえますか」と聞き、椅子を1脚だけ磨いて見せに来ます。主人は2人目の名前を覚えるでしょう。

OSSも同じです。メンテナーは、空き時間や無償で動いている人が多いです。プルリクエストは1つ1つ、確認しなければならない品物です。AIは品物を送るコストを大きく下げましたが、確認するコストはメンテナーの時間のままです。

ポイント： 良い貢献は、送った行数ではなく、メンテナーが「はい」と言いやすくなるかどうかで測られます。

---

2. なぜメンテナーは限界なのか#

2.1 Linux Foundation Researchの調査（2026年10月20日）#

Linux Foundation Researchは2026年10月20日に、報告書「Navigating Open Source Software Development in the Generative AI Era: Challenges and Opportunities for Project Communities」を公開しました。プレスリリースによると、メンテナーは届くプルリクエストの約25%、大規模プロジェクトでは**31%**をAIスロップと見積もっています。同じリリースには、59%のメンテナーが貢献の量が増えていると感じていること（大規模では69%）、約35%のプロジェクトにAIを許可する正式な方針があること、32%には方針も予定もないこと、61%の貢献者がAI生成コードを提出前に詳しくレビューし十分にテストしていると答えたこと、回答者がコードを書く時間を平均で約52%短縮できると見積もっていることも書かれています。

注意して読んでください。これは調査回答者の見積もりで、プルリクエストを数えた数字ではありません。私が読んだプレスリリースには、回答者数が書かれていませんでした。読んだのはプレスリリースで、報告書の全文ではありません。調査に答えてくれる人に偏っている可能性もあります。

ポイント： 問題は本物で、計測もされています。ただ、多くのプロジェクトにはまだ明確なルールがありません。ルールは自分で探しに行く必要があります。

2.2 1つのプロジェクトの例：curlがバグバウンティを終了#

curlの主要メンテナーであるDaniel Stenbergは、2026年1月26日の記事「The end of the curl bug-bounty」で、curlにバグバウンティはもうなく、2026年1月31日で終了すると書きました。2025年より前は、本物の脆弱性と確認された報告の割合が「15%を超えていた」のに対し、2025年からは「5%未満」、つまり20件に1件も本物ではないと述べています。理由として、AIスロップ、人間による質の低い報告、一部の報告者の悪意ある姿勢を挙げ、金銭的な報酬がそうした悪用を招いたのではないかと推測しています。AIスロップを送る人は引き続き禁止するとも書いています。

これは1つのプロジェクトと、その内部にいる人の見方です。すべてのプロジェクトが同じだという証拠ではなく、金銭の報酬はcurl特有の要因かもしれません。

ポイント： 受け手があふれると、扉を閉めます。扉が閉まると、良い貢献者も困ります。

2.3 GitHubがメンテナーに道具を追加#

2026年2月13日、GitHubはリポジトリの設定を2つ追加しました。プルリクエストを完全に無効にする設定と、書き込み権限のある人だけが新しいプルリクエストを作れる設定（誰でも読んでコメントはできる）です。場所はSettings、General、Featuresです。私が見つけた日本語の開発者ブログには、「コラボレーターのみ」の設定が当時の説明どおりに動かなかったという報告がありました。変わっている可能性があるものとして扱ってください。GitHubは、書き込み権限のないユーザーが同時に開けるプルリクエスト数の上限も追加したと伝えられています（2026年6月、私はニュース記事でしか確認していません）。

ポイント： 見知らぬ人からのプルリクエストを受け付けないリポジトリもあります。まず、貢献したい先がどうなのかを確かめてください。

2.4 実在するポリシー：Ghostty#

ポリシーがどこまで具体的になりうるかを見るため、GhosttyプロジェクトのCONTRIBUTING.mdとAI_POLICY.mdを読みました。書くのは、読んだ時点で読めた内容だけで、あなたが読むころには変わっているかもしれません。これらのファイルによると、プロジェクトはAIによるコード作成を認めていますが、AIの利用をすべて申告すること（ツール名と関与の程度）、提出するコードをすべて理解しAIなしで説明できること、初めての貢献者は先に推薦（vouch）を受けること（そうでないとプルリクエストは自動で閉じられる）を求めています。質の低い貢献を送った人の公開リストもあります。ルールは外部の貢献者に適用され、メンテナーは対象外です。

これは1つのプロジェクトです。もっと緩いところも、AI生成の貢献を全面禁止するところもありえます。この記事は、上で読んだプロジェクト以外には依拠していません。

ポイント： ルールはプロジェクト自身にあります。最初の問いは「何をするか」ではなく、「ここではどう決まっているか」です。

---

3. 4週間プラン#

工房への4回の訪問を思い浮かべてください。1回目は見て、2回目は聞いて、3回目は作業して、4回目は差し出します。以下の時間は目安で、週に数時間です。

1週目：プロジェクトを読んで使う#

やること：

1. 実際に使っているプロジェクトを選びます。使っていないと、何が役に立つのか分かりにくいからです。
2. README、CONTRIBUTING、CODE_OF_CONDUCT、あればAIポリシーを読みます。見知らぬ人のプルリクエストを受け付けているかどうかも確認します。
3. 受理されたプルリクエストを5件ほどと、閉じられたものを5件ほど読みます。説明の書き方や、閉じられた理由に注目します。
4. プロジェクトを手元にインストールして動かし、テストを1回実行します。

持ち帰るもの： 「このプロジェクトの決まりごと」を自分の言葉で書いた5行と、テストを動かすコマンド。

2週目：承認済みの小さな作業を選び、先に聞く#

やること：

1. 初心者向けのラベル（good first issueなど）がつき、誰も担当していないissueを探します。
2. issueとコメントを丁寧に読みます。メンテナーが確認したissueだけが、取り組む価値があります。
3. 担当したいとコメントし、やり方を2、3文で書き、コードを書く前に返事を待ちます。
4. 何日も返事がなければ、大きな変更を勝手に進めないでください。もう一度聞くか、別の作業を選びます。

持ち帰るもの： メンテナーから返事をもらった、短くて丁寧で明確なコメント1つ。

3週目：小さく、テストつきで、理解した変更を作る#

やること：

1. 自分用のブランチを作ります。問題を再現する失敗するテストを書き、そのテストが通るまで直します。
2. 目的は1つだけにします。同じPRで整形や一括リネームをしないでください。
3. プロジェクトのテストをすべて実行し、実行したテスト数を書き留めます。
4. プロジェクトが許すならAIを使ってもかまいませんが、このテストをしてください。AIを切って、変更した行を1行ずつ声に出して説明します。相手は他の人でも自分でも構いません。 説明できない箇所は、まだ理解していないということで、提出する準備ができていません。

持ち帰るもの： きれいなコミット1つのブランチと、動くテスト。

4週目：明確なPRを出し、AIを申告し、落ち着いてフィードバックを受ける#

やること：

1. 第5章のテンプレートでPRの説明を書きます。問題、修正、確認方法、そしてプロジェクトの求める形のAI申告です。
2. 送る前に自分のdiffをレビューします（AIが書いたコードのレビューを参照）。
3. フィードバックが来たら、短く返信し、求められたことだけを直し、プロジェクトが進んでいればrebaseします。
4. 却下されたら、お礼を言い、分からなければ質問し、議論はしません。

持ち帰るもの： メンテナーが一目で目的と確認方法を把握できるPR。

---

4. 実際に動かした例：小さな貢献のgitの流れ（gitをまだ使わないなら読み飛ばせます）#

本物の工房に入る前に、模擬の工房で練習するようなものだと考えてください。手元に「模擬の工房」を作りました。プロジェクトの「元」にあたるbareリポジトリと、「あなたのfork」にあたるクローンです。以下のコマンドはすべて、Git 2.56.0とPython 3.14.8で実際に実行しました。コミットのハッシュは、あなたの環境では変わります。

注意：これはGitHubではありません。GitHubでは、Webでforkボタンを押し、自分のforkにブランチをpushし、Webでプルリクエストを作ります。共通するのはgitのコマンド（ブランチ、コミット、rebase、修正）です。例の「プロジェクト」はtextkitという小さなライブラリで、タイトルをWebアドレスの一部に使う短い文字列に変えるslugify関数があります。「問題」は、slugify("Hello World!")がhello-world-と、末尾に余分なダッシュをつけて返すことです。

4.1 修正の前に：テストを実行し、ブランチを作る#

$ python3 -m unittest -q
Ran 1 test in 0.000s

OK

$ git switch -c fix-slug-trailing-dash

最初の実行は、静かに失敗していました。 「Ran 0 tests」と「NO TESTS RAN」と出たのです。testsフォルダに__init__.pyがなく、テストランナーが何も見つけられなかったからです。赤い行は1つもなく、テストが1つも走っていませんでした。だからAIの結果に自分で証明させるは、必ず実行したテスト数を書き留めることを勧めています。「エラーなし」は「確認済み」とは限りません。

4.2 先に失敗するテストを書く#

感嘆符と両端の空白があるケースのテストを足し、修正前に実行しました。

$ python3 -m unittest -q
FAIL: test_no_trailing_dash (tests.test_slug.SlugTests.test_no_trailing_dash)
Traceback (most recent call last):
  File "tests/test_slug.py", line 10, in test_no_trailing_dash
    self.assertEqual(slugify("Hello World!"), "hello-world")
AssertionError: 'hello-world-' != 'hello-world'

Ran 2 tests in 0.000s

FAILED (failures=1)

テストは、期待した理由でちょうど失敗しています。修正前にすぐ通る、または別の理由で失敗するなら、そのテストは問題とは別のものを確認しています。

4.3 修正して再実行#

$ python3 -m unittest -q
Ran 2 tests in 0.000s

OK

$ git diff --stat
 tests/test_slug.py | 4 ++++
 textkit/slug.py    | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

2ファイル、追加5行と変更1行。メンテナーが数分で見られる小ささです。

4.4 明確なメッセージと申告の行を持つコミット#

fix(slug): strip leading and trailing dashes

slugify("Hello World!") returned "hello-world-". Strip dashes at both
ends and add a test for punctuation and surrounding spaces.

AI assistance: used an AI tool to draft the test; I read and ran it.

最後の行は、プロジェクトが申告を求める形の一例です。貢献先のプロジェクトのやり方を使ってください。このテンプレートではありません。

4.5 プロジェクトが進んだ：fetchとrebase#

作業中に、メンテナーがメインブランチにコミットをもう1つpushしました。それを取得し、自分の変更を最新版の上に載せ替えます。

$ git fetch origin
$ git log --oneline --graph --all
* 4cbdd85 docs: add a line on review etiquette
| * 0606d8e fix(slug): strip leading and trailing dashes
|/
* 7835b68 chore: initial textkit

$ git rebase origin/main
Successfully rebased and updated refs/heads/fix-slug-trailing-dash.

$ git log --oneline --graph --all
* ea41359 fix(slug): strip leading and trailing dashes
* 4cbdd85 docs: add a line on review etiquette
| * 0606d8e fix(slug): strip leading and trailing dashes
|/
* 7835b68 chore: initial textkit

同じ変更ですが、新しい土台の上に載ったのでハッシュが変わりました（0606d8eからea41359へ）。古いコミット0606d8eは、先にpushしたブランチに残っています。

4.6 レビューのフィードバック：修正して新しい版をpush#

レビューする人が、空文字列のテストをもう1つ求めたとします。テストを足して実行し、継ぎはぎのコミットを足さず、古いコミットを修正します。

$ python3 -m unittest -q
Ran 3 tests in 0.000s

OK

$ git commit --amend --no-edit
$ git push --force-with-lease origin fix-slug-trailing-dash
 + 0606d8e (旧), d109624 (新): ブランチ fix-slug-trailing-dash (forced update)

$ git diff origin/main --stat
 tests/test_slug.py | 7 +++++++
 textkit/slug.py    | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

本物のGitは、新旧のハッシュを独自の記号でつないだ1行を出力します。ここでは読みやすく書き直しましたが、結果は、サーバー上のハッシュ0606d8eがd109624に置き換わった、ということです。--force-with-leaseは、サーバー上のブランチが想定どおりのときだけ上書きします。使うのは自分のブランチ（PRのブランチ）だけで、プロジェクトのメインブランチでは絶対に使わないでください。修正ではなく新しいコミットの追加を求めるプロジェクトもあるので、プロジェクトの案内を確認してください。

4.7 別の方法：パッチファイルを作る#

変更をメールで送るパッチファイルで受け付けるコミュニティもあります。

$ git format-patch -1 -o ../patches
../patches/0001-fix-slug-strip-leading-and-trailing-dashes.patch

GitHubでは少ない方法ですが、多くの大きなプロジェクトで今も使われています。どの方法を使うかは、各プロジェクトのCONTRIBUTINGに書かれています。

この例についての注記：1人だけの練習用リポジトリで、本物のレビュー担当も、Webの画面もありません。コマンドが動き、貼ったとおりの出力が出ることは示していますが、本物のやり取りがどう進むかは示していません。

---

5. PR説明のテンプレートとセルフチェックリスト#

5.1 プルリクエストの説明テンプレート#

## 問題
1、2文：何がおかしいか、いつ起きるか。issueへのリンク（Closes #123）。

## 修正
1、2文：何を変えたか、なぜこの方法か。

## 確認方法
- テストのコマンド：python3 -m unittest
- 実行したテスト数：3、すべて合格
- 修正前に新しいテストが失敗したか：はい

## AI利用の申告
プロジェクトの求めるとおりに：AIを使ったか、どのツールか、どの部分か。
変更全体を読み、実行し、理解しました。

5.2 送信ボタンを押す前の6つのセルフチェック#

1. 変更の1行ずつを、AIなしで説明できますか？
2. プロジェクトのテストをすべて実行し、実行したテスト数を把握していますか？
3. このPRの目的は1つだけですか？
4. プロジェクトのCONTRIBUTINGとAIポリシーを読み、従っていますか？
5. この作業は、issueでメンテナーに承認されていますか？
6. 説明に確認方法が書かれ、レビューする人がたどれますか？

「いいえ」が1つでもあれば、止まって、先にそれを終わらせてください。

---

6. よくある失敗#

工房の客を思い浮かべてください。客がすると、主人がため息をつくことがあります。

---

7. 例：同じissueでの2つの朝#

実在の人物やプロジェクトに触れない、想定の例です。2人の貢献者が、同じ小さなissueを見つけます。

1人目はルールを読まない：

• 09:00. issueを開き、「簡単な作業」と見て、AIにコードを生成させます。
• 09:40. AIが600行の変更を出します。3ファイルの整形と、余計な最適化も入っています。貢献者は全部を読まないままPRを出し、AI利用の申告もありません。
• 14:00. メンテナーはCONTRIBUTINGを読むよう促して、PRを閉じます。作業は承認されておらず、大きすぎる、と。貢献者は午前中を失い、何が悪かったのか分かりません。

2人目は4週間プランに従う：

• 09:00. CONTRIBUTINGを読み、このプロジェクトがAI申告と事前の確認を求めていると知ります。
• 09:20. 担当したいとコメントし、修正方法を2文で書きます。
• 翌日10:00. メンテナーが「いいですよ、どうぞ」と返信します。
• 翌日15:00. 先に失敗するテストを書き、修正し、テストをすべて実行し、AIなしで全行を読み直してから、追加が約8行だけで申告の行もあるPRを出します。
• 3日目09:00. レビューする人がテストをもう1つ求め、貢献者は15分で直します。

やるべきこと：「先に聞く」段階と「自分で説明する」段階で、自分を止めることです。この2つの段階は約30分かかりますが、双方の午前中を丸ごと節約できることがよくあります。

この例は証拠ではありません。証拠は、第2章のLinux Foundationの調査とcurlの事例です。本物のメンテナーが大きな負荷を抱えて扉を閉めているので、レビューしやすい貢献は本当の贈り物になります。この2つの情報源は、見積もりと内部の人の証言であり、対照実験ではありません。

---

8. 答えつきの練習問題#

練習A. PR説明の欠点を探す#

あるPRの説明は、こうです。「Fix stuff. バグを直しました、AIを使って早く。ついでにフォルダ全体を整形。テスト済み。」

弱点を少なくとも5つ挙げてください。

答え： (1) 具体的な問題が書かれておらず、issueへのリンクもない。(2) 「AIを使って早く」はツールも部分も示さず、読んで理解したとも書いていない。(3) フォルダ全体の整形は2つ目の目的で、別のPRにすべき。(4) 「テスト済み」はコマンドも、テスト数も、修正前に新しいテストが失敗したかどうかも示していない。(5) レビューする人が自分で確認する方法がない。(6) タイトル「Fix stuff」は何も語らない。

練習B. 先に聞くか、すぐ作るか#

練習用リポジトリで、slugify("Xin chào")はxin-ch-oを返します（実際に実行しました）。アクセント付きの文字が消えるのが分かります。すぐに修正のPRを出すべきか、先にコメントで聞くべきでしょうか？

答え： 先に聞きます。アクセント付きの文字をどう扱うかは設計上の判断です。アクセントを外す（xin-chao）、残す、別の文字に置き換える、など。メンテナーには現在の挙動にしている理由があるかもしれず、別のやり方を望むかもしれません。すぐにPRを出すと、コードが正しく動いても閉じられることがあります。起きている現象、いくつかの選択肢、どちらの方向がよいかを尋ねる2、3文のコメントで十分です。

練習C. 修正前に通ってしまうテスト#

slugify("Hello---World") == "hello-world"というテストを足しました。何も変えずに実行すると、すぐ通ります（実際に実行しました）。どうしますか？

答え： これはバグではありません。関数はすでに、連続するダッシュを1つにまとめています。最初から通るテストは、既存の挙動を守るために足す価値はあっても、バグを直した証拠にはならず、「修正」として出すべきではありません。本当の問題が何だったのか、見直してください。

---

9. バランスよく：分かっていること、分かっていないこと#

かなり確か： メンテナーは貢献の量が増え、その中に質の低いものがかなりの割合で含まれると報告している。少なくとも1つの大きなプロジェクト（curl）がこの理由で扉を1つ閉じた。いくつかのプロジェクト（Ghosttyなど）には、AIについて明確な方針がある。

不明、または注意が必要：

• 25%と31%は調査回答者の見積もりで、数えた数字ではありません。報告書の全文は読んでいません。
• curlの事例は、1つのプロジェクトと1人の内部の人の話です。金銭のバウンティがあったため、ないプロジェクトとは違うかもしれません。
• 方針は速く変わります。この記事は、読んだ時点で読めたことだけを書いています。
• 4週間プランに従うとマージされる割合が上がるかを直接測った研究は、見つけていません。このプランは実践の総合であり、実験結果ではありません。

大げさにしない。 PRが受理される保証はありません。プロジェクトは、あなたと関係のない理由で断ることがあります。リリース凍結中、方針の変更、あるいは単に余力がない、などです。

軽く見ない。 AI生成の貢献を全面的に禁止するプロジェクトもあります。出会ったら従い、回避しようとしないでください。

---

10. まとめ#

AI時代のOSS貢献は、敬意の行為です。ルールを先に読み、先に聞き、少なく、レビューしやすく送り、自分が送るものを理解すること。AIは書くのを速くしてくれますが、理解していないものを送るのも速くしてしまいます。上の4週間は、止まる地点を正しい場所に置く方法です。

このgitの流れを練習したいなら、まず練習用リポジトリで試してください。救出用のコマンドはAIエージェントを使う人のGit入門、直す前にバグを再現する方法は探偵のようにバグを追う、腕を保ちながら新しいプロジェクトを学ぶ方法は知らないライブラリをAIと学んで腕を落とさないも参照してください。

---

参考資料#

数字は2026年10月時点の公開情報によるものです。各プロジェクトの方針は変わっている可能性があるので、行動する前に出典を開いて確認してください。

• Linux Foundation, 調査「Navigating Open Source Software Development in the Generative AI Era」のプレスリリース（2026年10月20日）とニュースの要約
• Daniel Stenberg, The end of the curl bug-bounty（2026年1月26日）
• GitHub Changelog, New repository settings for configuring pull request access（2026年2月13日）
• Ghostty, CONTRIBUTING.mdとAI_POLICY.md（2026年10月に読んだもの。方針は変わっている可能性があります）
• Git, git-rebase、git-push（--force-with-lease）、git-format-patchのドキュメント