ClawSweeperの提案型リポジトリ保守を読む
ClawSweeter はすべての問題と PR をスキャンし、解決できる内容とその理由を提案します。すべての PR / Issue を週に 1 回発行します。
ひと目でわかる
- これは何?
- openclaw/clawsweeperは、IssueとPull Requestを定期的に確認し、根拠付きのレビュー、修復、automerge候補をガード付きで扱う保守ボットです。
- 誰に向いている?
- ClawSweeperは、OpenClaw系リポジトリのIssueとPRを定期的に見直し、レビュー結果を記録し、条件を満たす狭い修復やautomerge候補だけを人の判断へ渡したい運用に向きます。READMEはレビューとapplyを分け、ライブ状態、ラベル、作成者、スナップショット差分を再確認すると説明していますが、保守判断を無条件に自動化する製品ではありません。
- 商用利用できる?
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている?
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている?
- 主に TypeScript です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月15日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
IssueとPRを定期的に読み直すボット
ClawSweeperは、OpenClawリポジトリの保守を対象にしたボットです。リポジトリの短い説明では、IssueとPRを走査し、何を閉じられるか、その理由は何かを提案し、週に一度実行するとされています。READMEの詳しい説明では、オープンなIssueとPull RequestをスケジュールまたはGitHubイベントでレビューします。
対象は単純な自動クローズではありません。READMEは、レビューは提案のみで、applyはガード付き、Codexはレビュー中に書き込み資格情報を持たず、GitHubの変更直前に対象状態を再確認すると説明しています。判断材料を作る工程と、実際のコメント、クローズ、マージを行う工程を分ける設計です。
記録、コメント、ラベルの三つの出力
レビューごとに、generated stateのrecords/<repo-slug>/items/<number>.mdへ判断、根拠、メンテナー向けコメント、実行メタデータ、GitHubスナップショットのハッシュを書きます。公開コメントは項目ごとに一つのmarker-backedコメントを使い、繰り返し投稿せず、その場で編集します。レビュー開始時に短い状態コメントを出し、完了したら同じコメントを置き換える流れも説明されています。
オープンIssueに対しては、現在のレビューが揃った場合に構造化された結論を助言用のGitHubラベルへ投影できます。current-main reproduction、source reproduction、linked open PRs、queueable fixes、good first issue候補、missing infoなどの状態を、メンテナーの絞り込みに使う設計です。ラベルは修復、マージ、クローズを直接発火せず、ラベル同期の時刻も記録します。
関連項目と根本原因を補助情報にする
レビューのプロンプトには、明示的なリンク、関連するクローズPR、既存のClawSweeperレポート、任意のgitcrawlクラスタ、イベントレビューで選択したライブGitHub検索による文脈が入ります。重複や後継関係を考える材料ですが、READMEはそれだけでクローズを決める情報ではないと位置づけています。
同じレビューには、型付きの提案専用root-cause assessmentが保存されます。ここには同じリポジトリのURLと、根拠付きの代表項目を最大一つ含めますが、修復の派遣、ジョブの抑制、兄弟項目の変更、クローズ、マージは行いません。issueの関連を見つけたことと、対応が確定したことを分ける設計です。
applyでライブ状態を再取得する
Apply modeでは、GitHubのライブ状態を再取得し、ラベル、メンテナーの作成者情報、対になったIssueとPRの状態、スナップショットのずれ、リポジトリのプロファイル規則を確認してからコメントやクローズを行います。レビュー生成時点の情報だけに依存せず、直前の状態を見直す段階です。閉じた項目はclosedへ移り、再オープンされたものはstale workとしてitemsへ戻ります。
レビューされたIssueを修復する場合は、Codexの確認と修復を制限したループでPRを直し、マージ前に条件を再確認します。適格な公開openclaw/*やsteipete/*のプロジェクトでは、検討済みIssueからガード付き実装PRを自動で開く機能も説明されています。ただし、readyであることはmerge authorityではありません。人の判断を残す境界が設計の中心です。
状態保存と自ホストの責任
Canonical review recordはCloudflare Durable Object storeに置かれ、R2へスナップショットされます。ledger/v1の不変アクションイベント、公開アセット、exact-reviewの再試行キャッシュもR2に置かれます。stateブランチにはjobs、results、notifications、apply-report、repair-apply-reportだけを保持し、mainブランチはダッシュボードのレンダラーソースとして使う説明です。
OpenClawがホストするClawSweeperは第三者向けの公開レビューサービスではありません。自分のプロジェクトで使う場合は、このリポジトリをフォークし、自分の組織へ配置し、対象リポジトリを設定します。認証情報、GitHub App、Webhook、R2、Durable Objectの権限は自ホスト側の責任です。設定前にどのデータをどこへ保存するかを一覧にしてください。
MITライセンスと採用前の停止条件
メタデータでは、主な言語はTypeScript、既定ブランチはmain、ライセンスはMITです。取得時点のstarは1,969、forkは297、open issueは28件、直近のリリースはv0.2.0です。数値は更新されるため、プロジェクトの採用根拠はREADMEに書かれたガードと実環境の検証へ置きます。MITはコードの利用条件を定めますが、GitHub操作の安全性やサービス水準は保証しません。
向いているのは、レビューを提案として蓄積し、ライブ状態を確認してから限定的な変更を人が承認するチームです。自動でIssueを閉じることだけを求める場合、ClawSweeperの境界と合いません。最初は読み取り専用のレビューを一つのリポジトリで実行し、記録、コメント、ラベル、decision packet、apply前後の差分を確認します。失敗時にジョブを止め、権限を回収し、変更を追跡できることを確認してから対象を増やしてください。
提案とGitHub変更を段階的に分ける
ClawSweeperの導入では、まずレビュー記録だけを生成し、提案がどのIssueやPRに対応するかを人が確認します。次にmarker-backedコメントと助言ラベルの同期を試し、既存コメントを重複投稿しないこと、対象の状態が変わったときに処理を止めることを確認します。
applyを有効にする段階では、テスト用のリポジトリと低リスクの項目を使います。ライブ状態の再取得、作成者、関連PR、スナップショット差分、プロファイル規則の各結果を保存し、どの条件でコメントやクローズが許可されたかを追います。レビューが正しく見えても、merge authorityは別に置き、停止権限と復旧手順を担当者へ渡してください。
編集部の結論
ClawSweeperは、OpenClaw系リポジトリのIssueとPRを定期的に見直し、レビュー結果を記録し、条件を満たす狭い修復やautomerge候補だけを人の判断へ渡したい運用に向きます。READMEはレビューとapplyを分け、ライブ状態、ラベル、作成者、スナップショット差分を再確認すると説明していますが、保守判断を無条件に自動化する製品ではありません。自ホスト構成、権限、対象リポジトリ、停止条件を小さな範囲で確認してから導入してください。
コミュニティノート