オープンソースプロジェクトのメインテナー3人は、AIの普及でコード作成が容易になった一方、レビューと方針判断の負担が増したと述べました。CIO Koreaは2026年10月12日、ValkeyやIstioなどを率いる関係者にインタビューし、貢献やレビュー、コミュニティの変化を伝えました。Valkeyのメインテナー、マデリン・オルソン(Madelyn Olson)は、独自の分析によると昨年末から今年初めにかけ、Valkeyへのコミット数が約2倍、提出されたコードの行数が約5倍に増えたと話しました。この変化は、AIエージェントの問題解決能力が向上した時期と重なったと説明しています。

Valkeyのメインテナー、ジェイコブ・マーフィー(Jacob Murphy)は、以前はコードを書く時間と労力が、十分に検討されていない貢献を抑える役割を果たしていたと述べました。今ではAIが一度に1,000行を生成できるため、最初の批判的なレビューをメインテナーが担うこともあります。コード生成は大幅に容易になりましたが、レビューは少し楽になった程度で、貢献が正しい方向かを判断するには集中と深い検討が欠かせないといいます。オルソンは、すべてのプルリクエスト（コード変更の提案）を確認できないのは残念な一方、参加希望者が増えたことは歓迎すると話しました。

リン・スン(Lin Sun)は、コードだけでなくレビューへの返答までAIに書かせ、そのまま貼り付ける事例を経験したと述べました。新規または不定期の貢献者がコードを理解・検証せず変更案を提出し、メインテナーの負担が増えることがあります。また、一部のレビュアーは、ボットと修正依頼をやり取りする状況に不満を示しました。スンが参加する一部のプロジェクトは、Linux FoundationのAI利用指針を基に貢献の原則を定めました。AIを使う場合も、貢献者が成果物に責任を持ち、自ら作成したことを明らかにするという内容です。スンは新規参加者に会議への出席を求め、共に作業し、意思疎通できる相手がいるかを確かめることもあります。自身もAIコーディングツールで文法や手順を調べる時間を減らしながら、公開前に成果物を自分で確認し、理解すると話しました。

メインテナーはコードレビューにもAIを使っています。マーフィーはレビューを、メモリリークや異常終了などのエラー確認、コードの一貫性や重複の点検、変更案が全体の設計や目的に合うかの判断という3段階に分けました。複数のAIエージェントが人のレビュー前にコードを調べて意見を残せば、貢献者が一部の問題を先に修正できます。レビュアーは既存機能との重複やプロジェクトの方向性を確認します。また、エージェントにプルリクエストを読ませて質問を交わし、実装の背景を把握することもあります。

オルソンは、AIが生成したコードに重複関数がないかを確認し、より単純な解決策を探してテストを書くと述べました。テストが意図した動作を確かめているか、実装が期待どおりに動くかも自ら確認します。継続的インテグレーション（変更を自動でテスト・検証する仕組み）でテストに失敗した場合は、AIエージェントに問題の再現を任せます。再現できれば、ローカル環境で原因を調べて修正するための手がかりになります。AIツールによる事前のセキュリティ問題の検出も役立つといいます。ただし、変更がプロジェクトの目標に合い、安定性と性能を保ち、新たなセキュリティ上の脆弱性を生まないかは、メインテナーが引き続き確認する必要があると強調しました。

3人のメインテナーは、オープンソースのコミュニティがコードの書き方以外の経験も提供すると述べました。オルソンは、設計で何を優先し何を諦めたのか、ソフトウェアがなぜその方式で作られたのかをAIが理解するのは、まだ難しいと説明しました。コミュニティでは、エンジニアが開発管理者やプロダクト管理者の視点からユーザー体験を考えられると付け加えました。マーフィーは、ユーザー体験や開発の目的、システムが故障する条件を学ぶことに加え、増え続ける研究や技術情報のうち、プロジェクトに取り入れるものと見送るものを判断する経験を挙げました。

スンは、信頼を得て影響力を高め、他者を動機づける能力は、AIと対話することとは異なると述べました。コミュニティでは新しい分野の専門性を身につけ、自分の能力を示せますが、技術上の論点や企業の利害、政治が絡む状況で合意を導くのは難しいといいます。オルソンは、2019年ごろRedisプロジェクトで修正したバグを、数年後に利用者が覚えていて感謝を伝えてくれた経験を、やりがいとして語りました。

スンは、トークン費用の負担から自ら運用するオープンモデルへの関心が高まり、コーディングエージェントが貢献への参入障壁を下げると予想しました。ただし、プロジェクトの成功には、支えながら共に発展させるコミュニティが必要だと強調しました。コードを作る費用が下がっても、人々がそのコードを使うとは限らないと述べています。オープンソースで起きている変化は、企業の開発組織にも、設計の理由を説明し、同僚と合意を築き、ユーザーの課題を解決する力をどう育てるかを問いかけています。

オープンソースプロジェクトのメインテナー3人は、AIの普及でコード作成が容易になった一方、レビューと方針判断の負担が増したと述べました。CIO Koreaは2026年10月12日、ValkeyやIstioなどを率いる関係者にインタビューし、貢献やレビュー、コミュニティの変化を伝えました。Valkeyのメインテナー、マデリン・オルソン(Madelyn Olson)は、独自の分析によると昨年末から今年初めにかけ、Valkeyへのコミット数が約2倍、提出されたコードの行数が約5倍に増えたと話しました。この変化は、AIエージェントの問題解決能力が向上した時期と重なったと説明しています。

Valkeyのメインテナー、ジェイコブ・マーフィー(Jacob Murphy)は、以前はコードを書く時間と労力が、十分に検討されていない貢献を抑える役割を果たしていたと述べました。今ではAIが一度に1,000行を生成できるため、最初の批判的なレビューをメインテナーが担うこともあります。コード生成は大幅に容易になりましたが、レビューは少し楽になった程度で、貢献が正しい方向かを判断するには集中と深い検討が欠かせないといいます。オルソンは、すべてのプルリクエスト（コード変更の提案）を確認できないのは残念な一方、参加希望者が増えたことは歓迎すると話しました。

リン・スン(Lin Sun)は、コードだけでなくレビューへの返答までAIに書かせ、そのまま貼り付ける事例を経験したと述べました。新規または不定期の貢献者がコードを理解・検証せず変更案を提出し、メインテナーの負担が増えることがあります。また、一部のレビュアーは、ボットと修正依頼をやり取りする状況に不満を示しました。スンが参加する一部のプロジェクトは、Linux FoundationのAI利用指針を基に貢献の原則を定めました。AIを使う場合も、貢献者が成果物に責任を持ち、自ら作成したことを明らかにするという内容です。スンは新規参加者に会議への出席を求め、共に作業し、意思疎通できる相手がいるかを確かめることもあります。自身もAIコーディングツールで文法や手順を調べる時間を減らしながら、公開前に成果物を自分で確認し、理解すると話しました。

メインテナーはコードレビューにもAIを使っています。マーフィーはレビューを、メモリリークや異常終了などのエラー確認、コードの一貫性や重複の点検、変更案が全体の設計や目的に合うかの判断という3段階に分けました。複数のAIエージェントが人のレビュー前にコードを調べて意見を残せば、貢献者が一部の問題を先に修正できます。レビュアーは既存機能との重複やプロジェクトの方向性を確認します。また、エージェントにプルリクエストを読ませて質問を交わし、実装の背景を把握することもあります。

オルソンは、AIが生成したコードに重複関数がないかを確認し、より単純な解決策を探してテストを書くと述べました。テストが意図した動作を確かめているか、実装が期待どおりに動くかも自ら確認します。継続的インテグレーション（変更を自動でテスト・検証する仕組み）でテストに失敗した場合は、AIエージェントに問題の再現を任せます。再現できれば、ローカル環境で原因を調べて修正するための手がかりになります。AIツールによる事前のセキュリティ問題の検出も役立つといいます。ただし、変更がプロジェクトの目標に合い、安定性と性能を保ち、新たなセキュリティ上の脆弱性を生まないかは、メインテナーが引き続き確認する必要があると強調しました。

3人のメインテナーは、オープンソースのコミュニティがコードの書き方以外の経験も提供すると述べました。オルソンは、設計で何を優先し何を諦めたのか、ソフトウェアがなぜその方式で作られたのかをAIが理解するのは、まだ難しいと説明しました。コミュニティでは、エンジニアが開発管理者やプロダクト管理者の視点からユーザー体験を考えられると付け加えました。マーフィーは、ユーザー体験や開発の目的、システムが故障する条件を学ぶことに加え、増え続ける研究や技術情報のうち、プロジェクトに取り入れるものと見送るものを判断する経験を挙げました。

スンは、信頼を得て影響力を高め、他者を動機づける能力は、AIと対話することとは異なると述べました。コミュニティでは新しい分野の専門性を身につけ、自分の能力を示せますが、技術上の論点や企業の利害、政治が絡む状況で合意を導くのは難しいといいます。オルソンは、2019年ごろRedisプロジェクトで修正したバグを、数年後に利用者が覚えていて感謝を伝えてくれた経験を、やりがいとして語りました。

スンは、トークン費用の負担から自ら運用するオープンモデルへの関心が高まり、コーディングエージェントが貢献への参入障壁を下げると予想しました。ただし、プロジェクトの成功には、支えながら共に発展させるコミュニティが必要だと強調しました。コードを作る費用が下がっても、人々がそのコードを使うとは限らないと述べています。オープンソースで起きている変化は、企業の開発組織にも、設計の理由を説明し、同僚と合意を築き、ユーザーの課題を解決する力をどう育てるかを問いかけています。