ウォレットアドレスは、ブロックチェーン上で送金先を指定するための識別子です。これに対し、MemoやTagは、同じ受取アドレスに届いた入金を利用者や用途ごとに振り分けるための追加情報として使われます。したがって、MemoやTagが指定されている入金では、アドレスだけが正しくても十分とは限りません。本稿では主に一般利用者による取引所、交換サービス、カストディ型ウォレットへの入金を対象とし、秘密鍵の管理方法や各資産の投資価値は扱いません。
どのように根拠を確認するか
技術的な判定には、各プロトコルの公式ドキュメントを優先します。具体的には、アドレスやトランザクションの仕様、MemoやDestination Tagのデータ型、受取側が追加識別子を要求できる仕組みを確認します。送金の取消しや詐欺リスクについては、プロジェクトの公式資料と公的機関の消費者向け情報を補助的に参照します。
プロトコル仕様が変わらなくても、取引所が採用するネットワーク、入金アドレス、Memo・Tagの要否、復旧手続きは変更され得ます。そのため、技術仕様から確認できる事実と、受取サービスの現在の運用条件は分けて扱う必要があります。数値による確率評価、手数料計算、処理時間の見積もり、価格予測は本稿の判定に含めません。
アドレス、Memo、Tagは何を識別するのか
ウォレットアドレスはブロックチェーン上の送金先
ウォレットアドレスとは、送金トランザクションの宛先として入力する文字列です。ただし、その構造はネットワークによって異なり、必ずしも「一人につき一つの銀行口座番号」のような意味になるわけではありません。個人が秘密鍵を管理するアドレスの場合もあれば、取引所が多数の利用者の資産をまとめて管理する共用アドレスの場合もあります。
たとえばXRP Ledgerでは、アカウントを識別するクラシックアドレスとは別に、Destination Tagを一つの文字列へ組み込めるX-address形式も定義されています。ただし、プロトコルがネイティブに扱う形式と、ウォレットや取引所が表示・解釈できる形式は必ずしも同じではありません。[1]
Memoはトランザクションに添付される情報
Memoは通常、アドレスそのものではなく、トランザクションに付加されるデータです。用途には入金者の識別、請求番号、返金情報、受取サービス内部の振り分け番号などがあります。
Stellarでは、Memoはトランザクションに追加できる任意フィールドとして定義され、テキスト、数値ID、ハッシュなど複数の型があります。プロトコル上は任意でも、受取サービスが利用者を特定するために入力を必須としている場合があります。つまり、「ブロックチェーンの仕様上は任意」と「今回の入金手続きでは必須」は両立します。[2]
Tagは共用アドレス内の宛先を区別する
Tagという表示は、特にXRP LedgerのDestination Tagで広く見られます。これは、共通の受取アドレスに送られた資産を、受取側のどの利用者または目的へ割り当てるか示す整数です。XRP Ledgerの公式資料では、一般的な受取アカウントの中で特定の顧客への支払いを識別する仕組みとして説明されています。[3]
受取アカウントが「Destination Tag必須」の設定を有効にしている場合、Tagのない支払いはネットワーク側で拒否されます。一方、形式上有効でも間違ったTagについては、ブロックチェーンが受取サービスの顧客データベースまで確認することはできません。そのため、誤った利用者番号を入力したトランザクションが処理され、受取サービス側で入金先を特定できなくなる可能性があります。[4]
なぜアドレスだけでは入金者を特定できないことがあるのか
取引所が利用者ごとに独立したオンチェーンアカウントを用意すれば、アドレスだけで入金先を区別できます。しかし、ネットワークによってはアカウント維持条件や鍵管理の負担が生じるため、一つのアドレスを複数の利用者で共有し、内部データベースで残高を管理する方式が採用されます。
この方式では、ブロックチェーンが記録するのは「共用アドレスに資産が届いた」という事実までです。受取サービスは、MemoやTagを自社データベースの利用者番号と照合して、誰の残高へ反映するか決めます。したがって、追加識別子を省略すると、オンチェーン送金は完了していてもサービス内残高へ自動反映されない、という差が生じます。
Stellarの公式資料も、カストディ事業者が一つのプールアカウントを共有し、追加のIDで個々の利用者を区別する構造を説明しています。StellarにはIDをアドレスへ組み込むMuxed Accountもありますが、すべてのウォレットや取引所が対応しているとは限らないため、従来のMemoが必要な場面も残っています。[5]
MemoとTagは同じものなのか
利用者の操作という観点では、どちらも「受取側から指定された追加識別情報」として似ています。しかし、プロトコル上のデータ構造まで同一という意味ではありません。
| 項目 | 主な役割 | 入力内容 | 注意点 |
|---|---|---|---|
| ウォレットアドレス | ネットワーク上の送金先を指定する | 受取側が発行した文字列またはQRコード | 資産だけでなくネットワークも一致させる |
| Memo | トランザクションに識別情報や参照情報を付加する | 数値、テキスト、ハッシュなど。仕様とサービスによって異なる | 「任意」と表示されても、受取側では必須の場合がある |
| Destination Tag | 共用アドレス内で顧客や支払い目的を区別する | 受取側が指定した数値 | 別のTagへの置換や推測入力をしない |
送金画面では「Memo」「Tag」「Memo/Tag」「Destination Tag」「Payment ID」など異なる名称が使われることがあります。名称だけから互換性を判断せず、受取画面に表示された項目名、値、ネットワークをそのまま対応させるのが基本です。あるネットワーク用のMemoを、別のネットワークのTag欄へ流用できるとは限りません。
主張レジストリ
| 主張 | 確認状況 | 一次資料の種類と名称 | 公開・更新日 | 制限 | 結論を変え得る要因 |
|---|---|---|---|---|---|
| StellarのMemoはトランザクションに付加される任意フィールドであり、複数のデータ型がある | 確認済み | プロトコル公式文書「Operations and Transactions」[2] | 2026年7月24日更新 | 任意であるのはプロトコル上の扱い。受取サービスが入力を要求する可能性は残る | プロトコル改定、受取サービスの入金方式変更 |
| XRP Ledgerでは、Destination Tagの入力を要求するアカウント設定があり、Tagなしの支払いを拒否できる | 確認済み | XRP Ledger公式チュートリアル「Require Destination Tags」[4] | ページ表示では「11か月前」。具体的な更新日は非表示 | 必須設定を有効にしていないアカウントには同じ拒否動作が適用されない | 受取アカウントの設定変更、プロトコル仕様の変更 |
| 同じStellarアカウントを複数利用者で共有する場合、MemoまたはMuxed Accountによる内部識別が使われる | 確認済み。ただし対応状況は条件依存 | Stellar公式ガイド「Pooled accounts: muxed accounts and memos」[5] | 2026年7月22日ごろの更新表示 | Muxed Accountはすべてのウォレットや取引所で受け付けられるとは限らない | ウォレット、取引所、アンカーの対応拡大または入金方式変更 |
| 特定の送金でMemoまたはTagが必要かどうか | 受取側の条件に依存 | 受取サービスがその都度表示する入金指示 | 固定日なし。送金直前の表示を確認 | 過去の入金情報、第三者の記事、以前保存したアドレスでは現在の要件を確定できない | 対応ネットワーク、入金システム、アドレス、口座状態の変更 |
| 誤ったMemoやTagを付けた送金が必ず回収できる | 確認できない | すべてのネットワークと受取サービスに共通する一次資料は存在しない | 該当なし | 復旧可能性は秘密鍵の管理者、内部記録、本人確認、受取側の手続きに左右される | 受取サービスの調査結果、復旧方針、技術的な資金管理方法 |
通常の利用者が送金前に照合する項目
- 資産名を確認する：同じような名称やシンボルの資産を取り違えない。
- ネットワークを一致させる：受取側が指定したネットワークと、送金側で選択するネットワークを一致させる。Ethereum系では同じアカウントを複数ネットワークで利用できても、残高と取引履歴はネットワーク間で共有されません。[6]
- アドレス全体を照合する：先頭と末尾だけでなく、可能ならコピー後の文字列全体を確認する。クリップボードを書き換えるマルウェアや偽のQRコードにも注意が必要です。[7]
- Memo・Tag欄の有無を確認する：表示されている場合は、空欄にせず正確にコピーする。数字の前後へ空白や説明文を付け加えない。
- 保存済み情報を無条件で再利用しない：以前と同じサービスでも、アドレス、ネットワーク、Memo・Tagが更新される可能性があるため、現在の入金画面と再照合する。
- 条件が不明なら送信を確定しない：受取側の案内で「Memo不要」と明示されているか、追加欄自体がないことを確認する。「分からないため0を入力する」といった推測は避ける。
少額のテスト送金は、アドレスやネットワークの入力ミスを早期に見つける一つの方法です。ただし、テスト時と本送金時に入金情報が変わっていないこと、二回分のネットワーク手数料が発生し得ることを踏まえる必要があります。テスト送金を行っても、誤った情報を二度使えば安全性は高まりません。送金先とネットワークの再確認が前提です。[8]
入力を誤った場合に起こり得ること
アドレスを誤った場合：形式上有効な別人のアドレスへ送金すると、通常は送信者が一方的に取り消せません。Bitcoinの公式案内でも、確定した支払いは受取人による返金以外の方法で反転できないと説明されています。[9]
ネットワークを誤った場合：文字列として同じアドレスを利用できるネットワークでも、台帳は別です。受取サービスがそのネットワークを監視・対応していなければ、自動入金されず、復旧できない可能性があります。実際の対応可否は受取側に依存するため、ネットワーク名の一致はアドレス照合と同じ優先度で扱う必要があります。[10]
MemoやTagを省略した場合：ネットワークがトランザクションを拒否するケースと、共用アドレスへの送金自体は成立するものの、受取側で利用者を特定できないケースがあります。トランザクションハッシュ、送金元アドレス、受取アドレス、資産、ネットワーク、数量、入力したMemo・Tagを保存し、受取サービスの正規窓口へ提示するのが実務上の次の手順です。返還や残高反映が保証されるわけではありません。
誤ったMemoやTagを入力した場合：別の利用者に対応する有効な識別子であれば、受取側の内部処理が誤った残高へ紐付ける可能性があります。ブロックチェーン上で成功と表示されても、サービス内で正しく入金されたことまでは意味しません。
リスクと動的情報の再確認
- 不可逆性：送信確定後に取り消せないことを前提に、確認は署名前に行う。
- フィッシング：検索広告、SNSの返信、突然届いたメッセージから入金ページを開かず、公式のアプリや保存済みの正規経路から操作する。公的機関を装い、資産保護を理由に暗号資産の送金を求める手口も報告されています。[11]
- 表示名の違い：MemoとTagを同義語だと決めつけず、受取側が指定した名称と形式に従う。
- 対応状況の変化：資産名が同じでも、利用できるネットワークやMemo・Tagの要件はサービスごとに異なり、後から変更される可能性がある。
- 相場変動：送金確認や入金調査に時間を要する間も暗号資産の価格は変動し得る。価格や法的取扱いも国・地域によって異なるため、送金技術上の成功と経済的・法的な評価は分けて考える。
動的情報は、送金直前に受取画面を開き直し、資産、ネットワーク、アドレス、Memo・Tagの四項目を再取得して確認します。交換サービスを利用する場合は、対応方向やネットワークに加え、取引方向とコンプライアンス確認の結果によって必要条件が異なる可能性があります。証拠としては入金画面の表示、トランザクションハッシュ、対応するブロックチェーンエクスプローラーの記録を保持します。
実際に交換を進める前には、過去の情報を流用せず、現在利用できる交換方向と入金条件を確認することができます。この案内は技術的主張の根拠ではなく、対象資産、ネットワーク、Memo・Tagの要否を申請時点で確かめるための実務的な確認先です。
