「GDPR対応をお願いします」——外資系クライアントとの契約書、あるいは社内法務からの一言で、システム開発の進め方が一気に不透明になった。そんな状況に直面していないでしょうか。
困るのは、法務やクライアントが求めているのは「GDPRに準拠したシステム」であるのに、それをシステムの機能要件として何を作ればよいかに翻訳する部分が、誰の担当でもないまま宙に浮いてしまう点です。要件があいまいなまま発注すれば、開発の途中で「この機能も必要だった」と判明し、手戻りと追加費用が発生します。GDPR違反には全世界年間売上高の最大4%という重い制裁金が定められているため、抜け漏れを恐れる気持ちはもっともです。
ですが、GDPR対応で「システムに作り込むべきこと」は、実は整理すれば有限のチェックリストに落とし込めます。同意の取得・削除権・データの持ち出し（ポータビリティ）・漏洩時の通知——これらを「何のための要件か」「システムで何を実装するか」「要件書にどう書くか」の3点セットで把握しておけば、ベンダーと具体的に会話でき、予算の当たりもつきます。
本記事では、発注者の立場でGDPR対応のシステム開発を進めるために、(1) 自社への適用判断、(2) 要件書に盛り込むべき7つのシステム要件のチェックリスト、(3) 費用・追加工数の目安、(4) ベンダーへの確認質問、(5) 日本の個人情報保護法との違い——という順で、要件書・RFPにそのまま使える粒度で解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
GDPR対応はなぜ「システム開発」の問題になるのか
GDPR（EU一般データ保護規則）と聞くと、プライバシーポリシーの整備や社内規程の見直しといった「文書・運用の話」を思い浮かべる方が多いかもしれません。しかし実際には、GDPRが求める要件の多くはシステムに機能として実装しなければ満たせません。ここを最初に押さえておかないと、規程だけ整えて「対応済み」と思い込み、肝心のシステム側が空白のまま発注してしまう事故が起こります。
法務対応とシステム対応は別物
GDPR対応は、大きく「法務・規程の対応」と「システムの対応」の二層に分かれます。
- 法務・規程の対応: プライバシーポリシーの改定、データ処理に関する社内規程の整備、データ処理者（委託先）との契約条項（DPA）の締結、必要に応じたEU域内代理人の選任など
- システムの対応: 同意を取得・記録する仕組み、利用者からの開示・削除請求に応える機能、データを暗号化・仮名化する設計、漏洩を検知して通知につなげる仕組みなど
法務部門が「GDPR対応してほしい」と言うとき、その多くは前者を指しています。しかし、たとえば「利用者が自分のデータの削除を求めてきたら応じる」という規程上の約束は、実際にそのデータをシステムから削除する機能がなければ守れません。規程とシステムは両輪であり、発注者が要件書を書くべきなのは後者の「システムの対応」部分です。本記事はこの翻訳作業に焦点を当てます。
対応漏れが招くリスク
なぜ抜け漏れを避ける必要があるのか、リスクの大きさを簡潔に確認しておきます。
GDPRの制裁金には2つの水準があり、重大な違反（処理の原則違反、データ主体の権利の侵害など）に対しては、前事業年度の全世界年間売上高の4%、または2,000万ユーロのいずれか高い方が上限とされています。漏洩時の72時間以内の報告義務を怠った場合などは、売上高の2%、または1,000万ユーロのいずれか高い方が上限です（各国のデータ・プライバシー法情報）。実際にAmazonに対して約970億円の制裁金が課された事例もあり（日本経済新聞）、これは「形だけの対応」では済まされないことを示しています。
加えて見落とされがちなのが、開発中の手戻りコストです。要件を後から追加すると、設計のやり直し・データベース構造の変更・テストの再実施が連鎖し、当初見積もりを大きく超えることがあります。最初の要件定義でGDPR要件を織り込んでおくことが、結果的に最も安価で確実な対応になります。
自社にGDPRが適用されるか — 日本企業が押さえる判断基準
「うちは日本の会社だからGDPRは関係ない」——これは最も危険な誤解の一つです。GDPRはEU域外の企業にも適用される（域外適用）設計になっており、日本企業であっても一定の条件を満たせば対象になります。発注前に、まず自社が対応すべきかどうかを正しく判断しましょう。
適用を決めるのは「所在地」ではなく「データ主体」
GDPRが適用されるかどうかは、会社がどこにあるかではなく、EU域内にいる個人（データ主体）の個人データを扱っているかで決まります。日本に拠点を置く企業でも、EU域内の人々を対象にサービスを提供したり、その行動を監視したりしていれば適用対象となります（GDPR Scope - Sprinto）。
ここでいう「EU域内の人」は、EU市民かどうかではなく、EU域内に所在しているかが基準です。たとえば日本企業のサービスをEU滞在中の日本人が利用した場合も、形式的には対象になり得ます。
適用される代表的な4ケース
実務上、次のいずれかに該当する場合は適用の可能性が高いと考えてください。
- EU域内の個人向けにサービス・商品を提供している: EU向けの言語・通貨対応、EU圏への配送オプションなど、EUの利用者を意図的に対象にしていると判断される場合
- EU域内の個人の行動を監視している: Webサイトのトラッキングクッキーやアクセス解析で、EU域内の利用者の行動を追跡・プロファイリングしている場合
- EU域内に拠点・子会社がある: 現地法人や支店でEU域内の従業員・顧客のデータを扱う場合
- EU企業からデータ処理を委託されている: 外資系クライアントのシステム開発・運用を受託し、その過程でEU域内の個人データを処理する場合
外資系クライアントから「GDPR対応してほしい」と求められるケースの多くは、4番目に該当します。クライアントが管理者（コントローラー）、自社が処理者（プロセッサー）という関係になり、処理者にもGDPR上の義務が課されます。
個人データの範囲は想像より広い
GDPRが保護する「個人データ」は、氏名やメールアドレスだけではありません。Cookie・IPアドレス・端末ID・位置情報なども、個人を識別し得る情報として個人データに含まれます（ブルースクレイ・ジャパン）。
この点は日本の感覚とずれやすい部分です。「個人情報は集めていないから大丈夫」と思っていても、アクセス解析やリターゲティング広告のためにCookieを使っていれば、それだけでGDPRの対象になり得ます。Cookieバナーによる同意取得が必要になるのも、この広い定義が理由です。自社のサービスがどんなデータを扱っているか、まずは棚卸しすることをおすすめします。
なお、域外適用の対象となる企業は、原則としてEU域内に代理人（EU代理人）を選任する義務があります（GDPR第27条）。これはシステム要件ではなく体制の話ですが、対応スコープに含まれることを覚えておくとよいでしょう。
GDPR対応でシステムに必要な7つの要件チェックリスト
ここが本記事の中核です。GDPRが求める要件を「システムで何を作るか」に翻訳し、7つのチェックリストとして整理しました。各要件は「何のための要件か」「システムに必要な機能」「要件書への書き方の例」の3点セットで記載しています。要件書・RFP作成の出発点としてご活用ください。
要件1: 同意管理（取得・撤回・記録）
何のための要件か: GDPRでは、個人データの処理にあたって本人の明確な同意を得ることが原則です。同意は「取得して終わり」ではなく、いつでも撤回でき、いつ・どの目的で同意を得たかを記録しておく必要があります。
システムに必要な機能:
- 利用目的ごとに分けた同意取得UI（一括同意ではなく目的別のオプトイン）
- 同意の撤回をいつでも行える導線（設定画面など）
- 同意・撤回の履歴を「誰が・いつ・何に同意したか」の形で記録するログ機能
- CookieについてはCookieバナーと、カテゴリ別（必須・分析・広告など）の選択機能
要件書への書き方の例: 「利用者は、データ処理の目的ごとに同意・非同意を選択できること。同意および撤回の操作は日時・対象目的とともに記録し、監査時に提示可能であること。」
要件2: アクセス権・開示対応
何のための要件か: データ主体には、自分に関するどんなデータが、どんな目的で処理されているかを知り、その写しを求める権利（アクセス権）があります。
システムに必要な機能:
- 本人確認を経たうえで、当該利用者の保有データを一覧・出力できる管理機能
- どの目的・どの第三者にデータが提供されているかを提示できる情報
要件書への書き方の例: 「利用者からの開示請求に対し、本人確認後に当該利用者の個人データと処理目的を出力できる機能を備えること。」
要件3: 訂正権
何のための要件か: データ主体は、自分のデータが誤っている場合に訂正を求める権利を持ちます。
システムに必要な機能:
- 利用者自身がプロフィール等を修正できる機能、または問い合わせを受けて管理者が修正できる機能
- 訂正の事実を記録し、必要に応じて提供先にも訂正を反映する仕組み
要件書への書き方の例: 「利用者は自身の登録データを訂正できること。訂正履歴を記録し、第三者提供済みデータについても訂正を反映できること。」
要件4: 削除権（忘れられる権利）の実装
何のための要件か: いわゆる「忘れられる権利」です。データ主体が削除を求めた場合、企業は対象データを削除する義務があります。ここで重要なのは、表示上消すだけでは不十分で、バックアップや関連データも含めて確実に削除・無効化する必要がある点です（arcserve）。
システムに必要な機能:
- 本人確認後に、対象利用者のデータを関連テーブルも含めて削除する機能
- バックアップ・ログ・分析基盤など、データが複製されている全ての場所での削除または匿名化の方針
- 法令上保存が必要なデータ（会計記録など）は削除対象外とする例外処理
要件書への書き方の例: 「削除請求に対し、本番DBおよびバックアップ・派生データを含めて対象データを削除または復元不能な匿名化を行う機能を備えること。ただし法定保存義務のあるデータは対象外とし、その範囲を明示すること。」
削除権は、システム設計に最も大きな影響を与える要件の一つです。「データは消さずに無効フラグを立てるだけ」という一般的な論理削除では要件を満たせない場合があるため、設計段階での検討が欠かせません。
要件5: データポータビリティ
何のための要件か: データ主体は、自分が提供したデータを、機械可読な形式で受け取ったり、別のサービスへ移したりするよう求められます（電通総研）。
システムに必要な機能:
- 当該利用者のデータをCSV・JSONなど構造化された機械可読形式でエクスポートする機能
- 可能であれば他サービスへ直接送信する連携機能（必須ではないが望ましい）
要件書への書き方の例: 「利用者は自身の個人データを構造化された機械可読形式（CSVまたはJSON）でエクスポートできること。」
要件6: Privacy by Design（設計段階からの保護・暗号化/仮名化）
何のための要件か: GDPRは「Privacy by Design / by Default（設計段階からのデータ保護）」を原則として求めています（Microsoft GDPR）。後付けではなく、システムの設計時点からプライバシー保護を組み込むという考え方です。
システムに必要な機能:
- 保管時・通信時のデータ暗号化
- 個人を直接識別できないようにする仮名化・匿名化の仕組み
- 必要最小限のデータのみ収集する設計（データ最小化）
- デフォルトで最もプライバシー保護的な設定にする（オプトイン前提）
要件書への書き方の例: 「個人データは保管時・通信時に暗号化し、分析等の用途では仮名化したデータを用いること。収集項目は利用目的に必要な最小限とすること。」
要件7: アクセスログ・データ処理記録と漏洩時の72時間通知
何のための要件か: 不正アクセスや漏洩を検知し、説明責任（アカウンタビリティ）を果たすために、誰がいつどのデータにアクセスしたかの記録が必要です。さらにGDPRでは、個人データの漏洩が発生した場合、原則として72時間以内に監督機関へ報告する義務があります（各国のデータ・プライバシー法情報）。
システムに必要な機能:
- 個人データへのアクセスログ・操作ログの記録
- 異常なアクセスや漏洩の兆候を検知する仕組み（監視・アラート）
- 漏洩発生時に、影響範囲・対象データを迅速に特定できる機能
要件書への書き方の例: 「個人データへのアクセス・操作をログとして記録し、不正アクセスを検知・通知できること。漏洩発生時に影響範囲と対象データを72時間以内に特定できる体制を支援する機能を備えること。」
72時間という時間制約は、システムだけでなく検知・報告の運用フローと一体で考える必要があります。「どのログを見れば影響範囲が分かるか」を設計時に決めておかないと、いざというときに間に合いません。
GDPR対応にかかる費用・追加工数の目安
要件が見えてきたら、次に気になるのは費用です。社内で予算を確保し上申するには、概算でも当たりをつけておく必要があります。ただし、GDPR対応の費用は条件によって大きく変動するため、ここでは費用の構造と、ブレる要因を理解していただくことを優先します。具体額は出典のある範囲で示し、自社で概算を立てるための考え方を提示します。
費用は3つの層に分かれる
GDPR対応の費用は、性質の異なる3つの層に分けて考えると整理しやすくなります。
- 規程整備・コンサルティング層: プライバシーポリシー・社内規程の整備、適用範囲の調査、データ処理影響評価（DPIA）の実施支援など。法務・コンサル費用が中心
- システム実装層: 前章の7要件をシステムに実装する開発費用。本記事の主対象。新規開発か既存システムの改修かで大きく変わる
- 運用層: 漏洩監視ツール、ログ管理基盤、EU域内代理人の費用、DPO（データ保護責任者）の設置など、対応後に継続的に発生する費用
発注者が見落としやすいのは、システム実装層の費用です。コンサル費用や監視ツールの料金（月額制のサービスが多く提供されています）は見積もりやすい一方、自社システムへの作り込みは要件次第で振れ幅が大きくなります。
要件別の追加工数イメージ
7つの要件のうち、どれが重く・どれが軽いかの感覚を持っておくと、優先順位づけに役立ちます。あくまで相対的な目安です。
- 比較的軽い: 訂正権（要件3）、データポータビリティ（要件5）——既存のデータ出力・編集機能を拡張する形で対応できることが多い
- 中程度: 同意管理（要件1）、アクセス権・開示対応（要件2）、アクセスログ（要件7の一部）——新規の管理機能やログ基盤の追加が必要
- 重い: 削除権（要件4）、Privacy by Design（要件6）——既存システムの設計に深く関わるため、改修範囲が広くなりやすい
特に削除権は、既存システムが論理削除前提の設計になっている場合、データの持ち方そのものを見直す必要が出ることがあり、工数が膨らみやすい要件です。
費用がブレる要因と概算の立て方
同じ「GDPR対応」でも、費用が数倍変わることは珍しくありません。主な変動要因は次の通りです。
- 新規開発か既存改修か: ゼロから設計するなら最初からGDPR要件を織り込めますが、既存システムへの後付けは調査・影響範囲特定のコストが上乗せされます
- データの分散度: 個人データが複数システム・複数DBに分散していると、削除・開示の対応がその数だけ必要になります
- 対象データ量・ユーザー数: 大量データの暗号化・移行は処理設計のコストを押し上げます
- 対象国・言語: EU複数国を対象にすると、同意UIの多言語対応などが加わります
概算を立てる際は、まず「自社が対応すべき要件はどれか」を7要件のチェックリストで絞り込み、各要件の重さ（上記の軽い・中・重い）と自社システムの状況を掛け合わせて当たりをつけます。そのうえで、ベンダーに7要件を提示して見積もりを依頼すれば、要件ごとの工数内訳を含む現実的な見積もりが得られます。「GDPR対応一式いくら」というざっくりした見積もりではなく、要件単位で内訳を出してもらうことが、予算精度と後の手戻り防止の両面で重要です。
ベンダーに必ず確認すべきチェックポイント
要件と費用感が見えたら、いよいよベンダー選定です。GDPR対応は「対応できます」という一言で判断すると失敗します。ここでは、発注・選定の面談でそのまま使える確認質問を、回答から見抜くべきポイントとあわせて紹介します。
実績・設計思想を問う質問
- 「GDPR対応を含むシステムの開発実績はありますか。どの要件をどう実装しましたか」
- 「Privacy by Designをどう設計に反映していますか」
- 「削除権について、バックアップや派生データまで含めてどう削除を担保しますか」
見抜くポイント: 「対応できます」だけで具体的な実装方法を語れないベンダーは要注意です。削除権について論理削除の話しか出てこない、暗号化・仮名化の使い分けを説明できないといった場合、要件の理解が表面的な可能性があります。具体的な実装の選択肢とトレードオフを語れるかどうかが、信頼できるベンダーの見極めポイントです。
データ保管場所・越境移転に関する質問
- 「個人データはどこに保管されますか。EU域内ですか、域外ですか」
- 「利用するクラウド・外部サービスは何で、それらの所在地と契約形態（DPA）はどうなっていますか」
- 「データをEU域外へ移転する場合、適法化の根拠はどう確保しますか」
見抜くポイント: GDPRはデータの越境移転を原則として制限しており、適法化の根拠が必要です（Codebook）。利用するクラウドやSaaSの所在地・契約を即答できないベンダーは、データの流れを把握できていない可能性があります。なお日本はEUから十分性認定を受けているため、日本への移転には一定の道筋がありますが、第三国のクラウドを経由する場合などは別途検討が必要です。
保守・法改正追従に関する質問
- 「公開後の保守フェーズで、関連する法改正やガイドライン更新にどう追従しますか」
- 「漏洩を検知した場合の運用フロー（72時間通知に向けた影響範囲特定）はどう設計しますか」
見抜くポイント: GDPR対応はリリースして終わりではなく、運用と法改正への追従が続きます。保守契約の範囲に法対応が含まれるのか、別途費用なのかを最初に確認しておかないと、後から追加費用で揉める原因になります。
日本の個人情報保護法との違い（発注者が誤解しやすい点）
「国内の個人情報保護法には対応済みだから、GDPRも大丈夫だろう」——これも危険な思い込みです。両者は方向性こそ似ていますが、システム要件に影響する部分で無視できない差があります。ここでは網羅的な比較ではなく、発注判断に効く差分に絞って整理します。
要件に影響する主な違い
観点 | GDPR | 日本の個人情報保護法 |
|---|---|---|
削除権・忘れられる権利 | 明確に規定。バックアップ含む削除が求められる | 利用停止・消去の請求は認められるが、GDPRほど詳細・広範ではない |
データポータビリティ | 機械可読形式での提供を権利として規定 | 開示請求への電磁的方法での対応は認められるが、ポータビリティの権利として同等ではない |
個人データの範囲 | Cookie・IPアドレス・端末IDなども含む | 個人識別符号等の概念はあるが、運用上の感覚にずれが生じやすい |
同意（オプトイン） | 目的別の明確な同意が原則 | 利用目的の通知・公表が基本で、GDPRより同意要件が緩やかな場面がある |
越境移転 | 原則制限。適法化の根拠が必要 | 一定の規律はあるが、GDPRの方が厳格 |
制裁金の規模 | 最大で全世界売上高4%または2,000万ユーロ | 法人の罰金は最高1億円（2022年改正以降） |
制裁金の規模だけ見ても、桁が違うことが分かります（SDGsコンパス）。GDPRは権利の範囲が広く、システムに作り込む機能が多くなる、という点を押さえてください。
「国内対応済み」で見落としやすいポイント
国内法ベースで作られたシステムをそのままEU向けに使おうとすると、特に次の3点で漏れが生じやすくなります。
- 削除の徹底度: 国内対応では論理削除で済ませていた箇所が、GDPRではバックアップ含む削除を求められる
- 同意の粒度: 一括同意で運用していたものを、GDPRでは目的別の同意に分ける必要がある
- Cookie・トラッキング: 国内では明示的同意なしで使っていたCookieが、GDPRでは同意取得の対象になる
国内の個人情報保護法対応の考え方をベースに、GDPR固有の差分を上乗せしていくのが現実的なアプローチです。国内法対応のシステム要件については、個人情報保護法対応のシステム開発チェックリストや、仕様書・契約書への反映観点をまとめた個人情報保護法とシステム開発もあわせてご覧ください。両者の共通部分を土台にすることで、GDPR対応の検討を効率化できます。
まとめ — GDPR対応を見据えた発注で押さえること
GDPR対応のシステム開発は、「法務に言われたが何を作ればいいか分からない」という不安から始まることがほとんどです。しかし、要件を整理すれば、発注者が押さえるべきことは明確になります。
最後に、要点を振り返ります。
- GDPR対応は規程整備だけでなく、システムへの機能実装が必須。発注者が要件書を書くべきはシステム側の対応
- 適用判断は所在地ではなくデータ主体で決まる。日本企業でもEU域内の個人データを扱えば対象。Cookie・IPアドレスも個人データに含まれる
- システムに必要な要件は7つ——同意管理 / アクセス権・開示 / 訂正権 / 削除権 / データポータビリティ / Privacy by Design / アクセスログと72時間通知。各要件を「何のため・何を作る・どう書く」の3点で要件書に落とす
- 費用は規程整備・システム実装・運用の3層で考え、要件単位で内訳見積もりを取る
- ベンダーには「対応できます」の先を問う。具体的な実装方法・データ保管場所・保守追従を確認する
- 国内対応済みでも油断しない。削除の徹底度・同意の粒度・Cookieの扱いで差分が生じる
最初の一歩としておすすめするのは、「適用判断 → 対応すべき要件の優先度付け → ベンダーへの要件提示と見積もり依頼」という順序で進めることです。7要件のチェックリストを手元に置き、自社がどの要件にどこまで対応すべきかを絞り込めば、ベンダーと具体的な会話ができ、予算規模の当たりもつきます。抜け漏れのない要件定義こそが、手戻りと追加費用を防ぐ最大の対策です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
