← ラボに戻る

30 のオープンソースプロジェクトが AI の手を借りたコントリビューションに求めること

coding-agentsopen-sourceai-policy

9月27日から10月2日にかけて、十二のオープンソースプロジェクトに修正、バグ報告、コメントを送った。作業の多くはコーディングエージェントがこなした。Claude Code がバグを再現し、パッチとテストを書き、文章のほとんどを下書きした。取り組む Issue はどれも自分で選び、文章もすべて自分で読んだ。私が承認するまで、私のアカウントからは何も送られていない。

その間ずっと、この種の作業をどう進めてほしいのかを、プロジェクトの側から繰り返し告げられた。spec-kit は、エージェント、モデル、その設定、そしてどこまで手伝ったかを、AI が生成したすべてのコメントで明記するよう求めていた。MLX のプルリクエストテンプレートは、「PR の説明文を書くのに AI を使うことは固く禁じられていると理解している」という、チェックの入った一行で始まる。そこで10月2日に、30 のリポジトリのコントリビューションのルールを読んだ。作業を送ったリポジトリと、送っていない 21 のリポジトリだ。

手短に言うと、30 のうち 19 に AI に関するルールがあり、その 19 のうち 14 は2026年にできたものだ。ほとんどのルールは、提出した本人に変更の責任を負わせている。十五のプロジェクトは AI を使ったことを明かすよう求め、十のプロジェクトは、説明文やコメント、コミットメッセージを、モデルではなく人が書くよう求めている。コーディングエージェントがデフォルトで付けるコミットトレーラーを、これらのプロジェクトのあるものは必須とし、あるものは禁止している。

読んだもの

サンプルは無作為ではない。30 のうち九つは、その週に私が作業を送ったプロジェクトで、MLX、spec-kit、huggingface_hub、codebase-memory-mcp、Deskflow、agent-framework、awslabs/mcp、kaggle-cli、avoid-ai-writing だ。残りの 21 は AI ツール、開発者ツール、インフラの分野のプロジェクトで、その中には Docling、garak、TypeScript、Rust、Node.js、Kubernetes がある。作業を送ったプロジェクトのうち残る三つ、copilot-cli、PartCrafter、ltx-2-mlx は 30 には入っておらず、そのどれにも AI に関するルールは見つからなかった。

各リポジトリでは、2026年10月2日時点のデフォルトブランチで、CONTRIBUTING、プルリクエストと Issue のテンプレート、AGENTS.md と CLAUDE.md、行動規範、そしてこれらのファイルからリンクされているガイドや wiki のページを読んだ。以下の引用はどれも、私が読んだコミットにあるその行にリンクしているので、ファイルがあとで変わっても、その日に何が書かれていたかがリンク先でわかる。引用は日本語に訳してあり、リンクを開くとそれぞれ英語の原文の行が表示される。ルールができた時期は、そのファイルの履歴をたどり、ルールを含む最初のコミットを探して特定した。

ルールがあるのはどこか

30 のうち 19 には、コントリビューションでの AI の使用に関するルールがある。MLX、spec-kit、TypeScript、huggingface_hub、transformers、trl、peft、LangChain、Strands Agents、MLflow、garak、codebase-memory-mcp、Deskflow、workers-sdk、pydantic-ai、Rust、CPython、Node.js、Kubernetes だ。

九つのリポジトリでは見つからなかった。accelerate、awslabs/mcp、kaggle-cli、Docling、BeeAI、ADK for Python、NeMo Agent Toolkit、VS Code、React だ。残る二つは数に入れていない。agent-framework は、AI のせいでコントリビューションが増えたのでレビューに時間がかかる、と注意しているだけで、avoid-ai-writing が確かめるのは文章の文体であって、文章がどう作られたかではない。

一つのルールは、たいてい複数のことを同時に求めている。

19 のルールが求めていることを、リポジトリの数で数えたもの。AI を使ったと明かす：15。提出した本人が責任を負い、変更を理解していなければならない：12。説明文、コメント、コミットメッセージを人が書く：10。コミットトレーラーについてのルール：9。大量の、または自動化されたプルリクエストの禁止：7。プルリクエストの前に Issue を立てるか、メンテナーの承認を得る：6

二本目の棒は、私の解釈で数えたものだ。19 のうち 12 が、何らかの形で、提出した本人が変更に責任を持ち、それを理解していなければならないと述べている。huggingface_hub はそれを、「コードを書くのに AI の手を借りるのは構わない。自分で説明できない、AI が生成したガラクタを提出するのは駄目だ」という二文で言い表している。CPython は、作者が「提案する変更を自分の言葉で説明できる」ことを期待しており、Strands Agents はコントリビューターに「プルリクエストの作者はあなたであって、あなたのエージェントではない」と告げている。

ルールができた時期

最初は CPython で、2024年10月に開発者ガイドに短いページを設けた。2025年には spec-kit、LangChain、Kubernetes、MLflow の四つが続いた。残りの 14 は2026年にできたもので、そのうち七つは6月以降だ。codebase-memory-mcp がルールを加えたのは、私が読む十一日前だった。

AI を使ったコントリビューションについてのルールがある 19 のリポジトリが、それぞれ最初にルールを加えた時期を半年ごとに示したもの。2024年7月〜12月：CPython。2025年1月〜6月：なし。2025年7月〜12月：spec-kit、LangChain、Kubernetes、MLflow。2026年1月〜6月：Deskflow、transformers、trl、TypeScript、pydantic-ai、garak、huggingface_hub、peft、Strands Agents。2026年7月〜9月：workers-sdk、Rust、Node.js、MLX、codebase-memory-mcp

ファイルは今も変わり続けている。19 のうち 16 では、ルールを含むファイルが9月か10月の最初の二日間に編集されていた。ただし、そうした編集のすべてが AI についての記述に手を入れたわけではない。

使ったと明かす

もっとも多いのは開示のルールで、どこまで開示を求めるかはプロジェクトによって違う。Kubernetes なら一文で足りる。ガイドには、説明文に「This PR was written in part with the assistance of generative AI」（この PR の一部は生成 AI の助けを借りて書かれた）と入れれば「十分である」と書かれている。TypeScript は、開示がなければ PR をクローズする。「PR が AI によって書かれたように見え、この開示が含まれていない場合、その PR はレビューされずにクローズされる」とある。spec-kit は、エージェント、モデル、設定、支援の範囲を、プルリクエストで、AI が生成した各コメントで改めて、そしてエージェントが書いた各コミットに Assisted-by: トレーラーとして明記するよう求めている。

二つのプロジェクトは、何が懸かっているかを一行で言い切っている。codebase-memory-mcp は「開示がコントリビューションの不利になることは決してない。不利になるのは、あとで発覚することだ」と書き、Deskflow は「コントリビューションでの AI の使用について不誠実であれば、プロジェクトから追放される」と書いている。

CPython の求めはほかより控えめで、「PR の説明文で AI ツールの使用を開示してもらえるとありがたいが、必須ではない」としている。

文章は人が書く

十のプロジェクトは、コードについてはモデルの手を借りてもよいとしながら、文章は人が書くよう求めている。いちばん厳しいのは Rust で、「LLM が作成した PR の説明文は禁止。LLM が作成した GitHub のコメントは禁止」としている。コミットについても同じで、「コミットメッセージは、あなたの LLM ではなく、あなた自身が書かなければならない」とある。

Kubernetes と Node.js は、レビューへの対応のところで線を引いている。Kubernetes は「レビューコメントに返答するときは、AI ツールに頼らずにそうしなければならない」とし、Node.js は、フィードバックへの返答は「AI ツールで自動化してはならない」としている。

テンプレートに組み込んでいるプロジェクトもある。MLX には先に引用した一行と、Issue 用の同様の一行がある。Strands Agents はプルリクエストテンプレートに「Human Overview」というセクションを置き、ここは「AI エージェントが決して記入してはならない」と定めている。LangChain のテンプレートは、「明らかに AI が生成した長い説明文をここに貼り付けると、PR は無視されるか、クローズされることがある！」と警告している。

三つのプルリクエストテンプレートにある実際の行。ml-explore/mlx の .github/pull_request_template.md、1 行目と 2 行目：「☑️ PR の説明文を書くのに AI を使うことは固く禁じられていると理解している」と「AI usage disclosure:」。strands-agents/harness-sdk の .github/PULL_REQUEST_TEMPLATE.md、1〜3 行目：「## Human Overview」、続いてコメント「この PR を AI エージェントが下書きした場合は、人がここに自分の言葉で短い概要を書かなければならない。AI エージェントは決してこのセクションに記入してはならない。team/AI_USAGE_POLICY.md を参照。（50 語）」。langchain-ai/langchain の .github/PULL_REQUEST_TEMPLATE.md、11 行目：「明らかに AI が生成した長い説明文をここに貼り付けると、PR は無視されるか、クローズされることがある！」

大量に送らず、まず承認を得る

七つのプロジェクトは、大量の投稿や自動化された投稿を禁じている。TypeScript が拒むのは、「オペレーターが自律型エージェントを GitHub に差し向け、互いに関係のない多数の Issue にわたってパッチを生成させ、その出力をプルリクエストとして私たちに転送してくるワークフロー」だ。LangChain のガイドは、「プルリクエストを作るのに必要な労力が、メンテナーがそれをレビューするのに必要な労力より小さいなら、そのコントリビューションは提出すべきではない」という、どんなコントリビューションにも当てはまる基準を示している。

六つのプロジェクトは、プルリクエストの前に承認を求めている。peft では、それは @peft-triage approved を含むメンテナーのコメントだ。Rust では、LLM が作成した変更には事前の取り決めが必要で、これは「LLM が作成した PR をレビューする意思があることを、レビュアーが前もって伝えている」ことを意味する。

三つのプロジェクトは、エージェントを使う新規参加者を受け入れていない。transformers は「初めてのコントリビューターは、Issue や PR の作成にコードエージェントを使わない」よう求め、trl は「初めてのコントリビューターからの、完全に AI が生成した PR はレビューしない」としている。Node.js は新しいコントリビューターに「プロジェクトとのやりとりに AI エージェントを使うのを避ける」よう求め、「good first issue」のラベルが付いた Issue を AI で修正することも禁じている。こうした Issue は「AI ではなく、新しい人間のコントリビューターがコードベースについて学ぶのを助けるためのもの」だからだ。

Rust は、こうした作業が占める割合にも上限を設けていて、「6 週間の期間内にマージされた PR の半数を超えるものが LLM によって作成されていれば、50% を下回るまで、LLM が作成した新しい PR のマージを認めない。冷却期間は最低 10 日とする」としている。

意見が割れるトレーラー

コーディングエージェントは、自分の仕事に署名を残すことが多い。たとえば Claude Code は、そうしないよう指示されない限り、各コミットに Co-Authored-By: Claude … トレーラーを、プルリクエストには「Generated with Claude Code」という一行を付ける。こうしたトレーラーについてのルールがあるのは九つのプロジェクトで、ルールの向きは正反対に分かれている。

30 のリポジトリのうち 9 が、AI を共同作成者とするトレーラーについて定めていること。必須：MLflow（Claude Code による変更には Co-Authored-By: Claude）、garak（AI ツール名を記した Co-authored-by）、spec-kit（エージェントとモデルを記した Assisted-by。ツールが付けるトレーラーは残す）、Node.js（エージェント名を記した Assisted-by）。禁止：Kubernetes（AI を共同作成者にすること、assisted-by などのトレーラー）、Rust（Co-Authored-By トレーラー）、pydantic-ai（Claude を共同作成者にすること）、Deskflow（LLM を共同作成者とするタグ）、Node.js（エージェント自身による Co-authored-by や Signed-off-by）。許可：codebase-memory-mcp

出典：MLflow、garak、spec-kit、Node.js、Kubernetes、Rust、pydantic-ai、Deskflow、codebase-memory-mcp。

Kubernetes は「AI ツールを共同作成者として記載すること、AI ツールを使ってコミットに共同署名すること、assisted-by、co-developed またはそれに類するコミットトレーラーを使うことは認められない」としている。pydantic-ai は、Claude Code がセッションの開始時に読み込むファイルに、「コミットに自分（Claude）を共同作成者として決して追加しないこと」と書いている。Rust のガイドは、デフォルトで付くこの二行をどちらも開示の悪い例として挙げている。🤖 Generated with Claude Code と Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> だ。

つまりデフォルトのトレーラーは、MLflow では求められるものであり、Kubernetes、Rust、pydantic-ai ではルール違反になる。どこでも正しい設定というものはない。エージェントはリポジトリで最初にコミットする前にそのリポジトリのルールを読まなければならないし、エージェントを動かす人も同じだ。

エージェントに向けて書かれたルール

こうしたルールの一部は、AGENTS.md や CLAUDE.md、つまりコーディングエージェントがリポジトリで作業を始めるときに読むファイルの中で、エージェントに直接語りかけている。告げている内容は次のとおり。

こうしたルールが機能するのは、エージェントがそのファイルを読み、それに従う場合だけだ。

私が送ったものはどうなったか

十二のうち五つに AI に関するルールがある。MLX、spec-kit、huggingface_hub、codebase-memory-mcp、Deskflow だ。huggingface_hub では Issue を立てただけで、そのルールはプルリクエストについてのものだ。MLX では、ルールが求めるとおり、プルリクエストの説明文とコミットメッセージを自分で書き、説明文にはエージェントが何をしたかを書いた。spec-kit への私のコメントには spec-kit が求める完全な開示を付け、codebase-memory-mcp では Issue、プルリクエスト、各コメントに、このプロジェクトが求める一行を入れた。codebase-memory-mcp への私の返信のうち二つは、プロジェクトがルールを加えてから一週間後の9月28日に、その一行なしで出ていた。10月1日に書き足した。Deskflow はプルリクエストでの開示を求めている。そこへの私のコメントはエージェントが下書きしたもので、開示なしで出ていた。10月3日に開示の一行を書き足した。

クローズ時のコメントは、どちらも AI には触れていない。agent-framework が私の PR をクローズしたのは、以前から開いていた PR に同じ修正があったからで、自分の PR を書く前に検索していれば、それを見つけられたはずだ。MLX のメンテナーが判断したのは、アプローチそのものだった。

私が変えたこと

限界

これは一つのアカウントによる、六日間の記録だ。30 のリポジトリは私が選んだもので、ルールがありそうな AI ツールの分野に偏っている。分類は私が付けたもので、一つのルールが複数の分類に当てはまることも多い。すべて2026年10月2日に読んだものだが、19 のうち 16 ではその前の一か月の間にルールのファイルが変わっているので、この記事の一部はじきに古くなる。コミットに固定したリンクを開けば、その日に各ファイルに何が書かれていたかがわかる。

106 件の引用すべてと集計、そしてすべての引用をそれぞれのファイルと照合するスクリプトは nefayran/oss-ai-rules にある。

この記事は Claude Code（Claude Opus 5.5）を使って下書きした。ルールのファイルを集め、すべての引用をそれらのファイルと照合したのも Claude Code だ。