この記事は、CYBOZU SUMMER BLOG FES '26の記事です。
はじめに
こんにちは！サイボウズでQAエンジニアをしている tagashira です！ kintone システム管理/外部連携チームの機能開発の QA を担当しています。
さっそくですが、みなさんは普段の機能開発の中で、リグレッションテストをどのようなプロセスで作成していますか？
わたしのチームでは、リグレッションテストを自動テストとして作成しています。 QAエンジニア（以下 QA ）に特に強みのあるソフトウェアテストの知見と、プロダクトエンジニア（以下 PdE ）に特に強みのある実装の知見が交差する領域である自動リグレッションテストを、職能横断の価値ある共創の場として捉え、関心を寄せてきました。*1
そんな中、Claude Code の登場で、リグレッションテスト作成プロセスが大きく変わりました。そして、変わったことだけでなく、これまでと変わっていないものが見えてきたので、紹介します。
これまでのリグレッションテスト作成プロセス
まず、QA/PdE がモブ（複数人での同期作業）でテスト分析・設計*2を行います。
ここで一緒に起票まで行うと、ある程度まとまった時間を各メンバーが取る必要があるため、モブでは設計方針の合意を取るところまでで留めておき、QA が非同期でテスト起票を行います。
そして、起票された内容をもとに PdE がテスト実装/レビューを行います。
リグレッションテスト作成用 Skill を作った
わたしのチームでは、Claude Code の Skills という仕組みを活用して、リグレッションテスト分析・設計・起票を自動実行させるようにしました。 code.claude.com
Skill として実装した理由のひとつは、チームへの展開のしやすさです。 kintone 開発チームとして Skill を集約するリポジトリがあり、Skill を作成してリポジトリに追加すれば、チームメンバーはプラグインをマーケットプレイスからインストールするだけで同じワークフローを使えるようになります。
テスト設計の手順やノウハウを個人の中に留めず、チーム全体で再利用できる形にしたいと考えました。
Skill の構成
Skill の構成としては、SKILL.md（ワークフロー本体）と references/（リファレンス）の2層構成にしています。
SKILL.md にはテストベースの取得から、設計されたリグレッションテストが記載された GitHub Issue 起票までのステップごとの指示を書いています。
references/ にはテスト設計技法の定義・テストスコープの選定ガイド・GitHub Issue の出力フォーマット・サブエージェントに渡すプロンプトテンプレートを置いています。
この構成は、Claude Code の公式ドキュメントで紹介されているベストプラクティスに沿っています。SKILL.md はコンテキストに読み込まれ続けるため、詳細な定義を references/ に切り出すことでコンテキストの肥大化を防ぐことが可能になります。
いまのリグレッションテスト作成プロセス
作成したリグレッションテスト作成用 Skill を運用することで、これまでとプロセスが大きく変わりました。
まず、QA が Claude Code からリグレッションテスト作成用 Skill を呼び出してテスト分析・設計を行わせ、設計案を GitHub Issue として起票させます。
QA/PdE は、起票された GitHub Issue の内容をモブでレビューし、必要に応じて修正指示を行います。
QA/PdE によるレビューが終わったら、 テスト対象が実装されたタイミングで PdE がテスト実装を行います。
どこが変わったか？
Skill の一番の恩恵は、作業負担の代替にあると感じています。
リグレッションテスト作成用 Skill を運用することで、QA/PdE が自ら手を動かす作業がなくなり、レビューだけが残る形になりました。
具体的には、QA/PdE が自ら手を動かして行っていた、次のような作業がなくなりました。
QA：テスト起票
これまでは、大枠の設計方針が決まった後、QA がテストの起票を担当していました。
設計方針を、具体のテストケースに起こす上で、次のことを考える必要があります。
テストデータの準備手順
操作手順
期待結果
実装するテストケース数が少ない場合は大きな負担ではありませんが、10件以上程度になってくると、少しまとまった時間をとる必要がありました。
新しいプロセスでは、QA が Claude Code から リグレッションテスト作成用 Skill を呼び出すことでテスト分析・設計と同時に起票まで行ってくれるようになり、この負担がなくなりました。
PdE：起票されたテストケースの Claude Code への受け渡し
テストケースは社内ツール上で管理されているため、テスト実装を担当する PdE が、QA によって起票されたテストケースを Claude Code に受け渡すときに一手間必要になっていました。
新しいプロセスでは、GitHub Issue 内にテストケースが記述されるようになっているため、Claude Code に実装してもらう場合は GitHub Issue のリンクを Claude Code に教えてあげるだけでよくなり、PdE → Claude Code へのテストケースの受け渡しの負担がなくなりました。
変わらないものは何か？
ふりかえりによる成長サイクルを回す必要がある
リグレッションテスト作成用 Skill から毎回理想通りのアウトプットが得られるとは限りません。 そこで、リグレッションテスト分析・設計・起票のセッションが終わったら、理想のアウトプットとの差分をテーマに QA/PdE と Claude Code で一緒にふりかえりをするようにしています。
「なぜ今回はできなかったか？どうしたら次はできるようになるか？」を問い、フィードバックを反映させます。このとき、具体性が高すぎると、今回できなかったことと同様の課題にぶつかった時にフィードバックを活かすことが難しくなるため、汎用的に課題解決に活かせる程度の抽象度でフィードバックをまとめられているか？を確認する必要があります。 具体を積み上げていくアプローチでは、Skill がどんどん肥大化してしまい、「Skill には書いてあるけど、実行時に Claude Code が読んでいない」状況に陥ることが想定されるためです。 こうして得られたフィードバックの内容を、Claude Code 自身で Skill へ反映させることで、改善のサイクルを回していきます。
このようなふりかえりによる成長支援は、相手が QA/PdE から Claude Code になっただけで、これまでと変わらず重要な活動であると考えます。
曖昧さや不足のある入力からは、曖昧さや不足のある出力しか生まれない
テストベースに曖昧な点が残っていたり、記述に不足がある場合、それを元に出力させたテストも当然曖昧なものになったり不足が生じるのは依然として変わっていません。
現在の Claude Code のモデルの特性として、入力の曖昧さや不足を上手に誤魔化して、「それっぽい」出力を出してくることがあるのは、みなさんも感じていらっしゃるところではないでしょうか。そこで、テスト分析・設計をする上で、曖昧な項目や、記述不足が疑われる項目については誤魔化さずに、疑問点として出力するように明示的に Skill 内で指示しています。 この工夫によって、「それっぽい」テストが生み出されるのを防ぐことが可能になります。
あとは出力された疑問点を QA/PdE が確認・解消した上でテスト設計を見直すプロセスを踏みます。このプロセスの中で考慮不足であった項目が明らかになることが経験上多くあり、テスト設計からプロダクト設計へのフィードバックがここで生まれています。
プロダクトリスクを考慮したテスト設計が必要
QA が Claude Code から Skill を呼び出してどれだけ精度よくテスト観点を洗い出しても、「このテストケースを自動化する価値があるか」の判断は人間が行っています。
プロダクトリスクの許容度はチームの状況やビジネスの文脈によって変わるものであり、ユーザーストーリーや受け入れ条件、仕様書といったテストベースから機械的に決めることができないからです。これはリスクベースドテストの考え方に基づいています。すべての観点を同等に自動化するのではなく、リスクに応じて優先度をつけて自動化するテストケースを取捨選択するアプローチです。Skill の役割は網羅的な観点を素早く出すことであり、何を守るかを決める責任は変わっていません。
「テストケースを絞らずに洗い出した観点をすべて自動化すればいい、メンテナンスコストがかかっても、それすら Claude Code にやらせればいい」という意見もあるかもしれません。 しかし現状では、テストの実行時間自体は Claude Code には短縮できません。リスク低減効果が薄いテストケースまで増やしすぎると CI が律速になり、開発速度に直接影響します。
結局、「このテストを自動化する価値があるか」という判断は避けられず、そこには常に QA/PdE の判断が必要になると考えます。
Skill は “いまの” 最適解のスナップショットでしかない
Skill は QA/PdE によって決められた型に沿って Claude Code に作業をさせる技術であり、チームにとってのリグレッションテストの最適解を記述することによって、テスト対象が変わっても、定義済みの最適解に沿ったアウトプットを出してくれます。
しかしながら、ソフトウェアエンジニアリングの進化のスピードは非常に早いため、たとえば自動テストのベストプラクティスはどんどん変わっていくはずです。また、テストはテスト対象のコードの構造に依存しているため、テスト対象の構造が変われば、それに合わせてテストも変化していかなければなりません。
Skill は、あくまでも ”いまの” 最適解をスナップショット的に写しとることによってアウトプットに再現性を持たせているため、前述したような変化に適応して修正を加え続けなければ、すぐに陳腐化してしまうでしょう。
そのため、新たな技術を継続的にキャッチアップしながら、テスト対象のコードの構造に合わせた、リグレッションテストのその時その時の最適解を Skill に反映させ続けることは、主体的な意志をもたない Claude Code にはできないため、これまでと変わらず QA/PdE が担っていくべき活動であると考えます。
Claude Code はリグレッションテスト作成プロセスの何を変え、何を変えなかったか？
Claude Code が登場し、QA が Claude Code からリグレッションテスト作成用 Skill を呼び出すことで、テスト分析・設計・起票の一連の流れを自動で行えるようになりました。QA/PdE から作業が消え、Skill のアウトプットをレビューすることが仕事になりました。
プロセスが大きく変わる中で、変わらないものも見えてきました。
Skill を改善し続ける責任は変わりません。ふりかえりを通じてフィードバックを Skill に反映し、技術の進化やコード構造の変化に合わせて更新し続けることは、ふりかえりの相手が QA/PdE であったときと同様に、 QA/PdE 自身が担い続けるべき活動です。
リグレッションテストを設計するにあたり、テストベースの曖昧な箇所や不足が疑われる箇所を見抜き、早期に潰していくプロセスは変わらず必要です。
何を自動化する価値があるかのリスク判断も変わりません。プロダクトリスクの許容度はテストベースから機械的に決めることができず、チームの状況やビジネスの文脈を踏まえた QA/PdE の判断が必要です。
おわりに
Claude Code をはじめとする AI を前提とした開発フローの構築が、多くのチームで求められるようになってきました。
一方で、AI 自身の進化のスピードは目まぐるしく、ソフトウェア開発のベストプラクティスも変わり続けます。新しいモデルやツールへのキャッチアップだけでも一苦労ですよね。 だからこそ、変わるものと変わらないものを見極めながら、試行錯誤を続けていきたいと思っています。
この記事が、何か少しでもみなさんのチームでの取り組みの参考になれば幸いです。
