記事のサマリー（TL;DR）
- SmartHRの「基本機能」チームが2026年前期の約半年間、結合テスト3工程（観点作成・仕様書作成・実施）それぞれへのClaude Code活用を検証
- テスト仕様書作成は約30分でたたき台を生成でき「AI主導に価値あり」、観点作成は「人間主導が速い」、テスト実施は「現時点でROI見込めず」と工程別に結論が分かれた
- ハーネス（Skills）なしでは品質が安定せず、ドメイン知識を持たせたSkillsの作り込みがAI活用の可否を左右することが明確になった
Rails × Railsアプリ開発チームの結合テスト品質管理に関わる示唆
SmartHRが対象とするのは同社最大のRailsアプリケーションであり、仕様の複雑さとコードベースの規模が品質保証コストを押し上げている典型例だ。同様の課題は、国内でkintoneやSalesforceをRailsで専用UI補完している開発チーム、あるいはSmartHR・freee・マネーフォワードとの連携システムを内製で持つ情シス・開発部門にも起こりやすい。
本記事が示す最大の実務的示唆は「AIが向いているのはインプットがそろっていて人間がやると手間がかかる工程」という発見だ。テスト観点ドキュメント（因子レベルの箇条書き）さえ用意できれば、Claude Codeがテスト仕様書のたたき台を約30分で生成できる。この「インプット準備 → AI生成 → 人間一次レビュー → チームレビュー」の流れは、SaaSの業務フロー検証テストや受け入れテストの工数削減にそのまま応用できる。
一方、デシジョンテーブルやペアワイズ法を使うべき「条件を網羅する系のテストケース」はAIの非決定論的な出力と相性が悪く、PICTやGIHOZなどの決定論的ツールとのハイブリッド運用が必要という点は、QA担当者が押さえておくべき現実的な制約だ。
詳細
問題意識：ボトルネックが実装からレビュー・QAに移行
SmartHRの「基本機能」チームは2026年に入ってから、AIに開発を主導させて人間が監督役に回る開発プロセスを本格的に検証してきた。仕様駆動開発（SDD: Specification-Driven Development）や、仕様のみを渡してAIに実装方法を委ねる進め方などを採用した結果、従来2〜3スプリントかかっていた実装タスクが1スプリントで完了するケースも出てきた。
しかし、コードレビューとQAの工程では現時点でもAIの活用は補助的にとどまっており、人間が主導する必要がある。実装速度の向上に比例して、これら2工程が開発全体の新たなボトルネックになった。
本記事では特に、マニュアル（手動）での結合テストにAIを活用してボトルネックを解消しようとした半年間の試行錯誤を総括する。
マニュアル結合テストの負担が増えた背景
チームでは、フィーチャーのタスクをユーザーストーリー単位に分割し、1ユーザーストーリーにつき1PRを作成している。PRごとに結合テストに近い手厚いテストを実施しているため、実装が速くなるとPR単位の結合テストとフィーチャー開発末尾の結合テストの両方が増加する。
フィーチャー
├── ユーザーストーリー1のPR → PR単位の結合テスト
├── ユーザーストーリー2のPR → PR単位の結合テスト
└── ユーザーストーリー3のPR → PR単位の結合テスト
↓
フィーチャー開発の最後の結合テスト
その結果、スプリント内でマニュアルテストに費やす時間が増え、スクラムのレトロスペクティブでは「マニュアルテストに疲れた」という声が上がるようになった。
結合テスト3工程へのAI導入の全体像
チームはもともと以下の3工程で結合テストを実施していた。
- 結合テスト観点作成
- 結合テスト仕様書作成
- 結合テスト実施
この3工程それぞれについて、AI主導のプロセスを試みた。
工程1：結合テスト観点作成へのAI導入
ハーネスなしでは品質が安定しない
最初の検証は、Skills等のハーネスを使わない素のClaude Codeで実施した。ここでいう「ハーネス」とは、AIに作業させる前にあらかじめ与えておく手順・フォーマット・ドメイン知識といった枠組みのことだ。
過去のフィーチャーを題材にPRD（プロダクト要求仕様書）とPRをプロンプトで与え、同じ手順を3〜5回繰り返してテスト観点を作成させたところ、以下の問題が発生した。
- 試行ごとにフォーマットが大きく異なる
- 致命的な観点の漏れが発生する
ハーネスなしでのテスト観点作成は品質が安定せず、AI主導は難しいという結論に至った。
ハーネス（Skills）を作成すると品質が安定する
次に、過去フィーチャーの複数の結合テスト仕様書をClaude Codeに与えて、対象機能に特化したテスト観点作成用のSkillsを生成させた（skill-creatorを活用）。
Skillsを適用して同様の検証を行ったところ、次の改善が確認された。
- Skillsで必須と定めた観点が出力から漏れなくなった
- ドキュメントのセクション構成が固定され、レビューしやすくなった
- パフォーマンス・アクセシビリティ・多言語対応といった一般的な観点の有無を指定できるようになった
試験導入で浮かび上がった課題：観点が詳細すぎる
Skillsを適用した状態で開発中のフィーチャーに試験導入した。5人程度のメンバーでモブレビューを行い、約2時間かけてLGTMが出るまで繰り返すプロセスを取った。
網羅性という点では高品質のドキュメントが作成できた。しかし課題も浮かび上がった。AIが作成したテスト観点ドキュメントが詳細すぎてレビューしにくいという問題だ。
例えば「条件を網羅する系のテスト」では、AIは申請方式・申請提出者・申請承認者・承認要否・適用日の指定を掛け合わせた40行規模のパターン表を出力する。各観点には優先度付きの詳細な説明文も添付され、テスト仕様書に近い分量になった。
一方、従来の人間が書くテスト観点では「申請方式（本人申請／代理申請）」「ロール（メンバー／事務担当者／管理者）」「適用日（過去／現在／未来）」のように因子のみを列挙する。十数行に収まり、因子レベルの見落としがないかというテスト観点本来のレビューができる。
書籍『ソフトウェアテスト徹底指南書』（井芹洋輝著、技術評論社、2025年）でも、テスト観点を詳細に洗い出しすぎると発散・複雑化して読み取りにくくなると指摘されており、今回の出力がまさにこのケースに陥っていた。
まとめ：テスト観点作成は人間主導が優位
チームから「テスト観点はAI主導にするメリットが薄い」という意見が出た。ドメイン知識を持つ人間なら30分〜1時間でたたき台を作成できるため、人間がベースを作成し、AIは抜け漏れのチェックやレビューに特化させるほうが速く品質も高い、という結論に至った。
次回はSkillsをレビュー専用に作り替え、人間が作成した観点をドメイン知識を与えたAIにレビューさせる新しいフローを試す予定だ。
工程2：結合テスト仕様書作成へのAI導入
従来の仕様書作成プロセスは次のとおりだった。
- Claude Codeにテスト観点からスプレッドシート用CSVを出力させる
- CSVを人間がスプレッドシートにインポートする
- テストケースの過不足・期待値誤り・フォーマット崩れを手作業で修正する
- 修正後の仕様書をもとにチームレビューを行う
AI主導にすることで、CSVを経由する手順と手作業修正を削減できると期待した。
NotionへのテストツールMCP移行
従来はNotion（テスト観点）とGoogleスプレッドシート（テスト仕様書）を使い分けていた。AIが直接読み書きできるのはMCPサーバーが利用できるNotionのみだったため、今回から結合テスト仕様書もNotionに移行した。スプレッドシートの表現の自由度をNotionでどう実現するかは今後の課題として残っている。
汎用Skillsでは付加価値なし → ドメイン特化Skillsで安定
フォーマットのみを定義した汎用Skillsでは、テスト観点をそのままフォーマットに並べただけの仕様書が生成された。元のテスト観点に対して付加価値がほとんどなかった。
この検証で気づいたのは、テスト観点からテスト仕様書を作成する作業が単なるフォーマット変換ではなかったということだ。人間が手作業で行っていたのは以下の肉付けだった。
- 期待値の追加
- 因子の組み合わせからパターン表の作成
- 必要なテストデータの導出
- テスト担当者向けの操作手順の記述
- 効率のよいテストスイートの組み立て
- テストケースの重複検出
そこで対象機能のドメイン知識・フォーマット指定・重複テストケースのマーキングを盛り込んだ専用Skillsを作成した。これを適用して3〜5回の試行を行ったところ、以下が安定した。
- 各テスト観点に正しい期待値が追加される
- 各テスト観点に具体的な操作手順が追加される
- テストケースの重複が検出される
- 元のテスト観点の取りこぼしがなくなる
モブでの試験導入：30分でたたき台が完成
チームで集まり、Claude Codeに結合テスト観点ドキュメントを渡してから約30分でたたき台が完成した。CSVを経由していた従来の手順を丸ごと省略できた。
ただし2つの課題が浮かんだ。
課題1：モブレビューが現実的ではない
- 分量が多い（AIは1手順ずつ詳細に記述するため全体が膨大になる）
- どこを重点的に見ればよいかが仕様書から読み取れない
- テストケースの作成意図が誰にも分からず、全員でゼロから解読する作業が発生する
実際に1週間スプリントの初日に3時間かけてモブレビューを行ったが、進んだのは全体の約10%だった。レビュー班とテスト実行班に分けることでなんとか1スプリントに収めた。
課題2：条件を網羅する系のテストケースで漏れが発生
デシジョンテーブルを使うような「条件を網羅する系のテスト」で、本来含まれるべきケースの漏れが発生した（例：「権限 × 操作対象」の4規則のうち1規則に対応するケースが欠けるなど）。
パターンを決定論的に網羅したいという要求と、AIの非決定論的な出力は相性が悪い。この領域については、PICTやGIHOZなどの決定論的ツールをSkillsから呼び出すハイブリッドアプローチが現実的だという結論になった。
まとめ：テスト仕様書作成はAI主導に価値あり
テスト観点から仕様書を作成する工程は、人間がやると手間と時間がかかる。AIなら約30分でたたき台まで持っていけるため、AI主導にするメリットが大きい。ただし出来上がった仕様書をそのままモブレビューするのは非現実的なため、次回はオーナーシップを持つ人を決めてAI成果物を一次レビューする形を試す。
工程3：結合テスト実施へのAI導入
Claude Code × Playwright CLIの実行原理
Claude CodeとPlaywright CLIを連携させると、以下のサイクルで動作する。
playwright-cli snapshotで画面のスナップショットをYAML形式で取得- Claude Codeがスナップショットを解析し、目的の要素を探す
- Claude Codeが
playwright-cliコマンドを実行してブラウザを操作 - 期待する結果が得られたと判断するまで1〜3を繰り返す
なお先行事例としてZOZOのテックブログ（Claude Code × Playwright CLIの本番業務レベルでの運用事例）を参考にしたと明記されている。
テストコード生成ではなく直接実行を選択した理由
E2Eテスト導入には2つのアプローチが考えられる。
- 方針A：コード化 画面探索結果をもとにPlaywrightのテストコードを生成・資産化する
- 方針B：直接実行 自然言語のテスト仕様書をそのまま渡し、AIにブラウザを操作させる（コードは残らない）
今回は方針Bを重点検証した。方針Aはコード化までのオーバーヘッドが大きく、また今回の目的はリグレッションテスト用のスイート構築ではなく「フィーチャー開発ごとのマニュアル結合テストの負担軽減」だったため、メンテナンスが必要なコードを残す意義が薄かった。
初期検証での実速度の問題
ハーネスなしで検証したところ、実用に耐える速度が出なかった。主なボトルネックは2つ。
-
ドメイン知識がなく探索効率が悪い 例えば「代理申請フォームの作成確認」というテストケースでは、AIが前提条件（代理提出設定の事前作成）を知らず、エラーを受け取ってから探索を始める。1画面遷移ごとに「スナップショット取得 → AI解析 → コマンド発行」という重いサイクルが発生するため、無駄な遷移が積み重なる。
-
単純な操作でもリトライが多発 「ログインIDとパスワードを入力してログインボタンを押す」という操作でも、ref（要素参照キー）の指定ミスによるエラーとリトライが発生し、1コマンドあたり数秒の積み重ねで全体実行時間が膨らむ。
ハーネスを整えることで実用的な速度に近づく
ドメイン知識をSkillsに登録することで無駄な探索を削減した。具体的には以下を記述した。
- 機能間の依存関係と前提条件（「代理申請には代理提出設定が必要」など）
- 主要画面への直リンクURL
- フォームの必須項目とテスト用データの規定値
加えて、ref安定性が高い画面（ログイン画面や固定フォーム画面など、何度スナップショットを取っても同じref番号が割り当てられる画面）については、ref番号を直接Skillsに記述しておくことで、スナップショット全体の解読・推論ステップを省略できるようにした。
### Step 2: ID フィールドに id を入力
- **ref 安定性**: ✅ stable（観測値 `e37`）
- **playwright-cli の操作**:
- playwright-cli snapshot
- playwright-cli fill <ref> "<id>"
これにより、全体の実行速度は人間のマニュアルテストに近い水準まで縮まった。なお、ref番号は仕様変更で変わるため、失敗時は取り直して更新するルールもSkillsに定義している。
課題：AIに任せるメリットが薄い
速度が改善されても、2つの理由からAIに任せるメリットが薄いという課題が残った。
理由1：人間のマニュアルテストのほうが速く、バックグラウンド実行にも壁がある
速度は近づいたが現時点では人間が手操作するほうが速い。非同期実行するにも、録画を人間が確認する時間コストが発生するか、AIの完了報告をそのまま信頼するかの二択になる。後者は品質保証の観点から組織レベルの方針決定が必要であり、開発チームの工夫だけで踏み切れる話ではない。
理由2：トークン消費量が多くROIが低い
Claude Code × Playwright CLIによるテスト実行はPlaywright MCP経由と比べてトークン効率は良好だが、結合テストのように長時間・多操作のテストを実行すると消費量は大きくなる。マニュアルテストの代替として日常的に回すと、浮く人件費に対してAPIコストが見合わないという結論になった。
まとめ：技術的には成立するがROIが見込める場面は少ない
現時点での部分的な活用にとどまっている領域は以下の2つだ。
- テストデータの作成
- 結合テスト完了後に修正が入ったときの影響範囲に絞ったリグレッションテスト
自然言語でAIにテストさせること自体は技術的に成立すると確認できた。実行速度やAPIコストの条件が変われば、AI主導で任せる余地は広がると見ている。
総括：工程によってAI主導のメリットは大きく異なる
| 工程 | 結論 | 理由 |
|---|---|---|
| テスト観点作成 | 人間が主導するほうがよい | ドメイン知識のある人間なら30分〜1時間で書ける。AIの出力は詳細すぎてレビューしにくい |
| テスト仕様書作成 | AI主導に価値がある | 人手では時間がかかる作業を約30分でたたき台にできる |
| テスト実施 | 現時点ではROIが見込めない | マニュアルテストより速くならず、トークンコストが見合わない |
AIが向いているのは「インプットがそろっていて、人間がやると手間がかかる工程」だ。テスト仕様書の作成がこれにあたる。一方、少ない情報から方針を決める観点作成や、確実性が求められるテスト実施では、人間が主導したほうが結果的に速く確実だった。
「QAがボトルネック」という言葉の解像度
検証を通じて、「QAがボトルネック」という言葉は工期の問題と精神的負担の問題に分けて考える必要があると分かった。
- 工期としては致命的なボトルネックではない チームの人数を動員すれば、テスト仕様書の作成と実施でそれぞれ1スプリント程度に収まる。リリースを大きく遅らせるほどではなかった。
- 精神的な負担は増大している 実装が速くなったことでテストが回ってくる頻度が上がり、スプリントごとに手作業テストが全員に回ってくる状態になっている。レトロスペクティブで上がった「マニュアルテストに疲れた」という声は、工期の長さではなくこの頻度への反応だった。
工期に収まっているからといって精神的負担を無視すれば、チームのモチベーションは徐々に下がる。結合テスト工程へのAI活用で開発体験を向上させる取り組みは、引き続き続けていくとSmartHRのエンジニアは締めくくっている。