古典テスト技法 × モデリング × LLM

QA学園・放課後再現部「これ、MBTってことですよね？」

※このエントリは、創作世界「QA学園」を舞台にした
テスト設計／LLM活用のストーリー仕立て解説です。
内容はかなり実務寄りですが、登場人物はフィクションです。

0. 今日のテーマ：「これMBTってことで合ってますか？」

放課後、QA学園の「再現部」の教室。

ユウタ：現場寄りQA、テスト設計担当見習い
テラ：モデル厨。因子水準表／状態遷移が大好物
アヤ：ユーザ体験と感情の波形（Ew）に敏感な人
言坂先生（ことさか）：品質アーキテクトな担任
QA-Lite：教室に置かれたLLM端末

今日も、フォームのテストをどうやって設計するか、という話をしていた。

1. 仕様だけ食べさせたAIのテストが「惜しい」

まずはユウタの一言から、議論が始まる。

ユウタ「先生、LLM（QA-Lite）に
『この画面のテストケース出して』って頼むと、
それっぽいんですけど 抜けとダブりが多い んですよね。」

テラも頷く。

テラ「仕様書の文章だけ渡してるから、
QA-Lite の中で暗黙にモデルを組み立ててるはずなんですけど、
どんなモデルで考えてるかが見えない のがネックですね。」

アヤの違和感は、もう少し感情寄りだ。

アヤ「なんか、“ここ刺してほしい”ってところじゃない観点を
ひたすら攻めてくる時あるんだよね。
ユーザー Ew 的には “そこじゃない” っていう。」

ここで、言坂先生が口を開く。

言坂先生「じゃあ今日は、
古典的なテスト技法を“モデル”としてAIに教えたらどう変わるか、
それと、
『それっていわゆる MBT（Model-Based Testing）なのか？』
を一緒に確かめてみようか。」

2. 各自の役割：古典技法を「モデル」として言語化する

言坂先生はホワイトボードに３つの箱を書く。

同値分割・境界値
状態遷移・決定表
シナリオ／探索的テスト

そして３人に、それぞれ担当を振った。

ユウタ：同値分割・境界値
テラ：状態遷移・決定表
アヤ：シナリオ／探索的テスト

2.1 ユウタ：同値分割・境界値 → 因子・水準表への落とし込み

題材はログイン画面。

メールアドレス
パスワード
「利用規約に同意」チェックボックス

ユウタは、同値分割・境界値を 因子・水準表（FL表） に落とし込んでいく。

因子A: メールアドレス形式
  - A1: 正形式
  - A2: 不正形式

因子B: パスワード長
  - B1: 最小未満
  - B2: 最小ちょうど
  - B3: 最大ちょうど
  - B4: その他

因子C: 規約チェック
  - C1: ON
  - C2: OFF

2.2 テラ：状態遷移・決定表 → フローのモデル

まず、ユウタの一言から。

ユウタ「同値分割って、
要は 入力空間を“意味のあるクラス”にまとめる操作 ですよね。
これをそのまま QA-Lite に渡して、
『この因子と水準を前提に、代表テストを出して』って頼んでみたい。」

テラは、対象として「パスワード再設定フロー」を選びます。

フローの代表的なステップはこんな感じです。

メールアドレス入力
メール送信
トークン検証
新パスワード設定
完了画面

各ステップには、例えば次のような分岐があります。

成功／失敗の遷移
トークン期限切れ
再送要求

テラはこれを 状態遷移図＋簡易決定表 に落とします。

テラ「状態遷移図は、
“どの順番で世界が動くか” のモデル で、
決定表は、
その場ごとの条件と結果の対応 です。
これを QA-Lite に渡して、
『各遷移を少なくとも1回は通るテストフローを列挙して』
ってお願いしてみます。」

2.3 アヤ：シナリオ／探索的テスト → ユーザーストーリー＋Ew

アヤは Kノートを開き、ユーザーストーリーを書き出します。

たとえば、こんなシナリオです。

「深夜2時、眠くてイライラしながらパスワード再設定をする」
「電波が不安定な電車内で、再設定リンクを踏む」

それぞれの場面で、

どこで不安・怒り・不信感（Ew）が上がりやすいか

をメモしていきます。

アヤ「探索的テストって、
ユーザーの感情の波形（Ew）に沿ってシナリオを歩く技法 だと思ってて。
QA-Lite には
『このシナリオで Ew を悪化させないためのテスト出して』
って頼みたい。」

3. 仕様だけ vs モデル込み：AIの出力はこう変わる

3.1 仕様だけ渡したとき（Before）

まずは対照実験として、仕様テキストだけを QA-Lite に渡し、

「テストケースを10件提案して」

と依頼した結果はこんな感じでした。

典型的な「空値」「形式不正」「長すぎる」テストは出る
しかし…
- クラス代表値のダブりが多い
- 実際には辿れない画面遷移を前提としたテストが混ざる
- ログイン → 再設定 → 再ログイン…といった“流れ”が薄い

ユウタ「すごく雑ではないけど、
“このままテスト設計に採用するには足りない” 感じですね。」

3.2 モデル込みで渡したとき（After）

次に、さっき 3 人が作ったモデルを前提として QA-Lite に渡します。

同値分割・境界値 → 因子・水準表
状態遷移・決定表 → フローモデル
シナリオ＋Ew → ユーザー状況の定義

このうえで、QA-Lite には例えば次のように指示します。

「この因子・水準を使って、重複しない同値クラス代表テストを列挙して」
「この状態遷移図の 各遷移をすべて通るテストフロー を出して」
「このシナリオの Ew が悪化しないか確認するテスト も追加して」

その結果──

同値分割／境界値

各水準から代表値が1つずつ取り出され、ダブりが減る
境界値も明示的にカバーされる

状態遷移

与えたフロー内で、現実的な 正常系＋異常系パス が揃う

シナリオ／探索的

「深夜で眠い」「電波不安定」といった状況に紐づいた
具体的なテストが出てくる

テラ「モデルを先に人間が握ってから AI に仕事を振ると、
ここまで出力の質が変わるんですね。」

4. これって結局 MBT なの？（先生パート）

ここでテラが、前から気になっていたことを聞きます。

テラ「これって、
欧米でやってるっていう MBT（Model-Based Testing） なんですか？」

言坂先生は、少し考えてから頷きます。

言坂先生「考え方としては ほぼMBT だね。
画面やフローを“モデル”として明示して、
そこからテストケースを導く。
ただし──」

と指を一本立てて続けます。

言坂先生「クラシックな MBT はね、

UML ステートマシンや形式的なモデルをきっちり書いて

専用ツールでテストを自動生成する
というスタイルが多い。
今日やったのはそこまでガチガチじゃなくて、
“軽量MBT＋LLM” くらいの位置づけ だね。」

ユウタがまとめます。

ユウタ「つまり、
古典技法でモデルを作って、
ジェネレータ部分を LLM にやらせてる
って理解でいいですか？」

言坂先生「その通り。
“技法そのもの” を AI にやらせるんじゃなくて、
人間が作ったモデルの上で、
列挙・組合せ・補完をさせる。
それが今日のやり方だね。」

アヤは Kノートに、一行だけメモします。

アヤ「“MBT的な考え方＋AI＝
ちゃんとモデル作った人が強い世界” って感じ。」

5. 実務に持ち帰るチェックポイント

最後に、先生がホワイトボードに 4 つのポイントを書きます。

LLM に丸投げしない
- 人間側で最初のモデル（FL表／状態遷移／シナリオ）を作る
モデルは古典テスト技法を “圧縮表現” として使う
- 同値分割・境界値・状態遷移・決定表・探索的テスト
LLM には、
- 「どのモデルを前提に、何を列挙してほしいか」を明示して伝える
出てきたテストは人間がレビューする
- 抜け・ダブり
- 現実に辿れるフローか
- ユーザー Ew 的に “そこじゃない感” がないか

言坂先生「MBTというラベルを使うかどうかは、正直どっちでもいい。
大事なのは、
“モデルを握った人間の頭の中” を、
AIにどうやって安全に共有するかなんだ。」

３人はそれぞれ、今日の Kノートに
自分なりの Fth（しきい値）を書き込んで、教室を後にしました。

おわりに

この放課後再現部エピソードでやっていたことを一言でまとめると、こんな感じです。

「古典テスト技法で作ったモデルを、
LLM に食べさせるライトウェイト MBT」

仕様だけ食べさせたときの “惜しい AI テスト” から一歩進んで、

人間側のモデリング力 × LLM の列挙力

を組み合わせるスタイルが、今後もう少し広がっていくのではないか、
という仮説も込めています。

あなたの現場では、
MBT 的なやり方と LLM をどう組み合わせていますか？