オンチェーンの取引は誰でも見える|企業がウォレットアドレスを公表する前に
エグゼクティブサマリー
- パブリックチェーンでは、アドレスに紐づく残高と送受信の履歴を誰でも参照できます。ethereum.orgは、暗号資産のトランザクションの多くがパブリックなブロックチェーン上で公開されていると説明しています
- アドレスの文字列そのものに持ち主の名前は書かれていません。ethereum.orgはユーザーのアイデンティティは多くの場合仮名であるとしたうえで、本人が意図的に現実世界のアイデンティティにリンクする場合と、オンチェーン・オフチェーンのデータ分析で関連付けられる場合を挙げています
- したがって企業にとっての分岐点は、見えるかどうかではなく紐づけるかどうかです。これが当社の公式アドレスですと一度公表すれば、そのアドレスの過去と将来の全取引が自社名で読める状態になり、あとから非公開に戻すことはできません
- アドレスの公表は技術作業ではなく広報物です。文字列は差し替えの標的になるため、正本のチャネルを1つに決め、更新権限者・変更時の周知手順・利用者からの照会への一次回答者を先に決めます
- そもそも公表せずに済む設計が先です。登録を受けた事業者を経由する型では自社アドレスを外部に出す必要がない場合があり、公表が必要な場面に限って、用途ごとにアドレスを分けます
この記事の目次
オンチェーン決済の検討が具体化すると、ある時点で「では、うちの受取アドレスをどこに載せますか」という問いが出てきます。技術的な確認事項として上がってくるのですが、これは技術の話ではありません。アドレスを自社名と結びつけて外に出すという判断は、取り消せない広報上の意思決定です。
パブリックチェーン(誰でも参加でき、記録を誰でも参照できる型のブロックチェーン)では、残高も送受信の履歴も公開されています。ただし公開されていること自体は、それだけでは企業のリスクになりません。効いてくるのは、その公開情報が自社名と紐づいた瞬間からです。鍵を誰が持つのかという管理形態は法人のステーブルコイン管理で扱っているので、本記事はこの一点に絞ります。
図: アドレスの公表が不可逆になる三段階(当サイト作成)
何が、誰に見えているのか
用語を先に一言ずつ定義します。アドレスは、チェーン上の宛先を表す文字列です。ethereum.orgの開発者ドキュメントによれば、イーサリアムの外部所有アカウント(秘密鍵を持つ人が制御するアカウント)は、0x に40文字の16進数を続けた42文字のアドレスを持ちます。トランザクションは、そのアドレスから開始される取引の1件1件で、同ドキュメントは含まれる項目として送信者のアドレス(from)、受信者のアドレス(to)、送金する数量(value)、そのアカウントからの送信回数を示すカウンター(nonce)などを挙げています。
そしてブロックエクスプローラとは、こうしたチェーン上の記録を検索して表示できる公開のウェブサイトの総称です。アドレスの文字列を貼り付ければ、残高とそのアドレスが関わった取引の一覧が表示されます。特別な権限も契約も申請も要りません。
💡 社内説明の順番はここから
「見られてしまう」という言い方は、防げるものを防げていないような印象を与えます。正確には、公開されていることがこの仕組みの前提です。銀行口座に例えるなら、口座番号を知っている人が誰でも入出金明細を見られる状態が最初から標準になっている、と説明すると齟齬が起きません。
チェーンによって公開の範囲は異なります。参加者を限定する型のチェーンでは前提が変わるため、選定の段階からこの論点が関わります。詳細はパブリックチェーンとパーミッションドチェーンの違いを参照してください。
論点は「見えるかどうか」ではなく「自社名と紐づくかどうか」
ここが本記事の芯です。ethereum.orgは、ほとんどの暗号資産のトランザクションはパブリックなブロックチェーン上で公開されているとしたうえで、ユーザーのアイデンティティは多くの場合仮名であり、意図的に現実世界のアイデンティティにリンクされているか(例:ツイッターやGitHubのプロフィールにETHアドレスを含めるなど)、基本的なオンチェーンおよびオフチェーンのデータ分析を使用して現実世界のアイデンティティと関連付けることができると説明しています。
紐づけには2つの経路がある、ということです。ひとつは第三者が分析によって推定する経路。もうひとつは、本人が自分で宣言する経路です。企業が公式アドレスを公表するのは、後者を自ら実行することにほかなりません。しかも公表は、その時点以降だけに効くのではありません。
| 公表する前 | 公表したあと | |
|---|---|---|
| 残高 | 誰でも見えるが、どこの会社のものかは分からない | 自社の残高として読める |
| 送受信の履歴 | 匿名の記録として見える | 公表より前の分も含め、自社の取引として読める |
| 取引の相手先 | 別のアドレスとしか分からない | 相手先の存在・取引の頻度・規模の傾向が推測されうる |
| 送信の回数 | カウンターの数値として見える | 自社が何回動かしたかとして読める |
| 訂正・撤回 | ― | 記録は消えず、公表した事実も残る |
⚠️ 「あとで非公開に戻す」という選択肢は存在しません
告知ページを削除しても、削除前にそれを見た人の手元には自社名とアドレスの対応が残ります。以後の取引もその対応づけを使って追えます。公表を検討するときに社内で確認すべき問いは「載せてよいか」ではなく、「この対応づけが5年後も残ることを前提に、この設計で問題ないか」です。公表の可否を、後から見直せる運用ルールとして稟議に書かないでください。
アドレスの公表は、技術作業ではなく広報物です
もうひとつ、社内で見落とされやすい論点があります。公表したアドレスの文字列は、そのまま差し替えの標的になるという点です。
利用者や取引先は、その文字列が本物かどうかを自分では判定できません。42文字の英数字を目視で照合する作業は現実的ではないからです。だから偽の告知ページ、偽の公式アカウント、案内文の差し替えといった経路が成立します。金融庁は「インターネット取引サービスへの不正アクセス・不正取引にご注意ください」で、実在する事業者のウェブサイトを装った偽のウェブサイト等を通じた被害に注意を促し、メールやSMSのリンクを開かず正しいURLをブックマークからアクセスすることを呼びかけています。利用者側に求められている対策が、正しい入口を1つ覚えておくことに集約されている点に注目してください。裏を返せば、その正しい入口を提供する側の設計が先に要るということです。
この4点は、実際の被害が出てから決めることができません。なりすまし広告への対策強化についてはSNSなりすまし詐欺広告の対策要請を読むで、広告を出す側に跳ね返る経路を整理しています。
送る側の手続きが変わりつつある点にも触れておきます。金融庁が令和8年8月6日に公表した「暗号資産を用いた詐欺被害等防止に向けた対策の一層の強化について(要請)」は、暗号資産交換業者への要請11項目のうち④で出庫先情報の事前登録及び詐欺等との関連性の確認と、新規に登録された出庫先に対する一定期間の出庫制限を挙げ、②では第三者からの指示による口座開設や暗号資産の購入・出庫は詐欺のおそれが高い旨を顧客に注意喚起するよう求めています。名宛人は暗号資産交換業者であって事業会社ではありませんが、自社が公表したアドレスに送金してもらう導線は、送る側でこうした手続きを通るという前提で設計してください。この文書の読み解きは金融庁の暗号資産詐欺対策要請を読むにまとめてあります。
事案:海外の取引先1社に受取アドレスを伝えるD2C事業会社
以下は公表資料をもとに構成した想定事案です。実在の企業・案件ではありません。
①既存事業と既存ユーザー——国内で自社ブランドの生活雑貨をオンラインで販売する、従業員40人規模のD2C事業会社です。販売は自社ECと国内モールが中心で、既存ユーザーは日本の一般消費者。会員向けのメールマガジンとSNSアカウントを運用し、キャンペーンの告知はそこから流しています。
②やろうとしていること——海外の卸売先1社からの入金について、着金の速さを理由にステーブルコインでの受け取りを試したいという相談が先方から来ています。自社の受取アドレスを相手に伝える必要があります。少額の1回から始め、事務負担を実測してから継続を判断する方針です。
③登録業者との役割分担——口座の開設、本人確認、受取後の円転、取引履歴の提供は、登録を受けた事業者が担います。自社が担うのは、受取先を相手に伝え、着金を確認し、記帳することだけです。自社は一般消費者から暗号資産を受け取らず、第三者の資金を預からず、自社ECの決済手段として一般に提供することもしないという前提を、検討の最初に文書で固定します。この前提が変わる案が出てきたら、そこで法務に戻す運用にします。
④想定される告知・導線の具体像——ここが本記事の論点です。この事案では、アドレスを一般に公表する必要はありません。伝える相手は1社だけだからです。したがって自社ドメインに公開ページは作らず、先方との取引に使う契約書類の添付資料としてアドレスを通知し、送付前に電話で読み合わせて照合します。社内では、経理課の担当者が事業者の管理画面で受取先を確認し、契約書類に転記した文字列と画面上の文字列を別の担当者が突合します。変更する場合は書面と電話の二経路で確認する旨を覚書に明記します。会員向けのメールマガジンとSNSには一切載せません。既存ユーザーには関係のない取引であり、載せれば当社の公式アドレスという対応づけを、必要のない範囲にまで広げてしまうからです。問い合わせが来た場合の一次回答は広報が持ち、当社は一般のお客様に暗号資産の送付をお願いすることはありませんという定型文を先に用意しておきます。
そもそも公表しないで済む設計が先にあります
事案の④が示すとおり、実務で最初に検討すべきは「どう公表するか」ではなく「公表せずに済むか」です。決済事業者や登録を受けた取扱業者を経由する型では、相手方は事業者側の指定する導線で支払い、自社アドレスを外部に出す必要がない場合があります。まず事業者に、その形が使えるかを確認してください。
公表が必要になるのは限られた場面です。ひとつは取引先に受取先を伝える場合、もうひとつは公開の受付窓口を置く場合。どちらかに当てはまるなら、次に決めるのは用途ごとにアドレスを分けることです。本業の入出金に使うアドレスと外向けに公表するアドレスを混ぜると、公表した瞬間に本業の取引の頻度や規模まで自社名で読める状態になります。分けておけば、外から読める範囲をその用途の分だけに限定できます。
✅ 公表の可否を稟議に上げる前に埋める確認事項
- そのアドレスを見せる必要があるのは誰か(不特定多数か、特定の取引先か)
- 事業者側の導線を使えば、自社アドレスを外に出さずに済まないか
- 公表するアドレスは、本業の入出金に使うアドレスと分かれているか
- そのアドレスの過去の取引履歴を自社名で読まれて差し支えないか
- 正本のチャネルは1つに絞れているか。他の媒体に文字列を転記していないか
- 正本ページの更新権限者と承認者が決まっているか
- 変更・追加が必要になったときの周知の順番と文面のひな形があるか
- 照会の一次回答者と定型文が、公表より前に用意されているか
- 誤送金の申し出やなりすましの申告を受けたときの受付窓口が決まっているか
最後に、制度面の留保を置いておきます。自社の設計が何らかの業規制の対象になるかどうかを、社内判断だけで結論づけることはできません。金融庁の事務ガイドライン(第三分冊:金融会社関係「17 電子決済手段等取引業者関係」)Ⅰ-1-2-2④は、資金決済法第2条第10項第3号の「他人のために電子決済手段の管理をすること」への該当性について、個別事例ごとに実態に即して実質的に判断するべきであるとしています。本記事も、特定の公表方法が適法である/違法であると述べるものではありません。業務フロー図を作った段階で、必ず弁護士に確認してください。
アドレスを公表するかどうかは、稟議書の末尾に付ける技術的な確認事項ではありません。公表した瞬間に、自社の取引の一部が恒久的に外から読める形になる——この一文を先に社内で共有できていれば、その後の設計はほとんど自動的に決まります。
よくある質問
ブロックチェーンの取引は匿名だと聞きましたが、誰でも見えるのですか?
匿名ではなく仮名だと整理するのが正確です。ethereum.orgは、暗号資産のトランザクションの多くがパブリックなブロックチェーン上で公開されており、ユーザーのアイデンティティは多くの場合仮名であると説明しています。アドレスの文字列に持ち主の名前は書かれていませんが、残高と送受信の記録そのものは誰でも参照できます。企業にとっての問題は、その仮名がいつ自社名と結びつくかです。
公表したアドレスを、あとから非公開に戻すことはできますか?
できません。チェーン上の記録は残り続け、公表したという事実も第三者の保存や引用の形で残ります。告知ページを削除しても、削除前にそのページを見た人は自社名とアドレスの対応を知っており、その対応づけを使えば以後の取引も追えます。だから公表は、取り消せる作業ではなく一度きりの意思決定として扱う必要があります。
取引先に受取アドレスを伝えるのも「公表」になりますか?
不特定多数への公表と、特定の取引先1社への通知は、外から見える範囲が異なります。ただし相手方の社内でその対応づけが共有され、記録として残る点は同じです。実務上は、公開の受付先として広く告知する場合と、相手を限定して伝える場合とで、必要な手当てが変わります。少なくとも、本業の入出金に使うアドレスと外部に伝えるアドレスを分けておく判断は、どちらの場合にも効きます。
自社アドレスを公表すると、規制上なにか義務が生じますか?
当サイトが個別の設計について法令上の該当性を判定することはできません。金融庁の事務ガイドラインは、電子決済手段の管理などの該当性について個別事例ごとに実態に即して実質的に判断するべきであるとしており、社内判断だけで結論づけられる論点ではありません。公表そのものより、公表によって何を引き受けることになるか(照会対応・誤送金の申し出・なりすましの申告)のほうが先に発生する実務です。業務フロー図を作った段階で弁護士に確認してください。
参照法令・公表資料
- 金融庁一次資料
- ethereum.org
- ethereum.org 開発者ドキュメント
社内資料に引用する際は、リンク先の原文と公表日をあわせてご確認ください。法令・ガイドラインは改正されます。