SkillがSkillを生む：QA観点出しを自動化した¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Claude Code の Skills を使い、QA 観点出しを自動化した事例スライド。
人間が SKILL.md を直接書き込むのではなく、言語化した課題を skill-creator に渡し、Skill 自体を生成・改善していく。
Findy の QA 業務を題材に、仕様理解、影響範囲分析、テスト観点生成を複数サブエージェントに分担させ、繰り返し使うレビュー観点を Skills 化する流れが説明されている。
本文¶
資料のメッセージは、「Skill が Skill を生む時代が来た」というもの。
AI エージェントに任せたい作業があるとき、人間が最初から完璧な SKILL.md を書く必要はない。
まず問題を言語化し、それを skill-creator のような仕組みに渡すことで、Skill の実装や改善を AI に任せられる。
Skillを人間が手で作り込まない¶
Claude Code の Skills は、特定の作業に必要な手順、判断基準、参照情報、ツール利用方法をまとめるための仕組み。 ただし、実際に使い始めると、Skill の粒度や記述内容を人間が毎回考えるのは負担になる。
資料では、/skill-creator xxxxを自動化したい のように、やりたいことを自然言語で伝えるだけで、Skill の雛形作成や改善を進める流れが示される。
人間の役割は、すべての手順を書くことではなく、繰り返し発生している課題や判断観点を言語化することに寄る。
この発想では、Skill は最初から完成品ではない。 一度使い、結果を見て、足りない観点や誤った判断を反映し、Skill を育てる。 Skill を作るための Skill があることで、この改善ループ自体を AI に寄せられる。
QA観点出しの課題¶
題材は Findy の QA 観点出し。 プロダクト開発では、機能追加や仕様変更のたびにテスト観点を作る必要がある。 しかし、QA 観点出しには複数の認知作業が含まれる。
一つ目は、仕様を理解すること。 要件、画面、業務フロー、期待される動作、境界条件を読む必要がある。
二つ目は、影響範囲を分析すること。 変更された箇所だけでなく、関連する機能、既存データ、権限、通知、外部連携、非同期処理などに影響がないかを見る。
三つ目は、テスト観点を生成すること。 正常系、異常系、境界値、権限別、状態別、並行操作、回帰確認など、テストすべき観点を具体化する。
これらを毎回人間だけでやると、時間がかかり、観点漏れも起きる。
複数サブエージェントへの分担¶
資料では、QA 観点出しを一つの大きなタスクとして投げるのではなく、複数のサブエージェントへ分担させる構成が説明される。
仕様理解担当のエージェントは、仕様書やチケットを読み、機能の目的、入力、出力、状態遷移を整理する。 影響範囲分析担当のエージェントは、コード差分や既存機能を見て、どこに副作用が出そうかを洗い出す。 テスト観点生成担当のエージェントは、それらの情報をもとに、実際に確認すべき QA 観点をリスト化する。
最後に統合役が重複や抜けを調整し、QA リストとして読める形にする。 この構成により、単一エージェントに長い文脈を詰め込むよりも、観点ごとの役割が明確になる。
繰り返しの人間レビューをSkill化する¶
資料で重要なのは、QA 観点出しそのものだけでなく、「毎回人間が同じように指摘していること」を Skill に落とす考え方。
たとえば、毎回「権限別の確認を入れて」「既存通知への影響を見て」「CSV 出力やバッチも確認して」とレビューしているなら、それは個人の勘ではなく、組織が持つ QA 観点である。 その観点を Skill に書き込めば、次回から最初の出力に反映できる。
このとき、Skill は業務ナレッジの保存先になる。 単なるプロンプトのコピペではなく、チームのレビュー観点、品質基準、過去の失敗、ドメイン固有のチェックリストを継続的に蓄積する場所になる。
「言語化」が自動化の入口¶
資料全体を通して、AI に作業を任せる前に必要なのは、作業を完全に手順化することではなく、まず言語化することだと読める。 何を自動化したいのか。 何が毎回つらいのか。 どの判断を人間が繰り返しているのか。 どんな出力なら使えるのか。
それを言語化すると、Skill 作成の材料になる。 Skill 作成自体も AI に任せられるため、人間は問題設定とレビューに集中できる。
読み替え¶
この資料は、QA だけでなく、コードレビュー、リリース判定、障害対応、設計レビューにも応用できる。 毎回同じ観点で確認しているなら、それは Skill 化の候補。
たとえばバックエンド開発なら、API 変更時の互換性、DB マイグレーションの安全性、認可漏れ、ログとメトリクス、エラー設計、リトライや冪等性を Skill にする。 属人的なレビューを、チームが再利用できる実行可能な知識へ変える発想として使える。
要点¶
- Skill は人間が完全に手書きするだけでなく、skill-creator で生成・改善できる。
- QA 観点出しは、仕様理解、影響範囲分析、テスト観点生成に分解できる。
- 複数サブエージェントに役割分担させることで、観点ごとの整理がしやすい。
- 人間が毎回レビューで指摘する観点は、Skill として蓄積できる。
- 自動化の入口は、完璧な手順化ではなく、つらさや判断観点の言語化。