装置ソフト開発を外注する方法｜タイ工場の受入設計2026

タイで装置ソフト開発を外注するとき、成否を分けるのはプログラム言語やPLCメーカーの選択だけではありません。重要なのは、装置がどの状態をたどり、異常時にどこまで戻り、上位システムや安全回路との境界で何を保証し、FAT・SATで何を証拠として残すかを、発注前に合意することです。本稿では、PLCソフトウェア設計、状態遷移設計、制御ソフト外注、ログ・時刻、版管理、シミュレーション、FAT/SAT、ソースコード・ライセンス・保守引渡しを一つの調達設計として整理します。PLCの命令解説、HMI画面の一般論、制御盤の電気設計、ロボット本体の選び方は繰り返さず、相互インターフェースと受入証拠に焦点を当てます。

先に結論：装置ソフト開発は「動作」ではなく「証明可能な仕様」を買う

装置が自動運転する動画だけでは、量産後に安心して保守できるか判断できません。発注時に最低限そろえるべきなのは、次の八つです。

1. 運転状態と状態遷移の一覧
2. 異常ごとの検出条件、停止挙動、復帰条件
3. 安全機能と通常制御の責任境界
4. PLC・ロボット・HMI・MES等のインターフェース契約
5. ログ項目、時刻基準、保存・抽出方法
6. ソース、設定、ライブラリを結び付ける版管理方法
7. シミュレーション、FAT、SATの試験項目と合否証拠
8. ソースコード、開発環境、ライセンス、保守情報の引渡し条件

この八つをRFPと受入計画に落とせば、「一応動くが直せない」「異常復帰でワークを壊す」「現地で最新版が分からない」「外注先が変わると保守不能」といった問題を減らせます。見積金額を比べる前に、各社が同じ成果物と同じ試験範囲を見積もっているかをそろえることが先です。

装置制御ソフトの外注で起きる五つの認識ずれ

1. 発注側の「自動運転」と受注側の「正常サイクル」が違う

発注側は、材料切れ、二度押し、通信断、非常停止、瞬時停電、途中品の再開まで含めて自動運転と考えます。一方、見積側が正常条件の一巡だけを想定していると、異常復帰は現地追加になります。そこで「正常サイクル」と「生産として成立する運用範囲」を分け、後者に含める例外を列挙します。

2. I/Oリストがあっても振る舞いが決まっていない

センサー名とアクチュエータ名だけでは、オン遅延、チャタリング、相互排他、タイムアウト、再試行、手動操作時の条件は決まりません。I/Oリストは必要ですが、それだけを装置制御ソフトの仕様書にしてはいけません。

3. 「安全は制御盤側」で責任が消える

非常停止やガードインターロックのハードウェア設計を別会社が担当しても、通常制御は安全状態を認識し、再起動を抑止し、意図しない自動再開を避ける必要があります。安全機能の設計責任と、通常制御が受け取る安全状態・リセット許可・再始動条件を切り分けます。

4. FAT合格と量産可能を同義にする

FATは供給者環境での受入、SATは据付先での受入です。実ワーク、実ネットワーク、工場の時刻同期、上位連携、ユーティリティ変動、現地権限など、現場でしか確かめられない条件があります。両者の試験責任と持越し条件を先に決めます。

5. ソースコード引渡しを「ファイルをもらうこと」と考える

プロジェクトファイルが開けても、IDE版、ライブラリ版、デバイス記述、ライセンス、パスワード、ビルド手順が無ければ再現できません。引渡しのゴールは「第三者が承認済み版を再現し、差分を説明し、バックアップから復旧できること」です。

要件定義の出発点は「境界表」

最初に機能一覧を増やすより、誰がどこまで作り、どの信号を境界とするかを一枚で決める方が効果的です。

境界表には、信号名だけでなく、所有者、送信条件、受信側の確認、タイムアウト時の動作、再送可否、初期値、電源再投入後の扱いを記載します。HMIとの詳細はタイ工場のHMI画面開発、盤と安全回路を含む電気側の整理は制御盤設計の実務を参照し、本稿のRFPでは接続点と受入条件を中心にします。

状態遷移設計：正常・停止・異常・復帰を同じ地図に載せる

IEC 61131-3:2025は、プログラマブルコントローラ向けのST、LD、FBDの構文・意味と、プログラムやファンクションブロックの内部構造化に使うSFC要素などを規定しています。どの表現を採用する場合も、発注仕様では「言語名」だけでなく、装置の状態モデルと遷移条件を確認できる形にすることが重要です。

状態名は運転員が理解できる言葉にする

最低でも、電源投入、初期確認、原点復帰、待機、準備、実行、正常停止、停止中、異常停止、復帰確認、保守を区別します。状態名とHMI表示、ログの状態コード、プログラム内部の列挙値を対応させれば、現場と開発者が同じ言葉で話せます。

各遷移には四つの条件を書く

遷移ごとに、開始条件、成立条件、タイムアウト、失敗時の移行先を書きます。例えば「搬送開始」は、下流準備、ワーク有無、軸原点、安全許可が開始条件です。到着センサーだけを成立条件にせず、クランプ状態や識別結果も必要かを決めます。タイムアウト後に単純停止するのか、安全な位置へ退避するのか、再試行を許すのかも明示します。

異常復帰は「リセットで消える」ではなく作業手順で定義する

アラームの解除条件、残留エネルギー、途中ワークの扱い、再投入部品、品質判定、再開点を決めます。復帰後に直前ステップから再開すると二重加工になる工程もあれば、全排出すると材料損失が大きい工程もあります。機械状態と製品状態を別々に評価し、誰がどの確認をしたら再開できるかを決めます。

電源断と通信断は独立した状態として試験する

瞬時停止や長時間停止後、保持変数、軸位置、実績送信、処理中IDがどうなるかを定義します。MESへ送った実績の応答前に電源が落ちた場合、再送で二重計上しない仕組みが必要です。通信断中の自律運転範囲も「何個まで」などの根拠のない固定値ではなく、ローカルに保持できる指図・レシピ・結果の設計と品質リスクから決めます。

異常復帰マトリクスをRFPの中心に置く

制御ソフト外注で差が出るのは、通常運転より例外処理です。異常一覧はアラーム番号表ではなく、復帰マトリクスにします。

この表の一行を一つ以上のテストケースへ変換します。「全アラームを試験する」とだけ書くより、入力条件と期待結果が明確になり、見積時点でテスト工数も比較しやすくなります。

安全境界：通常PLCに安全機能を曖昧に背負わせない

ISO 13849-1:2023は、安全機能を実行する制御システムの安全関連部（SRP/CS）の設計・統合について、ソフトウェア設計を含む方法論と要求・推奨・ガイダンスを扱います。一方、同規格の公開要約は、個別用途で使う安全機能や要求パフォーマンスレベルそのものを指定しないと説明しています。したがって「ISO 13849-1対応」と一行書くだけでは、対象機械の安全機能は決まりません。

装置ソフトのRFPでは、リスクアセスメントと適用規格を別途確認したうえで、少なくとも次を分離します。

• 安全機能を担う回路・安全PLC・機器の範囲
• 通常PLCが参照できる安全状態と診断情報
• 安全リセットと通常アラームリセットの違い
• 安全復帰後も自動再始動させない条件
• 手動・保守モードで許される動作と速度・範囲
• 安全機能の妥当性確認資料を誰が作成・承認するか

ロボットセルとの境界を含む場合は、産業用ロボット導入とISO 10218の実務と接続し、ロボット導入一般を再説明するのではなく、セル安全状態、PLCハンドシェイク、復帰順序の受入証拠を本案件の成果物にします。

インターフェース契約：タグ一覧から時系列仕様へ

PLCソフトウェア設計では、タグ一覧だけでなく時系列を合意します。起動要求を出したあと、相手が受付、実行中、完了をどの順で返すか。要求が途中で落ちたら中断か継続か。完了を確認する前に次の要求を出してよいか。相手の再起動時に古い完了信号をどう無効化するか。これをタイムチャートまたはシーケンス図で表します。

データ連携には、次のフィールドをインターフェース管理表へ入れます。

通信プロトコル名だけで品質は保証されません。境界の両側で同じテストデータを使い、送信値、受信値、装置動作、保存結果を一つのケースとして採取します。

ログと時刻：トラブルを再現できる粒度を決める

ログは「たくさん保存する」ほど良いわけではありません。必要なのは、装置状態、操作、異常、通信、版、対象ワークを同じ時間軸で追えることです。

最小ログモデル

• 発生時刻と時刻源の状態
• 装置・ステーション・ユニット識別子
• 状態遷移前後
• 操作ユーザーまたは権限ロール
• アラーム発生・確認・解除
• 主要な要求・応答と相関ID
• レシピ名と版、ソフト版、設定版
• ワークIDまたは追跡可能な製造単位
• 結果と理由コード

PLC時刻、IPC時刻、ロボット時刻、サーバー時刻がずれると、原因順序を誤ります。時刻同期源、同期喪失時の表示、UTCと現地時刻の保管方針を決め、FAT/SATでは意図的に時刻同期を外したときの診断も確認します。保持期間は一律に決めず、障害調査、品質記録、ストレージ、個人情報、顧客要求を基に決定します。

版管理：ソース、設定、レシピ、実機を一本の基線で結ぶ

「プログラム最新版.zip」を共有フォルダへ置く方法では、実機とソースの一致を証明できません。最低でも次の単位に版を付けます。

• PLC、HMI、ロボット、IPCのソース
• コンパイラ/IDEと必要な追加パッケージ
• 外部ライブラリとライセンス
• ハードウェア構成・デバイス記述
• I/O・ネットワーク・安全境界の設定
• レシピ・パラメータの初期値
• FAT承認版、SAT承認版、量産承認版

変更要求には、目的、影響、変更ファイル、試験範囲、ロールバック方法、承認者を紐付けます。PLCopenは産業制御ソフト向けにコーディング規約、ライブラリ構成、SFCの構造化などのガイドラインを公開し、2023年にはソフトウェア品質メトリクスのガイドラインも公開しています。これらを「特定の数値基準を満たせば品質」と短絡せず、命名、構造、複雑性、再利用、レビュー観点を案件のコーディング標準へ具体化します。

IEC 61131-3:2025ではUTF-8文字列と関連機能が追加されたこともIECの公開説明に示されています。多言語メッセージやレシピ名を扱う案件では、PLCランタイム、HMI、通信先、CSV/DBまで同じ文字コードで往復できるかを実機で確認します。規格版が新しいから既存機種が自動的に対応する、とは見なさないことが大切です。

シミュレーション：実機完成前に仕様の穴を出す

シミュレーションの目的は、実機を美しく再現することではなく、状態遷移、インターフェース、例外処理を早く試すことです。対象を三層に分けると見積しやすくなります。

正常ケースだけでなく、センサーが成立しない、応答が遅れる、重複メッセージが来る、順序が逆転する、設定値が範囲外になるケースを含めます。シミュレーションで合格しても機械的干渉や実配線ノイズは保証できないため、FAT/SATの代替にはしません。反対に、実機でしか試せないものを除けば、現地デバッグの前倒しになります。

FAT・SATソフトウェア受入：試験票を「証拠パッケージ」にする

FATで確認する範囲

FATでは、承認済みI/O、状態遷移、主要サイクル、異常復帰、権限、アラーム、通信、ログ、バックアップ・復元を確認します。実ワークが使えない項目は、代替条件とSAT持越し理由を記録します。試験ごとに前提版を固定し、途中修正した場合は影響ケースを再実施します。

SATで確認する範囲

SATでは、据付後の実配線、ネットワーク、上位システム、実ワーク、工場時刻同期、ユーザー権限、周辺装置、現地ユーティリティを使います。FAT合格項目をすべて繰り返す必要はありませんが、輸送・据付・設定変更の影響がある項目は再確認します。

受入証拠の形

「動画がある」「画面を見た」だけでなく、どの版のどのケースかを追跡できることが重要です。FAT/SATソフトウェアの合否基準は、サイクルタイムのような性能だけでなく、復帰可能性、ログ完全性、版再現性も含めます。

セキュアな開発・保守を契約に反映する

IEC 62443-4-1:2018の公開説明は、IACS向け製品のセキュア開発ライフサイクルとして、セキュリティ要求、セキュア設計・実装、検証と妥当性確認、欠陥管理、パッチ管理、製品終了などを扱うとしています。ただし同説明は、同規格の要求が製品の開発者・保守者に適用され、インテグレーターや利用者には適用されないとも明記しています。個別装置の外注先へそのまま認証要求を投げるのではなく、契約上必要なプロセスへ翻訳します。

• リモート接続の申請、認証、記録、終了方法
• 開発用アカウントと量産用アカウントの分離
• 既定パスワードや一時アカウントの撤去確認
• 依存ライブラリと既知脆弱性の連絡窓口
• セキュリティ欠陥の優先度、回避策、修正版の提供方法
• パッチ前評価、バックアップ、ロールバック、再試験
• 製品・部品・開発環境の終了通知

ISAの公開説明はISA/IEC 62443シリーズを、IACSのセキュリティを実装・維持するための要求とプロセスを扱い、資産所有者、製品供給者、インテグレーター、サービス供給者の共有責任を重視する体系として紹介しています。発注者も資産・アカウント・バックアップ・変更承認の責任を持ち、供給者だけへ丸投げしない体制が必要です。

ソースコード・ライセンス・保守引渡しの受入条件

引渡し物はファイル一覧ではなく、「再現テスト」で確認します。

ソースコード引渡しでは、知的財産権、再利用ライブラリ、第三者コンポーネント、改変権、別会社への保守委託可否を契約で区別します。「ソースを納品」と「著作権を譲渡」は同じではありません。秘密鍵や個人アカウントの認証情報をソースへ含めず、工場が管理する保管庫へ移管する条件も決めます。

装置ソフト開発の費用は金額ではなく工数ドライバで比較する

仕様が無い段階で固定金額を断定すると、前提差を隠します。見積は次の構造へ分解します。

• 状態・ステーション・軸・装置点数と並行動作
• 品種、レシピ、段取り替え、トレーサビリティの複雑さ
• ロボット、検査、MES等の接続数と相手仕様の成熟度
• 異常シナリオ、復帰方式、手動・保守モード
• 安全関連の責任範囲と妥当性確認支援
• ログ、監査、ユーザー権限、多言語
• シミュレーション範囲、FAT/SATケース数、実ワーク準備
• 現地立上げの時間帯、休日、通訳、移動、待機条件
• ソース、ライセンス、文書、教育、保証、保守の範囲
• 既存設備の解析と不明仕様に対するリスク枠

各項目について、含む/含まない、発注者支給、前提未成立時の変更方法を記載します。単価や総額だけでなく、レビュー、テスト、文書化、引渡しに配分された工数を比較すれば、安い理由と高い理由を説明できます。

タイ工場での進め方：現地条件を受入設計へ入れる

BOI/OSOSが2026年7月に公表した情報では、2026年上期の機械・自動化・ロボティクス分野の投資申請は82件、約131億バーツ、Smart and Sustainable Industryの下で機械更新・デジタル技術・自動化/ロボット統合を行う申請は132件、約172億バーツと報告されています。これは個別案件の採算や補助対象を保証する数字ではありませんが、タイ製造業で自動化投資が継続している背景を示します。

BOIの自動車産業向け自動化措置ページには、機械と統合して製造を操作・制御・支援するソフトウェア等の費用の扱いが説明されていますが、同じページには2025年末の申請期限も記載されています。その期限を過ぎた制度を2026年の現行優遇として扱ってはいけません。適用可能性は、最新のBOI告示、対象事業、申請時期、認定条件をBOIまたは専門家へ案件ごとに確認してください。

実務では、日本側の設備仕様、タイ現場の運転・保全、ローカルSI、装置メーカー、IT/MES担当が同じ受入票を見る体制を作ります。仕様の正本言語、通訳責任、単位、日時表記、祝日・夜間作業、予備品、リモート接続承認をキックオフで固定します。

外注先の選び方：デモより質問への答え方を見る

候補会社へ同じ異常シナリオを渡し、設計・試験・引渡しの考え方を比較します。

1. 状態遷移をどの成果物でレビューするか
2. 正常運転以外の見積範囲をどう数えるか
3. 安全制御との境界を誰と合意するか
4. インターフェース変更をどう管理するか
5. シミュレーションできる範囲と限界は何か
6. FAT/SATの証拠をどの形式で残すか
7. 実機とソースの版一致をどう確認するか
8. 標準ライブラリの権利と保守条件は何か
9. 担当者交代時に再現できる文書は何か
10. 不具合・脆弱性・EOLを誰へ連絡するか

良い回答は「できます」ではなく、前提、成果物、例外、試験方法を示します。実装能力に加え、未決事項を早く見つけ、発注者へ選択肢を返せることが重要です。

そのまま使えるRFPチェックリスト

要件・設計

• [ ] 対象設備、除外範囲、責任分界がある
• [ ] 状態一覧、遷移条件、タイムアウトがある
• [ ] 異常検出、停止、復帰、途中品処置がある
• [ ] 手動、保守、段取り、権限がある
• [ ] 安全機能と通常制御の境界がある
• [ ] 全インターフェースの所有者と時系列がある
• [ ] ログ、時刻同期、保持、抽出条件がある

開発・試験

• [ ] コーディング規約、レビュー、版管理がある
• [ ] シミュレーション範囲とテストデータがある
• [ ] FAT/SATのケース、設備、実ワーク、責任がある
• [ ] 不適合、変更、再試験、条件付き合格の手順がある
• [ ] セキュア開発・リモート保守の最低条件がある

引渡し・保守

• [ ] ソース、設定、開発環境、ライセンス一覧がある
• [ ] 承認版の再現・バックアップ復元試験がある
• [ ] 知財、改変、第三者保守、秘密情報の条件がある
• [ ] 教育、保証、障害切分け、EOL通知がある
• [ ] 未解決事項と量産後の改善窓口がある

FAQ：装置制御ソフト外注でよくある質問

装置ソフト開発の要件定義は何から始めればよいですか？

設備の機能一覧より先に、責任境界、運転状態、異常復帰、外部インターフェースを整理してください。その後、各状態・境界を受入テストへ変換します。既存設備なら、現行ソースの有無、実機版、停止可能時間、再現できない仕様も明記します。

PLCソフトウェア設計でIEC 61131-3準拠と書けば十分ですか？

十分ではありません。IEC 61131-3は言語の構文・意味や構造化要素などの共通基盤を与えますが、案件固有の状態、異常復帰、命名、ライブラリ、レビュー、テスト、ハードウェア対応版は別途決める必要があります。

状態遷移設計は小さな装置にも必要ですか？

必要な粒度は規模で変わりますが、小さな装置でも電源投入、待機、実行、停止、異常、復帰は存在します。図を大きくする必要はなく、表でも構いません。重要なのは、暗黙の復帰条件をテスト可能にすることです。

制御ソフト外注の費用はどう比較すればよいですか？

総額だけでなく、状態・例外・接続・試験・現地対応・文書・引渡し・保守の工数ドライバで比較します。発注者支給条件と除外範囲をそろえ、未確定仕様が変更見積になる基準も確認してください。

FATとSATのソフトウェア試験はどう分けますか？

供給者環境で再現できるロジック、状態、異常、通信、ログ、復元はFATで前倒しし、実配線、実ワーク、工場ネットワーク、上位本番環境、時刻同期、据付影響はSATで確認します。どちらも版情報と証拠を残します。

ソースコード引渡しで確認すべきものは何ですか？

ソース本体に加え、IDE版、パッチ、デバイス定義、依存ライブラリ、ライセンス、ビルド/ダウンロード手順、設定、パスワード移管、変更履歴が必要です。クリーン環境で開けることと、承認済み実機版との一致を受入条件にします。

安全機能と通常PLCの境界はどう決めますか？

リスクアセスメントと適用規格に基づき、安全機能を担う範囲を設計したうえで、通常PLCが参照する安全状態、リセット、再始動許可、診断のインターフェースを定義します。個別の安全機能や要求性能を汎用記事だけで決めず、機械安全の有資格者と確認してください。

まとめ：受入証拠から逆算すれば、装置ソフト開発は保守可能になる

装置ソフト開発の外注では、正常サイクルの実装だけでなく、状態遷移、異常復帰、安全境界、インターフェース、ログと時刻、版管理、シミュレーション、FAT/SAT、ソース・ライセンス・保守引渡しを一つの調達範囲にします。RFPの各要求を試験ケースと証拠へ結び付け、最終的に第三者が承認版を再現できる状態を受け入れることが、長期停止リスクと属人化を抑える近道です。

タイ工場での装置制御ソフト外注を検討中で、まだ仕様が状態図や試験票になっていない段階でも、TOMAS TECHは責任境界、RFP、FAT/SAT、引渡し条件の整理からご相談いただけます。お問い合わせページから、対象設備と現在分かっている範囲をお知らせください。

参考情報

• IEC 61131-3:2025
• ISO 13849-1:2023
• IEC 62443-4-1:2018
• ISA/IEC 62443シリーズ概要
• PLCopen Software Construction Guidelines
• PLCopen Guideline on Software Quality Metrics
• Thailand BOI: Investment Promotion Measure to Upgrade Automotive Industry
• Thailand BOI/OSOS: 1H 2026 Investment Update