AIが生み出すのはコードだけではない
個人向けAIアシスタントのオープンソースプロジェクト、OpenClawが急速に成長している。2025年11月にPeter Steinberger氏の週末の実験として始まったプロジェクトは、2026年8月26日時点で約38万8,000スター、8万1,000フォーク、8万件を超えるコミットに達したという。
この規模の成長が示しているのは、AIエージェントがコード生成を支援するだけではないということだ。エージェントは課題を発見し、プルリクエストを作成し、レビューを依頼し、コミュニティ上の活動まで大量に生み出す。結果として、従来のオープンソース運営を前提にしたレビュー体制や信頼の築き方が機能しにくくなっている。
OpenClawのメンテナーが共有した経験は、AIエージェントを開発に導入するすべてのチームにとって、実務的な示唆を含んでいる。
プルリクエストは「プロンプトリクエスト」になる
OpenClawでは、短期間に数千件のプルリクエストやIssueが寄せられ、一部の貢献者は自動化された仕組みで数百件単位のプルリクエストを作成したという。メンテナーは、こうしたプルリクエストを「プロンプトリクエスト」と表現している。
重要なのは、参加者を増やすこと自体が課題ではなくなった点だ。問題は、膨大な提案の中から、プロジェクトにとって価値があり、安全に取り込める変更を見つけることに移った。
この状況では、単純な件数や作成者の活動量を評価指標にするのは危険だ。AIを使えば、プルリクエスト数やコミット数は容易に増やせるためである。
メンテナーが見るべき情報
AIが作成したコードを一律に拒否する必要はない。OpenClawの事例では、初めてオープンソースに貢献する人や、開発者ではない利用者からの提案が取り込まれた例もある。重要なのは、コードを書いた主体が人間かAIかではなく、提案の背景と影響を貢献者が理解しているかどうかだ。
レビュー依頼には、次のような情報を含めると判断しやすくなる。
- どの課題を解決する変更なのか
- 変更しなかった場合にどのような問題が残るのか
- エージェントに与えた指示や、生成過程で得られた知見
- 実行したテストと、その結果
- 手動で確認した操作や画面のスクリーンショット
- 既存機能や互換性への影響
- 既知の制限事項と、今後の対応案
これはAI利用の有無を申告させるためだけの仕組みではない。レビュー可能な証拠を増やし、変更の妥当性を短時間で判断するための仕組みである。
信頼は実績の数ではなく、作業の透明性で築く
OpenClawでは、マージされたプルリクエスト数などの実績が、信頼のシグナルとして使われていた。しかし、既存のプルリクエストを複製することで、貢献実績を意図的に増やそうとする動きもあったという。また、製品宣伝を目的とした自動プルリクエストへの対応も必要になった。
この経験から得られる教訓は明確だ。実績は信頼の材料にはなるが、単独の認証情報にしてはいけない。
エンジニアリング組織で信頼を評価する場合も、次のような複数のシグナルを組み合わせるべきだ。
- 変更の目的と範囲が明確である
- テスト内容を第三者が再現できる
- 既存コードへの影響を説明できる
- レビューで指摘された点に適切に対応できる
- 依存関係や権限変更を隠していない
- 小さな変更から継続的に品質を示している
AIエージェントを使った貢献では、生成速度よりも、提案を説明し修正できる能力の方が重要になる。
AIが書いたコードをAIにレビューさせるときの注意点
OpenClawのメンテナーは、AIが生成したプルリクエストのレビューに別のAIツールを活用している。変更ファイルの整理や、差分の要約、レビュー観点の洗い出しには有効だ。
ただし、AIによるレビューは承認の代替ではない。生成系AIが見落とす可能性のある問題を、別のAIが必ず発見できるとは限らないからだ。特に、権限境界、データ漏えい、競合状態、運用時の失敗モードといった問題は、コード差分だけでは評価しにくい。
実務では、AIレビューを次の位置付けで使うのが現実的だ。
- AIで変更内容と影響範囲を要約する
- AIでテスト不足や危険な変更箇所を洗い出す
- 人間が要約と実際の差分を照合する
- 重要な変更は実行環境に近い条件で検証する
- 最終的な承認者を明確にする
また、OpenClawではメンテナーが提出されたプルリクエストを直接編集し、完成度を高める運用も一般化していたという。AI時代には、提出物をそのまま受け入れるか拒否するかの二択ではなく、良いアイデアを見つけてメンテナー側で安全な形に仕上げる運用も選択肢になる。
「安全なデフォルト」は利用者と環境で変わる
AIエージェントは、単なるコード補完よりも広い権限を持つ可能性がある。ファイル操作、外部サービスとの接続、メッセージングチャネルとの連携など、便利さを高めるほど攻撃面も広がる。
OpenClawのメンテナーは、ワークスペースの制限を強めると利用者から不便だという声が上がり、制限を緩めるとセキュリティ上のリスクが増えるという難しさを説明している。
ここで重要なのは、安全性を単一の設定値として考えないことだ。デフォルト設定は、少なくとも次の要素を踏まえて設計する必要がある。
- エージェントが実行できる操作
- 操作対象となるファイルやサービス
- 利用者が権限の影響を理解できるか
- 開発環境と本番環境の違い
- 失敗時に操作を停止・取り消しできるか
- ログや監査証跡を確認できるか
特に、開発用の利便性をそのまま本番環境へ持ち込まないことが重要だ。エージェントの権限は、必要な操作に限定し、環境ごとに分離する設計が望ましい。
依存関係は、一覧表だけでなく関係性も管理する
サプライチェーン攻撃への対応として、OpenClawのメンテナーは依存関係を精査し、コアの依存数を減らすとともに、依存しているプロジェクトのメンテナーとの関係を築くようになったという。
依存関係管理では、脆弱性スキャンやロックファイルの更新だけでは十分ではない。依存先がどのように保守され、リリースされ、脆弱性に対応しているかを把握することも必要になる。
プロジェクトで実施したいチェック項目は次の通りだ。
- 本当に必要な依存関係かを定期的に見直す
- 直接依存と推移的依存を把握する
- リリース元とメンテナーを確認する
- 更新頻度と脆弱性対応の実績を確認する
- 依存パッケージの変更をレビュー対象にする
- 重要な依存先には、問題発生時の連絡経路を用意する
- 可能な範囲で依存関係を小さく保つ
依存先に問題が起きたとき、自分たちだけで対処するのか、上流プロジェクトと連携できるのかで、復旧速度は大きく変わる。
メンテナー自身の持続可能性もセキュリティ対策である
AIエージェントによって作業量を減らせる一方、作業を終えるきっかけを失う危険もある。OpenClawの会話では、エージェントによって時間を取り戻せたという声と、休まず作業し続けてしまうという側面の両方が語られている。
レビューが滞ると、貢献者への対応が遅れ、重要なセキュリティ報告も見落としやすくなる。したがって、メンテナーの休息や交代体制は、単なる福利厚生ではなく、プロジェクトの信頼性に関わる運用設計である。
チームであれば、次のようなルールを決めておきたい。
- レビュー担当者と時間帯を分散する
- 緊急対応と通常対応の基準を分ける
- 長時間の連続作業を前提にしない
- 重要な判断を一人のメンテナーに集中させない
- 自動化した処理には停止条件を設定する
AI時代のOSS運営チェックリスト
OpenClawの事例を、自分のプロジェクトに適用するための最小限のチェックリストをまとめる。
- AIが作成した変更であることより、変更の目的と検証結果を重視する
- プルリクエスト数やマージ数を単独の信頼指標にしない
- 生成過程、テスト、スクリーンショットなどの証拠を提出してもらう
- AIレビューと人間による最終判断を分離する
- 権限、外部接続、データアクセスを最小化する
- 依存関係の数と保守状況を定期的に見直す
- 貢献者が初学者や非開発者でも参加できる導線を用意する
- メンテナーの負荷と交代体制を可視化する
AIエージェントの普及によって、オープンソースへの参加障壁は下がりつつある。一方で、コードと提案の量が増えるほど、信頼を判断するための仕組みが重要になる。
OpenClawの経験が示すのは、AIを導入すれば運営が自動化されるという単純な話ではない。必要なのは、何を自動化し、何を証拠として残し、どの判断を人間が担うのかを設計し直すことだ。AIエージェント時代のメンテナーに求められるのは、コードを書く速さだけでなく、信頼と安全性をスケールさせる運用能力である。
出典： GitHub Blog