工程管理のクラウド化で先に決めること｜責任分界と工場ネットワークの通し方

「クラウドにすれば工程が見える」。導入相談の入口はたいていこの一言から始まります。ところが実際に決着させるべき論点は、製品比較でも費用比較でもなく、その手前に残っています。クラウドへ置いた瞬間、止まったときに誰が復旧するのか、工場の制御ネットワークとどこで線を引くのか、協力会社にどこまで見せるのか。これらは製品を選んでも自動的には決まりません。この記事では工程管理をクラウドで運用する場合に事前に決めておく事項を、配置形態・責任分界・工場ネットワーク・共有権限・移行の順に整理します。費用相場と料金内訳はクラウド生産管理システムの記事、システムそのものの選び方は工程管理システムとはの記事に譲り、ここでは配置と運用の判断だけを扱います。

まとめ：工程管理のクラウド化は責任分界と回線断の設計で決まる

先に結論を置きます。工程管理 クラウドの導入が成功するかどうかは、製品の機能差より次の五点を契約前に決めたかで分かれました。

• 配置形態を三択で決める：共有型のSaaS、専有型のクラウド、自社運用の据え置き。設備に直結する処理が残るなら、併用型が現実的な着地になります。
• 停止時間の許容値を先に数字で置く：稼働率99.9%は月あたり約43分、99.5%なら月あたり約216分の停止を許す水準です。その時間に何が止まるかを工程側で棚卸ししておきます。
• 責任の線を項目ごとに引く：バックアップの取得範囲、復旧作業の担い手、権限設定の不備。設定に起因する事故は利用者側に残るのが原則で、契約書の稼働率だけ見ても足りません。
• 工場ネットワークとの間にゾーンを置く：制御系を業務系と同じ面に出さず、外部へ出すデータの種類と向きを決めてから接続します。
• 見せる範囲を工程単位で切る：協力会社アカウントに全案件が見えてしまう設計は、共有の便益より情報管理の負債が先に立ちます。

逆に、拠点が一つで、外部と工程表を共有せず、設備から実績を自動で拾う予定もない。この条件がそろっているなら、クラウド化で得られるものは小さく、表計算のままか単一サーバの据え置きで足ります。判断の分岐そのものは工程管理の課題を整理した記事でも扱いました。以降では、形態の選択から移行の進め方までを順に見ていきます。

工程管理をクラウドへ置く三つの形態｜共有と専有と据え置きの差

「クラウド型」と一括りにされる提供形態は、実際には性格の違うものが混ざっています。契約後に「思っていたのと違う」となる原因の多くは、この差を確かめずに月額料金だけを比べたことにありました。

共有型のSaaSと専有型で変わる更新の主導権と設定の自由度の違い

共有型のSaaSは、同じ基盤を複数の利用企業で分け合う形です。バージョンアップは提供者の計画で進み、利用者側に延期の裁量はほとんどありません。画面や項目の追加は用意された設定の範囲内に限られ、独自のテーブルを足すような改造は基本的に不可能でしょう。代わりに、初期構築が短く、運用担当を置かずに始められます。

専有型（プライベートクラウドやシングルテナントのホスティング）は、自社専用の環境を借りる形になります。更新の時期をこちらの都合で選べる契約もあり、既存システムとの接続や独自機能の追加にも余地が残ります。月額は共有型より上がり、環境の管理範囲も広がるため、情報システム部門か委託先のどちらかが面倒を見る前提です。工程管理では、生産設備や検査装置から実績を自動で拾う要件が入った時点で、専有型か次の併用型が候補に上がってきます。

自社運用を残す判断が成立する条件｜設備直結と止められない工程

据え置き、つまり自社の建屋内にサーバを置く形が今も合理的な場面は残っています。判断の分かれ目は三つでした。第一に、装置と秒単位でやり取りする処理が工程管理側に入っている場合。第二に、取引先との契約で、生産データを社外の基盤に置かないことを求められている場合。第三に、回線が切れても製造を止められず、かつ現場端末の手元入力では代替できない場合です。

逆に、この三つのどれにも当てはまらないのに据え置きを選ぶと、サーバの更改費とOSの保守切れ対応が数年ごとに戻ってきます。「セキュリティのため社内に置く」という理由だけで据え置きを選んだ現場では、更改の予算が付かず保守切れのまま使い続ける結果になりやすく、かえって守りが薄くなる逆転が起きます。

併用型の現実解｜実績の収集は工場内・計画と共有はクラウド側の設計

製造業の工程管理で落ち着きやすいのは、層で分ける併用型です。設備から実績を拾う部分と、装置に指示を返す部分は工場内に残し、計画の作成・進捗の集計・拠点間や協力会社との共有はクラウド側に置きます。工場内には数分から数十分ぶんのデータを溜める仕組みを挟み、外部との回線が切れている間も収集を継続させる構成です。

クラウド化で移る責任の線引き｜稼働率と復旧と設定の帰属先の確認

クラウドに置くと運用が楽になる、という理解は半分だけ当たっています。ハードウェアの保守と基盤の更新は提供者側へ移りますが、代わりに「自社が引き受け続ける範囲」が契約書の中に散らばる形になります。

稼働率の数字が示す停止時間｜99.9%と99.5%で変わる年間の差

サービス品質保証（SLA）の稼働率は、割合ではなく分に直して読みます。三十日を43,200分として計算すると、99.9%は月あたり約43分、99.5%なら月あたり約216分の停止までが契約上の想定内です。年間では525,600分に対し、99.9%が約8.8時間、99.5%が約43.8時間になります。ここで確かめるのは数字の大小ではなく、その停止が工程のどの時間帯に重なるかという点でした。

月末の出荷が集中する二日間に43分止まっても回るのか。夜勤帯に実績を入力できない時間が生じたとき、翌朝に手書きから転記して追いつけるのか。多くのサービス品質保証は、割れたときの補償を利用料の一部返金にとどめており、生産が止まった損害までは見ません。だからこそ、止まった時間をどう埋めるかは利用者側の運用設計として残ります。

バックアップは取得の範囲と復旧の担い手まで契約締結前に確かめる

「日次でバックアップを取得」という一行だけでは、実務の判断材料になりません。確かめる点は四つあります。取得の対象は基盤全体なのか自社のデータ単位なのか。保持期間は何日で、それを過ぎた分は消えるのか。特定の一件だけを戻したい場合に応じてもらえるのか。そして復旧の申請から復帰までにどれだけかかるのかです。

工程管理のデータは、誤って進捗を一括更新した、マスタを上書きした、といった人為的な事故で戻したくなる場面が多く、基盤障害からの復旧より部分復元の可否のほうが効いてきます。ここが提供者の標準サービスに含まれない場合、日次で自社側へ書き出す仕組みを別に用意する判断になるでしょう。

設定に起因する情報の漏れは利用者側に残る｜権限と接続元の制御

総務省が2022年10月に公表した「クラウドサービス利用・提供における適切な設定のためのガイドライン」は、設定の不備によって情報が外部から見える状態になる事故を扱っています。基盤側が堅牢でも、公開範囲や権限の設定を誤れば結果は同じで、その設定は利用者側の管理下にあるという整理です。

工程管理で具体的に効くのは、共有リンクの発行範囲、退職者と異動者のアカウント停止、接続元の制限、そして管理者権限を持つ人数の四点でした。とくに管理者権限は、導入時に情報システム部門と現場責任者とベンダー担当の三者に配ったまま棚卸しされず、数年後に誰が持っているか分からなくなる例が目立ちます。年に一度は一覧を出して確認する運用を、導入の設計に含めておきます。

工場のネットワークへ通す設計｜制御系との分離と回線断への備え

事務所のパソコンからブラウザで使うだけなら、工程管理のクラウド化はネットワークの論点をほとんど生みません。話が変わるのは、製造ラインの実績を自動で拾い始めたときです。

制御系と業務系の間にゾーンを置く｜経産省の手引きが示す実装手順

工場の制御ネットワークは、そもそも外部につながらない前提で組まれてきました。経済産業省の「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」は、この前提が崩れつつある状況を受けて策定されたもので、2026年8月時点の同省のページにはVer1.0（2022年11月策定）とVer1.1が併載されています。手引きの進め方では、業務と保護対象を整理したうえでゾーンを整理し、ゾーンと業務・保護対象を結びつける手順が置かれています。

実装に落とすと、制御系と業務系を同じ面に置かず、その間に中継のためのゾーンを設ける形になります。工程管理のクラウド化では、このゾーンに実績を集める仕組みを置き、外へ出すのは集計済みの実績だけ、外から入るのは計画データだけ、と向きと種類を限定します。装置へ指示を返す経路をクラウドから直接引かないのが、現時点で無難な線引きでしょう。

回線が切れた三十分に止まるもの｜現場で許容できる停止時間の決め方

クラウド化の検討で抜けやすいのが、事業所の回線そのものが切れた場合の想定です。基盤の稼働率が高くても、工場側の回線や機器が落ちれば結果は同じになります。棚卸しの手順はこうです。まず回線断が三十分続いた場合に止まる業務を書き出す。次に、そのうち紙と口頭で代替できるものに印を付ける。残ったものが、代替手段を用意すべき対象です。

実務では、進捗の入力と実績の収集は溜めておいて後から送れる一方、当日の作業指示と、他拠点からの引き当ての確認は止まると困る、という切り分けになることが多いでしょう。前者は工場内に溜める仕組みで対応でき、後者は当日ぶんの指示を朝の時点で紙に落とす運用か、回線の二重化で備えます。回線を二重化する場合、費用は契約形態で月額の数千円台から数万円台まで開くため、止まった一時間の損失額と並べて判断します。

端末側のオフライン入力とサーバ側で用意する縮退運用の設計範囲

現場のスマートフォンやタブレットから実績を入れる場合、電波の届かない場所での入力可否と、復旧時に同じ作業へ二重に登録された際の解決方法が要件になります。この端末側の要件は工程管理アプリの選び方を扱った記事で詳しく整理したため、ここでは繰り返しません。

サーバ側で決めておくのは、止まっている間に何を続けさせるかという縮退の範囲です。工程管理では、実績の収集だけは継続し、計画の再作成と他拠点への配信は復旧後にまとめて行う、という設計が扱いやすくなります。復旧時に溜まったデータを流し込む順序も先に決めます。実績を先に入れてから計画を更新しないと、進捗率が一時的に100%を超えるといった見え方の混乱が起きるためです。

拠点と協力会社に工程を見せる権限設計｜工程単位で範囲を区切る

クラウド化の便益がもっとも大きいのは、社外や他拠点と同じ工程表を見る場面です。同時に、事故が起きたときの影響がもっとも大きい場面でもあります。

協力会社に見せる範囲を工程単位で区切るアカウント権限設計の基準

外部アカウントに案件の全体が見えてしまう設計は避けます。区切り方は、案件単位、工程単位、期間単位の三通りが基本で、工程管理では「担当する工程と、その前後一工程まで」を既定にすると実務が回りやすくなりました。前後を見せるのは、自分の着手可能日が前工程の進捗で決まるからです。逆に、原価・受注金額・他社の見積は同じ画面に出さない設定を初期値にします。

アカウントの発行と停止の手続きも先に決めておきます。工事や案件が終わったときに誰が停止を依頼するのか。この一手が抜けると、終わった案件の関係者が閲覧できる状態のまま残ります。案件の完了処理と外部アカウントの停止を、同じ手順書の中に並べて書いておくのが確実でしょう。

複数の拠点で同じ工程表を触る場合の締め時刻と排他運用の決め方

拠点をまたいで同じ工程表を更新すると、後から保存した側が前の変更を消す事故が起きます。製品側の排他制御が行単位なのか表全体なのかを確認したうえで、運用でも重ならない形にします。実務的には、拠点ごとに更新できる工程の範囲を分け、全体の日程を動かす操作は本社側の一人に寄せる形が単純です。

締め時刻も揃えます。実績の入力を当日18時までとするのか、翌朝9時までとするのか。拠点で締めがずれると、朝の進捗会議で見ている数字が拠点ごとに別の時点のものになり、遅れの判断がぶれます。海外拠点が入る場合は、画面に表示される日時がどのタイムゾーンで解釈されるかも、導入前の確認事項です。

図面や数量を外部へ渡す場合の秘密保持と再委託先での契約上の取り扱い

工程表に図面や数量が添付されると、共有の対象は日程の情報にとどまりません。既存の秘密保持契約が、クラウド上での閲覧と再委託先の作業者による閲覧まで想定しているかを確認します。想定していない場合は、覚書を交わすか、添付そのものを社内に留めて外部には日程だけを見せる構成に切り替えます。

ダウンロードの可否も設計事項です。閲覧のみに制限できる製品なら、印刷と保存を止めたうえで期限付きの共有にできます。

既存の工程表と実績データを移す手順｜並行稼働と切替日の決め方

移行は、導入プロジェクトで最も見積りが外れる工程です。理由の大半は、移すデータの範囲を決めないまま「全部持っていく」と考えることにありました。

移すデータと移さないデータの線引き｜マスタと進行中と過去実績

対象は三層に分けて考えます。品目・工程・設備・取引先といったマスタは、新システムの項目に合わせて整備し直して移します。ここでの手間が後の運用品質を決めるため、移行作業のうち最も時間を割く部分です。進行中の案件は、残っている工程だけを新システムに登録し、完了済みの工程は実績として簡略に入れる形が現実的でしょう。

過去の実績は、原則として移さずに旧環境の参照だけを残す判断で十分です。標準時間の見直しや原価の分析に使う予定があるなら、集計済みの形で表計算に書き出して保管しておきます。何年ぶんを参照可能にしておくかは、品質記録として保存が求められる年限や取引先との取り決めから逆算して決めます。

止められない工程での並行稼働｜二重入力を許す移行期間の区切り方

製造も工事も止められないため、多くの現場は旧と新を一定期間並行させます。ここで決めるのは、並行の期間ではなく終わりの条件です。「一か月ほど様子を見る」という決め方をすると、現場は二重入力の負荷から逃れるために片方を使わなくなり、どちらのデータも欠けた状態になります。

実務では、案件の単位で切り替える方法が扱いやすくなります。切替日以降に着手する案件は新システムのみ、それ以前に着手した案件は旧システムで完了まで走らせる。この形なら二重入力は発生せず、旧環境は最後の案件が終わった時点で参照専用へ落とせます。工程が長期にわたる建設系では、この方式が特に噛み合いました。

移行後に効いてくるのは連携の向き｜受注と在庫との同期方針の設計

移行の成否を最後に分けるのは、周辺システムとのデータの受け渡しでした。受注データを工程管理へ取り込むのか、工程管理側で作った計画を基幹へ返すのか。向きが決まっていないと、どちらが正となる値なのかが曖昧になり、数量の食い違いが起きたときに解決できません。

片方向で足りるなら片方向にとどめます。双方向にする場合は、項目ごとにどちらを正とするかを表で決め、更新のタイミングを揃えます。既製サービスが提供する連携の口が日次のファイル取り込みしかない場合、当日の受注を当日の計画に反映したいという要件とは噛み合いません。この段階で初めて、追加開発の必要性が具体的な形で見えてきます。

クラウド型を選ぶ条件と見送る条件｜受託開発へ切り替える判断境界

ここまでの論点を、判断の形にまとめます。曖昧に「自社の状況に合わせて」と書いても選べないため、条件を数字と状態で示します。

クラウド型を選んでよい条件｜拠点数と共有相手と運用体制の閾値

次の条件のうち二つ以上に当てはまるなら、クラウド型を選んで問題は起きにくくなります。第一に、工程表を見る場所が二拠点以上に分かれている。第二に、協力会社や取引先と同じ工程を共有する必要がある。第三に、サーバの運用を担当できる人が社内にいない。第四に、現場の実績をスマートフォンやタブレットから入れたい。

これらはいずれも、据え置きのままだと外部公開の仕組みを自前で用意することになる要件です。その構築費と運用の手間は、多くの場合クラウドの月額を数年ぶん積んだ額を上回ります。

見送る判断が正しい場面｜秒単位の制御と閉域を求められる受託条件

反対に、次のいずれかに当てはまるなら、クラウド化を急ぐ理由はありません。装置と秒単位で同期する処理が工程管理の中に入っている場合。取引先との契約で生産データを外部基盤に置けない場合。そして、拠点が一つで外部との共有がなく、工程の変更が月に数回にとどまる場合です。最後の条件では、表計算のままで足りる可能性が残ります。

この三つに当てはまらないのに見送りを続けている現場では、判断が「クラウドは不安だ」という感覚で止まっていることが少なくありません。不安の中身を、停止時間・データの置き場所・設定責任の三つに分解すると、それぞれ契約と設計で扱える論点になります。

既製で埋まらない要件が三つを超えた場合に受託開発へ移す判断基準

既製のクラウドサービスを比較していて、標準機能で満たせない要件が三つを超え、そのどれもが業務上譲れないものだった場合。ここが受託開発との分岐点になります。とくに、実績を取る粒度が製品の想定より細かい、基幹との双方向の同期が要る、協力会社の権限を工程単位で切りたい、という三点が同時に出た案件は、既製品の設定では収まりにくくなりました。

その場合は、全部を作り直すのではなく、既製のクラウドを土台に足りない部分だけを開発して接続する形から検討します。工程管理を含む生産系の仕組みは、生産管理システム開発として要件の整理から連携の設計まで請け負っており、既製品で足りる範囲との線引きから相談できます。既製で足りるなら足りると答えるのが、この段階での誠実な回答です。

よくある質問

工程管理をクラウド化すると費用はオンプレより安くなりますか？

初期費用は下がり、五年程度の総額では条件により逆転します。サーバの購入と構築が不要になる一方、月額は使い続ける限り発生するためです。利用者数が多い、あるいは長期にわたって機能追加をしない前提だと、据え置きのほうが総額で下回る場合があります。料金の内訳と総保有コストの見積り方はクラウド生産管理システムの記事で詳しく扱いました。

工程 管理 クラウドへの切り替えにはどのくらいの期間が必要ですか？

既製サービスを設定の範囲で使う場合、マスタ整備を含めて二か月から四か月が目安になります。期間の大半を占めるのは製品の設定ではなく、品目と工程のマスタを整理する作業です。基幹システムとの連携開発が入る場合や、複数拠点を順に切り替える場合は、半年から一年の計画になることもあります。

インターネットに常時つながっていない工場でも使えますか？

使えますが、構成を分ける前提になります。設備からの実績収集は工場内に置いた仕組みで継続させ、外部との回線が復旧した時点でクラウド側へ送る形です。事務所側の計画作成と拠点間の共有だけをクラウドに置く構成なら、製造ラインは回線の影響を受けません。装置への指示をクラウドから直接返す設計は避けます。

協力会社に工程表を見せる場合の注意点はありますか？

見せる範囲を担当工程とその前後に限り、原価と受注金額は同じ画面に出さない設定を初期値にします。案件が終わったときにアカウントを停止する手順は、完了処理の一部として手順書に記載する運用です。図面や数量を添付する場合は、既存の秘密保持契約が再委託先での閲覧まで想定しているかを確認します。

既存のエクセルの工程表はそのまま移行できますか？

表の形そのままでは移せません。多くの製品は品目・工程・日程を項目として持つため、セルの結合や色分けで表現していた情報を、項目の値として置き直す作業が必要になります。移行の前に、色や記号が何を意味していたかを一覧にしておくと、設定の抜けが減ります。表計算での運用が成立する範囲については工程管理の課題の記事で整理しました。

関連記事

• 工程管理システムとは？機能・選び方と既製か自作かの判断軸を解説：システムそのものの機能範囲と、既製と受託開発の選び分けを扱っています。
• クラウド生産管理システムとは？費用・オンプレとの違いと選び方：料金の内訳と五年間の総保有コストの見積り方を詳しく扱っています。
• 工程管理アプリの選び方｜現場スマホ運用の要件と基幹連携：現場端末でのオフライン入力と同期時の競合解決の要件を扱っています。
• 工程管理の課題を原因別に整理｜システム化の境界：運用の見直しで直る範囲と、投資に踏み切る条件を整理しています。
• 施工管理の工程管理｜工程表の選び方と変動要因の織り込み：建設現場で協力会社を含めて工程を回す場合の実務を扱っています。