インドDPDP規則2025完全解説|日本企業が取るべき対応
![]()
今回は、インドでビジネスをする全ての日本企業にとって「死活問題」にもなり得る、インドのデジタル個人データ保護規則の正体について徹底解説していきます。
2025年11月13日、インド電子情報技術省(MeitY)から、「デジタル個人データ保護規則(DPDP Rules 2025)」がついに正式に告示されました。2023年に成立した根拠法(DPDP Act 2023)に基づくもので、以前から「もうすぐ出るぞ」と言われていた「細かいルールブック」です。18ヶ月間の準備期間が設定されているとはいえ、このまま放置していると最大で25億ルピー、日本円にして約45億円という巨額の罰金が課されるリスクさえあります。「うちはBtoBだから関係ない」「うちはIT系じゃないから関係ない」と思っている企業こそ、それが一番危険です。
GDPR・日本法との3大違い——インドが「世界一厳しい」理由
まずはこのインドの新規則がどれくらい厳しいのか、ヨーロッパのGDPRや日本の個人情報保護法と比較しながら、決定的な違いを見ていきましょう。
![]()
違い①:「同意至上主義」——契約・正当利益では処理できない
日本やGDPRでは、個人データを扱う際に「契約の履行」「正当な利益」などの理由があれば、本人の同意なしにデータ処理が認められるケースがあります。しかしインドのDPDP法は違います。原則として「同意(Consent)」がなければ何もできないという整理になっています。「契約のために必要だから」「マーケティングはお客様のためにもなるから」といった企業側の理屈は、インドでは通用しません。この徹底的な「同意至上主義」が、他国との最大の違いです。
違い②:「子供」は18歳未満——世界最高水準の保護基準
日本では実務上15歳前後、GDPRでも加盟国によって13〜16歳とされることが多いですが、インドはなんと18歳未満をすべて「子供(Child)」と定義しています。若くして働いている18歳未満の社会人もインドでは「子供」扱いになるため、サービスを利用させるには「保護者の同意」が必要です。マーケティングや採用活動においても、このハードルは無視できません。
違い③:インシデント報告は「6時間」——三重のデッドライン
データ漏洩などのインシデントが発生した場合、日本では「速やかに(3〜5日以内)」、GDPRでも「72時間以内」の報告が義務付けられています。インドのDPDP規則自体は72時間以内と規定していますが、2000年情報技術法(IT法)に基づくCERT-In(インドのサイバーセキュリティ機関)への報告義務がなんと「6時間以内」に設定されています。ハッキングに気づいてから6時間以内に報告するには、日本本社への報告・稟議を待っている余裕はありません。24時間体制の監視体制が事実上前提となる水準です。
違い④:罰則は企業規模を問わず最大約45億円
GDPRは「2,000万ユーロまたは売上の4%」、日本では法人最大1億円程度が上限ですが、インドは企業規模を問わず違反内容に応じて最大25億ルピー(約45億円)の罰金規定があります。スタートアップであっても大企業であっても、違反すればこの巨額ペナルティのリスクが生じます。
施行スケジュール——18ヶ月の「生存戦略」と3フェーズ
インド政府は、2025年11月13日の告示から2027年5月までの約18ヶ月間を本格施行に向けた準備期間として設定しています。この18ヶ月は3段階に分けて施行されます。
![]()
第1フェーズ:即時(2025年11月)——データ保護委員会が発足
まず違反を取り締まるデータ保護委員会(DPB : Data Protection Board)が設立され、委員が任命されます。取り締まりの準備はすでに整いつつあります。
第2フェーズ:1年後(2026年11月)——同意管理者が稼働
「同意管理者(Consent Manager)」という新しい仕組みが稼働する予定です(詳細は後述)。企業はこの新プラットフォームへのAPI連携対応を、2026年11月13日までに完了させる必要があります。
第3フェーズ:最終期限(2027年5月)——全条項の完全適用
2027年5月13日以降から全条項が完全適用されます。従来のIT法43A条に基づく規制が廃止され、厳格なDPDP法一本に統一されます。「まだ1年半ある」と思うか「あと1年半しかない」と思うか——システム改修や契約見直しを考えると、日系企業にとっては時間的な余裕はあまりないのが実態です。
適用範囲——日本本社も対象になる「域外適用」の罠
「インドに現地法人はあるが、サーバーは日本にある」という会社も、対応が必要になるケースがあります。
インド国外から提供するSaaS・ECも対象
この法律はインド国内でのデータ処理だけでなく、インド国外からインド居住者に向けて商品やサービスを提供している場合も対象になります。日本の本社が運営するSaaSや越境ECサイトであっても、インド国内のユーザーがいる限り、日本の本社に法的遵守義務が発生します。これが「域外適用」です。
BPO拠点の例外——適用が免除される条件とは
ただし一つだけ例外があります。インドをBPO拠点として活用し、日本の顧客データをインドの委託先に送って処理させているケースです。この場合、一定の条件を満たせばインドのコンプライアンスの一部が免除される規定があります。ただし契約書で責任分界点を明確にしておかないと思わぬ落とし穴になるため、現行の契約内容のレビューが必要です。
通知と同意——「抱き合わせ同意禁止」など世界一厳格なルール
実務の核心部分である「通知と同意」のルールは、おそらく世界一厳しいと言っても過言ではありません。特に衝撃的なのが「無条件(Unconditional)」というキーワードが明記されていることです。
抱き合わせ同意・デフォルト同意は「違法」
「サービスを使うなら個人情報を提供してください」というような、いわゆる「抱き合わせ同意」がインドでは厳格に禁止されます。サービス提供に本当に必要なデータ以外を強制取得することはできません。また、最初からチェックボックスにチェックが入っている「デフォルト同意」や、沈黙をもって同意とみなす行為もすべて無効・違法です。
項目別通知と22言語対応の義務
ユーザーへの通知は「プライバシーポリシーに書いてあるから読んでね」では不十分です。通知は他の情報から独立して「項目別」に——「どのデータを」「何のために使うのか」「どうやって同意を撤回できるか」を箇条書きで明示する必要があります。さらにインドは多言語国家のため、ユーザーは憲法で指定された22の言語から通知言語を選択できる権利を持っています。アプリやWebサイトのUIを根本から見直す必要が生じる可能性があります。
同意撤回の即時反映が必要
ユーザーが同意を撤回した場合、企業はその信号を受け取り次第、即座にデータ処理を停止しなければなりません。この仕組みを技術的に担保するのが、次に説明する「同意管理者」プラットフォームとのAPI連携です。
同意管理者(Consent Manager)——インド独自の仲介システム
今回の規則で最もインド独自色が強いのが、この「同意管理者(Consent Manager)」という仕組みです。他国にはほぼ存在しないユニークな制度です。
![]()
同意管理者の役割——ユーザーが同意の蛇口を操作
同意管理者とは、個人の代わりに企業への同意を一括管理する「仲介業者」のことです。イメージとしては、スマホのアプリひとつで「A社には個人情報を渡してもよいが、B社はブロックする」というように、ユーザーが自分の個人情報の蛇口をコントロールできる仕組みです。この同意管理者は、データ保護委員会(DPB)に登録された認可法人でなければなりません。
企業側の対応——API連携と即時データ停止の仕組み
企業側は自社で同意を取るだけでなく、同意管理者のプラットフォームとAPI連携し、「ユーザーが同意管理者経由で同意を撤回した」という信号を受け取ったら即座にデータ処理を停止する対応が必要になります。技術的な実装も含めた準備が求められます。なお、自社がこの「同意管理者」自体になるビジネスモデルも生まれますが、インド国内に法人格を持ち、2,000万ルピー以上の純資産を有することなど、参入障壁は高めに設定されています。
子供のデータ保護——「18歳の壁」が採用・マーケティングを直撃
前述の「18歳未満 = 子供」という定義は、実務に大きな影響を与えます。日系企業が最も陥りやすい障壁の一つです。
Aadhaarによる保護者同意の検証義務
18歳未満のユーザー全員に対して、検証可能な「保護者の同意」を取得する義務があります。「18歳未満ですか?」と質問して「いいえ」と答えさせるだけでは不十分で、Aadhaar(インド版マイナンバー)などの個人認証システムを使って本当に保護者が同意しているかをデジタル的に検証する必要があります。技術的な実装難易度も高くなる可能性があります。
ターゲット広告・行動追跡の全面禁止
子供に対する「行動追跡(トラッキング)」や「ターゲット広告」が全面的に禁止されます。ゲーム会社や教育アプリを展開している企業にとっては死活問題です。子供の興味関心を分析しておすすめを表示するという当たり前の機能が使えなくなる可能性があり、場合によってはマーケティング戦略やビジネスモデル自体の見直しが必要になります。
データ主体の権利と保持制限——90日対応・指名権・48時間前通知
法律を守るためには、社内の運用フローも大幅に見直す必要があります。特に「データ主体の権利」と「保持制限」が急所になります。
90日以内の修正・削除対応義務
ユーザーから「私のデータを修正してくれ」「削除してくれ」と求められた場合、企業は原則として90日以内に対応しなければなりません。問い合わせメールを担当者が手動でデータベースをいじって対応しているようでは、件数が増えた際にパンクする可能性があります。自動化された対応フローの構築が必要です。
インド独自「指名権」——代理人設定機能の追加開発
インド独自の制度として「指名権(Nomination)」があります。自分が亡くなったり判断能力を失った場合に、代わりに権利を行使できる人を指名できる権利です。GDPRや日本法では「相続」の枠組みで語られる論点ですが、インドでは「家族という最小単位のセーフティネット」をデジタル保護の仕組みに組み込んでいます。システム的には「代理人設定」機能の追加開発が必要になる可能性があります。
削除の48時間前通知——自動化が必須
特定のサービスでは、ユーザーが3年間活動していないデータは自動削除しなければなりませんが、削除する「48時間前」に本人への通知が義務付けられています。「もうすぐデータを削除します」という通知を送ってログインを促す仕組みを、システムで自動化しておかないと手動での対応は現実的ではありません。UI/UXの設計段階から組み込む必要があります。
インシデント対応——「6時間」「72時間」「直ちに」三重の義務
データ漏洩やサイバー攻撃(インシデント)が発生した際、インドでは三重のデッドラインが課されます。
CERT-Inへの6時間以内報告——24時間体制が前提
2000年情報技術法に規定された、最もきつい「魔の6時間」ルールです。サイバー攻撃を認識してから6時間以内に、インドのサイバーセキュリティ機関CERT-Inへの報告が義務付けられています。夜中に発覚すれば、朝になる前に報告しなければならないレベルです。法律が要求することと実務実態の両面から、どのような体制とするかは経営判断が必要です。
DPBへの72時間以内報告——詳細レポートが必要
DPDP規則に規定されたデータ保護委員会(DPB)への報告義務は72時間以内です。どの個人データが漏れたか、影響範囲はどれくらいかを含む詳細なレポートが求められます。
影響個人への直ちの通知義務
影響を受ける個人への通知は「直ちに」行う必要があります。被害者に対してインシデントを隠蔽することは当然に許されません。「6時間」「72時間」「直ちに」という三重のデッドラインを、パニック状態の中で対応できる体制を今のうちに設計しておく必要があります。
重大データ受託者(SDF)と国外移転——将来の規制リスク
SDFに指定されると義務が一気に重くなる
ユーザー数が2,000万人を超えるような大規模サービスは、「重大データ受託者(SDF : Significant Data Fiduciary)」に指定される可能性があります。SDFに指定されると、インド国内在住のデータ保護責任者(DPO)の任命、第三者による独立監査、定期的なデータ保護影響評価(DPIAs)の実施など、義務が一気に重くなります。
国外移転はネガティブリスト方式——地政学リスクに注意
インドの国外データ移転は基本的に「自由」ですが、政府が「この国には送ってはいけない」と指定した国以外ならOKというネガティブリスト方式が採用されています。現時点で日本は対象外ですが、地政学的なリスクでいつどこが「禁止国」になるかはわかりません。また、金融データなど特定セクターでは例外的にインド国内にデータを置く「ローカライゼーション規制」も存在するため、業種によっては個別の確認が必要です。
今すぐ着手すべき3つのアクションプラン
DPDP Rules 2025への対応は、今すぐ着手すべき課題です。優先すべき3つのアクションを整理します。
![]()
①ギャップ分析——契約・プライバシーポリシーの現状確認
まず、現状の契約書・プライバシーポリシー・利用規約に対して、どのような対応が必要かのギャップを洗い出します。従業員の個人情報や写真を広報活動やSNSで利用しているケースを含め、本人同意の取得が必要かどうかを確認しておくことが重要です。
②システム改修ロードマップ——2027年5月逆算で計画
2027年5月の完全施行に向けて、「48時間前通知機能」「指名機能」「22言語対応」「同意管理者へのAPI連携」など、必要なシステム改修の計画を立てます。スコープが大きいほど、早期に着手することが重要です。
③インシデント対応チームの再編——「6時間」への備え
CERT-Inへの6時間以内報告という厳しいルールに対して、どのような体制で対応するかの方針を決めておく必要があります。24時間体制の監視をどこまで整備するか、日本本社とインド現地の連絡ラインをどう設計するかが具体的な論点になります。
▼ あわせて読みたい関連記事