クラウドが使えない環境でもテスト自動化はできる

規制産業・高セキュリティ環境におけるT-Plan Robotの活用

ソフトウェアテストの自動化は、開発スピードの向上や品質の安定化を実現する重要な手段として、さまざまな分野で導入が進んでいます。

しかし、防衛、官公庁、医療、金融、社会インフラなど、厳格なセキュリティポリシーやコンプライアンス要件が求められる環境では、一般的なテスト自動化とは事情が異なります。

「テスト環境をインターネットへ接続できない」
「クラウド型のテストサービスへ画面やデータを送信できない」
「ソースコードやAPIへのアクセスをテストツールへ許可できない」
「テスト結果を監査証跡として残さなければならない」

こうした条件が重なることで、“自動化したいが、自動化ツールそのものを導入できない”という問題が発生します。
そこで注目したいのが、T-Plan Robotによる**Secure Test Automation（セキュアなテスト自動化）**です。

T-Planは、デスクトップ、Web、モバイル、エンタープライズアプリケーションを対象に、ソースコードへのアクセスや侵入的なインテグレーションを必要とせず、ユーザーインターフェースレベルからテストを自動化するアプローチを提供しています。公式サイトでも、防衛、政府・公共、医療、金融などの規制・高セキュリティ環境を主な対象として紹介しています。

規制産業では、なぜテスト自動化が難しいのか

一般的なWebアプリケーションでは、DOM、API、テストフレームワーク、CI/CDサービスなどを利用することで、高度な自動テスト環境を構築できます。しかし、高セキュリティ環境では、それらを自由に利用できるとは限りません。

例えば、次のような制約があります。

• インターネットへの接続が禁止または厳しく制限されている
• 外部クラウドサービスの利用が認められていない
• ソースコードへのアクセス権限が限定されている
• APIを公開できない、あるいはAPI自体が存在しない
• 外部ソフトウェアやライブラリの追加に厳格な審査が必要
• テストの実施内容と結果に再現性・追跡性が求められる
• 長期間利用されているレガシーアプリケーションが残っている

このような環境では、「どのテストツールが高機能か」だけではなく、

“そのテストツールがシステム内部へどの程度入り込む必要があるのか” が重要な選定条件になります。

T-PlanのSecure Test Automationは、こうした制約を前提として、制御されたインフラストラクチャや制限ネットワーク内でも利用できるテスト自動化を想定しています。

非侵入型テストという考え方

ここで重要になるのが、**Non-Intrusive（非侵入型）**という考え方です。
多くのテスト自動化では、アプリケーション内部のオブジェクト、DOM、API、テスト用インターフェースなどを利用して操作や検証を行います。
一方、T-Plan Robotは、画面上に実際に表示されたGUIを起点として操作・検証するブラックボックス型のテスト自動化を得意としています。

T-Planの公式説明では、画像ベースの自動化によって画面上のGUIやテキスト要素を認識し、マウスやキーボード操作など、ユーザーに近い方法でアプリケーションをテストします。アプリケーション内部のコードがどのように処理されたかではなく、最終的にユーザーへ何が表示されたかを検証する考え方です。

一般的な自動化とT-Plan Robotの違い

一般的な自動化では、
Test Tool → DOM / API / SDK → Application
という経路でシステム内部へアクセスするケースがあります。

それに対してT-Plan Robotでは、
T-Plan Robot → 画面・マウス・キーボード → GUI
というユーザー視点のアプローチを取ることができます。

つまり、「アプリケーション内部を見る」のではなく、「ユーザーが実際に見る画面をテストする」という発想です。

これは、ソースコードを開示できないシステム、APIが存在しないシステム、専用端末、レガシーアプリケーションなどにおいて大きなメリットになります。

T-Plan Robotが高セキュリティ環境に適している5つの理由

1．ソースコードへのアクセスを必要としない

T-Plan Robotは、ユーザーインターフェースレベルでテストを実行できるため、テスト対象アプリケーションのソースコードへアクセスすることを前提としません。ソースコードを外部部門やツールへ公開できないシステムでも、画面を通じてE2Eテストを構築できます。

2．APIに依存しない

レガシーアプリケーションや専用業務システムでは、自動化用APIが存在しないケースも少なくありません。T-Plan公式FAQでも、レガシーアプリケーション、デスクトップソフトウェア、カスタム業務システムを、APIやソースコードへのアクセスなしでUIレベルから自動化できると説明しています。

3．オンプレミス環境で利用できる

クラウドサービスへテスト対象の情報を送信することが難しい場合でも、テスト環境内部で自動化を構築できることは大きな利点です。特に防衛、公共、医療、金融などでは、「テストデータを外に出さない」こと自体が重要な要件になる場合があります。

4．Air-Gapped環境に対応できる

さらに重要なのが、Air-Gapped環境への対応です。

Air-Gappedとは、重要システムを外部ネットワークやインターネットから物理的・論理的に分離した環境を指します。T-Planは、オンプレミスおよびAir-Gapped環境でのテスト自動化をサポートし、インターネット接続やクラウドインフラを必須としない構成を公式に案内しています。

Air-Gapped環境でのT-Plan Robot

セキュリティ境界の内側に、

• T-Plan Robot
• テスト対象アプリケーション
• テストデータ
• スクリーンショット
• テスト結果・レポート

を配置し、外部インターネットへ接続せずにテストを完結させるイメージです。

「クラウドが利用できないからテスト自動化できない」のではなく、“セキュリティ境界の中で完結する自動化方式を選択する”という考え方に変えることができます。

5．ユーザーが実際に見るGUIを検証できる

T-Plan Robotの画像認識型アプローチでは、単に内部処理が成功したかだけでなく、
ユーザーから画面がどのように見えているか
を検証できます。

例えば、

• ボタンやアイコンが正しい位置に表示されているか
• GUI部品が欠落していないか
• 画面レイアウトが崩れていないか
• 正しい画面へ遷移しているか
• 期待するメッセージや状態が表示されているか

といった確認です。

T-Planは画像ベースの自動化について、画面上に表示された結果をユーザー視点から検証でき、レイアウトの重なりや不適切なGUI配置などの問題も検出対象にできると説明しています。

セキュアな自動化で重要なのは「監査性」と「再現性」

---

規制産業における品質保証では、
「テストを実施した」
だけでは十分ではありません。

重要なのは、
いつ、どのテストを、どの条件で実施し、その結果がどうなったのか
を説明できることです。

手作業によるテストでは、担当者によって操作手順や判断基準が微妙に変わる可能性があります。

一方、自動テストでは、同じ手順を同じ条件で繰り返し実行できます。T-PlanはSecure Test Automationのメリットとして、Consistent / Repeatable Test Execution、Audit Readiness、Traceabilityなどを挙げています。

自動テストから監査証跡まで

テスト仕様
↓
自動実行
↓
GUI操作・検証
↓
Pass / Fail判定
↓
スクリーンショット・結果保存
↓
テストレポート
↓
品質保証・監査

という流れを構築することで、Automation（自動化）からEvidence（証跡）までを一貫したプロセスとして考えることができます。

これは、定期的な回帰テストだけでなく、リリース判定、受入テスト、品質監査などにも有効です。

レガシーシステムにも適用しやすい

高セキュリティ環境では、最新のWebアプリケーションだけが利用されているわけではありません。
長期間運用されているWindowsデスクトップアプリケーション、専用業務端末、Java GUI、仮想デスクトップ、製造装置、監視端末などが現在も重要な役割を担っています。

こうしたシステムでは、

「DOMが存在しない」
「自動化用APIがない」
「システムを改修できない」

という問題があります。

画像ベースで画面を認識するブラックボックス方式では、内部技術への依存を抑えながら、画面に表示されるアプリケーションを自動化対象にできます。T-Planも、デスクトップ、Web、モバイルに加えて、レガシーシステムや仮想デスクトップ環境などを対象として挙げています。

複数OSをまたぐクロスプラットフォームテスト

---

高セキュリティ環境でも、1つのOSだけでシステムが完結するとは限りません。
PC、サーバー、タブレット、スマートフォンなど、複数のプラットフォームをまたいでシステムが構成されるケースがあります。
T-Planでは、Windows、Linux、macOS、Android、iOSなどを対象としたクロスプラットフォームの自動化が提供されています。

このメリットがよく分かるのが、T-Plan公式サイトに掲載されている防衛分野の事例です。

防衛分野での実例 ― 5つのOSをまたぐ重要アプリケーションを自動テスト

T-Planの公式事例では、ある防衛分野の組織が、公共衛生情報を扱う重要なCOVID-19関連アプリケーションのテスト自動化にT-Planを採用しています。

このアプリケーションは、

• iOS
• Android
• Windows
• macOS
• Linux

という複数のプラットフォームで動作する必要があり、短期間での展開、品質、安定性に加え、防衛分野としての厳格なセキュリティおよびコンプライアンス要件も求められていました。

T-Planの事例では、クロスプラットフォームでテストを再利用できたことや、導入後短時間でテスト作成・反復実行へ移行できたことが紹介されています。

この事例が示しているのは、単に「テストを速くする」という価値だけではありません。

セキュリティ要求を維持しながら、複数環境にまたがる品質検証を標準化できる という点が重要です。

どのような分野で活用できるのか

Secure Test Automationという考え方は、防衛だけに限定されません。

例えば、次のような分野が考えられます。

分野	想定されるテスト対象
防衛	閉域ネットワーク内の業務・指揮・支援システム
官公庁・公共	専用業務システム、公共サービス端末
医療	医療機器、医療情報システム、院内端末
金融	業務端末、取引システム、レガシーアプリ
製造	製造装置、HMI、検査装置
エネルギー	監視・制御GUI
鉄道・交通	運行管理・監視システム
組込み機器	タッチパネル、専用GUI、各種端末

T-Planの業種別ページでも、防衛、政府・公共、Healthcare & Pharma、Finance、Banking、Energy & Utilities、Railwayなど幅広い分野が紹介されています。

「Secure Test Automation」は「Security Testing」ではない

ここで、言葉の違いを整理しておく必要があります。

Secure Test AutomationとSecurity Testingは同じ意味ではありません。
Security Testingは一般に、脆弱性診断、侵入テスト、認証・権限確認など、システムのセキュリティそのものを評価するテストを指します。

一方、この文脈でのSecure Test Automationは、「セキュリティ制約の厳しい環境において、その環境の管理方針を維持しながらソフトウェアテストを自動化すること」

を意味します。

つまり、
「セキュリティをテストする」
のではなく、

「セキュリティを損なわずにテストを自動化する」
という考え方です。

まとめ ― 「自動化できない環境」ではなく「自動化方法を選ぶ環境」

---

高セキュリティ環境だからといって、テスト自動化を諦める必要はありません。

重要なのは、どのような方法でテスト対象へアクセスするのかです。

ソースコード、API、クラウドサービスへの依存をできるだけ抑え、ユーザーインターフェースからブラックボックスとしてシステムを操作・検証する。

そして、テスト対象、テスト結果、スクリーンショット、レポートなどをセキュリティ境界内部で管理する。

T-Plan Robotの

Non-Intrusive（非侵入型）
On-Premise / Air-Gapped
Visual / UI-Level Testing

という特徴は、防衛、医療、金融、公共、製造、社会インフラなど、セキュリティとソフトウェア品質の両立を求められる環境において、有力なテスト自動化の選択肢となります。

これまで「セキュリティ上の理由から自動化が難しい」と考えていたシステムでも、テスト対象へのアクセス方法を変えることで、自動化できる可能性があります。

Channel Bridgeでは、T-Plan Robotを利用したGUIテスト自動化、ブラックボックステスト、クロスプラットフォームテスト、多言語GUIテストなどについて、国内のお客様向けにご提案・技術支援を行っています。

閉域ネットワーク、オンプレミス環境、レガシーシステム、組込みGUIなどのテスト自動化をご検討の場合は、ぜひChannel Bridgeまでお問い合わせください。