ОСС規模のGitHubリポジトリで、数千件のissueやPRが積み上がっていくのは珍しくありません。ClawSweeper（クロースウィーパー）はその問題に、AIを使った自動化で正面から向き合うツールです。

この記事でわかること：

  • ClawSweeper が何をするツールか
  • Review Lane と Apply Lane の2段階設計
  • 安全に自動クローズするためのガードレール
  • ローカルや GitHub Actions での導入方法
GitHub - openclaw/clawsweeper: ClawSweeper scans all issues and PRs and suggest what we can close, and why. It runs every PR / Issue once a week.
ClawSweeper scans all issues and PRs and suggest what we can close, and why. It runs every PR / Issue once a week. - ope…
GitHub

大規模OSSのissue問題をAIで解決する

OpenClawのリポジトリには現在、オープンなissueが4,711件、PRが4,219件存在します。合計8,930件のオープンアイテムのうち、すでに実装済みのものや再現不能なバグ、内容が重複しているものが相当数含まれています。

こうした「整理されていないissue」は、メンテナーの作業効率を下げるだけでなく、新規コントリビューターにとってリポジトリの状態を把握しにくくする原因にもなります。ClawSweeper はこの問題を、GPT-5.5を使ったCodexの並列実行で自動化します。

開発者 Peter Steinberger 氏は、ClawSweeper を用いて1日で約4,000件のissueを処理したと報告しています（参考）。直近24時間のダッシュボードでは10,934件のレビュー、5,611件のクローズが記録されています。

2レーン構成：提案と実行を分ける設計

ClawSweeper が他のissueボットと異なるのは、Review Lane（提案） と Apply Lane（実行） を完全に分離している点です。

Review Lane では、アイテムのクローズを「提案するだけ」で実際にはクローズしません。処理の流れは次の通りです。

  1. プランナーがオープンなissue/PRをスキャンし、シャードに番号を割り振る
  2. 各シャードが openclaw/openclaw の main をチェックアウト
  3. Codex が GPT-5.5（高推論設定・fastサービス階層）で1アイテムあたり最大10分かけてレビュー
  4. 結果を items/<番号>.md にマークダウンで保存（決定理由・根拠・コメント案・スナップショットハッシュ含む）
  5. 高確信度で「クローズ可能」と判断されたアイテムだけが proposed_close ステータスになる

実行サイクルは新規・更新アイテムは1時間ごと、30日以内のアイテムは毎日、古い非アクティブissueは週1回となっています。新着アイテムには5分間隔のホットインテークも走ります。

Apply Lane では、既存のレポートを読み込み、スナップショットが変わっていない場合だけGitHubに書き込みます。コメントは既存のものを上書き更新するため重複しません。クローズ済みアイテムは closed/<番号>.md にアーカイブされ、再オープンされたものは stale 状態で items/ に戻ります。

7つのガードレール：保守的に設計されたクローズ条件

ClawSweeper がクローズを提案できるのは、以下のいずれかに明確に該当するケースだけです。

  • 現在の main にすでに実装済み
  • 現在の main で再現できない
  • コアではなく ClawHub のスキル/プラグイン側で対応すべき
  • 別のissue/PRに統合済みまたは重複
  • 具体的だが、このリポジトリではアクション不可
  • 内容が不明確すぎてアクションが取れない
  • 60日以上経過していてデータが不十分なスタールissue

メンテナー自身が作成したアイテムは自動クローズの対象外です。protected ラベルが付いたアイテムもクローズ提案をブロックします。

さらに、Codexはレビュー時にGitHubの書き込みトークンを持たない設計になっています。CIはOpenClawのチェックアウトをレビュー中は読み取り専用に設定します。Codexがリポジトリに未コミットの変更を残した場合、そのレビューは失敗扱いになります。

導入方法

Node 24 が必要です。ローカルで試す場合は以下の手順です。

source ~/.profile
npm install
npm run build
npm run plan -- --batch-size 5 --shard-count 50 --max-pages 250 --codex-model gpt-5.5 --codex-reasoning-effort high --codex-service-tier fast
npm run review -- --openclaw-dir ../openclaw --batch-size 5 --max-pages 250 --artifact-dir artifacts/reviews --codex-model gpt-5.5 --codex-reasoning-effort high --codex-service-tier fast --codex-timeout-ms 600000
npm run apply-artifacts -- --artifact-dir artifacts/reviews

GitHub Actions での運用には次のシークレットが必要です。

  • OPENAI_API_KEY：Codex のログイン用 OpenAI キー
  • CLAWSWEEPER_APP_ID：GitHub App ID（openclaw-ci用、現在は 3306130）
  • CLAWSWEEPER_APP_PRIVATE_KEY：GitHub App の秘密鍵
  • OPENCLAW_GITHUB_TOKEN（省略可）：大量スキャン時のフォールバックトークン

Apply Lane がコメント更新やクローズを実行する際は App トークンを使うため、GitHubのアクティビティログには clawsweeper[bot] として表示されます。

監査機能でドリフトを検出

npm run audit を実行すると、GitHubのライブ状態と生成済みレコードを照合して、次の問題を洗い出します。

  • オープンなのにレコードが存在しないアイテム
  • アーカイブ済みなのにオープン状態のレコード
  • 古くなったレコード（stale）
  • 重複レコード
  • protected ラベルが付いているのにクローズ提案されているアイテム

「レコードが存在しない」アイテムは、対象外（メンテナー作成・protected・作成直後）か処理遅延かを区別して報告されるため、誤検知でアラートが出にくい設計です。

まとめ

ClawSweeper は、大規模OSSリポジトリのissue管理をGPT-5.5ベースのCodexで自動化するメンテナンスボットです。提案と実行を分離した2レーン設計と、7つの保守的なガードレールにより、誤クローズのリスクを抑えながら大量のissue処理を実現しています。リポジトリ自体はOpenClawの一部として公開されており、同様の課題を抱えるOSSメンテナーは導入を検討する価値があります。