暗号資産の送金では、受取側から資産、ネットワーク、アドレス、必要な追加情報を取得し、実際の受取量が最低条件を満たすか、手数料が足りるかを確認します。送信後は正しいネットワークの取引識別子TxIDで、実行結果と口座反映を調べます。同じ形式のアドレスやTxIDだけでは完了とは判断できません。情報不一致、最低量不足、署名内容が不明な場合は送信を止めます。
送金欄に20 USDTと入力しても、相手の受取量は19かもしれません。アドレスが同じでも、安いネットワークへ替えただけで入金が反映されないこともあります。必要なのは受取条件一式の照合であり、画面更新を繰り返すだけでは解決しません。
同じ20 USDTの仮定例を、受取情報の取得から照合まで追います。中止すべき場面、元の取引を追えばよい場面、オンチェーン成功だけでは口座反映にならない理由を確認してから、次の送金へ進みましょう。
暗号資産の送金では操作の種類を先に確認する
自己管理のオンチェーン送金、取引所からの出金、サービス内部の振替では、完了を示す記録が異なります。 公開取引を作る方式も、内部台帳で処理する方式もあります。確認経路を間違えると、処理待ちの申請をすでにネットワークへ送信済みと誤認します。
ウォレット、アドレス、管理責任に不慣れなら、ウォレットでの送受金確認から始めてください。本記事では入金の最低条件と未反映時の確認を詳しく扱い、必要な操作条件も本文で説明します。ほかの記事をすべて読まなくても、この例を確認できる構成です。
オンチェーン送金・出金申請・内部振替を分ける
セルフカストディからの送金では、自分で取引を確認して署名します。取引所からの出金は、まずサービスへの申請で、審査、順番待ち、オンチェーン送信を経る場合があります。「申請成功」は公開取引がある証拠とは限りません。内部振替は受取アカウントなどで処理され、独立したTxIDがない場合もあります。
操作を特定してから追う記録を決めます。オンチェーンならネットワークとTxID、内部振替ならサービスの振替番号と受取記録を照合します。まだ送信されていない出金申請を、公開取引が見つからないというだけで重複申請しないでください。
受取情報には何が必要か
少なくとも資産、ネットワーク、アドレス、MemoやTagの要否を確認します。サービスへの入金なら、実際の最低受取量、受付状態、反映条件も必要です。Kraken公式「How to deposit cryptocurrencies」の2026年8月19日版でも、資産、ネットワーク、アドレス、追加情報、必要承認数は分けて示されています。
自分のウォレットへ送るなら、受取アカウントの管理権限と復旧情報を確認します。アドレスが見えるだけでは、後で送金できる証拠にはなりません。バックアップが復元できる範囲で作成元を確認し、自分で復元できない場所へ資産を入れないようにします。
アドレスだけでなくネットワークとトークンを一致させる
正しいアドレスは必要ですが、資産とネットワークも受取側の要件に一致しなければなりません。 送信画面が文字列を受け付けても、サービスがその経路に対応するとは限りません。同じ名前のトークンが目的の資産とも限りません。
同じ銘柄名でも対応ネットワークは別
USDTはTetherが発行するトークンの名称です。対応状況と識別方法をネットワークごとに確認します。Ethereum（イーサリアム）メインネットでは、Tether公式「Supported Protocols」から該当トークンのコントラクトアドレスも確認できます。これはトークンプログラムを識別するアドレスであり、サービスが示す入金アドレスの代わりには使いません。
ネットワーク間でアドレス形式が同じ、あるいは同じ鍵から同じ見た目のアドレスが得られても、サービスが同じ入金処理を提供するとは限りません。安い経路が送信側にあっても、受取側が使えるとは限りません。両側が対応する経路を先に決め、その後に料金を比較します。
MemoとTagは受取側の指定に従う
MemoやTagは、一部の受取方法で利用者を識別する追加情報です。XRP Ledger公式「Source and Destination Tags」は、共通アドレスへの支払いを顧客へ対応付ける目的タグを説明しています。一部のX-addressはアドレスとタグを一緒に符号化しており、毎回必ず別欄へ入力するとは限りません。
受取画面の情報を完全に取得し、勝手にゼロを入れたり、他人のタグを使ったりしません。QRコードを読んでも照合は必要です。必要な追加情報を送信画面へ入力できない場合は、信頼できる公式サポートへ確認し、自動で含まれるとは推測しません。以下のUSDT例はMemo不要と仮定します。
20 USDTの例で送信条件を確認する
自分のウォレットAからEthereumメインネットを使い、サービスMが提示するアドレスRへUSDTを送ると仮定します。Mは架空の識別名で、最低受取量20 USDT、受付中、Memo不要という条件です。金額、最低量、以下の料金は教材用の設定で、実在サービスの現行条件ではありません。実際の送信も行いません。
手順1：今回の入金情報を受取側で取得する
自分で確認した公式入口を開き、USDTとEthereumメインネットを選んで入金アドレスを取得します。最低受取量、追加情報の要否、受付状態も記録します。ここではRという記号だけを使い、誤送金できる実在文字列は示しません。実際には自分の公式入金画面を使ってください。
Aへ戻り、同じネットワーク上の同じ資産であることを確認して完全なアドレスを貼り付けます。元の情報と全体を照合し、確定前にもう一度確認します。ハードウェアでは信頼できる機器の表示も比べます。履歴の見知らぬ少額入金から、似たアドレスを選ばないでください。
Mが受付停止中、またはAに別ネットワークの資産しかない場合は止めます。クロスチェーンには別の対応状況とリスク判断が必要です。画面でネットワーク名を変えても、既存資産が自動で別チェーンへ移るわけではありません。
手順2：入力額と実際の受取量を比べる
Aには100 USDTあり、20 USDTを送るとします。ネットワーク手数料はEthereumのネイティブ資産ETHで別に払います。後の取引が成功し、ほかの入金控除がないという条件なら、Rの受取量は20で、「20以上」の最低条件を満たします。別払いのETH手数料をUSDT数量から直接引いてはいけません。
次に送信元だけを別サービスへ替え、その仮定ルールでは入力20 USDTから出金手数料1 USDTを引くとします。実際の受取量は19で、同じ最低20に届かないため、送信前に中止または再計画します。この1は現在の料金でも全サービス共通の方式でもありません。手数料が別途加算なら別計算です。
少額テストでも最低量を調べる必要があるのは、このためです。小さい金額なら必ず反映されるわけではありません。Kraken公式「Cryptocurrency deposit is missing」も最低入金量を確認項目にしています。参照確認日は2026年10月27日です。借りているのは照合の考え方であり、実際の最低量ではありません。
手順3：ネットワーク手数料と最後の署名を確認する
自己管理ウォレットから送る本筋へ戻り、Aが0.004 ETHを持ち、今回の仮定の最大手数料が0.003 ETHだとします。この条件なら費用残高を確認できます。USDTが足りてもETHが足りるとは限りません。実費はまだ不明です。ガスはオンチェーン実行の料金計算の対象となる使用量で、上限と実費の違いはガス上限と実際の手数料で説明します。
最後にEthereumメインネット、正しいUSDT、R、20 USDT、料金条件を確認します。自分でのトークン送金と、第三者への利用承認は別の操作です。単に送る予定なのに未知の相手へ大きな権限を求められたら拒否し、理由を調べます。「テストだから」を不明な署名の許可理由にはしません。
送信後も同じ取引を段階ごとに照合する
送信後は元の取引を追い、二件目の送金で一件目の確認を代用しません。 以下は送信済みと仮定する分岐で、各段階の情報がそろってから次へ進みます。実際にブロードキャストしていなければ「未実行」とし、入金成功とは記録しません。
手順4：正しいネットワークのTxIDを見つける
送信ウォレットの履歴からTxIDを取得し、Ethereumメインネットの信頼できるブロックエクスプローラーで調べます。公開記録を読むツールなので、通常の照会にウォレット接続、シードフレーズの入力、署名は不要です。本例に実在TxIDはなく、教材の識別名を検索可能な取引として扱いません。
取引所からの出金でTxIDがまだなければ、サービス内で処理中かを先に調べます。TxIDがあっても見つからなければ、ネットワークとコピー内容を確認し、送信元へ照会します。「未送信」と「別ネットワークで検索」を分け、検索結果が空というだけで再送しないでください。
手順5：トークン・受取先・数量を確認する
ブロックへ取り込まれ、実行も成功したと仮定した後、トークン移転記録からUSDTコントラクト、実際の受取先R、20 USDTを照合します。トークン送金はコントラクト宛ての取引として実行される場合があるため、外側の受取先欄が最終のトークン受取人とは限りません。一つのアドレス欄だけで確認を終えないでください。
Ethereumでよく使うトークンのインターフェース規格ERC-20は、「Token Standard」で移転と関連イベントを定義しています。これが移転記録を調べる根拠です。違うコントラクト、数量不一致、別アドレスなら異常確認で止めます。同名トークンの別入金で穴埋めせず、名称やロゴでコントラクト識別を代用しません。
手順6：オンチェーン成功後にサービスへの反映を確認する
オンチェーン情報が計画に一致したら、Mで同じ入金の承認状況と残高反映を確認します。Mのルールに従い20 USDTが反映されて初めて、この例の経路は完了します。チェーン上の成功、サービスでの処理中、利用可能残高の増加は別の状態です。
未反映なら、ネットワーク、資産、TxID、受取先、数量、入金条件を残し、公式サポートへ問い合わせます。固定の数分待てばよいとは決め付けず、反応を見るための再送もしません。承認数と処理時間はその時点のサービス説明で確認します。
届かない場合は止まっている段階を特定する
未送信、処理待ち、実行失敗、サービス未反映には同じ対応を使えません。 段階を特定すると、送信側へ聞くか、受取側へ聞くか、新しい操作を止めるかが分かります。
処理待ち・実行失敗・口座未反映を分ける
pendingは処理待ちで、元の取引とウォレットの対応方法を調べます。実行失敗なら原因を確認します。Ethereum.org「Gas and fees」は、ブロックに入る前の拒否とオンチェーン実行失敗を区別し、後者には使用資源に応じた料金が発生する場合があると説明しています。成功済みなのにサービス未反映なら、資産、ネットワーク、最低量、追加情報、処理状況へ戻ります。実行失敗と入金遅延を混同しません。
ウォレット画面に一時的に表示されないだけでも、まずネットワークと正しいアカウントを調べます。公開オンチェーン記録とサービス残高は別の情報源であり、画面のゼロだけでは流出を証明できません。
誤ったネットワークや情報不足は再送で直らない
ネットワーク、アドレス、Memoを誤った場合、対応可能性は受取先の管理権限とサービス支援に左右されます。料金を払えば必ず戻るとは約束できません。前述のKrakenの説明も情報の誤りは公式サポートへ照会しますが、すべての誤りやサービスが復旧可能という意味ではありません。
自分が送っていない出金が見つかった、または知らないサイトへ復旧情報を渡した場合は、単なる未反映ではありません。新しい署名や追加送金を止め、ウォレットの不正利用への対応へ進みます。入金を急いで、回収を約束する相手へ秘密を渡さないでください。
今回の経路を照合できる記録として残す
資産とネットワーク、受取情報の取得時刻、実際の受取量の計算、TxID、最終状態を残せば、異常時にも同じ一件を追えます。次回もその時点の公式情報を確認します。一度の少額成功は、その経路の確認にすぎず、アドレス、サービス、以後の署名の永続的な安全は証明しません。
本記事は送金判断と照合の学習用で、投資助言ではありません。M、最低量、料金は仮定です。実際にはサービスとネットワークの条件を確認し、誤送金は回収できない場合があります。