ソリューション技術通信 ベリサーブナビゲーションでは、さまざまな分野で検証に携わるベリサーブが「今とこれから」を皆様にお届けします。

VERISERVENAVIGATION

2019
JanuaryVol.16

ソフトウェアと品質を考える
ベリサーブ アカデミック イニシアティブ 2018 特集

UI自動テストツールとAI〜AIを使った自動テストの「今」と「未来」〜
伊藤 望 氏自律運営要員・チーム・組織を創るためのアプローチ〜テストプロセス改善の取り組みを事例に
安達 賢二 氏

UI自動テストツールとAI〜AIを使った自動テストの「今」と「未来」〜
はじめに

今世の中のさまざまな産業が、AI（人工知能）
によって大きく変わりつつあり、その波は自動テストツールの世界にも押し寄せて来ています。本稿では、筆者が「ベリサーブアカデミック伊藤 望 氏いとう のぞみ

日本Seleniumユーザー
コミュニティ代表

イニシアティブ 2018」で行った講演内容を基に、この新しいAIの技術が自動テストツールの分野にどのような影響を与えるかについて紹介します。

株式会社TRIDENT
代表取締役社長

1. AI自動テストサービス「Magic Pod」

大手パッケージベンダーにて社内

最初に、AI技術をUI自動テストに適用した具体的な事例として、筆者も開発に関わっている

自動テストツールを開発した後、2012年独立し、テスト自動化を支援する株式会社TRIDENTを設立。現在は、機械学習を活用

した自動テストサービス「Magic

Pod」の開発・運営に取り組む。

また、日本 S e l e n i u m ユーザー
コミュニティの運営や、講演・執筆活動を通じ、テスト自動化の普及にも努めている。

著 作に「システムテスト自動 化

標 準ガイド」「Selenium実践入門」。

「Magic Pod」を取り上げ、その仕組みについて解説します。
Magic PodとはMagic Pod（https://magic-pod.com）はディープラーニングなどの各種AI技術を利用した商用自動テストサービスです。現在はiOS/Androidのモバイルネイティブアプリ
テストに対応しています。Magic Podの特徴は、AIエンジンを用いて、アプリ画面の画像
から画面項目を「名前入力欄」「登録ボタン」などの分かりやすい日本語名称で検出できることです。
具体的には、Magic Podの画面上にアプリ画像をアップロードすると、そこからAIエンジン
によって画面項目が検出されます（図1の①）。後は、ユーザーが検出された画面項目をテスト
ケース作成エリアにドラッグ&ドロップしていくことで、テスト手順を簡単に作成することができます（図1の②）。なお、https://www.youtube.com/watch?v=f6SO9pZANas
ではこの一連の流れを動画で分かりやすく解説しています。

2

VERISERVE NAVIGATION

画面項目を選べるようになり、「ボタン」なら「タップ」、「入力欄」
なら「入力」のように、選んだ項目に応じたコマンドが生成さ①AIエンジンがアプリ画 面から項目を自動検出れます（図2の③）。実はこの時、コマンドの種類と、画面項目の位置に対応する内部システム情報を基に、テストスクリプト
が内部では自動生成されています（図2の④）。このテストスク
リプトは、モバイル向け自動テストツールAppium（https://appium.io）のスクリプトであり、テスト実行時にはAppium
でこのスクリプトを実行します（図2の⑤）。

Magic Podの画像解析AIエンジンの仕組み
続いて、
アプリ画像から画面項目を検出するAIエンジンの仕組みについて説明します。エンジンの核となる技術は大きく② 項 目のドラッグ&ドロップでテスト
作成

2つあります。1つは、画像の見た目から「ボタン」「入力欄」など画面項目の種類を判別する技術です。
この部分には「畳み

図 1：Magic Pod によるテストの作成

込みニューラルネットワーク」（Convolutional Neural
Network、CNN）と呼ばれるディープラーニングの技術を利用しており、
読み込んだ画像の見た目と学習済みデータ（一例
として、数多くのボタンの画像を「ボタン」として学習させた

Magic Podの仕組み

もの）
を基に、
「ボタン」
「入力欄」などの画面項目の種類、さら

テストを作成する具体的な仕組みは実際にはこうです。
Magic Podでアプリ画像をアップロードする際には「Magicには「検索アイコン」「設定アイコン」などのアイコンの種類を判別することができます。
（図3）

Pod Desktop」という専用のアプリを利用しますが、これを使うと実際には「アプリ画面の画像」と「画面の内部システム
情報」の2つがMagic Podのサイト上にアップロードされ（図2の①）、
さらAIエンジンがこの画像を解析して画面項目を

検索
アイコン

検出します（図2の②）。解析が終わればユーザーは画像から

ボタン

AIの活用

畳み込みニューラルネットワーク（CNN）①アプリ画像とを内部システム情報を
取得

↑
学習データ
（入力情報と出力結果の関係に対する重みづけを保有）

図 3：CNN による画面項目の種類判別

②AIで
画像を解析

もう1つは、図4のように、テキストと画面項目の位置関係を基に「お名前入力欄」「ログインボタン」のようなラベル付けを行う技術です（Magic Podの内部ではこれを「Captioning」③選んでテスト作成と呼んでいます）。この部分はディープラーニングではない
別の機械学習技術を利用しています。
④内部システム情報から
テストスクリプトを生成⑤自動テストツールAppiumで実行

図 2：Magic Pod の仕組み

VERISERVE NAVIGATION

お名前入力欄

ログインボタン
図 4：Captioning3この2つを組み合わせた解析エンジンの全体像は以下のようになります。

● 色や模様を基準に、画面の領域を分割（図5）● 分割した各領域の画面項目は何かを、
CNNを使って判別● OCR（光学文字認識）技術を使って、画像からテキストを検出● Captioningを使って、画面項目とテキストを結合（例）名前＋入力欄、登録＋ボタン

AI技術の進歩による機能の向上
AIの技術は日々進歩しています。続いて、この進歩を取り入れてMagic
PodのAIエンジンをさらに改善しようとしている試みを紹介します。
まず、現在のMagic PodのAIエンジンの問題点として、画像解析の最初に画面の領域分割を実施する点があります。この領域の分割は画面項目の種類などを考慮

図 5：画面領域の分割

せず色や模様を基準に行われるため、例えばグラデーションのかかった画面
では、図6のようにうまく分割を行うことができません。また、
この領域分割の処理が低速であることも問題です。
そこで現在Magic Podでは、単純なCNNに代わり、ここ数年でメジャーになってきたSingle Shot MultiBox Detector（ SSD）と呼ばれる新しいディープラーニングの手法を用いて、この問題の改善に取り組んでいます。
単純なCNNでは、画像に「何が」写っているかしか判別できませんが、SSDを使えば、図7のように、画像の「どの位置に」「何が」写っているかを検出できます。SSDをうまく活用すれば、図8のように、複雑な画面からもうまく画面項目の位置、さらに種類も同時に検出できます。
加えて、低速な領域分割の処理を廃止することもできます。SSDによる検出処理も通常のPCでは時間がかかりますが、ディープラーニングの処理によく＊1使われるGPU（Graphics Processing Unit）
を搭載したマシンであれば、この処理は画像1枚あたり0.2〜0.3秒程度で行えます。
図 6：グラデーションのかかった画面の領域分割結果

入力欄
入力欄

ボタン

Single Shot MultiBox Detector（SSD）

図 7：SSD による画面項目の位置・種類の検出

4

図 8：SSD による画面項目の検出結果

VERISERVE NAVIGATION将来的には、テスト実行時にSSDによる画像認識をリアル
タイムで行うことで、
Appiumaでは扱いが難しいUnity＊2など

AI自動テストの未来のフレームワークを使ったアプリケーションや、組み込み製品などの自動化もMagic Podで対応できるようになるでしょう。

これまで見てきたようなAI自動テストツールがどんどん進歩
すれば、いずれAIがテストを全て自動化し、品質保証担当者の仕事は無くなってしまうのでしょうか?筆者は、当面はそうはならないと考えています。例えば、以下に述べるようなスキル

その他のAI自動テストツール・サービス
Magic Pod以外にも、海外ではAIを使ったさまざまな自動テストツール・サービスが登場しています。図9では、どの部分にAI技術を使っているかで、代表的なツール・サービスを分類しました。筆 者 の 所 感としては、「スクリプト自動 生 成 」や
「バグ自動修正」については、単純なものはAIで自動化できると思いますが人間のような複雑なタスクを行うのはかなりハードルが高いと感じています。一方、「スクリプト自動修復」「画面要素検出」「モンキーテスト」については、AI技術による大きな改善が十分に可能だと思います。ここではそれぞれについて詳しくは取り上げないので、詳細は各ツール・サービスのをA Iで実 現することは、結 局のところA Iでソフトウェアを設計・開発するのと同じくらい難しく、現在のAIのレベルから
考えるとまだまだ困難であると感じます。
● ユーザーや業務を理解し、良いテストを設計するスキル● 仕様バグや業務ロジックの不備を見つけるスキル

AIを使った自動テストツールは今後もどんどん進化していき
ますが、それらが人間を全て置き換えるのではなく、人間がテストを設計し、さまざまなAI自動テストツールでそれらを効率よく実行する、という形が、最も現実的な未来だと筆者は考えています。

Webサイトをご確認ください。

おわりに
テスト実行

テスト設計

● mabl, Testim● Appvance［スクリプト自動生成］［スクリプト自動修復］● test.ai［画面要素検出］

探索的テスト

静的解析● Firebase Test Lab● GenProg、
SapFix［モンキーテスト］［バグ自動修正］

人間の仕事がAIに全て奪われることはないとはいえ、単純な作業は今後確実にAIで代替されていきます。日々の業務においても、AIに代替されにくいテスト設計などのスキルを磨いていくことが、
これからの時代に重要になるのではないかと思います。

図 9：自動テストツール・サービスの分類

参考サイト● "Magic Pod". https://magic-pod.com/● "Magic Podコンセプト動画". https://www.youtube.com/watch?v=f6SO9pZANas● "Firebase Test Lab" . https://firebase.google.com/docs/test-lab/● "Appvance.ai" . https://www.appvance.ai/● "mabl" . https://www.mabl.com/● "Testim" . https://www.testim.io/● "test.ai" . https://test.ai/● "GenProg" . https://squareslab.github.io/genprog-code/● "SapFix" . https://code.fb.com/developer-tools/finding-and-fixing-software-bugs-automatically-with-sapfix-and-sapienz/*1： GPU（Graphics Processing Unit）：3Dグラフィックスなどの画像処理に特化した演算装置。
定形かつ大量の計算処理を並列的に行うことが可能。
*2： Unity：Unity Technologies社（アメリカ）が開発した世界シェア1位のゲーム開発用ツール

本記事の内容に関するご質問、お問合せは、ベリサーブマーケティング部 Email：verinavi@veriserve.co.jp までお寄せください。
VERISERVE NAVIGATION

5

自律運営要員・チーム・組織を創るためのアプローチ〜テストプロセス改善の取り組みを事例にはじめに

安達 賢二 氏あだち けんじ
株式会社HBA

共創推進グループ

エグゼクティブエキスパート

このたびご縁があり、アカデミックイニシアティブ２０１８で講演させていただきました。
本稿ではその講演内容を抜粋してご紹介させていただきます。
講演の中でご紹介した事例は、以下の問題意識から当初ソフトウェアテストシンポジウム
2018東京で発表したものです。

HBA入社以来、システム保守・運用・開発業務、プロジェクトマネー

ジャなどを経 験 後 、部 門 → 全 社

品質保証担当、全社品質・セキュ

リティ・環 境 管 理 統 括 責 任 者 、
全社生産革新活動技術コーディ

ネータなどを担当。

実務の現場が組織的なプロセスモデルの導入やAgile、DevOps、テスト自動化など、毎年変化する施策に混乱し、疲弊しているケースが多いのではないか。
一つの例として、プロセスモデル活用が普及しているように見えて、形式対応や、やらせる／やらされる図になっているなど、使いこなせていないケースが多いのではないか。

2 0 1 2 年 社 内イントレプレナー
第 一 号 事 業 者として品 質 向 上
支援事業を立ち上げ。

現在、自律運営チーム構築･変革

メソッドSaPIDをベースに、関係者と一緒に価値あるコトを創る共このような問題意識の解消を目指し、「テストプロセスモデル適用」に対するアプローチを試みました。本稿では、第１章で「テストプロセス改善の取り組み事例」を、第２章で「事例で伝えたかったこと」をお伝えしたいと思います。

創ファシリテータとして活動中。

6

VERISERVE NAVIGATION

1. テストプロセス改善の取り組み事例

懸念事項（2）：多くの N G が あり、どこから手を付 けたら
よいのかわからない。
TPI NEXTが推奨しているクラスタA＊1

1-1 きっかけ

から順に行うのがよいのか？

この事例は、自らのチームにTPI NEXTを活用して現場環境の改善から着手したらよいのか？

中 山 さん が 普 段 から気 にして いるテスト改善を進めようとしたテストチームのリーダ中山さん（仮名）が自らアセスメントを実施したところから始まりました。

この状態は、
プロセスモデルへの専門性を備えたアセッサーなどの有識者が実施しないセルフアセスメントにおいてよく

1-2 TPI NEXTとは？

起き得ることです。地域のテストコミュニティの会合で一緒に

TPI NEXTとは、オランダのSogeti社が開発したテストなった中山さんからこの状況をうかがい、一緒に状況打開に

プロセス改善モデルです。
SR：利害関係者との関係、
TM：テスト

向けて取り組んでみよう、ということになりました。

管理、TP：テスト業務の専門性の3グループに16のキーエリア、
146のプラクティス（実践事項）があり、それぞれに初期・コント

1-4 プロセスモデルを活用した改善におけるリスクと打開策

ロール・効率化・最適化の4レベルが定義されています。
当モデルをベースにアセスメント
（評価）
を実施。
プロセスの成熟度や能力

プロセスモデルを使う／使わないにかかわらず、現在のを判定し、改善目標やビジネスゴール達成に寄与するキー

状況を的確に把握することなくして有効な改善はできません。

エリアを中心に改善を進めることができます。
（図１．
１）

今回は日本語書籍を一読した状態の中山さんが１人でアセス
メントを実施しています。よって、以下のリスクが発生しやすく

1-3 セルフアセスメントの実施とその結果なります。

現状のテスト運営に問題意識を持っていた中山さんは、何かヒントになることはないかとTPI NEXTの日本語書籍を手に取り、Webサイトに掲載されているアセスメントシートにてリスク（1）：アセスメント結果が実態を反映していない可能性がある。

セルフアセスメントを実施してみたところ、
どうしてよいのか迷う

リスク（2）：チームメンバーにとって改善が他人事になり状態となりました。

やすい。

懸念事項（1）：アセスメント結果が正しいのか確信が持て

この２つのリスクを軽減、解消するために、メンバーの声をない。
わかるようなわからない質問が多く、実態を直接収集して現状を把握すること、できるだけチームに余計反映した結果になっているのかが不安。

な負荷をかけないようにするために、毎週チームで実施している「ふりかえり」の結果を活用することを提案しました。

グループ

キーエリア

レベルに応じた
プラクティス

図１．
１ TPI NEXT 日本語書籍とチェック項目の一部*1： 小さな改善ステップを段階的に踏むために、1つの改善ステップを構成する複数のキーエリアのチェックポイントをグループ化したもの。各クラスタはアルファベット1文字で識別され、Aから順に改善の優先順位を意図している。

VERISERVE NAVIGATION7

1-5 メンバーの問題意識の収集と分類

1-6 状況を掘り下げるヒアリングの実施

まずは直近数週間分のふりかえり結果のテキスト情報を次に、現状をより詳細に把握するための追加ヒアリングを列挙し、分類して、プロセスモデルのどの領域に問題意識が行います。メンバーが発した現状の問題点や困り事の表現あるのかを確認してみました。
（図１．
２、図１．
３）

（「ふりかえり」における表現）
は、感情に引っ張られて歪曲してその結果、チームメンバーは「テストウェア管理」と「テストいたり、具体的なイメージが湧かない内容だったり、特定のケース設計」に多くの問題意識を持っていることがわかりま

メンバーにしかわからない表現が混在しています。作業のした。もし、これらが解決できればメンバーの困り事の多くが状態や発生している事象が、できるだけリアルに関係者全員で把握できるレベルになるまで質問を繰り返して認識を共有解消され、仕事がしやすくなるはずです。

します。
（図１．
４）

 	 
テスト設計の見積もりがされない

ユニットテストの狙いが作り手によってことなるテスト計画の作成が遅い

システムテストで単機能テストはやりたくない

テスト実施工程が見積れない

テスト計画の作成が遅い

各テストの狙いがあいまい

テスト設計の見積もりがされない

定量的に物事を判断していない

テスト実施工程が見積れない「ふりかえり」の結果

管理側面

各テストの狙いがあいまい

総合テストが計画的ではない
テスト設計とテストケースのトレーサビリティを良くしたい

総合テストが計画的ではない

テスト環境、
テスト対象、
テストケース、
テスト結果の管理

定量的に物事を判断していない

性能テストの管理、狙いが宙ぶらりん

テスト結果の管理があいまい

テスト結果の管理があいまい

テスト仕様書の役割があいまいテストで考える品質特性を整理したけど使っていない

テスト設計とテストケースのトレーサビリティを良くしたい

GUI単体のテストは分割したい

関連する他チームメンバーと目的、認識があっていない

関係者連携

テスト環境、
テスト対象、
テストケース、
テスト結果の管理
性能テストの管理、狙いが宙ぶらりん

似ている内容を集めてグルーピング

当初困りごと収集
原データ 分類データ

テストの自動化が進まない

インフラ側面

テストケースをテスト管理ツールを使って脱Excelしたい

テストで考える品質特性を整理したけど使っていない
テ トで考
テストで
ト 考える品
考える品 質特性を考える品質特性
質特性を整整 理したけど使
整理した
けど使っ
ど使 ていないて な

図１.2「ふりかえり」の内容が、アセスメントのキーカテゴリーのどこに当たるのか割り付ける…

収集したふりかえり結果（左側）と分類（右側） ※部分

ふりかえりコメントの件数を表す

利害関係者のコミットメント
制御 効率 最適

テスト戦略
テストプロセス管理
制御

効率

制御

効率

最適

割付が多い
↓
問題意識の
集中箇所

最適

関与の度合い
制御

効率

最適

見積と計画
制御

効率

最適

担当者のプロ意識
制御

効率

最適

手法の実装
制御

効率

最適

テスト組織
制御

効率

最適
テストウェア管理

テストケース設計

制御

制御

効率

最適

効率

最適

欠陥予防
制御

効率

最適

コミュニケーション
制御

効率

最適
メトリクス
制御

報告
制御

効率

効率

最適

テスト環境
制御

効率

最適

テストツール
制御

効率

最適

最適

図１.3

1-7 ヒアリング結果の構造分析

チームメンバーの問題意識の分布分析し、関係性のある要素を矢印でつないでいくことを指します。さらに、構造図の要素の意味をまとめ、それぞれに名前掘り下げヒアリングの結果を、「ふりかえり」の際と同様に分類・整理して、それらを構造的に分析します。
構 造 的に分 析するとは、それぞれの要 素の因 果 関 係を8付けします。
（図１．
５）
これらは、テストチームが実施している
１サイクル（テスト作業の開始～終了＋その結果まで）の問題
構 造の詳 細と概 要を表しています。ここまで来たところでVERISERVE NAVIGATION

テストの狙いが曖昧

掘り下げ１
質 問：狙いが 曖 昧とは、具体 的にはどのような状態なのですか？

掘り下げ2
質問：それによってどのような困り事が発 生しているのですか？

システムテストで 何 を、G U Iテストで
何 を 確 認した い の か 、認 識 が 合 って
いない。

（1）
それぞれのテストの境界に対して人により判断が異なるため、テストの重複や漏れが発生する場合がある。
（2）
テスト漏れについてはレビュー等で見つけて防ぐようにしているが、（3）その分余計な手間がかかっている。

構 造 分 析した 結 果 と
紐 づ け で きる ように
掘り下 げ た 内 容 一 つ
ひとつに番号を付けていく（4）また、レビューアであるリーダが多忙で未実施や見逃しも起きている

図１.4

中山さんは当初のセルフアセスメント結果に誤りがあることに掘り下げヒアリングの例

改善対象が決まれば、次は具体的な改善施策とその結果獲得する効果を明確にします。改善施策を検討する上で、自ら気付いて修正を行っています。

最後に活用するのはTPI NEXTプロセスモデルに定義された
1-8 改善対象の明確化

プラクティスです。テストプロセスモデルは、効果と効率の問題構造が明確になったところで、獲得したい結果（改善ティス）の集合体ですから、特定した改善対象に適用できる

効果）とその実現のためにどこに改善施策を打つのがよい

プラクティスを特定できればそれが「改善施策要件」になりか、つまり改善対象の検討と特定を行います。検討の結果得ます。今回のケースでは、主にキーエリア「テストケース

図 1 . 6 のように案１、案２の２つの 候 補が上がりましたが、設計」に記載されているプラクティスを改善施策要件の抽出

今回は「テスト漏れによる欠陥流出を防ぐ」ために「テストに利用しました。

両面を兼ね備えたテストを実現するためにすべきこと（プラク

設計の方法を見直す」案１を優先で対応することにしました。

C→ テスト準備の生産性が悪い（5）元から存在する機能に対するテストケースの 粒 度 がバ ラバ ラでスパゲティテスト仕様
状態（→20）残された情報では以前の作業者のユニット
テストの意図がわからない

凡例： 品質性悪要素

B（6）過去のテスト結果が残っているがテスト
環 境 情 報 が 残 っていないものが多い

調査／確認
など手間が
かかる

（20）ユニットテストの狙いと粒度が作り手によって異なる（3）人によりテストレベル・
タイプの境界に対する判断が異なる（18）人によりテスト手順（操作手順）の書き方がバラバラ（粒度や表現がそろわない）→ 過去テスト
結果情報の品質が悪い（15）テスト設計できる人がなかなか育たない（20→）テストをやってみて、想定と違うテストになっていることに気づく場合もある
経験則や過去テスト
ケースによるテスト（16）変更分のテスト設計が端折られることがある（23）テスト詳細設計結果
レベルで記載する人とテスト
実装レベルで記載する人がいる→ テスト設計と過程のばらつきが大きい

テスト結果に以降の作業に必要な情報が記載されていないものが多い

A（24）システムテスト仕様書にはGUI、制御、ストレージ、
通 信 などサブシステム 単 位に必要なテストをすべて記載
している（B-25）結果的にすべてをテスト実施することになるCB（27）シナリオテストなのにGUI単品、単機能テスト等が混じったまま実行することがある（ 2 6 ）シ ス テム テ スト にGUI単品レベルのテストが混じってしまう→ テスト実行工数が多くなる

テストの重 複が発 生してしまう場合がある→ テスト重複（ 2 6 → 他 ）必 要 な
テストケースが漏れてしまうことがある→ テスト漏れ（4）
テスト漏れをレビュー → レビューが大変＆
手戻りで防ぐようにしている（18/19→）レビュー
しにくい（26→）調 査 ／ 確 認など手間がかかるA→ 特定メンバーの負荷が高い（13）時間が無くなるとテスト設計できる人に作業が回される

1つの箱の中には、掘り下げ結果の内容1つを記入し、原因、結果の順に矢印でつないでいく→ 手戻り作業（20→）テストコードの修正箇所の特定が難しい

C（7）定期的に回帰テスト
実 施前に過去のNG
項目で作戦を立てるが役 立 つ 情 報 に なっていない

生産性悪要素レビューで見落とす（10-14）テスト設計できる人に作業が集中するレビューできない場合がある

探 索 的 テ ストやリリース後に
欠陥流出→ レビューできない＆見落とし
入力情報

準備

テスト設計・実装

レビュー

テスト実行

図１.5

VERISERVE NAVIGATION

最終結果

ヒアリング結果より構造分析した結果

9

C

凡例： 品質性悪要素

案２（5）元から存在する機能に対するテストケースの 粒 度 がバ ラバ ラでスパゲティテスト仕様
状態（→20）残された情報では（20→）テストコードのテスト準備の生産性が悪い
以前の作業者のユニッ
ト
修正箇所の特定が難しい
テストの意図がわからない（20→）テストをやってみて、想定と違う手戻り作業発生テストになっていることに気づく場合もある
経験則や過去テスト
ケースによるテスト

C（7）定期的に回帰テスト
過去テスト
実 施前に過去のNG
結果情報の品質が項目で作戦を立てるが悪い
役立つ情
報 に なっていないB（6）過去のテスト結果が残っているがテスト
環 境 情 報 が 残 っていないものが多い

調査／確認
など手間が
かかる

案1
（16）変更分のテスト設計が端折られることがある

改善対象（20）ユニットテストの狙いと粒度が作り手によって異なる

テスト結果に以降の作業に必要な情報が記載されていないものが多い

A（24）システムテスト仕様書にはGUI、制御、ストレージ、
通 信 などサブシステム 単 位に必要なテストをすべて記載
している（3）人によりテストレベル・
タイプの境界に対する判断が異なるテスト設計と過程のばらつきが（18）人によりテス
ト手順（操作大きい（B-25）結果的にすべてをテスト実施することになる（23）テスト詳細設計結果
レベルで記載する人とテスト
実装レベルで記載する人が
いる

C

B

テスト実行工数が（27）シナリオテストなのに大きくなる
GUI単品、
単機能テスト等が混じったまま実行することがある（ 2 6 ）シ ス テム テ スト にGUI単品レベルのテストが混じってしまう
テスト重複

手順）の書き方がバラバラ（粒度や表現がそろわない）（15）テスト設計できる人がなかなか育たない生産性悪要素

効果獲得対象テストの重 複が発 生してしまう場合がある（ 2 6 → 他 ）必 要 な
テスト漏れ
テストケースが漏れてしまうことがある

改善対象（4）
テスト漏れをレビューで防ぐようにしているレビューが大変＆手戻り（18/19→）レビュー
しにくい（26→）調 査 ／ 確 認など手間がかかるA（13）時間が無くなるとテスト （10-14）テスト設計できる人
特定メンバーの負荷が大きい設計できる人に作業が回されるに作業が集中する

入力情報

準備

テスト設計・実装

見逃し
レビューできない場合がある

効果獲得対象
レビュー

テスト実行

図１.6

改 善 施 策 要 件が抽 出できれば、それを参 考に具 体 的な

探 索 的 テ スト
欠陥流出やリリース後に欠陥流出レビューで見落とすレビューできない＆

最終結果

意味づけ後の構造分析結果言われたことでは変わらない」ということです。

改善施策を検討することができるようになります。こうして、中山さんは納得してプロセスモデルを活用し、現場の改善に効果的な施策を打つことができるようになりました。

人は、本心からそれが必要と思わない限り、自らを変えようとはしません。
組織的施策はたいていの場合、指示・命令を中心とする
トップダウンで進められます。結果を出すためのスピードを

2. 事例で伝えたかったこと
今回の事例はプロセスモデル適用でしたが、新たなものを導入・適用することは、それにより実務の効果や効率が現在より求めれば求めるほど、短絡的に指示・命令で人を動かすことが多くなると思いますが、指示・命令された側は反抗するか、
良くても表面的にやったことにするだけで、実態としては内面を変えていないため、時間が経つと元に戻ってしまいます。

良くなることを目指す「実務の改善」となります。それなのに、
これらの取り組みにより余計な作業が増えて非効率になった
り、やる気をなくしたり、疲 弊するような結 果になることは避けなければなりません。さて、これらの組織的な施策がどうして正反対の結果になることが多いのでしょうか？

1. 内発的動機づけを失わせる。
2. かえって成果が上がらなくなる。
3. 創造性をむしばむ。
4. 好ましい言動への意欲を失わせる。
5. ごまかしや近道、倫理に反する行為を助長する。

2-1 組織的施策がうまくいかない要因と当事例における解決策
組織的施策がうまくいかない場合、大事な原理・原則に反していることが多いと感じています。それは「人は、他人から
10

6. 依存性がある。
7. 短絡的思考を助長する。
図２．
１ アメとムチの致命的な７つの欠陥
書籍「モチベーション 3.0」ダニエル・ピンク より

VERISERVE NAVIGATION

指示・命令はアメとムチで表現されるように「外的動機付け」に分類され、現在ではさまざまな負の効果が指摘されてい
ます。
（図２．
１）
今回発表した事例では、指示・命令ではなく、自ら感じている問題点や困り事から改善すべきこと、改善策を自ら決め、行動する（私はその場づくりと後方支援だけを行う）
アプローチ
を採用することでこの原則に対応しています。

2-3 最終目標は自律運営
事例で示したアプローチが最終的に目指している目標は
自律運営の実現です。
自律とは、自ら考え、行動し、振り返りながら、周囲と協調しつつ目的をより良く達成して自ら成長することを意味します。
周囲と協調し、三方よし（売り手、買い手、世間よし／現場、
顧客、会社よし）を実現するために取り組むため、ワガママ
三昧、周囲に迷惑を撒き散らしてでも自分のやりたいように

2-2 プロセスモデル導入・適用がうまくいかない要因と当事例における解決策
プロセスモデル導入・適用がうまくいかないケースでは、「自ら手を染めたことは自分事になりやすい」に反している場合が多い、と感じています。
プロセスモデルによるアセスメントは、通常第二者、第三者などの有識者やリーダが実施します。そのため、他者が出した結果をベースに改善を自分たちで行うように仕向けられるように受け取ってしまう可能性が高くなります。
また、「感情は論理に勝る」というように、いくら適切な論理を並べても、感情には勝てません。
プロセスモデルによる改善では、論理的なものづくりや管理の視点から現状評価（アセスメント）を行い、その結果をベースに論理的な対策を立案します。
毎日さまざまな問題に苦しめられている実務の現場に、論理の集合体であるプロセスモデルで現状を把握して説明しても、心に響かないことが多くなってしまいます。問 題に苦しめられている度合いが大きいほど、負の感情が前に出てしまい、
心に余 裕が無くなり、論 理を受け止める余 裕が無くなってしまいます。
今回発表の事例では、メンバーそれぞれの負の感情につながる問題点や困り事を自ら記載し、その情報をベースに現状を把握して感情論の解決をチーム（自分事）
として取り組める

やる自分勝手とは異なります。また、自律とは何でも自分でできることを意味しません。自分の得意なところ、不得意なところ、至らないところをも把握して、意図的に他社・他者に依存（相互依存）しながら一緒に価値のある目的を達成する
ように行動します。
自律した方（やチーム、組織）は、たとえ困難に出くわしても自らの思考と行動、周囲への働きかけと協調で解決していきます。周囲への貢献により自信を深め、仕事がどんどん楽しくなる。人間関係も良好になっていき、さらに大きな価値を実現
していきます。
自律に向かう第一歩は、自ら考えてやってみる、その結果を振り返ってより良いやり方や結 果を引き寄せて「自分でもできる！」と実感する領域を拡げながら徐々に自信をつけてもらうことです。これは目先の行動や成果を強制する指示・
命令の繰り返しでは成し遂げられないことです。いくら急かしても思考は突然速くなることはありません。要員やチームが持つ現状の思考力を徐々に高めていくように、根気強く支援する必要があります。今回の事例はその第一歩となるものです。
経営やマネジメントの方たちには部下の皆さんの育成方法
として、リーダの方たちにはチームが一体となる改善への取り組み方として、要員の方たちには自らの能力向上への取り組
み方としてのヒントになれば幸いです。

支援を行っています。
多くのメンバーが関心を寄せる問題の発生頻度を軽減し、メンバーが心の余裕を持てる状態になってから、組織やチーム、
個人のミッションや目標達成のためにプロセスモデルを本格的に活用していくのが段階的にゴールへ向かう方法の一つになると思います。

参考文献● TPI NEXT

ビジネス主導のテストプロセス改善. 薮田和夫,湯本剛,皆川義孝 訳. 株式会社トリフォリオ, 2015, 318p.

®

●“SaPID3.0”. https://www.software-quasol.com/sapid3-0/（SaPID=Systems analysis/Systems approach based Process Improvement methoD）● ソフトウェアテストシンポジウム（JaSST）2018東京投稿事例：

TPI Nextを活用した チームメンバーの問題意識から始めるテストプロセス改善【導入時：改善計画立案編】HBA安達賢二

本記事の内容に関するご質問、お問合せは、ベリサーブマーケティング部 Email：verinavi@veriserve.co.jp までお寄せください。
VERISERVE NAVIGATION

11

ball

要求仕様の曖昧さを理解し、ソフトウェアテストを組み立てる
株式会社ベリサーブ 東日本オートモーティブ事業部 第一ビジネスユニット 課長

はじめに

東 弘之

ようになりました。このような問題へ対応するために、要求仕様書を非曖昧に作成し、要件を正しく伝える、要件を正しく理解していただくことが重要な課題となっています。

自然言語は思っているより曖昧です。当社ソフトウェアテスト
チームは、自然言語で記述された要求仕様書をテスト活動の入力情報として用いる機会が多くあり、多くの要求仕様曖昧さと向き合ってきました。
本稿では、日本品質管理学会誌に投稿いたしました自著

自然言語には曖昧さに気付くための言語学的な技術に限界があり、曖昧さを完全に排除することは困難です。しかし、自然言語の特徴を理解し、適切な対応をすることにより、曖昧さを減らす・曖昧さによる影響を下げることは十分可能です。

論文を一部引用させていただきながら、要求仕様の曖昧さや、
それら曖昧さへの向き合い方をご紹介します。

2. 要求仕様の曖昧さを知る
1. 要件定義にまつわる課題

要求仕様書を非曖昧に作成するためには、まず「曖昧な要 求 仕 様 」とは何かを知る必 要 があります。要 求 仕 様 のJUAS＊1の調査によると、プロジェクトの工期遅延の理由のうち55%が要件定義の問題であるといわれています。その要因には、大きく２つが考えられます。
１．
ユーザーからベンダーへ要件が正しく伝わらないこと。

曖昧さについてはさまざまな定義が存在しますが、本稿ではDaniel M.BerryとErik Kamsties による、書籍「ソフトウェア要求の全体像」（原題：Perspectives on Software
Requirements）2章における定義と分類（図1）をご紹介します。

２．
リスクの認識・合意が不十分であること。
近年、短納期化やコストダウンを達成するための開発手法の一つとして、
ソフトウェア開発の外部委託化が進み、開発工程

曖昧な要求仕様（Kamstiesによる定義）
読み手の背景知識があるにも関わらず複数の解釈があるなら、曖昧な要求である。

ごとに、複数の組織を跨いで開発することが増えています。その結果、組織間に要求の認識齟齬が発生、受入試験までその齟齬に気づかず問題発覚が遅延するなどの問題が生まれる*1： JUAS（Japan Users Association of Information Systems）：一般社団法人 日本情報システム・ユーザー協会

12

本定義における「背景知識」とは、要求を解釈するために必要な知識のことを指し、要求文書、適用分野、システム分野、開発分野の4つからなります。
これら背景知識が読み手に不足していた場合、要求文書が全うでも複数の解釈が生まれて
VERISERVE NAVIGATION

1）語彙論的曖昧さ

1-1）同音異義1-2）多義A）一般性
2）統語論的曖昧さB）漠然性

2-1）接続曖昧さ2-2）等位構造曖昧さC）言語学的曖昧さ

3）意味論的曖昧さ

3-1）等位構造曖昧さ3-2）指示曖昧さ

要求曖昧さ

3-3）作用域曖昧さ
4）語用論的曖昧さ
1）要求文書曖昧さ

Berryらは、要求仕様の曖昧さを大きく言 語 学 的 な 曖 昧さと
ソフトウェア工学的な曖昧さに

4-1）指示曖昧さ4-2）言語誤り

2）適用分野曖昧さD）ソフトウェア工学的曖昧さ

3）システム分野曖昧さ分類した

4）開発分野曖昧さ

図1 Berryらによる要求曖昧さの分類

しまいます。書き手は、読み手の背景知識レベルの想定と対処④Shut off the pumps if the water level remains above
100 meters for more than 4 seconds.

を考慮に入れる必要があり、読み手は要求文章を正しく解釈（4秒より多く水位100メートルを上回ったなら、ポンプを止めろ。）

するために必要な「背景知識」が何かを知り、理解する必要が
あります。

④の例は、
ソフトウェア工学的曖昧さの例で、読み手の適用

ここで、書籍「ソフトウェア要求の全体像」より曖昧さの例を

分野知識の有無により複数の解釈が生まれます。下記のように紹介します。

色々な解釈が可能ですが、多くの工学領域での標準的な解釈
は、解釈3となります。タンク内の水が波打たない場合は全て自然言語の曖昧さの例

同じ結果となり、実装が簡単な解釈4でも良いですが、波打った
場合は危険な水位になる可能性があります。

①The police shot the rioters with guns.
（警官は暴徒たちを銃で撃った。）①の例は、言語学的な曖昧さを含んでいます。人によっては、「銃で武装した暴徒たちを、警官は撃った」というように、
この文章を捉えます。
これは、”with guns”が”shot”と”rioters”のどちらの修飾語句にもなり得るからです。これは2-1)接続

解釈１： 平均水位が100メーターを上回る
解釈２： 中央値水位が100メーターを上回る
解釈３： 二乗平均平方根水位が100メーターを上回る
解釈4 ： 最小水位が100メーターを上回る

曖昧さの例となります。
②Sue is visiting her cousin.

3. 要求仕様の曖昧さ情報を活用する（スーは彼女のいとこを訪ねている。）③He is tall.（彼は背が高い。）②、③の文章は共に不確定性と言われる曖昧さを含む文章

自然言語の特徴から、自然言語で書かれた要求仕様ので、②は一般性、③は漠然性に分類されます。②の文章の曖昧さを完全に排除することは不可能です。実際には、要求

cousin（いとこ）は、性別の判断はできないので一見曖昧だ

仕様曖昧さを排除することがコストや期間的に困難で、曖昧なとも言えます。
しかし読み手、書き手にとって性別情報が不要でまま進めるプロジェクトもあります。そこで、要求仕様の曖昧さあるならば、満足な意思疎通を行えます。一方③のtall（高い）度合の情報をソフトウェアテスト工程に生かすことはできないか？

は、文化などにより異なります。プロバスケットボール選手にと考え、次のような仮設を立て検証を行いました。日本品質

とって、身長180cmは高いとは言えません。漠然性は読み手に管理学会誌に投稿した自著論文では、
この仮説について考察

よって解釈が異なりやすく、境界値ケースで多く現れます。

を行っています。

要求仕様が曖昧①因果関係

欠陥密度が高い仮説 要求仕様が曖昧な領域ほど、欠陥密度が高い②因果関係

質問割合が高い③これらに因果関係は無いが相関関係があると仮説する①要求仕様が曖昧だと欠陥密度が高くなる。
（因果関係）②要求仕様が曖昧だと、テスト設計時の質問割合が高くなる。
（因果関係）①と②の因果関係から③の相関関係が仮定される。
③質問割合の高い機能領域は、欠陥密度が高い。
（相関関係）
図2 要求仕様の曖昧さが与える影響

VERISERVE NAVIGATION

13

0.300欠陥密度 実 測値

0.250
0.200
0.150

各測定値と実測値の相関係数

0.100

欠陥密度
測定手法

0.050
0.000
0.000

0.020

0.040

0.060

0.080

0.100

提 案 手法：要求仕様曖昧度（質問密度）
質問密度 = 質問数(誤り指摘を除く) ／ 文章数

欠陥密度 = 欠陥数 ／ 文章数● 検証対象のシステムを30の機能領域に分け、各領域の質問密度と欠陥密度を計測した。
（外れ値、てこ比の大きなデータは除外）（括弧内は有意確率）

ピアソン積率
相関係数

スピアマン順位
相関係数

提案手法

0.76
（P<0.001） 0.75
（P<0.001）

Kaner法-0.18（P=0.348） -0.10（P=0.621）

鎌田法

0.28
（P=0.151） 0.37
（P=0.054）

経験法

0.10
（P=0.615） 0.07
（P=0.725）● 提案手法以外にも、仕様書改編数や序章の充実度、事前テスト結果から推測する手法を試し、比較を行った。

● これら密度間の相関係数は0.76となり、相関があることを確認できた。

● 提案手法のみ相関が有意であると評価でき、相関も提案

手法が最も高いことを示した。
図3 要求仕様曖昧度と欠陥密度の分布

この仮定が正しいかを、とあるプロジェクトで検証を行いました。その結果、曖昧さ度合いと欠陥密度の間に相関がプロジェクトで確認することのできる、数少ない欠陥予測の情報として活用が期待できます。

あること示す結果を得ることができました。
（図3）
この関 係 性を用いることで、リスクベースドテストのインプットとしてより効果的な指標が得られます。すなわち、テスト
設計時の質問内容や質問領域を調査し、欠陥の多い領域を推定、テスト組織やテストの厚みを決めるときの参考にすることができます。ソフトウェアテストの見積・計画は、困難なことが多いのですが、要求仕様の曖昧さは、外部委託開発形態の4. 要求仕様の曖昧さを正す
曖昧さを活用する一方、曖昧さを減らす取り組みも、もちろん行っています（むしろ、こちらが王道です）。プロジェクトを成功に導くためには、上流成果物の品質を高めることが不可欠であり、近年、お客様（委託元企業）からのニーズも、テスト
設計工程から、要求仕様の作成工程、プロセス作りと、より上流工程からの品質づくりへと変化しています。図４は当社①U M Lや S y s M L 、
USDMを用いた要求間の整理や改善、
読み易さへの工夫要件定義③ソフトウェアシス
テムのテストに関
する研究

レビュー・
テスト設計

委託発注

システム
テスト

デバッグ

②上流工程でテスト
設 計、仕様問題 点のフィードバックの品質向上のソリューション例となりますが、①、②の部分における取り組みが曖昧さ削減へ効果的な活動となります。

おわりに④受入基準の明確化

受入テスト

本稿では自然言語を用いた要求仕様の曖昧さ、および当社
で行っている曖昧さへの向き合い方を２つご紹介しました。

設計

⑤設計書と
要求仕様とのトレースチェック

レビュー・
テスト設計

実装

デバッグ

レビュー

単体統合
テスト

⑥モデル図検証（要求仕様どおりにモ デル 化 さ れているか）

何より重要なのは、
自然言語は曖昧であることを知っていることです。曖昧さにはどのような種類があるか、要求仕様書を読むために（書くために）必要な背景知識は何か、などを知っておくことで、
より正しく要求を理解できるようになると思います。
本稿が、皆様の品質向上活動の一助になれば幸いです。

曖昧さソリューションは①②

図4 当社の品質ソリューション例

本記事の内容に関するご質問、お問合せは、ベリサーブマーケティング部 Email：verinavi@veriserve.co.jp までお寄せください。

14

VERISERVE NAVIGATION

非機能テストにおけるベリサーブの取組みと、IoTのセキュリティ要求への対応
株式会社ベリサーブ ソリューション事業部 事業部長

はじめに

桑野 修

となるにも関わらず、暗黙の要件として見落とされてしまう
ことが少なくありません。実際に非機能要件に関する開発の手 戻りは非 常に大きく、ユーザーと開 発 者 間でのトラブル

当社は、検証専門企業として2001年に設立した当初から、を引き起こす要因の一つになっています。

専門性を追求する分野の一つとして「非機能要件」の検証に携わってまいりました。
昨今のIoT関連製品の普及に伴い、「性能」や「セキュリティ」をはじめとした「非機能要件」に関する検証のご相談が増加の一途をたどっております。

1.2 非機能要件の重要性の高まり
ネットワークの発達によりシステムの規模やユーザー数の増大、多種多様のデバイス同士がつながることで、想定外の

そこで、
本稿では
「非機能要件」中でも特に重要視されている

使われ方が出てくることから、非機能要件をきちんと考慮した「セキュリティ」
を中心に、当社での取り組みをご紹介いたします。

開 発がよりその重 要 性を増しています。2 0 0 8 年ごろから
ユーザー側、ベンダー側双方の立場を考慮した、「非機能要件
要求仕様定義ガイドラン（日本情報システムユーザー協会）」、

1.非機能要件について「非機能要求グレード（2010年からはIPAより発行）」といった非機能要件についての要求ガイドラインが発表されるようになりました。品質特性においても、ISO/IEC 9126-1から、

1.1 非機能要件とは

ISO/IEC 25010への改定時、「機能性」の副特性として「 非 機 能 要 件 」という言 葉については、耳 慣れない方も格上げされたことからも、その重要性が伺えます。このようないらっしゃるかもしれません。ソフトウェア製品・システムには、満たすべき振る舞いが「要求仕様書」などで明示的に定義される「機能要件」と、システム全体が満たすべき特性として期待されるが、必ずしも明記されていない「非機能要件」の定義されていた「セキュリティ」が、副特性から主特性として流れからソフトウェアの開発に携わる企業は、ガイドラインや標準化をもとに、品質面でのリスクを十分に考慮する必要に迫られています。

２つが存在します。本来、非機能要件の実現には「システムアーキテクチャ設計」などの「最上流工程」での考慮が必要*1： ISO/IEC 9126-1：ソフトウェア製品の品質―第1部：品質モデル*2： ISO/IEC 25010：システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム
及びソフトウェア品質モデル

VERISERVE NAVIGATION

15

① PCI DSS

2.非機能要件に対するアプローチ

PCI DSSとは、
Payment Card Industry Data Security
Standard の略で、VISA、MasterCardなどをはじめとする

当社では、非機能要件の品質に対する関わり方として、

ペイメントカードブランド5社が展開しているセキュリティプロ

主に「性能」「セキュリティ」の２つの側面よりアプローチをグラムの拠り所となる、国際的なデータセキュリティ基準です。

行っています（図１）。非機能要件については、テスト工程から2006年9月に公開後、改定が繰り返され2018年12月時点

対策を行うのではなく、要求・要件整理やレビューなどの活動をでは2 0 1 8 年 5月に改 訂された3 . 2 . 1 版が最 新 版となって通して、開発の上流工程からテストエンジニアがプロジェクト

います。この基準にはセキュリティ要件と、具体的なテスト方法に関わるケースも増えてきました。テストプロセスを開発プロが記載されているため、カード業界だけでなく、機密性の高いセスと並走させることにより、早い段階で課題を検出することデータを保持するあらゆるシステムのセキュリティに関するが可能で、プロジェクトの効果的なリスク回避につながって要件抽出に役立ちます。また、2020年の東京オリンピック

います。

開催に向けた、
クレジットカードのセキュリティ強化を目的として、すべてのカード事業者についてはPCI DSS準拠が義務化されるようになりました。

3.セキュリティ要件に対する取り組み② CC認証・JISEC

図2は、IT、IoTを取り巻く代表的な脅威と、それに伴うセキュリティ基準の開始時期を表しています。インターネットのCC（コモンクライテリア）
認証とは、IT製品に対するセキュリ

普及をきっかけに、2000年頃より情報セキュリティの基準がティ評価の国際標準規格を指します。CCは1999年にISO設けられるようになりました。
しかし、IoT機器の普及により、

標準（ISO/SEC 15408）に制定されており、車載などの業種

機器同士やIoT機器とWebサービスの接続が行われるように別セキュリティガイドラインでも広く引用されています。日本

なってきたことで、新たなセキュリティリスクが急増しています。

ではJISEC（Japan Information Technology Security

ITサービス・製品の開発に携わる事業者様、とりわけ標準化のEvaluation and Certification Scheme）と呼ばれる、

スピードが速い自動車・車載分野を中心に、新たなセキュリティ基準の策定および適用が急速に進んでおり、多くの事業者様がその対応に苦慮されております。

IT関連製品のセキュリティ機能の適切性・確実性を、第三者（評価機関）がCCに基づいて評価し、その結果を認証機関

そこで、当社でもセキュリティ基準の準拠のご支援を行っている、代表的なセキュリティ基準や業界の動向についてご紹介いたします。

が認証する制度があります。この制度は主に政府調達に利用されています。JISECよりCC認証を受けた場合、その認証はCCRA（CC国際認証アレンジメント）加盟国17カ国と、11カ国受入国からも相互認証を受けることが可能です。

対象

開発工程での取り組み●

キャパシティ予測

テストプロセスでの取り組み●

アクセスログ・リソース分析
ビジネス要求からのリソース予測●

性能

テストアウトソース（テストプロセス全般）
テストPMO
テスト推進・方式設計
テスト実行支援●要求分析支援●脅威分析・対策検討●

セキュリティ

レビュー支援要件策定支援●要件・設計レビュー

テストアウトソース（テストプロセス全般）

主なテストの種類
●

性能テスト

●

負荷テスト

●

限界負荷テスト●

累積稼働テスト●

セキュリティ性能適合性テスト●

脆弱性テスト●Fuzzing

ソースコード検証

セキュアコーディング規約検証
脆弱性診断
図1 当社における非機能要件に対するアプローチ

16

VERISERVE NAVIGATION

1991年〜

2001年〜
自己顕示

2011年〜

2021年〜

情報搾取・金銭目的化
ISMS（ISO/IEC 27001：2013）

IT

Pマーク（JISQ15001：2006）
PCI DSS
IoT
AI

ITサービス・製品の開発者セキュリティを意 識した「企画・設 計・実 装・検 証・運 用」
していく事が要求される時代にIoT

組込製品がN/Wにつながる
さまざまなITサービス：高度化・自動化

CC（ISO/IEC 15408）

ITセキュリティ評価及び認証制度

ISO21434（策定中）

自動車向けセキュリティ規格

図2 セキュリティの脅威と対策の変遷③自動車・車載分野における動向
組み込みソフトウェア製品領域の中で、セキュリティ対策の具体化が最も進んでいる分野として「自動車・車載」の分野

a.PSIRT 組織構築・ガイドライン策定
b.付帯業務の効率化
c.脆弱性管理運用が挙げられます。2020年以降を目途に、自動走行やコネクテッド化も視野に入れたセキュリティ対策に関する国際標準
ISO21434の策定が予定されており、OEM（完成車メーカー）
を中心に、CCなどを活用したセキュリティ要件の明示化が自主的に進められています。このような動向に伴い、Tier1（一次請サプライヤ）
をはじめとした各種サプライヤについても、

当社では、これらの課題に対し、製品を構成するソフトウェアのBOM（部品表）の整備や、ナレッジの集約などのご提案を通して、SIRT組織の立ち上げや、運用効率化のためのシス
テム整備および運用のご支援を行っております。

セキュリティ要件に対する対応の検討・実施についての説明
責任が伴うようになりました。これらの対応については、お客様からのご相談も多く、検証の立場よりご支援を行っている分野

おわりにとなります。
④セキュリティ運用についての課題
セキュリティ要件の新たな動向として、SIRT（Security
Incident Response Team）組織の立ち上げを課題とされているお客様が増えています。背景としては、プロダクトの開発にOSSを利用するケースなどが増えてきており、自社製品の中に組み込まれたOSSの脆弱性がリリース後の運用時にIoT技術の進歩と普及により、非機能要件の中でも特にセキュリティのリスクは飛躍的に高まっています。そのセキュリ
ティリスクを回避するために、さまざまな分野においていろいろな規格や基準が設けられ、それが常に改変されているのが現状です。当社は、それらのトレンドを常に取り込みながら、適切なサービスやソリューションを考えて、お客様のご要望にお応えして参ります。

見つかるケースなどが増えてきたためです。情報システムに対する対応組織であるC(Computer)SIRTの普及はここ5〜10年で進んできましたが、IoT機器の普及に伴い、組み込み製品に対する対応組織P（Product）SIRTの立ち上げを急がれるお客様が増えています。組織の立ち上げに関する
お客様の課題は、概ね次のようなものに分類されます。

本記事の内容に関するご質問、お問合せは、ベリサーブマーケティング部 Email：verinavi@veriserve.co.jp までお寄せください。

VERISERVE NAVIGATION

17

～

A
I

利用テストツールの最新動向

はテスターを超えるのか ～

A
I

はじめに
第三次AIブームと言われる中、
ソフトウェア開発の世界でもAI製品の開発方法（SE4AI: Software Engineering
for AI）とソフトウェア開発へのAIの利用（AI4SE： AI for
Software Engineering）の両面からの議論が盛んになっています。実践面の事例ではAI4SEに関するものが先行しているようで、
ここ1～2年インターネットニュースやSNS、あるいはカンファレンスでAI4SEのツールの記事や講演を目にすることが多くなりました。
本稿では、主にインターネットで収集した情報に基づいて、
AI4SEの概況と我々に関係の深いソフトウェアテストへのAIの利用の典型例としてAI利用テストツールの最新動向を紹介します。

辰巳 敬三 氏たつみ けいぞう

1976年、富士通株式会社に入社。ソフトウェア製品検査部門でメインフレームOSの検査、品質保証を担当。その後、UNIXやPCのソフトウェア
検査に従事。
1999年に検査の現場は離れたがソフトウェアの品質、テストの技術の探求をライフワーク
として研鑽を続けている。
2009年から2016年にNPO
法人高度情報通信人材育成
支援センター（CeFIL）に出向
し産 学 連 携のI T 人 材 育 成を担当。

1. ソフトウェア工学関連の会議や活動の最近の動き
従来から開催されているICSE（International Conference
on Software Engineering）などのソフトウェア工学系
国際会議やISSTA（International Symposium on
Software Testing and Analysis）などのソフトウェアテスト系
国際会議ではAI関連の論文発表が増えてきています。さらに
2017年頃からはAIとソフトウェア工学を主題とする新たな研究系の国際会議やワークショップの開催、実務家のコミュニティの設立、標準化などの動きが始まりました。筆者が認識している新たな会議や活動を表-1にまとめましたので状況を見てみましょう。
海外の研究系の会合では、RAISEが比較的早く第三次
AIブームが始まった頃の2012年に開始されました。ICSE
併設のワークショップで、AIとソフトウェア工学の関係を双方向から研究者と実務家で議論することを目的としています。
SEMLAはAIの中でも機械学習に焦点をあて、機械学習

18

VERISERVE NAVIGATION

アプリケーションへのソフトウェア工学の適用を主題として実務家のコミュニティの活動もいくつか見受けられます。

モントリオール理工科大学の研究者が立ち上げた研究会です。

AISTAはAI利用テストツール会社test.ai（旧称Appdiff）

2018年6月に第一回がカナダで開催されました。WAISEはの創立者のJason Arbon氏とUltimate Software社のコンピュータの安全性、信頼性、セキュリティに関する国際

Tariq King氏が2017年に立ち上げた米国の組織で、テスト

会議SAFECOMPに新たに併設されたAIの安全工学ワークと品質工学に関するAIの調査やコミュニティでの情報共有のショップです。2018年9月にスウェーデンで第一回が開催され促進を図っています。AIFORSE Communityはウクライナ

ました。iMLSEはアジア太平洋ソフトウェア工学国際会議のValentin Grigoryevskiy氏らが2017年に設立した組織

APSEC 2018併設の機械学習工学に関する第一回国際で、AIを使ったソフトウェア開発企業や利用者の協業プラット

ワークショップです。前述のSEMLAと後述の機械学習工学

フォームになることを目指して、AI適用に関するカンファレンス研究会（MLSE）の共催で12月に奈良で開催されました。

やWebinarの開催、情報収集や公開を行っています。

ソフトウェアテストの研究系の会合としては、2019年4月に標準化の活動も始まっています。国際標準化機構ISOではIEEEの第一回AIテスト国際会議AITestが開催されます。

2017年に情報技術専門委員会（JTC1）の配下にAIの委員会

また、
ソフトウェアテスト国際会議ICST 2019でも新たに併設（SC 42,人工知能）を設け、ISO/IEC 22989（AIの概念とで機械学習のテストとテストへの適用の双方向を扱うワーク

用語）とISO/IEC 23053（機械学習を使ったAIのフレーム

ショップMLSTが2019年4月に開催、さらにICSE 2019でもワーク）の策定を開始しました。
AI製品の品質についても先述のQA4AIの発足が示すようディープラーニングのテストとテストへの適用の双方向を扱う
ワークショップDeepTestが2019年5月に開催されます。

に課題は多く高い関心がもたれています。オランダのSogeti社

日本国内の動きとしては機械学習工学研究会が日本ソフト

はAIの時代におけるテストや品質に関する書籍"Testing in

ウェア科学会の研究会として2018年度より活動を開始し、

the digital age: AI makes the difference"を2018年

2018年5月にキックオフシンポジウムが開催されました［1］。

6月に発刊しました［2］。この書籍では、ISO 25010の製品

また、AI製品の品質保証に関するAIプロダクト品質保証コン

品質特性に、AIやロボテッィクスで使うことを想定した品質

ソーシアム（QA4AI）が2018年3月に発足しています。

特性/副特性を追加することを提案しています。

分野
研究

海外

日本

コミュニティ

標準化
品質の定義

名称

発足

概要

RAISE（International Workshop on Realizing Artiﬁcial Intelligence
Synergies in Software Engineering）
http://promisedata.org/raise/2018/2012年2月

AIとソフトウェア工学 の双 方向の関 係 を扱うICSE 併 設のワークショップとして2012年に開始。
RAISE'18で6回目を開催。

SEMLA（Software Engineering for ML Applications）
http://semla.polymtl.ca/

2018年6月

機械学習アプリケーションへのソフトウェア工学の適用を扱う研究会。
第一回をカナダで開催。

WAISE（International Workshop on Artiﬁcial Intelligence Safety
Engineering）
https://www.waise2018.com/

2018年9月

AI適用システムの安全工学のワークショップ。
S A F E COMP（安 全 /信 頼 性 /セキュリティ工 学 国 際 会 議）2018に併設で第一回を開催。

iMLSE（International Workshop on Machine Learning Systems
Engineering）
http://research.nii.ac.jp/iMLSE /2018年12月

A P SEC 2018併 設の 機 械 学 習工学に関する第一 回国際
ワークショップ。SEMLAと機械学習工学研究会（MLSE）の共催。奈良で開催。

AITest（International Conference on Artiﬁcial Intelligence Testing）
2019年4月
http://www.ieeeaitests.com/

AIアプリケーションのテスト、テストへのAIの適用、AIアプリケー
ションのデータ品質を扱うIEEEの第一回AIテスト国際会議。

MLST（International Workshop on Machine Learning and Software Testing）
https://mlst2019.github.io/

2019年4月

機械学習とソフトウェアテストの双方向を扱うワークショップ。
ICST 2019併設で第一回を開催。

DeepTest (International Workshop on Testing for Deep Learningand Deep Learning for Testing)https://deeptestconf.github.io/index.html

2019年5月

AIプロダクト品質保 証コンソーシアム（Q A4AI：Consor tium of Quality
Assurance for AI-based products and services）
http://w w w.qa4ai.jp/

2018年3月

A I 製 品 の 品 質保 証に関する調 査・体系化、適 用支 援・応 用、研究開発の 推 進とAI製品品質の適切な 理 解の 啓発 活動を展開。

機械学習工学研究会（MLSE：Machine Learning Systems Engineering）
https://sites.google.com/view/sig-mlse

2018年4月

機械学習システムの開発・運用の生産性や品質の向上を追求する研究会。
2018年度より日本ソフトウェア科学会の配下で発足。

2017年

Jason Arbon氏とTariq King氏が立ち上げた米国の組織。
テストと品質工学に関するAIの調査、コミュニティの協力や情報共有を促進。

AIFORSE Community（Artiﬁcial Intelligence for Software Engineering）
https://aiforse.org/

2017年

ウクライナのValentin G r igo r yevsk i y 氏らが 設 立した組織。
AI適用に関するカンファレンスやWebinarの開催、情報
収 集 /公開を実 施。

ISO/IEC JTC1/SC42 Artiﬁcial intelligence
https://www.iso.org/committee/6794475.html

2017年

ISO 22989（AIの概念と用語）、ISO 23053（機械学習を使ったAIのフレームワーク）の策定開始。

2018年6月

オランダのSogeti社の著者が出版した書 籍。
AI製品の品質についてISO 25010の品質特性を拡張したモデルを提 示している。

AISTA（Artiﬁcial Intelligence for Software Testing Association）
https://www.aitesting.org/

Testing in the Digital Age - AI makes a diﬀerence
https://www.sogeti.com/explore/books/testing-in-the-digital-age/

ディープラーニング（深層学習）とソフトウェアテストの双方向を扱うワークショップ。ICSE 2019併設で第一回を開催。

表 -1. AI に関する最近のソフトウェア工学関連の会議や活動

VERISERVE NAVIGATION

19

2. ソフトウェア開発を支援するAIツール

3. AIを利用したテストツール

前章で紹介したAIFORSE Communityでは定期的にテストに関するBlog、TestTalksという対談、Automation

AI4SEツールの提供状況を調査して"Industry Landscape"

Guildというオンラインカンファレンスの開催などで著名なと呼ぶAI4SEツール提供状況表を公開しています［3］。

米国のJoe Colantonio氏は2017年11月のBlogでAIと機械学習によりテスト自動化に第三の波が来ていると書いてこのLandscapeは横軸をソフトウェアライフサイクル、縦軸います［4］。

をツールの成 熟 度（ 提 供 状 況 ）にしてツールが分 類 、集 計されているので、
ライフサイクルのフェーズごとにどの程度のAI4SEツールが提供されているのかが分かります。
ツールの● 第一の波：WinRunner、
Silk Test、
QTPなどのベンダー

成熟度はそのツールのWebサイトで、
顧客、
デモ、
価格の3つ

ツール

の情報のうち2つ以上あれば提供可能（B2B Ready、
B2C● 第ニの波：Seleniumの登場● 第三の波：AIと機械学習を利用したツールにより次のReady）な状態になっていると判定されています。
Webサイトに段階へ記載された情報に基づく判断なので厳密なものではないですが大まかな状況は把握できていると思います。

確かに前章で紹介したLandscapeの状況を見てもこの表-2は本稿執筆時の最新のLandscape（ 2018年8月

第三の波が感じられます。それでは、この波を具体的に見て版）です。掲 載にあたってはA I F O R S E C o m m u n i t yのみましょう。

G r i g o r y e v s k i y 氏 の 許 可を得るとともに 、項 目 名 の

表-3はLandscapeで調査された品質管理/テストツールに

翻訳と注釈をつけました。集計結果に基づいてAIFORSE

筆者が調査したAI利用テストツールを加えて一覧化したもの

Communityは次のようにコメントしています。

です。
盛り上がっている状況を把握するために、ツールの機能
概要に加えてツール開発企業の設立情報も調査して記載しま● AI4SEツールの数は前回調査（2017年10月）の29した。

から今回は43に増加し10ヶ月で48%の増加。

まず、表-3の18社の設立年を見ると、2010年代の企業● フェーズ別に見ると、実装（コード構築/構成管理）とが13社、内8社は2015年以降の設立なので、AI利用テスト

品質管理/テストが多い。

ツールを提供しているのは設立数年のスタートアップ企業● 成熟度で見ると、
品質管理/テストの方が実装よりも実用が 多いことが 分かります。スタートアップ のデータベース

段階のツールが多い。
● 前回調査時点から対象フェーズを変更したツールが5件

CrunchBaseの情報からはこれらの企業へのベンチャー

あり、ベンダーはまだまだ手さぐり状態。

投資が盛んな様子がうかがえます。
また、2018年の半ばにはアジャイルテストで著名なLisa Crispin氏がMabl社に、
AIテストに関して数多く講 演しているA n g i e J o n e s 氏がまとめると、
AIを利用する動きはソフトウェアライサイクルのApplitools社に移籍するなど、本格的なビジネス展開に各フェーズで始まっており、実装やテストという比較的作業が向けて人材の移動も始まっています。一方、2010年以前に

具体的なフェーズのツールは実用段階に入ってきたと言えると設立され第二の波をリードしている中堅スタートアップ企業も思います。

既存ツールへのAIの追加を始めていますが新興スタート

INDUSTRY LANDSCAPE ARTIFICIAL INTELLIGENCE for SOFTWARE ENGINEERING （ver.2018-08-12）
ツール成熟度（＊1）

プロジェクト
管理

要求

設計

コード構築／
構成管理

品質管理／
テスト

保守

合計

提供可能
B2B Ready

0

1

0

4

9

2

14

提供可能
B2C Ready

0

0

3

3

0

0

3

社内ツール
Internal Development

0

0

1

1

0

0

1

説明のみ
Landing Page

2

3

8

12

8

3

25

合計

2

4

12

20

17

5

60 \ 43（＊1）B2B Ready：Webページに顧客、デモ、価格のうち2つ以上の情報あり
B2C Ready：B2B Readyと同じ。SEツールではなく最終顧客用製品

社内ツール：大規模ソフトウェアエンジニアリング企業の社内開発ツール
説明のみ：ツール説明Webページはあるが顧客、デモ、価格情報なし

表 -2. AI4SE ツールの提供状況

20

VERISERVE NAVIGATION

アップに比べて少し出遅れているようです。

また、AIを使ってテストの自動生成をしているツールが7件あり

次に、テストに関する作業のどこにAIが利用されているます。中でもFunctionizeは人間が記述したテストプランをのかを見てみます。次ページの表-4は各社のWebサイトに

自然言語処理（NLP：Natural Language Processing）と記載されている情報からAIを利用している機能を筆者がAIを使って解析してテストケースを自動生成する機能を提供

推定して分類したものです。実際にツールを使用して調査した

しており、かなり先進的なツールとなっているようです。他には、訳ではないので情報が正確でない可能性があることにご注意

コード解析や性能テスト/テスト結果分析を適用分野とするください。アプリケーション画 面を画 像 解 析 A Iで処 理してツールが提供されています。

テスト実行、
ビジュアルの検証、
テストの自動修復（画面要素のテスト自動化の第三の波は、単なるテスト実行フェーズの変更を認識して修正）を行うツールが半数の9件あります。

自動化にとどまらずテスト活動のすべての段階に押し寄せて現在のAI利用テストツールの中心を占めていると言えます。

きています。

No.

ツール名

1

Acellere

2
3
4

機能概要

会社名

国

設立年

ソフトウェア静的解析ツールGAMMAを開発・提供。
Acellere
内蔵するAIを利用して影響範囲を検証しながら効率よくリファクタ
http://www.acellere.com/
リング作業可能。

ドイツ 2009年

Apimetrics

エンドツーエンドの性能監視ソリューションを提供。
Apimetrics
機 械 学 習とA Iにより、見 逃した問 題、懸 念事 項、A P Iとの関 連をhttps://apimetrics.io/
特定。

米国

AppAchhi

機能テスト、性能テストの実行プラットフォーム。
AppAchhi
AIテストボットが実行状況、
スクリーンショット、
ログからクラッシュhttps://appachhi.com/
を識別。

インド 2015年

Applitools Eyes

アプリケーションのUIレイアウト、コンテンツ、外 観を自動 的にApplitools
検証するクラウドベースのテストツール。

https://applitools.com/

2014年

イスラエル 2013年

Appvance IQ

AI駆動の統合テスト自動化システム。
Appvance
AI Scriptingによりユーザのビヘイビアに基づくテストケースを
https://appvance.ai/
生成する。

米国

2012年

Autonomiq

テストケース作成 から影 響 分 析まで 全 テストライフサイクルを
Autonomiq
自動化する自律型プラットフォーム。
ディープラーニングとAIによりhttps://autonomiq.io/
変更を検出しテスト資産を自動修復。

米国

2018年

DeepCode

機械学習によりOSSのコードから得た知識を元にコードレビュー
DeepCodeとQA監査を行う。
https://www.deepcode.ai/
スイス連邦工科大学チューリッヒ校（ETH）のスピンオフ企業。

スイス 2016年

Diﬀblue Cover

AIにより単体テストの自動作成、リグレッションスイートの改善、
DiﬀBlue
未テスト部分を検出し単体テストの自動作成を行う。
https://www.diﬀblue.com/
オックスフォード大学のスピンアウトベンチャー。

英国

2016年

9

Eggplant AI

グラフィカルツールで 記 述したアプリケーションの モデルに基Eggplant
づいて、機械学習を使ったEggplant AI Serverによりカバレッジ
https://eggplant.io/
分析やバグ捜索を行ってテストケースを作成。

英国
米国

2008年

10

Functionize

テストプランを自然言語処理（NLP）とAIを使って解析してテスト
Functionize
ケースを自 動 生 成し、数 千 の テストを 数 分で 実 行 するクラウド
https://www.functionize.com/
テストプラットフォーム。

米国

2015年

11

Mabl

機械学習を使った自動テストサービス。
Mabl
外観の異常検出、リグレッションテスト、テストの自動修復などを
https://www.mabl.com/
自動化。

米国

2017年

Magic Pod

モバイルアプリケーションの自動テストのスクリプト作成を支 援。
TRIDENT
ディープラーニングなどの技術を活用して画面から項目を自動検出
https://www.trident-qa.com/
してテストを作成。

日本

2012年

Perfecto

Web、モバイル、IoTアプリの継続的テストやデリバリーのためのPerfecto
クラウドプラットフォーム。最近のWebinarで機械学習やAIによる
https://www.perfecto.io/
リポーティング機能を紹介。

5
6
7
8

12
13
14

ReTestGUIリグレッションテストツール。AIを 使ったモンキーテストのReTest機能をもつ。

https://retest.de/

SOAtest Smart APIテスト自動化ツール。AIで、APIコールの識別とデータの関係性 Parasoft
API Test
を分析し、さまざまなユースケースのAPIテストシナリオを自動生成
15
https://www.parasoft.com/
Generator
する機能を追加。

16
17
18

イスラエル
2006年
米国
ドイツ 2016年

米国

1987年

AIボットによりリグレッションテストを実 行するモバイルテスト
test.ai
自動化サービス。
http://test.ai/
アプリの画面と要素を識別しユーザのシナリオを実行。

米国

2015年

TestComplete

GUIアプリケーションのテスト自動化ツール。従来手法とAIによる
SmartBear Software
ビジュアル認識を組み合わせたハイブリッドエンジンですべての https://smartbear.com/
UIを検出してテスト。

米国

2009年

Testim.io

機械学習を使用して、自動化テストの編集、実行、保守をスピード
Testimアップ。
https://www.testim.io/
機械学習によりテストスイートの安定性が向上。

米国

2014年

test.ai

ファンド状況
（＊1）
最新ファンドタイプ
Early Stage Venture
Series A
Seed
Seed
ー
ー
Late Stage Venture
Series C
Early Stage Venture
Series A
投資ファンドなし
ー
Seed
Seed
Early Stage Venture
Series A
ー
ー
Seed
Seed
Early Stage Venture
Series B
ーー
M&A
Series Eーーーー
Early Stage Venture
Series Aーー
Early Stage Venture
Series A（＊1）スタートアップのデータベースCrunchBaseの2018年11月時点の情報
表 -3 AI 利用テストツール

VERISERVE NAVIGATION

21

AI利用機能のテスト適用分野
No.

ツール名

1

Acellere

2

Apimetrics

3

AppAchhi

4Applitools Eyes

5

Appvance IQ

6Autonomiq

7

DeepCode

静的解析／
コード解析

テスト
自動生成

テスト実行

ビジュアルの
検証

テスト
自動修復

テスト実行
状況監視

性能／テスト
結果分析

○
○
○
○
○

○
○

○

8

Diﬀblue Cover○9

Eggplant AI○

10Functionize

○

11

Mabl

12

Magic Pod

13

Perfecto

14

ReTest15

SOAtest○16

test.ai

○

○
○

○

○

○
○
○
○

○
○

17

TestComplete○

18

Testim.io○○
表 -4. AI利用機能のテスト適用分野

4. AIはテスターを超えるのか

ぞらえたテスト自律性レベルをBlogで提示しました［7］［8］。
また、Appvance.ai社のKevin Surace氏も2018年10月にBlogで提示しています［9］。なお、単なる自動化ではないの

test.aiのJason Arbon氏はAIのチュートリアルの講師を務めた際、AIには難しいと思われる定性的な品質評価の能力を人間のテスターと比較する実験を行ったそうです。
参加していた70人の優秀なテスト技術者にログイン画面を見せ、「このページが信頼できるものかどうか、どのように評価しますか?」という質問をしました。結果は、70人が5分かけて出した回答が2つ、一方訓練されたAIは3つを回答した
そうです。AIが70人のテスターを打ち負かした（AI Beat 70
Testers）［5］と騒ぐほどではないかもしれませんが、AIに厳しい問題も訓練データによっては人間を超える可能性を示したと言えそうです。AIがすべてにわたって人間のテスターを凌駕するとは思えませんが、現時点でもある種のテストではAIの方が確実に上回るものがありそうです。前章で紹介した
AI利用テストツールの中心を占める画像解析AIを使用したものがそれに当たるのではないでしょうか。果たしてAI利用
テストツールはどこまで進化していくのでしょう。
今 、自動 車の世 界では自動 運 転 車の開 発 競 争が激しくなっていますが、開発にあたっては自動運転レベルの分類とで"automation"ではなく"autonomy"や"autonomous"（自律）という用語が使われています。表-5に自動運転レベルと各氏のテスト自律性レベルをまとめました。各氏の定義は少し異なるところがありますので、比較してみると考え方の違いが分かり興味深いです。
レベル5になると人間のテスターに取って代わることになります。まだまだ先のことだと思っていたら、先日（2018年11月）
Functionizeが最新機能はGil Tayar氏の定義のレベル5にほぼ到達しているとBlogで表明したり［10］、Appvanceも彼らの定 義のレベル5に到 達したとアナウンスするなど
俄かに現実味を帯びてきました。ただ、FunctionizeのPaul
Clauson氏はTayar氏の定義モデルは少し狭く、考慮されていない要素があると指摘していますので、テスト自律性レベル
自体の定義の妥当性はまだ議論の余地がありそうです。
いずれにしろ、テスト自律性レベルを定義して、その目標に向かってAI利用テストツールの開発競争が進めばそう遠くない日にAIがテスターを超えるかもしれません。テスターのみなさん、油断は禁物ですよ！

定義が行われ、業界及び社会での共通認識となっています［6］。2017年10月,11月にApplitools社のGil Tayar氏、
test.ai社のJason Arbon氏が相次いで自動運転レベルにな
22

VERISERVE NAVIGATION

レベル
0

1

2

3

4

運転自動化レベル［6］テスト自律性レベル

名称

概略(各種情報から筆者が要約)

運転自動化なし

ドライバーがすべてを操作
Hands On
Eyes On

運転支援

ベースラインの 【スクリプトによる自動化（Hands On）】
システムがステアリング操作、 人間はテストを書き、テストを繰り返し実行でき、アプリケーション
加減速のどちらかをサポート 変更を検証。
スクリプト作成／コーディング
Hands On
A I はテストア サ ー ション の 記 述 と の変更に対する自己修復性をもつこともEyes On
ページの見映えチェックを支援。
ある手作りのテスト自動化スクリプト

部分運転自動化

ベースラインの 【探索的ボット（Hands Oﬀ）】
システムがステアリング操作、 人間はテストを書き、自動化された準知的探索と人間の コードレスのキャプチャ／変更を検証。
加減速のどちらもサポート
Hands Temp Oﬀ
プレイバックAIは変 更をグル ープ化して変 更の 介入なしの性能／安定性の測定
Eyes Temp Oﬀ検証を支援。

条件付運転自動化

Gil Tayar［7］(Applitools)

Jason Arbon［8］(test.ai)

Kevin Surace［9］(Appvance.ai)

人間はテストを書き、ベースラインの 【手動テスト（無支援）】
人間が物理的に実行する手作業による 自動化なし
変更を検証。
探索的およびリグレッションテスト
AIは何もしない。

特定の場所でシステムが全てを操 作、緊 急時はドライバー
人間はテストを書く。
が操作【人間指示リグレッション（Eyes Oﬀ）】

Hands Oﬀ
Eyes Oﬀ

リグレッションテストケースの目的をどのAIはベースラインの変更を検証。

人間はテストケースの高位の意図を記述、自動マシンはアプリケーションに対して機械学習 - 人間が作成したスクリプトとモンキーボットの自己修復

ように実行するかを自律的に決定

高度運転自動化【生成的（Mind Oﬀ）】
特 定 の 場 所 で シス テム が人間はテストを書くのを支援。
マシンは、探 索 的テストとリグレッ 機械学習 - ほぼ全自動 - スマートな
全てを操作
AIは人間の指導のもとテストを書く。 ションテストのほとんどを網羅する スクリプトの自動生 成Hands Oﬀ
Mind Oﬀ
テストを生成して実行

完全運転自動化

人間の支援なしで、マシンはアプリケー
場所の限定なくシステムが機械学習 - 完 全自動 化 - 検 証 済
ションの評価と、いつ、どこで、どのように人間は何もしない。
全てを操作
ス マ ート ス ク リ プ ト の 自 動 生 成
AIは人間の指導なしにテストを書く。 テストを実行するかの決定ができ、Hands Oﬀ
テスト
（mind-oﬀ）
Driver Oﬀ
結果に基づいてリリース判定できるよう【完全自律（人間のテスターは任意）】
5に人間（またはマシン）に結果を要約

表 -5. テスト自律性レベル導入を検討する際は実際に使用した上での評価が欠かせまおわりにせん。日本でもTRIDENT社のAI自動テストサービスMagic
Podが提供されており身近でAI利用テストツールに触れられ現在のAIブームの盛り上がりを見るとこれからもいろいろな
AI利用テストツールやサービスが登場してきそうです。
ツールのますし、海外のAI利用テストツールの試行評価結果［12］も報告され始めていますので参考にされるとよいでしょう。

参考文献［1］鵜林 尚靖, 鷲崎 弘宜, 鄭 顕志, 機会学習工学研究会キックオフシンポジウム参加報告, コンピュータソフトウェア, 35巻3号, J-STAGE, 2018https://www.jstage.jst.go.jp/article/jssst/35/3/35_3_96/_article/-char/ja［2］Testing in the digital age: AI makes the difference, Sogeti, 2018 https://www.sogeti.com/explore/books/testing-in-the-digital-age/［3］Valentin Grigoryevskiy, AI for Software Engineering - Industry Landscape（12/Aug/2018）https://medium.com/ai-for-software-engineering/ai-for-software-engineering-industry-landscape-12-aug-2018-e8e028628663［4］Joe Colantonio, 8 Innovative AI Test Automation Tools for the Future：The Third Wave, Nov 7, 2017https://www.joecolantonio.com/7-innovative-ai-test-automation-tools-future-third-wave/［5］Jason Arbon, AI Beat 70 Testers - and You!, Nov 1, 2018 https://medium.com/testdotai/ai-beat-70-testers-and-you-c4d14e8f8007［6］自動車技術会, JASO TP 18004:2018 自動車用運転自動化システムのレベル分類及び定義［7］Gil Tayar, Not Only Cars: The Six Levels of Autonomous Testing, Oct 30, 2017

http://www.jsae.or.jp/08std/

https://medium.com/@giltayar/not-only-cars-the-six-levels-of-autonomous-testing-a22611ab1d7f［8］Jason Arbon, Test Autonomy Levels, Nov 21, 2017https://blog.appdiff.com/test-autonomy-levels-7de7967d030e［9］Kevin Surace, 5 Levels of AI Testing Autonomy, Oct 24, 2018https://www.appvance.ai/5-levels-ai-testing-autonomy［10］Paul Clauson, Levels of Automation in Testing, Applying this model to Functionize, Nov 5, 2018https://www.functionize.com/blog/levels-of-automation-in-testing/［11］Appvance Announces Level 5 Autonomy for Software QA, Nov 15, 2018https://www.appvance.com/appvance-announces-level-5-autonomy-software-qa［12］板垣 真太郎, AI for Testing（AIを活用したテスト）のスタートアップ情報共有, システムテスト自動化カンファレンス2018https://www.slideshare.net/ssuser5c492c/ai-for-software-testing

本記事の内容に関するご質問、お問合せは、ベリサーブマーケティング部 Email：verinavi@veriserve.co.jp までお寄せください。
VERISERVE NAVIGATION

23

連載

【後編】

デジタルイノベーションがもたらす創造的破壊とは～ソフトウェア大革命に備えよう～

大原 茂之 氏おおはら しげゆき
現在（株）オプテック代表取締役
会長、工学博士

東 海 大 学 名 誉 教 授 、九 州 工 業
大 学 客 員 教 授 、一 般 社 団 法 人

スキルマネージメント協会理事長

はじめに
前編では、新製品や新サービスをマーケットへ提供する側と、それら新製品などを利用する側を一体化したイノベーション・
イノベータモデルを示し、イノベーション
の拡大について述べました。その上で、未だにアナログ的なソフトウェア開発をデジタル化できなければ、日本の多くの産業が世界の中で遅れをとることを指摘しました。特にAIの導入はソフトウェア
開発をベンダー側からドメイン側に大きく移行させるなどソフトウェアの産業構造

グループの研究活動、本院・分院間の1. IoTとデジタル
イノベーション

連携や、患者が治療の予約をするなど、物理的な作業やデータを扱います。
IoT空間はリアル空間との間でカルテ

1-1.リアル空間、IoT空間、
サイバー空間情報などをやりとりします。電子機器などの場合はセンサがデータを取得してIoT

ここではこれらの 空 間 の 一 般 論は空間側へ送り、IoT空間側からモータ避けて、AIを活用する歯科用電子カルテなどのアクチュエータ（駆動装置）をコンシステムの観点から俯瞰した場合（図１）

トロールするデータが送られてきます。

について述べます。

機器等をコントロールする機能が機器を離れてI o T 空 間 側 へ 移 行していく

リアル空間では歯科医師が口腔内の治 療について電 子カルテシステムにのです。いわば、歯科医師がセンサと患者の所見や治療状況を入力します。

アクチュエータの役割を果たし、電子

さらに、大学での教育活動、スタディー

カルテシステムと一体になってエッジとを大きく変革していきます。
そして、
ソフトウェア開発以上にデータとその履歴の収集と活用が大きな価値

リアル空間
IoT空間
IoT

を生み出します。過去のデータが価値を持つため、機能を開発する技術力が如何に高度であっても勝負できないの

サイバー空間スマートフォン

AI

歯科大学

DB

です。データの収集が遅くなればなるほど産業競争力は弱体化していくことを認識する必要があります。この後編

スタディグループ
IoT 空 間 上のカル テは歯科医師と一体化した
エッジとなる

歯科診療所
歯科診療
診療所

では、IoT、AI、
ビッグデータによるデジタルイノベーションの実際の事例として
歯科用電子カルテにおけるAIについて
ご紹介します。

24

電子カルテ
はエッジ

歯科医師と電子カルテ

ドクターはセンサ
お よ び アクチュ
エータの役割本院−分院などのネットワーク

図1 IoT空間、サイバー空間、
リアル空間

VERISERVE NAVIGATION守破離は日本の伝統的な人材育成の文化
離が創造的破壊型のレベル

スキルの期待値
離

異なる次元へ破

創造的破壊型イノベーション型

新たな技術（知識）を開発できる（創造者）
レベル４（最上級）（これまでの知識を超えた新しい知識を創造できる）
定常的イノベーション型

レベル３（上級）

作業を分析し改善・改良できる（1.5人前以上）（後進を指導でき、既定の工程での想定外の事象に対応できる）

レベル2
（中級）

自律的に作業を遂行できる（1人前）（既定の工程に沿った行動ができる）

レベル1（初級）支援のもとに作業を遂行できる（半人前）（一人では既定の工程に沿った行動ができない）

守

図2 ETSSとイノベーションスキルの育成なっていると解釈できます。
サイバー空間はIoT空間の一部として位置付けられます。
AIやAIの学習データ
はここに位 置 付けると分 かりやすい構造になります。
AIを活用する電子カルテシステムの 一 部 機 能はクラウド側に

2. イノベーションを創造する
人材育成と環境2-1.イノベーションを起こす
骨太の人材育成

ものです。この評価基準は日本の伝統である守破離をベースにしています。
守破離は武道、茶道などさまざまな流派（グループ）に伝わっている考え方です。
守の段階は、技の形を覚え、それらの形を使いこなせるように指 導します。

存 在することになり、データの収 集と欧米の人材に教えを受けながら近代破の段階は、形の存在を意識すること一括管理に寄与することになります。
この化に向けて踏み出した明治時代、
その中なく身体が勝手に動くまで指導します。

ことがシステムの運用強化やコストのにフリードリッヒ・ワグネルというドイツ人

守破離の凄いところは離にあります。

削減につながることになります。

の技術者がいました。ワグネルは東京

離はその流派を超えた高い次元の流派

工 業 大 学 の 創 設に深く関 わったイノを創始できるように指導するのです。

1-2.開発、製造および運用コストの観点ベーターでした。ワグネルは西洋の油絵

すなわち流派の指導者のミッションは、などに傾注し日本の伝統文化を軽視する

その 流 派を創 造 的に超えていくイノ

当時の日本の姿を猛批判しています。

ベーターの人材育成にあるのです。こうリアル 空 間だけで機 能する製 品に「日本固有の画術を捨てるとは何事した考えを現代風にアレンジしたものか。外国の一芸を真似する流れを止めがETSSです。

対し、一部もしくは大半の機能をIoT空間に移行した製品では、その開発、製造
および運用コストは大きく異なってきます。
製造コストにおいては、
リアル空間における部 品 点 数の削 減 、製 造 工 程の簡略化、品質管理の簡素化などコスト削減が可能となります。
運用コストにおいては、
IoT空間で提供される機能やストレージといったリソース
は、多くのリアル空間のユーザが共有するため、可動率が高くなりユーザ当たりのコストは低下します。
サイバー空間にあるAIは多くのユーザ

ないと、
日本の諸製品の質は低下し、製品は似て非なるものとなり、外国に容易に製法を真似されよう」。
ワグネルは画の上手下手ではなく、日本の画に代表される日本固有の文化がものづくりとその品位向上に大きく貢献
していることを説いたのです。
ワグネルに学ぶならば、
単に「IoTだ」
「AIだ」
、
「ビ
、 ッグ
データだ」と無批判にまねるのではなく、日本の文化の観点から人材育成とイノベーションをセットにして新しい時代に臨むべきだと考えるべきでしょう。

が使うことから当然安価なものになってきます。
デジタル化された空間の結びつき

2-3.組織改革を阻害する
マニュアル
イノベーションあるいは組織改革を起こすには組織的な環境が重要なファクタとなります。どのような環境がマイナスとして機能するかについては、米国
戦略諜報局（OSS）が敵国をおとしめる
ように作成した諜報員用のサボタージュ
マニュアルが衝撃的です。
基本的な考え方は、誰も否定できない
理屈や規則を作って無駄な時間を増やす

2-2.日本の伝統「守破離」に学ぼう

ことや 、リソースのライフサイクルをできるため、
１ユーザ当たりのコストを

図２はIPAで開発した組込みスキル

以下に示します。

低減するサービスにつながるのです。

標準（ETSS）のスキル評価基準を示した

は、多くのユーザが保有することなくシェア

VERISERVE NAVIGATION

縮めることなどです。アレンジした例を

25

①重要な現場の業務があっても、あら場合は、それらの経験知を丸め込んだ

歯科用電子カルテに記録する際に、適かじめ設定した会議やイベントには解決事例をAIに学習させることで、人間切な実例を参照できるようにしたAzure

必ず出席させ、組織的活動を守ると同 等 の 解 決レベルを目指すことがAI（マイクロソフトが提供するAIプラット

ことの重要性を認識させる。

できます。具体的には図３の口腔内のフォーム）の概要を図４に示します。

②例え前回の会議で決まったことでも、状態で組合せ爆発が起こります。

大づかみには、Azure AIはURLの再度検討を促しあるいは質問を繰りこの図は親知らずを含む大人の歯牙のかえして結論の質を高めていく。

場所（部位）を示したもので、上下左右③拙速に物事を決めると先々問題がで合計３２カ所になります。
ここで、
各部位

発生することを理解させ、注意深くごとに正常と虫歯（５段階）の計６通り

時間を掛けて判断する習慣を付けの状態のいずれかになっていると考えさせる。

ます。すると、口腔内の状態の場合の集合として認識することもできます。
3-3.歯科の電子カルテ
作成支援用Azure AI
図５に電子カルテに記載する際に関連する臨床データを参照できるように支援

数は6 32 (7.95866111×10 24 )通りに
こうしたサボタージュは、参加者のモチなります。実際には一つの部位だけでベーションを徐々に削り、イノベーション

100通り以上の状態があり、手を付けようを阻害していくことにもなります。

がない組合せ爆発になります。さらにするAzure AIの全体の関係を示します。
所 見から病 名の事 例を探 索するA I 、
病名に対する治療の事例を探索するAI、口腔内全体の治療部位の治療計画事例

治 療 順 序に対する患者からの要望も

3. 歯科診療とAIによるデジタルイノベーション
3-1.AIを活用する場面を探索するAIまでの流れに対し、逆のあり、治療に関しては次の②で述べる

方向で探索するAIもあります。これらのように歯科医師の経験知がものをいう

Azure AIにはそれぞれクレンジングことになります。

した学習データを用意しています。
組合せ爆発の一方で、歯科医師の②経験知を狙え

ここからは、
どのような問題解決にAIを活用しイノベーションに結び付けていくかについて、歯科用電子カルテシス
テムへの応用事例に基づいてご説明
していきましょう。
①組合せ爆発を狙え

組合せ爆発ではなくても、感覚、直感

経験知がものをいう処理であるため、あるいはコミュニケーションのニュアンス

基本的にプログラミングで解決する対象など、データにできない対象はプログラムにはなり得ず、
ソフト開発ベンダーが活躍

開発に向いていません。
こうした場合は、する場面は限定的になります。
ちなみに、質問と回答の事例を集めてAIに学習させ

このAIは機械学習のタイプであり、AIることで、AIがあたかも経験知を持ってとしては基本的なアーキテクチャになりいるかのように機能させることができます。

ます。

組合せ爆発＊1を起こしている問題領域のプログラムを開発するには、解を導く

3-2.マイクロソフトのAzure AI

3-4.実行例あります。
しかし、アルゴリズムが無くてもここでは、組合せ爆発や経験知に囲図6.1と図6.2は病名から治療の流れ人間が経験知（暗黙知）で解決している

まれた歯科治療に関わる内容を弊社のの臨床事例を探索するAIを、弊社のアルゴリズムが発見されている必要が

正面
4

右上

3

1 2

3

4

左上

5

5
6

6

7

7

口腔内部位
32カ所

8
8

右下

2 1

7
6

3

2 11 23

45

学習用 DB

学習要求
制御部
②学習要求
③学習状況取得要求

学習データ

8

6
4

①
データクレンジング
作業

④質問

8

7

5

学習用
データ

回答

Azure AI
学習状況報告左下

図3 口腔内の部位①図に示すように、学習させるカルテデータをクレンジングし、学習用DBに登録していきます。クレン
ジングとしてはカルテデータの訂正、個人情報が含まれないようにするなどを行います。
②学習用DBができあがった段階で学習要求を発行します。ここでは約20万人分のカルテデータを学習させています。
③学習状況取得要求を発行することでAIの学習状況を把握できます。

*1： 問題の規模に対して解の数が指数関数的に急激に大きくなってしまうために、有限時間で解を発見することが困難になることをいう。
（Wikipediaより要約）

26④学習完了後、質問に対して、確信度を付けた回答を得ることができるようになります。

図4 Microsoft Azure AI の概要

VERISERVE NAVIGATION

歯科医師側と患者側の要望に応えるAIソリューション
所見と病 名の対応
関係を学習

歯 科 医 師 やスタディグル ープの考え方を学習可能⇒カルテ作成の効率化、標準化、高品質化などに寄与

所見

所見

病 名と治 療リスト の対応関係を学習病名

病名／所見事例探索ＡＩ
一口腔内の全治療リスト部位nの処置リスト＜病名, 治療, 確信度＞
部位2の処置リスト＜病名, 治療, 確信度＞
部位1の処置リスト＜病名, 治療, 確信度＞

一口腔内
部位別
治療集計機能治療リストと治療プランの対応関係を学習

部位ごとの
治療の流れ

治療事例／病名探索AI

A I 探 索 の 臨 床 デ ー タによる治療計画事例の提示

客 観 性のある
一口腔の治療プ ラン の 事 例

治療計画事例探索AI＊本研究開発は平成28年度補正革新的ものづくり・商業・サービス開発支援補助金 第四次産業革命型による成果です。

図5 電子カルテ作成支援用AI

おわりに

臨床事例

本稿ではデジタルイノベーションの具体的な事例として歯科医療分野に
C3急化Pul

確信度

おけるAI開発と活用をご紹介しました。
プログラミング技術が大きな曲がり角を迎えていると言えます。これまでプロ

図 6-1 病名からの「治療事例探索 AI」

図 6-2 病名からの「治療事例探索 AI」の結果

電子カルテシステムOpt.oneと連動①都道府県別探索支援させた結果です。

②スタディーグループ別探索支援

図6.1は実行前の画面で、病名を選択③歯科大学向け教育支援ツール

している画 面です。ここではC 3 急 化④本院―分院間標準化支援

Pulという病名を選択しています。

⑤代診向け標準化

図 6 . 2はA z u r e A Iに上 記 病 名を

⑥歯科クリニック向け探索支援

投げた後で返ってきた確 信 度 付きの⑦弊社ユーザ以外でもクラウドから使用可能にする支援臨床事例です。
これらのAIは次のような活用シーンに投入していきます。

このように歯科医療機関やさまざまな組 織の事 情に合わせてチューニング
できることもAIの強みになります。

参考文献［1］エベレット・ロジャーズ イノベーションの普及

グラミングの対象から外れていた領域が急速に拡大していきます。この加速を持続させようとすると、データ収集が壁になってくる可能性があり、この壁をどのように乗り越えるかが大きな課題となります。
Azure AIを用いて本稿のシステムを開発する上で、日本マイクロソフト、
クレスコの２社様には多大なご協力をいただ
きました。この場をお借りして御礼申し上げる次第です。またこのような執筆の機会をいただいたベリサーブ様にも感謝申し上げます。

翔泳社、2007［2］鎌田富久 テクノロジー・スタートアップが未来を創る 東京大学出版会、2017［3］クレイトン・クリステンセン イノベーションのジレンマ 翔泳社、2001［4］ジェフリー・ムーア キャズム２ 翔泳社、2014［5］ヨーゼフ・シュンペーター 経済発展の理論（上・下） 岩波文庫、1977［6］ヨーゼフ・シュンペーター 資本主義、社会主義、民主主義（Ⅰ・Ⅱ） 日経BP社、2016［7］瀧悌三 日本近代美術事件史

東方出版、1993［8］米倉誠一郎 イノベーターたちの日本史［9］IPA/SEC 組込スキル標準

東洋経済新聞社、2017

ETSS概説書[2008年版]

翔泳社、2008［10］米国戦略諜報局（OSS） サボタージュマニュアル★諜報活動が照らす組織経営の本質、北大路書房、2015
本記事の内容に関するご質問、お問合せは、ベリサーブマーケティング部 Email：verinavi@veriserve.co.jp までお寄せください。
VERISERVE NAVIGATION

27

VERISERVE NAVIGATION（ベリサーブナビゲーション）
2019年1月号
編集・発行

株式会社ベリサーブ
東京都新宿区西新宿6-24-1 西新宿三井ビル14F

お問い合わせマーケティング部：03-6302-0707
verinavi@veriserve.co.jp＊本誌の記事中に掲載する社名または製品名は、各社の商標または登録商標です。