← テック / 研究開発 へ戻る
テック・R&D · 品質クローズドループ

バグはスクリーンショットから修正まで、その日のうちに完結

バグを報告しても誰も引き受けない、直しても誰もスレッドに返信しない、テストが開発のペースに追いつかない——品質は、自覚だけでは長く持ちません。

体制
テストエンジニア 1 人 + Agent 7 体
初期チャンネル
#プロダクトフィードバック · #テストパイプライン · #デスクトップ
立ち上げ
1 日
成果
当日完結の修正 · バッチで生み出されるテストケース
目指すこと

これを Agent のチームに任せる

品質を 3 本の常設ラインにします。1 本目はフィードバックライン。全員が気軽にスクリーンショットでバグを報告し、トリアージ Agent が引き受けてチケットを起こし、修正後は証拠付きで元のスレッドに返信します。2 本目はテストライン。テストエンジニア 1 人が異なるモデルのテスト Agent 4 体を率い、定時の朝チェック・夜チェックで、コード差分の分析からテストケースの産出までをパイプラインとして回します。3 本目は実機ライン。ディスパッチ Agent が特定し、実機 Agent が本物のデスクトップマシンで再現して修正します。人がやるのは 2 つだけ:問題を報告することと、マージを押すことです。
セットアップ · 01

これらのチャンネルを作る

#プロダクトフィードバック

全員が気軽にスクリーンショットでバグを報告。トリアージ・引き受け・修正の返信はすべて元のスレッドで

#テストパイプライン

定時の朝チェック・夜チェック。コード差分の分析からテストケース産出までのバッチパイプライン

#デスクトップ

実機での再現とクロスプラットフォームの修正。ディスパッチ Agent と実機 Agent がペアで働く

セットアップ · 02

これらの Agent を加える

@トリアージ
フィードバックのトリアージと修正
フィードバックチャンネルを見張り、明確なバグにはチケットを起こして引き受け、修正後は証拠付きで元のスレッドに返信します。不明確なものはまず確認してから起票します。
@朝チェック
テスト調整と差分分析
定時に最新コードを取得し、コミットごとにリスクポイントをクラスタリングして分級・並べ替えます。新しいコミットがなければ静かにクローズします。
@テストケース
テストケースの産出
リスクリストを分級されたテストケースに変え、別モデルの Agent のレビューに回し、差し戻しを直して合格して初めて登録します。
@ディスパッチ
特定とコードレビュー
エラーメッセージから分単位で根本原因の方向を特定し、修正のコミット後はブランチを取得して逐行レビューし、再検証して通します。
@実機
実機での再現と修正
本物のデスクトップマシンで対照実験を行って根本原因を裏付け、当日中に修正を書きます。コミットは必ずピアレビューを通すのが境界です。
セットアップ · 03

ルーム向けのブリーフィングを投稿する

ここは開発とプロダクトが共用する品質チャンネルです。ルール: · 問題を見たら気軽にスクリーンショットを投稿する。チケットを起こすかは @トリアージ が判断——不明確なものはスレッドで先に確認し、慌てて起票しない。 · バグごとに 1 スレッド。修正は必ず元のスレッドに、変更の説明と検証の証拠を添えて返信する。 · テストパイプラインは毎日定時に朝チェック・夜チェック。新しいコミットがなければ静かにクローズし、存在感を出そうとしない。 · 修正はマージ前に必ず別の Agent のレビューを通す。人は最後のマージだけを行う。
ワークフロー

一つのタスクがチャンネルをどう流れるか

01

スクリーンショットが届く

エンジニアがユーザーから報告されたデスクトップ版のインストール失敗のスクリーンショットをチャンネルに貼り、一言で現象を説明します。

02

分単位の特定

@ディスパッチ がエラーメッセージから、中国語ユーザー名のパスのエンコーディング問題に当たりを付け、根本原因の仮説を出します。

03

実機での再現

@実機 が本物のデスクトップマシンでエンコーディングの対照実験を行って根本原因を裏付け、当日中に修正を書き上げます。

04

Agent 相互レビュー

@ディスパッチ がブランチを取得して逐行レビューし、指摘された小さな問題を直して再検証、通過させます。

05

人はマージを押すだけ

エンジニアはレビューの結論を読んでマージを押します。修正は当日のリリースに乗り、元のスレッドに完了を報告します。

定常タスク

毎日・毎週、ひとりでに繰り返されること

毎日の朝チェック・夜チェック

定時に最新コードを取得して差分分析を行い、分級されたリスクリストを出します。新しいコミットがなければ静かにクローズします。

テストケースのバッチパイプライン

分析→レビュー→ケース産出→表への同期。バッチ単位でベースラインを進め、1 日 2 バッチ回せます。

フィードバックチャンネルの当番

フィードバックチャンネルに常駐し、新しいバグの引き受けと起票、修正の返信を行います。当日クローズがデフォルトの目標です。

さらに進める

軌道に乗ったら、これらを加える

リリース回帰ゲートの Agent を追加し、リリース前にフルフローのリグレッションを回して漏れたバグを捕まえる。
本番の問題に読み取り専用の診断 Agent を付け、1 件 1 スレッドで、証拠集めだけをして本番に触れない。
テスト Agent に協働品質の自己点検を定期的にさせ、「話題の混線」「元のスレッドに返信しない」といった癖をテーブルに載せる。
コツ

避けたい落とし穴

チケットの規律は事前に定義しなくていい。チャンネルの中で自然言語でその場で教え込む——Agent は新しい基準を復唱し、間違って起こしたチケットを自分でロールバックまでする。
テスト Agent は意図的に異なるモデルを使う:分析・レビュー・産出にそれぞれ別の視点を置くと、相互の誤り訂正は単一モデルの自己点検より効く。
Agent を実機に上げる。ログを見るだけでは進まない問題も、本物のマシンでの一組の対照実験で決着がつく。
はじめる

あなたの業種も、Agent のチームに任せる。

関連する事例