GDPRと産業IoT：予知保全チームが知るべきこと

コンプライアンスの盲点

振動センサーは個人データを収集していない——本当にそうでしょうか？

ほとんどのプラントエンジニアはGDPRをマーケティングとHRの問題と考えています。しかし予知保全システムがオペレーターの行動、シフトパターン、人員に紐づいた設備の割り当て、またはIoTゲートウェイのIPアドレスでさえも記録した瞬間に、GDPR第4条に基づく個人データを処理していることになります。

欧州データ保護委員会が2025年に実施した調査では、**産業IoT展開の43%**に少なくとも一つの認識されていないGDPRコンプライアンスのギャップがあることが判明しました。罰則は理論的なものではありません。あるドイツの製造業者は、適切な同意なしに個々のオペレーターのパフォーマンスを追跡した監視システムにより、2025年に120万ユーロの罰金を科されました。

PdMが個人データと交わる点

予知保全の文脈で実際に個人データとなるものを示します。

明確に個人的なもの

オペレーターのログイン資格情報とセッションログ
個人に紐づいたシフト割り当て記録
作業指示の割り当て（「オペレーターSchmidtが設備41の軸受を交換した」）
モバイルアプリのプッシュ通知トークン
アラートルーティングのためのメールアドレス

グレーゾーン

特定のシフト中の機械運転パラメーター（間接的にオペレーターを特定できる）
技術者名を含む保全ログ
設備イベントと照合されたアクセスバッジ記録
機械エリアのビデオフィード（設備監視を目的としていても）

個人データでないもの

センサーからの生の振動、温度、圧力の読み値
MLモデルの予測と異常スコア
設備の健全性指標
集計された生産メトリクス

GDPR準拠のPdMのための6つの原則

1. データ最小化——必要なものだけを収集する

原則： 必要かつ適切で、目的に限定された個人データのみを処理する（第5条(1)(c)）。

実践において：

センサーデータはオペレーターの帰属を必要としません。ポンプ7Aからの振動の読み値はポンプに関するものであり、操作している人に関するものではありません。
CMMSの統合がオペレーター名を作業指示に取り込む場合、PdMにその名前が必要か、それとも保全が実施されたという事実だけが必要かを判断してください。
セキュリティ監査で必要でない限り、MQTT/OPC-UAの接続ログからIPアドレスを削除してください。

Prevlyのアプローチ： センサーの読み値はasset_idとtenant_idのみで保存されます。時系列データにオペレーターの身元は付与されません。作業指示は、顧客が人員追跡を明示的に有効にしない限り、個人ではなく役割を参照します。

2. 目的制限——なぜかを定義する

予知保全のために収集されたセンサーデータは、別の法的根拠なしにオペレーターのパフォーマンス監視に転用できません。これは明白に聞こえますが、以下の場合に常に起こります。

プラントマネージャーが「どのシフトで設備故障が多いか？」と尋ねる
人事部が技術者の対応時間を評価するために保全ログを要求する
保険会社がオペレーターレベルのインシデントデータを求める

ベストプラクティス： 展開前に処理活動記録（ROPA）で処理目的を文書化してください。Prevlyのデータ処理契約（DPA）は、処理を設備の健全性予測と保全最適化に明示的に限定しています。

3. 保持——データを抱え込まない

原則： 個人データは必要な期間を超えて保持してはならない（第5条(1)(e)）。

PdMの課題： MLモデルはより多くの履歴データで改善します。残存寿命予測のためのWeibull-RNNは2年以上の故障履歴から恩恵を受けます。しかし2年分のオペレーターログが必要でしょうか？

段階的な保持戦略： | データ種別 | ホットストレージ | コールドアーカイブ | 削除 | |---|---|---|---| | センサーの読み値 | 90日 | 2年（S3 Parquet） | アーカイブ期限後 | | ML予測 | 1年 | 3年 | アーカイブ期限後 | | 監査ログ（ユーザーID付き） | 90日 | 1年 | 義務的削除 | | オペレーターの作業指示 | 30日 | 法的要件に準拠 | ポリシーに準拠 | | 集計統計 | 無期限 | — | 削除なし（匿名化済み） |

4. マルチテナンシーの分離——御社のデータは御社のもの

マルチテナントSaaSにおいて、最大のGDPRリスクはハッカーではなく——テナントAのデータをテナントBに漏洩させるソフトウェアのバグです。

GDPRグレードの分離のための要件：

行レベルセキュリティ（RLS）： すべてのデータベースクエリは認証されたテナントに自動的にスコープされます。アプリケーションレベルのフィルタリングではなく——データベースで強制されます。
保存時の暗号化： テナントごとの暗号化キー（または最低限、AES-256を使用したテナントごとの論理的な分離）。
ネットワーク分離： プレミアムテナントは専用インフラを必要とする場合があります（GDPRはこれを義務付けていませんが、リスクを嫌う業界は要求します）。
監査証跡： 誰がいつどのデータにアクセスしたか。SOC 2 Type IIはこれを副次的な効果として提供します。

5. 国境をまたぐデータ転送——データはどこに存在するか

シュレムスII以降、EU域外への個人データの転送には標準契約条項（SCC）または十分性認定が必要です。

産業IoTでは、以下の場合に重要です。

クラウドプロバイダーがEU域外にデータセンターを持つ場合
PdMベンダーがEU域外でデータを処理する場合
エッジデバイスがベンダーの米国ベースのサポートシステムに診断情報を送信する場合

解決策： EUデータ居住オプションを持つプラットフォームを選択してください。PrevlyのインフラはデフォルトでEUリージョンで稼働し、DPAにデータ居住の保証があります。

6. データ主体の権利——エンジニアにも適用されます

保全エンジニアには以下の権利があります。

個人データへのアクセス（第15条）
不正確なデータの訂正（第16条）
データの消去（「忘れられる権利」）（第17条）
機械可読形式でのデータのポータビリティ（第20条）

エンジニアが会社を辞めて削除を要求した場合、PdMシステムは保全履歴を保持しながら過去の作業指示から名前を削除できますか？

初日からこれを設計に組み込んでください。 GDPRコンプライアンスを後付けするよりはるかに難しいです。

チェックリスト

EUで予知保全を展開する前に：

[ ] PdMデータ処理のためのROPAエントリ。 センサーの読み値、ML予測、作業指示、およびオペレーター関連データを含む、すべてのPdM関連データをカバーする専用エントリを処理活動記録に作成してください。法的根拠（設備監視には通常正当な利益、オペレーター追跡には同意）、データカテゴリ、受信者、保持期間を含めてください。これは250人以上の従業員を持つ組織には第30条に基づき義務付けられており、小規模組織にも強く推奨されます。
[ ] PdMベンダーとのDPA締結。 データ処理契約には、ベンダーの役割（処理者）、処理されるデータの種類、セキュリティ対策、サブプロセッサーの開示、および契約終了時のデータ削除手順を明記する必要があります。第28条に基づき、十分な保証を持つ処理者のみを使用することが義務付けられています。証拠として最新のSOC 2 Type IIレポートまたはISO 27001認証書をベンダーに求めてください。
[ ] センサーと個人データの移動を示すデータフローマップ。 すべてのホップを図解してください：センサー → エッジゲートウェイ → クラウドインジェスト → データベース → MLパイプライン → アラートエンジン → 通知チャネル。各ホップで、個人データが存在するか、転送時の暗号化（TLS 1.2+）は何か、データが国境を越えるかを記録してください。このマップはDPIAと監督機関からの問い合わせへの対応の両方に不可欠です。
[ ] 個人データの自動削除を含む保持ポリシー。 手動のクリーンアップに頼らないでください。自動保持ルールを設定してください。90日でセンサーの読み値をアーカイブし、ユーザーIDを含む監査ログを12か月で削除し、退職時に作業指示のオペレーター参照を匿名化する。削除プロセスをテストしてください——ステージングで実行し、個人データが定義されたウィンドウ内にバックアップから実際に削除されることを確認してください（GDPRはバックアップの即時削除を要求していませんが、文書化されたタイムラインが必要です）。
[ ] RLSの検証——マルチテナント分離はテスト済み、文書化だけではない。 クロステナントデータアクセスを特に狙った侵入テストを実施してください。つまり：テナントAとして認証し、すべてのAPIエンドポイント、直接データベース接続、エクスポート機能を通じてテナントBのデータにアクセスを試みる。データベースレベルの行レベルセキュリティは、アプリケーションのバグに関係なくこれを不可能にするはずです。テスト結果を文書化してください。
[ ] Webダッシュボードのクッキー同意。 そう、保全ダッシュボードもカウントします。ブラウザで実行されてクッキーを設定したり分析を使用したりする場合（内部分析でも）、細かい承認・拒否オプションを備えたGDPR準拠の同意バナーが必要です。「厳密に必要な」クッキー（セッション認証）は同意を必要としません；分析・追跡クッキーは必要です。
[ ] 侵害通知計画——監督機関への72時間以内の報告。 エスカレーションチェーンを定義してください：誰が侵害を検知し、誰が重大度を評価し、誰がDPOに通知し、誰が監督機関に申告するか。72時間の時計は侵害を「認識した」ときから始まります——調査が終わってからではありません。監督機関の必須フィールドで事前に通知テンプレートを準備しておいてください。
[ ] 大規模処理や自動意思決定を使用する場合はDPIAを完了。 データ保護影響評価は、大規模監視（何千ものセンサー、複数の施設）や個人に影響する自動決定（作業指示の割り当て、パフォーマンス関連メトリクスなど）を含む高リスクな処理の場合に第35条に基づき義務付けられています。DPIAはリスク、軽減措置、および残存リスクの受け入れを特定すべきです。

避けるべき一般的な間違い

産業IoT展開でGDPRの問題を引き起こすパターンが3つあります。

すべてのセンサーデータをデフォルトで非個人と扱うこと。 生の振動データは確かに非個人です。しかしシフトスケジュール、オペレーターのログイン、保全の割り当てと結合した瞬間に、関連付けによって個人データになります。最も安全なアプローチ：センサーデータと人員データを別々のデータストアに保持し、明示的に必要かつ文書化された目的がある場合にのみ結合する。

アプリケーションレベルのアクセス制御に頼ること。 マルチテナント分離がアプリケーションコード（「WHERE tenant_id = ?」）で強制されている場合、バグ一つですべてのテナントが露出します。データベースレベルの行レベルセキュリティがGDPRグレードの標準です——アプリケーションロジックとは独立して、クエリ実行レイヤーで分離を強制します。すべてのクエリ、すべてのAPIコール、すべてのエクスポートがデータベース自体によってスコープされます。

個人データの削除能力がないこと。 多くのPdMシステムはMLトレーニングには優れているが消去の権利に問題があります、追記専用の時系列ストレージのために設計されています。作業指示と監査ログのオペレーターIDを（「deleted_user_」に置換することで）匿名化でき、MLモデルが必要とする保全履歴を破壊しないよう、スキーマを設計してください。

結論

GDPRはイノベーションに反対するものではありません。それはデータアーキテクチャについて考えることを強制するフレームワーク——本来どにかく本番PdMシステムのために行うべきことです。コンプライアンスを設計上の制約（後付けではなく）として扱う企業は、よりクリーンなアーキテクチャ、より優れたデータガバナンス、そして顧客が本当に信頼するシステムで終わります。

PrevlyはGDPRファーストで構築されました：行レベルセキュリティ、段階的な保持、EUデータ居住、同意ゲートの分析、データエクスポートAPI。産業IoTにおいて、信頼はオプションではありません——それは最初のパイロットの前提条件です。