工場の競争力は、自動化を変え続ける力で決まる

工場の競争力は、 自動化を変え続ける力で 決まる Automation as a Service で、 生産機能を使い、変え続ける https://itfactory.s-facom.jp/ IT Factory White Paper No.2 1

目次 エグゼクティブサマリー 1. 自動化は、「設備を入れたら終わり」ではない 2. Automation as a Service とは何か 3. AaaS は何をサービス化するのか 4. AaaS を支える実行アーキテクチャ 5. AI エージェントは自動化をどう変えるのか 6. 構成要素は、もう目の前まで来ている 7. 国内展示に見る AaaS の先行例 8. まとめ：自動化を「買う」から「変えられる」へ IT Factory White Paper No.2 2

エグゼクティブサマリー 工場の自動化は、「設備を導入したら終わり」ではありません。 品種が変われば、検査条件が変わります。部品の供給方法が変われば、搬送の順 序が変わります。新しい製品をつくるなら、設備の動作だけでなく、設備同士の連 携、データの扱い、品質判定、保守方法まで変えなければなりません。 ところが、従来の自動化は、設備、PLC、ロボット、検査装置、搬送システムを 個別の導入プロジェクトとして構築することが多く、変更のたびに個別改修、現地 調整、再試験が必要になります。生産システムは動く。だが、簡単には変えられな い。ここに、現在のものづくりが抱える大きな課題があります。 工場の競争力は、自動化を変え続ける力で決まります。 Automation as a Service（AaaS）とは、工場の自動化機能を、サービスとして継 続利用する考え方です。検査、搬送、制御、把持、位置決めなどの機能を、必要な ときに組み合わせ、更新し、別ライン・別工場へ展開できる可能性を広げます。 AaaS の価値は、設備を月額で借りることでも、導入後の保守を外部化することで もありません。導入前の機器選定、設計、設定、配線、仕様・図面・データの準備 から、導入時の立ち上げ、導入後の更新、保守、データ活用、専門知識、変更管理 までを、ひとつながりのサービスとして扱えることにあります。自動化の価値は、 設備の性能や導入価格だけでなく、導入のしやすさ、工場が変化に対応する速度、 機能を再利用する能力、改善を続ける力で評価されるように変わります。[1] さらに、Software-defined Automation によって自動化機能と実行ハードウェア を分離できれば、特定のハードウェアベンダーだけでなく、特定の型式や機器その ものに縛られにくくなります。ソフトウェアの更新やプログラムの改修が必要にな っても、生産機能を引き継ぎやすくなります。これも、AaaSが利用者にもたらす重 要な選択肢です。 これは、映像コンテンツを買い切って再生する方式から、クラウドサービスとし て視聴する Video on Demand（VoD）への変化に似ています。利用者は、モニター とネット接続機器を揃えたあとは、コンテンツの選択、配信、更新、履歴管理を含 む利用環境を受け取ります。AaaSでは同じ発想を自動化に当てはめ、機器とソフト ウェア一式をそろえて使い始めるまでの負担と、使い始めた後に管理し続ける負担 を軽くします。機器を一式そろえたあとは、制御ソフトウェアの選択、利用、更 新、履歴管理を含む利用環境をサービスとして受け取ることになるのです。 IT Factory White Paper No.2 3

AaaS がもたらすのは、設備の所有方法の変更ではなく、生産機能を使い始め、組 み替え、更新し、広げていくまでの時間と負荷を変えることです。 その実現を支えるのが、Software-defined Automation、Virtual PLC、Cloud PLC、Edge、情報モデル、運用サービスです。AI エージェントは、目標や制約に合 う自動化サービスを検索し、構成し、検証し、承認された範囲で配備・監視する上 位機能として位置づけられます。 AaaS という統合された市場定義は、まだ確立していません。しかし、その構成要 素は、標準、製品、産業プロジェクト、展示の中にすでに現れています。以下で は、AaaSがものづくりにもたらし得るインパクトを整理し、終盤で 2023 年以降の 国内展示事例として、新エフエイコムの「外観検査 as a Service」と「部品物流 as a Service」を取り上げます。 IT Factory White Paper No.2 4

1. 自動化は、「設備を入れたら終わり」ではない 生産システムは動く。だが、簡単には変えられない。 月曜日、製造する品種が変わりました。検査条件、部品の供給順序、ロボットの 把持位置、作業者の画面を変更しなければなりません。火曜日には品質判定のルー ルが変わり、水曜日には部品の供給方法が変わり、木曜日には制御ソフトウェアの 更新が予定されています。 設備は故障していません。生産ラインも止まっていません。それでも、工場は簡 単には変えられません。 検査装置の設定、PLCのプログラム、ロボットの動作、WCSや上位アプリのデー タ、設備間のタイミング、安全確認を、一つずつ調整し、試験し、現場で立ち会う 必要があります。作業が異なるベンダー、異なるツール、異なる担当者に分かれて いれば、変更はさらに重くなります。 工場が支払っているのは、設備を動かすための費用だけではありません。自動化 を変更するための調整時間、専門人材、再試験、停止リスク、保守契約、データ連 携の費用も支払っています。導入時には見えにくかった負担が、運用期間中に積み 上がります。 生産活動上の課題 n 変更のたびに、個別改修が始まる 多品種少量生産では、品種変更は例外対応ではなく、日常業務です。しかし、制 御プログラム、検査アプリ、ロボット、搬送設定、上位システムのデータ定義が設 備ごとに分かれていると、一つの変更が複数の改修に広がります。 検査条件を変えるだけのつもりでも、搬送タイミングに影響します。搬送順序を 変えるだけのつもりでも、ロボットの待機位置やインターロックに影響します。変 更のたびに、対象を特定し、設定を変え、設備間のデータとタイミングを確認し、 品質・安全・復旧条件を試験しなければなりません。 n 自動化が、再利用・更新・人材の資産にならない あるラインで実現した検査や搬送を、別ライン・別工場へ展開したくても、設備 構成、PLC、通信方式、データ名、ロボット、カメラ、安全条件の違いが個別設計を 呼び込みます。標準化のためにつくった仕組みが、工場ごとの例外処理に変わり、 企業全体の生産能力として蓄積されにくくなります。 IT Factory White Paper No.2 5

更新も同じです。脆弱性対応やOS・ランタイム更新は必要ですが、制御ロジッ ク、通信、検査判定、安全機能、復旧手順を確認しなければなりません。更新でき ない自動化は古くなり、更新する自動化は毎回リスクを負います。さらに、設備固 有の設定を一人の担当者が抱えていれば、異動・退職によって「動くが、変えられ ない」状態が生まれます。 n 設備が増えるほど、選択肢が減る 専用 I/O、専用通信、専用ライブラリ、専用ツール、専用の保守技能は、合理的 な選択として導入されます。しかし、積み重なると、別のベンダーや機器へ移行す るための再設計、再試験、安全再認証、教育、停止リスクが発生します。 これは、ハードウェアベンダーへの依存だけではありません。特定の型式、世 代、機器構成に依存すると、調達困難や老朽化が起きたとき、生産機能まで作り直 すことになります。設備を所有していても、変更の自由を失うことがあるのです。 n 稼働率だけでは、変化対応力を測れない 設備が止まっていないことは重要です。しかし、工場の競争力には、次の問いも 含まれます。 • 新品種を立ち上げるまで何日かかるか • 検査条件を変更するまで何時間かかるか • 新しい機能を別ラインへ展開するまで何週間かかるか • 更新を安全に実行し、失敗から復旧できるか • 専門人材が不在でも、診断・復旧できるか 需要の変動、製品の短命化、人手不足、サプライチェーンの変化に対応するに は、設備の稼働率だけでなく、自動化を変更する速度が重要になります。 自動化を、生産機能として捉え直す ここまでの課題は、個別の設備が悪いという話ではありません。従来の設備導入 モデルが、導入時点の性能、価格、納期を中心に最適化されてきたということで す。 工場の競争力は、設備を買った瞬間だけで決まりません。どれだけ早く変えられ るか、どれだけ再利用できるか、どれだけ安全に更新できるか、どれだけ少ない専 門人材で運用できるかによって差がつきます。 検査する。運ぶ。把持する。位置決めする。判定する。設備を連携させる。これ らを、必要なときに使い、更新し、別の場所へ展開できる生産機能として提供でき ないか。 この問いから、Automation as a Service という考え方が始まります。 IT Factory White Paper No.2 6

2. Automation as a Service とは何か AaaSの価値は、導入前から始まる AaaS を導入後の更新・保守サービスとしてだけ捉えると、価値の半分を見落とし ます。自動化では、実際に機器を動かす前にも、制御機器を選び、構成を決め、設 定し、配線し、プログラム・図面・取扱説明書を管理し、データを保存・連携する ための準備があります。これらの前後工程が重いほど、機能を使い始めるまでの時 間と社内調整が増えます。 製造の前後工程を軽くするという価値は、映像コンテンツの VoD化を考えると理 解しやすくなります。利用者は、モニターとネット接続機器を揃えたあとは、コン テンツの選択、配信、更新、履歴管理を含む利用環境を受け取ります。AaaSでは同 じ発想を自動化に当てはめ、機器とソフトウェア一式をそろえて使い始めるまでの 負担と、使い始めた後に管理し続ける負担を軽くします。機器を一式そろえたあと は、制御ソフトウェアの選択、利用、更新、履歴管理を含む利用環境をサービスと して受け取ることになるのです。 このようにAaaSは、導入前から導入時、導入後までの仕事の流れを変え、自動 化機能を使い始めるまでの摩擦を減らします。そのうえで、使い始めた機能を更新 し、別の工程や工場へ展開し、変化に合わせて使い続けます。AaaSは、この一連の 生産活動を支える提供モデルです。 段階 従来の負担になりやすい仕事 AaaS が目指す変化 機器選定、制御構成、設定・ 利用する機能を起点に構成 導入前 配線、仕様・図面・データ準 し、必要な準備をサービス側 備 と分担する 導入時 現地調整、設備間連携、立ち 検証済みの機能・構成を使 上げ、再試験 い、立ち上げの不確実性を減 らす 導入後 保守、更新、脆弱性対応、デ 監視・更新・専門知識・変更 ータ管理、変更改修 管理を継続的に利用する もちろん、AaaSがすべての作業を自動的に不要にするわけではありません。安全 確認、現場条件の確認、最終的な品質責任、設備固有の作業は残ります。重要なの は、ユーザーが毎回すべてを個別に抱え込むのではなく、どの仕事をサービスとし て任せ、どの責任を現場に残すかを設計できることです。 IT Factory White Paper No.2 7

また、Software-defined Automation によって制御機能をソフトウェアとして定 義し、実行環境から分離できれば、ハードウェアの変化にも対応しやすくなりま す。これは、特定のハードウェアベンダーに縛られにくくするだけではありませ ん。特定の型式、世代、機器構成そのものに縛られにくくする価値でもあります。 機器の入れ替えが必要になったとき、機能の再設計から始めるのではなく、機器差 分を吸収して同じ生産機能を継続できる可能性が広がります。ただし、実際の移行 可能性は、標準インターフェース、アプリ移植性、性能、安全、契約条件の設計に 左右されます。 AaaSが可能にすること AaaS とは、工場の自動化機能を、サービスとして継続利用する考え方です。 AaaS のインパクトは、設備の所有形態を変えることだけではありません。従来は 個別設備プロジェクトとして扱われやすかった活動を、継続的なサービスとして扱 える可能性があります。 n 自動化機能を、設備購入の単位から切り出して利用する 必要なのは、必ずしも新しい設備一式ではありません。必要な工程に、検査機 能、搬送機能、把持機能、制御機能を追加したいという要求かもしれません。 AaaS では、機器の型式ではなく、工程で必要な機能をサービスの単位として捉え ます。機器は顧客が所有する場合も、提供者が用意する場合もあります。重要なの は、顧客が機器そのものではなく、定義された機能を利用できることです。 この考え方は、導入前の判断も変えます。最初から設備一式を固定するのではな く、「どの生産機能を、いつ、どの品質・速度・安全条件で使いたいか」を起点 に、必要な機器と実行環境を組み合わせます。機器の選定・設定・配線・保守を含 む準備の一部をサービス側と分担できれば、新しい自動化を試すまでの時間と社内 負荷を抑えられます。 n 品種・工程の変更に合わせて、自動化を組み替える 自動化機能がソフトウェアとして定義され、設備能力や制約条件が記述されてい れば、変更時に利用可能な機能を検索し、構成し、検証するという流れをつくれま す。 これは、変更が自動的に終わるという意味ではありません。安全確認、人の承 認、現場試験は必要です。ただし、毎回ゼロから作り直すのではなく、再利用可能 な機能と検証手順を積み上げることができます。 IT Factory White Paper No.2 8

n 一つの工場で作った自動化を、別ライン・別工場へ展開する 設備の違いをすべてなくすことはできません。しかし、機能の目的、入力、出 力、制約、状態、データの意味を標準化できれば、差分を管理しながら横展開する 可能性が広がります。 n 導入後も、ソフトウェアと専門知識を取り込む 自動化を導入して終わりにせず、監視、診断、更新、脆弱性対応、遠隔支援、改 善提案を継続的に受けます。これにより、工場内だけでは確保しにくい専門性を、 必要なときに利用する考え方が可能になります。 n ベンダーを変える選択肢を残す AaaS だから、直ちにベンダーロックインがなくなるわけではありません。しか し、標準インターフェース、データ可搬性、アプリ移植性、退出条件を契約・調達 条件に組み込むことで、将来の選択肢を増やすことはできます。 n 自動化の評価軸を、設備性能から改善速度へ広げる 設備の処理速度や精度だけでなく、変更に何日かかるか、別ラインへ何週間で展 開できるか、更新失敗からどれだけ早く復旧できるかを評価します。 つまり、AaaS は、ものづくりの競争力を「何を所有しているか」から「どれだ け速く、柔軟に、生産機能を変えられるか」へ広げるのです。 AaaSの価値と利用時の条件 AaaS の価値は、導入後の改修時間だけに現れるものではありません。導入前に、 機器・制御構成・データ連携・保守方法を一から組み立てる負担を減らせれば、新 しい機能を検討し、試し、採用するまでの意思決定も速くなります。導入後も、監 視、診断、更新、専門知識、セキュリティ対応を継続的に受けられれば、導入時点 の機能を固定せず、改善を続ける運用へ移行できます。 n ハードウェア・ベンダーロックイン AaaS は、ベンダーロックインを自動的に解消しません。しかし、Software- defined Automation、標準インターフェース、データ可搬性、アプリ移植性、退出 条件を組み合わせれば、特定ベンダーだけでなく、特定の機器・型式・世代への依 存も小さくできる可能性があります。接続できること、構成を移行できること、ア プリを移植できること、安全と性能を再現できること、契約終了後も第三者が運用 できることは、それぞれ別に確認しなければなりません。 n 責任分界と退出条件 AaaS を利用する際は、通信断・Cloud障害・更新失敗時の継続運転と安全停止、 更新・検証・ロールバックの責任、物理機器・ランタイム・アプリ・データの保守 IT Factory White Paper No.2 9

責任、データの所有・利用、SLA、契約終了時のコード・設定・データ・運用手順の 移管条件を決める必要があります。技術要素だけでなく、責任分界と退出条件まで 設計して、初めて継続利用の選択肢になります。 3. AaaS は何をサービス化するのか AaaS を理解するために、サービスの対象を 6層に分けます。この 6層は、本稿の 整理モデルです。 1. 機器層 センサー、ロボット、I/O、搬送機、加工機、制御盤内機器など、物理的に工程へ 作用するものです。機器を提供者が所有する場合も、顧客が所有する場合もありま す。 機器層だけを月額化した場合、それは機器リースや Equipment-as-a-Service に近 いものです。AaaSでは、機器の上で動く機能と、その後の運用まで含めて考えま す。 2. 実行機能層 検査する、運ぶ、把持する、位置決めする、温度を制御する、設備を連携させ る、といった工程上の能力です。 ここがAaaSの中心です。顧客が本当に利用したいのは、PLCの型式や制御盤の 台数ではなく、生産工程で必要な機能だからです。 3. ランタイム層 PLC、Virtual PLC、Cloud PLC、Edge Runtime、HMI、SCADAなど、機能を実行 する基盤です。 Siemens は SIMATIC S7-1500V を、Industrial Edge 上で配備・管理できるハード ウェア非依存の Virtual PLC として説明しています。AWSも、Software-defined Automation による Cloudベースの PLC管理とコード配備のガイダンスを公開して います。これらは、制御機能をソフトウェアとして管理し、更新する方向を示す公 式例です。[2][3] 4. データ・知識層 設備能力、状態、レシピ、品質、ログ、AAS、OPC UA 情報モデル、シミュレーシ ョン、AI モデルなどです。 IT Factory White Paper No.2 10

AI エージェントが「この設備は何ができるか」「今どの状態か」「どの条件では 使えないか」を判断するには、設備・工程・機能の意味が記述されていなければな りません。データを集めるだけでは、サービスとして検索・構成することはできま せん。 5. 運用層 監視、診断、保守、脆弱性対応、更新、検証、配備、ロールバック、遠隔支援で す。 単発の設備導入とAaaSを分けるのは、この運用層です。導入後の変化に対応 し、機能を使い続けられる状態を維持する責任が含まれます。 6. 成果層 稼働率、品質、処理量、切替時間、エネルギー、保全負荷などです。 成果保証や成果連動課金は魅力的ですが、原材料、作業者、上流・下流設備、計 画変更などの影響を分けなければなりません。成果層はAaaSに含められる選択層で あり、必須条件ではありません。 6 層モデルが示すこと AaaS の価値は、機器をなくすことではありません。機器の上で動く実行機能を、 ソフトウェア、データ、運用、更新と組み合わせ、継続利用できるようにすること です。 4. AaaS を支える実行アーキテクチャ Software-defined Automation：自動化機能をソフトウェアとして定義する Software-defined Automation は、自動化機能を専用ハードウェアに固定せず、 ソフトウェアとして定義し、管理し、更新する設計の方向性です。Siemens は、ア プリケーション管理の集中化、ランタイムの仮想化、IT型のエンジニアリング、複 数の機械・ライン・工場への展開を要素として説明しています。[4] 重要なのはハードウェアを否定することではなく、どの機器を使うかと、どの自 動化機能を提供するかを分離していくことです。機器を交換すれば同じ機能がその まま動くという意味ではなく、機器能力の記述、標準インターフェース、検証、再 認証が前提になります。 IT Factory White Paper No.2 11

Cloud PLC、Cloud 制御盤、Edge の役割分担 Cloud PLC は、PLCランタイムを集中計算基盤で実行・管理する考え方です。 「Cloud」が外部のパブリックCloudを指すのか、工場内のサーバーや Edge Cloud を指すのかで、遅延、可用性、安全、データ主権は変わります。Virtual PLC は制御 ランタイムの実行形態であり、Cloud PLC は配置・管理形態の一つです。 Cloud制御盤は、現場の電源、保護、I/O、安全系と、Cloud／Edge 側のソフトウ ェアサービスをつなぐ構成概念です。現場機器をクラウドへ接続するだけではAaaS にはならず、通信断や更新失敗時の動作、現場とサービス側の保守責任まで設計す る必要があります。 Edge は、工程・設備に近いローカルの実行環境です。低遅延、ローカルデータ処 理、プロトコル変換、通信断時の継続・縮退運転に向きます。安全機能、非常停 止、高速制御を外部Cloudの到達性に依存させないことが重要です。NIST も、一般 的な ITとは異なるOT固有の制約を考慮する必要があるとしています。[5] 5. AI エージェントは自動化をどう変えるのか AI エージェントはAaaSそのものではありません。AaaSとして利用可能になった 自動化サービスを、目的や制約に合わせて扱う上位機能です。 AI エージェントが担う可能性のある仕事 1. 生産目標、品質、納期、品種、制約を理解する。 2. サービスカタログから、利用可能な検査・搬送・制御機能を検索する。 3. 設備能力と生産要求を照合する。 4. 機能の組み合わせ、配置、パラメータの案をつくる。 5. シミュレーション、テスト、変更影響分析を依頼する。 6. 承認された変更を配備する。 7. 実行結果を監視し、異常時の再計画や復旧を提案する。 人の承認と安全境界 AI エージェントが自然言語の指示を、そのまま PLCや安全機器へ流すという話で はありません。 配備、停止、ロールバック、安全パラメータの変更は、権限、承認、監査の対象 です。安全インターロックと非常停止は、AI エージェントの判断とは独立した仕組 みとして維持します。 IT Factory White Paper No.2 12

AI エージェントの最初の実用領域は、自由な直接制御ではなく、サービス検索、 能力照合、構成案、検証、異常説明、運用監視になるでしょう。 これは、AI の能力を小さく見積もるということではありません。AI に任せる範囲 を、現場の安全と責任に合わせて段階的に広げるということです。 6. 構成要素は、もう目の前まで来ている AaaS という統合市場が完成しているわけではありません。しかし、その構成要素 は、すでに各所に現れています。 標準・情報モデル Asset Administration Shell（AAS）は、資産の情報やサブモデルを扱う標準化の取 り組みです。OPC UA は、機器、制御、IT、Cloudにまたがる相互運用性の基盤とし て使われています。MTP は、モジュールの機能・サービスを上位のオーケストレー ション層から扱う考え方を支えます。[6][7][8] Virtual PLC と Software-defined Automation Siemens、Beckhoff、CODESYS などは、専用 PLCハードウェアから制御ランタイ ムを分離する Virtual PLC や仮想制御の製品を提供しています。AWSも、SaaS とし ての Software-defined Automation による PLCコード管理・配備を説明していま す。[2][3][4] 産業プロジェクト Factory-X には、Autonomous Operation-as-a-Service のユースケースがありま す。Edge 上のソフトウェア管理、監視、診断、遠隔制御、手動およびAI による介 入を扱うものです。これは、本号のAaaSと同一のサービスではありません。しか し、自動化機能や運用能力を、設備の買い切りではなくサービスとして扱う方向を 示しています。[9] AaaSの成熟度 現時点で言えるのは、AaaSが確立したということではありません。 言えるのは、次の部品が、標準、製品、プロジェクト、展示の各段階で存在して いるということです。 • 自動化機能をソフトウェアとして扱う • ランタイムを仮想化・集中管理する IT Factory White Paper No.2 13

• 設備能力とデータの意味を記述する • Cloud と Edge を役割分担する • 運用、監視、更新、保守を継続提供する • AI による検索、構成、検証、監視を支援する 次に必要なのは、これらを現場の安全、責任、SLA、データ、退出条件と結びつ けることです。 7. 国内展示に見る AaaS の先行例 ここまで、AaaSがものづくりにもたらし得るインパクトと、それを支える構成要 素を説明してきました。 ここでは、2023 年以降に新エフエイコムが展示してきた「生産機能をサービスと して扱う」事例を取り上げます。これらはAaaSの一般定義を証明するものではあり ませんが、AaaSの考え方が国内の展示・提案でどのように具体化されてきたかを示 す例です。 2023 年 11 月 iREX：外観検査 as a Service 2023 年 11 月の iREX で展示された「外観検査 as a Service」では、Cloud制御盤 を介してクラウドと接続し、クラウドから外観検査を実行し、NG品を除去する構成 が示されています。 展示内容には、外観検査アプリとNG品除去アプリをクラウドから選択・設定す ること、最新版への自動更新、メンテナンスやデータアップロードの負担を減らす 考え方が示されています。[10] この展示は、検査装置をクラウドにつないだ構成であると同時に、外観検査と NG品除去を生産機能としてアプリから選択・設定・更新する構成としても整理でき ます。後者の見方では、機器の所有単位ではなく、生産機能の利用単位で自動化を 捉えています。 この構成から確認できる論点は、次のとおりです。 • 検査機能を、設備一式ではなく機能として捉える • 機能を設定し、更新する • 導入後の保守やデータを、継続運用の対象にする 2024 年 4月 関西物流展：部品物流 as a Service 2024 年 4月の関西物流展では、「部品物流 as a Service」が展示されました。 IT Factory White Paper No.2 14

展示内容には、部品物流 as a Service、Cloud WCS、Cloud制御盤、AGV・AGF、 クラウドアプリ、データ活用、保守・省エネが含まれています。[11] この展示では、物流機器単体ではなく、部品供給、搬送、WCS、現場制御、デー タ活用、保守を組み合わせた機能群として、部品物流を捉えています。 外観検査と部品物流は、対象工程が異なります。しかし、両者には共通点があり ます。 • 現場設備とCloud／Edge 側の機能を接続する • アプリや機能を選択・設定する • 導入後の更新・保守・データ活用を扱う • 機器ではなく、生産機能をサービスとして捉える 8. まとめ：自動化を「買う」から「変えられる」へ Automation as a Service は、設備をなくす概念ではありません。設備の上で動く 自動化機能を、必要なときに使い、更新し、組み替え、横展開するための提供モデ ルです。 AaaS がものづくりにもたらし得るインパクトは、工場を「固定された自動化」か ら「変化に対応する自動化」へ近づけることです。 • 品種・工程変更に対応しやすくする • 機器選定、設定、配線、データ準備など、導入前の負担を軽くする • 新しい機能を小さく試し、段階的に広げる • 一つのラインでつくった機能を、別ライン・別工場へ展開する • 導入後もソフトウェア、専門知識、保守を取り込む • 特定のハードウェアベンダーや機器に縛られにくくする • 設備性能だけでなく、改善速度と変更対応力を評価する そのためには、機器、実行機能、ランタイム、データ・知識、運用、成果を分け て考える必要があります。Cloudサーバー、Cloud PLC、Cloud制御盤、Edge を役 割に応じて配置し、AI エージェントには検証・承認・安全統制を組み込まなければ なりません。 最後に、導入を検討する際は、次の問いから始めてください。 - 私たちがサービスとして利用したい自動化機能は何か。 - その機能は、どの工程の変化対応力を高めるのか。 - どこまでをCloud、Edge、現場制御に置くのか。 - 更新、停止、復旧、責任分界を誰が担うのか。 IT Factory White Paper No.2 15

- 別ライン、別工場、別ベンダーへ移せるのか。 - AI エージェントに、どの権限まで与えるのか。 自動化の導入を、設備を買う一回限りのプロジェクトから、生産機能を使い続 け、変え続けるサービスへ変えます。その先に、Automation as a Service があり ます。 IT Factory White Paper No.2 16

参考文献・参照資料 [1] 新エフエイコム資料 [2] Siemens, “SIMATIC S7-1500V Virtual PLC,” https://www.siemens.com/en- us/products/simatic/s7-1500v/ （確認日：2026-08-07） [3] AWS, “Guidance for Automation Software Management with Software Defined Automation on AWS,” https://aws.amazon.com/solutions/guidance/automation-software-management- with-software-defined-automation-on-aws/ （確認日：2026-08-07） [4] Siemens, “Software-defined automation,” https://www.siemens.com/en- us/company/insights/industrial-operations-x/software-defined-automation/ （確認日：2026- 08-07） [5] NIST, “SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security,” https://csrc.nist.gov/pubs/sp/800/82/r3/final （確認日：2026-08-07） [6] OPC Foundation, “OPC Unified Architecture - Part 80: UAFX Overview and Concepts,” https://reference.opcfoundation.org/specs/OPC-10000-80/full （確認日：2026-08-07） [7] IDTA, “Asset Administration Shell Specification - Part 1: Metamodel Schema,” https://industrialdigitaltwin.org/wp-content/uploads/2023/06/IDTA-01001-3- 0_SpecificationAssetAdministrationShell_Part1_Metamodel.pdf （確認日：2026-08-07） [8] PROFIBUS & PROFINET International, “MTP - Module Type Packages,” https://www.profibus.com/technologies/mtp （確認日：2026-08-07） [9] Factory-X, “TP 2.07 Autonomous Operation-as-a-Service,” https://factory-x.org/use-case/tp-2- 7-autonomous-operation-as-a-service/ （確認日：2026-08-07） [10] 新エフエイコム資料 [11] 新エフエイコム資料 IT Factory White Paper No.2 17