バグ報告が工場の入口に並ぶ
Cloudflareは2026年8月4日、AstroのGitHub運用をAIで自動化した事例を出しました。GitHubは、開発者がコードや課題を管理する場です。Issueは、不具合や要望の投稿です。
この話は、AIが一瞬で完璧なコードを書く物語ではありません。バグ報告を一つずつ流す工場の設計に近いです。入口に来たカードを、順番に処理していきます。
工場で大切なのは、腕のいい一人だけではありません。受け取り、検査、修理、出荷の並びです。Cloudflareの記事は、その並びをAIで作った実例です。
Astroの未解決Issueは、200件超から約30件へ減りました。200件から30件なら、減少幅はおよそ85%です。数字が強いのは、作業の型まで変えたからです。
一人の天才AIにしない
Cloudflareの仕組みは、AIエージェントを分業させます。AIエージェントは、目的に沿って手順を進めるAIです。さらに、孤立したサブエージェントへ仕事を分けています。
担当は、工場の持ち場のように並びます。 ・再現担当が問題を試す ・診断担当が原因を探る ・判定担当が本当にバグか見る ・修正担当が解決策へ進む
この分け方には、現実的な意味があります。大規模言語モデルは、答えを出そうとしすぎることがあります。バグでないものまで、直す対象にしてしまう場合があります。
だからCloudflareは、工程を分けました。前の担当はreport.mdに発見を残します。次の担当は、その記録を読んでから進みます。
出荷前に本人が試す
この工場は、GitHub Actionsの中で動きます。GitHub Actionsは、GitHub上で作業を自動実行する仕組みです。外の黒い箱ではなく、開発の場に組み込まれています。
Cloudflareは、Issueラベルで流れを動かしました。新しい投稿はtriage neededから始まります。投稿者が修正を認めるとfix verifiedへ進みます。
AIが修正案を出すと、pkg.pr.newでプレビューリリースを作ります。プレビューリリースは、正式反映前に試す版です。投稿者は、自分のプロジェクトで動かせます。
ここが、ただの自動返信との違いです。返事だけではなく、試せる修正まで届けます。動いたと分かれば、Pull Requestへ進みます。
| 項目 | 発表に書かれた内容 |
|---|---|
| 記事公開日 | 2026年8月4日 |
| 公開されたもの | Astroでの運用事例とFlueの紹介 |
| 一般向け製品の提供時期 | 発表に書かれていない |
| 価格 | 発表に書かれていない |
| 対象条件 | 発表に書かれていない |
普通の職場にも同じ型がある
GitHubを使わない人にも、この話は遠くありません。未処理の山を、どう小さな工程に分けるかという話だからです。問い合わせ、申請、レビュー待ちにも同じ型があります。
AIに任せやすい仕事は、最初から全部を決める仕事ではありません。まず読む、分類する、試す、記録する。そうした前半の処理です。
Cloudflareは、この仕組みがFlueに発展したと説明しています。Flueは、耐久的なエージェントやワークフローを作るためのオープンなフレームワークです。Slack、定期実行、Webhookにも広げられる見方を示しています。
同時に、弱いところも見えます。AIがうまく動かない時、Cloudflareは文書不足やテスト不足を原因に挙げています。曖昧な手順は、AIにも人にも重くなります。
この事例が示す一言はシンプルです。AIは答える道具から、作業の流れを保つ道具へ移っています。人間の価値は、最後の判断と関係づくりに寄っていきます。