こんにちは、kickflow QAチームのyanagiyaです。
今回は、Asanaにたまったバグチケットを月に一度AIがチェックし、すでに直っているかもしれないものをクローズ候補として提示するBotを作りました。
Asanaのチケット自体には手を触れず、確信度と根拠を添えて候補を挙げるところまでを自動でやります。
本記事では、このBotの中身と、実際に動かしてみてどうだったかを紹介します。
- なぜバグチケの棚卸しを自動化したかったのか
- 棚卸しBotがやること（全体像）
- 確信度と根拠をセットで出す
- Asanaは書き換えず、候補提示だけにした
- 全期間を取りこぼさず、サブエージェントで分散する
- 実際に動かしてみて（2026年7月の実行結果）
- 今後やりたいこと
- まとめ
なぜバグチケの棚卸しを自動化したかったのか
私たちはバグ管理にAsanaを使っています。
起票したバグチケットは、担当者が決まって着手されるまでは「バックログ」に置いておき、すぐに着手しないものは「そのうちやる」に移す、という運用をしています。
そのため、担当者が決まらないまま「バックログ」に残ったチケットや、「そのうちやる」に移したまま手がついていないチケットがあり、古いチケットがどんどんたまっていきます。
やっかいなのは、この中に「もう直っているのにクローズし忘れているチケット」が混ざることです。
別のバグ対応のついでに直っていたり、問題箇所ごと書き換わっていたりして、いつの間にか再現しなくなっているものがあります。
ところが、それを1件ずつ現行の製品コードと突き合わせて確認するのはそれなりに手間がかかります。結果として棚卸しは後回しになり、「バックログ」や「そのうちやる」のチケットは実態より膨らんだままになっていました。
この「たまっていくが、確認する手が回らない」という状態を、AIに肩代わりしてもらえないかというのが出発点です。
棚卸しBotがやること（全体像）
Botの動きはシンプルで、次の流れを月初に自動で回します。
- Asanaのバグ管理用のプロジェクトから、バックログ／そのうちやるにある未完了チケットを取得する
- AIが各チケットの事象を読み、現行の製品コードや関連するPRと突き合わせて「もう再現しなさそうか」を判定する
- クローズ候補を確信度（高／中／参考）で分類し、根拠を添える
- 結果をSlackに投稿する（親メッセージに件数、スレッドに候補リスト）
使っているのは次のツールです。
- Claude Code（判定の実行）
- Asana API（バックログ／そのうちやるのチケット取得）
- GitHub API（関連PRのマージ状態と、現行の製品コードとの照合）
- Slack（結果の通知）
判定ロジックの中心は、チケットの事象を読んで次の3つに振り分けるところです。
再現しなさそう : マージ済みの修正PRがある、または現行コードで
該当箇所が改修・削除されている強い証拠があるもの
再現しそう : 未着手・未マージ・リバートされている、残っているもの
判断できない : コードだけでは分からないもの
（安易に「再現しなさそう」に倒さない）
このうち「再現しなさそう」だけをクローズ候補として拾います。
迷ったものは候補にせず「判断できない」に置いておく、という振り分けにしています。ここを緩くすると、まだ直っていないバグを「直った」と誤って提示してしまうためです。
確信度と根拠をセットで出す
候補をただ並べるだけだと、受け取った側は結局全部を確認し直すことになってしまいます。
そこで、候補ごとに確信度スコアと根拠をセットで出すようにしました。
出力はこんな形式です（内容は例示用に一般化しています）。
高（確信度 0.88+） • 画面に表示される文言の修正漏れ（確信度 0.95）｜Asana｜根拠: 修正PR merged 中（確信度 0.80〜0.87） • REST APIのバリデーションが緩いケース（確信度 0.85）｜Asana｜根拠: 修正PR merged 参考（確信度 0.8未満・要最終確認） • 検索のエスケープ挙動（確信度 0.70）｜Asana｜根拠: escape実装済だが導入時期が未確認
確信度で3段階に分けているのは、確認する側が濃淡をつけられるようにするためです。
高（0.88以上）はマージ済みの修正PRやコードの改修が確認できているので軽く確認すればよく、参考（0.8未満）は根拠が弱いので最終確認が要る、という読み方ができます。発生頻度が高くないチケットを高確信度に紛れ込ませないためのしきい値でもあります。
根拠は、後から人が裏取りできる形にこだわりました。
マージ済みかどうか（merged）、現行コードのどこが改修されたか、対象チケットのリンク、といった「そこを見れば確かめられる」情報を必ず添えるようにしています。
Asanaは書き換えず、候補提示だけにした
このBotは、Asanaのチケットを自動でクローズしません。
やるのは候補を挙げるところまでで、実際にクローズするかどうかは人が判断します。
AIの判定は完璧ではないので、自動でクローズしてしまうと、まだ直っていないバグを勝手に閉じてしまうおそれがあります。閉じたバグは見失いやすいので、最終判断は人に残すことにしました。
候補は多めに出しておいて、閉じるかどうかは人が決める、という分担です。
全期間を取りこぼさず、サブエージェントで分散する
作るうえで地味に手こずったのが、チケットの取りこぼしとコンテキストの管理でした。
まず、対象は直近ではなく全期間です。
バックログには数年前のチケットも残っているので、プロジェクトの起点まで遡って全部を見る必要があります。Asanaの検索APIには1回あたりの取得件数に上限があり、そのままでは古いチケットを取りこぼしかねません。取得の仕方を工夫して、全期間のチケットを取りこぼさず集めるようにしています。
もう一つは、判定処理をAIのコンテキストに全部載せると溢れてしまう点です。
チケットの情報やコードの確認結果は量が多く、数百件ぶんをひとつの会話に積み上げるとすぐに限界がきます。
そこで、チケットを少数ずつのバッチに分けて別々のサブエージェントに処理させ、メインの会話には各バッチの要約だけを集めるようにしました。
判定そのものにも歯止めを入れています。
「再現しなさそう」に振り分けた候補は、そのまま採用せず、いったん反証する姿勢でもう一度見直します。少しでも判断に迷えば候補から落とす、という運用にしました。誤クローズを避けるうえでは、拾いすぎるより取りこぼすほうがまだ安全だと考えたためです。
実際に動かしてみて（2026年7月の実行結果）
2026年7月の実行では、対象262件をチェックし、クローズ候補を11件（高3・中3・参考5）挙げました。
この候補について、実際に再現するか・どのPRで修正されたかを確認し、最終的に高3件・中2件・参考3件の計8件をクローズできました。
反対に、候補に挙げたものの「これはまだ確認が要る」と判断が保留になったチケットもありました。
最終的に人が確認して残す判断ができたので、これは想定どおりの動きです。自動でクローズしていたら見失っていたところでした。
数字にすると、月一の実行で候補11件を出し、そのうち8件がその場でクローズにつながった、という結果です。手作業では後回しになっていた棚卸しが、一度の実行で目に見えて進みました。
今後やりたいこと
月一で候補が出てくる仕組みができたので、手が空いたタイミングでまとめて棚卸しを進められるようになりました。今後はもっと積極的に候補を消化していきたいと考えています。
判定の根拠をAsana側にも残していくことで、Bot自身の精度も少しずつ上げていければと思っています。
まとめ
たまっていく一方で後回しになりがちだったバグチケットの棚卸しを、月一でAIが候補を挙げる形に置き換えられました。
作ってみてよかったと思っているのは、Asanaを書き換えず候補提示だけにとどめ、確信度と根拠をセットで出すようにした点です。
最終判断を人に残したことで誤クローズの心配がなく、確信度の濃淡で確認の手間も抑えられます。実際に、もう直っているチケットを候補として拾えて、棚卸しが前に進みました。
kickflowでは、こうしたQA・テスト業務の自動化に一緒に取り組んでくれる仲間を募集しています。
ご興味のある方は、ぜひ採用サイトをご覧ください。
