生成 AI を製造業の内製開発で使う実戦ガイド — Claude / ChatGPT / Copilot 対応

1. はじめに — なぜ製造業で生成 AI なのか

製造業の内製化が進まない最大の理由は「人手と時間が足りない」ことでした。生成 AI は、その制約を緩めます。本サイトの運営で取った作業ログベースでは、コーディング・ドキュメント作成・調査の所要時間が、生成 AI 併用で概ね1.5〜3 倍に加速するケースが珍しくありません（あくまで個人の作業ログに基づく主観的な観察で、業界統計に基づく数値ではありません）。

本記事は、本サイトの運営で生成 AI を継続的に活用してきた経験を、製造業エンジニア向けに一般化したものです。想定読者は次の 3 層です:

• 生産技術・設備保全のエンジニア: Python は入門書レベルで、コーディング効率化に生成 AI を使いたい
• 社内 SE・情報システム部: 業務ツールを社内で試作したい / 上司への稟議書に説得材料が欲しい
• 研究開発・品質管理: データ解析・レポート作成の負荷を減らしたい

いずれの読者にとっても、共通の悩みが「情報漏洩リスク」です。本記事は §3 でこのリスクの具体的な回避方法（伏字化コード実例つき）を掘り下げます。

2. 主要な生成 AI ツールの選び方

2026 年時点で、製造業エンジニアが押さえておくべき主要ツールは次の 4 系統です。まずは比較表で全体像を掴んでから、自社の条件に合うものを選んでください。

⚠️ 「Claude Code」は IDE 統合型ではなく、CLI（ターミナル）で動くエージェント型ツールです。ファイルシステムを直接読み書きしたり、複数ファイルを横断で編集したりできる代わりに、GitHub Copilot のような「エディタ内のリアルタイム補完」とはユースケースが違います。「エディタ補完」なら Copilot / Cursor、「ターミナルから複数ファイル操作」なら Claude Code、と分けて理解するのが実務では混乱しません。

個人運用: Claude / ChatGPT のいずれか月額契約 + IDE 系 1 つ（Copilot or Cursor）の組み合わせが標準です。
業務運用: 会社が契約した法人プラン（社内統合型 + IDE 統合型 Business 版）を使い、個人アカウントで業務情報を扱わないのが鉄則です。個人利用と業務利用のアカウントを混ぜないことが、監査時のトラブル回避にも直結します。

3. 情報漏洩リスクと回避ガイドライン

製造業エンジニアにとって、最大の悩みは情報漏洩リスクです。「業務コードを生成 AI に貼って質問していいのか」を、判断軸を持って扱う必要があります。ここが本記事で最も紙面を割いた章です。

3.1 「学習に使われるか」と「保管されるか」を分けて考える

まず前提として、多くの読者が混同しがちな 2 つの概念を分けます。

• 学習に使われる: 送ったデータをベンダーの次世代モデルの訓練データとして使うこと。使われれば、他社ユーザーへの回答に自分の入力が滲む可能性がある
• 一時的に保管される: 送ったデータをベンダー側が数十日程度サーバに保管すること（不正利用検知・カスタマーサポート応答・監査目的）。学習には使わなくても、ベンダー内部では一定期間残る

⚠️ 「学習に使わない ≠ 保管もされない」 です。法人プランで「学習には使わない」が保証されていても、不正利用検知目的の一時保管は行われる場合があります（ベンダー・プランごとに保管期間は異なり、Zero Data Retention オプションを別途契約できるケースもあります）。本当に一切残さないでほしいなら、Zero Retention 契約が可能かベンダー確認するか、社内統合型（Azure OpenAI 等・テナント内完結）を選ぶのが実務の答えです。

注: 上記のプラン名（ChatGPT Business など）は 2026 年 9 月時点で確認した名称です。生成 AI 業界のプラン名は変更が頻繁で、以前は「ChatGPT Team」と呼ばれていた法人プランが 2025 年に「ChatGPT Business」へ改称されるなどの動きがありました。導入直前には必ず各ベンダーの公式ページで最新名称・条件を確認してください。

3.2 業務情報を貼る前のチェックリスト

業務情報を生成 AI に貼る前に確認すべきチェック項目を、判断の粒度を上げて表にしました。

NG が 1 つでもあれば、「公開情報レベルへの抽象化」「数値だけのダミー化」「社内統合型 AI への切り替え」のいずれかで対処します。この機械的なチェックを毎回回すことが、事故を防ぐ最も現実的な方法です。

3.3 伏字化コード実例（Before / After）

抽象論だけでは実務に落ちないので、業務コードを AI に貼る前の「伏字化」の具体例を示します。以下はローカル PC の Modbus ロガーで「実 IP・実型番・実閾値・実顧客名」が入った Before と、それを伏字化した After です（なお、この Before / After に登場する IP・型番・数値・顧客名は、他記事と同様すべて本記事用に作成した架空のダミーです。「○○」「□□」「△△」は伏字を表します）。

Before（そのまま AI に貼ってはいけない）

# src/logger.py — 本番用（AI に貼らない）
"""B 組立ライン向け Modbus ロガー。○○電機の顧客向けデバッグ用。"""
import socket
from pymodbus.client import ModbusTcpClient

# ⚠️ 実 IP と実型番と顧客固有パラメータ
HOST = "10.24.135.87"            # B 号機の PLC（△△電機製 CPU ユニット □□-8000）
PORT = 502
BAD_TEMP = 187                   # ○○樹脂の劣化開始温度
BAD_PRESSURE = 4.32              # ラインが停止する圧力（社内実測）
CUSTOMER = "○○電機・第三工場"

def read_line_B():
    client = ModbusTcpClient(HOST, port=PORT)
    ...

After（AI に貼っていい伏字化版）

# AI 相談用（伏字化・公開レベル）
"""ある製造ライン向けの Modbus ロガー。"""
import socket
from pymodbus.client import ModbusTcpClient

# ダミー値（実際の値は伏せる）
HOST = "192.168.10.20"           # PLC の IP（プライベート IP 例）
PORT = 502                        # Modbus/TCP 標準
BAD_TEMP = 100                   # 温度の閾値（ダミー）
BAD_PRESSURE = 2.5               # 圧力の閾値（ダミー）

def read_from_plc():
    client = ModbusTcpClient(HOST, port=PORT)
    ...

ポイントは 3 つです:

1. 固有名詞は完全に削除・汎用化: 顧客名 / 型番 / ライン名 / 部品名を消す。「B 組立ライン」「○○電機」「△△電機製 CPU ユニット □□-8000」は全部匿名化
2. 数値はダミーに置換: 実測値・閾値・座標・寸法は「型（int/float）」だけ保ち、値は無関係のダミーへ
3. コメントも書き換える: 「○○樹脂の劣化開始温度」のような業務ドメイン知識が滲む記述をそぎ落とす

もう 1 つの実例として、業務ロジックの伏字化パターンも示します。

Before:

# 顧客 X 向けの受注データ処理
def process_order(order_id: str):
    # 型番が SKU-A100 なら通常配送、SKU-B200 なら特急便
    if order_id.startswith("SKU-A100"):
        return ship_normal(order_id)
    elif order_id.startswith("SKU-B200"):
        return ship_express(order_id)

After:

# 受注データ処理（伏字化・汎用化）
def process_order(order_id: str):
    # 2 種類の商品コードで配送手段を分岐する典型例
    if order_id.startswith("TYPE-A"):
        return ship_normal(order_id)
    elif order_id.startswith("TYPE-B"):
        return ship_express(order_id)

この伏字化を毎回手作業でやるのは面倒なので、テキストエディタの「置換」機能で、業務データが登場する文字列を機械的に置き換えるのが現実的です。頻出する固有名詞（組織名・取引先名・機器型番）を「伏字化辞書」として手元のメモに持っておくと、コピペ + 一括置換で数秒で仕上げられます。

3.4 「再現コード」戦略 — 業務課題を汎用題材で解く

そもそも伏字化ですら不安な業務コードは、「同じ問題構造を、汎用的な題材で再現したコード」を AI に渡すアプローチが有効です。機密性が高くて貼りづらい通信プロトコル実装の課題を、手元の socket + シミュレータで再現してから AI に相談するのが定石です。

例えば「特定機器との独自プロトコルで、応答が遅れると業務がタイムアウトする」問題を相談したいときは、業務コードを見せず、手元の Python シミュレータ（サーバとクライアントを両方書く）で同じ挙動を再現し、そのコードを AI に渡します。技術的な議論だけを引き出せて、業務情報は一切外に出ません。この戦略は、業務そのものが機密性の高い研究開発領域でも使えます。

「再現コードを書く工数のほうが高くつくのでは」と思うかもしれませんが、副次的な効果として、再現コードは記事化・社内共有・OSS 化に転用できるという利点があります。GenbaPy の記事群も、この再現コード戦略で書かれています。

4. 用途別の使い分け

4.1 コーディング

• 新規実装の下書き: 「pymodbus でレジスタを 1 秒ごとに読んで CSV に書く最小コード」のように依頼 → 改造
• 既存コードのレビュー: 「このコードに 24 時間運用で気をつけるべき点があるか」と聞く
• エラー解析: スタックトレースを貼って原因を聞く
• テストコード生成: pytest のテストパターンを生成
• リファクタリング: 「この関数を読みやすくしてほしい」

4.2 ドキュメント作成

• 仕様書のドラフト作成（章立て、用語定義、要件項目）
• ユーザーマニュアルのスクリーンショット説明
• 議事録の整形・要約
• 稟議書、社内提案書の構成案

4.3 調査・学習

• 新しい技術の概念整理（「OPC UA を 5 分で説明して」）
• 複数候補の比較（「pymodbus と minimalmodbus の違い」）
• 仕様書の難解部分の解説
• 英語ドキュメントの読解補助

4.4 コミュニケーション

• 取引先メールのトーン調整、英文化
• 新人や他部署向けの説明文の作成
• 長文資料の要約

5. プロンプト設計の基本

「どう聞くか」で出力の質は大きく変わります。製造業エンジニアにとって特に効くプロンプトの工夫を整理します。

5.1 役割を明示する

あなたは製造業向けに 24 時間動く Python 監視アプリを実装する経験豊富なエンジニアです。
以下の要件で、tkinter ベースの監視アプリの最小実装を提示してください。

要件:
- TCP/IP で 192.168.1.10:5020 から 1 秒ごとに値を取得
- 値が 80 を超えたら赤色のアラート表示
- ログを 14 日分ローテーション保存
- 異常終了からの自動復旧

5.2 制約と非機能要件を伝える

「現場 PC は Windows 10、Python は 3.11、ネットは隔離されておりオフラインインストール必要、文字コードは CP932 が混入する」のような制約は、最初に伝えます。これにより、的外れなライブラリ提案や、現場で動かないコードを避けられます。

5.3 失敗例も渡す

過去にうまく動かなかったコードと、そのときのエラーメッセージを一緒に渡すと、AI は同じ罠を踏まないコードを提案できます。

5.4 1 ターンで全部聞かない

長い回答が必要な要求は、複数ターンに分けるとミスが減ります。「まず構造を提案して」「次に具体的なコードを書いて」「最後にエッジケースをチェックして」と段階的に進めます。

6. AI を「設計レビュー」で使う

生成 AI の使い方で効果が出やすいものの 1 つが、設計の批判的レビューを依頼することです。

以下の Modbus ロガーの設計を批判的にレビューしてください。
24 時間連続稼働、現場 PC（Windows）、書き込み先は社内ファイルサーバー。

設計:
- 1 秒ごとに 5 レジスタ読み、CSV にそのまま追記
- 例外時は print してリトライしない
- ログは標準出力のみ
- 単一スレッドで動作

懸念点を 5 つ以上挙げ、それぞれ修正提案を添えてください。

人間のレビュアーに頼みづらい時間帯でも、AI なら即座に複数の視点でフィードバックをくれます。「自分の盲点を埋める道具」として極めて強力です。

7. AI 出力の取扱い注意点

7.1 ハルシネーション（虚偽生成）

AI は「もっともらしいが事実ではない」回答を返すことがあります。特に注意すべきは以下です。

• 存在しない関数 / 引数を提案する: 必ず公式ドキュメントで確認
• 古いバージョンの API を使う: ライブラリのバージョン明示で防げる
• 誤った技術的事実: 業界の慣習や仕様を確証なく述べる場合あり

7.2 動作確認は必須

AI 生成のコードは「動くだろう」ではなく「動くか確認した」状態で初めて使います。「動かしてみたら、思ったのと違う動作だった」は AI 活用で頻繁に起きます。テストを書いて回す習慣がないなら、AI 活用と同時に始めるのが推奨です。

7.3 知財とライセンス — 3 つのリスク層を分けて考える

AI 生成物の知財・ライセンス問題は、実務で見落とされやすい 3 つの層に分かれます。それぞれ対処法が違います。

① OSS ライセンスの意図せぬ混入: AI が学習データとして取り込んだ GPL / LGPL / AGPL のコードが、そっくりそのまま生成物に現れる可能性は否定できません。GitHub Copilot 集団訴訟（Doe v. GitHub）は、まさに Copilot が OSS コードを帰属表示なしに複製・提示することを争点にしており、2026 年時点でも米国連邦裁判所で係争中です。判決の方向性が確定するまでは、AI が生成した「特徴的なコード片」は必ずネット検索で類似実装がないか確認する、または License Scanner（scancode-toolkit 等）を CI に組み込むのが安全側です。

② AI 生成物自体の著作権帰属: 日本の文化庁は「AI が自律的に生成した文章・コードで、人間の創作的関与が認められないもの」は著作権が発生しないという見解を公式資料で示しています（文化庁「AI と著作権」）。実務的には、プロンプトで方向性を与え、生成結果を選別・修正したケースは人間の創作的関与ありとされ、逆に「AI に丸投げ」した成果物は権利主張が難しくなります。社外納品物に AI 出力を使う場合は、「どこを AI が生成し、どこを人間が修正したか」を後で説明できる状態にしておくのが安全です。

③ AI サービス利用規約と成果物の商用利用: 各 AI サービスの利用規約には「生成物の商用利用範囲」の条項があります。Claude / ChatGPT / Copilot はいずれも生成物の商用利用を認めていますが、「AI が生成したことを明示する義務」の有無や、「ユーザー入力を学習に使わない保証」はプランごとに違うため、業務利用前に必ず該当プランの規約を読み込む必要があります。

商用配布・顧客納品を含むケースでは、上記 3 層をそれぞれチェックしたうえで、社内の法務・知財担当と最終判断してください。「AI 出力だから権利が曖昧」ではなく、「意識的に権利を積む」姿勢が必要です。

8. 社内導入のステップ

個人で使うのと、組織で使うのは別物です。組織導入時のステップを整理します。

8.1 ポリシー策定

• 業務情報を入力してよいツール / 範囲
• 個人アカウントの業務利用の可否
• AI が生成したコード / 文章の社内取扱い
• 顧客向け成果物への AI 利用の開示有無

8.2 ツール選定

• 法人プランで契約することを大前提に
• SSO 連携（Microsoft Entra / Google Workspace）
• 監査ログ / 利用統計が確認できるか
• 社内 SharePoint / Confluence 連携の可否

8.3 教育とサポート

• 「プロンプトの書き方」を社内勉強会で共有
• 実例ベースの社内 FAQ を整備
• 「失敗例」も積極的に共有して、リスクを組織で学ぶ

9. 内製開発の標準ワークフロー例

参考までに、本サイトの運営で使っている標準的なワークフローを共有します。

1. 要件をテキストで整理: AI に渡す前に、人間が要件を文章化する
2. 設計案を AI と相談: 「この要件を満たす設計案を 3 つ提案して」 → 比較し選ぶ
3. 下書きを AI に書かせる: 選んだ設計をベースに、最小実装の下書きを作らせる
4. 自分で動作確認: 動かない部分を直し、エッジケースに対応
5. レビューを AI に依頼: 「24 時間運用の観点で」「セキュリティの観点で」レビューさせる
6. テストを書く: 期待動作をコードで固定
7. 本番投入: 段階的にロールアウト

このサイクルを回すことで、「自分一人ではできなかった」レベルのアウトプットが、現実的な時間で出せるようになります。

10. 「内製化との掛け算」

本サイトの主題でもある「外注 1 年を内製 1 ヶ月に」変える流れには、生成 AI が決定的な追い風になっています。Python の文法を完璧に覚えていなくても、設計思想と現場の要件を理解しているエンジニアなら、AI と協働してプロダクトを作れる時代です。

逆に言えば、「コードを 1 行も書けないが、業務を深く理解している現場担当者」が AI と組めば、これまでベンダーに発注していた小規模ツールは内製で作れるケースが増えます。

11. やってはいけないこと

• セキュリティ判断を AI に丸投げする: 認証・暗号化・権限設計は最終判断を人間が行う
• 規制対応を AI に任せる: 法律・規格・社内規程の解釈は専門家を経由する
• 動作確認なしの本番投入: AI 出力をそのままコピペで本番に流さない
• 「動いたから大丈夫」: テストとレビューを省略しない
• 業務固有情報の無防備な投入: 機密情報の取扱いは個人プランでも要注意

12. おわりに

生成 AI は道具です。優秀な道具ですが、「何を作るか」を決めるのも、「動くまで責任を持つ」のも人間の役割です。製造業エンジニアにとって、AI は「コードを書ける範囲を 2〜3 倍にする」「ドキュメント作成の苦痛をなくす」「ひとりで悩まない」ための強力な味方です。

導入するかしないかは、業種・企業規模・情報統制の要求水準によって判断が変わります。本記事のガイドラインを起点に、自分の業務文脈に合わせた使い方を見つけていってください。少なくとも、「情報漏洩リスクの管理」と「AI 出力の動作確認・著作権対応」の 2 つを押さえた上で使えば、生産性向上の道具として現実的な選択肢になる——というのが 2026 年 9 月時点での筆者の実感です。

⚠️ 本記事は 2026 年 9 月時点の情報に基づきます。生成 AI 業界は変化が速く、プラン名・料金・機能・法的取り扱いが数ヶ月単位で変わります。導入判断時は、必ず各ベンダーの公式ページで最新情報を再確認してください。