AI TEST SUITE

海隆言霊 / AIテスト自動化プラットフォーム

画面の操作を一度記録すれば、あとは言葉でテストを作れます。

OUTPUT #1
言葉で書かれたテスト手順

クリック・入力・選択を一度記録すると、手順と期待結果を言葉で書き起こします。コードを書かないので、業務の担当者も内容を読んでレビューできます。

OUTPUT #2
実行の記録・証跡・報告書

再生できる実行の記録をHTMLで、画面と注記を並べた証跡をExcelで、仕様書と報告書をあわせて出力します。受入や納品に添える形のまま使えます。

領域

開発手法(開発の全工程に、AIを組み込む)

対象

入力フォームを主体とするシステムで回帰テストを繰り返しており、成果物の整理にも工数を取られている開発チーム

キーワード
操作の記録から生成言葉で書くテスト画面を見て実行成果物の自動生成
01 ISSUE

テスト工程は、いまも人手と時間を食い続けている

自動化そのものは以前から試みられてきました。それでも工数が減らないのは、次の四つが残るからです。

ISSUE 01
作るのに専門知識が要る

画面の構造とコードを理解していないとスクリプトを書けません。書ける人が限られるので着手が遅く、その人がいなくなると続きません。

ISSUE 02
画面の作りに密着している

記録して作ったスクリプトは、画面の中の位置や名前に強く依存します。並びが動いただけで外れ、直す手間が毎回発生します。

ISSUE 03
データを1件ずつ手で作る

入力の条件に合うデータを人が用意します。件数が必要な試験ほど手間が増え、工数の大半をここに取られることもあります。

ISSUE 04
成果物の整理が手作業

仕様書・証跡・報告書を手で整えます。品質の証拠を揃えるという説明の責任まで、担当者の作業として積み上がります。

02 PROCESS

記録してから成果物が出るまでの順序

人が入るのは三か所 ── 最初の記録、生成された手順の確認、判定が合わなかったときの原因の切り分けです。あいだの工程はこの基盤が受け持ちます。

STEP 01 録る クリック・入力・選択を一度記録する
STEP 02 手順を作る 言葉の手順と期待結果に書き起こす
STEP 03 手順の確認 手順と期待結果を読み、足りない分を補う
STEP 04 実行する 画面を見て操作し、確かめる
STEP 05 判定 期待結果と登録内容を照合
STEP 06 成果物 証跡・仕様書・報告書を出力
期待結果と合わない箇所 ── 不具合か手順の誤りかを確かめ、直してから流し直す
AI が担う 人が判断 外へ渡すもの 機械が止める関門

データが要る試験では、入力欄の名前と制約から規則に合うデータをまとめて作ります。範囲は画面の上で調整できます。

ログインや検索のような頻出の操作は部品として登録できます。部品を直せば、呼んでいるケースすべてに反映されます。

03 STRENGTH

読めて、壊れにくく、成果物まで出てくるテスト

テストの中身がコードではなく言葉になると、作る人・直す頻度・残る成果物の三つが同時に変わります。

POINT 01
一度の記録が、読めるテストケースになる

業務画面でいつもどおり操作すると、押した順が手順の文に、確かめた点が期待結果になります。期待結果は、操作の前後で画面がどう変わったかから推定するので、記録のときに書き足す必要はありません。足りないところは後から手で補えます。

できあがったものはコードではなく言葉なので、業務の担当者が読んで内容を確かめられます。テストの網羅性を確かめる作業が、技術者だけの仕事でなくなります。

画面の操作を一度記録するだけで、読める言葉の手順と期待結果に変換されることを示す図
POINT 02
画面が少し変わっても、実行が止まらない

従来の方式は、画面の中の位置や名前を覚えて操作します。そのため並びが動いただけで外れ、直せる人も限られていました。

この基盤は画面を見て、意味で要素を捉えます。言葉で書かれた手順がそのまま指示になるので、並びや名前が動いても同じ手順のまま動きます。作り替えが大きいときは変わった部分を記録し直しますが、日々の小さな変更にスクリプトの修正で追随する必要はありません。

要素を名指しする方式は画面の改版で止まり、意味で捉える方式は同じ手順のまま続くことを示す図
POINT 03
納品物は、実行の副産物として出てくる

再生できる実行の記録をHTMLで、画面と注記を並べた証跡をExcelで、仕様書と報告書をあわせて出力します。手順が操作に、期待結果が判定にそのまま対応しているので、実行した内容と書類の内容が離れません。

出力したものはオブジェクトストレージ(S3)へ自動で保存されるので、あとから取り出して経過をたどれます。手で作り直す工程を挟まないので、成果物は実行のたびに最新になります。受入や納品に添える資料を、テストが終わってから作り始める必要がなくなります。

テストを走らせた結果から証跡と仕様書と報告書が副産物として出てくることを示す図

テストの前後にある作業も受け持つ

実行そのものより、その前後の準備と後始末に時間が取られています。そこも同じ基盤の中で片付けます。

入力データを作る 入力欄の名前と制約から、規則に合うデータをまとめて作る。範囲は画面の上で調整できる
業務の制約に合うデータを作る 当社の別製品「コードRAG」と連携し、業務とデータベースの制約に合うデータを作る。中身が空のデータベースからでも用意できる
頻出の操作を部品にする ログインや検索を部品として登録し、全ケースから呼ぶ。部品を直せば全ケースに反映される
環境を切り替えて実行する 接続先を環境変数で切り替え、試験・受入・本番の各環境で同じケースを走らせる
画面の差分を見る 改修の前後で実行した画面を比べ、違いを示す。基盤の入れ替えや改修のときに使う
登録内容を確かめる 画面の表示だけでなく、データベースへ正しく書き込まれたかまで照合する
対応範囲と進め方
いまの対象と、これからの予定

現在の対象はWindows環境で動くWebアプリケーションです。モバイル(Android/iOS)への対応と、CI/CD(継続的インテグレーション・継続的デリバリー)との連携が、拡張の予定として挙がっています。

進め方は、試験導入 → 対象にする場面の選定 → 横展開の順です。入力フォームを主体とするシステムの回帰テストから始めると、効き方を確かめやすくなります。

できないこと
ここは自動化の外に残ります

削減できる工数の幅は、現時点では公開できる実測値としてお示ししていません。導入後に計測して報告する形をとっています。

効果が大きいのは、入力フォームを主体とする画面の回帰テストです。試しながら方針を決めていく探索的なテストや、性能・耐久のような非機能の試験は、この基盤が置き換えるものではありません。

画面を大きく作り替えたときは、該当する手順を直すか、変わった部分を記録し直す必要があります。配置や見た目の調整であれば、同じケースのまま実行が続きます。

現在は試験導入の形でご提供しています。個別の要件に合わせた調整は、内容を伺ったうえで対応します。

04 RESULT

手作業だった工程の、置き換わり方

積み上がっていた四つの手作業が、それぞれどの機能に置き換わるのかを並べます。

これまでの手作業 → 置き換わり方

これまでの手作業 置き換わり方
仕様書を人が組み立てる記録した操作から手順と期待結果を書き起こし、そのまま仕様書として出力する
データを1件ずつ用意する入力欄の名前と制約を読み取り、規則に合うデータをまとめて作る
実行して目視で確かめる画面を見て操作し、表示と登録内容の両方を照合する
証跡を手で整える実行の記録をHTMLで、画面と注記の証跡をExcelで、そのまま添えられる形で出力する
画面が変わるたびに直す要素を名指ししないので、小さな変更では手順を書き換えずに済む
環境ごとにケースを作り直す接続先を環境変数で切り替え、試験・受入・本番で同じケースを走らせる

当社が開発した基盤の機能仕様(紹介資料、2026年9月時点)。削減できる工数の幅は導入後に計測してお示しするため、ここには載せていません。

NEXT

ご相談は、担当者までご連絡ください。

対象を一つ指定いただければ、成果物とその検証レポートを実物としてご提示します。

この方式が有効かどうかは、件数の説明ではなく、ご自身のシステムから出てきた成果を見ていただくのが最短です。

連絡先を見る →

対象を一つお知らせいただくところから始まります。