ClaudeのAgent SkillsでQA業務を効率化した話

目次

はじめに

こんにちは、デリッシュキッチンのUserMatching事業でエンジニアをしている惟高です。

今回は、Anthropicが提供するAgent Skillsを活用して、UserMatching（UM）のQA業務を効率化した取り組みを紹介します。

QAに必要な手順や判断基準をSkillとして定義し、「△△のLPをQAして」「△△のETLをQAして」といった一言で複雑なQAフローを進められる仕組みを構築しました。

最終的には、LPのQAでは設定分析とテストシナリオ生成までを、ETLのQAではテストデータ設計から実行結果の照合までをSkill化しました。

UserMatching（UM）とは

デリッシュキッチンやトモニテでは複数のプレゼントキャンペーンがあり、ユーザー様はLP（ランディングページ）経由でいくつかの質問に回答することで応募できるようになっています。クライアント様の要望に応じたLPを個別で作成しているため、案件ごとにフォームの構成や表示条件が異なります。

案件ごとの基本的な流れは、LPで回答を収集し、その回答データがDBに保存され、最後にETLでクライアント向けの出力形式へ変換する、というものです。

UMでの主なQA対象は以下の2つです。

• LP（ランディングページ）：案件ごとにフォームの設問・表示条件・応募完了条件が異なり、ユーザーの回答によって後続の設問が動的に変わるなど、複雑な条件分岐が組まれています。

• ETL（データ変換処理）：応募データをクライアント企業が求める形式に変換する処理です。変換ルールやフィルタリング条件が案件ごとに設定されます。

参考: DELISH KITCHEN×パルシステム神奈川 プレゼントキャンペーン｜DELISH KITCHEN

QAの課題

LP・ETLともにビジネス側が管理画面から設定とQAを担当していますが、案件ごとの設定が複雑で、初見では確認すべきポイントをつかみにくい状況でした。

たとえばLPでは、「神奈川県在住」「26歳以上」「現在サービス未利用」といった応募条件に加え、ある設問への回答によって次の設問の表示有無が変わることがあります。そのため、単に入力項目を埋めるだけではなく、「どの回答パターンでどの設問が表示されるか」「どの条件で応募対象外になるか」まで含めて確認する必要があります。

またETLでも、応募データをクライアントごとの指定フォーマットに合わせて変換するため、日付形式の変換、項目名のマッピング、特定条件のデータ除外などを案件ごとに確認する必要があります。1つの設定ミスでも、出力結果全体が意図とずれてしまいます。

こうした背景から、主に以下の3つが課題でした。

1. パターンの多さ: LPは表示条件の組み合わせが、ETLは変換ルールとフィルタリング条件の組み合わせが多く、網羅すべきテストパターンが膨大になります。
2. 人依存の網羅性: 確認すべきパターンの優先度や網羅範囲の判断が担当者の経験に委ねられており、案件ごとに確認観点がばらつく状況でした。
3. 作業コスト: テストパターンの設計・実施から結果照合まで手動工程が多く、案件数が増えるほどQAがボトルネックとなっていました。

Agent Skillsというアプローチ

Agent Skillsは、Anthropicが提供する再利用可能なプロンプトテンプレートの仕組みです。本記事でいうSkillは、Claudeへの指示手順と補助スクリプトをまとめて再利用できる単位、と捉えてもらうとイメージしやすいと思います。

業務手順や判断基準をSkillとして定義しておくことで、自然言語の指示を起点に複雑なタスクを進めやすくなります。Claude CodeとClaude Desktopの両方で利用できますが、今回はビジネス側のメンバーも使えるよう、GUIで操作できるClaude Desktop上で運用しています。

QA支援の仕組みとしては管理画面にQA機能を組み込む選択肢もありましたが、以下の理由でClaude Desktop上のAgent Skillsを選択しました。

1. 開発コストの低さと柔軟性: 管理画面への実装と比べてSkillを作成するだけで開発コストが低く、QA観点の変更もSkillの修正だけで対応できます。
2. 一定の手順で進められる: Skillとして手順と判断基準を定義することで、担当者による観点のばらつきを抑えつつ、一定の流れでQAを進められるようになりました。
3. ビジネス側のメンバーが直接使える: 弊社ではビジネス側にもClaude Desktopを配布しており、Skillsは自然言語で呼び出せるため、QA担当者が「△△のLPをQAして」と指示するだけでQAフローを開始できます。

QA手順をSkillsに落とし込む

設計した5つのSkills

まず完成形のイメージを紹介します。たとえばLPのQAの場合、以下のような対話になります。

QA担当者: 「△△のLPをQAして」（△△は案件名）

Claude: 案件の設定を読み込み、フォームの表示条件を分析します。

Claude: 設定ミスが1件見つかりました。テストシナリオを8パターン生成しました。確認してください。

QA担当者: シナリオ5を修正して、あとはOK

Claude: 修正しました。チェックリストを出力します。

このように、設定の読み込み→シナリオ生成→人間のレビュー→チェックリスト出力を一連の対話で進められます。これを実現するために、以下の5つのSkillを設計しました。

#	分類	スキル名	役割
1	設定取得	campaign-lp-lookup	案件の設定情報を取得する（LP/ETL共通）
2	導出	lp-column-resolver	フォーム定義からDBの保存形式を導出する
3	設定取得	etl-config-lookup	ETLの変換設定とフィルタリング条件を取得・整形する
4	分析	lp-form-checker	設定の整合性チェック・テストシナリオ生成・チェックリスト出力を行う
5	実行	etl-qa-runner	テストデータの設計フェーズと、投入・実行・検証フェーズを持つ

LPのQAでは主に campaign-lp-lookup lp-column-resolver lp-form-checker を使い、ETLのQAではそれに etl-config-lookup etl-qa-runner を組み合わせて進めます。

これらのスキルが、LPのQAとETLのQAでどのように連携するかを図にすると、次のようになります。

Agent SkillsによるQAフロー全体像

Skill設計のポイント

• 再利用性: 「案件の設定を取得する」スキルはLPのQAとETLのQAの両方で使う共通部品にしました。
• 段階的な実行: AIが生成したテストシナリオをそのまま実行せず、人間の確認を挟むことで信頼性を担保しています。
• 確定的な処理はスクリプトに追い出す: Agent Skillsでは、Skill本体のMarkdownファイルとは別にスクリプトをバンドルできます。「APIから設定データを取得する」「フォーム定義からDBのカラム構造を導出する」といった、入力が決まれば出力も一意に定まる処理はPythonスクリプトとして実装し、Skillから呼び出す形にしています。判断や要約のような曖昧さを含む部分はLLMに任せつつ、データ取得や構造変換のような確定処理はスクリプトで実行することで、再現性を高めています。
• ドメイン知識の局所化: 「フォーム項目がDBにどう保存されるか」の変換ルールはデータ構造導出のスキルに、「ETLの変換タイプごとの仕様」は変換設定取得のスキルに閉じ込めています。各スキルが担当する知識のスコープを明確にすることで、メンテナンスしやすくなります。

LPのQA: 表示条件のパターンを自動で網羅する

シナリオの自動生成

LPでは、ユーザーの回答内容によって後続の設問が表示されたり、応募対象外になったりします。こうした条件分岐を人手だけで漏れなく追うのは難しく、QAでは「どの回答パターンで何が表示されるべきか」を整理する必要があります。

たとえば、同じLPでも回答内容によってフォームの表示内容や応募可否が変わります。

応募対象外になるパターン

応募対象外になるパターン

後続の設問が表示されるパターン

後続の設問が表示されるパターン

このような分岐が複数の設問にまたがって存在するため、確認すべき表示パターンを体系的に洗い出すことがLPのQAでは重要になります。

まず案件の設定データを取得し、以下の2つの分析を行います。

• 設定ミスの自動検出: フォーム設定とフロントエンドの実装仕様を突合し、矛盾や不整合がないかをチェックします。
• 表示条件テストシナリオの生成: 応募条件と表示条件を分析し、テストすべき表示パターンを整理します。各シナリオには「どの選択肢を選ぶか」「何が表示されるべきか」「応募不可になるか」といった期待結果を付与します。最終的な過不足の確認は担当者がレビューして補います。

生成されたシナリオはユーザーに提示され、追加・修正・削除を経て承認後、チェックリストが出力されます。

LPのQAチェックリスト

Claude in Chromeによる自動確認を断念した経緯

当初はClaude in Chrome（Claude Desktopのブラウザ操作機能）を使い、承認済みシナリオの実機確認まで自動化する設計で、実際に動作する仕組みも構築しました。しかし、1シナリオあたり3〜5分ほどかかり、途中で処理が止まってしまうこともありました。特に各操作でスクリーンショット取得を挟む点が律速となり、実運用には向きませんでした。

結果としてこのSkillの運用は取りやめ、パターンの洗い出しとチェックリスト出力までをlp-form-checkerに集約し、実機確認は担当者が行うフローに落ち着きました。パターンの網羅的な洗い出しこそがQAの課題の本質だったため、この分担でも十分に価値がありました。

ETLのQA: テストデータ設計から検証まで一気通貫

ETLのQAでは、テストデータの設計から投入、ETL実行、結果検証までを一連の流れで実行します。

ETLのQAフロー

テストデータの自動設計

ETLのQAで最も手間がかかるのがテストデータの準備です。LPのフォームから毎回手入力するのは非効率なため、必要なテストデータを開発環境のDBに直接投入する方針を取りました。投入先は本番とは分離された開発環境の検証用データに限定しており、本番データや本番環境には触れない前提で運用しています。ここでの目的はETLの変換処理とフィルタリング条件の検証に絞っており、UI経由の入力体験やLP側の表示制御の確認はLPのQAで担保しています。

直接投入にはデータの「形」を正確に知る必要があり、LP側で応募不可になるパターンの除外判断にもLPの表示条件の知識が必要です。Skillはこうした複雑さを吸収し、以下のテストパターンを自動生成します。

• 変換テスト: 正常値・境界値・異常値で各変換タイプが正しく動作するか
• フィルタリングテスト: 全条件クリア（有効）、各条件で無効になるパターン
• 共通バリデーション: 電話番号・メール・郵便番号・日時の形式チェック

検証フロー

承認後は、テストデータの投入、ETLの再実行、結果取得、期待値との照合までを一連の流れで進めます。不一致が見つかった場合は、ETL設定の問題かテストデータの問題かを切り分けて報告します。

導入効果と課題

効果

最も大きな効果は、QA担当者が毎回ゼロから確認観点を考えなくてよくなったことです。従来は案件ごとに設定画面を読み解き、表示条件や変換条件を見ながらテストパターンを組み立てていましたが、Skill導入後はその整理とたたき台作成を自動化できるようになりました。

自動化の範囲と人間の介在ポイントを整理すると、以下のようになります。

工程	従来（手動）	Skill導入後
設定内容の読み解き	人間が管理画面を目視確認	Skillが自動取得・整形
テストパターンの設計	人間が経験ベースで洗い出し	Skillがたたき台を自動生成
パターンの妥当性確認	—	人間がレビュー・承認
テスト実行	人間が手動で1パターンずつ	LP: チェックリストに沿って人間が確認 / ETL: Skillが自動実行
結果の判定	人間が目視で照合	LP: 人間が目視で判定 / ETL: Skillが期待値と自動照合

LP・ETLに共通してSkillに任せているのは「設定の読み解き」と「パターンのたたき台作成」で、ETLではさらに「テスト実行」と「結果照合」も自動化しています。一方、パターンの妥当性を判断する工程は担当者に残しています。完全自動化ではなく、担当者のレビューを挟むことで安全性を高めています。

実際に複数案件で試したところ、特に負荷軽減につながったのは「設定の整合性確認」「パターンの洗い出し」「テストパターンの設計」でした。たとえばLPのQAでは、Skillが最初に複数の表示パターンを整理した状態から確認を始められるため、担当者は不足分の追加や期待結果の見直しに集中できます。

また、LPのQAでは表示条件の整合性を確認する過程で、実際に設定ミスを事前に検出できたケースもありました。見落としやすい条件分岐を人手だけで追う負担を減らしつつ、確認精度の底上げにもつながっています。

ETLの設定でも、変換対象のカラムが想定とは異なるカラムを参照している設定ミスに事前に気づけたケースがありました。設定画面では見落としやすい差分でも、Skillが設定を整理して確認観点を提示することで発見しやすくなりました。

ETLでも、従来はLPから実際に応募して用意していた検証データを、開発環境に直接投入する形へ置き換えられたため、テストデータ準備の手間を減らせました。フォーム入力を何度も繰り返さずに必要な検証ケースを作れるようになり、変換条件やフィルタリング条件の確認に集中しやすくなっています。

課題

今回の取り組みを通じて、以下の2点を課題として感じました。

• Claude in Chromeの安定性: 実機確認の自動化を試みましたが、1シナリオあたり3〜5分ほどかかり、途中で処理が止まってしまうこともあったため断念しました。
• Skillの保守コスト: 管理画面の仕様変更や新しい変換タイプの追加があった場合、Skillファイルの更新が必要です。各利用者のローカル環境に配置されるため変更の配布・反映を自動化しにくく、現状は手動更新を前提に運用しています。

おわりに

QAに必要な手順と判断基準をAgent Skillsとして定義することで、「LPの表示パターンの整理と確認観点の洗い出し」「ETLのテストデータ設計から検証まで」という複雑なQA業務を効率化できました。

今後はQA以外の業務にもSkillを活用していきたいと考えています。案件のセットアップ作業など、手順や判断基準をSkillとして定義できる場面は多く、幅広い業務への展開が期待できます。

最後までお読みいただきありがとうございました。