ステーブルコイン対応とプライバシーポリシー｜ウォレットアドレスの扱いと改定の告知

ステーブルコイン（法定通貨と価値が連動するデジタルな決済手段。日本では資金決済法上の「電子決済手段」として整理されています）建ての支払いを、既存の決済手段の隣に1つ足す。この作業は決済プロジェクトとして立ち上がりますが、実際に最初に発生するのは、自社が自分で書いている文書を1枚書き換えるかどうかの判定です。その文書がプライバシーポリシーです。

当サイトはこれまで、ライセンス区分・取扱業者の役割・会計税務・トラベルルール・表示規制を扱ってきましたが、個人情報保護法を正面から扱うのはこの記事が初めてです。理由は単純で、この論点だけは相手が金融庁でも取扱業者でもなく、自社の文書と自社のデータベースだからです。本記事は、2026年8月時点で公開されている原文を確認しながら、どこから手を付けるかを整理します。

事案：会員35万人のオンラインサービスが支払手段を1つ足す

以下は当サイトが公表資料をもとに構成した想定事案です。実在の企業・案件ではありません。

国内で会員制のオンラインサービスと自社ECを運営する事業会社があります。会員は約35万人で、すべて一般消費者です。会員登録時に取得しているのは氏名・メールアドレス・配送先住所・電話番号で、購入のたびに注文履歴と支払方法の記録が会員IDにひも付いて蓄積されます。プライバシーポリシーは数年前に作られたもので、利用目的の欄には商品の発送、代金の決済、問い合わせ対応、サービスの改善といった項目が並んでいます。

この会社が検討しているのは、決済手段の選択肢にステーブルコイン建ての支払いを1つ加えることです。役割分担ははっきりしています。会員の口座開設と本人確認は電子決済手段等取引業者が担い、自社は行いません。自社に残るのは、どの会員がいつ何を買い、その支払方法として何を選んだかという注文情報と支払方法の記録です。

告知と導線の具体像も見えています。プライバシーポリシーの改定ページ、その下部に置く改定履歴、会員向けの通知メール、決済手段選択画面に置く注記、そしてFAQの5点です。制作の担当は広報と制作チームで、公開日は決済機能のリリース日に合わせる想定になっています。

ここで最初に止まるのが、ポリシーを改定する必要があるのか、あるとしてどの欄なのかという問いです。そして多くの場合、この問いは「ウォレットアドレスは個人情報か」という形で法務に投げられます。この投げ方が、順番として逆になっています。

判定しているのは文字列ではなく、自社のデータベースの持ち方

個人情報保護法第2条第1項第1号は、個人情報を、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるものと定義し、そのあとにかっこ書きを置いています。「他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。」という一文です。

このかっこ書きがあるために、「この文字列は個人情報か」という問いは、その文字列だけを見ても閉じません。個人情報保護委員会のガイドライン（通則編）は、「他の情報と容易に照合することができ」るとは、事業者の実態に即して個々の事例ごとに判断されるべきであるが、通常の業務における一般的な方法で、他の情報と容易に照合することができる状態をいい、例えば、他の事業者への照会を要する場合等であって照合が困難な状態は、一般に、容易に照合することができない状態であると解される、と説明しています。

つまり、判定の分岐は文字列の性質ではなく、自社が同時に何を持っていて、通常の業務でどう突き合わせられるかのほうにあります。

図: 判定の分岐が生じる場所（結論ではなく分岐点のみを示しています。当サイト作成）

だとすると、最初にやるべきは条文の解釈ではありません。自社の保有情報の棚卸しです。ステーブルコイン建ての支払いを1件処理したときに、自社のシステムに何の行が増えるのかを、実際のテーブル定義とログ出力を見ながら書き出します。

なお、法人ウォレットとカストディの整理で扱ったとおり、鍵を誰が持つかという設計はそれ自体が別の論点です。ここで棚卸しの対象にしているのは、鍵ではなく自社のデータベースに残る記録のほうです。

書き換わるのは「利用目的」の欄だけではない

プライバシーポリシーの改定というと、利用目的の箇条書きに1行足す作業だと理解されがちです。しかし条文を並べると、連動する欄は複数あります。

この表で既存の整理と違うのは、右の2列です。3列目が「現物を持っているのは誰か」で、そこが社外になっている行は、社内会議を何回開いても埋まりません。4列目は、弁護士に投げる前に自社で決めておくことで、ここが空欄のまま相談に行くと一般論しか戻ってきません。

とくに第28条は見落とされやすい欄です。条文は、外国にある第三者に個人データを提供する場合には、第27条第1項各号に掲げる場合を除くほか、あらかじめ外国にある第三者への提供を認める旨の本人の同意を得なければならないと定め、第2項で、その同意を得ようとする場合には、あらかじめ当該外国における個人情報の保護に関する制度、当該第三者が講ずる個人情報の保護のための措置その他当該本人に参考となるべき情報を本人に提供しなければならない、としています。同意の取り方だけでなく、同意の前に何を示すかまで条文に書かれている、という構造です。

役割分担の話は、トラベルルールとAML実務で扱った受取人情報の通知とも接続します。送付にあたって受取人の情報が通知される仕組みがある以上、「自社は本人確認をしていないから無関係」という整理は、自社側に残る記録の話には届きません。誰が確認したかと、自社に何が残るかは別の問いだからです。

なお、利用者に対する説明の現物を持っているのが取扱業者側であることは、金融庁の事務ガイドライン（第三分冊：金融会社関係）17からも読めます。Ⅱ－２－２－１－２の⑶①は、内閣府令に規定された事項について、利用者の知識、経験等を勘案して、取引内容、取引形態及び取り扱う電子決済手段等に応じて、適切に説明を行っているか、を着眼点として挙げています。取引の説明は業者側、自社のデータの説明は自社側、という線がここで引かれます。

改定そのものが、ひとつの告知物である

改定の内容が固まると、次は「いつ、どこに、どう出すか」の設計に移ります。ここが実務の中心です。

出発点は第17条第2項です。個人情報取扱事業者は、利用目的を変更する場合には、変更前の利用目的と関連性を有すると合理的に認められる範囲を超えて行ってはならない、と定められています。ガイドライン（通則編）はこの範囲について、変更後の利用目的が変更前の利用目的からみて社会通念上、本人が通常予期し得る限度と客観的に認められる範囲内で変更することは可能である、と整理し、この「本人が通常予期し得る限度と客観的に認められる範囲」を、本人の主観や事業者の恣意的な判断によるものではなく、一般人の判断において、当初の利用目的と変更後の利用目的を比較して予期できる範囲をいう、と説明しています。この範囲を超える取扱いを行う場合には、第18条第1項により、あらかじめ本人の同意を得ることが条文上求められます。

つまり、改定案が「範囲内の変更」なのか「同意が要る変更」なのかで、使うべき告知の面が変わります。そして条文は、その面について異なる言い回しを使っています。

ガイドライン（通則編）は、「本人に通知」を本人に直接知らしめることとし、事業の性質及び個人情報の取扱状況に応じ、内容が本人に認識される合理的かつ適切な方法によらなければならない、として、電子メール、FAX等により送信し、又は文書を郵便等で送付することにより知らせることを事例に挙げています。一方の「公表」は、広く一般に自己の意思を知らせること（不特定多数の人々が知ることができるように発表すること）とされ、自社のホームページのトップページから1回程度の操作で到達できる場所への掲載が事例として挙がっています。

ここに第32条第1項の「本人の知り得る状態（本人の求めに応じて遅滞なく回答する場合を含む。）」が加わります。かっこ書きが示すとおり、常時掲示だけが選択肢ではなく、求めに応じて遅滞なく回答する形も含まれる書き方になっています。常時掲示・能動的な通知・求めに応じた回答という3つの温度差が条文上あり、どの欄をどの面に載せるかが設計の対象になります。なお、施行令第10条は第32条第1項第4号を受けて、安全管理のために講じた措置、苦情の申出先などを列挙しています。

図: 棚卸しから機能公開までの順序と、日付の突き合わせが必要になる箇所（当サイト作成）

告知面の設計は、具体的には次の3点に分解できます。

3点目は、実務で最も頻繁に起きる事故です。決済機能のリリースが1週間前倒しになり、古い版のポリシーのまま新しい支払手段が動き始める。あるいは逆に、改定だけが予定どおり公表され、まだ公開されていない機能の記載が先に見えてしまう。どちらも文書としての瑕疵というより、公開日を1つの表で管理していなかったことの結果です。改定ページ・通知メール・決済画面の注記・FAQ・機能リリースの5つを、同じ1枚のスケジュール表に載せてください。

用語の定義や関連する制度の整理は用語集にまとめています。ポリシー本文を書き始める前に、自社が使う用語の表記を統一しておくと、改定履歴の差分が読みやすくなります。