Site Acceptance Testing（一般にSATと略されます）は、機器、ソフトウェア、システム、または統合ソリューションが顧客サイトに設置された後に実施される正式な検証プロセスです。その目的は、納入されたシステムが実際の運用環境で正しく動作し、プロジェクト要件を満たし、関連システムと連携し、引き渡し、運用、または最終承認に進める状態であることを確認することです。

出荷前または展開前に行われる工場試験とは異なり、SATは実際の現場条件に重点を置きます。電源、ネットワーク接続、環境要因、現場配線、ユーザー権限、第三者インターフェース、アラーム、制御ロジック、安全機能、オペレーターの作業手順、文書類は、システムが本当に使われる条件のもとで確認されます。

プロジェクト現場での最終確認が重要な理由

システムが工場検査に合格していても、設置後に問題が発生することがあります。実際の現場には、工場では完全に再現できない変数があるためです。ケーブル長が異なる場合があり、ネットワークルールがより厳しい場合があり、機器室の接地条件が異なる場合があり、オペレーターが別の手順を使う場合があり、第三者システムが試験用シミュレーターとは違う応答をすることもあります。

SATはこの差を埋めるために役立ちます。納入されたソリューションが技術的に完成しているだけでなく、実際の運用で使えるかを構造的に確認できます。プロジェクトオーナーにとっては、後で繰り返し修正が必要になるシステムを受け入れるリスクを下げます。サプライヤーやインテグレーターにとっては、何を試験し、何が合格し、何が不合格で、何を継続対応すべきかを明確に記録できます。

複雑なプロジェクトでは、SATは責任の整理にも役立ちます。機器の欠陥、設置上の問題、設定ミス、インターフェースの問題、文書不足、オペレーター教育の不足、当初範囲外の現場条件を切り分ける助けになります。

工場試験と現場試験の違い

Factory Acceptance Testing、つまりFATは、通常、システムの出荷または納入前に実施されます。管理された試験環境で、製品またはシステムが合意済み要件を満たすかを確認します。サプライヤーは、展開前に入力、出力、ネットワークリンク、オペレーター操作、障害条件を模擬できます。

SATはその後、プロジェクト場所に設置された後で行われます。同じシステムが、実際の電源、実際の現場機器、実際の通信リンク、建物インフラ、顧客ネットワーク、安全システム、制御室の作業手順、エンドユーザー操作とともに正しく動作するかを確認します。

どちらの試験にも価値があります。FATは、不完全または欠陥のあるシステムを出荷する可能性を下げます。SATは、設置後のシステムが顧客の実環境の一部として機能することを確認します。どちらかの段階を省略したプロジェクトは、コミッショニング時のリスクが高くなります。

受け入れプロセスの一般的な進め方

準備と試験計画

プロセスは試験計画から始まります。計画では、何を試験するか、誰が参加するか、どの文書が必要か、どのツールを使うか、どの受け入れ基準を使うか、結果をどのように記録するかを定義します。

良い計画は、契約、技術仕様、設計文書、承認図面、インターフェース要件、安全要件、プロジェクト範囲と結び付いている必要があります。明確な基準がなければ、SATは管理された受け入れプロセスではなく、非公式なデモになりがちです。

現場準備状況の確認

正式な試験を始める前に、チームは現場が準備できているかを確認します。これには、電源の利用可能性、接地、ネットワークアクセス、キャビネット設置、ケーブル終端、環境条件、機器ラベル、ソフトウェアインストール、ライセンス有効化、基本的なシステム起動が含まれる場合があります。

現場が準備できていない場合、正式な受け入れ試験で誤解を招く不合格が出ることがあります。たとえば、通信プラットフォームが不良に見えても、実際の原因はファイアウォールルールの遮断や未完了の配線である場合があります。

機能試験

機能試験では、必要な各機能がプロジェクト仕様どおりに動作することを確認します。通常運用、ユーザーログイン、機器制御、アラーム発報、呼ルーティング、データ表示、レポート生成、信号入力、出力制御、録音、通知、オペレーター操作などが含まれる場合があります。

機能試験は実務的な言葉で書くべきです。各試験は、操作、期待結果、合格または不合格の条件、必要な証拠を記述する必要があります。これにより、結果の確認が容易になり、後日の監査もしやすくなります。

統合試験

多くのシステムは他のシステムに依存しています。建物プラットフォームは、火災報知、入退室管理、CCTV、公共放送、エレベーター、HVAC、ネットワークスイッチ、データベース、第三者ソフトウェアと接続されることがあります。SATでは、これらのインターフェースを実環境で検証しなければなりません。

統合試験では、隠れた問題が表面化しやすくなります。主システム単体では動作し、第三者システム単体でも動作していても、両者のインターフェースがプロトコル不一致、タイミング遅延、アドレス誤り、権限問題、データ形式の違いによって失敗することがあります。

性能と信頼性の確認

プロジェクトによっては、SATに性能試験が含まれることもあります。応答時間、通話品質、スループット、データ更新率、アラーム遅延、フェイルオーバー動作、負荷処理、録音品質、ネットワーク遅延、再起動後のシステム復旧などが対象になる場合があります。

安全、生産、通信、エネルギー、交通、医療、セキュリティ、公共サービスを支えるシステムでは、信頼性確認が重要です。システムはデモで一度動くだけでは不十分で、想定される運用条件で継続的に安定して動作する必要があります。

SATは儀式的な最後の手順ではありません。納入システムが、実際のユーザー、実際のインターフェース、実際の制約の中で、顧客の実環境で運用できることを示す実践的な証拠です。

チェックリストに含まれる代表的な項目

設置品質

チームは、機器が承認図面、現場標準、安全規則、メーカー要件に従って設置されているかを確認します。キャビネット固定、ケーブル配線、ラベル、接地、換気、コネクター保護、物理アクセスなどが確認対象になることがあります。

設置品質は重要です。システムがソフトウェア試験に合格していても、ケーブルの緩み、ラベル不良、不十分な接地、気流の遮断、安全でない取り付けによって、将来の信頼性リスクが残る可能性があるためです。

設定とパラメーターの確認

設定確認では、システム設定がプロジェクト設計と一致していることを確認します。IPアドレス、ユーザー役割、内線番号、アラームしきい値、ルーティングルール、機器名、タイムゾーン、録音ポリシー、保存パス、アクセス権限、バックアップスケジュールなどが含まれます。

設定は文書化する必要があります。後でシステムの交換、復旧、拡張が必要になったとき、記録されていない設定は保守を難しくします。

ユーザー操作

SATでは、実際に使う人にとってシステムが機能するかを確認する必要があります。オペレーターは、ログイン、状態確認、アラーム確認、通話、機器制御、記録のエクスポート、レポート生成、モード切替、緊急手順の実行を行う場合があります。

この段階では、使い勝手の問題がよく見つかります。機能が技術的に存在していても、見つけにくい、表示名が分かりにくい、顧客の作業手順と合わない場合は、追加教育やインターフェース調整が必要になることがあります。

アラームと障害処理

障害とアラームの動作は慎重に試験する必要があります。システムは正しいイベントを検出し、正しいメッセージを表示し、期待される通知を発出し、イベント記録を保存し、障害解除後に正常状態へ戻る必要があります。

アラーム試験は、安全、セキュリティ、産業、医療、交通の環境で特に重要です。誤報、見逃し、優先度の誤り、不明確なイベント説明は、対応品質に影響します。

バックアップと復旧

多くのシステムには、設定バックアップ、データベースバックアップ、ログ保持、冗長電源、フェイルオーバーサーバー、予備機器、復旧手順が必要です。SATでは、バックアップと復元のプロセスが約束どおり機能するかを確認できます。

この部分は、引き渡し時にシステムが正常に見えるため見落とされがちです。しかし、障害、停電、ハードウェア交換、ソフトウェア破損が発生したとき、復旧能力は極めて重要になります。

プロジェクトオーナーとサプライヤーへのメリット

引き渡しリスクの低減

SATは、不完全または不安定なシステムを受け入れる可能性を下げます。プロジェクトオーナーは、最終サインオフ前に必要機能が実演され記録されたことを確認できます。

サプライヤーにとって、SATは引き渡しの明確な根拠になります。口頭確認に頼るのではなく、試験記録、パンチリスト、是正措置、受け入れ署名を提示できます。

現場固有の問題を早期に発見

一部の問題は、システムが実際の場所に設置されてから初めて現れます。ネットワーク制限、ケーブル不良、電源容量不足、互換性のない第三者システム、現場配線ミス、環境干渉、オペレーターの作業手順との不一致などが含まれます。

こうした問題をSAT中に発見することは、システムが日常運用に入った後で見つけるより望ましいです。

チーム間のコミュニケーション改善

受け入れ試験では、プロジェクトオーナー、サプライヤー、インテグレーター、設置業者、オペレーター、ITチーム、安全チーム、保守担当者が集まります。この共同プロセスは、期待事項と責任の明確化に役立ちます。

試験が不合格になった場合、チームは問題が設定、設置、設計、現場インフラ、第三者インターフェース、ユーザー教育のどれに属するかを判断できます。これにより責任の押し付けが減り、問題解決が進みます。

文書化とコンプライアンスの支援

試験記録、報告書、チェックリスト、設定ファイル、図面、受け入れフォームはプロジェクト文書の一部になります。これらの記録は、監査、保証請求、将来の保守、規制検査、システム拡張を支援できます。

規制環境では、文書化された受け入れは試験そのものと同じくらい重要な場合があります。引き渡し時に、定義済み要件に照らしてシステムを確認したことを証明するためです。

保守の基準値を作成

受け入れ後、SAT結果は基準値として使えます。後でシステムの挙動が変わった場合、保守チームは現在の性能を最初の試験記録と比較できます。

これは、トラブルシューティング、バージョンアップ、ハードウェア交換、ソフトウェアパッチ、将来の拡張に役立ちます。

さまざまなプロジェクトでの用途

産業オートメーション

産業プロジェクトでは、PLCシステム、SCADAプラットフォーム、センサー、ドライブ、制御盤、安全インターロック、アラーム、操作パネル、生産ライン機能を確認するためにSATが使われます。試験により、システムが実際の現場機器とプロセス条件で動作することを確認します。

産業上の故障は生産と安全に影響するため、SATには通常運転、異常条件、手動制御、非常停止動作、アラーム処理、データ記録を含めるべきです。

通信およびネットワークシステム

通信プロジェクトでは、サーバー、ゲートウェイ、IP PBXプラットフォーム、ルーター、スイッチ、録音システム、ディスパッチシステム、SIPトランク、アクセス機器、監視ツールを確認するためにSATが使われます。チームは接続性、ルーティング、品質、フェイルオーバー、管理機能を確認します。

ネットワークベースのシステムは、実際のIPアドレス、VLAN、ファイアウォールルール、QoS設定、リモートアクセス方針、ユーザーアカウントで試験するべきで、実験室設定だけに依存すべきではありません。

ビル管理とセキュリティ

建物プロジェクトでは、入退室管理、CCTV、火災報知インターフェース、公共放送、インターホン、エレベーター、HVAC制御、照明制御、統合管理プラットフォームにSATが使われます。目的は、別々のサブシステムが連携して動作することを確認することです。

統合は特に重要です。たとえば、火災警報は、ドア解放、カメラポップアップ、公共放送、制御室でのイベント記録を同時に起動する必要がある場合があります。

医療および研究室システム

病院、診療所、研究室、クリーンルーム環境では、通信システム、監視機器、入退室管理、環境システム、医療支援インフラ、データプラットフォームにSATが必要になる場合があります。

試験では、安全性、プライバシー、正確性、トレーサビリティ、ユーザー役割、サービス継続性を考慮する必要があります。これらの環境では、文書品質が非常に重要になることがよくあります。

エネルギーと公益インフラ

発電所、変電所、水処理施設、石油・ガス現場、再生可能エネルギープロジェクトでは、監視、制御、通信、安全、計量、アラーム機能を確認するためにSATが使われます。

これらの現場では、冗長性、接地、サージ保護、環境条件、サイバーセキュリティ、緊急対応手順について追加確認が必要になる場合があります。

試験中によく見つかる問題

未完了の設置

一部の不合格は製品欠陥ではなく、設置未完了によって発生します。ケーブル不足、ラベル誤り、端子の緩み、未接続の接地、キャビネット配線の未完了、ライセンス不足はいずれも試験不合格の原因になります。

顧客立会い試験を始める前に事前SAT準備確認を行うことで、こうした問題を減らせます。

設定不一致

設定ミスはよくあります。IPアドレス、ユーザー権限、アラームしきい値、ルーティングルール、機器ID、時刻設定、データベース接続、プロトコルパラメーターが承認済み設計と一致しないことがあります。

これらのミスは短時間で修正できる場合が多いですが、最終設定を追跡できるよう、記録しておく必要があります。

インターフェース障害

第三者インターフェースは、プロトコル差異、ファイアウォール遮断、認証情報不足、バージョン不一致、データマッピング誤り、API設定不足によって失敗することがあります。

インターフェース試験には、接続の両側が参加する必要があります。一方のシステムがデータを送信するだけでは不十分で、受信側システムが正しく処理できなければなりません。

不明確な受け入れ基準

試験計画が合格条件と不合格条件を定義していない場合、争いが起きることがあります。一方はシステムを受け入れ可能と考え、もう一方はより高い性能や異なる作業手順を期待する場合があります。

明確な基準は、試験開始前に合意しておくべきです。これにより、引き渡し時の主観的判断を防げます。

不十分なユーザー教育

システムは動作していても、ユーザーが操作方法を知らないことがあります。受け入れ試験では、これが技術的故障のように見える場合があります。

教育、クイックリファレンスガイド、役割別の操作手順は、最終引き渡し前に含めるべきです。

SATの不合格の多くは、機器の故障が原因ではありません。未完了の設置、不明確な範囲、弱い文書化、不十分なインターフェース計画、未検証の実作業手順から生じます。

円滑な引き渡しのためのベストプラクティス

チェックリストは早めに準備します。SATチェックリストを最後の瞬間に作成すべきではありません。契約要件、技術仕様、承認図面、ユーザー作業手順、プロジェクトリスクポイントに基づいて作成する必要があります。

適切な人を招集します。試験には、サプライヤー、設置業者、顧客、エンドユーザーチーム、IT部門、安全チーム、保守チームの代表を必要に応じて含めるべきです。関係者が不足すると、重要な確認を後で繰り返す必要があり、受け入れが遅れる可能性があります。

証拠を記録します。スクリーンショット、写真、ログ、エクスポートされたレポート、測定記録、通話記録、アラーム記録、署名済みフォームは、試験完了を証明する助けになります。

パンチリストを使います。小さな問題が残る場合は、担当者、優先度、是正措置、目標完了日を明確に記録します。これにより、未完了事項を追跡しながらプロジェクトを前進させることができます。

ネガティブテストを無視しないでください。通常運用が動くことを証明するだけでは不十分です。必要に応じて、障害アラーム、無効入力、停電、通信断、フェイルオーバー、復旧動作も試験する必要があります。

最終報告書に含めるべき内容

最終報告書には、プロジェクト名、システム範囲、試験日、参加者、試験環境、参照文書、チェックリスト結果、合格項目、不合格項目、是正措置、写真またはログ、設定記録、受け入れ署名を含める必要があります。

逸脱がある場合は文書化する必要があります。逸脱は顧客が受け入れる場合もあり、引き渡し前に修正される場合もあり、後で完了するパンチリストに追加される場合もあります。重要なのは、隠れたまま、または曖昧なままにしないことです。

報告書にはバージョン情報も含めるべきです。ソフトウェアバージョン、ファームウェアバージョン、データベースバージョン、図面改訂、設定バックアップ日付は、将来の保守に役立ちます。

FAQ

すべての現場作業が完了する前にSATを実施できますか？

一部実施することは可能ですが、最終受け入れは通常、必要な設置、配線、設定、インターフェース、運用条件が整うまで待つべきです。そうしないと、試験結果が実際のシステムを反映しない可能性があります。

受け入れ報告書には誰が署名すべきですか？

署名者はプロジェクトによって異なりますが、多くの場合、サプライヤーまたはインテグレーター、顧客代表、プロジェクトマネージャー、エンドユーザー側責任者、場合によっては保守、安全、品質の代表が含まれます。

試験項目が不合格になった場合はどうなりますか？

不合格は、原因、責任者、是正措置、優先度、再試験要件とともに記録する必要があります。重大な不合格は通常、受け入れ前に修正が必要であり、軽微な問題は顧客が同意すればパンチリストに追加できます。

ソフトウェアのみのプロジェクトにもSATは必要ですか？

はい、必要になる場合があります。顧客サイトまたはクラウド環境に展開されるソフトウェアでも、設定、ユーザー役割、統合、性能、セキュリティ、レポート、運用手順について現場受け入れ試験が必要になることがあります。

試験開始前に準備すべき文書は何ですか？

有用な文書には、承認済み技術仕様、システム図面、ネットワーク計画、I/Oリスト、設定シート、ユーザーアカウント一覧、試験チェックリスト、操作マニュアル、保守ガイド、利用可能な場合は前回のFAT報告書が含まれます。