製造業で生成AIを使うとき、最も多い不安の一つが「機密情報を入力してよいか」です。図面、製造条件、不具合情報、顧客名、見積、個人情報などを扱うため、便利だからという理由だけで外部サービスへ入力することはできません。
結論は、「生成AIだから一律に禁止」でも「法人向けプランだから何でも入力可能」でもありません。情報の種類、利用サービスの契約と設定、保存・学習の扱い、アクセス権、利用目的を確認し、自社が許可した範囲だけで使います。
この記事は実務上の確認観点を整理するものであり、個別の法的判断を示すものではありません。契約、法令、顧客要求については、自社の法務・情報セキュリティ部門へ確認してください。
図：情報区分、契約・設定、利用目的、人の確認を通して入力可否を判断する流れ
まず入力情報を4段階に分ける
利用サービスを検討する前に、情報区分を決めます。次は一般的な例であり、自社の情報管理規程を優先してください。
| 区分 | 情報例 | 基本的な扱い |
|---|---|---|
| 公開情報 | Webサイト、公開カタログ、公開規格の引用可能部分 | 承認済みサービスで利用 |
| 社内情報 | 社内用テンプレート、一般的な業務手順 | 利用目的と環境を限定 |
| 機密情報 | 図面、製造条件、不具合、原価、未公開計画 | 契約・設定・権限を確認し個別承認 |
| 高機密・規制情報 | 顧客秘密、輸出管理、個人情報、安全保障関連 | 原則として専用環境と専門部門の判断 |
顧客から受領した情報は、自社の情報区分だけでなく、秘密保持契約、取引条件、目的外利用の禁止も確認します。
利用前に確認する7項目
1. 入力・出力がモデル学習に使われるか
サービス名が同じでも、個人向け、法人向け、APIで条件が異なる場合があります。「学習に使わない」という説明だけでなく、対象プラン、設定、例外、管理者操作を確認します。
2. データの保存期間と削除方法
入力内容、添付ファイル、会話履歴、監査ログがどこに、どれだけ保存されるかを確認します。利用者が画面上で削除しても、すべての保存先から即時削除されるとは限りません。
3. データの処理場所と再委託先
データが処理・保管される地域、サブプロセッサー、越境移転の条件を確認します。自社や顧客の規程で地域要件がある場合は重要です。
4. アクセス権と管理機能
誰が利用できるか、退職・異動時に権限を外せるか、共有リンクを制限できるか、管理者が利用状況を把握できるかを確認します。社内文書検索では、元文書の閲覧権限を引き継げることが必要です。
5. セキュリティと契約上の責任
暗号化、認証、監査報告、インシデント通知、データ処理契約、補償や責任範囲を確認します。サービスの技術仕様だけでなく、自社と提供者の役割分担を明確にします。
6. 出力の知的財産と第三者権利
生成された文章や画像の利用条件、第三者の著作権・営業秘密を侵害する可能性、入力データの利用権限を確認します。AI出力だから自由に利用できるとは限りません。
7. 記録と追跡ができるか
誰が、どの目的で、どの情報を使い、出力をどこへ反映したかを追跡できるようにします。品質文書や顧客向け資料では、最終確認者と使用した根拠も残します。
サービス選定時の確認票
提供者のWebページだけで判断せず、契約書、データ処理条件、管理画面の設定を照合します。「確認済み／要追加確認／要契約変更／対象外」で記録すると、未解決事項が見えます。
| 分類 | 確認項目 |
|---|---|
| データ利用 | 入力、出力、添付、フィードバックが学習や人手レビューに使われるか |
| 保存 | 保存期間、バックアップ、削除要求、契約終了時の扱い |
| 処理 | 保管・処理地域、再委託先、越境移転 |
| 認証 | SSO、多要素認証、端末制限、共有制限 |
| 権限 | 管理者、利用者、文書ごとの閲覧権限、異動時の剥奪 |
| 監査 | 利用ログ、管理者ログ、ログ保存期間、エクスポート |
| 技術 | 暗号化、脆弱性対応、第三者認証、インシデント通知 |
| 契約 | 秘密保持、目的外利用、知的財産、責任分界、監査権 |
| 継続 | サービス停止、モデル・規約変更、データ返却と移行 |
「法人向け」という名称だけでは要件を満たすとは限りません。自社が利用するプランと設定を特定し、設定画面の証跡と確認日を残します。
「匿名化すれば安全」とは限らない
会社名や製品名を削除しても、設備型式、特殊な工程条件、発生日、顧客地域などの組み合わせから対象が推測されることがあります。匿名化ではなく、必要最小限化として考えます。
たとえば、文章表現の修正だけなら、固有名詞、数値、図番、顧客条件をダミーへ置換できます。過去不具合の分析なら、承認された閉じた環境を使い、対象データと利用者を限定する方が適切な場合があります。
許可・承認・禁止の具体例を作る
利用者が毎回規程を読み解かなくてもよいように、業務例で示します。
| 区分 | 業務例 | 条件 |
|---|---|---|
| 許可 | 公開資料の要約、一般的なメール構成、ダミーデータでの練習 | 承認済みアカウントを使用する |
| 事前承認 | 社内手順の草案、匿名化した不具合分析、社内文書検索 | 指定環境、対象者、データ範囲、ログを確認する |
| 禁止 | 未公開図面、顧客秘密、個人情報を個人アカウントへ入力 | 例外を自己判断しない |
| 専門審査 | 輸出管理、安全保障、規制対象データ、製品合否への使用 | 法務、セキュリティ、専門部門が判断する |
同じ業務でも、公開情報だけを使う場合と実データを使う場合で区分が変わります。目的、情報、環境の三つを組み合わせて判断します。
製造業向け生成AI利用ルールの例
ルールは、禁止事項だけでなく、安全に使う方法を具体的に示します。
入力
- 会社が承認したアカウントとサービスだけを使う
- 情報区分を確認し、必要最小限の情報だけを入力する
- 顧客秘密、個人情報、図面、条件値は承認なしに入力しない
- 添付ファイルに非表示シート、コメント、メタデータがないか確認する
- 個人アカウントへ業務データを保存しない
出力
- AI出力を事実や社内承認済み情報とみなさない
- 数値、規格、契約、品質・安全条件は原典と照合する
- 顧客提出、標準書改訂、合否判定は責任者が承認する
- 出典を確認できない記述を重要文書へ使わない
- AIを利用したこと、確認者、修正内容を必要に応じて記録する
運用
- 利用可能業務と禁止業務を例示する
- 問い合わせ窓口と事故時の報告先を決める
- 利用状況と誤りの事例を定期的に共有する
- サービスの規約・設定変更を定期確認する
- 退職、異動、委託終了時に権限を見直す
ルールを技術的な制御で支える
教育だけでは、個人アカウントや未承認サービスを使う「シャドーAI」を完全には防げません。SSOと多要素認証、利用者グループ、添付・共有制限、文書アクセス権の継承、ログ監視などを組み合わせます。必要に応じて、DLPやWebアクセス制御で機密情報の送信を検知・制限します。
一方、制限を増やしすぎると、現場が承認外の手段へ流れることがあります。安全に使える承認済み環境、申請窓口、回答期限を用意し、未承認利用を見つけたときは目的と業務課題も確認します。
安全に始める3つの方法
公開情報だけで業務手順を試す
まずは公開資料やダミーデータで、要約、分類、テンプレート作成を試します。業務効果が見えない段階で機密情報を扱う必要はありません。
入力情報を置換する
文章の構成やプロンプトを検証する段階では、会社名、製品名、条件値をダミーへ置換します。実データでしか評価できない部分を分けます。
承認された専用環境で限定PoCを行う
機密文書を使う必要がある場合は、契約、保存、権限、ログを確認した環境で、対象者とデータを限定します。製造業への生成AI導入・PoCの進め方も参考にしてください。
教育は「判断できるか」まで確認する
年1回の説明だけでなく、実際の入力例を使って、許可・事前承認・禁止を判断する演習を行います。添付ファイルの非表示シート、画像に写り込んだ図番、複数情報の組み合わせによる再識別など、見落としやすい例を含めます。
誤入力を想定した机上訓練では、利用者がどこへ連絡し、管理者がログと共有範囲をどう確認し、法務・顧客対応へどう引き継ぐかを試します。報告の速さを責める運用にすると隠蔽につながるため、早期報告を優先する方針も明示します。
誤って入力した場合の初動
入力事故に気づいたら、自己判断で会話を削除して終わらせず、社内ルールに従って報告します。
- 追加の入力と共有を止める
- 利用サービス、日時、アカウント、入力内容を記録する
- 情報セキュリティ、上司、必要な部門へ連絡する
- 共有設定、会話履歴、APIキーなどの影響範囲を確認する
- サービス提供者への削除・調査依頼を検討する
- 顧客・本人への連絡要否を専門部門が判断する
- ルール、教育、技術的制御を見直す
まとめ
製造業で生成AIへ機密情報を入力できるかは、情報区分と利用環境を組み合わせて判断します。学習利用の有無だけでなく、保存期間、処理場所、権限、契約、ログ、第三者の権利まで確認が必要です。
安全条件を決めたうえで、最初は公開情報やダミーデータを使い、人が確認できる文書業務から始めます。具体的な活用候補は製造業のAI・生成AI活用事例15選をご覧ください。
製造業向けの講座については、製造業DX実践シリーズをご確認ください。