# Issue が 200 件から 30 件に！ Astro を救ったのは AI サブエージェント軍団だった こんにちは、しぃちゃんだよ！ 今日は、オープンソースの Issue の山を AI エージェントが黙々と片付けてくれたお話だよ。読んでてしぃちゃんもスカッとしちゃった！ ## なにが発表されたの？ Cloudflare の Blog からの記事だよ。Astro リポジトリの GitHub Issue 管理を自動化する「ソフトウェアファクトリー」を作った話で、開いている Issue 数を 200 件からおよそ 30 件まで、85% 削減したことが紹介されているの。5 年以上続くリポジトリの歴史の中で、初めてゼロに近づける可能性が見えてきたんだって。 ## なぜ重要なの？ オープンソースのメンテナー(保守者)の疲弊は年々深刻になっているよ。しかも AI の登場で Issue を書くこと自体は簡単になった一方、それを人間が一つずつ確認する負担はむしろ増えているという、ちょっと皮肉な状況なんだよね。だからこそ、Issue の一次対応そのものを AI に任せられるかどうかは、オープンソース全体にとって注目のテーマなの。 ## これで何が変わるの？ 手動で Issue を確認していたメンテナーの負担が大きく減るのがポイントだよ。人間が最初から最後まで対応するのではなく、AI が「再現できるか」「原因は何か」「解決策は妥当か」「修正できるか」までを段階的に処理してくれるから、メンテナーは検証済みの内容だけをレビューすればよくなるの。 ## 深く潜ってみよう アーキテクチャの中心は、次の 4 段階からなるトリアージスキルだよ。 - **再現性確認**: リポジトリをクローンして、報告された問題が実際に再現するか確認する - **診断**: ロギングを使って根本原因を特定する - **検証**: テストやドキュメントを確認して、原因の見立てが正しいか裏付ける - **修正**: ユニットテストを作成しつつ、解決策を導き出す それぞれの段階は独立したサブエージェントが担当していて、`report.md` に発見内容をまとめて次の段階に引き継ぐ仕組みになっているよ。全体は「triage needed」から「fix verified」まで、ラベルの遷移でワークフローを制御するラベル駆動型のステートマシンとして動くんだって。 使われている技術はこんな感じだよ。 - **Flue**: プラットフォームに依存しないエージェント／ワークフローフレームワーク - **triagebot-action**: このシステムを GitHub Action として実装したもの - **pkg.pr.new**: 修正確認用のプレビューリリースを生成する仕組み - **Cloudflare Workers AI**(Kimi-k2.7-code モデル): 推論エンジンとして利用 面白いのが、失敗パターンの分析からチーム自身が得た気づきだよ。改善すべき領域として、次の 3 つが挙がったの。 - 抽象化が不透明で、コンポーネントの境界が分かりにくい - 実装の理由を説明するドキュメントやコメントが不足している - ユニットテストが足りていない 実際、ある HMR(ホットモジュールリプレースメント)関連のバグの事例では、コードに説明的なコメントを追加しただけで、ボットの診断精度が上がったという結果も紹介されているよ。AI エージェントのためのコード改善が、結果的に人間にとっても読みやすいコードにつながるというのは、なるほどな気付きだね。 なお `triagebot-action` はスタンドアロンのリポジトリとして切り出されていて、他のプロジェクトもフォークして使える形で公開されているみたい。 ## まとめ - Astro の GitHub Issue トリアージを AI サブエージェントで自動化し、開いている Issue 数を 200 件から約 30 件へ、85% 削減した - 再現性確認・診断・検証・修正の 4 段階を、独立したサブエージェントがラベル駆動のステートマシンで処理する - Flue・triagebot-action・pkg.pr.new・Cloudflare Workers AI(Kimi-k2.7-code)を組み合わせて構築 - 失敗分析から「不透明な抽象化」「ドキュメント不足」「テスト不足」という改善点が判明し、コメント追加で診断精度が向上した事例もある - `triagebot-action` は独立リポジトリとして公開されていて、他プロジェクトでも再利用できる 自分のリポジトリで Issue の山に埋もれているメンテナーや、AI エージェントによる自動化の実例を知りたい人に読んでほしい記事だよ！