テスト設計AIは、どれも同じではない
――SHIFTのテスト設計AIエージェント「ネムラナイ」が他と違う「一点」

いま、「テストをAIにやらせる」と謳うサービスは数えきれないほどあります。
ところが導入を考え始めると、すぐに壁にぶつかります。「結局どれも同じに見える。何が違うのかわからない」。

ここに落とし穴があります。
“テストAI”とひとくくりにされているものの中身は、実はまったくの別物だからです。

世の中の多くは、テストの“実行”を肩代わりしてくれるタイプです。
画面を自動で操作する。スクリプトを書く。崩れたら直す。たしかに便利で、現場の手間を大きく減らします。

でも、よく考えてみてください。
これらはすべて、「何をテストするか」がもう決まっていることが前提です。
人間の頭の中に答えがあって、その作業を代行してくれている、ということ。

つまり、冒頭のあの「ざわつき」――“何を見るべきか”そのものには、ほとんど踏み込んでいないのです。

ソフトウェアの品質を決めるのは、もう一つ手前の工程です。
「どんなテストをすれば、この品質を守れるのか」を考える、“設計” です。

どの機能を、どんな条件の組み合わせで、何を正解として確かめるのか。
ここを外せば、いくらテストを自動で大量に流しても、肝心の不具合はすり抜けます。
逆に言えば――この設計さえ間違えなければ、品質は守れる。

それほど大事な工程なのに、市場を見渡すと、実行支援型のサービスが多い印象です。

ここが、最初の、そして最大の分かれ道です。

「ネムラナイ」は、その設計までやります。

さらに特徴的なのが、人との対話を極力減らしている点です。

多くのツールは「AIが案を出す → 人が逐一確認して直す」という二人三脚の形をとります。
それも一つの正解です。でも、それでは結局、人の時間と判断にぶら下がり続けます。
ベテランが一人抜けたら品質が落ちる――あの不安から、いつまでも抜け出せません。

私たちは、あえてそこに踏み込みました。
人を「確認作業」から解放したい。人にしかできない判断にこそ、時間を使ってほしい。
だからネムラナイは、あなたが細かく指示を出し続けなくても、筋の通ったテスト設計が自力で立ち上がる――そういう設計思想でつくられています。

理由は、AIが賢いから――ではありません。

「SQF」という体系化されたSHIFTのテストノウハウを、プロンプトという形に変えたからです。

ここは、はっきり言わせてください。
SHIFTは、テストで大きくなった会社です。数えきれないほどのテストを、優秀なQAたちの手でやり抜いてきました。
その一人ひとりを支え、育ててきたのは、誰かの勘ではなく、整理され受け継がれてきた“型”でした。

その“型”の中身を、もう少し具体的にお話しします。
ネムラナイが受け継いでいるのは、優秀なテスト設計者の“頭の中の手順”まるごとです。

・テストの目的を、どう定めるか ―― 「なんとなく全部確認」を許さず、狙いを先に絞る
・仕様の曖昧さを、どう潰すか ―― 書かれていない条件、矛盾、抜けを先にあぶり出す
・影響範囲を、どう見極めるか ―― どこまでが対象で、どこからが対象外か（In/Out）を切り分ける
・観点を、どう選ぶか ―― 900を超える標準観点の辞書から引き、要らないものは理由を添えて削る

条件の組み合わせと、期待値を、どう決めるか ―― 因子を洗い出し、確かめるべき正解を一つずつ定める

「画面ならここを見る」「入力ならこの境界を疑う」という観点の引き出しは、その一つひとつが大切な資産です。
そして、それらを“どの順で、どう判断して組み立てるか”という思考の道筋もまた、同じだけ価値のある資産です。
ネムラナイは、この両方を丸ごと、AIへの“指示書” に落とし込んでいます。

AIの性能に賭けているのではありません。
人が何十年とかけて培った「考え方」を、AIが迷わず辿れる形に翻訳している。それがネムラナイの正体です。

ご存じの通り、AIは曖昧な指示を渡すと、出来栄えがモデル任せになり、品質が日によって揺れます。
逆に、明確で矛盾のない指示があってはじめて、誰がいつ使っても、同じ高さの設計が返ってきます。（もちろん、AIをどう呼び出し／何を見せ／何を実行させ／出力をどう扱うかをプログラムとして設計する ハーネスエンジニアリングのようなことも必須ですが。）
ネムラナイの強さは、最新のAIを積んでいることよりも、この“指示書”の質にあるのです。

言葉だけでは伝わりにくいので、機能テストを想定して、インプットとアウトプット、そしてその間にある“指示書”を一部お見せします。

① インプット ―― テスト方針書と仕様書・画面定義・状態遷移等
ネムラナイが読み込むのは、ソースコードではありません。
どういうテストがしたいかを述べたテスト方針書と、みなさんが普段つくっている仕様書そのものです。例えば、画面項目の定義表や表を渡します。

普段の仕事の成果物が、そのまま入口になる。新しい資料を書き起こす必要はありません。

② 間に挟まる“指示書” ―― SHIFTのノウハウ「SQF」
ここで効いてくるのが、体系化されたプロンプトです。
指示書は一枚ではありません。「目的を定める」「仕様の曖昧さを潰す」「影響範囲を見極める」「観点を選ぶ」「条件と期待値を決める」――工程ごとに用意され、バトンを渡すように連なっています。

たとえばそのうちの一つ、「テスト観点の選定」を担う指示書には、SHIFTが積み上げた標準観点の辞書（900観点超）が組み込まれていて、AIにこう指示します。

・タイプ（新規/変更/削除…）ごとに見るべき観点を切り替える
– 新規：表示/入力/遷移… を広く網羅
– 変更：条件・計算等とその周辺を重点的に
・「初期表示の値」「桁数制御」「ブラウザバック後の挙動」… 見落としがちな観点まで列挙
・該当しない観点は、理由を添えて除外し、判断ログを残す

冒頭の「ブラウザバック」も「初期表示」も、ここにきちんと載っています。
人が最後に見落とすあの一点が、抜け漏れのないチェックリストとして明文化されている。
だからAIは、迷わず、ブレずに、そして疲れることなく設計できるのです。

③ アウトプット ―― そのまま使えるテストケース
最終的に出てくるのは、観点・確認すること・期待値まで埋まったテストケースの一覧です。

仕様書を渡せば、観点が割り当てられ、確認項目と期待値が埋まったこの表が立ち上がる。
この一連を、人手の対話を挟まずに走らせているのがネムラナイです。

ここまで読んで、そう思った方もいるはずです。
まっとうな疑問です。むしろ、テストを知っている人ほどそう感じます。

その答えの一つはこうです。
“人の確認を減らせる”のは、確認すべきことが指示書に書き尽くされているから です。
行き当たりばったりでAIに丸投げしているのではありません。何を見るべきかという基準を、人があらかじめ、徹底的に外に出してある。だから安心して任せられます。

冒頭で書いた通り、テスト設計AIは、外から見るとどれも似て見えます。
機能の一覧も、デモの鮮やかさも、並べてみれば大きくは変わりません。
だからこそ、目を向けるべきは“見えている部分”ではありません。

そのAIの裏側に、どれだけ確かな知見が積み上がっているか。

何を見るべきかを、どんな順序で、どう判断して組み立てるのか。
その「考え方」が、どれだけ深く型として書き込まれているか――ここでこそ、差は決定的に開きます。

ネムラナイの“指示書”には、SHIFTがテストサービスで磨き続けてきた型が、まるごと詰まっています。
これは一朝一夕には真似できない、私たちにしか書けないものです。

あの「リリース前夜のざわつき」を、もう一人で抱えなくていい。
導入を迷っているなら、機能の数ではなく、ぜひAIの裏側を比べてみてください。
違いは、きっと、そこに出ます。

▶「ネムラナイ」 のサービス詳細・お問い合わせはこちら
https://contents.shiftinc.jp/nemuranai/