ACMのオープンソースAIレポート、コーディングの高速化が人間によるレビューを圧迫していると警告
ACMのオープンソースAIレポートは、コストの大きい逆転現象を指摘している。AIはパッチを迅速に作成できるが、どの変更を信頼に値すると判断するかは、依然として人間が決めなければならない。この不均衡により、時間、資金、レビュー能力が限られているメンテナーの負担は増している。
Association for Computing MachineryのTechnology Policy Councilが公表したこのレポートは、AIがオープンソースソフトウェアに及ぼす影響を検討している。中心的な懸念は、AIが有用なコードを書けるかどうかではない。人間主導のプロジェクトが、機械支援による貢献の大幅な増加を安全に受け入れられるかどうかだ。
この違いは重要である。オープンソースソフトウェアは、スマートフォン、車両、クラウドサービス、AIシステムを支えている。一方で、多くの重要なプロジェクトは、ボランティアや少人数のチームに依存している。Godot、curlなどのプロジェクトは、低品質なAI提出物に直面した後、すでに貢献ルールを厳格化している。豊富なコードという期待は、希少な人間の注意力という現実に直面している。
ACMのオープンソースAIレポートはレビューに注目を移す
レポートは、コード生成の高速化は人間側のボトルネックを解消するのではなく、レビュー、ガバナンス、保守へと移すだけだと論じている。
ACM TechBriefは、ACMのTechnology Policy Councilを通じて活動する6人の著者により、2026年に公表された。著者にはArunachalam Balasubramanian Shrinivass、Simson Garfinkel、Josiah Dykstra、Andy Oram、Nina Shamsi、Jonathan M. Smithが含まれる。
このブリーフは、サイバーセキュリティ、ソフトウェア保守、財政的持続可能性、そして組織におけるオープンソース依存関係の知識不足という、相互に関係する4つの圧力を扱っている。AIは各領域に影響を与えるが、その影響の仕方は同一ではない。
AIシステムは脆弱性を発見し、パッチを提案し、テストを書き、定型的な開発作業を自動化できる。こうした能力は、適切に運営されたプロジェクトが明確に定義された問題をより速く解決する助けになり得る。また、貢献者がドキュメントを準備したり、慣れないコードベースを調査したりする際にも役立つ。
しかし、プルリクエストはプロジェクトへの変更提案にすぎない。信頼されたメンテナーは、それが示された問題を解決するか、互換性を維持するか、プロジェクトの基準を満たすか、新たなセキュリティリスクを回避するかを判断しなければならない。
その判断には、変更された行を読む以上の作業が必要になることが多い。レビュー担当者は、問題を再現し、関連モジュールを調査し、アーキテクチャ上の影響を評価し、サポート対象の環境全体で動作をテストする必要があるかもしれない。
AIは、もっともらしい提出物を作るコストを下げる。しかし、その結果をすべて理解するコストを、同じ割合で下げるわけではない。
この非対称性は、参加の経済性を変える。メンテナーが最初のパッチをレビューしている間に、貢献者は複数のパッチを生成できる。また、提出者はリクエストを開いた後に離脱できる一方、未解決の疑問はすべてプロジェクトに残される。
元の報道は、これを人間が確認すべきコードの増加と表現している。この表現は目先の問題を的確に捉えているが、より広い影響はさらに深刻だ。
オープンソースのリリースは、委任された信頼に依存している。メンテナーは、どの貢献者、プロセス、成果物が公式ビルドに入れるほど信頼できるかを判断する。したがって、未検証の出力が増えることは、コーディング作業だけでなくガバナンス作業を生み出す。
レポートは、AI支援によるすべての貢献が低品質だとは主張していない。モデルの品質が向上し得ることも認めている。未解決の問題は、追加される提出物の一つひとつについて、依然として一定水準の人間の判断が必要になる点だ。
生成コードが説得力を持って見える場合、その判断は特に高コストになる。パッチはコンパイルでき、目に見えるテストを通過しても、文書化されていない前提を誤解していることがある。また、後の変更によって問題が表面化するまで無害に見える複雑さを加える可能性もある。
そのためACMのオープンソースAIレポートは、中心的な問いを変えている。問題はもはや、AIが個々の開発者を単純に高速化するかどうかではない。プロジェクトレベルのレビュー能力が、その出力の増加に合わせて成長するかどうかだ。
この再定義が、この記事の中心的な対立を生み出す。すなわち、機械生成による豊富さと、人間が管理する信頼との対立である。
オープンソースメンテナーはレビュー能力の不足に直面している
最も大きな圧力を受けるプロジェクトは、必ずしもコード品質が最も低いプロジェクトではない。採用規模が大きく、十分な資格を持つレビュー担当者が少なすぎるプロジェクトだ。
適格なレビュー担当者には、一般的なプログラミング能力以上のものが必要だ。プロジェクトのアーキテクチャ、互換性に関する約束、リリースプロセス、コミュニティの期待を理解していなければならない。
こうした知識はゆっくりと身につく。成熟したプロジェクトには数千人のユーザーがいるかもしれないが、重要な変更を承認できる人は少数にとどまる場合がある。コード生成ツールを一つ追加しても、信頼できるレビュー担当者が一人増えるわけではない。
AIが初めての貢献者を呼び込むとき、この問題はより鮮明になる。貢献者がその規範を学び、やがて保守の責任を担うようになれば、新しい参加はオープンソースコミュニティを強化し得る。
従来のレビューは、そのメンタリング機能の一部を果たしてきた。メンテナーは、なぜ変更に修正が必要なのかを説明し、貢献者はその知識を将来の作業へ持ち込む。
機械を介した参加は、このやり取りを壊しかねない。メンテナーは依然としてプロジェクト要件を説明する時間を費やすが、コードを提出した人がその教訓を理解したり保持したりしない可能性がある。
Godotは、2026年6月30日により厳格な貢献ルールを発表した際、この懸念を明確に示した。このオープンソースのゲームエンジンは、適格なレビュー担当者の層が小さく、プルリクエストのバックログはすでに管理が難しい状態にあると述べた。
Godotは、AIがプルリクエスト作成に必要な労力を下げた一方で、そのレビューに必要な作業量は減らしていないと説明した。財団はまた、貢献者も将来のメンテナーも育成しないフィードバックの価値に疑問を呈した。
計画されているルールでは、自律型AIエージェントと、AIが大部分を作成したコードを禁止する。また、貢献者が限定的なAI支援を利用する場合には、人間による説明責任と開示を求める。
この方針は、単にAIを理念的に拒絶するものではない。希少な資源、すなわち十分な知識を持つレビュー担当者の時間を守ろうとする試みだ。
リスクはコードの提出にとどまらない。プロジェクトには、生成されたバグ報告、機能提案、セキュリティ上の指摘、議論へのコメントが届く可能性がある。どの項目も、同じメンテナーの注意を奪い合う。
一見詳細な脆弱性報告は、特に高コストになり得る。レビュー担当者は、それを安全に却下する前に、指摘された欠陥が実在するかを判断しなければならない。捏造された報告でも、修正を生まないまま数時間を消費する可能性がある。
2026年7月のプレプリントは、このパターンをAI contribution floodと表現した。研究者らは、200万件を超えるプルリクエストとissueを含む294のリポジトリを分析した。
報告によると、2025年にはプルリクエストの件数が増加する一方、マージ率は低下した。一度きりの貢献者では、研究のモデル化された反実仮想と比べて、マージ率が18.18パーセント低下した。
研究者らは実務者へのインタビューと、229人のオープンソース参加者を対象とした調査も行った。その結果、より厳格な貢献テンプレートから外部提出への広範な制限まで、多様な防御策が確認された。
これらの知見は、AIが却下されたすべてのリクエストを引き起こしたことを示すものではない。リポジトリ研究には、分類と比較に関する限界もある。それでも、メンテナーが新たな量を能力上の問題と捉える理由は示している。
別の2026年の研究は、2023年1月から2026年5月までの11,097のGitHubリポジトリを調査した。プロジェクトがAIコーディングエージェントを導入した後、レビューの深度が5.3パーセント増加したと報告している。
レビューの深度は、レビュー上のやり取りの強度を測るものであり、最終的なソフトウェア品質を測るものではない。それでも、この増加は一貫したメカニズムを裏付ける。生成の高速化は、作業を検証へと移転させる。
その結果、レビュー能力のギャップが生まれる。貢献量は低コストな自動化によって拡大できる一方、信頼できるレビューは希少な人間の専門知識に結びついたままである。
AIコーディングの高速化は信頼とセキュリティのトレードオフを生む
AIはオープンソースソフトウェアの修復に役立ち得るが、その同じ速度が攻撃の機会を増やし、安全なリリースに責任を負う人々を圧倒する可能性がある。
ACMのオープンソースAIレポートは、AIをデュアルユースの能力として位置づけている。モデルは脆弱性を見つけ、修正案を提案できる。同様の技術は、攻撃者が弱点を探したり、もっともらしい悪意ある提出物を生成したりする助けにもなり得る。
GoogleのCodeMenderは、防御面での可能性を示している。Googleによれば、このエージェントは2025年4月から10月にかけて、オープンソースプロジェクトに72件のセキュリティ修正を提供した。
対象となったプロジェクトの中には、450万行ものコードを含むものもあった。人間のチームはすべての経路を手作業で調べられないため、この規模では自動化が価値を持ち得る。
ただし、自動化された修正も、プロジェクトの信頼プロセスに入る。メンテナーは診断を検証し、パッチをレビューし、テストを評価し、リリース時期を調整しなければならない。
アプリケーションが多数の別個のパッケージに依存している場合、そのプロセスはさらに難しくなる。各コンポーネントには、それぞれのメンテナー、リリーススケジュール、下流のユーザーがいる。
AIシステムは、複数のライブラリにまたがる関連した弱点を迅速に見つけられるかもしれない。しかしエコシステム全体が、影響を受けるすべてのコンポーネントを同じ速度で修正、リリース、展開できるとは限らない。
攻撃者には同じ責任がない。多くの仮説を生成し、失敗を放棄し、最初に得られた有用な結果を悪用できる。防御側は、既存システムを壊すことなく、信頼に足る指摘を調査しなければならない。
オープンなリポジトリは、サプライチェーン上のリスクも生む。悪意ある行為者は、有用に見えながら望ましくない動作を隠したパッケージ、パッチ、依存関係の更新を提出できる。
AIは、そのような提出物をより洗練されたものにできる。テスト、ドキュメント、注意深さを印象づける詳細な説明を生成できるからだ。見せ方の品質は、出所や安全性を証明するものではない。
このため、テストスイートの通過だけを唯一の関門にすることはできない。テストが表すのは既知の期待である。すべてのセキュリティ境界、特殊な環境、長期的な保守コストを網羅することはほとんどない。
レビュー担当者は、誰が変更を理解し、後に誰がそれを修復するのかを問わなければならない。また、追加された依存関係、生成ファイル、不慣れなパターンが、プロジェクトの攻撃対象領域を広げていないかも判断する必要がある。
この説明責任の問題が、支援と委任を分ける。開発者は、あらゆる設計判断を説明できる能力を維持したままAIを利用できる。パッチを説明できない貢献者は、その責任をプロジェクトへ移転する。
オープンソースを利用する組織は、その影響を引き継ぐ。多くのチームは技術ナレッジベースを維持しているが、それでも自社のソフトウェア依存関係に関する最新の地図を持っていない。
ソフトウェア部品表、すなわちSBOMは、アプリケーションのコンポーネントを機械可読形式で一覧化したものだ。脆弱性が公表された後、セキュリティチームが影響を受けるライブラリを特定する助けになる。
SBOMでは、そのコンポーネントに十分なメンテナーがいるかどうかは分からない。未解決のプルリクエストが蓄積しているか、プロジェクトのガバナンスが弱まっているかも明らかにできない。
また、AI生成の修正が適切なレビューを受けたかどうかも判断できない。インベントリは必要だが、組織としての認識には、プロジェクトの健全性と保守慣行も含まれなければならない。
したがって、トレードオフはAIかセキュリティかではない。説明責任のないスピードか、レビュー、追跡可能性、責任あるオーナーシップに支えられたスピードかである。
AIは、発見から候補パッチまでの道のりを短縮できる。しかし、そのパッチが信頼できるリリースに含めるべきものだと確認する必要をなくすことはできない。
資金調達モデルはオープンソースの価値に見合っていない
AIは、経済的価値が多くの個別プロジェクトに届く資金を大幅に上回るエコシステムにおいて、メンテナーへの要求を増大させている。
ACMのブリーフは、オープンソースが存在しなければ企業はソフトウェアに3.5倍多く支出することになる、との研究を引用している。同じ経済価値に関する研究では、企業にとっての世界全体の需要側価値を8.8兆ドルと推計している。
これらの数値は、組織が共有ソフトウェアを利用することで回避できるコストを示している。メンテナーが受け取る収益を示すものではない。
この隔たりが重要なのは、オープンソースの保守がコードを書くこと以上の業務を含むためだ。プロジェクトには、リリース管理、ドキュメント作成、ユーザーサポート、パッケージング、テスト、資金調達、コミュニティのモデレーションが必要となる。
AIはその一部を支援できる。しかし、プロジェクトの優先順位を決めたり、ユーザー、コントリビューター、スポンサーの間の意見の相違を調整したりすることはできない。
ACMのオープンソースAIレポートは、際立った組織間比較を取り上げている。Linux Foundationは2024年の収益として292,217,236ドルを報告した。一方、Apache Software Foundationは2,379,402ドルだった。
これらの組織は対象範囲も運営モデルも異なるため、収益を直接的なパフォーマンス比較として扱うべきではない。それでも、この対比はオープンソース全体で資源の流れがいかに不均衡になり得るかを示している。
より重要な不平等はプロジェクト単位で存在する。広く使われているコンポーネントであっても、専任組織、サポート契約、フルタイムのメンテナーがいない場合がある。
企業は、誰がリリースを承認しているのかを知らないまま、そのコンポーネント上で収益性のあるサービスを構築できる。脆弱性、放棄、破壊的変更が発生して初めて、そのガバナンスを調べることもある。
これはフリーライダー問題である。利用者は共有資源から価値を得ながら、その維持に比例して貢献しない。AIがこの問題を生み出したわけではないが、深刻化させる可能性はある。
企業はAIコーディングツールを使い、外部依存関係に対する変更を作成できる。その変更をアップストリームに提出すれば、受け取るプロジェクトがレビューコストを負担することになる。
企業はより安価なコード生成の恩恵を得る。ボランティアのメンテナーには、検証すべき提案がもう一つ届く。
有用なパッチであっても、調整作業を課す。メンテナーは、それがコントリビューター固有の要件だけでなく、より広いユーザーコミュニティを支えるものか確認しなければならない。
質の低い提出は、さらに大きな外部コストをもたらす。提出組織は要求を放棄できる一方、プロジェクト側はそれをクローズし、判断を説明し、あるいは生じた対立を管理しなければならない。
資金提供によってレビュアーの能力を増やすことはできるが、資金だけで専門性が即座に生まれるわけではない。新しいメンテナーにも、プロジェクトを学び、コミュニティの信頼を得る時間が必要だ。
つまり、支援は短期的なバグ報奨金にとどまるべきではない。プロジェクトには、ドキュメント、オンボーディング、テスト基盤、パッケージング、後継者計画のための持続的な資金が必要である。
ACMのブリーフにある提言は、このより広範な必要性を反映している。財務的持続可能性と、プロジェクトを利用可能な状態に保つ組織的な作業に、より大きな注意を向けるよう求めている。
企業の調達担当者は、これをサプライチェーン管理として捉えるべきだ。重要な依存関係が疲弊した一人のボランティアによって保守されているなら、その状態は運用リスクを意味する。
調達チームは日常的に商用ベンダーの安定性を評価している。請求書がレビューの契機にならないため、オープンソースパッケージには同等の精査をほとんど適用していない。
AIによるコントリビューションの圧力は、この見落としを擁護しにくくしている。より多くの自動生成アウトプットがプロジェクトに届く一方で、そのプロジェクトの人的能力はダウンストリームの利用者から見えないままである。
したがって、資金の問題はレビューの問題と切り離せない。判断に資金を提供せず、より多くの提案を生み出すシステムは、ボトルネックを深刻化させる。
一律のAI禁止は注意力を守るが、参加の裾野を狭める可能性がある
より厳しいゲートは短期的なレビュー能力を維持できるが、不適切に設計された制限は正当なコントリビューターも阻み、将来のメンテナー育成パイプラインを弱めかねない。
価値の低い提出の殺到に直面するプロジェクトには、いくつかの選択肢がある。開示を義務付ける、コントリビューションの規模を制限する、再現可能なテストを求める、新機能を制限する、あるいは特定のAI利用形態を禁止することだ。
それぞれのルールは、誰がコストを負担するかを変える。詳細な提出テンプレートは、メンテナーがレビューを始める前に、コントリビューターに自らの作業を説明させる。
許可要件は、投機的な機能要求を減らす。自動チェックは、人間によるレビューの前に、書式エラーやテスト不足を却下できる。
一律の禁止はより明確な境界を示すが、執行は難しい。AI生成コードには信頼できる技術的な識別子がなく、人間が作成した作業にも質の低いものはあり得る。
検出ツールは誤検知を起こす可能性がある。洗練された文章がAI利用の証拠とされるなら、第二言語で文章を書くコントリビューターやアクセシビリティ支援を使う人々が、不当に疑われかねない。
厳格なルールは、本物の新規参加者にとっても参入を難しくする。オープンソースは、一部の初回コントリビューターを長期的な参加者へと育てることに依存している。
プロジェクトがアクセスしやすい経路をすべて閉ざせば、今日のレビュアーを守る一方で、明日のメンテナー候補を減らしてしまう可能性がある。これは近年の研究が指摘する持続可能性の罠である。
ACMのオープンソースAIレポートは、普遍的なコントリビューション方針を提示していない。オープンソースのガバナンスは分散型のままであり、プロジェクトごとにリスク、規模、レビュアーの能力は大きく異なる。
小規模なコマンドラインユーティリティが、大規模な財団のプロセスをそのまま採用することはできない。暗号ライブラリには、実験的なデザインツールとは異なる保証要件を適用すべきである。
それでも、メンテナーからの証拠は広範な懐疑を示している。Tideliftのメンテナー調査では、既知のAI利用がコントリビューションのレビュー意欲にどう影響するかを尋ねている。
344人の回答者のうち、64パーセントはAIが作成したコントリビューションをレビューまたは受け入れる意欲が低くなると答えた。意欲が高くなると答えたのは9パーセントで、27パーセントは判断がつかないとした。
この調査は最新のコーディングエージェントより前のものであり、ツールの改善に伴って態度が変わる可能性はある。それでも、技術的能力だけを根拠にコントリビューターへの信頼を当然視できないことを示している。
最も公正な方針の対象は、文体ではなく説明責任である。コントリビューターは自らの変更を理解し、関連する自動化を開示し、証拠を示し、修正に対応できなければならない。
プロジェクトは、低リスクの支援と大規模な委任を分けて扱うこともできる。コード補完、機械的な置換、翻訳は、自律的な機能開発とは異なる負担を生む可能性がある。
コントリビューションの規模も重要だ。再現済みのバグと対象を絞ったテストを備えた焦点の定まったパッチは、事前の議論なしに生成された広範なリファクタリングより評価しやすい。
メンテナーには、不釣り合いなレビュー作業を生む提出をクローズする権限が必要である。また、コントリビューターが時間を投じる前に、この境界を説明する方針も必要だ。
GitHubのようなプラットフォームは、プロジェクトにより強力な受付管理機能を提供することで支援できる。有用な機能には、コントリビューション権限、構造化された申告、レート制限、リポジトリ固有のチェックなどが含まれ得る。
プラットフォームによる支援は、ローカルのガバナンスに取って代わることはできない。ただし、各コミュニティが選択した方針を施行するための管理負担を減らすことはできる。
懐疑的な論点は依然として重要である。現在の証拠では、AI支援を受けたすべての作業を測定できない。コントリビューターは常にツール利用を開示するわけではなく、研究者は不完全なシグナルから導入状況を推定しなければならない。
レビュー活動の増加は、より大規模なプロジェクトや変化するコントリビューター層を反映している可能性がある。それは、追加されたすべてのレビューコメントが有害な機械出力を表すことを証明するものではない。
利用可能な証拠が支持するのは、より限定的な結論である。生成能力は、多くのプロジェクトがコントリビューションを検証する能力より速く高まっており、メンテナーはより強いゲートで対応している。
圧力が緩和しているかを示す3つのシグナル
次の試金石は、プロジェクトがレビュー能力を獲得するか、プラットフォームがコントリビューション管理を改善するか、主要な利用者が依存する依存関係に資金を提供するかである。
第1のシグナルは、リポジトリのキューにおける測定可能な変化だ。研究者とプロジェクトリーダーは、レビュー時間、クローズ理由、マージ率、継続的なコントリビューションを追跡すべきである。
健全な介入は、成功する新規参加者を排除せずに、価値の低い受け入れを減らすはずだ。プロジェクトが外部からの参加を閉ざすことでキューを短縮しただけなら、キューが短くなっただけでは十分ではない。
最も強い証拠は、量と質を組み合わせたものになる。プロジェクトは、受け入れられた変更がより少ない修正で済むか、より少ない回帰を生むか、継続して関与するコントリビューターを惹きつけるかを報告すべきである。
第2のシグナルは、説明責任を支えるプラットフォームレベルの支援だ。リポジトリホストは、信頼性の低い検出でAIの著者性を特定しようとせずとも、開示と検証を容易にできる。
構造化された提出フィールドでは、コントリビューターにテスト内容の説明、設計判断の解説、変更を保守する能力の確認を求められる。
プロジェクトには、高コストなコントリビューションの種類を制限するためのツールも必要である。メンテナーは、大規模なリファクタリングや自律エージェントによる提出について、事前の議論を必須にできるべきだ。
プラットフォームがこれらの管理機能を導入すれば、ACMのオープンソースAIレポートによる診断に、運用上の対応策が加わる。エージェント出力の増加だけに注力すれば、不均衡は拡大する。
第3のシグナルは、オープンソースに依存する組織からの持続的な資金提供である。一度限りの助成金も役立つが、保守には継続的な支援と有給レビュアーの時間が必要だ。
企業は、本番運用、セキュリティ、コンプライアンスに影響する依存関係を特定すべきである。そのうえで、メンテナーの集中度、リリース活動、ドキュメントの品質、対応能力を調べるべきだ。
SBOMは、コンポーネントを特定することで、このプロセスを始められる。より難しい段階は、そのインベントリをオーナーシップ、ガバナンス、投資判断へ結び付けることである。
セキュリティチームは、パッチの提供可能性とパッチの展開も区別すべきである。AIは欠陥を素早く見つけられるが、すべての依存関係が更新されるまで、ダウンストリーム製品は露出したままである可能性がある。
この遅延は一部が技術的であり、一部が組織的である。人員が限られたプロジェクトは、多数の商用システムにまたがる最も遅いリンクとなり得る。
開発者にも責任がある。オープンソース作業にAIコーディングツールを使う人は、出力を検証し、周辺コードを理解すべきである。
提出には、明確な問題説明、焦点を絞った範囲、関連するテスト、そしてモデルに頼らずコントリビューター自身が説明・擁護できる解説を含めるべきだ。
組織は、経験豊富なエンジニアを割り当ててアップストリームへの変更を支援することで、外部のレビューコストを減らせる。コミュニティのメンテナーを無償の品質保証担当者として扱うべきではない。
一方でメンテナーには、実際の能力に合わせてコントリビューションのプロセスを設計する権限が必要だ。オープンであることは、無制限かつ未検証の出力を受け入れることを意味しない。
長期的な機会は、オープンソースからAIを排除することではない。コードと人間の責任を切り離すことなく、反復的な作業を減らせる場面で自動化を活用することである。
AI支援レビューは、いずれこのバランスに役立つかもしれない。587件のパッチレビューを対象とした研究では、生成されたコメントのうち直接受け入れられたものは少数にとどまったが、追加コメントはガイダンスとして有用と評価された。
この複雑な結果は、レビュー支援ツールが人間の判断を補助できても、それに取って代わるものではないことを示している。こうしたシステムに依存する前に、各プロジェクトは自らのワークフローで得た証拠を必要とする。
そのシステムが成熟するまで、この根本的な逆転は続くだろう。コード生成は潤沢になりつつある一方、文脈に基づく判断は依然として希少だ。
オープンソース上で製品を構築する読者は、実践的な3つの問いを投げかけるべきだ。あるメンテナーが離れた場合、どの依存関係が安全な更新を受けられなくなるのか。レビュー業務への資金提供者は誰か。自動化された投稿が残された対応能力を使い果たした場合、チームはどう対処するのか。
ACMのオープンソースAI報告書がこれらの問いを緊急のものにしているのは、圧力がすでに顕在化しているためだ。今後数か月は、リポジトリのバックログ、プラットフォーム側の管理策、そして継続的なメンテナンス資金に注目したい。
この3つすべてが改善すれば、AIはオープンソースの対応能力を実質的に高める存在になり得る。そうでなければ、投稿量だけが増え、より速いコーディングが、より遅い信頼の形成を生み続けることになる。
