2026.03.01
既存資産を活用した生産系システムの長時間稼働テスト自動化
～製造業DX・現場改善事例～
はじめに：システムと事例の概略
弊社は創業35年以上、福岡で製造業・自治体向けに継続的にスクラッチ開発を行っており、現場業務に密着したシステム設計・保守運用を強みとしています。
筆者の所属している第二システム部（以下、2S）は、地場企業様の生産現場で使用するシステムを上流工程から下流工程まで弊社が担当し、フルスクラッチでの受託開発や開発したシステムの保守を行っています。
弊社が保守を行っているシステムは、主に.NET FrameworkとSQL Serverを基盤とし、パッケージソフトでは難しいユーザー様の生産現場に特化したものです。
先達の活躍もあり、システムは安定稼働にたどり着き、今では企業様の生産現場で無くてはならないシステムとして、ユーザー様にご周知いただいています。
今回は、そのようなシステムのサーバー移行時に発生した、既存資産を活用して行ったテストの自動化についての事例を紹介します。
システム概略
背景：サーバー老朽化とクラウド移行
システムの利用が浸透していけば現場から要望も出てくるため、大小さまざまな改修を月々行っています。更にシステムの利用期間が長くなれば避けて通れないのが
・サーバーの老朽化
・端末の老朽化
・端末のOSなどの定期的なバージョンアップ（Office製品なども含む）
あたりではないでしょうか。
ユーザー様の現場でも、例に漏れずサーバーの老朽化の問題が顕在化してしまいました。
既存クラウドサーバーのDC閉鎖
発端は、クラウドサーバーの提供元から施設の老朽化に伴うデータセンター閉鎖の連絡がユーザー様にあったことです。
OSのサポート期間切れは延長サポートという手段もありますが、データセンターの閉鎖は回避する手段なく、期日までにサーバーを移設するのみです。
ユーザー様が協議した結果、サーバーの移行先はAWS EC2（Amazon Elastic Compute Cloud）を採用し、既存構成を維持しながら段階的に移設を進めました。
AWS EC2を採用した理由は、WEBシステムやバッチ処理、クライアントモジュール配布の仕組みまで含めて再構築するとなると膨大な工数が発生すると判断したためです。
既存構成を維持できるEC2を選択することで、改修範囲を抑える方針としました。
避けられない問題：動作検証
私が保守しているシステムは生産現場で稼働しています。
システムが停止すると生産に影響があるため、AWSサーバーでの稼働検証は必須でした。
レスポンスはもちろんですが、次の2点が特に重要でした。
１．FTP接続によるプログラムの自動更新
２．連続稼働時間
FTP接続によるプログラムの自動更新
生産現場には数百台のPCがあり、そのすべてに更新パッチを配布して切り替え作業をするのは大変な作業です。
そのため、このシステムには、FTP接続によるプログラム自動更新機構を備えています。
動作確認は本番環境と同じPCで何度も行いました。
最大の課題：8時間連続稼働検証
一番の課題は、実運用と同じようにシステムを連続8時間稼働して問題がないかどうかを検証する方法です。
現場には生産工程が複数あります。
理想は「8時間×生産工程分」の動作検証。
工数の大きさは明白で、私たちのチームには、開始前から戦意喪失感が漂っていました。
解決策の模索：RPAではなく既存資産へ
最初に思いつくのはRPAなどの自動操作アプリです。
しかしユーザー様環境での導入となると、ライセンス費用や承認プロセスの問題が出てきます。
どちらを取るべきか悩んでいるときに、弊社が別システムで作成した「画面操作を行うプログラム」があったことを思い出しました。
このプログラムは、対象プロセスを捕捉し、画面のボタンを見つけてマウスクリック or キーボード操作を行うという簡単なものです。
既存資産としてソースコードも揃っており、自動操作に必要そうな処理は含まれていました。
既存資産の再活用による自動化
プロジェクトメンバーに相談し、既存資産のソースコードを活用して、必要な操作を自動で行うプログラムに改修しました。
外部公開ツールではなく、クライアント様管理下のソースコードを活用しているため、セキュリティ面でも問題はありません。
Visual Studioで既存ソースを組み合わせ、CSVを読み込む処理を追加してコンパイルすれば完成です。
CSV定義型の自動操作
自動操作については、次のような内容を一動作の定義としてCSVファイルに記述します。
・対象のプロセスを指定
・対象オブジェクトを指定
・キーボード入力 or マウスクリック
・前後の待ち時間
これにより、ソフトを導入せずに自動操作を行うことが可能になりました。
本番投入前には検証環境で十分なテストを行い、誤動作リスクを最小化しています。
CSVファイルの定義例
8時間連続稼働の実現と効果
既存資産の改修と8時間分のCSV定義ファイル作成という作業は発生しましたが、手動検証と比べると格段に効率的でした。
・出勤時に自動操作スタート
・日中に問題なく動作していることを適宜確認
・退勤前にログをチェック
これで8時間連続稼働の検証が完了です。
実際の検証では、複数工程を並行実行しても大きな問題は発生せず、当初1～2ヵ月を想定していた検証期間は2週間に短縮されました。
手作業では避けられない並行作業が発生し、作業遅延が発生する前提でしたが、自動化したことで遅延を最小化することができました。
この自動化により、他の作業に人員を割くことが可能になり、結果としてプロジェクト全体の品質向上にも寄与しました。
まとめ：無理なく改善するDX
クラウド移行時に、
・長時間稼働検証の方法が確立できていない
・RPA導入コストに悩んでいる
・過去資産を活かせていない
といった課題をお持ちの企業様は少なくありません。
AWSサーバー移設をきっかけに、スクラッチ開発で発生した既存資産を活用し、効率化と品質を実現した事例は、「現場の課題を正確に把握し、既存資産を活かしながら無理なく改善するDX」の好例です。
パッケージ導入だけでなく、現場に最適化された改善をお求めの製造業の皆さまへ
XSEEDSでは無料の事例資料と、個別相談を承っています。