はじめに
こんにちは、株式会社アサインでエンジニアをしているうちほり（@showichiro0123）です。
去る2025年10月16日に開催した「AI駆動開発 - 各社のリアルな事例と課題とは？」というイベントで「AI時代の品質保証」というテーマで登壇させていただきました。
Vibe CodingやAgentic Codingという言葉が人口に膾炙して久しく、できることが大幅に増えた一方で、AIが作るコード品質に対して不満を持つ方も増えたのではないでしょうか。私も同じような課題感を持っています。そこで、今回の発表では、アサインでの取り組みを元に、以下のトピックを取り上げてお話させていただきました。
- AI駆動開発で生産性がどれくらい変わったのか
- なぜテスト駆動開発（TDD）がAI時代に重要なのか
- プロダクトとチームをどうTDD Readyにしていくか
- 実際に取り組んで得たナレッジと残る課題
本記事では、発表資料を一部抜粋しつつ、AI駆動開発における品質保証の考え方と実践について紹介します。
開発フェーズでできる品質保証
今回の発表では、開発ワークフロー全体の中でも特に開発フェーズでの品質担保（コードを良いものにすること）に焦点を当てました。
というアサインのAI駆動開発ワークフロー全体のうち、
ここを扱いました。
ワークフローの全体像については、CHIHIRO が詳しく書いてくれているので以下の記事を参考にしてください。
AI駆動開発で生産性はどれくらい変わったのか
実際にAI駆動開発を導入してどれくらい生産性が変わっているのでしょうか。私自身のコード変更量を比較したところ、単純な追加・削除・変更行数では約1.25倍になっていました。これだけだと大した事ないなと思うのですが、ここで注目すべきは、コーディング時間は体感で50%〜70%ほどに減少しているという点です。同じ時間で作業するとコード生産ペースとしては2〜3倍になっています。
私は技術広報などコード執筆以外の仕事も担当しているため、純粋なコーディング時間は減っています。仮に同じ時間投入してコードを書くと、2〜3倍のスピードでプロダクト開発が進むということです。
私のコード変更量の詳細は以下のグラフのとおりです。
やはり、体感と同じく凄まじいスピードでコードが増えていくなという印象です。
開発フェーズの品質三銃士たち
一方で、コード品質を保つためのモダンTypeScriptの三銃士といえば以下の3つです。これらを如何にAI Drivenにしていくかが鍵となると考えています。
1. 型（Type）
- コンパイル時の整合性チェック
- 型情報によるドメイン知識の補完
2. Lint
- 構文・構造レベルの品質担保
- コーディングスタイルの徹底
3. テスト（Test）
- あるべき振る舞いの定義
- リグレッション防止
自動テストの重要性が高まる
三銃士たちはAIと向き合う中でいずれも重要なのですが、今回の発表ではテストについて扱いました。AI駆動を進める中で自動テストの重要性が高まる理由を人間目線とAI目線の両方から見ていきましょう。
人間目線での重要性
そもそも、コードの量が増えすぎて具にコードレビューすることが現実的ではなくなりつつあります。
ただし、生成コードの量が膨大でも、十分なカバレッジと検証がなされたテストコードが書けていれば受け入れ可能です。また、AIの意図せぬ破壊に対する防御（リグレッション防止）にもなります。
AI目線での重要性
テストコードは振る舞いの定義なので、そのまま仕様書になります。
特にユニットテストは、実行してPASSもしくはFAILすることによって、仕様に対して適切な実装ができているかというフィードバックになります。
vitestなど現代的なテストフレームワークであればある程度の規模でも高速にフィードバックを返すことができ、AIに「仕様を満たすコードを書けているか」という判断基準を与えることができます。
とりわけテスト駆動開発（TDD）でやる意義
AI駆動開発において、TDD（Test-Driven Development: テスト駆動開発）は特に有効です。
TDDとは、先にテストコードを書いてから実装コードを書く開発手法で、「Red（失敗するテストを書く）→ Green（テストが通るコードを書く）→ Refactor（リファクタリング）」のサイクルを繰り返します。
つまり、TDDを開発手法に据えれば、仕様 → テスト → 実装の順で生成し、中間ドキュメント的に仕様をコンテキスト化していけるということです。
また、TDDは実装を踏まえてテストリストを見直すというプロセスが含まれています。例えば「設計時に見落としていたエッジケースの存在に実装中に気づいた」等の場合に、テスト（=すなわち仕様）側を追従させるワークフローになっています。実装から知見を得て仕様を進化させることができるということです。
具体例
例えば、ログイン機能の仕様が以下のようだったとします。
仕様書
- パスワードは8文字以上
- 成功時はトークンを返す
- 失敗時はエラーを返す
テストコード
it("8文字未満はエラー", () => {
expect(login("short")).rejects.toThrow();
});
it("成功時はトークン", () => {
expect(login("pass1234")).resolves.toHaveProperty("token");
});
これはloginという関数の振る舞いを定義しており、実行してみれば、PASS or FAILのフィードバックが返り、仕様を満たすかが一目瞭然となります（中間ドキュメントになるということ）。
プロダクトコード
async function login(pw: string) {
if (pw.length < 8) {
throw new Error("パスワードは8文字以上必要です");
}
// 認証処理
return { token };
}
テストを巡る状況の改善
また、AIの登場により、ユニットテストの障壁が大きく下がりました。
AIがユニットテストの障壁を取り除く
従来、ユニットテストを書けない理由として「書き方がわからない」「時間がかかる」という2つの大きな障壁がありました。
しかし、AIの登場によってこれらの障壁は大きく低減されています。書き方がわからなくてもAIが教えてくれますし、テストコードそのものも生成してくれます。また、手作業では時間がかかっていたテスト作成も、AIなら瞬時に生成してくれます。
一方で、テストに対するリテラシーを高める必要が発生している
一方で、新たな課題も生まれています。テストケースの設計やテストコードの作成もAIに委ねることになるため、エンジニアには「AIが生成したテストが適切かどうかを判断する力」がより重要になります。
必要な知識
大きく2つの知識がエンジニアの基礎教養になりつつあると考えています。
- テスト設計技法: そもそもどのようなテストを書けばいいのか？
- ユニットテスト技法: 書かれたテストコードは適切か？
例えば、AIが生成する以下のようなテストコードを見逃さないリテラシーを身につけなければなりません。
// テストを通すために一時的に trueにする
expect(true).toBe(true);
このようなコードは一見テストが通りますが、何も検証していません。
プロダクト・チームをTDD Readyにしていこう
上記の認識を前提に、アサインでは以下の2つの取り組みを進めています。
1. as-isのテストコードを書いていく
まずは現行コードに対するテストコードを整備していきます。これはTDDの前提としてリグレッションへの耐性をつける（リファクタリングの勇気を持つ）という目的で行われています。
2025年3月: CI復旧・主要APIへのユニットテスト整備
- 放置されていたテスト関係のCI復旧
- コンバージョンに関わるAPIに絞ってユニットテストを整備（カバレッジベースで20%弱）
- AI時代を見据えてではなかったが、結果的に効果あり
2025年7月: 残る主要機能へのユニットテスト整備
- カバレッジベースで60%まで拡大
- このタイミングでClaudeCodeを導入し、パワフルに進行
実際のPRでは、126コミット、223ファイル変更という大規模なテスト追加を行いました。
2. TDDの標準化
新機能にはto-beのテストが存在することを目指します。
テスト設計・TDD勉強会
まずは開発者の目を肥やすため、以下の教材を使った勉強会を実施しました。
勉強会の様子などはこちらです。
ClaudeCodeカスタムコマンドの整備
TDD原則に従ったコード生成を促すカスタムコマンドやサブエージェントを次のように作成しました。
Your approach follows these fundamental principles:
1. **Red-Green-Refactor Cycle**: You religiously follow the TDD cycle:
- Write a failing test first (Red)
- Write the minimum code to make it pass (Green)
- Refactor to improve the design while keeping tests green
- Never write production code without a failing test
...略
このコマンドにより、AIに以下のような振る舞いを促します。
- Red-Green-Refactorサイクルの徹底
- テストファーストでのコード設計
- エッジケースの網羅的な検証
テスト×AI駆動を推進する中で得たナレッジ＆課題
バックエンドとAI駆動開発の親和性
テスト×AI駆動で特に効果が高いのはバックエンド開発です。AI駆動開発をプロジェクトに導入しようと考えている方は、バックエンドから攻めるのが良い戦略です。
APIのテストでは、最終的に「レスポンスのJSONにこういう値が入っているか」を検証することになります。これはコードに起こしやすく、AIも実際に出力されたJSONログなどを見て容易に理解できます。
つまり、バックエンドはAI駆動開発を始めやすい領域なのです。
フロントエンドUI品質担保の課題
一方、フロントエンドには課題も残っています。
現在、チーム内で主要な動線に対するユニットテストの整備を進めています。React Hooksなどロジック部分のテストはある程度書けますが、フロントエンドで最も重要な「UIがちゃんと実装されているか」「デザインと実装が合っているか」をテストするのが難しいという課題があります。
例えば以下のような点です。
- デザイン通りのレイアウトになっているか
- 文字が枠からはみ出ていないか
- 適切な余白が取れているか
これらをどう自動テストするかは、現在進行形で試行錯誤しているところです。
OpenAI DevDay Codexからのヒント
先日開催されたOpenAI DevDayで発表されたCodexというコーディングエージェントの取り組みが、1つのヒントになるのではないかと考えています。
Codexでは以下のようなアプローチを取っています。
- デザインのキャプチャ(スクリーンショット)を渡して開発を開始
- 「できました」と言われたら、実際にUIを表示させてキャプチャを撮る
- デザインと実装のスナップショットを比較し、差分をAIに自覚させる
- 「文字がはみ出している」などの違いを修正
- デザインと徹底的に一致するまで、このループを繰り返す
ClaudeCodeもCodexもマルチモーダル(テキスト以外の情報も扱える)という特徴があります。スナップショットをコンテキストとして渡し続け、フィードバックループを回すことで、UI品質を担保できるのではないかと考えています。
この分野は、まだこれから頑張っていこうというフェーズですが、期待できるアプローチだと感じています。
まとめ
本記事では、AI駆動開発における品質保証について、以下のポイントを紹介しました。
1. AI駆動開発の現実
- コード生産ペースは2〜3倍、あるいはそれ以上に
- もはや人間の目で全てのコードを見る時代ではなくなりつつある
2. 自動テスト（特にTDD）の重要性の増大
- テストコードは振る舞いの定義 = AIへの直接の仕様書・詳細設計書
- テストを流せばAIにすぐフィードバックを返せる
- AIが「コードがちゃんと書けているか」を判断できる
3. エンジニアに求められるスキルの変化
テストへの比重が高まるため、以下のリテラシー向上が必須です。
- テスト設計技法
- ユニットテストをちゃんと書く技術
- AIが生成したテストコードの適切性を判断する目
4. 段階的なアプローチ
アサインでは、以下の2つを並行して進めています。
- as-isのテスト整備: 既存コードに対するテストを充実させリグレッション体制を作る
- TDDの標準化: 新機能開発ではテスト駆動を当たり前にする下地作り
AI駆動開発は開発速度を大きく向上させますが、それに見合った品質保証の仕組みが必要です。テストを中心とした品質基盤を整備することで、AIの生成速度に負けない持続可能な開発体制を構築できます。
おわりに
本記事では、AI駆動開発における品質保証の考え方と、アサインでの実践例を紹介しました。AI時代だからこそ、テストの重要性は増しています。
この記事が皆さんのプロダクトの開発のお役に立てればと思います。
Discussion