テストケース手書きの限界

LLM アプリを検証するには、多様な入力ケースが要ります。ところがテスト入力を手書きで作ろうとすると、2〜3 個でペンが止まります。「これ、さっき書いたケースと実質同じでは？」「重要なエッジケースを取りこぼしていないか？」という問いに、頭の中だけでは答えられないからです。

しかもアプリが扱う入力には複数の軸があります。たとえば文書生成なら「文書の種類 × 読み手 × 複雑さ」。軸が三つ重なれば組み合わせは数十通りになり、全部を人手で網羅するのは非現実的です。何より、どこを埋めてどこが空いているのかが見えないのが一番の問題です。

カバレッジマトリクスで「網羅」を可視化する

そこで、テストすべき入力を一つずつ書く前に、「変化させるべき軸」を先に列挙します。これがカバレッジマトリクスです。

MATRIX = {
    "doc_type":   ["提案書", "報告書", "議事録", "要件定義"],
    "audience":   ["経営層", "現場担当者", "外部クライアント"],
    "complexity": ["シンプル", "標準", "高度"],
}

軸の直積の各セルが「一つのテストケース」に対応します。マトリクスを眺めれば、どの組み合わせが埋まっていてどこが空白かが一目で分かる。テストの網羅性が、頭の中の感覚から、目に見える表に変わります。

重要度で優先順位を付ける（tier）

直積を全部埋める必要はありません。全組み合わせは膨大になりがちなので、重要なセルから埋めるよう優先度を添えます。

TIER = {
    1: [("提案書", "経営層", "高度")],        # 最重要・必ず検証
    2: [("報告書", "現場担当者", "標準")],    # 次点
    # ...
}

「最も壊れたら困る組み合わせ」を tier 1 として明示しておくと、時間が限られているときも要所だけ確実に押さえられます。

LLM にセルを渡してテストデータを生成させる

軸とセルが決まれば、あとは各セルの条件を LLM に渡し、具体的なテスト入力を生成させます。

マトリクスのセル（条件の組み合わせ）
        ↓  LLM に「この条件のリアルな入力例を作って」と渡す
具体的なテスト入力データ
        ↓
テストケースとして保存・実行

CLI に落とすなら、優先度や対象を絞れるようにしておくと運用が回ります。

sim generate --tier 1                # 最重要セルだけ生成
sim generate --only-missing          # まだ埋まっていないセルだけ補完
sim generate --dry-run --max 2       # 中身を確認してから本生成

「LLM でテストデータを作り、LLM で実行し、LLM で評価する」パイプラインの、最初のデータ生成ステップにあたります。手書きでは数個が限界だったところを、網羅的に量産できます。

合成データの落とし穴

ただし LLM が生成したテストデータには偏りが出ます。軸を均等に指定しても、LLM は「よくあるパターン」に寄りがちで、訓練データに少ない事例——業界特有の用語、地域性のある言い回し、レアだが重要なケース——は生成されにくい。これは合成データ全般に共通する弱点です。

対策は二つ。重要だが LLM が見落としやすいセルを tier 1 として明示すること。そして生成物を人がレビューし、必要なら手書きで追加することです。LLM 生成は量を稼ぐ手段であって、質の最終担保は人が握ります。

拡張しやすさを設計に織り込む

新しい対象（エンドポイントや機能）を検証範囲に加えるときに、フレームワーク全体をいじらずに済むようにしておきます。具体的には、対象の一覧をレジストリに集約し、追加は 1 エントリで済む形にします。

PIPELINES = [
    PipelineSpec(name="report_generator", ...),
    PipelineSpec(name="screening", ...),
    PipelineSpec(name="new_feature", ...),   # ← この 1 行を足すだけ
]

生成・実行・比較・品質ゲートといった各処理がこのレジストリを参照していれば、新対象を足してもそれらのコードは変更不要になります。レジストリ駆動にしておくことが、検証範囲を広げるコストを最小化します。

まとめ

  • テストケースの手書きは頭打ちになり、網羅性が「感覚」になってしまう
  • 入力の軸をカバレッジマトリクスで定義すると、何をテストすべきか・どこが空白かが可視化される
  • tier で重要なセルから優先的に埋める
  • 各セルを LLM に渡してテストデータを量産する
  • 合成データは偏るので、tier 指定と人手レビューで補正する
  • 対象をレジストリに集約しておけば、検証範囲の拡張を 1 エントリで済ませられる