Blog
ブログ

2026年07月02日

Claude Code Skillsを活用したSalesforce結合テスト設計の効率化 ～影響分析・テストケース生成・レビューの自動化を試してみた～

はじめに

こんにちは。事業推進部のSです。

Salesforce開発において、機能開発後の結合テスト設計は意外と工数がかかる作業です。変更内容を確認しながら影響範囲を洗い出し、テスト観点を整理し、さらに実行可能なテストケースへ落とし込む必要があります。近年は生成AIを活用してこれらの作業を支援するケースも増えていますが、毎回同じプロンプトを入力し直したり、前工程の出力を次のプロンプトへコピーしたりといった手間や、プロンプトが一致しないことで品質が不安定になってしまうという問題がありました。

そこで今回は、Claude CodeのSkills機能を利用し、以下のタスクを半自動化することで効率化ができないかを検証してみました。

  • 変更内容の影響分析
  • テスト観点抽出
  • 結合テストケース生成
  • QAレビュー

実際の案件は利用できないため、今回は架空の「休暇申請システム」を題材にデモ環境で今回の記事向けの動作検証を行っています。

検証環境

今回利用したサンプルシステムは以下の構成です。

 

カスタムオブジェクト

Leave_Request__c

主な項目

項目 テスト観点
Start_Date__c 開始日
End_Date__c 終了日
Leave_Days__c 休暇日数（数式項目）
Status__c 申請状態
Director_Approval_Required__c 部長承認要否

数式項目

End_Date__c - Start_Date__c + 1

入力規則

開始日が終了日より後の場合は保存不可

 

承認プロセス（改修前）

申請者
↓
上長承認
↓
承認完了

改修内容

休暇日数が4日以上の場合のみ、承認プロセスに部長承認を追加する。

申請者
↓
上長承認
↓
3日以下：この時点で承認完了
4日以上：更に部長承認に進む
↓
部長承認
↓
承認完了

Claude Code Skillsの構成

今回作成したSkillは以下の3ステップ構成です。

.claude/
└── skills/
    └── salesforce-integration-test/
        ├── SKILL.md
        └── templates/
            ├── step1-analysis.md
            ├── step2-generate.md
            └── step3-review.md

SKILL.mdには、templatesに入っているファイルを順番に実行するという仕様にしています。
また、ここでClaude Codeを使用する理由としては、Gitによるバージョン管理を行っていることで、ブランチやコミットなどの修正範囲を指示し、修正点をピンポイントで取り扱うテストが行えるためです。

---
name: salesforce-integration-test
description: Salesforceの変更仕様やGit差分から影響分析、結合テストケース生成、QAレビューを実施する
---

# Salesforce Integration Test Skill
Salesforceの改修案件に対して結合テスト設計を支援するスキルです。

## 実行フロー
以下の順序で実行してください。
影響分析・テスト観点抽出
結合テストケース生成
QAレビュー・カバレッジ分析

## 参照ファイル
- templates/step1-analysis.md
- templates/step2-generate.md
- templates/step3-review.md

## 実行ルール
- Salesforce標準機能およびカスタマイズを考慮すること
- Git差分だけでなく関連機能への影響も分析すること
- Step1の出力をStep2へ引き継ぐこと
- Step2の出力をStep3へ引き継ぐこと
- 正常系、異常系、権限差異を必ず含めること
- Experience Cloud影響を確認すること
- Approval Process影響を確認すること
- Files(ContentDocument/ContentDocumentLink)影響を確認すること
- Permission SetおよびPermission Set Group影響を確認すること
- 既存機能へのデグレードを確認すること

## 出力品質基準
- テスト観点は具体的に記載すること
- テストケースは実際に実施可能な内容とすること
- テストデータ条件を明確にすること
- QAレビューでは未カバー観点を抽出すること
- リスク評価を実施すること

Step1：影響分析とテスト観点抽出

変更内容から影響分析とテスト観点を抽出します。

Step2：結合テストケース生成

テスト観点から結合テストケースを生成します。

Step3：QAレビュー

テストケースのカバレッジ分析とQAレビューを行います。

実際の入力と検証結果

今回Claudeへ渡した入力の一例です。最後に生成されたテストケースに対してレビューを実施しました。

【変更概要】
休暇日数が4日以上の場合、部長承認を必須とする。

【Flow変更内容】
Leave_Days__c > 3 の場合、Director_Approval_Required__c = true

【承認プロセス変更】
上長承認後、Director_Approval_Required__c = true の場合のみ部長承認へ遷移

 

Step1：影響分析とテスト観点抽出の出力結果

まず変更内容から影響分析を実施しました。以下は出力例の一部抜粋です。

機能 テスト観点
承認プロセス 4日以上で部長承認が発生すること
承認プロセス 3日以下では部長承認が発生しないこと
フロー Director_Approval_Required__cが正しく更新されること
入力規則 開始日と終了日の入力制御が維持されること
レコードロック 承認済レコードが編集できないこと

💡 効果： 単なる変更箇所だけでなく、承認プロセスやレコードロックなど周辺機能への影響も網羅的に抽出されました。

 

Step2：結合テストケース生成の出力結果

続いて、Step1の結果をもとにテストケースを生成しました。

NO テスト項目
TC001 開始日＞終了日の入力チェック
TC002 3日休暇で上長承認のみとなること
TC003 4日休暇で部長承認へ進むこと
TC004 部長却下時に却下状態となること
TC005 却下後に再申請できること
TC006 承認済レコードが編集できないこと

💡 効果： 特にテストの境界値である「3日」「4日」のケースが自動的に漏れなく生成されている点は、非常に有用だと感じました。

 

 

Step3：QAレビューの出力結果

最後に、生成されたテストケースに対してレビューを実施しました。

### 指摘事項
Flowの更新条件について、4日以上の場合にtrueへ更新する処理は確認できるが、4日以上から3日以下へ変更した際に「false」へ戻す処理が存在しない可能性があります。

この場合、本来は部長承認が不要な申請であっても、過去のデータ状態によって部長承認フローへ進んでしまうリスクがあります。

実際に仕様を確認したところ、この「値を戻す処理（デグレード対策）」の観点は考慮漏れしていたため、追加検討事項として非常に価値のある指摘でした。

生成されたテストケースの精査だけでなく、仕様上の懸念点の洗い出しにも活用できるため、テストと合わせてより成果物の品質を高めることができると実感しています。

まとめ

今回の検証では、Claude Code Skillsを利用することで、以下の動作を一連の流れとして自動化・実施できることを確認できました。

 

  • 影響分析
  • テスト観点抽出
  • テストケース生成
  • QAレビュー

 

特に、承認プロセスやレコードロックなどSalesforce特有の仕様・観点を含めてテストケースを作成できた点は非常に強力です。もちろん生成結果をそのまま鵜呑みにするのではなく、人間によるレビューや微調整は必要ですが、ゼロからテスト設計を行う場合と比較すると、影響分析や観点整理の工数を大幅に削減できます。

今後はこの知見を部署内で共有し、FlowやApex Triggerを含むより複雑な改修案件でも検証を進め、プロンプトの改善を行いながら実務への適用範囲を広げていきたいと考えています。

このページの先頭へ