装置ソフト開発2026｜5階層で分けると発注先と費用が変わる

装置ソフト開発を外注したいのですが、いくらぐらいですか。この問い合わせに金額で答えられたことがありません。装置に載るソフトが1種類ではないからです。シーケンス、モーション、ビジョン、操作画面、上位への受け渡し。この5つは要求される技術も、作れる会社も、変更の頻度も違います。1つの見積書に「制御ソフト一式」とまとめられた瞬間、比較も検収も効かなくなります。本記事では装置のソフトを5階層に分け、どこで責任が割れ、どこに費用が乗るのかを整理します。

装置ソフト開発の見積が1枚に収まらない理由

まず、なぜ「一式」で発注すると後で困るのかを押さえます。ここを飛ばすと、以降の話が単なる分類の遊びに見えてしまいます。

「制御ソフト一式」は比較できない見積になる

装置の引き合いで受け取る見積書に、ソフトウェアの費用が1行だけ書かれていることがあります。他社の見積にも同じように1行だけある。金額を並べれば比較できたように見えますが、実際には何も比較できていません。

その1行の中に、シーケンス制御しか入っていない会社と、画像判定の作り込みまで入っている会社と、上位システムへのデータ送信まで含んでいる会社が混ざっているためです。範囲が違うものを金額で並べれば、範囲の狭い見積が最も魅力的に見えます。そして立ち上げの終盤で、含まれていなかった部分が追加見積として出てきます。

この構造そのものは自動化の見積全般に共通するもので、スコープを揃えてから金額を並べる考え方は自動化見積もり比較で扱っています。本記事はそのうち、ソフトウェアという最も範囲が見えにくい部分に絞ります。

装置ソフトが扱う範囲は広がる方向にある

機械・装置メーカーの意思決定者120人を対象に、3つの地域・22の機械サブ分野で実施された2026年5月の調査では、96%が社内業務や装置ソフトへのAI適用に着手していると報告されています。内訳は、特定用途を本番展開まで進めた回答者が55%、実証段階が41%です。用途としては、装置の生産工程では予知保全が54%、画像認識が35%、サービス工程では遠隔診断が48%と報告されています。

この数字から読み取るべきは「AIを入れるべきだ」ということではありません。装置に載るソフトウェアが、機械を動かすためのプログラムだけでは済まなくなってきているという方向性です。遠隔診断が装置に載れば通信とログの設計が要り、画像認識が入れば判定基準とその責任の所在を決めなければなりません。

同じ調査では、導入の障壁として費用が54%、データ基盤の不足が43%、人材のスキル不足が43%と挙げられています。データ基盤と人材が並んで上位に来るのは、装置ソフトの発注が「作ってもらって終わり」ではなくなっていることの裏返しです。

分けないと、社内に残す部分も決められない

範囲が見えない状態では、内製と外注の線も引けません。装置ソフトのうち、自社の技術者が触れるようにしておきたい部分と、専門会社に任せて構わない部分は、明らかに違います。しかし「一式」で発注してしまうと、その区別を後から作ることはできません。

そこで本記事では、装置のソフトを5つの階層に分けます。層で分ける目的は、発注先を分けることではありません。1社にまとめて頼む場合でも、層ごとに成果物と責任を書き分けるためです。

装置のソフトウェアを5階層に分ける

同じ「装置ソフト」という言葉で呼ばれていても、中身は性質の違う5種類のソフトの集合体です。順に見ていきます。

層1 シーケンス制御｜装置が動く順序を決める部分

PLCのラダーやST言語で書かれる、装置の動作順序そのものです。センサの入力を見て、シリンダやモータの出力を切り替え、インターロックで危険な組み合わせを禁止する。装置ソフトと聞いて多くの人が思い浮かべるのがこの層です。

この層の特徴は、装置が変わっても考え方が持ち越せることと、保全担当が最も触りやすいことです。一方で、書き方の個人差が最も大きく出る層でもあります。プログラミング言語の国際規格であるIEC 61131-3に沿って書かれていても、そのまま別のメーカーのPLCへ移せるわけではありません。この層の発注実務はPLCプログラム開発の外注で詳しく扱っています。

層2 モーション制御｜どう動かすかを決める部分

サーボモータで軸を動かす場合、「どこへ動かすか」を決めるのが層1だとすれば、「どういう速度と加減速で、どの軌跡で動かすか」を決めるのが層2です。単軸の位置決めだけなら層1に含めて考えても破綻しませんが、複数軸を同期させる、カム動作を持たせる、押し付け力を制御するといった要求が入ると、まったく別の技術になります。

この層が厄介なのは、要求仕様が数字で書きにくいことです。「もう少し滑らかに」「もう少し速く」という調整が立ち上げの現場で発生し、その調整工数を誰が持つのかが見積の段階で曖昧になりがちです。タクトタイムを契約条件に入れるのであれば、どの条件下で測ったタクトなのかを層2の要求として明文化しておく必要があります。

層3 ビジョン・計測｜合否を判定する部分

カメラで撮り、画像から良否を判定する部分です。近年はこの層に機械学習が入ることも増えました。判定のしきい値、照明条件、撮像位置、そして判定を外したときの装置の振る舞いが、この層の設計対象になります。

層3が他の層と決定的に違うのは、正解が装置側にないことです。層1と層2は「指示どおりに動いたか」で検収できますが、層3は「その判定が正しいか」を誰かが決めなければ検収できません。この判定基準を発注者が持つのか、装置メーカーが持つのかで、費用も納期も大きく変わります。ビジョンを装置に組み込むときの費用構造はロボットビジョン導入の費用と投資回収にまとめています。

層4 HMI・操作画面｜人と装置の接点

タッチパネルに表示する画面、アラームの出し方、操作権限の設計です。装置が完成した後、最も多くの人が毎日触るのがこの層でありながら、見積では最も軽く扱われがちな層でもあります。

海外拠点ではさらに条件が加わります。表示言語をどうするか、権限を誰に与えるか、アラームの文言を現地の保全担当が理解できるか。層4は「作画」の工数だけで見積もられることが多いのですが、実際の費用を決めるのは情報設計のほうです。この層はタッチパネル画面設計で単独に扱っています。

層5 上位連携｜装置の外へ出す部分

生産実績、稼働状態、品種切替のレシピ、トレーサビリティ用のデータ。これらを装置の外へ渡す部分です。渡す先はPCアプリケーションのこともあれば、MESやIoT基盤のこともあります。

層5は「今回は不要」と言われて削られやすい層の筆頭です。しかし後から足そうとすると、層1のプログラムに手を入れることになり、装置が稼働に入った後では触りにくくなります。取得口だけ作っておく判断が効くのはこのためです。取得側の考え方はPLCデータ収集で整理しています。

5階層の性質を並べて見る

層	主な中身	検収の判断基準	変更の頻度	見積で落ちやすい費用
層1 シーケンス制御	動作順序、インターロック	指示どおり動くか	品種追加時	ドキュメントとコメントの整備
層2 モーション制御	軌跡、同期、加減速	条件下でタクトが出るか	立ち上げ時に集中	現場での追い込み調整
層3 ビジョン・計測	撮像、判定、照明条件	判定が正しいか	ワーク変更のたび	判定基準の合意と再学習
層4 HMI・操作画面	画面、アラーム、権限	現場が操作できるか	運用開始後も継続	情報設計と多言語化
層5 上位連携	実績、稼働、レシピ、通信	上位で使える形か	上位側の都合で発生	データ項目の定義作業

この表で言いたいのは、層ごとに検収の物差しが違うということです。同じ「装置ソフト」でも、層1は動作で、層3は判定基準で、層4は現場の操作で、層5は受け取る側の要件で検収されます。1行の見積書は、この5つの物差しを1つに潰しています。

装置ソフト開発2026｜5階層で分けると発注先と費用が変わる - figure 1

装置ソフトの見積が割れるのは層と層の間

層の中身そのものより、層と層の接点のほうが揉めます。装置ソフト開発の見積が会社によって割れる場所は、ほぼここに集中します。代表的な4つの境界を挙げます。

境界1 シーケンスとモーションの間｜軌跡を誰が決めるか

発注仕様書に「ワークをAからBへ搬送する」とだけ書かれている場合、そこにモーションの設計が含まれているかどうかは読み取れません。装置メーカー側は「指定された座標へ動かす」と読み、発注者側は「最適な軌跡を設計してもらえる」と読む。この解釈差が、立ち上げ終盤のタクト未達として表面化します。

回避策は、タクトタイムを測る条件を先に決めることです。どのワークで、何個連続で、どの状態から測るのか。これを書いておけば、軌跡の設計責任が自動的に装置メーカー側に寄ります。

境界2 ビジョンと判定の間｜不良の定義を誰が持つか

画像判定を入れる場合、最も費用が動くのは「限度見本を誰が用意するか」です。良品と不良品の境界にあるサンプルを、発注者側が現物で提示できるかどうか。これが無い状態で発注すると、装置メーカーは判定基準を仮置きして作り、立ち上げで作り直すことになります。

もう1つ決めておくべきは、判定を外したときの装置の振る舞いです。停止するのか、疑わしいものだけ別ラインに出すのか、記録だけ残して流すのか。これは技術ではなく運用の決定であり、発注者側でしか決められません。

境界3 HMIと操作の間｜画面を誰が設計するか

画面は装置メーカーが作るのが一般的ですが、「何を表示するか」は本来発注者の要件です。ここが空欄のまま発注されると、装置メーカーの標準画面がそのまま納入され、現場は自分たちの言葉ではない画面を毎日操作することになります。

自社に残すべきは作画そのものではなく、表示すべき情報とアラームの分類です。この2つを渡せば、作画は外注して構いません。

境界4 上位連携とデータの間｜粒度をどこで決めるか

装置から出すデータの粒度は、装置側だけでは決められません。1ショットごとに残すのか、ロット単位で集計するのか。時刻はどこの時計を使うのか。異常停止の理由をどこまで細かく分類するのか。

この粒度が決まらないまま「データを出せるようにしておいて」と発注すると、出てきたデータが上位側で使えないという結果になります。上位側の要件が固まっていないなら、粒度を決めるのは後でよいが、取得できる状態にはしておくという中間解を仕様に書いておくべきです。

装置全体としてどこまでを1社に任せるかという発注形態の議論は、自動機の設計製作の発注ガイドで費用の層構造として扱っています。本記事の5階層は、その中の制御・電気の層をさらに割ったものと考えてください。

装置ソフト開発2026｜5階層で分けると発注先と費用が変わる - figure 2

止まった理由が残るかどうかは装置ソフトの設計で決まる

装置が稼働に入ってから最も多く聞く相談が、「稼働率を上げたいが、何で止まっているのか分からない」というものです。これは計測器の問題ではなく、装置ソフトの設計の問題であることがほとんどです。

装置の状態を共通の言葉で定義するPackML

包装機械の分野で使われてきた考え方に、PackMLがあります。OMACが策定し、計測制御の国際団体であるISAの技術報告ISA-TR88.00.02として文書化されているもので、装置の状態を共通の名前で定義する枠組みです。

定義されている状態は17個あります。停止や待機のように装置が留まる状態と、起動中や停止処理中のように装置が遷移している状態に分かれます。あわせて、生産、保全、手動、段取り替えという4つの運転モードが定められています。この技術報告はバージョン3.0として整理された後、2015年と2022年に更新されています。

OMACはこの枠組みの利点として、装置メーカー側では開発期間の短縮と制御プラットフォームに依存しないこと、装置を使う側では立ち上げの短縮、教育の再利用、復旧時間の短縮を挙げています。

状態を定義しないと停止理由が後から作れない

PackMLをそのまま採用するかどうかは、装置の種類によります。包装機以外では、そこまで細かい状態遷移が要らない場合もあります。重要なのは規格の採否ではなく、装置が今どの状態にあるかを、装置ソフトが自分で持っているかどうかです。

状態を持っていない装置は、外から見ると「動いている」か「動いていない」かの2値でしかありません。この装置から稼働率を出そうとすると、動いていない時間の理由を人が後から書き足すことになります。書き足された理由は、書いた人の記憶と判断に依存します。

逆に、状態が定義されていれば、段取り替え中と異常停止中と材料待ちは最初から別のものとして記録に残ります。同じ「止まっている」でも、投資の判断に使えるかどうかがまるで違います。

見積の書き方が変わる

状態の定義を仕様に入れると、見積の書き方も変わります。「稼働監視機能」という漠然とした1行ではなく、「装置の状態を定義し、状態の遷移とその時刻を層5から取得できるようにする」という書き方になります。

これは追加費用が発生する項目です。しかし、装置の稼働に入ってから同じことをやろうとすると、層1のプログラムに手を入れる必要が出てきます。稼働中の装置のシーケンスに手を入れる作業は、新規設計時に同じことをやるのとは費用の桁が違います。

発注時に成果物として名前を書く7項目

層に分けたら、次は各層で何を受け取るかを書きます。ここが空欄のままだと、装置は動いているのに自社では何も触れないという状態になります。

項目	何を決めるか	空欄にすると起きること
ソースの引き渡し	各層のソースを受け取るか、実行形式のみか	小さな改造も装置メーカーに依頼するしかなくなる
コメントの言語	日本語か英語か、現地語の併記が要るか	現地の技術者がプログラムを読めない
パラメータとレシピ	どの形式で、誰がバックアップを取るか	復旧時に品種の設定が戻せない
テスト仕様書	出荷前検査と据付後検査で何を確認するか	検収の合否が担当者の印象で決まる
変更履歴	立ち上げ中の変更をどう記録するか	最終版がどれか分からなくなる
ライセンスと開発環境	改造に必要なソフトを自社が持てるか	ソースはあるが開けない
遠隔保守の入口	誰がいつどこから接続してよいか	接続経路が把握されないまま残る

このうち海外拠点で特に効くのが、コメントの言語と開発環境のライセンスです。ソースを受け取っても、開発ソフトのライセンスが装置メーカー側にしかなければ、実質的に何も触れません。逆に言えば、この2つを発注条件に入れておくだけで、将来の改造の選択肢が大きく変わります。

装置ソフト開発2026｜5階層で分けると発注先と費用が変わる - figure 3

2027年1月の欧州機械規則が装置ソフトに求めていること

タイの工場には直接関係がないように見えて、装置の調達に効いてくる制度変更があります。欧州の機械規則です。

ソフトウェアと安全が同じ枠で扱われる

機械規則(EU)2023/1230は、2027年1月20日から適用されます。同日をもって従来の機械指令2006/42/ECは廃止され、重複する猶予期間は設けられていません。

この規則の特徴は、ソフトウェアとサイバーセキュリティを機械安全の要求の中に取り込んだことです。安全に関わる制御システムとソフトウェアは、偶発的な故障だけでなく意図的な攻撃に対しても耐えることが求められます。ネットワーク接続や遠隔アクセスの機能が危険な状態を作り出さないこと、そしてこれらの対策を機械の寿命を通じて維持することが要求されています。改ざんの試みを追跡できるよう、介入の記録を残すことも求められます。

制御ソフトの入れ替えが実質的変更にあたる場合がある

もう1つ、装置を使う側にとって重要なのが「実質的変更」の扱いです。市場に出た後の機械に対して、自動化の追加や制御ソフトの更新といった改造を行い、それが新たな危険源を生む、あるいは既存のリスクを高めて新しい保護方策が必要になる場合、改造した者が機械全体の製造者としての立場を負うことになります。その場合はリスクアセスメントをやり直し、適合宣言を出し直す必要があります。

これはタイの工場でも他人事ではありません。欧州製の装置を使っていて、その制御ソフトを現地で入れ替える判断をするとき、どこまでが保守でどこからが改造なのかという線が、契約と規格の両面で問われるようになります。

開発プロセスそのものを問われる規格が使われはじめている

装置に載るソフトの作り方を評価する規格として、産業用オートメーション制御システムのセキュリティ規格であるIEC 62443-4-1があります。セキュリティ要求の定義、セキュアな設計、検証、脆弱性管理、更新の管理といった工程を、開発の作法として求めるものです。装置やコントローラを供給する側に適用され、達成度は成熟度レベルで示されます。実際に、HMIやコントローラを供給するメーカーがIEC 62443-4-1の成熟度レベル2の認証取得を公表しています。

関連して、欧州のサイバーレジリエンス法では、実際に悪用された脆弱性や重大なインシデントの報告義務が2026年9月11日から適用されます。24時間以内の早期警告と72時間以内の詳細報告という枠組みで、大半の義務は2027年12月から適用されます。

装置ソフトの発注者として、これらの規格をすべて理解する必要はありません。押さえるべきは、装置メーカーに「セキュリティ対応はどうなっていますか」と聞いたときに、製品の機能ではなく開発プロセスで答えられるかどうかという点です。

上位連携をどこまで装置ソフトに持たせるか

層5の設計は、装置ごとに決めるとバラバラになります。工場全体でどう揃えるかという視点が要ります。

装置間をつなぐ標準の現在地

装置と上位システムをつなぐ通信では、OPC UAが事実上の共通言語になっています。近年はこれを装置間の実時間通信まで広げるOPC UA FXの整備が進んでいます。

2026年3月時点で、OPCファウンデーションはリリース候補V1.00.04を公開しており、接続機器と情報モデルを扱うPart 81、適合プロファイルを扱うPart 84が加わっています。2026年2月16日から19日にかけては、ベルリンで主要な自動化ベンダーが参加する相互接続検証イベントが開催されました。

実務的な意味は、装置と装置、あるいは装置とコントローラの間を、メーカーをまたいで標準的な方法でつなぐ道筋が整いつつあるということです。ただし現時点ではリリース候補の段階であり、いま発注する装置の仕様に必須要件として書き込む段階ではありません。仕様書に書くとすれば、「上位通信にOPC UAを使うこと」までが現実的な線です。

「今回は不要」を「将来もやらない」にしない

層5を削るかどうかの判断は、コストだけを見れば削る側に傾きます。しかし削り方には2種類あります。

上位への送信機能そのものを作らないという削り方と、送信は作らないがデータを取り出せる状態にはしておくという削り方です。前者は後から足すときに層1へ手を入れることになり、後者は層5だけで完結します。この差は、装置が稼働に入った後で大きく効いてきます。

具体的には、生産数、良否、状態、時刻の4つを、装置内部のどこかに整理された形で持たせておくことです。送信先が決まっていなくても、持たせておくこと自体は今できます。

内製と外注をどこで分けるか

5階層に分けた最大の実務的な効用は、内製と外注の線を層の単位で引けるようになることです。

自社に残すのは仕様と受入基準

すべての層を自社で書ける工場は多くありません。むしろ現実的なのは、書く仕事は外に出し、決める仕事を自社に残すという分け方です。

層1では動作順序とインターロックの考え方、層2ではタクトの測定条件、層3では良否の判定基準、層4では表示する情報とアラームの分類、層5ではデータ項目の定義。これらはすべて、装置メーカーではなく発注者側でしか決められないものです。逆に、ラダーの記述、サーボの調整、画像処理の実装、作画、通信の実装は、専門会社に任せて構いません。

現地で触れる範囲を決めておく

海外拠点では、もう1つの軸が加わります。日本本社と現地拠点のどちらが触るかです。

現実的な落としどころは、層4と層5を現地で触れるようにし、層1から層3は変更手順を決めたうえで日本側または装置メーカーに残すという分け方です。層4と層5は運用に伴って継続的に変更が必要になる一方、装置の安全と品質に直結する度合いが層1から層3より低いためです。

ただしこれは、現地の技術者が層1を読めなくてよいという意味ではありません。故障の切り分けには読む力が要ります。読めるが変更はしないという状態を作るために、コメントの言語とドキュメントの整備が効いてきます。装置の据付から量産までを誰が担うのかという分担については、設備立ち上げ支援も参考にしてください。

タイで装置ソフト開発を発注するときの固有の論点

ここまでは装置ソフト一般の話でした。タイ拠点を前提にすると、いくつか別の条件が加わります。

装置メーカーが日本にしかいないという条件

日本で設計製作された装置をタイに持ち込む場合、装置ソフトを書いた人はタイにいません。立ち上げ時は出張で対応できても、その後の改造や不具合対応は距離と時差の影響を受けます。

この条件下で効くのは、層の分割です。すべてを日本側に依存させるのではなく、現地で対応できる層を先に決めておく。とくに層4の画面変更と層5のデータ項目追加が現地でできるかどうかで、日常の運用負荷が変わります。

もう1つ、日本の装置をタイに持ち込むときには電源やドキュメントの前提が崩れる論点があります。これは装置ソフト固有の話ではないため、PLCプログラム開発の外注の該当部分を参照してください。

BOIの2026年措置を装置ソフトの投資計画に入れられるか

タイ投資委員会は2026年に、既存事業者の生産性向上を対象とする措置を用意しています。自動化やロボットの導入を含む機械設備のアップグレードに対して、機械の輸入関税の減免と3年間の法人所得税免除が与えられるものです。

免除額の上限は原則として対象投資額の50%です。対象となる自動化・ロボット機械の30%以上がタイ国内製造品に紐づく場合には、上限が100%まで引き上げられます。対象となる投資額は土地と運転資金を除いて最低100万バーツで、奨励証書の発行から3年以内に実施を完了することが条件です。

装置ソフトの費用がこの対象に含まれるかどうかは、投資の申請単位の作り方に依存します。装置一式の投資として申請するのか、ソフトだけを切り出すのか。切り出した場合の扱いは案件ごとに確認が必要です。少なくとも、装置の投資計画を組む段階でソフトの費用を別枠に置いておくと、申請の際に説明しやすくなります。

現地語での教育を仕様に書く

装置ソフトの話は、最終的に人の話に戻ります。層4の画面をタイ語にしても、アラームが出たときに何をすべきかが伝わっていなければ意味がありません。

発注仕様書に入れておきたいのは、操作教育と保全教育を分けること、そして教育の実施言語を明記することです。装置メーカーの標準的な引き渡しでは、日本語または英語の説明書と数時間の操作説明で終わることがあります。それが十分かどうかは、現地の保全体制によります。

発注前チェックリスト

装置ソフトの見積を依頼する前に、社内で埋められる項目を挙げます。

装置に必要なソフトを5階層に分けて、どの層が必要かを書き出したか
タクトタイムを測る条件を、ワークと個数と開始状態まで決めたか
画像判定を入れる場合、良品と不良品の限度見本を現物で用意できるか
判定を外したときに装置がどう振る舞うべきかを決めたか
画面に表示する情報とアラームの分類を、自社の言葉で書けるか
装置から取り出したいデータの項目を、送信先が未定でも列挙できるか
ソース、コメント言語、パラメータ、テスト仕様書、変更履歴、ライセンス、遠隔保守の7項目を発注条件に書いたか
現地で触れるようにする層と、日本側に残す層を決めたか
教育の対象者と実施言語を決めたか
BOIの措置を使う場合、ソフトの費用を投資計画のどこに置くかを整理したか

このうち上から4つが埋まっていれば、装置メーカーとの会話は具体的な工数の議論まで進みます。逆に、ここが空欄のまま相見積もりを取ると、範囲の違う見積が並ぶだけになります。

よくある質問

装置ソフト開発の費用相場はどのくらいですか？

1本の金額として示すことはできません。同じ「装置1台分のソフト」でも、シーケンス制御だけの装置と、複数軸の同期制御と画像判定と上位連携が入る装置では、必要な技術も工数も違うためです。相場を知りたい場合は、本記事の5階層のうち自社の装置にどれが必要かを決めたうえで、層ごとに見積を出してもらうのが実務的です。層で分けた見積であれば、会社をまたいだ比較も成立します。

装置ソフト開発とPLCプログラム開発は何が違いますか？

PLCプログラム開発は、装置ソフトのうち層1のシーケンス制御にあたる部分を指すことが多い言葉です。装置ソフト開発は、それに加えてモーション制御、画像判定、操作画面、上位連携までを含む広い意味で使われます。発注時に用語が食い違うと範囲の解釈がずれるため、見積依頼の時点でどの層を指しているのかを明示することを勧めます。

装置のソースコードは必ずもらえますか？

自動的にもらえるものではありません。発注条件に書いていなければ、実行形式だけが納入されることもあります。あわせて確認すべきなのが開発環境のライセンスで、ソースを受け取っても開発ソフトが手元になければ改造はできません。ソースの引き渡しとライセンスの2つを、契約書に別々の項目として書いておく必要があります。

PackMLは包装機以外の装置でも使えますか？

考え方は転用できます。PackMLは装置の状態を17個の状態と4つの運転モードで定義する枠組みで、ISA-TR88.00.02として文書化されています。包装機以外の装置にそのまま適用すると過剰になる場合もありますが、装置が今どの状態にあるかを装置ソフト自身が持つという設計思想は、稼働率を後から測れるかどうかを左右します。全面採用しない場合でも、状態の分類だけは仕様に入れておく価値があります。

装置ソフトの開発をタイの会社に依頼できますか？

層によります。層4の画面変更や層5のデータ取り出しは、現地で対応できる体制を作りやすい領域です。一方、装置の安全に直結する層1のシーケンス制御を全面的に書き換える作業は、元のプログラムのドキュメントとコメントが整っていることが前提になります。現地対応を想定するなら、装置の発注時点でコメントの言語と開発環境のライセンスを条件に入れておくことが実質的な準備になります。

欧州の機械規則はタイの工場にも関係しますか？

直接の適用対象は欧州市場に上市される機械ですが、間接的には関係します。欧州製の装置を使っている場合、制御ソフトの更新や自動化の追加が実質的変更にあたるかどうかという論点が生じるためです。機械規則(EU)2023/1230は2027年1月20日から適用され、ソフトウェアとサイバーセキュリティを機械安全の要求に取り込んでいます。装置メーカーとの保守契約や改造の合意の中で、どこまでが保守でどこからが改造かを整理しておくことを勧めます。

まとめ

本記事の要点を整理します。

装置ソフト開発の見積が比較できないのは、金額の問題ではなく範囲の問題です。装置に載るソフトは、シーケンス制御、モーション制御、ビジョン・計測、HMI・操作画面、上位連携という性質の違う5階層の集合体であり、層ごとに検収の物差しが違います。1行の見積書は、この5つの物差しを1つに潰しています。

見積が会社によって割れるのは層の中身ではなく、層と層の接点です。軌跡を誰が決めるか、不良の定義を誰が持つか、画面に何を出すかを誰が決めるか、データの粒度をどこで決めるか。この4つを発注前に埋めておけば、見積の差は範囲の差ではなく実力の差として読めるようになります。

装置が止まった理由を後から追えるかどうかは、装置ソフトが自分の状態を持っているかどうかで決まります。PackMLは17の状態と4つの運転モードで装置の状態を定義する枠組みで、全面採用しない場合でも状態の分類という考え方は転用できます。

制度面では、機械規則(EU)2023/1230が2027年1月20日から適用され、ソフトウェアとサイバーセキュリティが機械安全の要求に組み込まれます。制御ソフトの入れ替えが実質的変更にあたる場合があること、装置メーカーの開発プロセスがIEC 62443-4-1のような規格で評価されはじめていることは、装置を選ぶ側にとっても判断材料になります。タイでは、BOIの2026年措置が機械設備のアップグレードに対する法人所得税免除を用意しており、装置ソフトの費用をどう位置づけるかを投資計画の段階で整理しておく価値があります。

最後に、内製と外注の線は層の単位で引けます。書く仕事は外に出し、決める仕事を自社に残す。この分け方ができれば、装置ソフトはブラックボックスになりません。

装置ソフトの範囲を決める段階では、まだ装置そのものの仕様も固まりきっていないことがほとんどだと思います。TOMAS TECHでは、タイの日系製造業の現場を前提に、どの層を発注仕様書に書き、どの層を自社に残すのが現実的かという整理の段階からご相談を承っています。発注先を決める前の検討段階でも構いませんので、お問い合わせページからお気軽にご連絡ください。