BLOGサブスレッドの日常
2026.05.18
2026年4月のサブスレッド勉強会
chao
しみずです、どうぞよろしく。
ちょっと遅くなってしまいましたが、今回は、先月開催された4月のサブスレッド勉強会についてご紹介します。
今回のテーマは『品質にAIを〜テストにおける生成AIの活用法〜』。
開発において欠かせない「テスト」の種類をおさらいしつつ、生成AIをテストにどう組み込んでいくか、具体的な検証を交えたとても興味深い内容でした!
テストは「自動化する場所の見極め」が重要
まずは、テストの全体像についての説明からスタートしました。
テストは大きく分けて「手動テスト」と「自動テスト」の2つがあります。
手動テストは、仕様を元に人間が実際にブラウザやアプリを操作して確認する方法です。ユーザーの実際の運用に近い形でテストができるメリットがある反面、「見逃しの懸念」「時間がかかる」「何度も繰り返すのが大変」というデメリットもあります。
そこで活躍するのが、テストケースをプログラム化して実行する自動テストです。
こちらは「繰り返しのテストに強く、実行が速い」のが大きな強みですが、「仕様変更のたびにテストコードを直すメンテナンスコスト」が課題になります。
さらに、自動テストの中には以下の3つの種類の紹介がありました。
- E2E(End-to-End)テスト:画面全体の動きを保証するテスト。ただし、仕様変更で操作手順が変わると壊れやすい(メンテナンスが大変)。
- コンポーネントテスト:2つ以上の関数・クラス間の統合や、APIエンドポイント、画面を構成する部品などの動きをチェックするテスト(壊れやすさは中程度)。
- ユニットテスト:関数やメソッド単体が正しく動くかを確認するテスト。部分的な動きを保証するもので、一番細かく、壊れにくいのが特徴。
| 種類 | 特徴 | 壊れやすさ |
|---|---|---|
| E2Eテスト | 全体動作保証 | 高い |
| コンポーネントテスト | 統合確認 | 中 |
| ユニットテスト | 単体検証 | 低い |
それぞれのテストの特徴を理解して、どこを自動化すべきかを見極めるのが大切ということを改めて実感しました。
生成AIでテストは作れるが、網羅性は不足する
講義の後半では、生年月日を入力するフォームを題材に、生成AIにテストケースを作らせてみた検証結果が紹介されました。これがとってもリアルで面白かったです!
① 仕様書を元にAIにテストを作ってもらった場合
一見綺麗なテストケースができあがりましたが、よく見ると「エッジケース(境界値など)」のテストが足りず、網羅性はイマイチという結果に。
② 仕様書なしで、画面のスクリーンショットだけで依頼した場合
こちらも網羅性は低めでした。ただし、あとから仕様を追加で与えると、①の仕様書から作った場合と同程度のクオリティまで引き上がったそうです。
③ テストが難しいメソッドのテストコードを書いてもらった場合
Androidの onViewCreate のテストコード作成をAIに指示したところ、AIが「テストがしやすいように、プログラム全体の構成を大きく変更する」という出力が返ってきたとのこと。
「AIに丸投げすれば完璧なテストができる」というわけではなく、AIに良いアウトプットを出してもらうためには、人間側が「テストの種類や仕様」をしっかり理解して正しく指示を出す必要があると、とても勉強になりました。
まとめ
今回のまとめとして、「AIはあくまで副操縦士(Copilot)」という言葉がありました。
テストの種類や目的を理解した人間が適切にハンドリングして初めて、AIは最高のパフォーマンスを発揮してくれます。うまく利用して、開発の品質とスピードをどんどん上げていきたいですね!
終わりに
サブスレッドでは、このように現場に近いテーマで
生成AIや品質向上の取り組みを継続しています。
- テスト自動化
- AIを活用した開発効率化
- 品質改善のナレッジ共有
今後も開発力を高める取り組みを続けていきます。
また、サブスレッド勉強会は毎月開催しております。
このように実業務に直結する技術テーマから、日々の生活に役立つ知識まで、幅広いテーマを扱っています。
ご興味のある方は、お問い合わせフォームや最寄りの弊社スタッフまで、お気軽にお声がけください!
今日はサブスレッド勉強会!
— 株式会社サブスレッド (@subthread) April 22, 2026
テストにおける生成AIの活用法について学びます。#今日のサブスレッド pic.twitter.com/A4S1J8mkeA
この記事を書いた人
chao
