AI時代に問い直すユニットテストの価値

AI時代に問い直す ユニットテストの価値 Takeshi Yonekubo Aug. 19, 2025 @ QA Tech Talk #2

※本日の資料は後ほど公開します About Me 米久保 剛 (よねくぼ たけし) X: @tyonekubo note: https://note.com/yonekubo Docswellで400K+ PV 最近、韓国語版も 出ました リファクタリング 特集の第1章を寄稿

（今日のトークにおける）ユニットテストの定義 開発者テストとして自動化する、小規模のテスト （E2Eや統合テストの話はしない） 定義： ● 1単位の振る舞い（a unit of behavior）を検証すること ● 実行時間が短いこと ● 他のテスト・ケースから隔離された状態で実行されること 『単体テストの考え方/使い方』Vladimir Khorikov

1. ユニットテストの意義

ユニットテストの目的 なぜユニットテストを書き、それを自動化したいのか？ ● ● ● ● 検証 - コンポーネントが期待通り動作することの検証 保護 - 機能退行（リグレッション）からの保護 文書化 - 実例を用いて振る舞いの仕様を文書化 設計支援 - 良い設計へと導くツール（TDD）

自動化以前 テスティングフレームワーク（xUnit）普及前： ● 開発者はコードを実装した後、ローカル環境でデバッグ作業を 行う ● 次の工程では、打鍵による機能テスト（単体テスト＝単機能テ スト）を行う ● 後工程で多くの不具合が発見され、手戻りによる修正コストが 高い QAエンジニアも、開発者、PMもみんな不幸

シフトレフト より前工程から品質を担保していく ユニットテストを含むテスト自動化はシフトレフトの手段の一つ

ユニットテストが開発者に与える、2つの「自信」 コードが完成したという「自信」 ● 完成基準が明確となる ● 客観的な評価が可能となる（レビュー） 他のソフトウェア構成要素と統合して大丈夫という「自信」 ● 早過ぎる統合は不幸を生む ● 各々の部品は、単体レベルの品質基準をクリアしている

2. AIへの委託

生成AI技術の発展 開発スタイルの大きな変化： Vibe coding / Agentic coding

ミニ・ウォーターフォール ● 仕様を与え、それを満たすようにAIに実装させる ● AIによる実装はブラックボックスとみなす ● 人間による実装のレビューは最低限とする ？ 仕様 実装

どこまで委託するか？ AIへの発注単位（委託範囲）は？ ● ● ● ● ● システム サブシステム モジュール コンポーネント クラス

委託範囲の検討 委託範囲を決めるうえで考慮すべき要素： ● ドメインの重要性や複雑度 ● ソフトウェアの位置付け（基幹/周辺、SoR/SoEなど） ● 組織文化やAI習熟度

委託範囲の検討 プロトタイプや周辺ツール、ワンショットのアプリではない、 リアルガチのアプリケーションにおいて重要な判断基準とは？

運用可能性 「自信」をもって本番運用できるか？ ● 柔軟性 ○ 継続して発生する変更に低コストで迅速に対応できる能力 ● 可観測性 ○ 障害やその兆候を捉えて、適切な活動へ繋げる能力 ● 耐障害性 ○ 障害や不測事態に対して安全かつ迅速に対応できる能力

現実的な選択 「自信」をもって本番運用できる範囲を、AIに委託する →多くの組織では、現時点ではそんなに広くない 適切に分割された「振る舞い」を実現するコンポーネント単位でAI に委託する ？ コンポーネント仕様 実装

3. AIとの協働

アンチパターン 「〜〜を実装して。テストコードも書くこと」 「実装が完了し包括的なテストスイートも作成しました！」 問題点： ● AIは、コードの内部実装に依存したテストを書きがち ● コードカバレッジを上げることが目的化する

アンチパターンが招く結果 表面的なテストの量産 ● ● ● ● ● テストは全部グリーン 高いカバレッジ テストケースの構造のわかりにくさ テスト観点の抜け漏れ 保守性の低いテストコード 開発者（人間）によるレビューなし →自動化以前の「開発者によるデバッグ作業」と大差ない

良いテストコードをAIに生成させるには？ コンテキストが、成果物の品質を決定づける 入力（コンテキスト、プロンプト）： ● ガイドラインとなる文書 ● コンポーネントの仕様 出力（AIが生成する成果物） ● テストコード ● プロダクションコード

ガイドライン ● ガイドラインの記載内容例 ○ テスト戦略、テスト設計方針 ■ ユニットテスト作成対象 ■ カバレッジ基準 ■ テスト設計時のテスト観点やテスト技法 ○ テスト実装規約（サンプルコードつき） ■ テスティングフレームワーク/ライブラリの利用方針 ■ テストコードの構造や命名規約 ■ テストダブル（スタブやモック）の利用方針 ※Markdown形式でrepo内のdocsに入れておく

テストファースト？テストラスト？ ● テストコードのない既存コードに対してはテストラストで追加 ● 基本はテストファースト ○ 内部実装に依らない、観察可能な振る舞いに対してテストする ○ テストコードそのものが、LLMのコンテキストとなる ● テストファーストのアプローチはいくつかある ○ 全てのテストケースを先に書く ○ TDDで段階的に書く ○ 代表的なテストケースを先に書く

代表的なテストケースを先に書くアプローチ 1. コンポーネント仕様の明確化 人間が主導 or AIと協働 2. 代表的テストケース作成 人間が作成 or AIと協働 3. コンポーネント実装 AIが生成 4. テストケース増幅 観点を合意後、 AIが生成 5. レビューと調整 人間が最終チェック（サンプリング） ウォーターフォールの手戻りリスクを避け、アジャイルに！

まとめ

AI時代のユニットテスト戦略 ● AIに任せることはできない、人間が責任をもつべき役割 ○ テスト戦略や方針の策定 ○ テストコードの品質評価 ● 自動テストに関するドメイン知識は重要さを増す ○ テストに関する知識を体系的に学ぶ ○ 実践して経験を積む（AIに経験機会を奪われないように！） ○ 経験で得たフィードバックにより、知識を知恵にする

ご清聴ありがとうございました