AI生成コードの「意図不明」に立ち向かう：テスト設計3つの型

TL;DR

• AI生成コードのテストは「実装の詳細」ではなく「振る舞い」を検証する
• 3つの型：振る舞い駆動テスト・プロパティベーステスト・スナップショットテスト
• 「自分が書いていないコード」のテスト設計こそ、AI時代のエンジニアの中核スキル

---

はじめに

本記事は、AI生成コードのテスト戦略を3層で整理した親記事の「層1: ユニットテスト設計」を深掘りします。 👉 AI生成コードのテスト戦略：品質を「祈り」から「仕組み」に変える

AI生成コードのテストで最初にぶつかる壁は、「自分が書いていないコードをどうテストするか」です。

従来のテスト設計は、暗黙的に「コードを書いた本人がテストを書く」前提でした。実装者は意図を知っているので、テストすべきエッジケースも、境界値も、想定外の入力も把握している。しかしAIが書いたコードには、この「意図の伝搬」がありません。

本記事では、この課題に対処するための3つのテスト設計パターンを、コード例付きで解説します。

---

1. なぜ「実装を読んでからテストを書く」が破綻するか

量の問題

AIエージェントが1日に生成するコードは、人間の数倍から数十倍です。すべての実装を精読してからテストを書く余裕はありません。

脆さの問題

AI生成コードの実装詳細に依存したテストは、AIが同じ仕様で再生成しただけで壊れます。たとえば以下のテストを考えてみましょう。

// 脆いテスト：実装の内部変数名に依存
test("calculateDiscount uses tieredRate", () => {
  const result = calculateDiscount(1000);
  expect(result._tieredRate).toBe(0.1); // 内部実装に依存
});

AIがリファクタリングして_tieredRateを_discountMultiplierに変えただけで、このテストは壊れます。検証すべきは「割引計算が正しいか」であって、「内部変数名が何か」ではありません。

発想の転換：仕様からテストを書く

受入条件を先に書くTDD実践で紹介したように、テストの出発点は「実装」ではなく「仕様」です。仕様さえ明確なら、実装がAIであろうと人間であろうと、テストは同じように書けます。

コンテキスト負債を減らすためにIssueの要件解像度を上げる取り組みは、そのままテスト設計の品質向上につながります。

---

2. 3つのテスト設計パターン

型A: 振る舞い駆動テスト（BDD）

考え方: 「外から見た振る舞い」をGiven-When-Then形式で記述し、実装の内部構造に依存しないテストを書く。

// 振る舞い駆動テスト：外部仕様のみに依存
describe("割引計算", () => {
  test("1000円以上の注文には10%割引が適用される", () => {
    // Given: 1000円の注文
    const order = createOrder({ amount: 1000 });

    // When: 割引を計算
    const result = calculateDiscount(order);

    // Then: 10%割引 = 900円
    expect(result.finalAmount).toBe(900);
  });

  test("999円以下の注文には割引が適用されない", () => {
    const order = createOrder({ amount: 999 });
    const result = calculateDiscount(order);
    expect(result.finalAmount).toBe(999);
  });
});

BDDが効果的な場面:

• 受入条件が明確に定義されている機能
• CRUD操作、バリデーション、ビジネスロジック
• 入出力の関係が明確なピュア関数

BDDの限界:

• 「すべての入力パターン」を人間が列挙する必要がある
• エッジケースの漏れは、テスト設計者の想像力に依存する
• AIが予想外の実装をした場合、想定外のバグを見逃す可能性がある

この限界を補うのが、次のプロパティベーステストです。

型B: プロパティベーステスト

考え方: 個別のテストケースではなく、「すべての入力に対して成り立つべき性質（プロパティ）」を定義する。テストフレームワークがランダムな入力を大量に生成し、性質が破れるケースを自動探索する。

import { fc } from "@fast-check/vitest";

describe("割引計算のプロパティ", () => {
  test("割引後の金額は常に0以上", () => {
    fc.assert(
      fc.property(fc.integer({ min: 0, max: 1_000_000 }), (amount) => {
        const order = createOrder({ amount });
        const result = calculateDiscount(order);
        return result.finalAmount >= 0;
      }),
    );
  });

  test("割引後の金額は元の金額以下", () => {
    fc.assert(
      fc.property(fc.integer({ min: 0, max: 1_000_000 }), (amount) => {
        const order = createOrder({ amount });
        const result = calculateDiscount(order);
        return result.finalAmount <= amount;
      }),
    );
  });

  test("同じ入力には常に同じ結果を返す（決定性）", () => {
    fc.assert(
      fc.property(fc.integer({ min: 0, max: 1_000_000 }), (amount) => {
        const order = createOrder({ amount });
        const r1 = calculateDiscount(order);
        const r2 = calculateDiscount(order);
        return r1.finalAmount === r2.finalAmount;
      }),
    );
  });
});

プロパティベーステストが効果的な場面:

• 数値計算、ソート、フィルタリングなど「普遍的な性質」が定義できる処理
• AI生成コードの境界値バグの自動検出（人間が思いつかないエッジケースを探索）
• データ変換処理（「変換後も元のデータ量は保存される」等）

プロパティベーステストの限界:

• 「プロパティ」を定義するには、ドメイン知識が必要
• UIやI/Oが絡む処理には適用しにくい
• テスト実行時間が長くなりやすい（CI設定で最大試行回数を調整）

型C: スナップショットテスト

考え方: 関数やコンポーネントの出力をスナップショットとして保存し、次回実行時に差分がないか検証する。AIが再生成した際の「意図しない変更」を検知する安全網。

describe("レポート生成", () => {
  test("月次レポートの出力構造が変わっていない", () => {
    const report = generateMonthlyReport({
      month: "2026-01",
      data: sampleData,
    });
    expect(report).toMatchSnapshot();
  });
});

スナップショットテストが効果的な場面:

• UIコンポーネントのレンダリング結果
• APIレスポンスの構造
• 設定ファイルやコード生成の出力

スナップショットテストの注意点:

スナップショットテストの最大のリスクは「安易な更新」です。AIがコードを再生成してスナップショットが壊れたとき、差分を確認せずに--updateで更新すると、スナップショットテストの意味がなくなります。

チームルールとして「スナップショット更新は差分レビュー必須」を徹底しましょう。CIでスナップショットの自動更新を禁止し、ローカルで明示的に--updateを実行 → 差分をコミット → レビューで確認、というフローにします。

---

3. テスト設計の判断基準

3つの型をどう使い分けるか。以下のフローチャートで判断できます。

graph TD
    A["AI生成コードのテストを書く"] --> B{"受入条件は明確か？"}
    B -->|はい| C["型A: 振る舞い駆動テスト"]
    B -->|いいえ| D{"普遍的な性質を定義できるか？"}
    D -->|はい| E["型B: プロパティベーステスト"]
    D -->|いいえ| F["型C: スナップショットテスト"]
    C --> G{"エッジケースが多い？"}
    G -->|はい| H["型A + 型Bの組み合わせ"]
    G -->|いいえ| C

実践的な組み合わせ:

| 対象コード | 推奨する型 | 理由 | | ---------------- | ------------------------- | ---------------------------------------- | | ビジネスロジック | 型A + 型B | 仕様が明確＋エッジケース探索 | | データ変換 | 型B | 「量が保存される」等の性質が定義しやすい | | UIコンポーネント | 型A + 型C | 振る舞い＋構造の安定性 | | API統合 | 型C（+ Contract Testing） | 出力構造の安定性 | | 数値計算 | 型B | 数学的性質の検証に最適 |

重要なのは、1つの型に固執しないことです。AI生成コードは多様な形で現れるため、対象に応じて型を組み合わせるのが実践的です。

LLMを統合した機能のテストでは、ユニットテスト設計だけでは不十分です。LLMとの境界をどうテストするかは、Contract Testingの手法が必要になります。 👉 LLM出力は毎回変わる：Contract Testingで「変動に強い」テストを作る

---

まとめ

AI生成コードのテスト設計は、「書いた本人がテストする」という従来の前提を手放すことから始まります。

• 型A（振る舞い駆動）: 仕様からテストを書く。最も基本かつ汎用
• 型B（プロパティベース）: 人間が思いつかないエッジケースをランダム探索で発見
• 型C（スナップショット）: AI再生成時の意図しない変更を安全網として検知

「テストは実装者の仕事」という認識を「テストは仕様設計者の仕事」に更新することが、AI時代のテスト設計の第一歩です。

• AI生成コードのテスト戦略：品質を「仕組み」に変える
• LLM出力は毎回変わる：Contract Testingで「変動に強い」テストを作る
• AI生成PRの品質ゲートを自動化する：リスクベースCI設計
• 受入条件を先に書くTDD実践
• コンテキスト負債：AI開発における最大のボトルネック