お疲れ様です！IT業界で働くアライグマです！
個人開発している技術記事キュレーションサービス「DevPick」のAndroidアプリは、日本で公開したあと、配信する国を少しずつ広げてきました。2026年10月15日から18日の4日間で、配信国は日本だけから32か国になりました。この記事では、国ごとの個人情報保護法をどう確かめて、プライバシーポリシーへどの順で書き足したかを記録します。
なお、この記事は個人開発者として調べた範囲の記録で、法律の専門家による助言ではありません。各国の法令は2026年10月時点で確認したものです。
配信国を広げても費用は増えない。残る壁は国ごとの個人情報保護法だった
配信国は、段階を分けて広げてきました。最初にカナダ・オーストラリア・ニュージーランド、次に英国・アイルランド、その次にマルタと米国です。英国・アイルランドは、広告の同意管理（Googleの UMP）をアプリに組み込んでから加えました。その経緯はAdMobのUMPをExpoアプリに組み込んだ記事に書いています。
米国・マルタを加えた時点では、インドやシンガポールなど残りの英語圏の国は「国別のインストール数を見てから判断する」予定でした。ところが、その日のうちに考え直しています。理由は、DevPickの費用が利用者の数にほとんど比例しない作りになっていることでした。
- AI要約は、記事ごとに1回だけまとめて作っています。英語版の要約も同じです。利用者が増えても、要約を作る回数は増えません。
- サーバーは月額が固定のVPSです。
- アプリは完全無料で、収益は広告だけです。広告の単価が低い国で利用者が増えても、赤字にはならず、収益の伸びが小さいだけです。
そうなると、配信をためらう理由は1つしか残りません。その国の個人情報保護法に、外国の小さな個人事業者として対応できるかどうかです。そこで、英語が公用語の国を1か国ずつ確かめて、対応できる国をまとめて加えることにしました。
IT女子 アラ美
ITアライグマ英語が公用語の国を「そのまま追加」「ポリシーへの追記が要る」「見送り」に分けた
最初の下調べはWeb検索で、出てきたのは法律事務所の解説などの二次資料です。二次資料で当たりを付けたあと、加える前に法令の本文や監督機関のガイダンスで確かめ直しました。確かめた出典は、国ごとにリポジトリの配信ガイドへ残しています。
判断の前提は次のとおりです。
- DevPickは日本の個人運営で、従業員も売上もごく小さい。
- 病歴などの、特に慎重に扱うべき個人情報は扱わない。
- Google Play Consoleで申告した対象年齢は「18歳以上」。
- どの国にもサーバーなどの処理の拠点を置かず、データは日本のサーバーで保存・処理する。
そのうえで、分け方の軸を「国外の事業者にも、登録・代理人の選任・規約の変更が求められるか」にしました。
| 分類 | 基準 | 主な国 |
|---|---|---|
| そのまま追加 | 国外の事業者に登録や代理人が要らない。または法律が未施行・未制定 | フィリピン、ケニア、香港、南アフリカ、インド、パキスタン、フィジーなど |
| ポリシーへの追記が要る | 国外の事業者にも適用され、公開すべき記載がある | シンガポール |
| 見送り | 国外の事業者にも登録が要る。または国外の事業者への適用が確かめられない | ウガンダ、ルワンダ、ガーナ、ジャマイカ、タンザニア、ナイジェリアなど |
「そのまま追加」の国にも、法律が無いわけではありません。たとえばフィリピンは、監督機関への登録が要るのは従業員250人以上などの条件を満たす事業者です。ケニアは、売上500万ケニア・シリング未満かつ従業員10人未満なら登録が免除されます。南アフリカは、国外の事業者には国内の処理の手段を使う場合だけ適用されます。どれも、DevPickの規模や作りでは該当しませんでした。
見送った国は、理由と「どうなったら考え直すか」も記録しています。条件は、監督機関が国外の小規模事業者の登録を免除する方針を示したときです。
このとき、23か国を加えました。Play Consoleの「国 / 地域」の一覧に無くて加えられなかった国も9か国あります。配信国はPlay Developer APIでは変更できないので、Play Consoleの画面で私が手作業で追加しています。そのため、追加したあとにAPIで配信国を読み戻して、漏れが無いかを確かめました。
# 製品版の配信国を表示し、--expect に並べた国が1つでも欠けていれば終了コード1で終わる（国の並びは省略）
python mobile/scripts/androidpublisher_country_availability.py --expect JP,CA,AU,NZ,GB,IE,MT,US,...実は1件、誤りもありました。英語が公用語のドミニカ国（DM）とは別に、名前のよく似たドミニカ共和国（DO）まで配信国に入っていたのです。ドミニカ共和国はスペイン語圏で、法令も確かめていなかったので外しました。どの時点で気づいたかは、記録から特定できませんでした。ただ、画面での手作業はこういう間違いが起きるので、最後にAPIの読み戻しで「確かめた国だけが入っている」状態を確認する工程は欠かせないと考えています。
IT女子 アラ美ITアライグマ米国・マルタ: 13歳未満の扱いと「販売しない」をポリシーに書き足した
国ごとの追記の前に、全部の国に共通する土台は、最初の段階（カナダなど）で入れていました。プライバシーポリシーの第5条に、次のことを日本語と英語で書いています。
- 運営者は日本にいて、情報は日本国内のサーバーで保存・処理すること。
- 日本の外から使うと、利用者の情報は日本へ移されること。
- 広告などの外部サービス（Googleなど）は、米国などで処理することがあること。
マルタは、この土台のうえで追加の対応がいりませんでした。EU加盟国で英語が公用語なので、広告の同意フォーム（GDPR向け）も、EUのデジタルサービス法（DSA）で求められる事業者情報の表示も、アイルランド向けに用意したものがそのまま使えます。
米国は、2つの記載を第4条に書き足しました。
1つ目は子どもの扱いです。米国の COPPA（児童オンラインプライバシー保護法）は、13歳未満の子どもの個人情報を守る法律です。DevPickはソフトウェアエンジニア向けで、Play Consoleでも対象年齢を「18歳以上」と申告しています。それでもポリシーには書いていなかったので、次の内容を加えました。
- 13歳未満の子どもを対象にしておらず、意図的に個人情報を集めないこと。
- 集めていたと分かった場合は削除すること。
- 保護者はお問い合わせページから連絡できること。
2つ目は、個人情報の「販売」です。カリフォルニア州の CCPA など、米国の州のプライバシー法には、売上や利用者数の適用基準があります。DevPickの規模では基準に届きません。ただ、米国の利用者向けのポリシーには普通書かれている内容なので、加えておくことにしました。書いたのは次の3点です。
- 運営者は、個人情報を対価を得て第三者に販売しないこと。
- ただし、広告のために端末の識別子をGoogleへ渡すことは、州によっては「販売」や、ターゲティング広告のための「共有」とみなされる場合があること。
- 利用者は、端末の設定で広告のパーソナライズを無効にするか、アプリのマイページにある「広告のプライバシー設定」（表示される場合）から、これを拒否できること。
「販売しません」と書くだけでなく、広告のために識別子をGoogleへ渡していることも同じ段落に並べています。州によっては、それ自体が「販売」や「共有」にあたり得るからです。
アプリ側は変えていません。同意管理の処理は国を決め打ちしておらず、UMPが返す判定にそのまま従う作りです。AdMobの管理画面で米国の州法向けのメッセージを公開すれば、同じ仕組みでマイページの入口が表示されます。公開するかどうかは任意です。
IT女子 アラ美ITアライグマインドDPDP法: 第7条に通知を書いたが、ポリシーだけでは足りなかった
インドには、2023年に成立したデジタル個人データ保護法（DPDP法）と、その細かいルールを決めた規則（DPDP規則2025）があります。規則は2025年11月に公示され、通知・同意・権利の行使・苦情処理といった主な義務は、公示から18か月後の2027年5月13日に施行されます。主な義務はまだ施行されていないので、インドは「そのまま追加」の国として先に配信国へ加えました。
そのうえで、施行を待たずにプライバシーポリシーへ第7条「インドの利用者の方へ」を日本語と英語で書き足しました。それまで最後の条だった「改定」は第8条へ繰り下げています。第7条に書いた項目は次のとおりです。
- 処理する個人データと、その目的
- 同意の撤回の方法と、その効果
- 権利の行使（自分のデータの確認、訂正・削除、本人が亡くなったときなどに代わりに権利を使う人の指名）
- 苦情の窓口と、受付から30日以内に回答すること
- 回答に満足できない場合の、インドのデータ保護委員会（Data Protection Board of India）への申立て
- 18歳未満の扱い
- 日本への移転
回答期限の30日は、規則の上限より短い数字です。規則14は、苦情に回答するまでの期間を、90日を超えない範囲でWebサイトやアプリに公表することを求めています。DevPickでは、その範囲の中で30日と書きました。
18歳未満の扱いも、米国とは基準が違います。インドの法律では、18歳未満が「子ども」です。子どものデータを扱うには保護者の確認可能な同意が必要ですが、DevPickにはその仕組みがありません。そこで、インドの18歳未満の方を対象にせず、意図的に処理しないことを明記しました。
ところが、第7条を書いたあとで、これだけでは足りないことが分かりました。DPDP法の同意は、ポリシーをWebに置いておけば済むものではありません。法第5条・第6条と規則3は、次のことを求めています。
- 同意を求める時点か、それより前に、他の規約や情報とは独立した通知を示すこと。
- 同意は、利用者の明確な肯定的行為（はっきりとした「同意する」の操作）で得ること。
一方で、当時のアプリはインドの端末で同意フォームを出していませんでした。UMPの判定ではインドは同意の対象外なので、アプリは起動するとそのまま広告SDKを動かし、広告の識別子を処理します。施行後は、この動きのままでは条件を満たせません。
対応の方針は、2つの選択肢を持つ形で決めました。
- AdMobの管理画面でインド向けの同意メッセージを作る。アプリは同意を確かめるまで広告SDKを起動しない作りになっているので、メッセージを公開すれば、コードを変えずにインドの端末にも同意フォームが出ます。
- UMPがインド向けのメッセージに対応していない場合は、アプリの中で地域を判定して、通知と同意の画面を自前で出す。同意する前は広告SDKを起動しません。
2026年10月20日の時点では、決めたのは方針までで、どちらもまだ実装していません。施行日までにUMPのインド対応を確かめて、どちらにするかを決めます。
IT女子 アラ美ITアライグマシンガポールPDPA: DPOの連絡先を公開してから配信国に加えた
シンガポールは、23か国をまとめて加えたときには入れず、1か国だけ後に回しました。個人データ保護法（PDPA）は、シンガポールの国内で個人データを集めたり使ったりする国外の事業者にも適用されます。そして、すでに施行されている義務に、ポリシーの書き換えが要るものがあったからです。
中心になったのは、DPO（データ保護責任者）の条文です。PDPAの第11条は、事業者に次のことを求めています。
- PDPAを守る責任者を1人以上指名すること（第11条(3)）。
- 指名した人のうち少なくとも1人の、仕事用の連絡先を公開すること（第11条(5)）。
当時のポリシーは、問い合わせ先として第6条でお問い合わせページを案内しているだけで、DPOを書いていませんでした。そこで、第6条に「運営者がDPOを兼ねる」ことと、サポート窓口のメールアドレスを書き足しました。
あわせて、第8条「シンガポールの利用者の方へ」を日本語と英語で新しく作りました（改定の条は第9条へ繰り下げ）。他の義務が今の記載で足りているかも見直して、足りない項目を入れています。
- DPOの連絡先
- 利用目的と、同意の撤回
- 自分のデータの開示の請求（過去1年間に、そのデータをどう使い、誰に開示したかも含む）
- 訂正の請求
- シンガポールの外への移転と、移転先でも同等の保護をすること
- 重大なデータ侵害が起きたときの通知
最後の項目は、期限がはっきり決まっています。PDPAの第26D条(1)は、データ侵害を「通知が必要なもの」と判断したら、できるだけ早く、遅くとも判断した日から3日以内に、監督機関の PDPC（個人情報保護委員会）へ通知するよう求めています。通知が必要になるのは、個人に重大な害が出るか出るおそれがある場合と、影響を受ける人が500人以上の場合です。ポリシーには、侵害が起きたら通知が必要かどうかを判断し、この基準に当たるときはPDPCへ通知すること、法令で求められる場合は影響を受ける利用者にも通知することを書きました。
小さなつまずきもありました。第8条にもお問い合わせページへのリンクを入れたところ、ページ内に同じリンクが2つになりました。その結果、E2Eテストが「お問い合わせページ」のリンクを1つに絞り込めずに失敗しています。テストでは、第6条の中のリンクを指定するように直しました。
ポリシーを直したあと、シンガポールをPlay Consoleで加えて審査へ送りました。APIの読み戻しで、配信国が32か国になったことを確かめています。
IT女子 アラ美ITアライグマ2回続けて「同意を撤回すれば処理は止まる」と書きすぎた
この一連の作業で一番の反省は、同意の撤回の書き方です。インドの第7条とシンガポールの第8条で、同じ間違いを2回しています。どちらも本番に出る前、プルリクエストに付けているAIレビューの指摘で見つかりました。
1回目はインドの第7条です。最初の案では、撤回の方法として、端末の設定で広告のパーソナライズを無効にすることなどを挙げました。そのうえで、撤回したら対象の個人データの処理を止めて削除する、と書いていました。DPDP法の第6条も、撤回されたら合理的な期間内に処理を止め、委託先にも止めさせるよう求めています。文面だけ見れば、条文の求めにそのまま応えた形です。
AIレビューの指摘は、この約束が実装と合っていない、というものでした。
- 端末の設定で広告のパーソナライズを無効にしても、AdMobによる広告識別子の収集・処理は止まらない。
- アプリは、インドを含む欧州・英国以外の地域では、同意を求めずにAdMobを動かし続けている。
- 「プロフィールを削除」で消えるのはDevPickが保存しているデータだけで、GoogleやRevenueCatへすでに渡した情報を消す処理は無い。
指摘はもっともでした。同じプルリクエストの中で、撤回の記述を「手段ごとに、実際に止まるもの」に書き直しました。いまの第7条は、次のような書き分けになっています。
| 撤回の手段 | 止まるもの |
|---|---|
| 「プロフィールを削除」 | DevPickが保存しているアカウントと関連データを削除し、以後の処理を止める |
| マイページの「広告のプライバシー設定」（表示される場合） | 広告識別子の処理と、広告の配信・リクエストそのもの |
| 端末の設定での広告のパーソナライズの無効化 | パーソナライズ広告の配信だけ。識別子の処理を止めるには、上の設定から撤回するかアンインストールが必要 |
| ブラウザの設定でのCookieの無効化（Web版） | 以後のアクセス状況の収集 |
あわせて、外部サービスへすでに渡った情報は各事業者のポリシーに従って扱われ、運営者には削除できないことも書きました。「広告のプライバシー設定」の行は、インド向けの同意の方針を決めたあとに、撤回すると広告のリクエスト自体が止まる効果をはっきり書き足したものです。
2回目は、続けて取り組んだシンガポールの第8条です。撤回の方法は第7条を参照する形にしたのに、本文では撤回すれば以後の収集・利用・開示を止める、と書いていました。AIレビューは、第7条と食い違っていると指摘しました。第7条では、パーソナライズ広告を無効にしても識別子や診断情報の処理は続き、Cookieを無効にしても止まるのはアクセス状況の収集だけだと書いています。同じポリシーの中で、利用者に矛盾した約束をすることになります。こちらも、手段ごとの効果に絞る形に直しました。
2回とも、間違い方は同じでした。「撤回したら止める」という約束が、アプリで実際に止められる範囲より広かったのです。プライバシーポリシーは、法令に合わせた宣言である前に、アプリの動きの説明だと考えています。実装と違うことを書けば、法令を守るどころか、利用者に事実と違う約束をすることになります。処理の効果を書くときは、その処理をしているコードと突き合わせてから書くべきでした。
IT女子 アラ美ITアライグマまとめ
DevPickのAndroidアプリは、2026年10月15日から18日の4日間で、日本だけの配信から32か国の配信になりました。費用が利用者の数にほとんど比例しない作りなので、判断の材料は国ごとの個人情報保護法だけでした。
- 英語が公用語の国を、国外の事業者に登録や代理人が要るかどうかで「そのまま追加」「ポリシーへの追記が要る」「見送り」に分けました。
- 米国向けには、13歳未満の子どもの扱いと「販売しない」をポリシーに書き足しました。
- インド向けには、ポリシーに通知の条を書きました。ただ、2027年5月13日の施行までに、アプリの中で同意を得る仕組みがまだ要ります。
- シンガポールは、DPOの連絡先を公開してから配信国に加えました。
- 配信国はPlay Consoleの手作業で加え、最後はAPIの読み戻しで確かめました。
振り返って一番大事だと思うのは、ポリシーに書く「効果」を実装と突き合わせることです。法令の条文に合わせて「撤回すれば止まる」と書くのは簡単ですが、アプリで本当に止まらなければ、利用者への約束が事実と違ってしまいます。配信国を増やすほどポリシーの条も増えるので、条を足すたびに、書いた効果をコードで確かめたいと考えています。
IT女子 アラ美ITアライグマ
