2026 年 8 月 31 日更新: 本記事を「サイト紹介」から「現場の課題から実装ルートを選ぶ総論」へ全面的に書き直しました。サイトの方針・運営者・AI の利用方針は サイトについて に集約し、本記事では扱いません。あわせて、責務分界・課題ルーティング・通信経路の図解 3 点と、参考文献ブロックを追加しています。
1. 結論 — Python が担当するのは「集める・見せる・知らせる」まで
製造現場のシステムは、役割で 3 つの層に分けると整理がつきます。人を守る安全層、設備を動かす制御層、状態を見えるようにする情報層です。Python が入るのは 3 番目の情報層で、ここからはみ出さないことが、現場で使い続けられるかどうかを分けます。
層を分ける理由は、求められる応答時間と、止まったときの被害が層ごとに違うからです。安全層と制御層は「決められた時間内に必ず反応する」ことを前提に設計されます。一方、Windows と Python の組み合わせは、その保証をしていません。OS のスケジューリング、ウイルス対策ソフトのスキャン、Windows Update、ガベージコレクション——処理を数百ミリ秒単位で遅らせる要因が、アプリの外側にいくつもあります。
ばらつきは手元でも簡単に観測できます。ラベルを 1 つ表示するだけの最小 GUI アプリを PyInstaller で --onefile にした exe は、起動から終了までが 1 回目 2.97 秒、2 回目 1.51 秒でした（当サイト実測。Windows 11 Pro / Python 3.12.10 / PyInstaller 6.22.2）。同じ PC で同じ exe を続けて動かしても、ファイルキャッシュの効き方だけで 1 秒以上変わります。これは起動時間の測定であって制御周期の測定ではありませんが、汎用 OS の上では「毎回同じ時間で終わる」が保証されない点は共通です。測定条件は PyInstaller の onefile と onedir の実測比較 に載せています。
裏を返せば、情報層は Python の得意分野です。秒から分の単位で動けば足り、処理が遅れても設備は止まりません。集計が 5 分遅れて困る現場はあっても、5 分遅れて人が怪我をすることはない——この差が、外注を待たずに自分たちで踏み出せる範囲を決めます。
私自身、産業ソフトウェア開発の仕事を通じて、現場の小さな課題が大きなコストになる場面を何度も見てきました。日報の転記、装置ごとに書式の違う CSV、担当者しか読めない Excel ブック。設備は正常に動いているのに、人の時間だけが削られていきます。この種の課題は情報層に収まるので、見積もりを取る前に自分たちで試せます。進め方の全体像は 「外注1年」を「内製1ヶ月」に変える方法 にまとめました（同記事のコストと期間は説明用の架空企業の数値で、実在の案件ではありません）。
2. Python に任せない 4 つの領域
できることの一覧より先に、やらない範囲を決めます。ここが曖昧なまま作ると、動くものはできても現場には入れられません。
2.1 人の安全に関わる機能
非常停止、安全柵の扉スイッチ、ライトカーテン、両手押しボタン。人が怪我をしないための機能は、安全リレーや安全 PLC といった専用機器で構成します。汎用 PC の上で動く Python アプリで代替してはいけません。
理由は速度ではなく、壊れ方です。安全機器は「故障したときに危険側に倒れない」ことを前提に設計されています。対して Windows PC では、アプリのフリーズ、突然の再起動、ネットワーク断がいずれも普通に起こり、そのとき何が起きるかを設計者が保証できません。当サイトでは、安全関連部の設計そのものは扱いません。
2.2 ミリ秒単位で間に合わせる制御
サーボの位置決め、高速なシーケンス、一定周期で必ず出さなければならない出力。こうした処理は PLC やモーションコントローラの仕事です。Python 側から「1 ミリ秒ごとに読んで、判断して、出す」を安定して回そうとすると、前章のとおり OS 側の要因に負けます。
目安は単純です。秒単位で遅れても困らない処理が Python の守備範囲と考えてください。1 秒周期のデータ収集、10 秒ごとの画面更新、1 分ごとの集計、異常時の通知。この範囲なら、多少のばらつきは運用でのみ込めます。
2.3 設備を動かすシーケンスそのもの
「PLC の代わりに PC で全部やれば安上がりでは」と考えたくなる場面はあります。おすすめしません。理由は 3 つです。
- PC が落ちたら設備が止まる。PLC は電源投入から同じ動きを繰り返しますが、PC は起動に時間がかかり、更新にともなう再起動もあります
- 現場が直せない。夜間にラダーを見て手当てできる保全担当はいても、Python のソースを読める人はまだ少数です
- 設備メーカーの保守範囲から外れる。制御を自作に置き換えると、トラブル時の切り分けが自分たちの責任になります
Python から制御層に触れるときは、値を読むことと、停止や切替を要求することまでにとどめます。要求を受けて実際に止めるかどうかは PLC 側が判断する——この形にしておけば、PC が固まっても設備は自分のロジックで動き続けます。
2.4 検定や法令の根拠になる記録
取引に使う計量値、法令で保存が義務づけられた記録、顧客との契約で証跡を求められるデータ。これらを Python で加工した結果に置き換えてよいかどうかは、技術の話ではなく社内規程と法令の話です。品質保証部門や、必要なら所轄の窓口に確認してください。当サイトでは可否を判断できません。
実務上の安全策は、元データをそのまま残し、Python は写しだけを加工することです。元の CSV やログを書き換えなければ、後から突き合わせて検証できます。
2.5 では Python は何をするのか
残った範囲が Python の仕事です。
- 集める: PLC・計測器・センサー・既存システムからデータを取り込む
- 貯める: CSV やデータベースに、後から検索できる形で残す
- 見せる: グラフ・管理図・ダッシュボードにする
- 知らせる: しきい値を超えたら画面・メール・チャットに通知する
- 片づける: 日報・月報・提出書類を自動で作る
地味に見える 5 つですが、現場の時間を実際に食っているのはここです。しかも失敗しても設備は止まりません。試して駄目なら捨てられる——これが情報層で内製を始める最大の利点です。
「Excel マクロではだめなのか」という疑問には、線を引いておきます。ブック内の集計・帳票づくりだけで完結するなら、VBA のほうが速いことが多いです。Python に持ち替える価値が出るのは、Excel の外に出る仕事——PLC や測定器から値を取る、数千ファイルを横断して集計する、24 時間動かし続ける、しきい値超えを通知する——を含むときです。本記事の 4.1・4.2・4.4・4.6 はいずれも Excel の外側にある課題で、逆に 4.3・4.5 は VBA でも成立します。両方できるなら、まず 4.3 を Python で 1 回作って比べてみると、判断が早く付きます。
3. 内製する・設備側に任せる・買う の判定
情報層に収まる課題でも、全部を自分で作るのが正解とは限りません。判断は次の 4 つの問いで、だいたい決まります。
- 止まったら何が起きるか。設備が止まるなら制御層の話です。レポートが出ないだけなら内製の範囲に入ります
- どれくらいの速さが要るか。ミリ秒なら PLC、秒より遅くてよいなら Python です
- 誰が直すか。作った人しか直せない状態なら、内製しても異動や退職で使われなくなります。コードをバージョン管理に置き、手順を書き、2 人目が触れる形にできるかを先に考えます
- 買ったらいくらか。既製品で解決するなら、まず見積もりを取ります。市販の検査装置や BI ツールに、工数で勝てない領域はあります
この 4 つを課題に当てはめた結果が下の表です。判定は筆者の見解で、現場の規模・保守体制・既存設備によって変わります。表のとおりに決めるのではなく、右列の決め手を自分の現場に当てはめて読み替えてください。
| 課題 | 判定（筆者の見解） | 判断の決め手 |
|---|---|---|
| 設備の稼働状況・生産数を集めて可視化したい | 内製しやすい | 収集が数秒遅れても設備は動く。多くの場合、読み出しだけで済む |
| 測定器の値を PC に取り込みたい | 内製しやすい | シリアルや TCP でテキストを吐く機器が多く、読み取り専用で始められる |
| 装置ごとの CSV を統合して集計したい | 内製しやすい | 既存ファイルを読むだけで、設備にはいっさい触らない |
| 品質データの管理図・工程能力指数を出したい | 内製しやすい | 計算式が決まっており、結果を人が検算できる |
| しきい値を超えたら通知したい | 内製できる（停止は制御層に任せる） | 通知が数十秒遅れても人が対応できる設計にしておく |
| 設備を止めるインターロック | 内製しない | 制御層・安全層の責務（2 章） |
| 外観検査で不良を自動判定して排出したい | 段階を分ける | キズの見え方を試すところまでは Python 向き。ライン上で不良を弾く工程は、照明・搬送・実績の面で専用装置が有利なことが多い |
| 生産計画・在庫・原価をまとめて管理したい | 買う／既存システムを使う | 業務ルールが多く、内製すると保守が重くなりやすい |
| 数十人が同時に使う入力画面がほしい | 買う／Web 製品を検討 | 同時アクセス・権限管理・バックアップの作り込みが必要になる |
迷ったときは、読み取り専用で小さく作るのが安全側です。設備に書き込まない、既存ファイルを壊さない、まず 1 台 1 週間だけ動かす。既存のファイルやデータを扱うだけの課題（4.3・4.4・4.5）なら、この条件で失敗しても現場に影響は出ません。一方、設備の通信線に自分をつなぐ課題（4.1・4.2）は「読むだけ」でも無害ではありません。RS-485 のように 1 本の線を複数の機器で共有している場合、PC を足すこと自体が既存の通信に影響します。PLC 側も機種によって同時接続数に上限があり、ポーリングを増やすと既存の収集装置がつながらなくなることがあります。つなぐ前に、その線に何がぶら下がっているかを保全担当と確認してください。
4. 課題別ルート — 何がしたいかで入口を選ぶ
ここからは課題ごとのルートです。使う手法と、着地する記事の対応は次の図のとおりです。会社の PC に Python をそもそも入れられない（管理者権限がない・社内プロキシ・閉域網）方は、先に 製造業エンジニアのための Python 学習ロードマップで導入の壁を片づけておくと、各ルートの「最初の1歩」で止まりません。
4.1 設備の稼働状況や生産数を自動で集めたい
やることは、PLC のデバイス（レジスタ）を一定周期で読み、CSV かデータベースに書くことです。設備の改造は要らないことが多く、PLC 側では Ethernet の通信設定を有効にするだけで済む場合もあります。ただし、稼働中の設備の設定を変えること自体が設備への変更にあたります。可否と手順は機種の取扱説明書で確認したうえで、保全担当・設備メーカーの承認を得て、生産に影響しないタイミングで実施してください（実機での作業は自己責任でお願いします）。
向く条件: PLC が Ethernet を持ち、読みたいデバイス番号が分かっている。向かない条件: 読み出しのために PLC のプログラムを大きく変える必要がある場合です。その改造は制御層に手を入れる作業なので、設備メーカーや保全担当と先に相談してください。そもそも PLC に通信ポートがない、PLC に触らせてもらえない設備もあります。その場合は、積層信号灯や接点出力を外付けの入力ユニット（Raspberry Pi ＋ デジタル入力、市販の IO モジュールなど）で拾い、稼働・停止・生産数のカウントだけを取る方法があります。設備側に手を入れないので調整も楽です（当サイトでは今後扱う予定です）。
最初の 1 歩は、実機ではなくライブラリの選定です。三菱の MC プロトコル（SLMP）なら pymcprotocol、メーカーをまたいで使うなら pymodbus が入口になります。どちらもシミュレータで練習でき、実機がなくても書き方を確かめられます。
メーカー別の対応プロトコルとライブラリ比較、つながらないときの切り分けは PLC と Python で通信する方法 に、Modbus 固有の詳細は pymodbus 完全ガイド にまとめています。
4.2 測定器や古い装置から値を取り込みたい
ノギス、はかり、温調器、古い検査装置。Ethernet を持たない機器は、RS-232C や RS-485 のシリアルでデータを出していることがあります。手順は、ポート番号を調べ、通信条件（速度・パリティ・ストップビット）を機器の説明書どおりに合わせ、届いたバイト列を区切って読むことです。
向く条件: 機器の通信仕様書が手元にある。向かない条件: 仕様が非公開で、メーカーの専用ソフト経由でしか値が出ない場合です。無理に解析するより、メーカーに出力仕様を問い合わせるほうが早く済みます。
最初の 1 歩: pip install pyserial でライブラリを入れ、実機の前に仮想ポートで練習します。timeout を指定しないと機器が黙った瞬間に処理が戻らなくなるので、最初から必ず指定してください。当サイトの実測では、timeout=1.5 を指定した read() はデータが来なくても 1.50 秒で空のバイト列を返しました（Windows 11 Pro / Python 3.12.10 / pyserial 3.5、仮想ポート loop://）。
接続からエラー処理までは pyserial の使い方、Ethernet 経由でバイナリを扱う場合は TCP/IP でのリアルタイム通信 を参照してください。
4.3 装置ごとに書式がバラバラな CSV をまとめたい
いちばん頻度が高く、いちばん設備に触らずに済む課題です。装置がそれぞれ出す CSV を読み込み、列名をそろえ、1 つの表にして集計します。設備側の設定を変える必要がないので、失敗しても現場に影響しません。
向く条件: ファイルが所定のフォルダに出力されている。向かない条件: そもそも装置がファイルを出しておらず、画面表示しかない場合です。その場合は 4.1 や 4.2 に戻ります。
最初の 1 歩: 1 ファイルを pandas で読み、文字化けしないことを確かめるところからです。Windows で作られた CSV は CP932 のことが多く、encoding を指定しないと日本語の列名で失敗します。日本語を含むデータで最初につまずくのはここです。
集計とグラフ化は pandas と Matplotlib で品質管理グラフを作る、文字コードの体系的な対策は CP932 と UTF-8 の完全対策 にまとめています。
4.4 たまり続けるデータを後から検索できる形で残したい
CSV が数千ファイルになった、Excel が重くて開かない、去年の同じ条件を探せない。こうなったらファイルではなくデータベースの出番です。1 台の PC で完結するなら、追加インストールなしで使える SQLite が手軽です。Python の標準ライブラリだけで読み書きできます。
向く条件: 書き込むプロセスが 1 つに絞れる。向かない条件: 複数の PC から同時に書き込みたい場合です。その場合はサーバー型のデータベースを検討します。
最初の 1 歩: 既存の CSV を 1 か月分だけテーブルに流し込み、日付範囲の検索を試します。ここで速さと使い勝手を体感してから、収集アプリ側の保存先を切り替えると失敗しません。
スキーマ設計、書き込み性能、肥大化対策は 製造データを SQLite で管理する にまとめています。
4.5 品質データを管理図や工程能力指数にしたい
毎月の集計作業を自動化する話です。計算式が決まっているため、結果を人が検算でき、内製と相性が良い領域です。ヒストグラム、X̄-R 管理図、工程能力指数（Cp / Cpk）、パレート図まで、必要なグラフはひととおり作れます。
向く条件: 入力データの形式が毎月同じ。向かない条件: 元データの取り方自体が担当者ごとに違う場合です。先に入力の形をそろえないと、自動化しても例外処理が増え続けます。
最初の 1 歩: 今月分のグラフを 1 枚だけ Python で再現し、いつもの Excel の結果と数値が一致するか確かめます。一致を確認してから対象を広げます。
実装は 品質管理グラフの記事 に、Streamlit でのダッシュボード化は同記事の 10 章にまとめています。社内公開・認証まで含む本格構築は Streamlit でのダッシュボード構築で扱う予定です。
4.6 設備の異常に人より早く気づきたい
収集した値を画面に出し、しきい値を超えたら知らせる仕組みです。設備を止めるのは制御層で、Python 側は気づいて知らせるところまでを受け持ちます（2 章）。この線引きを守れば、監視アプリが落ちても生産は止まりません。
向く条件: 異常の判定基準が数値で決まっている。向かない条件: 「なんとなくいつもと違う」を検知したい場合です。その場合は正常データを集めるところから始めます。統計的な手法で外れ値を拾う方法もありますが、まずは固定しきい値で運用し、誤報の傾向を見てから高度化するほうが確実です。
最初の 1 歩: 24 時間動かす前提で作ることです。メモリの使い方、通信が切れたときの自動復旧、オペレーターが一目で状態を判断できる画面。この 3 点を後から足すのは大変なので、最初の設計に入れておきます。
画面と常時稼働の設計は tkinter で作る現場用監視アプリ、しきい値以外の判定手法は scikit-learn での異常検知、障害調査のためのログ設計は 24 時間動くアプリのためのロギング設計 にまとめています。
4.7 キズや欠けの外観確認をカメラで補助したい
画像処理は「試す」と「導入する」の距離が大きい領域です。手元の写真で傷が検出できるかを確かめるところまでは、OpenCV を使えば数時間で試せます。一方、ラインに載せて不良を自動排出する工程まで行くと、照明・治具・搬送・判定実績の話になり、専用装置のほうが有利なことが多くなります。
向く条件: 不良品と良品の画像が手元にある。向かない条件: 撮影条件が毎回変わる場合です。照明が安定しない現場では、アルゴリズムを工夫するより照明を固定するほうが効果があります。
最初の 1 歩: 良品と不良品を同じ条件で 10 枚ずつ撮り、差分や輪郭で違いが出るか見ます。ここで差が出ないなら、撮り方を変えます。
前処理から寸法測定・傷検出までは OpenCV で外観検査の入門 にまとめています。
4.8 作ったツールを現場の PC で動かしたい
最後の関門です。自分の PC で動いたスクリプトは、そのままでは現場の PC で動きません。Python が入っていない、文字が化ける、管理者権限がない、勝手に閉じられる——止まる理由は技術以外にもあります。詳しくは 6 章で扱いますが、方針だけ先に書きます。
単発で渡すなら exe 1 ファイル、毎日使うなら常駐させる。この二択で考えると設計が決まります。人が起動して使うツールは exe 化して配り、データ収集のように止まってほしくない処理は Windows のサービスとして常駐させます。
配布方法の選択と実測比較は PyInstaller の使い方と主要オプション、常駐化は Windows サービスとして常駐させる方法 を参照してください。
5. データが現場 PC に届くまでの経路
4.1 と 4.2 で触れた「データを取る」部分は、層をたどると全体像がつかめます。設備から現場 PC までは、物理的なつなぎ方・プロトコル・ライブラリ・保存先の 4 段階です。
この経路で最初に迷うのがライブラリ選定です。判断材料は「動くかどうか」だけではありません。誰がいつまで保守しているかを、採用前に見てください。
- 最終リリース年を見る: 日本語の解説記事で頻繁に紹介される
pymcprotocolは、PyPI へのリリースが 2021 年で止まっています。使えないという意味ではなく、問題が出たら自分たちで直す前提になるということです（詳細は pymcprotocol と pymelsec の比較） - 引数名の変更を見る:
pymodbusは開発が活発な一方、相手局を指定する引数がunit→slave→device_idと変わってきました。古い記事のコードをそのまま貼るとTypeErrorになります - 名前の紛らわしさに注意する: シリアル通信のライブラリは pip 名が
pyserial、import 名がserialです。PyPI には無関係のserialというパッケージが別に存在するため、pip install serialは間違いです
ライブラリ名は、検索結果や生成 AI の回答をそのまま信じずに、PyPI か公式リポジトリで実在と最終更新を確かめてから採用してください。実在しないパッケージ名がもっともらしく提示されることがあります。
6. 「自分の PC では動いた」の先にある 4 つの壁
ここは作ったものを他人の PC で動かす話です。自分が学ぶための環境を作る話（管理者権限がない PC への Python 導入、社内プロキシ、閉域網）は 学習ロードマップの 4 章にまとめてあるので、そちらを参照してください。
6.1 現場 PC に Python が入っていない
もっとも多い壁です。解決策は exe 化で、PyInstaller を使えばコマンド 1 行で作れます。判断が要るのは配り方です。当サイトの実測では、最小 GUI アプリの場合、既定の onedir 形式が合計 26MB・配るファイル数 942 個、--onefile 形式が 9.9MB の 1 ファイルでした。起動時間は onefile のほうが毎回およそ 1 秒遅く、1 回目 2.97 秒に対し onedir は 1.93 秒です（Windows 11 Pro / Python 3.12.10 / PyInstaller 6.22.2）。
読み方はこうです。手渡しの単発配布ならファイル 1 個の onefile が事故を減らします。毎日使うツールを複数台に置くなら、起動が速く差分更新もできる onedir が向きます。
6.2 文字が化ける
Windows の現場 PC で必ず通る壁です。Python の open() は、文字コードを指定しないと Windows の既定である CP932 を使います（Windows 11 Pro / Python 3.12.10 で当サイト実測）。UTF-8 で書いたはずのログが化ける、他部署からもらった CSV が読めない、といった症状の大半はここが原因です。
対策は単純で、読み書きのたびに encoding を明示することです。加えて、コマンドプロンプトや PowerShell から実行したときの表示も別に対策が要ります。詳細は CP932 と UTF-8 の完全対策 にまとめました。
6.3 権限とネットワークで止まる
現場 PC には管理者権限がなく、外部インターネットにもつながらないことがあります。この条件では、開発 PC で pip install したライブラリを現場 PC で入れ直せません。exe 化が有効なのは、ここでも同じ理由です。実行に必要なものを 1 つにまとめてしまえば、現場側でインストール作業が発生しません。
それでも社内ルールで実行ファイルの持ち込みが制限されている場合があります。持ち込みの可否は情報システム部門に先に確認してください。作ってから止まると、手戻りが大きくなります。
6.4 動かし続けられない
人が起動するツールなら閉じられても実害はありませんが、データ収集は止まると穴が空きます。ログオンしていなくても動かしたい処理は、Windows のサービスとして登録します。あわせて、何が起きたかを後から追えるログを残しておきます。
止まったときに「いつ・何が原因で止まったか」が分からないアプリは、現場で信用されません。常駐化は Windows サービス化の記事、ログの設計は 24 時間動くアプリのためのロギング設計 を参照してください。
7. 内製が現実的になった背景を、公的統計で確かめる
「外注せずに自分たちで作る」という進め方は、勢いだけの話ではありません。公表されている統計にも、社内で人を確保する方向へ動いている様子が出ています。
- IPA「DX動向2025」（2025 年 6 月 26 日公開）によると、DX を推進する人材の「量」が不足していると答えた日本企業は 85.1%。同じ調査での米国は 23.8%、ドイツは 44.6% と報告されています
- 2025 年版ものづくり白書（経済産業省・厚生労働省・文部科学省）では、デジタル技術の導入にあたって約 6 割の企業が社内人材の活用・育成で人材を確保し、26.1%（4 社に 1 社程度）は新たな人材確保をせず導入部署の既存人材だけで対応した、とされています（第 1 部第 2 章第 3 節。調査の実施主体は白書本文の図表注記をご確認ください）
この 2 つを並べると、外から人を採る前提が成り立ちにくく、結果として現場の人が自分で作る流れになっていることが読み取れます。加えて 2023 年以降は、生成 AI がコードの下書きとエラーの読み解きを引き受けてくれるようになり、最初の 1 本を書くまでの時間が短くなりました。
ただし、統計は「内製が正解だ」と証明するものではありません。数字が示しているのは、社内で人を確保する企業が多いという事実だけです。自分の現場で何を内製し、何を買うかは 3 章の 4 つの問いで決めてください。当サイトは白書 PDF の該当図表番号までは確認できていないため、数値を引用する際は下の参考文献から原典にあたることをおすすめします。
8. 次に読む 3 つの入口
目的によって、次に開くページが変わります。
- Python 自体をこれから学ぶ → 製造業エンジニアのための Python 学習ロードマップ。基礎から現場 PC で動くアプリまでの順序と、会社の PC で最初に詰まる壁をまとめています
- やることは決まっていて、組織を動かしたい → 「外注1年」を「内製1ヶ月」に変える方法。外注が高くつく構造、社内提案の材料、段階的に進めるためのフェーズ設計を扱っています
- 今すぐ手を動かしたい → 4 章の該当ルートから各記事へ。実装手順・落とし穴・動作確認済みのコードはそちらにあります
本記事は、どの入口に進むかを決めるための地図です。読んだ結果「これは Python でやる話ではなかった」と分かったなら、それも成果だと考えています。作らずに済ませた工数は、そのまま現場の時間として残ります。
当サイトの方針、運営者の専門領域、AI の利用方針は サイトについて にまとめています。