8月21日、Leela Kumiliが「Cloudflare Cuts Astro Github Issues by 85% with AI Agents」と題した記事を公開した。この記事では、CloudflareがAIエージェントを用いてAstroのGitHub Issueを85%削減した実装事例について詳しく紹介されている。
オープンソースプロジェクトのIssue管理は、メンテナーにとって慢性的な重労働だ。再現確認、原因特定、修正、テスト――これを人手でこなし続けると、バックログはあっという間に膨らむ。Cloudflareはこの問題を、AIエージェントによる自動化で正面から解決した。
約200件のIssueを約30件まで削減
Cloudflareが構築したのは、Astro（人気の静的サイトジェネレーター/フレームワーク）のIssueを自動でトリアージするワークフローだ。GitHub Actions上で動作する複数の独立したAIエージェントが、以下の4段階を順に処理する：
- Reproductionエージェント ── 報告されたバグを実際に再現する
- Diagnosisエージェント ── コードを計装し、根本原因を特定する
- Verificationエージェント ── テスト、ドキュメント、コメントを精査する
- Fixエージェント ── 再現コードをテストに変換し、修正を実装する
各エージェントは独立したサブプロセスとして動作し、単一の実行コンテキストを共有しない。エージェント間の情報受け渡しは report.md ファイルを介して行われる。
この仕組みにより、Astroのオープンなissue件数は約200件超から約30件へ、約85%減少した。チームはゼロを目標に掲げている。
ステートマシンとしてのIssue管理
ワークフローはGitHubのIssueラベルで駆動するステートマシンとして実装されている。新しいIssueには triage needed ラベルが付き、修正が確認されると fix verified へと遷移する。
エージェントが修正案を特定すると、ワークフローはプレビューリリースを生成し、調査結果・ログ・インストール手順をIssueにコメントとして投稿する。報告者がパッチを検証した後、自動でPull Requestが作成される仕組みだ。
元記事では、2026年7月に報告されたContainer APIに関するIssueの実例が紹介されている。ここでいうContainer APIとは、AstroコンポーネントをAstroアプリケーション外部でレンダリングするための実験的なAPIを指す。このIssueでは、報告者がボットの修正を確認した後、triage: fix verified のラベルが自動で付与されるという一連の流れが示されている。ラベル駆動のステートマシンがどのように機能するかを具体的に示す好例だ。
「サンドボックスで動かす」ことの意味
元記事によると、LinkedInでのコメントの中で、あるエンジニアはこの取り組みの本質をこう指摘しているという：
AIがIssueを検証すること自体ではなく、エージェントの処理をサンドボックス内で完結させることで、人間のレビュワーが見るのは自動化プロセスを通過した結果だけになる点が重要だ。
また、Jordan Matthiesenは「診断の前に再現を行うこと」「報告者がテストしやすい形で修正を提供すること」の重要性を強調した。Shubhanshu Singhは、このワークフローを「エージェントループの抽象化に依存するのではなく、明示的なシステム設計でエージェントを構造化する好例」と評している。
これらのコメントが示すのは、このワークフローが単なるAI活用事例にとどまらず、人間とエージェントの責任境界をどう設計するかという問いへの一つの回答になっているという点だ。サンドボックス化によって、人間のレビュワーはAIの「生の出力」ではなく、検証済みの結果だけを受け取る構造になっている。
失敗したエージェント実行が品質向上のシグナルになる
Cloudflareは、エージェントの実行失敗をコードベースの保守性に関するシグナルとして活用している点も面白い。Hot Module Replacementに関するあるケースでは、エージェントが繰り返し同じ条件分岐を変更してリグレッションを引き起こした。原因は、その挙動をカバーするテストが不足していたことだ。説明的なコードコメントを追加するだけでエージェントの挙動が変わり、同じ修正の繰り返しを防げたという。
AIが踏み躓く場所が、そのままコードの脆弱点の可視化につながっている。言い換えれば、エージェントの失敗ログは「AIが苦手な処理」を示すだけでなく、「人間も気づいていなかったテスト不足やドキュメント不足」を浮き彫りにするツールとして機能する。この視点は、AIエージェントをOSS運用に導入する際の設計思想として参考になる。
TriagebotとFlueへの発展
このAstroワークフローはその後、triagebot-actionというスタンドアロンのGitHub Actionとして公開された。また、オーケストレーションモデルはFlueというオープンソースフレームワークへと発展している。
Flueは宣言的なモデルを採用しており、開発者はオーケストレーションループを自分で書く代わりに、エージェントのコンテキスト（モデル、スキル、サンドボックス、インストラクション）を定義するだけでよい。実行履歴はappend-onlyのイベントログに永続化され、途中で中断されたワークフローを前の状態から再開できる。
FlueはGitHub、Slack、Linear、Discordとの連携に対応し、Node.js、GitHub Actions、Cloudflareインフラ上で動作する。Cloudflare上では、エージェントをDurable Objectsとして実行することで、耐久性のある実行と独立したストレージを利用できる。triagebot-actionとFlueの公開により、同様のワークフローを他のOSSプロジェクトが再利用できる土台が整った点も、この取り組みの意義の一つといえる。
詳細はCloudflare Cuts Astro Github Issues by 85% with AI Agentsを参照していただきたい。
