LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

機器やソフトウェアが生み出すデータを、誰がどこまで使えるのか。クラウドを別の事業者へ移したいとき、どこまで自由に動けるのか。この二つに正面から答えようとしているのが、EUの「データ法（Data Act）」です。個人データを守るGDPRとは目的が異なり、こちらはデータを「使いやすくする」「動かしやすくする」ことに軸足を置いています。

本記事では、EUと接点のある製品・サービスを持つ事業部門や情報システム部門の担当者に向けて、EUデータ法の柱、クラウド乗り換えのルールと時期、日本企業に関わってくる場面、そして受託・委託開発で押さえておきたい実務のポイントを整理します。制度の一般的な整理であり個別の法的な助言ではありませんので、実際の判断は公式文書と専門家への確認を組み合わせて進めてください。

EUデータ法とは——データを「使える」「動かせる」状態にする規則

EUデータ法は、正式にはRegulation (EU) 2023/2854として定められた、EUの規則です。2024年1月11日に発効し、原則としての適用が2025年9月12日に始まりました*1。ねらいは、産業データが特定の事業者の手元に閉じ込められがちな状況をほどき、利用者や他の事業者もそのデータを使えるようにすること。あわせて、クラウドなどのデータ処理サービスを別の事業者へ乗り換えやすくすることにも踏み込んでいます。

この規則が扱う範囲は広く、分野を限定しません。製造業やアグリテックのように機器からデータが上がってくる領域、クラウドやSaaSを提供する領域、そしてそれらを使う企業まで、立場ごとに関わり方が変わってきます。柱として押さえるとよいのは、次の四つでしょう。

GDPRと並べて考えると、性格の違いが見えやすくなります。GDPRは個人データの保護が主眼で、「守るための規律」が中心です。いっぽうデータ法は、産業データを含めて「流通させるための規律」に重心があります。もっとも、機器から上がるデータに個人に関わる情報が混ざることは珍しくありません。両方が同時にかかる場面がある、と捉えておくほうが無難でしょう。

コネクテッド製品のデータ共有——製造業・IoT開発への影響

第一の柱は、コネクテッド製品にまつわるデータです。工作機械、車両、家電、センサー付きの設備といった「つながる製品」が使われるなかで生まれるデータを、その製品の利用者が取り出せるようにする。さらに、利用者が望むなら第三者のサービス事業者へ渡せるようにする、という考え方が置かれています*1。

ここで実務に効いてくるのが、「取り出せる状態で作っているか」という点です。データがベンダー固有の形式でクラウドに囲い込まれていて、利用者からは画面越しにしか見られない——そうした設計だと、求めに応じるための改修が後追いで必要になります。設計段階でエクスポートの経路とデータ辞書を用意しておけば、追加開発の負担はずいぶん軽くなるはずです。

もう一つ気をつけたいのが、保守やアフターサービスの位置づけです。製品データを第三者が使えるようになると、修理や予防保全のサービスに新しい競争が生まれます。自社の保守ビジネスがデータの独占に支えられている場合、その前提が変わる可能性を見ておいたほうがよいでしょう。逆に、他社製品のデータを活用して保全サービスを組み立てる、という広がりも生まれます。

開発の見積りに関わる論点として、データの粒度と保持期間の設計も挙げておきます。取り出せるようにするといっても、一秒ごとの生データを何年も保持し、いつでも第三者へ渡せる状態を保つとなると、保管と転送のコストは膨らみます。どの粒度で、どこまで遡って渡せるようにするのか。この線引きを製品企画の段階で決めておけば、基盤の規模も見通しやすくなるわけです。

関連して、機器側のセキュリティ要件も同時期に動いています。EU域内で無線機器やIoT製品を売る場合の要件は別の法令で定められており、あわせて確認しておくと重複した作業を避けられます。詳しくは組込み・ファームウェア開発の委託で、機器側の開発体制の作り方を整理しています。

クラウドの乗り換え——2027年1月に切替手数料はゼロへ

日本企業にとって影響がわかりやすいのは、三番目の柱、クラウドなどデータ処理サービスの乗り換えに関するルールです。契約の解除から実際の移行までの手続き、移行にかかる期間、そして手数料の扱いが定められました。とりわけ手数料は、段階的に縮小していく形が採られています*2。

通常の利用料金や、期間契約を途中で解約したときの違約金は、この切替手数料とは別の話です。ここを混同すると社内の説明がずれてしまうため、「乗り換え作業への課金」と「サービス利用の対価」を分けて整理しておきましょう。

移行のしやすさが制度として押し出されると、選定の見方も変わってきます。従来は「出るときにいくらかかるか」が壁でしたが、その壁が低くなるぶん、データ形式・API・運用の作り込みといった技術面の移しやすさが前面に出てくるわけです。移行の実務そのものは、システム移行・データ移行を外注する進め方や、SaaSのベンダーロックイン脱却で扱っている論点とそのまま重なります。

日本企業に関わる場面——どこで接点が生まれるか

「EUの規則だから自社は関係ない」と早合点しないほうがよい理由は、接点の生まれ方が複数あるからです。代表的な場面を挙げてみます。

• EU域内で、つながる製品（機器＋関連サービス）を販売している
• EU域内の顧客に、クラウドやSaaSといったデータ処理サービスを提供している
• EUの事業者が提供するクラウドを、自社の業務やサービス基盤として使っている
• EUの取引先から、機器データの提供や共有を求められる立場にある
• EUに子会社や工場があり、そこで得たデータを日本側で使っている

このうち、自社が「守る側」になるのか「求める側」になるのかで、やることは変わります。提供者の立場なら、データを取り出せる経路や乗り換え時の手続きを整える作業が中心。利用者の立場なら、既存契約のどこに縛りがあるのかを洗い出し、乗り換えの余地を確かめる作業が先に来るでしょう。

グループ会社をまたぐ構成にも目を向けておきたいところです。EUの現地法人が集めたデータを日本の本社が分析している、という形はよくあります。この場合、現地法人が負う義務と、日本側で行う処理の関係を整理しないと、どちらが何を担うのかが宙に浮いてしまいます。データの流れを図にして、境界ごとに責任を書き込む——地味な作業ですが、後の説明責任を大きく左右します。

もう一つ見落としがちなのが、契約書の点検です。データの帰属、持ち出しの可否、移行時の協力義務、そして不当とみなされうる条項の扱い——このあたりは、規則の適用が始まったあとの新規契約だけでなく、既存契約の見直しにも関わってきます。法務と開発が別々に進めると抜けが出やすいところなので、棚卸しの段階から一緒に見るのが得策です。

GDPR・EU AI規制との重なりをどう整理するか

EUの制度は、目的の異なるルールが層になって重なります。個人データの保護はGDPR、AIの提供や利用にはEU AI規制（AI Act）、金融分野のシステム運用にはDORA、重要インフラのセキュリティにはNIS2指令。データ法はそのなかで、「データの流通と移動」という軸を担っています。

実務では、同じシステムに複数の要求が同時にかかる場面が出てきます。たとえば、工場設備のデータを分析基盤に集めてAIで予測を行い、その基盤はEUのクラウド上にある、という構成なら、データ法・GDPR・AI規制のいずれも視野に入るわけです。ばらばらに対応するとコストが膨らむため、「どのデータが、どの経路で、どこに置かれ、誰が触れるのか」を一枚の図に落として共有するところから始めるのがよいでしょう。

この整理は、セキュリティ設計の文書づくりとも重なります。クラウドを跨ぐ構成の設計はクラウド移行のセキュリティ設計・対策でも触れているとおり、後追いで足すより初期に織り込むほうが安く済みます。

対応の進め方——棚卸しから設計への反映まで

やることが多岐にわたるため、順番を決めて進めるほうが迷いません。四つの段階に分けて考えてみましょう。

第一段階は、接点の棚卸しです。製品・サービスの一覧に対して、EU域内で売っているか、EUの顧客が使っているか、EUのクラウドに載っているか、という三つの問いを当てます。ここで一つも当たらなければ、当面の優先度は下げてよいはずです。逆に当たるものがあれば、その系統だけを対象に絞って次へ進みます。全社一律で身構えると、手が回らなくなりがちなのです。

第二段階は、立場の切り分けになります。同じ会社でも、機器を売る事業ではデータを保有する側、業務でクラウドを使う場面では利用する側、という具合に立場が変わります。立場ごとに求められることが違うため、ここを曖昧にしたまま対策を並べると的が外れてしまいます。事業単位・システム単位で表に落として、担当部門まで書き添えておくとよいでしょう。

第三段階は、現状の技術的な棚卸しです。データの取り出しに使える手段（API・バッチ出力・管理画面からのダウンロード）、項目の意味をまとめた資料の有無、特定サービス固有の機能への依存度。この三点を洗い出すと、足りない部分がそのまま改修の候補になります。既存システムの現状分析はクラウド移行アセスメントの考え方が流用できます。

第四段階が、設計と契約への反映です。洗い出した不足を、次の開発案件や保守の計画に載せていきます。新規開発なら最初から要件に含める。既存システムなら、影響の大きいところから順に手を入れる。契約の見直しは法務と並走し、移行時の協力義務や引き渡すデータの形式を文言として残します。この段階まで来れば、制度の動きに振り回されずに済むはずです。

受託・委託開発で押さえる実務ポイント

受託・委託開発の観点では、次の五点を初期の要件に入れておくと、後の手戻りを抑えられます。

• データの取り出し経路を標準機能として作る：エクスポートAPIや定期出力を、追加開発ではなく前提の機能として設計に置く
• データ辞書と形式を文書化する：項目の意味・単位・更新頻度をまとめておくと、第三者への提供時にそのまま使える
• 移行容易性を非機能要件に入れる：特定サービス固有の機能に寄りかかる部分を洗い出し、代替の道筋を残す
• 契約に協力義務と手順を書く：移行時の作業分担、期間、引き渡すデータの形式を、あらかじめ合意しておく
• ログと権限を分けて管理する：誰がどのデータに触れたのかを追える状態にしておくと、共有を求められたときの説明が容易になる

これらは、規則への対応というより、そもそも運用と移行を軽くする設計です。制度が求めるからやる、という受け止め方より、「動かしやすい仕組みにしておくと選択肢が増える」と捉えたほうが社内の合意も取りやすいのではないでしょうか。オンプレミスからの移行を含む全体設計はクラウド移行戦略と移行方式（6R）の選び方も参考になります。

体制面では、法務・情報システム・事業部門の三者が同じ資料を見ている状態を作れるかどうかが分かれ目になります。外部に委託する場合も、制度の解釈そのものではなく「設計と移行の実装」を任せる範囲を明確にしておくと、判断の責任が曖昧になりません。

本記事はクラウドなどデータ処理サービスの乗り換えを中心に扱いました。もう一つの柱である、機器が生み出すデータへのアクセスと第三者への共有については、コネクテッド製品のデータ開示への備えで扱っています。製品を出す側の論点はそちらを確かめてください。

まとめ：EUデータ法で押さえる3つの視点

EUデータ法（Data Act）は、データを守る規律ではなく、データを使えるようにし動かせるようにする規律です。押さえたい視点は三つに整理できます。第一に、コネクテッド製品のデータ共有・事業者間の共有条件・クラウドの乗り換え・相互運用という四つの柱で構成され、2025年9月12日から原則の適用が始まっていること。第二に、乗り換えにかかる手数料は段階的に縮小し、2027年1月12日以降は請求できなくなるため、選定の論点が費用から技術的な移しやすさへ移ること。第三に、受託・委託開発では、データの取り出し経路・データ辞書・移行容易性・契約の協力義務を初期要件に織り込むのが実務の要になることです。まずは自社にEUとの接点があるかを棚卸しし、あるなら「守る側か求める側か」を見極めるところから始めてみてください。

よくある質問

出典

1. *1　参考：European Commission「Data Act｜Shaping Europe’s digital future」（https://digital-strategy.ec.europa.eu/en/policies/data-act）。規則の位置づけ・発効日（2024年1月11日）・適用開始日（2025年9月12日）・対象範囲の参考として（2026年8月確認）
2. *2　参考：European Commission「Data Act explained」（https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained）。クラウド等データ処理サービスの切替に関する規定と手数料の段階的な扱いの参考として（2026年8月確認）

Tweet